Applies To:
Show Versions![Show Versions](/etc/designs/pcx/techdocs/images/expandversions.gif)
BIG-IP LTM
- 13.0.1, 13.0.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
![](/kb/global/manual_images/MAN-0670-00_v1/GUID-47A370C9-43B4-4E8F-BA6E-D4C2C40E0EB7-online.png)
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> }
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
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.
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:
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:
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.
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.
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.
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.
|
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.
|
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
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](/kb/global/manual_images/MAN-0670-00_v1/GUID-2253C417-B611-4EA8-8152-AA1CE8D63E07-online.png)
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](/kb/global/manual_images/MAN-0670-00_v1/GUID-5D42A903-853C-4545-8BCF-4567C99DAC9F-online.png)
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](/kb/global/manual_images/MAN-0670-00_v1/GUID-73FBCCFA-C5CA-4170-952C-C64B7B0D695B-online.png)
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.](/kb/global/manual_images/MAN-0670-00_v1/GUID-B6524C4A-EAB0-4FA4-AC7F-0D87A17BC5DE-online.png)
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
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
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
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
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 }
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
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.
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.
|
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.
|
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 |