Operation Modes

Manual Chapter : Operation Modes

Applies To:

Show Versions

BIG-IP LTM

13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0

Operation Modes

Load Balancing

Configuration Objects

Virtual Server

A virtual server is a traffic-management object on the BIG-IP^® system that is represented by an IP address and a service. Clients on an external network can send application traffic to a virtual server, which then directs the traffic according to your configuration instructions.

The virtual server configuration contains a destination address and mask which specifies what IP addresses and port the virtual server will listen for incoming packets. The virtual server object also contains a source address allowing it to limit packets to those packets that originate from a range of devices.

The behavior of a virtual server is determined by the set of profiles attached to the virtual server. To configure a MRF SIP virtual server, transport profile (TCP, UDP or SCTP), a sipsession profile and a siprouter profile must be attached to the virtual server.

The behavior of a virtual can further be extended by assigning iRules to the virtual.

All virtual servers that share the same siprouter profile will share the same router instance. The routing instance owns the route table, the persistence table and flowmap table (a table of all open connection usable for message forwarding).

A virtual server of type "message-routing" assigned with "session" & "router" profile is part of a SIP router-instance.
Persistence is configured through the SIP session profile, hence a persist profile must not be attached to the virtual server.
One or more iRules can be attached. The rules are validated against the configured transport and the events/commands as supported by SIP and MRF.
Source-address-translation can be configured in the virtual server. For server side flows the transport-config parameters overrides the virtual server setting for source address translation. If a route does not specify a transport-config, than the transport of the originator of the message will be as the transport for the outgoing connection. For example if the SIP message originated on a virtual server, the parameters of the virtual server will be used to create the outgoing connection. This includes the source-address-translation settings of the virtual server.
A static route object containing wildcard attributes can be used as a default route. The configured by adding a SIP route with empty request-uri, from-uri and to-uri attributes to the siprouter profile used by the virtual server.
Static routes can be configured to only operate on messages originating for specific virtuals. This allows each virtual using the same router instance to have independent default routes.
The virtual can be configured to listen on all or selected set of VLANs.
All virtuals that needs to work together as one router-instance must share the same "router" profile.
All virtuals that are to acts as one router-instance, must have the all their corresponding Virtual Addresses in the same traffic group. The traffic group of the siprouter profile must match the traffic-group of the virtual's virtual address.

ltm virtual <virtual name> {
    cmp-enabled yes
    destination <ip address>:<port>
    enabled | disabled
    ip-protocol <tcp|udp|sctp>
    mask <netmask>
    profiles {
        siprouter
        sipsession
        <tcp|udp|sctp>
        <other profiles>
    }
    rules <list of iRules|none>
    source 0.0.0.0/0
    vlans {
        <list of vlans>
    }
    vlans-enabled | vlans-disabled
}

SIP Router Profile

SIP Router Profile Entity-Relationship

A SIP router profile provides the router-instance level characteristics such as mode of operation, routes and more. This profile defines attributes that are to be the same across the entire router-instance. In addition, it holds the static routes to be used across the entire router-instance.
A route is made of peers, where a peer may have a pool and a transport config
If a peer does not contain a pool, the local address of the originating connection is used as the remote address of the outgoing connection
If a peer does not contain a transport-config, the settings of the originating connections transport (virtual or transport-config) is used to create the outgoing connection.
The router profile binds the multiple virtuals (that clients connect to) and peers (that connect to backend servers), together with common shared states.
For ALG, no routes are configured for the router profile. The local address of the originating flow is used as the remote address of the outgoing connection.

ltm message-routing sip profile router siprouter {
    defaults-from none
    inherited-traffic-group <true|false>
    max-pending-bytes <integer>
    max-pending-messages <integer>
    max-retries <integer>
    mirror <enabled|disabled>
    mirrored-message-sweeper-interval <integer>
    operation-mode load-balancing
    routes {
        <static routes>*
    }
    session {
        max-session-timeout <integer>
        transaction-timeout <integer>
    }
    traffic-group <traffic group name>
    use-local-connection <enabled|disabled>
}

Table 1. SIP router profile attributes
Attribute	Description	Type	Acceptable Values	Default
operation-mode	Sets the operation mode of the SIP routing instance. Must be set to load-balancing	ENUM	load-balancing application-level-gateway	load-balancing
routes	List of references to sip-route object. The ordering of the route entries does not matter.	sip-route	A list of sip-route objects
max-pending-messages	The maximum number of pending messages that are held while waiting for a connection to a peer to be created. Once reached any additional messages to the peer is flagged as undeliverable and returned to the originator.	UINT32	1 to 4294967295 (32-bits)	23768
max-pending-bytes	The maximum number of bytes contained within pending messages that is held while waiting for a connection to a peer to be created. Once reached any additional messages to the peer is flagged as undeliverable and returned to the originator.	UINT32	1 to 4294967295 (32-bits)	64
use-local-connection	Controls whether connections established by the ingress TMM are preferred over connections established by other TMMs when selecting egress connection to destination peer.	BOOL	Enabled/Disabled	Enabled
traffic-group	The traffic group for the router instance. All virtual servers using this router profile will have the their traffic group replaced by the traffic group of the router profile.	traffic-group		default (inherited from partition)
mirror	Enables mirroring of all incoming connections for all virtual servers using this router instance, and all outgoing connection created by this router instance.	BOOL	enabled/disabled	disabled
mirrored-message-sweeper-interval	This attribute sets the frequency of the mirrored message sweeper. For virtual servers where mirroring is enabled, the received messages will be processed on both the active device and the standby device. On the standby device, the messages are not routed, instead they are stored in a message store until the active device sends a notification that the message has been routed to the standby device so that the standby device can deliver the message to the equivalent connection for egress processing. A sweeper has been implemented to drop messages from the message store if they remain in the store longer than the time specified in this attribute. The time shall be in milliseconds.	UINT32		1000(ms)
media-proxy
max-media-sessions	N/A in LB Mode	UINT32	1 to 10 (32-bits)	6
media-inactivity-timeout	N/A in LB Mode	UINT32	1 to 120 (32-bits)	120
session
dialog-establishment-timeout	N/A in LB Mode	UINT32	1 to 4294967295 (32-bits)	32
max-session-timeout	N/A in LB Mode	UINT32	1 to 4294967295 (32-bits)	7200
transaction-timeout	Specifies the maximum time in seconds between request and its response. A provisional response restarts the timer. This may not affect all transactions. The scenarios where a BIG-IP^® system waits for response (like final response for REGISTER request), is impacted, by dropping any persistent data maintained for this request.	UINT32	1 to 4294967295 (32-bits)	180

Operation Mode

Table 2. SIP operation mode
operation-mode	Description
load-balancing	Configures the SIP routing instance to operate in load-balancing mode. See How to configure DAG Modes for details.
application-level-gateway	Configures the SIP routing instance to operate in application level gateway mode (ALG). See Default DAG for details

SIP Route Table

SIP routes are collected into a route table.
Each SIP router instance maintains a route table.
When the SIP router receives a message for forwarding, the route table is used to determining the best route to use for forwarding the message.
The message's to-uri (RFC 3261 section 8.1.1.2), from-uri (RFC 3261 section 8.1.1.3), request-uri (RFC 3261 section 8.1.1.1) attributes and originating virtual is matched against the routes in the route table.

Table 3. SIP Route table example
From-URI	To-URI	Route Value
		Default_pool
	*.f5.com	Subdomain pool
	*@f5.com	F5 domain pool
	help@f5.com	Helpdesk pool
*@external.com		External pool
priority.user@isp.net	help@f5.com	Special helpdesk pool

Attributes Matching

The attributes is matched in the following order: to-uri, from-uri, request-uri and virtual.
Each URI is matched starting at the end of the attribute.
Because a URI key may contain a wildcard, a URI from a messages attribute may match multiple attributes, the longest match for the attribute is tried first.
If a matching route does not exist using the longest match, the next longest match is attempted.
An empty field is the same as a wildcard (all values are considered to match).
Route selection first matches the to-uri then the from-uri, followed by the request-uri and finally the virtual.
Each field is matched starting at the end of the field (last character).
There can be no characters before a wildcard (asterisk).

Specific Route Match Example

Consider a SIP route table with following routes:

Table 4. SIP route match
To-URI	Virtual	Route Value
		default-route
*.f5.com		subdomain-route
*af5.com		f5domain-route
help@f5.com		helpdesk-route
it@f5.com	internal_vs	it-route

To route a message with the following attributes:

Table 5. SIP route match
To-URI	From-URI	Request-URI	Virtual
it@f5.com	top.salesman@vendor.com	it@f5.com	external_vs

The SIP route table (refer table 3.3.3) would first look for a match for the to-uri.
It would find 3 matches: "" (wildcard), "*@f5.com", and "it@f5.com".
The longest match would be "it@f5.com". It would then try to match from-uri, request-uri and virtual.
The from-uri attribute would match the wildcard as would the request-uri.
The virtual would not match.
No match was found using "it@f5.com", so it would return to the next longest matching value, "*@f5.com".
It would then try and match from-uri, request-uri and virtual.
Matches for all three fields would be found so it would forward the message to a host as specified in the route value of the f5 domain route in table 3.3.3

SIP Route

ltm message-routing sip route siproute {
    from-uri <string>
    peer-selection-mode <sequential|ratio>
    peers {
        <one or more peer>
    }
    request-uri <string>
    to-uri <string>
    virtual-server <string>
}

The SIP route has the following attributes.

Table 6. SIP Route Attributes
Attribute	Description	Type	Acceptable Values	Default
name	Specifies the name of the route object	STRING	ASCII string	None
request-uri	Defines the pattern to be matched against the request-uri of a sip message. This URI is matched as a case insignificant method. It should be in the form of user@domain. The sip: prefix should not be present. Any additional modifiers (for example port or transport) should also not be present. It may begin with a wildcard, ‘*’. If empty, it is treated as if the entire URI was a wildcard (matching all Request-URIs).	STRING	ASCII string format: <user@domain>	""
to-uri	Defines the pattern to be matched against the To field of a sip message. This URI is matched as a case insignificant method. It should be in the form of user@domain. The sip: prefix should not be present. Any additional modifiers (for example port or transport) should also not be present. It may begin with a wildcard, ‘*’. If empty, it is treated as if the entire URI was a wildcard (matching all To-URIs).	STRING	ASCII string format: <user@domain>	""
from-uri	Defines the pattern to be matched against the From field of a sip message. This URI is matched as a case insignificant method. It should be in the form of user@domain. The sip: prefix should not be present. Any additional modifiers (for example port or transport) should also not be present. It may begin with a wildcard, ‘*’. If empty, it is treated as if the entire URI was a wildcard (matching all From-URIs).	STRING	ASCII string format: <user@domain>	""
virtual-server	Specifies a virtual server that this route is limited to. If no virtual is specified, messages originating on any connection may be routed to the route.	virtual-server	A virtual server instance	None
peers	Specifies the list of peers. The peers attribute is a list of references to mr-peer objects.	mr-peer	An instance or mr-peer
peer-selection-mode	Describes the method of selecting a peer from a list of peers. sequential: Peers are selected in the order listed. All traffic is routed to the first peer unless all pool members in the peer are marked down. ratio: Peers are selected based on their weights in comparison with other peers.	ENUM	sequential/ratio	sequential

A SIP route specifies a set of peers to use for forwarding messages. Each route contains a route key and a route value. The route key contains attributes that are matched against attributes in a SIP message. The route value contains a list of peers. If the attributes in the route key match, the message is forwarded to a host specified by route value.

Route Key

The route key contains the attributes that are matched against attributes from the SIP message header and optionally a list of virtual servers.

The to-uri, from-uri and request-uri attributes are matched against corresponding attributes in a SIP message's header.
These values are matched in a case insignificant method.
Only the user@host portion of the uri is matched. The protocol prefix and additional modifiers (like port, transport, key, etc) are not included in the match. (see RFC 3261 section 19.1)
The uri key in the message may start with a wildcard character, '*' (for example '*@f5.com'). If a uri key starts with a wildcard, this means that any valid pattern of characters at that position in the message's corresponding attribute is considered as matching refer section 3.3.1.1
An empty uri key is considered as matching any valid value in the message's corresponding attribute.
If virtual server attribute in the route key is empty, the route is applied to all messages. If the virtual server attribute is not empty, the route applies only to messages originating the virtual server specified.
A route key with all fields empty (wildcard) is used as a default route.

Table 7. Filtered URI for Route Key
Example URI	Filtered URI for matching
sip: alice@atlanta.com	alice@atlanta.com
sip: alice:secretword@atlanta.com;transport=tcp	alice@atlanta.com
sips:alice@atlanta.com?subject=project%20x&priority=urgent	alice@atlanta.com
sip:+1-212-555-1212:1234@gateway.com;user=phone	+1-212-555-1212@gateway.com
sips: 1212@gateway.com	1212@gateway.com
sip:alice@192.0.2.4	alice@192.0.2.4
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com	atlanta.com
sip:alice; day=tuesday@atlanta.com	alice@atlanta.com

Route Value

The route value contains a list of peers and a peer selection mode attribute.

Peer Selection

The peer selection mode attribute specifies how a peer in the peer list is selected. Available values are sequential and ratio.
If the contained peers contain different transport types (ipproto), TCP, UDP, SCTP, only those peers that match the transport type of the originating connection is used for peer selection.
In sequential mode, the peers are selected in the order listed. The first peer is used unless all of its members are down.
In ratio mode, the ratio value in each peer shall be used to determine the distribution of message to each peer.
Once a peer has been selected, a pool member from the peer's pool is selected based on the pool's lb-mode attribute.
The peer's transport-config name (MR transport-config object refer to HighperformancemessageroutingframeworkforIMSprotocolsFS#Transport-config) is used to configure the type of connection (transport, security, protocol, rules, snat).

Host Selection

If the selected peer does not contain a pool, the destination ip and port of the message's originating connection is used as the destination host.
If the selected peer does not contain a transport-config name, the transport type and name of the message's originating connection is used as the destination host.
If the selected peer contains a pool with no pool members, the message is returned to the originator marked as unroutable.
If the selected peer contains a pool with pool members. one active pool member is selected as per the pool's specified load balancing mode.

SIP Session Profile

This profile is attached to every virtual & associated with each peer of a routing instance. This profile has settings that can affect the SIP message processing. Multiple SIP session profiles can be in use in a single routing instance. The virtual/peer processes the ingress/egress messages per its sip-session profile settings.

ltm message-routing sip profile session sipsession {
    custom-via <string>
    defaults-from none
    do-not-connect-back <enabled|disabled>
    enable-sip-firewall <yes|no>
    generate-response-on-failure <enabled|disabled>
    honor-via <enabled|disabled>
    insert-record-route-header <enabled|disabled>
    insert-via-header <enabled|disabled>
    loop-detection <enabled|disabled>
    maintenance-mode <enabled|disabled>
    max-forwards-check <enabled|disabled>
    max-msg-header-count <integer>
    max-msg-header-size <integer>
    max-msg-size <integer>
    persistence {
        persist-key <Call-ID|Src-Addr|Custom>
        persist-timeout <integer>
        persist-type <session|none>
    }
}

The sip protocol profile has the following attributes.

Table 8. SIP Session Profile Attributes
Attribute	Description	Type	Acceptable Values	Default
max-msg-size	Specifies the maximum acceptable SIP message size in bytes. The message that exceeds this size is silently discarded.	UINT32	1 to 4294967295 (32-bits)	65535
max-msg-header-count	Specifies the maximum count of expected header fields; The message that exceeds this limit is silently discarded.	UINT32	6 to 4096	64
max-msg-header-size	Specifies the maximum message header size in bytes; The message that exceeds this limit is silently discarded.	UINT32	1 to 4294967295 (32-bits)	16000
generate-response-on-failure	Enables to send failure response messages such as 4xx, 5xx and 6xx, when a SIP request is being dropped; Note: Where it is specified "silently" discarded/dropped, no error response is generated. In any case, a dropped message (request/response) is tracked in appropriate statistics counter.	BOOL	Enabled/Disabled	Disabled
Maintenance Mode	When selected (enabled), sends a SIP response of 503 Service Unavailable for an incoming SIP request. The SIP response to the SIP request is dropped.	BOOL	Enabled/Disabled	Disabled
max-forwards-check	Enables check on max-forwards; If 0, the request is discarded. An error response is sent, if configured.	BOOL	Enabled/Disabled	Enabled
loop-detection	Enables loop-detection check and in case loop detected, the request is discarded. An error response is sent, if configured. Note: A request is detected as seen before (forwarded/spiraled/looped) only if self inserted Via is found in the message and the value of its branch param plays a key role in detecting loop versus spiral. Hence enabling via insertion becomes a requirement to do loop detection check. In ALG mode, Via header is not inserted by default and there is no loop detection in this mode.	BOOL	Enabled/Disabled	Disabled
insert-via-header	Enables insertion of top Via; When enabled, custom params to help route the response back are inserted, along with sent-by field of Via. The source address:port of the flow forwarding the request is filled as value for sent-by field of Via unless user provides custom via value. The custom params inserted to help routing, helps improve performance as it facilitates routing without any lookup. The via is inserted at egress side of the flow, after SIP_REQUEST_SEND event.	BOOL	Enabled/Disabled	LB MODE: Enabled ALG MODE: disabled
custom-via	Specifies the custom value for the sent-by field of Via. Only the sent-by component value is mentioned here not the complete header.	STRING	<IP or FQDN name>[:<port>]	None
honor-via	Enables to honor via that is not inserted by a BIG-IP^® system for routing the response.	BOOL	Enabled/Disabled	LB MODE: Enabled ALG MODE: disabled
insert-record-route-header	Enables insertion of record-route header in requests that establish dialog. When enabled, along with URI, the custom params may be added to facilitate the routing of subsequent requests within this call to avoid route lookup. The record route URI is the local-IP & port of flows that are used for forwarding the message.	BOOL	Enabled/Disabled	Disabled
sip-firewall	Enables application of firewall policy	BOOL	Enabled/Disabled	Disabled
do-not-connect-back	Controls whether connection to a request originator is established (if it no longer exists) in order to deliver response. When disabled, responses that cannot be forward using an existing connection are dropped.	BOOL	Enabled/Disabled	Disabled
persistence
persist-key	Specifies the method to extract the key value that is used to persist on. Call-ID - To persist based on the "Call-ID" header field value in the message. Src-Addr - To persist based on originating IP address in the message Custom - To persist based on the custom key specified using iRule.	ENUM	Call-ID/Src-Addr/Custom	Call-ID
persist-type	Specifies the type of the persistence to be used for the specified "persist-key" attribute value, the currently supported type is session. Session - Uses session DB for storage, no hash is applied. The key used for session DB is value specified in the "persist-key" attribute. Insert-via-header must be enabled when persist-type is set to "Session", if not a validation error is thrown. None - Persistence is disabled Persistence is not applicable for SIP ALG modes.	ENUM	Session/None	Session
persist-timeout	Indicates the timeout value of persistence entries in seconds. It's recommended to have the persist-timeout to be greater than transaction timeout, specified in the SIP session configuration, as the lesser of the two is used when creating the persist record on receiving of the initial SIP request message. The initial SIP request can be INVITE/SUBSCRIBE/MESSAGE. Upon receiving of the response for the initial SIP Request message the persistence record is updated with the persist-timeout value. (For any subsequent responses received the persist timeout is updated for the persist record.)	UINT32	1 to 4294967295 (32-bits)	180

Peer Object

A peer object is used to define a set of hosts and the the method to connect with them. Peers are used to create static routes. The peer structure is protocol independent while each protocol implementation of MRF will define its own static route structure.

ltm message-routing sip peer <named-object> {
  app-service <string>
  auto-initialization <enabled/disabled>
  auto-initialization-interval <integer>
  connection-mode <per-peer/per-tmm/per-blade/per-client>
  description <string>
  number-connections <integer>
  partition <string>
  pool <pool_name>
  ratio <integer>
  transport-config <tc_name>
}

Peer Attributes

Table 9. Peer Attributes
Attribute	Description	Default
pool	Pool associated with the peer. If only one peer, then configure a single-member pool. If none, the message will be forwarded to the destination address and port of the originating connection.	none
transport-config	Specifies the transport-config that defines the parameters of the outgoing connection. If none, the parameters of the originating connection will be used to create the outgoing connection.	none
connection-mode	Specifies how the number of connections per peer are to be limited as follows: per-peer, per-blade, per-tmm, per-client. If a transport config is not specified, the attributes of the originating connection of the message being routed will be used to create the outgoing connection. In this case, the connection-mode in the peer object will be ignored.	per-peer
number-connections	Specifies the number of connections between the BIG-IP^® system and a peer. If a transport config is not specified, the attributes of the originating connection of the message being routed will be used to create the outgoing connection. In this case, the number-connections in the peer object will be ignored.	1
ratio	Used to designate the ratio of this peer when used within a route with a peer-selection-mode of ratio.	1
auto-initialization	If 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 system and the pool members of the pool. If a connection does not exist, it will attempt to reestablish one.	disabled
auto-initialization-interval	Specifies the interval (in milliseconds) that attempts to initiate a connection occur. Valid ranges are from 500ms to 65535ms	5000ms

Connection Modes

Per Peer

A BIG-IP^® system will make just one connection to a peer. This means that only one TMM is connected to each Peer. While this connection mode uses fewer connections it will introduce latency. This will happen when messages are disaggregated to the wrong TMM and must be forwarder. The following diagram provides additional detail.

Optimum scenario

Message arrives on a Virtual Server (VS)
Message is disaggregated to TMM-0
TMM-0 is connected to the correct server so the message is sent

Performance impacted scenario

Message arrives on a Virtual Server (VS)
Message is disaggregated to TMM-1
TMM-1 is not connected to Server 1 so message must be forwarded to the correct TMM. This will introduce latency.
TMM-0 is send message to Server 1

Per TMM

A BIG-IP^® system will make a connection from every TMM to the same peer. This means a machine with 8 cores will have 8 connections per peer. While this increases the number of active connections, it also improves performance because there is no need to forward messages between TMMs.

Every TMM is connected to every peer which decreases latency but increases the number of connections

Message arrives on a Virtual Server (VS)
Message is disaggregated to TMM-0
TMM-0 is connected to the correct server so the message is sent
Second message arrives
Message is disaggregated to TMM-1
TMM-1 is connected to the requested server so the message can be sent directly

Per Blade

A BIG-IP^® system creates one connection per blade to each peer. This provides a balanced performance approach between the per peer connection mode (only one connection) and a per tmm connection mode (a connection from each TMM). This mode only makes sense for a hardware chassis with multiple blades.

Each blade will make a single connection to each peer.

Message arrives on Blade 0
Blade 0 opens a connection to Server 1 and forwards the message
Second message arrives
Blade 1 opens a connection to server 1 and forwards the message

Note: A connection will not be opened to Server 2 until a message targeted at that server arrives.

Transport Config

A transport config defines the parameters of a new outgoing connection.

The behavior of a transport-config is determined by the set of profiles attached to it. To configure a MRF SIP transport-config a transport profile (TCP, UDP or SCTP), and a sipsession profile must be attached. The siprouter profile will be inherited by the router instance that creates the outgoing connection.

The behavior of a transport-config can further be extended by assigning iRules to it.

ltm message-routing sip transport-config <transport-1> {
   ip-protocol <tcp/udp/sctp/...>
   profiles {
      tcp {}
      diameter_protocol_test {}
   }
   source-address-translation {
      type automap
   }
   rules {
      some_irule
   }
   source-port <integer>
}

Transport Config Attributes

Table 10. Transport Config Attributes
Attribute	Description	Default
ip-protocol	Specifies the ip protocol. This will be automatically set based on the transport profile added. This value is read-only.	none
source-port	Specifies the source port to be used for the connection being created. If the source-port is zero, an empirical port will be used.	0
profiles	The transport protocol and the protocol-specific profile associated with this outgoing connection.
source-address-translation	Specifies the source-address-translation type and the pool.
rules	List of iRules associated with this outgoing connection.	none

Source Address Translation

Table 11. Source Address Translation
Sub-Attribute	Description	Default
type	Specifies the type of source address translation to perform	automap
pool	Specifies the name of the snap pool	none

Source Address Translation Types

Table 12. Source Address Translation Types
Type	Description
automap	The self-ip of the outgoing vlan will be used as the source address of the outgoing connection.
snat	A source address will be selected from the named snat pool
none	No source address translation will be performed.

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

Configuration Objects

Virtual Server

The behavior of a virtual server is determined by the set of profiles attached to the virtual server. To configure a MRF SIP virtual server, transport profile (TCP, UDP or SCTP), a sipsession-alg profile and a siprouter-alg profile must be attached to the virtual server.

The behavior of a virtual can further be extended by assigning iRules to the virtual.

A virtual server of type "message-routing" assigned with "session" & "router" profile is part of a SIP router-instance.
MRF SIP ALG does not require persistence or message routing.
Persistence is configured through the SIP session profile, hence a persist profile must not be attached to the virtual server.
One or more iRules can be attached. The rules are validated against the configured transport and the events/commands as supported by SIP and MRF.
MRF SIP ALG without source-address-translation does not support source-address-translation. The virtual's source-address-translation type must be set to none

Please note that profile call statistics in this mode will double-count hairpinned calls.

ltm virtual <virtual name> {
    cmp-enabled yes
    destination <ip address>:<port>
    enabled | disabled
    ip-protocol <tcp|udp|sctp>
    mask <netmask>
    profiles {
        siprouter-alg
        sipsession-alg
        <tcp|udp|sctp>
        <other profiles>
    }
    rules <list of iRules|none>
    source 0.0.0.0/0
    source-address-translation {
        type none
    }
    vlans {
        <list of vlans>
    }
    vlans-enabled | vlans-disabled
}

SIP Router Profile

ltm message-routing sip profile router siprouter-alg {
    inherited-traffic-group <true|false>
    max-pending-bytes <integer>
    max-pending-messages <integer>
    media-proxy {
        max-media-sessions <integer>
        media-inactivity-timeout <integer>
    }
    mirror <enabled|disabled>
    mirrored-message-sweeper-interval 1000
    operation-mode application-level-gateway
    routes none
    session {
        max-session-timeout <integer>
        transaction-timeout <integer>
    }
    traffic-group <traffic group name>
    use-local-connection enabled
}

Table 13. SIP Router Profile Attributes
Attribute	Description	Type	Acceptable Values	Default
operation-mode	Sets the operation mode of the SIP routing instance. Must be set to application-level-gateway.	ENUM	load-balancing application-level-gateway	load-balancing
routes	N/A in ALG Mode	sip-route	A list of sip-route objects
max-pending-messages	The maximum number of pending messages that are held while waiting for a connection to a peer to be created. Once reached any additional messages to the peer is flagged as undeliverable and returned to the originator.	UINT32	1 to 4294967295 (32-bits)	23768
max-pending-bytes	The maximum number of bytes contained within pending messages that is held while waiting for a connection to a peer to be created. Once reached any additional messages to the peer is flagged as undeliverable and returned to the originator.	UINT32	1 to 4294967295 (32-bits)	64
use-local-connection	N/A in ALG Mode	BOOL	Enabled/Disabled	Enabled
traffic-group	The traffic group for the router instance. All virtual servers using this router profile will have the their traffic group replaced by the traffic group of the router profile.	traffic-group		default (inherited from partition)
mirror	Enables mirroring of all incoming connections for all virtual servers using this router instance, and all outgoing connection created by this router instance.	BOOL	enabled/disabled	disabled
mirrored-message-sweeper-interval	This attribute sets the frequency of the mirrored message sweeper. For virtual servers where mirroring is enabled, the received messages will be processed on both the active device and the standby device. On the standby device, the messages are not routed, instead they are stored in a message store until the active device sends a notification that the message has been routed to the standby device so that the standby device can deliver the message to the equivalent connection for egress processing. A sweeper has been implemented to drop messages from the message store if they remain in the store longer than the time specified in this attribute. The time shall be in milliseconds.	UINT32		1000(ms)
media-proxy
max-media-sessions	This attribute is valid when the operation-mode is application-level-gateway. Specifies the maximum number of media sessions that are allowed per call.	UINT32	1 to 10 (32-bits)	6
media-inactivity-timeout	This attribute is valid when the operation-mode is application-level-gateway. Specifies the maximum duration (in seconds) that a media flow is active with no RTP packets. After this period the RTP flow is removed. This timeout is applicable only to RTP packet where as the RTCP packet will have the timeout set to the max-session-timeout.	UINT32	1 to 120 (32-bits)	120
session
dialog-establishment-timeout	This attribute is valid when the operation-mode is application-level-gateway. Specifies the timeout (in seconds) that represents the Timer B as per RFC 3261, the INVITE transaction timeout. The dialog-establishment-timeout is used by the Call Table. The default value is 32 seconds.	UINT32	1 to 4294967295 (32-bits)	32
max-session-timeout	This attribute is valid when the operation-mode is application-level-gateway. Specifies the maximum duration (in seconds) that a call and its media remains active. After this period the call and its media is terminated.	UINT32	1 to 4294967295 (32-bits)	7200
transaction-timeout	Specifies the maximum time in seconds between request and its response. A provisional response restarts the timer. This may not affect all transactions. The scenarios where BIG-IP waits for response (like final response for REGISTER request), is impacted, by dropping any persistent data maintained for this request.	UINT32	1 to 4294967295 (32-bits)	180

Operation Mode

Table 14. SIP operation mode
operation-mode	Description
load-balancing	Configures the SIP routing instance to operate in load-balancing mode. See How to configure DAG Modes for details.
application-level-gateway	Configures the SIP routing instance to operate in application level gateway mode (ALG). See Default DAG for details

SIP Session Profile

ltm message-routing sip profile session sipsession {
    custom-via <string>
    defaults-from none
    do-not-connect-back <enabled|disabled>
    enable-sip-firewall <yes|no>
    generate-response-on-failure <enabled|disabled>
    honor-via <enabled|disabled>
    insert-record-route-header <enabled|disabled>
    insert-via-header <enabled|disabled>
    loop-detection <enabled|disabled>
    maintenance-mode <enabled|disabled>
    max-forwards-check <enabled|disabled>
    max-msg-header-count <integer>
    max-msg-header-size <integer>
    max-msg-size <integer>
    persistence {
        persist-key <Call-ID|Src-Addr|Custom>
        persist-timeout <integer>
        persist-type <session|none>
    }
}

The sip protocol profile has the following attributes.

Table 15. SIP Session Profile Attributes
Attribute	Description	Type	Acceptable Values	Default
max-msg-size	Specifies the maximum acceptable SIP message size in bytes. The message that exceeds this size is silently discarded.	UINT32	1 to 4294967295 (32-bits)	65535
max-msg-header-count	Specifies the maximum count of expected header fields; The message that exceeds this limit is silently discarded.	UINT32	6 to 4096	64
max-msg-header-size	Specifies the maximum message header size in bytes; The message that exceeds this limit is silently discarded.	UINT32	1 to 4294967295 (32-bits)	16000
generate-response-on-failure	Enables to send failure response messages such as 4xx, 5xx and 6xx, when a SIP request is being dropped; Note: Where it is specified "silently" discarded/dropped, no error response is generated. In any case, a dropped message (request/response) is tracked in appropriate statistics counter.	BOOL	Enabled/Disabled	Disabled
Maintenance Mode	When selected (enabled), sends a SIP response of 503 Service Unavailable for an incoming SIP request. The SIP response to the SIP request is dropped.	BOOL	Enabled/Disabled	Disabled
max-forwards-check	Enables check on max-forwards; If 0, the request is discarded. An error response is sent, if configured.	BOOL	Enabled/Disabled	Enabled
loop-detection	Enables loop-detection check and in case loop detected, the request is discarded. An error response is sent, if configured. Note: A request is detected as seen before (forwarded/spiraled/looped) only if self inserted Via is found in the message and the value of its branch param plays a key role in detecting loop versus spiral. Hence enabling via insertion becomes a requirement to do loop detection check. In ALG mode, Via header is not inserted by default and there is no loop detection in this mode.	BOOL	Enabled/Disabled	Disabled
insert-via-header	Enables insertion of top Via; When enabled, custom params to help route the response back are inserted, along with sent-by field of Via. The source address:port of the flow forwarding the request is filled as value for sent-by field of Via unless user provides custom via value. The custom params inserted to help routing, helps improve performance as it facilitates routing without any lookup. The via is inserted at egress side of the flow, after SIP_REQUEST_SEND event.	BOOL	Enabled/Disabled	LB MODE: Enabled ALG MODE: disabled
custom-via	Specifies the custom value for the sent-by field of Via. Only the sent-by component value is mentioned here not the complete header.	STRING	<IP or FQDN name>[:<port>]	None
honor-via	Enables to honor via that is not inserted by a BIG-IP^® system for routing the response.	BOOL	Enabled/Disabled	LB MODE: Enabled ALG MODE: disabled
insert-record-route-header	Enables insertion of record-route header in requests that establish dialog. When enabled, along with URI, the custom params may be added to facilitate the routing of subsequent requests within this call to avoid route lookup. The record route URI is the local-IP & port of flows that are used for forwarding the message.	BOOL	Enabled/Disabled	Disabled
sip-firewall	Enables application of firewall policy	BOOL	Enabled/Disabled	Disabled
do-not-connect-back	Controls whether connection to a request originator is established (if it no longer exists) in order to deliver response. When disabled, responses that cannot be forward using an existing connection are dropped.	BOOL	Enabled/Disabled	Disabled
persistence
persist-key	Specifies the method to extract the key value that is used to persist on. Call-ID - To persist based on the "Call-ID" header field value in the message. Src-Addr - To persist based on originating IP address in the message Custom - To persist based on the custom key specified using iRule.	ENUM	Call-ID/Src-Addr/Custom	Call-ID
persist-type	Specifies the type of the persistence to be used for the specified "persist-key" attribute value, the currently supported type is session. Session - Uses session DB for storage, no hash is applied. The key used for session DB is value specified in the "persist-key" attribute. Insert-via-header must be enabled when persist-type is set to "Session", if not a validation error is thrown. None - Persistence is disabled Persistence is not applicable for SIP ALG modes.	ENUM	Session/None	Session
persist-timeout	Indicates the timeout value of persistence entries in seconds. It's recommended to have the persist-timeout to be greater than transaction timeout, specified in the SIP session configuration, as the lesser of the two is used when creating the persist record on receiving of the initial SIP request message. The initial SIP request can be INVITE/SUBSCRIBE/MESSAGE. Upon receiving of the response for the initial SIP Request message the persistence record is updated with the persist-timeout value. (For any subsequent responses received the persist timeout is updated for the persist record.)	UINT32	1 to 4294967295 (32-bits)	180

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

BIG-IP LTM

Operation Modes

Load Balancing

Configuration Objects

Virtual Server

SIP Router Profile

Operation Mode

SIP Route Table

Attributes Matching

Specific Route Match Example

SIP Route

Route Key

Route Value

Peer Selection

Host Selection

SIP Session Profile

Peer Object

Peer Attributes

Connection Modes

Per Peer

Per TMM

Per Blade

Transport Config

Transport Config Attributes

Source Address Translation

Source Address Translation Types

ALG without SNAT (No Address Translation)

Configuration Objects

Virtual Server

SIP Router Profile

Operation Mode

SIP Session Profile

Have a Question?

Follow Us

About F5

Education

F5 Sites

Support Tasks