+

Search Tips   |   Advanced Search

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

Routing 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 appserver. 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:

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






Related concepts


SIP high availability

 

Related tasks


Browse all SIP topics