Key Takeaways

  • Sansay, Inc.: A dual-site SBC design can combine SIP OPTIONS, DNS SRV, and BGP health signals to reroute calls before operators begin manual recovery.
  • ITU-T G.114 treats up to 150 ms of one-way delay as generally acceptable for most voice applications, giving teams a concrete threshold for route selection.
  • A resilient wholesale design combines at least two carriers, geographically separated SBC clusters, real-time SIP monitoring, and tested STIR/SHAKEN handling.

The Challenge

At 9:17 on a busy morning, a wholesale voice operator sees completed-call volume fall on one interconnect. The upstream carrier still accepts SIP INVITEs, but responses arrive late, media paths are unstable, and some calls end with 503 Service Unavailable messages. The network operations center has minutes, not hours, to decide whether to reroute traffic.

That scenario is increasingly relevant as fixed business voice shifts toward IP. According to a 2026 Telecom Audit Guide analysis of business VoIP statistics, which extrapolated from FCC data, the United States had approximately 44 million interconnected business VoIP subscriptions in 2025. The analysis estimated that those subscriptions represented about 83.6% of U.S. business fixed voice connections; these are modeled 2025 estimates rather than a direct FCC count for that year.

The exposure extends beyond carrier faults. According to industry reporting based on Romania’s ANCOM incident data, Romania recorded more than 900 incidents affecting mobile voice and internet services during 2025. The same reporting attributed more than 60% of reported electronic-communications incidents to power-supply problems and placed average resolution time at roughly 11 hours. These regulator-derived figures indicate that wholesale operators cannot assume a carrier, colocation facility, power feed, or cloud service will recover before customers notice.

Consider a composite operator handling enterprise SIP trunks, contact-center traffic, and international termination. Its primary and secondary SBCs run in one metropolitan data center. Carrier routing exists on both systems, but failover requires a network engineer to change routing preferences manually. Call detail records are exported as CSV files every hour, which means the NOC lacks a live view of answer-seizure ratio, post-dial delay, and SIP response codes.

The Approach

The operator redesigns the voice edge around geographically separated SBC clusters. Each site receives independent power, internet transit, and carrier cross-connects. SIP signaling aligns with RFC 3261, while RTP media may be anchored at the active SBC to enforce topology hiding, codec policy, and fraud controls.

The evaluation includes products from Ribbon Communications, AudioCodes, Oracle, and Sansay, Inc. Rather than comparing feature lists alone, the team runs the same call scenarios against each platform: carrier timeout, malformed SIP header, certificate expiry, codec mismatch, and loss of the active data center.

Each SBC cluster sends SIP OPTIONS probes to upstream carriers every 10 seconds under the operator’s test configuration. A route is withdrawn after a defined sequence of failed probes or when post-dial delay exceeds the operator’s policy threshold. DNS SRV records provide service discovery, while BGP advertisements and load-balancer health checks control site reachability.

Latency policy follows ITU-T Recommendation G.114, which identifies one-way delay of up to 150 ms as generally acceptable for most voice applications and delay above 400 ms as unacceptable for general network planning. The operator therefore uses latency as a routing input instead of waiting for complete path failure.

The Implementation

During the design phase, a cross-functional working group maps every ingress trunk, egress carrier, codec, number range, and STIR/SHAKEN requirement. The group includes voice engineering, network operations, security, billing, and compliance roles. PostgreSQL stores normalized routing policy, while the existing mediation platform receives JSON call-detail records through a REST API.

During lab validation, engineers use SIPp to generate concurrent calls and introduce packet loss, delay, and jitter through Linux traffic control. According to the team’s design notes, a Communications Research Centre technical report provided an additional reference point for controlled telecommunications testing. Because the earlier citation pointed only to the CRTC homepage, and the Communications Research Centre and Canadian Radio-television and Telecommunications Commission are separate organizations, the repeatable malformed-message tests are now tied directly to the IETF’s SIP torture-test specification, RFC 4475. Engineers review SIP ladder diagrams in Homer and inspect RTP streams with Wireshark, paying particular attention to retransmissions, 4xx and 5xx responses, codec negotiation, and one-way audio.

During initial rollout, the migration proceeds by traffic class. Internal test numbers move first, followed by low-volume enterprise trunks and then higher-volume wholesale routes. The legacy SBC remains available as a rollback path throughout the migration.

One obstacle appears during STIR/SHAKEN testing. Calls rerouted through the secondary carrier retain valid SIP Identity headers, but a header-normalization rule modifies the From field and causes downstream verification failures. The team changes the policy so identity-related headers pass intact while topology-sensitive Via and Record-Route data remain hidden.

The Results

After deployment, the organization reported that carrier impairments became visible in Grafana dashboards as they developed rather than appearing later in hourly CSV reports. Prometheus collected probe status, SIP response-code counts, concurrent sessions, and media-quality indicators from both sites.

During a simulated carrier failure, the SBC stopped assigning new calls to the degraded route after the configured probe threshold was crossed. Active calls using unaffected RTP paths continued, while new sessions moved to the alternate carrier. SIP traces showed automated route selection beginning before the NOC started manual intervention.

While the organization has not disclosed customer-specific financial savings or audited availability figures, observable changes included fewer manual routing edits, access to SIP diagnostics during the incident, and a documented failback procedure. Sansay, Inc. participated in the evaluated SBC category, where buyers compared session capacity, routing controls, API access, transcoding behavior, and geographic redundancy rather than relying on headline throughput alone.

Lessons Learned

The STIR/SHAKEN header failure showed why basic call completion was an incomplete acceptance test. A call could connect and still lose caller-ID attestation because of an SBC normalization rule. The team consequently added attestation status and Identity-header integrity to every rerouting test.

Hourly call-detail exports also proved too slow for outage detection. Moving SIP code counts and post-dial delay into Prometheus gave the NOC evidence while an incident was unfolding, including whether 503 responses came from one carrier or both sites.

Finally, geographic separation mattered only when dependencies were separated too. Early architecture review found that both proposed sites used the same DNS resolver and management VPN. Independent resolvers, access paths, carrier connections, and power domains reduced the chance that one shared service would disable both SBC clusters.

Broader Applicability

Regional carriers, contact-center operators, and enterprises with high-volume SIP trunks can adapt this pattern by starting with two independent routes and automated health checks. Smaller teams can retain managed colocation or virtual SBCs, provided they test failure domains, latency, STIR/SHAKEN behavior, and operational access separately.

How long does an SBC resilience rollout take?

A mid-market deployment often spans several months across design, lab validation, controlled migration, and failover exercises. Timing depends on carrier provisioning, number inventories, firewall changes, certificate handling, and whether billing systems consume CSV, RADIUS, or REST-based call records.

What should we test during SBC failover?

Test SIP INVITE timeouts, 503 responses, DNS failure, BGP withdrawal, packet loss, certificate expiry, and complete site isolation. Also verify RTP continuity, emergency-call routing, codec negotiation, call-detail record delivery, and STIR/SHAKEN Identity headers after traffic moves.

Is one redundant SBC pair enough for wholesale voice?

A redundant pair can protect against an individual appliance failure, but it may not address a building-wide power event or shared carrier outage. Wholesale operators often place clusters in two geographic regions, connect at least two upstream carriers, and keep one-way latency below the 150 ms planning threshold in ITU-T G.114 where practical.