The SIP Registrar process receives the registration request and calls XDM to update the shared memory (XLA) and database.
Figure 1. SIP Registrar process
XDM updates the memory, sends a best effort synch message to the partner XDM, add an entry to the local background task queue to update the database and acknowledges back to the SIP Registrar.
If the registration synch message could be sent to the partner the background task entry is marked as 'synchronized''.
If not (most likely because the partner node is out of service, XDM triggers an MWI update by a message to FSN.
The partner XDM reads the registration synch message, updates XLA, stores the message in the background task queue (marked as synchronized) and triggers an MWI update by sending a message to FSN.
The background task on the node with the primary database sequentially stores the registration information in the database. Once stored it informs the background task on the partner node to remove this entry from its queue.
If an entry in the queue is not marked as synchronized the background task tries to send it to the partner XDM. If this is not possible
With this re-design there are no delays in the processing path and it should be possible to handle about 50 registrations per second.
Today the X3650T IBM server can do 20 new registrations/sec without x-channel delay
The partner node processes registrations in parallel. In order to handle race conditions of registration requests for the same phone received over both nodes, a timestamp is added to the registration synch message and registration updates with an older timestamp are discarded.
Startup of node without connection to partner node
Figure 2. Startup of single node
When a Telephony Control Server node starts-up without connection to the partner node XDM initializes XLA with data from the database. New registrations from the SIP registrar are processed after XLA is initialized.
Startup of node with connection to partner node
Figure 3. Startup of 2nd node
Before XDM on the starting node reads data from the database it sends a message to the background task on the partner node. The background task marks all current entries in its queue as 'not synchronized', acknowledges back to the starting XDM and starts sending all current entries to the process message queue of the starting XDM.
The starting XDM now updates XLA with registration data from the database while receiving, but not processing, registration synch messages from the partner background task.
Once the database has been read XDM declares RTP-Ready and starts processing messages from its message queue:
Synch messages from the partner background task
New registrations from the network
Synch messages from the partner XDM
Registration synchronization during upgrade and standalone
Figure 4. Synchronization during Upgrade and Standalone
When during upgrade call-processing is about to be switched to the node with the new SW load or when a node in standalone-secondary is about to be rebooted to re-join the cluster, registration data need to be synchronized that are not stored in the database of the node that will take over all call processing.
There is no change to current concept. XDM marks all registrations that need to be synchronized and copies them via SMUCOM. There is only one acknowledgement, generated by SMUCOM back to XDM after the last copied registration
There is no 'normal' registration synchronization of XLA and database since RTP and PrimeCluster consider the partner node to be out of service.
Modifications to the current implementation are necessary since not all registrations may be stored in the database, some may still be in the background task queue.
Parent topic: Endpoints and Endpoint Management