Replicating SIP sessions

This page provides an overview of when replication of session and dialog state can take place during typical Session Initiation Protocol (SIP) processing. It also describes the steps that we have to complete to set up a replication domain for SIP sessions.

The SIP container typically uses the Data Replication Service (DRS) to replicate all state information. Because DRS does not provide a way to confirm when data replication has completed, the only thing that can be quantified is when a piece of state information is queued for replication. Within this topic, references to replication of data only means that the data has been queued for replication. The SIP container replicates several different types of information. This data falls into two general categories:

• Internal SIP container state information associated with the dialog.

• Application state information associated with the various session objects.

Each of these categories includes a number of different data types, that are described below. Each data object is treated independently. Therefore, a change to an application session object, that causes a replication, does not result in the replication of any internal state information.

Replication of internal state information Internal state information can be defined as anything related to the state of a dialog being handled by the container. It includes things like cseq, dialog state (initial, early, confirmed, terminated), session expiration, local, remote party, etc. Internal state information is only replicated due to the existence of a dialog. Therefore, no internal SIP-related data will be replicated until the dialog with which it is associated is established. The types of SIP requests that can cause the creation of a dialog include:

• INVITE

• SUBSCRIBE

• REFER

Replication of internal state happens at well-defined, predictable points in the call flow. For example, a dialog is only established at the container when a 2xx response or a 1xx response with a “To” tag is received or sent due to one of the method types listed above. Events that can trigger an internal state replication include:

• Creation of a new SIP dialog

• Expiration of a session due to a session timeout

• The sending of a final response to a UAC

• Creation of an encoded URI

• Handling of any message that results in a change of the internal dialog state

It is important to note that transaction state is NOT replicated in the WAS 6.1 version of the SIP container, only dialog state. Not replicating transaction state reduces the load on all the servers in the replication domain, but can cause problems in failures that happen in the middle of a transaction (for example, loss of some dialog-related SIP messages).

An important difference between a B2BUA and a proxy application is the number of session objects created and replicated. In both cases only a single application session is created, but for the B2BUA, two session objects are created–one for the inbound leg and one for the outbound leg. For a proxy application, only a single session object is created.

Replication of application state information Application state information is treated differently from internal dialog state information because it does not rely on the existence of a dialog to be replicated. Application state refers to any data that is being maintained by the application through the use of JSR 116 data constructs. This includes:

• javax.servlet.sip.SipApplicationSession

• javax.servlet.sip.SipSession

• javax.servlet.sip.ServletTimer

• Any attribute set on the SipSession or the SipApplicationSession

Replication of internal state happens at well-defined, predictable points in the call flow, while replication of application state is less predictable because it is generally dependent on when an application creates, invalidates or modifies the session data and timers through JSR 116 APIs. This could be due to the processing of an inbound message, or to the expiration of a SIP timer. All of the following can cause the replication of application-related session data:

• Creation of an application session object

• Creation of a SIP session object

• Creation of a SIP session timer

• Modification of a session object through setAttribute or removeAttribute

• Invalidation of a SIP session object

• Expiration of a session timer

• Application code sending out a request *

  *Causes replication of the SipSession and SipApplicationSession in order to synchronize the "last access timestamp" with the peer container(s) in the cluster. This is for integrity of future calls to SipSession.getLastAccessedTime() and SipApplicationSession.getLastAccessedTime()

Replication can occur for requests that do not establish a dialog if an application calls request.getApplicationSession(true) and if addTimer() and/or addAttribute() are called on the resulting application session object. This is needed so that a listener can be called when the timer expires.

SIP failover and replication setup considerations

A SIP cluster that requires replication and failover can consist of many replication domains, each of which contain a set of SIP containers. There is no limit set on the number of containers in a cluster. For performance reasons, each replication domain should contain two containers only.

The replication domain should be set to the Entire Domain, which means state is replicated to all containers in the replication domain. The replication mode should be Both client and server.

The distributed session for a container needs to be set to Memory-to-memory replication. Any applications that require session replication must include the <distributable /> tag in the web.xml and sip.xml files. Both SIP and HTTP will utilize the same replication topology

SIP session replication topology

• Each member replicates all state data to every peer in its replication domain.

• Each replication domain should ideally contain two servers.

• When a failure occurs, the core group coordinator tells the remaining core group members which replicated sessions to activate. These replicated sessions then become part of their active sessions.

Complete the following steps to set up a replication domain for SIP sessions.

 

1. In the admin console, click Environment > Replication domains > New

2. Click Number of replicas , and then select Entire domain .

3. In the Container settings section, click Session management.

4. In the Additional Properties section, click Distributed environment settings, and then click Memory-to-memory replication .

5. Set Replication mode toBoth client and server .

6. Save the changes.

 

Results

Memory-to-memory replication is enabled for SIP sessions.

SIP session affinity and failover
SIP high availability

 

Related tasks

Browse all SIP topics