Thirty-three documented Microsoft Teams outages since January 2025. A 19-hour cascading failure in July that took down Exchange Online alongside Teams. A major RingCentral disruption in which the CEO had to issue a public apology. These are not edge cases; they are the operating reality of depending on a single UCaaS vendor for your entire voice estate. The question enterprises should be asking is not whether their UCaaS provider will go down again, but what happens to the phones when it does.
SIP trunking resilience has become the architectural answer to that question, and the market data reflects it. Data Bridge Market Research values the global SIP trunking market at $13.85 billion in 2024, growing at a CAGR of 11.48% toward $33.05 billion by 2032. Europe is the second-largest regional market at $4.2 billion, expanding at 12.4% annually. That growth is not nostalgia for on-premise gear; it is enterprises building a voice layer they actually control.
A NetScout survey found that 97% of enterprises experienced major UCaaS-related outages in 2023, with 64% estimating losses of at least $10,000 in sales and productivity per incident. For organisations with revenue above $10 billion, nearly half estimated losses between $100,000 and $1 million or more. At those numbers, the cost of a properly engineered SIP fallback pays for itself in the first prevented outage.
Why UCaaS-only stacks have a structural resilience problem
UCaaS platforms are built for simplicity: one vendor, one app, one bill. That consolidation is genuinely useful for most day-to-day collaboration. But voice is different from presence or file sharing. A dropped Teams message is inconvenient; a dropped call from a customer, a trading desk, or an emergency contact is a business event with a cost attached to every minute.
The July 2025 Microsoft outage illustrates the structural risk. A routing configuration change inside Microsoft’s infrastructure triggered a cascading failure: Exchange Online went first at 22:20 UTC on July 9th, Teams followed by early morning on July 10th, and the disruption ran for over 19 hours. Microsoft itself, during a separate Azure incident, told customers to review their business continuity and disaster recovery plans. That is a vendor acknowledging, in writing, that you should not treat their platform as a single point of failure.
When your UCaaS vendor tells you to review your continuity plan, they are telling you that SIP trunking is not a legacy fallback. It is the continuity plan.
The Avaya Cloud Office outage of January 22, 2025, made the same point from a different direction. A provider advertising 99.999% uptime went dark in the early afternoon and stayed down for hours. RingCentral’s CEO confirmed it was an internal system error, not an external attack. No architecture is immune; the question is whether failure at one layer takes down everything else.
What SIP trunk failover actually looks like in practice
SIP trunk failover is the automatic rerouting of voice traffic to a backup path when a primary trunk or provider becomes unreachable. Paired with SIP trunk redundancy, meaning multiple independent paths maintained in parallel, it forms the foundation of high-availability telephony. The critical point is that redundancy must exist at every layer: provider, network, and PBX. A single point of failure at any one of those layers defeats the others.
The components of a properly engineered stack are straightforward. A session border controller (SBC) sits at the edge, handles signalling and media, and can be configured to fail over between trunks in sub-second timeframes. Users on a well-configured system rarely notice the handoff. DNS-level routing and IP failover add a second layer. PSTN fallback adds a third. Multi-provider redundancy means that if one carrier’s infrastructure has a problem, traffic shifts to another before the call drops.
BGP multihoming is where network-layer resilience becomes concrete. Border Gateway Protocol allows upstream networks to reroute traffic dynamically when a path becomes unreachable, without manual intervention and without waiting for a support ticket. For voice, where a 30-second delay is already a failed call, the difference between BGP-aware failover and manual rerouting is the difference between a transparent event and a visible outage.
On-premise SIP vs UCaaS: not a binary choice
The framing of on-premise SIP versus UCaaS misses the architecture that most resilient enterprises actually run. UCaaS handles the collaboration layer: presence, messaging, video, meeting rooms. SIP trunking handles the PSTN connection and provides the failover path when the UCaaS layer has a problem. They are complementary, not competing.
What SIP trunking gives you that UCaaS alone cannot is independence from a single vendor’s uptime. Your UCaaS platform can be completely unreachable, and inbound calls can still land on a backup SBC, route to a hunt group, or forward to mobile. Your outbound calls can still complete. The voice backbone continues operating because it does not share a failure domain with the collaboration platform sitting above it.
Business telephony continuity, in this architecture, means the PSTN layer survives independently of whatever is happening at the application layer. That separation is the design goal, and SIP trunking with carrier-grade infrastructure is how you achieve it.
Why the network layer matters as much as the trunking provider
SIP trunking resilience is only as good as the network carrying the signalling and media. Latency, jitter, and packet loss directly degrade call quality; path diversity determines whether a network failure takes down your trunks alongside everything else. This is where carrier-neutral infrastructure with genuine PoP reach changes the calculation.
We operate 44 points of presence across Europe and the Middle East, with direct peering to AWS, Azure, GCP, Oracle, and Cloudflare at every site. For SIP trunking customers, that peering matters operationally: when a UCaaS provider like Microsoft or Zoom is reachable via a direct interconnect rather than the public internet, the failure domain for signalling is narrower and the path is more predictable. BGP multihoming across those interconnects means that a routing problem at one upstream does not propagate to the voice layer. The trunk stays up because the path to the PSTN does not depend on the same infrastructure that just failed.
Cost savings between 25% and 65% over legacy PRI lines remain the most common economic argument for SIP trunking, and they are real, especially for multi-site organisations with high call volumes. But the resilience argument has become at least as strong, and for regulated industries where telephony is part of the operational continuity obligation, it is often the deciding one.
What to ask before your next outage
If your current architecture routes all voice through a single UCaaS platform, the questions worth answering now are: what happens to inbound calls when that platform is unreachable; how long does manual failover take; and who owns the PSTN relationship if the UCaaS vendor is the problem. If the answers are uncomfortable, the architecture needs a SIP layer underneath it. Not instead of UCaaS, but independent of it, so that the next 19-hour outage is a collaboration inconvenience rather than a telephony failure.
