Redundancy and High Availability in Voice Platforms
Understand redundancy and high availability strategies for voice platforms and how SipPulse SoftSwitch and SBC implement carrier-grade architectures with transparent failover.
Why high availability is non-negotiable for voice
In telecommunications, voice requires a higher level of availability than data services. When a web server goes down for 30 seconds, few users notice. When a voice platform fails for 30 seconds, all active calls drop and users notice immediately. For STFC operators, ISPs with voice, and contact centers, voice service interruption has a direct impact on revenue and customer satisfaction.
The typical target is 99.999% availability (five nines), which equals less than 5 minutes and 15 seconds of downtime per year. Achieving this level requires a platform designed for redundancy from the ground up.
How SipPulse SoftSwitch implements high availability
SipPulse SoftSwitch was designed for carrier-grade operations, with native support for clustering and failover. Built on OpenSIPS, the SoftSwitch supports up to 1000 CAPS (calls per second) and offers two redundancy architectures:
Active-Passive
The primary node processes all traffic. The secondary node remains on standby, monitoring the primary's health via keepalived (VRRP). On failure, the secondary takes over the virtual IP in under 3 seconds and starts processing calls. Active calls at the time of failure are lost, but new calls are processed normally.
This configuration is suitable for smaller operations where the cost of maintaining two active nodes is not justified.
Active-Active
Both SipPulse SoftSwitch nodes process traffic simultaneously, sharing the load. SIP load balancing distributes calls between nodes. If one node fails, the other absorbs the entire load automatically.
SipPulse SoftSwitch uses the OpenSIPS usrloc module with a database backend to replicate SIP registration state in real time between nodes. This means endpoints registered on a failed node can be served by the other node without re-registration.
SipPulse SBC redundancy
The SipPulse SBC, supporting up to 4000 concurrent calls, also operates in redundant configurations. Available in UNI (access), NNI (interconnection), and NNI-CC (contact center) variants, the SBC can be deployed in active-passive pairs with VRRP failover.
At the network edge, the SBC is often the first point of contact for SIP traffic. A redundant SBC ensures that interconnection with other operators and corporate customer access are not affected by hardware or software failures.
Database replication
CDRs, customer configurations, and routing data from SipPulse SoftSwitch must be synchronized between nodes. Supported approaches include:
- Synchronous replication (PostgreSQL with synchronous replication): ensures both nodes have the same data, with zero RPO.
- Asynchronous replication: lower performance impact, suitable when latency between sites is significant.
SipPulse BSS (billing system) also benefits from replication, ensuring billing data and CDRs remain available even during a failure.
Geographic redundancy
For protection against disasters affecting an entire datacenter, SipPulse SoftSwitch can be deployed in distinct geographic locations. The configuration uses DNS SRV with low TTL to redirect traffic on site failure.
SIP natively supports DNS SRV records. A typical failover record includes:
- Priority 10 pointing to the primary server
- Priority 20 pointing to the secondary server
When the primary fails, compliant SIP endpoints automatically try the secondary.
Media server redundancy
Media servers (responsible for transcoding, recording, and conferencing) also require redundancy. SipPulse SoftSwitch distributes media sessions among multiple media server instances. If an instance fails, new calls are directed to the remaining instances.
For contact centers using SipPulse NIVA (AI-powered virtual assistant) or call recording for SipPulse AI (transcription and analysis), media server redundancy ensures these features remain available even during partial failures.
RTO and RPO targets on the SipPulse platform
- RTO (Recovery Time Objective): with keepalived/VRRP, SipPulse SoftSwitch and SBC failover occurs in 2-5 seconds, well below the 30-second limit considered acceptable for voice.
- RPO (Recovery Point Objective): with synchronous replication, RPO is zero. CDRs and configuration data are not lost.
Conclusion
High availability in voice platforms is not optional for professional operations. SipPulse SoftSwitch and SipPulse SBC were designed from the architecture level to operate in redundant configurations, with transparent failover and state replication. For STFC operators, ISPs, and contact centers that cannot tolerate interruptions, the SipPulse platform delivers the carrier-grade availability the operation demands.
References
Related Articles
How to Choose an SBC for Your Voice Operation
Understand the role of a Session Border Controller in your voice network and learn how to choose the right SBC based on capacity, protocol support and deployment model.
End of long distance: understanding the unification of local areas
Anatel reduces local areas from 4,118 to 67. See the impact on STFC and the timeline.
Voice Channel Sizing: Erlang, CPS and Capacity Planning
Learn how to use the Erlang B formula, calculate CPS, and correctly size voice channels, media servers, and bandwidth for your VoIP operation.