F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IP Service Provider: SIP Administration
  3. FAQ
Manual Chapter : FAQ

Applies To:

Show Versions Show Versions

BIG-IP LTM

  • 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0
Manual Chapter

FAQ

FAQ

Advanced-Protocols License

In versions 11.6 and 12.0, MRF SIP virtual servers will not start without an Advanced Protocols license in addition to the LTM license. The license check happens when configuration is loaded, /var/log/ltm file will contain a “MESSAGE ROUTING SIP feature not licensed” line. Since the check only happens when config is loaded, no additional message will be displayed when trying to connect to the virtual server.
Starting with version 12.1, the Advanced Protocol License requirement is no longer required. Only an LTM license is necessary to use SIP.

Bi-Directional Persistence

Some persistence types, like Call-ID, write bidirectional persistence records. The entry records both SIP devices involved in the call and the transport used to connect to that device. Messages received using the call-id will be matched against the persistence entry to determine which SIP device the message should be forwarded to.

Transport Translation

Transport translation is not supported. In other words, a UDP client connection cannot be sent to a TCP peer and vice versa.

Connection Recreation

One interesting thing to consider is the snat setting for the virtual server. Lets say that you have two virtual servers inbound_vs and outbound_vs. Each virtual server has a route which uses a corresponding transport config, inbound_tc and outbound_tc. Calls received by the inbound_vs would be routed to connection created using the settings of inbound_tc. The persistence entry for these calls would contain the inbound_vs as the source transport and the inbound_tc as the destination transport.
Likewise calls received by the outbound_vs would be routed to connections created using the setting of outgound_tc. The persistence entry for these calls would contain the outbound_vs as the source transport and outboind_tc as the destination transport. If a call arrives on a connection created via outbound_tc and a valid persistence entry still exists, it would route to a connection using the outbound_vs transport. If no connection is found, it would create a new outbound connection using the outbound_vs’s parameters.
Therefore, the virtual server SNAT setting should be that of the VLAN it is on. This is opposite from traditional BIG-IP virtual servers.
Lets say that the inbound_vs listens on the external VLAN and the outbound_tc is for creating connections on the external vlan. The inbound_vs’s SNAT settings are what would be used for creating outgoing connections also on the external VLAN. Inbound_vs’s snat setting would never be used for creating connection on the internal VLAN.
In this case, the SNAT settings of the inbound_vs should match the SNAT settings of the outbound_tc. Likewise the SNAT settings of the outbound_vs should match the SNAT settings of the inbound_tc.

Message Retry

When a message fails to route, it will be returned to the originating connflow and MR_FAILED event will be raised. A iRule script will be able to examine the message and resubmit it for routing via the MR::retry command.
There are multiple steps to routing, to understand how MR::retry will work, you will need to understand the steps. To avoid some of these steps or force a different path you may need to modify some of the metadata contained with the message.
Steps of routing:
  1. If the message’s nexthop attribute is set, the message will be forwarded to the TMM and flowid specified in the nexthop. To avoid this, the message’s nexthop should be cleared via ‘MR::message nexthop none’.
  2. If the message’s route attribute is set, the message will skip persistence lookup and route selection and proceed to peer selection (step 5) and lb_pick. Every time route lookup occurs, the message’s route attribute is set. To ensure persistence lookup occurs the route attribute should be cleared via ‘MR::message route none’.
  3. If persistence is enabled on the originating transport, the generated persistence key (via config or iRule) will be used to look for a persistence record. If a persistence record is found, the message will be forwarded to the host specified in the persistence record (step 7). To remove any previous persistence record stored under the message’s key use ‘SIP::persist reset’ or ‘DIAMETER::persist reset’ iRule command. NOTE: The DIAMETER command is not yet implemented.
  4. The protocol specific route table implementation will lookup the best route for the message based on a protocol specific attributes contained in the message. For SIP, it uses the request-uri, to-uri and from-uri of the message. It is also able to match against the virtual server of the originator of the connection. Once a route is found, the message’s route attribute is populated with the route.
  5. The route found contains a peer list. A peer is selected from the peer list using the peer selection mode.
  6. The selected peer may contain a pool and a transport. If a pool exists, it will select the first active pool member that has not already be attempted for this message. If no pool exists, it will forward the message to the local IP and port of the incoming connection.
  7. Once a host has been selected, MRF will look to see if an available connection already exists to the host. If an available connection exists, the message will be egressed to the host via that connection. If an available connection does not exist, a new connection will be created and the message will be forwarded through the new connection
Examples
Retry the message to a known existing connection:
when MR_FAILED {
 MR::message nexthop 0:010000010111
 MR::retry
}
Retry the message to a pool of alternate servers
When MR_FAILED {
   MR::message nexthop none
   SIP::persist reset
   MR::message route config /Common/BackupTc pool /Common/BackupPool
   MR::retry
 }
Retry the message via the same persistence key
When MR_FAILED {
  MR::message nexthop none
  MR::message route none
  MR::retry
}
To reroute
When MR_FAILED {
  MR::message nexthop none
  MR::message route none
  SIP::persist reset
  MR::retry
 }
To forward to a host
When MR_FAILED {
  MR::message nexthop none
  SIP::persist reset
  MR::message route config /Common/BackupTc host 10.10.10.10:5060
  MR::retry
}

Connection Auto-Initialization

If a peer object has auto-initialization enabled, the BIG-IP® system will automatically create outbound connections to the active pool members in the specified pool using the configuration of the specified transport-config. For auto-initialization to attempt to create a connection, the peer must be included in a route that is attached to a router instance. For each router instance that the peer is contained in, a connection will be initiated. The auto-initialization logic will verify at a configurable interval if the a connection exists between the BIG-IP and the pool members of the pool. If a connection does not exist, it will attempt to reestablish one.
The first auto-intialization attempt will occur at least one auto-initialization-interval delay from when the object is loaded or changed in the TMM.
If the router instance is not included in any virtual servers, connection auto-initialization will not start. Once the router instance has been included in an enabled virtual server, auto-initialization will begin and will remain running for those peers used by routes attached to the router instance even if the router instance is removed from the virtual server.
If a peer with auto-initialization enabled, is used in multiple router instances, a separate connection will be established for each router instance.
The auto-initialization logic will only attempt to create connections to enabled pool members. If the pool member is marked down by an external monitor it will be ignored unless an inband monitor is also attached.
If mirroring is enabled on the router instance, the active device will initialize outgoing connections. The new outgoing connections will be mirrored to the standby device.

Sharing iRule variables between connections

MRF does not join the client side connection with the server side connection (except for SIP ALG). The traditional method of using the CLIENTSIDE or SERVERSIDE keywords to access variables will not work. Instead MRF provides a command to deliver tcl variables along side of the message to the outgoing connection. The MR::store command allows the script author to specify which tcl variables should be delivered to the outgoing connection. The MR::restore command unpacks the delivered variables on the outgoing connection and adds them to the connections context.
For example on the incoming connection:
when MR_INGRESS {
  set originator_ip [IP::remote_add]
  set ingress_message_count [expr $message_count + 1]
  MR::store originator_ip ingress_message_count
}
On the outgoing connection:
when MR_EGRESS {
  MR::restore
  log local0. "originator_ip $originator_ip ingress_message_count $ingress_message_count"
}

iRules on all transports

With MRF the outgoing connection may not use the same transport as the incoming connection. Incoming connections are defined via virtual servers. Outgoing connections are often defined with transport-configs. If the same iRule script is desired to run on all connections, the script should be defined for all transports.
For example tests assume a simple load balancing configuration with a virtual server (VS_IN) that is part of a router instance with a single default route. This default route contains a single peer that uses a transport-config (TC_OUT) to define the parameters of the outgoing connection. In this setup, a request message would be received on VS_IN. The request message would ingress on a hudchain configured via the settings of the virtual server. As the message was processed, the SIP_REQUEST and MR_INGRESS events would be raised on the iRule scripts attached to the virtual server. The request message would be forwarded to an outgoing connection configured via the setting of the transport-config. As the message egressed through the outgoing connection, the MR_EGRESS and SIP_REQUEST_SEND events would be raised on the iRule scripts attached to the transport-config. When the response message is received by the outgoing connection, the SIP_RESPONSE and MR_INGRESS events would be raised on the iRule script attached to the transport-config. The response will be forwarded to the connection that originated the request and the MR_EGRESS and SIP_RESPONSE_SEND events would be raised on the iRule script attached to the virtual server.
iRules on all transports
iRules on all transports

The effect of message pipelining on iRule variables

SIP can pipeline messages by allowing messages that require less processing to be forwarded without waiting for earlier messages that require more processing. For this reason, it is not recommended to store state in tcl variables to be used by subsequent iRule events. There is no guarantee that the next event raised after the protocol's message event will be the MR_INGRESS for the same message. For example, saving the SIP uri in a tcl variable during a SIP_REQUEST event to use for making a routing decision during MR_INGRESS is not recommended. The next MR_INGRESS event may not be for the same message as the last SIP_REQUEST event.
MRF SIP implementation allows accessing the SIP iRule commands during the MR events. This is the recommended method to make routing and delivery decisions based on attributes of a message.
For example:
when MR_INGRESS {
  if {[URI::host [SIP::uri]] equal "othersp.com"} {
    MR::message route config "/Common/othersp_tc" pool "/Common/othersp_pool"
  }
}

SNAT settings of the outgoing transport used

MRF uses the SNAT setting of the outgoing connection to determine how the source address is translated. Most outgoing connections are configured via a transport-config and the SNAT setting of the transport config will be used to select the source address. The only time the SNAT settings defined in the virtual server are used is if the setting of the virtual is used to create the outgoing connection (this occurs if no transport-config is set in the peer object).

Connection Reuse

MRF maintains a table of all existing connections on each TMM of a router instance. When a message is routed to a host, MRF will scan this table for an existing connection to the host that is available for use. If an available existing connection is not found, a new connection will be created.
There are many reasons that an existing connection may not be available for delivery of the current message (see the sub-sections below for details).

Transport

Each connection is created using the parameters of a transport object (either a virtual server or a transport-config). The transport specifies the profiles, SNAT and iRule scripts of the connection. When a message is routed, MRF will scan the list of connections for a connection created with the same transport specified. Even if the two transports contain the same parameters, a connection created with a different transport will not be used.
A pool object only allows specification of a transport-config as the outgoing connection transport. If the peer object does not specify the transport config, the transport of the message's originating connection will be used. If the system wishes to potentially deliver a message through an existing connection created with by different virtual server on the same router, the MR::message route iRule command must be used. For example:
MR::message route virtual "/Common/internal_vs" host [IP::local_addr]:5060

Remote Port and ignore-clientside-port (or ignore-peer-port)

Many clients when creating connections use an ephemeral port for the local port. If a message is routed to that host, the port specified in the host's address will be different than the remote port of any existing connection with the host. Many MRF protocol implementation have an 'ignore_clientside_port' attribute in their router profile. Setting attribute to 'true' instructs MRF that any connection created by the host (client side) that matches the transport, remote IP and rtdom_id may be used.

Number-connections and instance number

The number-connections attribute of the peer object specifies which connection of a set of connections to a host will be used for delivering a message. It is used alongside the connection-mode instance to set the maximum number of connections between a router instance not the BIG-IP® system and a host.

Connection-mode

Each peer object specifies a connection mode which is used to determine if a connection can be reused or if a new connection should be created. Possible connection modes are:
  • per-peer: When a message is routed to a peer with per-peer connection mode, any connection on any TMM with the correct instance number may be used for delivering the message.
  • per-blade: When a message is routed to a peer with per-blade connection mode, only connections on the current blade with the correct instance number may be used for delivering the message.
  • per-tmm: When a message is routed to a peer with per-tmm connection mode, only connections on the current tmm with the correct instance number may be used for delivering the message.
  • per-client: When a message is route to a peer with per-client connection mode, an outgoing connection will be created for exclusive use by the originating connection. The outgoing connection will not be usable for delivering messages from other connections. Any message received (request or response) on the created outgoing connection will be automatically delivered to the originating connection that owns the outgoing connection.

use-local-connection

Many MRF protocol router profiles contain a 'use-local-connection' attribute. If this attribute is set, if a outgoing connection exists on the current TMM, it will be used even if the instance number does not match. Using this optimization will effectively limit the number of outgoing connections to one per TMM.

Source port

MRF allows setting the source port used on outgoing connections through the source-port attribute of a transport-config object. Setting this attribute to a non-zero value causes the source port of the outgoing connection to be set to the provided value. If set to zero an ephemeral port value will be used.
Pinning the source port to a fixed value will limit the number of connections available to the host. There can only be one connection using the local and remote tuples (IP/port/rtdom_id) and IP protocol (TCP/UDP/SCTP). Attempts to create another connection using the same addresses and IP protocol will fail.
For this reason it is not recommended to use set the source port for outgoing connections except when using a connection-mode of 'per-peer' and a number-connections of '1'.
Likewise trying to use the same host from peers with different transport settings (transport-config and/or virtual) and setting the source port will produce failures (unless different SNAT pools are used).

LB Operating Mode

Response messages being processed by different router instance

SIP routes response messages by inserting a VIA header into the request message. This VIA header contains a branch parameter that is used to contain the internal identifier of the connection that originated the request. The contents of the branch header are encrypted.
When the response message is received, it will contain the inserted VIA header. This inserted header is removed from the message and the branch parameter is decrypted to get the connection identifier of the request's originator. The message will be forwarded to the originating connection. If the originating connection has since been closed, the address in the next top-most header will be used for routing the response message.
This method frees MRF SIP from having to store any data internally while waiting for a response message. All information needed to route the response is added to the message and will be returned with the response. This method works whether the message is returned to the same connection that it was sent from or a new connection.
But if the response message is returned to a different router instance, the branch parameter of the VIA header cannot be decrypted. "MR SIP: Decrypt branch parameter failed with error : Buffer error" will be recorded in /var/log/tmm.

Response message routing (insert-via and honor-via settings)

SIP can be configured to route responses twice using two different methods.
The first method attempts to route the message to the connection that originated the request message. This is enabled via the 'insert-via' attribute of the sipsession profile. If set, the request message will have a new via header inserted into the message. This via header will identify the IP and port that the next SIP device should route the response to. The response message should contain all the via headers included in the request message. Each SIP device will remove the via header it inserted as the response passes through. An example inserted via is as follows:
Via: SIP/2.0/UDP 10.10.10.5:5060;rport;branch=z9hG4bKPjlL6pbh49PLliE2ZNBsASKyO7EBckaoQt
When a response is received and insert-via is enabled, the top most via will be removed, and the message will be forwarded to the connection identified by setting the nexthop meta-data field of the message. This can be observed by logging the message's nexthop field during MR_INGRESS event as follows:
when MR_INGRESS {
  if {[SIP::response code] ne ""} {
    log local0. "Response: nexthop [MR::message nexthop]"
  }
}
If the request's originating connection no longer exists, the MRF proxy will return the message to the connection that received the response. The MR_FAILED event will be raised. Upon completion of the MR_FAILED logic, the message will be returned the the SIP filter. The SIP filter will use the fallback response routing mechanism if the 'honor-via' attribute is enabled. The fallback response routing used the IP and port of the second topmost VIA header of the received response (now the topmost after deleting the inserted one). This is the via header that was topmost when the request message was received. This header should contain the IP and port that the device which sent the request to the BIG-IP.
The MRF SIP filter will clear the message's nexthop field and instead set the message's route meta-data field to route the message to the IP and port of the device which sent the request to the BIG-IP. Once the route field has been set, the message will again be forwarded to the MRF proxy for routing and MR_INGRESS event will be raised.
The route command will specify the transport of the connection that received the response as the transport to use when creating the connection to the source of the request. If this is not desired, the route field can be modified during the subsequent MR_INGRESS event.

ALG without SNAT (No Address Translation)

  • Snoop control messages flowing through to manage media flows.
  • iRule can be used to rewrite headers.
  • Create media records in session db.
  • Create deny listeners to drop media packets received before the callee responds with its media details.
  • Create media flows to forward packets between caller and callee.
  • High Availability (HA)
    • Call table replication (supports failback)
    • Control connection mirroring (can be recreated on failback by endpoint)
    • Media flow mirroring

Routing using a virtual with SNAT none may select a source port of zero

MRF allows routing to a peer without a transport-config selected. If a peer does not have a transport-config, the transport of the message originating connection will be used to create the outgoing connection. If originating connection used a virtual server as its transport, the serverside of the virtual server will be used to create the outgoing connection.
If the virtual server had a SNAT setting of none and the 'source-port' attribute set to 'preserve' or 'preserve-strict', the outgoing connection will be created with a source port of zero instead of the remote port of the originating connection.

SIP ENUM Resolution Capability using iRule

DNS team has developed an iRule called RESOLV::lookup to perform a DNS query . From release 11.5.0, its capability was improved to support resolving NAPTR and SRV addresses as well. SIP ENUM resolution mainly involves resolving Telephone number to an IP address. This process normally involves 4 steps namely
  • Normalizing the telephone number to an ENUM address format.
  • Perform NAPTR resolution on ENUM to retrieve SRV records.
  • Perform SRV resolution to retrieve Domain Name records.
  • Perform DNS query to retrieve the IP Address.
RESOLV::lookup with its new capabilities could potentially be used to resolve ENUM to IP Address.
Eg: NAPTR resolution to retrieve SRV records.
RESOLV::lookup @$static::dns_vs inet -naptr "4.4.2.2.3.3.5.6.8.1.4.4.e164.arpa"
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information