Geo-Redundant SIP Server Failover via Transaction-Boundary State Replication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing telecommunications infrastructure is inadequate for providing seamless and redundant services across multiple domains or sites, particularly in the event of catastrophic failures, as current redundancy systems do not effectively address geographic location failures and require high network bandwidth for data replication.
Innovation Solution
Implementing a geographically redundant SIP server system with a primary and secondary site configuration, where state data is replicated across sites at transaction boundaries, using a JMS queue for message exchange, and load balancers for traffic distribution, allowing seamless failover and recovery without continuous data updates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If continuous data replication is implemented between sites, then service reliability is improved, but network bandwidth consumption increases
Solution Approach 1:
The system implements periodic data replication at transaction boundaries instead of continuous replication. The primary site replicates state data to the secondary site only when a transaction boundary is reached, which are periodic events in the SIP protocol flow. This approach maintains service reliability by ensuring data is replicated at meaningful intervals while significantly reducing network bandwidth consumption compared to continuous replication.
Solution Approach 2:
The system performs preliminary actions by pre-positioning state data at the secondary site before failover is needed. Through continuous background replication of state data to the secondary site, the system ensures that when a failover event occurs, the secondary site already has the necessary data ready, enabling immediate service continuity without requiring real-time data transfer during the crisis.
2Stability of the object's composition
If state data is replicated at every transaction boundary, then data consistency is improved, but processing latency increases
Solution Approach 1:
The system applies partial action by selectively replicating only the necessary state data at transaction boundaries rather than replicating all data continuously. This approach maintains data consistency for the critical state information while avoiding the overhead of replicating unnecessary data, thereby reducing processing latency while preserving data integrity where it matters most.
3Reliability
If geographically dispersed sites are used, then catastrophic failure protection is improved, but network bandwidth requirements increase
Solution Approach 1:
The system uses periodic replication at transaction boundaries to maintain data consistency across geographically dispersed sites without requiring continuous high-bandwidth connections. This allows distant sites to be protected against catastrophic failures while minimizing the network bandwidth requirements for data synchronization.
Solution Approach 2:
By pre-replicating state data to geographically dispersed secondary sites before failures occur, the system ensures catastrophic failure protection is in place without requiring high bandwidth during actual failure events. The preliminary replication happens at a manageable pace during normal operations.
Data Source
AI summary
The SIP server deployment can be comprised of an engine tier that provides high throughput processing and a state tier that maintains SIP state data in a set of partitions and replicas. Two sites of SIP server deployments can be configured, each being remotely located with respect to the other. A primary site can process various SIP transactions and communications and upon determining a transaction boundary, replicate the state data associated with the transaction being processed, to a secondary site. Engines in the primary site can generate hints for the state replicas which can be in turn responsible for replicating the SIP session state. The replicas can choose to follow or disregard the generated hints. Upon failure of the primary site, calls can be routed from the failed primary site to the secondary site for processing. Similarly, upon recovery, the calls can be re-routed back to the primary site.