Network Deployment (Distributed operating systems), v8.0 > Applications > SIP applications > SIP in WAS > SIP high availability

SIP session affinity and failover

SIP in WebSphere provides session affinity and failover.

SIP session affinity

A single SIP container in a cluster will handle all the messages associated with a single dialog. If a container fails in the middle of a dialog, a single server in the cluster will take over responsibility for the dialog. It is the SIP proxy's responsibility to maintain session affinity based on the session identifier (which includes the logical server name). Logical server information is published by the SIP container and consumed by the SIP proxy via Workload Management System (WLM).

Route SIP messages based on the session ID

The ibmsid is embedded in various SIP messages and is used to route to specific sessions running on the SIP application server. Generally speaking, VIA headers are always used to route responses. The container will always embed an ibmsid in the VIA associated with the SIP app server. Here is an example of such a VIA header:

Via: SIP/2.0/UDP 9.51.252.69:5063;ibmsid=sipcontainer1.1153242645968.4_2_2;branch=z9hG4bK920196437955379

For proxy applications, the ibmsid (or session ID) is inserted in the initial request received from the UAC in the Record-Route. The UAS returns the same Record-Route with the session ID in the response. The UAC returns the Route header with the session ID in subsequent request within the dialog. For example:

Record-Route:
<sip:protocol2.databeam.com:5060;transport=udp;ibmsid=sipcontainer1a.1138119214953.4_2_2;lr>

In this example the UAS returns the same Record-Route with the session ID in the response, and the UAC returns the Route header with the session ID in subsequent request within the dialog.

For UAC and UAS applications, the container acting as UAC or UAS will insert the Session ID into To tag (UAS) or From tag (UAC) (i.e.

To tag local.1132518053302_2_2). The same To or From tag is included in subsequent request.

Encoded URIs will also contain an ibmappid (very similar to an ibmsid), which can then be sent in subsequent HTTP request. An important point here is that the IBM SIP infrastructure does not support transaction level failover. It only supports dialog failover for stable calls.

Here are the general rules for how the IBM SIP infrastructure decides which address to use for contact headers it embeds in outbound SIP messages:

• A stand-alone SIP application server will use its own address in contact headers that it needs to insert into SIP messages.
• A SIP application server fronted by a stateless SIP proxy will use the address of the SIP proxy in contact headers it needs to insert into SIP messages. The SIP application server discovers this address via WLM.
• A SIP application server fronted by a stateless SIP proxy which is then fronted by an IP Sprayer will use the address of the IP Sprayer in contact headers it needs to insert into SIP messages. The address of the IP sprayer must be configured at the SIP proxy through the administrative console and this address is published to the SIP application server through UCF.

Failover in the middle of a call

When a server fails, the sessions associated with the failed server are activated on the remaining containers in the replication domain. Once active, the containers handling the failed sessions publish the session location to the proxy servers fronting the cluster via WLM. When a message associated with one of the failed dialogs arrives at the proxy, the proxy pulls the session ID from the SIP message and uses to look up the new container. When the failed server is restarted, it is added back to the cluster. It will then handle only newly created dialogs.

Figure 1. SIP Container Failover within a Cluster – Before

Figure 2. SIP Container Failover within a Cluster – After

Converged applications and failover

All messages associated with a converged HTTP/SIP Session are routed by the proxy to the same backend container using encoded URIs and SIP session affinity. HTTP and SIP utilize the same replication topology (they share the same replication settings). If a failure occurs, both HTTP and SIP requests associated with a failed dialog are routed to the same new backend server. Jsession cookies take precedence over Encoded URIs within the proxy when affinity targets are being determined.

Figure 3. Converged Application Example

SIP high availability
Browse all SIP topics

+

Search Tips   |   Advanced Search