The OpenCloud SIP RA supports replicated dialog activities. This allows dialog activities to be accessed on any node in the cluster, so that SBBs can attach to dialog activity contexts and use the dialogs on any node
Dialog activity state
When a dialog activity is created, the dialog activity state is initially local to the calling node. When the dialog transitions to the "confirmed" state (that is, a 2xx response is sent or received on the initial transaction), the SIP RA replicates the dialog state to all nodes, using Rhino’s built-in memory database. From this point on, the dialog activity state is available to all nodes.
If a node fails, any dialogs that it created can continue on other nodes. If another node receives a request for a dialog it has not seen before, it will check the replicated state and continue processing the request as an in-dialog request. Any SBB entities that were attached to the dialog activity context will be able to receive the request. This assumes that the SIP client is able to detect the node failure and send future requests to a different node. This can be achieved using a load balancer or DNS SRV records, for example.
Performance
The performance of FT dialogs will be slower due to the replication and transaction cost. Updates to replicated dialog activity state are performed transactionally, and require a distributed lock to be acquired by the node updating dialog state. For this reason the latency will be larger than when using non-replicated dialogs.
Example
The example B2BUA service supports the use of replicated dialogs. To
deploy a fully replicated B2BUA, ensure that the RA is deployed with the
ReplicatedDialogSupport=true property (see Configuration),
and also set the B2BUA_REPLICATED property in
sip.properties to True. The latter ensures that Rhino deploys the
B2BUA service as a replicated service, so that SBB CMP state is
replicated as well.
