Manual Chapter : Deployment Use Cases

Applies To:

Show Versions

BIG-IP LTM

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

Deployment Use Cases

Basic Load Balancing (LB)

The "load-balancing" mode is used for scaling of capacity and/or providing high availability for SIP signaling servers/proxies/gateways. It allows steering of SIP signaling traffic to a pool of servers based on static SIP routes to spread the load over members of the pool. It provides Call-ID based load balancing persistence. It is the default mode of operation and does not automatically handle media flows. BIG-IP Via header is inserted by default for request messages and removed from response messages. Lasthop information added to the Via header information is used for response routing and route lookup is skipped for response messages.

In the load balancing operation mode, related media flows are not handled. The media flows associated with the SIP signaling message are assumed to be routed via other devices or virtual servers.

The configurations in sip session profile: Insert-via, Custom-via, Honor-via and Do-not-connect-back are inter-related.

Basic LB Example

In this example, you can see that a BIG-IP® system is adding and removing the top most Via such that the message will return to the BIG-IP before being forwarded out to the caller.

Configuration

In a route, at least wildcard entries for UDP and TCP default routes must be specified.

Route entry - ["", "", "", peer-udp] (Wildcard entry, default route for UDP)
Route entry - ["", "", "", peer-tcp] (Wildcard entry, default route for TCP)

Load Balancing Configuration

ltm pool udp-default-pool {
     members {
         10.10.0.10:5060 {
            address 10.10.0.10
         }
         10.10.0.11:5060
            address 10.10.0.11
         }
     }
}
 
ltm message-routing sip peer peer-udp {
    pool udp-default-pool
}
 
ltm message-routing sip route default-route-udp { 
    peers {  peer-udp  }
}
 
ltm message-routing sip profile router siprouter-lb {
    routes {
       default-route-udp      
    }
}
 ltm virtual sip-lb-udp {  
     destination 10.20.0.60:5060
     mask 255.255.255.255
     ip-protocol udp
     profiles {    
         udp     
         sipsession      
         siprouter-lb     
     }
}

Load Balancing with Persistence

Persistence is configured through attributes in the "session" profile. Attaching a persistence profile to Virtual server is an invalid configuration and results in a configuration error.

There are two persistence types (persist-types) available; session (default) and none. If persist-type is set to "none", persistence is disabled. When persist-type is set to session, the persist-key specifies if BIG-IP persists on Call-ID (the default value), Src-Addr (source address), or custom. Persistence records are kept in SessionDB and therefore synchronized between TMMs and blades. Custom persist-key is specifically for iRules to create customer specific persistence keys. An iRule script may modify the message's persist-key during the SIP_REQUEST, SIP_RESPONSE or MR_INGRESS events. The value of the message's persist key after MR_INGRESS event is used for persistence lookup, if the "persist-key" is set to "Custom".

Session Persistence

Session persistence avoids a route lookup based on state recorded on the BIG-IP.

It guarantees those messages carrying the same persistence key are going to be delivered to the same (L4) peer.

Persistence entries are keyed by a value extracted from a message initiating a new session.

The value used for the persist entry key, depends on the “persist-key” configuration attribute.

When an existing persistence record is matched, the current message is delivered to the same (L4) destination avoiding a route lookup and LB pick.

It is recommended to have the persist-timeout set to be greater than the 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.)

Basic LB with Session Persistence Example

This diagram shows a call from Call-ID 1-2883 @10.20.0.2 being load balanced to Server 10.10.10.2 and a call from 1-3000@10.20.0.6 being load balanced to 10.10.10.7 and the persist records created from these calls when persistence is enabled with a key of Call-ID.

Basic load balancing with session persistence example

Configuration

In a route, at least wildcard entries for UDP and TCP default routes must be specified.

Route entry - ["", "", "", peer-udp] (Wildcard entry, default route for UDP)
Route entry - ["", "", "", peer-tcp] (Wildcard entry, default route for TCP)

Load Balancing Configuration

ltm pool udp-default-pool {
     members {
         10.10.0.10:5060 {
            address 10.10.0.10
         }
         10.10.0.11:5060
            address 10.10.0.11
         }
     }
}
 
ltm message-routing sip peer peer-udp {
    pool udp-default-pool
}
 
ltm message-routing sip route default-route-udp { 
    peers {  peer-udp  }
}
 
ltm message-routing sip profile router siprouter-lb {
    routes {
       default-route-udp      
    }
}
 ltm virtual sip-lb-udp {  
     destination 10.20.0.60:5060
     mask 255.255.255.255
     ip-protocol udp
     profiles {    
         udp     
         sipsession      
         siprouter-lb     
     }
}

SIP ALG without Address Translation

In Application Level Gateway (ALG) operation mode, the system will create media flows based on SDP offer/answer SIP message. The callee may begin sending media when they receive an INVITE/SDP message and before responding with SIP provisional or final response. A deny listener will be created to discard early media packets received before provisional SIP response with SDP. Media flows will be created on provisional or final SIP response with SDP and the corresponding deny listeners will be deleted. A call table is used to track calls and their associated media flows.

Other SIP request/response messages, like REGISTER, OPTIONS, SUBSCRIBE, NOTIFY, etc are simply passed through the system.

In ALG mode, "per-client" mode is the only natively supported connection-mode for the peer. All other modes must be handled via iRules. By default, there are no routes attached to the siprouter profile and persistence is disabled. BIG-IP does not insert Via header by default for request messages. The response messages are sent based on the associated "per-client" connection.

The ALG operation mode has two operating contexts, firewall (FW) and source address translation (SNAT). The operation-mode attribute of a SIPRouter profile is used to set a SIP routing instance into ALG mode. The operating context is automatically detected by the source address translation mode of the outgoing connection.

FW ALG mode

No address translation

No subscriber registration tracking

No separate IP Address support for RTCP flows. Both RTP and RTCP use the same connection IP Address.

Both TCP and UDP control connections wont terminate when 200OK for BYE or ERROR for INVITE is handled. This option is configurable.

Calls wont be dropped in case of media flow collision. BIG-IP will attempt to create media channel (RTP/RTCP).

There could be overlapped calls if the multiple caller/callee has same set of media connection attributes. Thus resulting in partial media for a call, for example only audio or video when one of the connection attribute overlaps with another call.

Media channels once created will updated solely by the media activity, re-invites won't update the idle timeouts of the existing channels. If the re-invites recreate the new media channels, its idle timeout will be set to its default value as configured.

For 183 Early Media: The media channels gets established upon receiving 183 for Invite; 200OK following 183 response will not affect the existing call. This statement relies on the assumption that both 183 and 200OK have same set of SDP parameters.

FW ALG Mode Requirements

Must allow external access to any address for TCP/UDP port 5060

There should be a virtual server to receive SIP messages on all vlans that expect SIP requests or responses

Request Routing

The request messages are forwarded to the destination IP and port. No message headers are modified. For each client, a new connection is established to the destination IP and port.

Response Routing

For response messages, the MR maintains the association of the per-client connection and the response messages are sent on the associated client-side connection. No headers are modified on the response.

ALG without Source-address-translation Example

In this example, the default router profile "siprouter-alg" for ALG has no routes attached to it and the operation-mode is "application-level-gateway".

SIP ALG without Address Translation

Other SIP request/response messages, like REGISTER, OPTIONS, SUBSCRIBE, NOTIFY, etc are simply passed through the system.

Subscriptions

Product Usage

Trials

Registration Keys

Downloads

Applies To:

BIG-IP LTM

Deployment Use Cases