http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/configwlss/architecture.html all stateful information about SIP dialogs is stored and retrieved from the SIP Data tier , which also provides replication and failover services for SIP session data.
http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/configwlss/georedundant.html When a SIP dialog boundary is reached, the call is replicated (in-memory) to the site’s SIP data tier, and becomes eligible for replication to a secondary site
Oracle SIP Servlet can fail over from No 5 to No 12 from user - would mean Early Dialog is considered boundary
Oracle SIP Servlet cannot fail over from No 1 to No 4 from user
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.
An important point here is that the IBM SIP infrastructure does not support transaction level failover. It only supports dialog failover for stable calls.
Granularity would be configurable so that users that don't want finer granularity don't pay the cost of it
For all those use cases, transaction affinity is mandatory on the LB side, meaning that all messages for the same transaction (and ACK as well for the INVITE Tx) should go to the same node, otherwise the perf hit will be too important => Supported in Mobicents Sip Servlets 1.5