Manual Chapter : Operation Modes

Applies To:

Show Versions Show Versions

BIG-IP LTM

  • 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
Manual Chapter

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
Request-URI From-URI To-URI Virtual 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 From-URI Request-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

Optimum scenario

  1. Message arrives on a Virtual Server (VS)
  2. Message is disaggregated to TMM-0
  3. TMM-0 is connected to the correct server so the message is sent
Performance impacted scenario

Performance impacted scenario

  1. Message arrives on a Virtual Server (VS)
  2. Message is disaggregated to TMM-1
  3. TMM-1 is not connected to Server 1 so message must be forwarded to the correct TMM. This will introduce latency.
  4. 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

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

  1. Message arrives on a Virtual Server (VS)
  2. Message is disaggregated to TMM-0
  3. TMM-0 is connected to the correct server so the message is sent
  4. Second message arrives
  5. Message is disaggregated to TMM-1
  6. 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.

Each blade will make a single connection to each peer.

  1. Message arrives on Blade 0
  2. Blade 0 opens a connection to Server 1 and forwards the message
  3. Second message arrives
  4. 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

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

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

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