Keeping Voice Running When Something Fails with SBC Redundancy
In a production voice network, the question is not whether something will fail but what happens when it does. A trunk provider degrades, an operator goes offline, a softswitch stops responding, or an SBC itself crashes. Without a plan, any one of those takes calls down with it.
A single SBC with a single set of trunks is a single point of failure for every call on the network. The same is true of a single softswitch or a single carrier. Any architecture that depends on one of anything is an architecture waiting for an outage.
How SBC Redundancy Works
SBC redundancy builds backup paths into the network so traffic keeps flowing when a component fails. A common setup has an operator deploying two active ProSBC servers, both running live full-time, so there is always more than one path available. Through routing rules set in the softswitch, the SBC, and the SIP trunking provider, backup routes are established for all traffic. Every path has an alternate.
Redundancy in this sense is broader than a single high-availability pair. HA is one important mechanism within it, keeping the SBC itself up with active/standby failover. This page is about the wider goal of building backup paths across the whole voice network so no single failure, of any component, stops service.
SBC redundancy: two active ProSBC servers provide primary and backup paths between the softswitch and its providers, so a failed component reroutes automatically. Click to enlarge.
What the SBC Contributes to Redundancy
Backup Routing Across Providers
The SBC holds the routing rules that define primary and backup paths, so it can move traffic between trunk providers when one fails or degrades. Managing multiple operators is itself an SBC strength, described in enterprise SIP trunking, and redundancy builds on that by making alternate providers into failover targets.
Quality-Based Rerouting
Beyond hard failures, the SBC can act on degradation, using call-quality signals such as MOS to move traffic off a provider that is getting worse before it fails outright. This keeps quality up rather than only reacting after a path has died.
High Availability of the SBC Itself
Because the SBC is critical, it can be made redundant too. ProSBC offers a 1+1 high-availability option with active/standby redundancy for maximum uptime and minimal downtime if a node fails, so the SBC is not itself the single point of failure the rest of the design guards against.
ProSBC for Redundant Deployments
ProSBC is a carrier-grade, software-based session border controller built on more than 20 years of SIP deployment experience. For the redundancy use case, it delivers:
Deploy It Your Way
Self-Managed
Run the redundant ProSBC pair as software on your own infrastructure. Full control over routing rules, failover behavior, and quality thresholds.
Managed Service
Hand deployment and operation to TelcoBridges through the ProSBC managed service. The redundant configuration is set up and monitored so failovers are caught and reviewed rather than discovered by customers.
Fully Hosted
TelcoBridges hosts and manages the redundant SBC deployment entirely. The operator connects its softswitch and providers to a managed, fault-tolerant voice edge.
Frequently Asked Questions
What is SBC redundancy?
It is deploying SBCs and routing rules so the failure of any single component, a trunk provider, an operator, a softswitch, or an SBC, reroutes traffic automatically instead of dropping calls. A common setup uses two active SBC servers running full-time with backup routes for all traffic.
How is redundancy different from high availability?
High availability usually refers to an active/standby SBC pair aimed at keeping the SBC itself up. Redundancy is the broader goal of building backup paths across the whole network, so trunk providers, operators, softswitches, and SBCs all have alternates. HA is one mechanism within a redundant design.
How does the SBC decide to reroute?
Routing rules define primary and backup paths. The SBC reroutes on hard failures, such as a provider going offline, a softswitch failing, or an SBC crashing, and it can also reroute on degradation, using call-quality signals like MOS to move traffic off a provider before it fails completely.
Can the SBC itself be made redundant?
Yes. ProSBC offers a 1+1 high-availability option with active/standby redundancy for maximum uptime and minimal downtime if a node fails, so the SBC does not become the single point of failure the rest of the redundant design is meant to avoid.
Build a Redundant Voice Network with ProSBC
Talk to a solutions architect about deploying a redundant ProSBC configuration, or start evaluating on your own.
Prefer to evaluate on your own first? Start your 30-day free trial.