This topic provides an overview of when replication of session and dialog state can take place during typical SIP call flows.
In WebSphere Application Server Version 6.1, SIP replication is done on a “best effort” basis. Generally, the SIP container uses the Data Replication Service (DRS) to replicate all state information. DRS provides no way to confirm when data replication has completed, so 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 means only that the data has been queued for replication.
Each category includes a number of different data types, which are described below. In terms of replication, each data object is treated independently. In other words, a change to an application session object, which causes a replication, will not result in the replication of any internal state information.
Replication of internal state information
It is important to note that transaction state is NOT replicated in the WebSphere Application Server 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
* 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 2 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
In this information ...Related concepts
Related tasks
| IBM Redbooks, demos, education, and more |