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

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.

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

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

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.

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^® and a host.

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.

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.

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).

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.

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.