Enterprise voice does not fail in one way. A primary PBX loses its registration. A SIP edge sits one ocean too far from the callers. A call-flow endpoint times out under load. A queue has nobody in it. Each of those is a different failure domain with a different blast radius, and "we have a second data center" answers none of them on its own. Multi-region SIP design is the discipline of deciding, for every layer of the call path, exactly what happens when that layer stops answering — and of placing the media path close enough to the caller that the geography itself is not a failure mode. This guide maps the four failover layers an enterprise voice deployment actually has, shows the control Devotel Orbit ships for each one, and closes with the checklist we see mature buyers run before they publish a new region.
The four failure domains
Every SIP deployment, however many data centers it spans, fails in one of four distinct ways:
| Failure domain | What dies | Correct response |
|---|---|---|
| Trunk health | The primary PBX or SBC goes offline (registration dropped, box rebooted) | Trunk failover chain |
| Route disposition | The route's primary disposition can't terminate — agent runtime down, queue empty, every device offline | Route-level fallback |
| Webhook dependence | The tenant-hosted call-flow URL times out or returns a non-2xx | Secondary fallback URL |
| Media geography | The SIP edge is far from the caller | Edge proximity and transport, not redundancy |
A "multi-region posture" that only addresses one of these is a partial answer. The rest of this guide walks each domain in order and the control that answers it on Orbit.
Layer one: trunk failover chains
A BYO-PBX trunk in Orbit can name a failover trunk directly on the trunk record: when the primary trunk is unregistered at dispatch time, delivery walks to the configured secondary instead of falling straight through to the platform default. Two things make this safe to configure at 3 a.m.:
- Cycle validation at write time. The trunk API rejects a self-referential or cyclic chain when the trunk is saved, so a loop of the form "primary points to secondary, secondary points to primary" never reaches a live call.
- A bounded walk at dispatch time. Even if a cycle slips into the data — a row that pre-dates the write guard, or a direct database edit — the dispatch walk is hop-capped (five, which is generous for any realistic chain) and only forces the caller into the safe platform default rather than hanging the call on an infinite loop.
There are two honest caveats to how this is evaluated. First, the chain is only consulted when the primary trunk is unregistered — a call with a healthy primary never pays the chain-scan cost. Second, each candidate hop must itself be registered before it is used; the walk checks registration status and skips a candidate that is also down. A failover that says "ring my secondary SBC" when the secondary is also dead is not a failover at all, and Orbit's walk accounts for that. The BYO trunk guide covers the single-trunk case; what matters architecturally is that this chain is a per-trunk property, walkable without human intervention when the primary drops.
Layer two: route fallback
The trunk layer answers "deliver to another box." The route layer answers "do something else with the call," and that distinction is the difference between a failover that rings a different device and a failover that keeps the caller from dead air. Every per-number inbound route on Orbit carries a primary disposition — ring a softphone user, enqueue to a call queue, forward to an external SIP server, answer with an AI voice agent, drop to voicemail — and an optional fallback disposition consulted when the primary cannot terminate.
The fallback fires under the specific conditions that make the primary useless: an agent runtime unreachable, a queue with nobody logged in past its wait limit, or every registered device in a ring-group offline. The default most tenants ship is voicemail, so a bad configuration degrades to a message capture instead of a dropped call. Without that, the trunk failover chain above gets you to a functioning box that answers nothing.
Layer three: webhook fallback URLs
Enterprises that run their own call-logic endpoint — pointing an inbound number at their own server, which returns the call instructions to execute — inherit one more failure domain Orbit covers explicitly. On a webhook route, a secondary fallback URL is stored on the same record as the primary; when the primary fetch fails — network error, non-2xx, malformed body — the platform re-issues the same signed call request to the backup endpoint once before deferring to the static fallback (play "line not available," drop to voicemail, or a clean decline, per the route config). The failover URL is therefore not just a retry; it is the operator's disaster-recovery endpoint, and on a critical number that is the difference between a failed call and a failed fetch.
Layer four: media-edge proximity
Redundancy does not fix geography, and geography is still the most consistent multi-region problem. Every one-way-kilometer the media path travels adds a hard floor to latency that no software gets back; move the SIP edge a continent away from the caller and the extra hop cost lands on every packet in both directions for the whole call. Orbit's published per-stage voice-agent latency budget calls this out explicitly as a region-dependent term, which is exactly the honest reading — for voice, the region question is a physics question before it is an engineering question. The practical guidance that survives:
- Keep the SIP edge close to the callers, not to a central headquarters — the media path is the constraint, and every intermediate SBC hop or chained registrar adds to it rather than subtracting from it.
- Prefer TLS transport end to end; the security benefit is a floor, but so is the predictability — a SIP edge far from the callers over UDP is also brittle to packet reordering under load.
- Minimize chained registration hops. Each intermediate registrar re-INVITES through adds a hop you will pay per call, and the fix is topology, not tuning: point the PBX at the nearest healthy edge, let one registrar own the binding, and place the redundant SBC where it rings alongside rather than behind.
These are not recommendations to "just add a second region." They are the things no second region can substitute for, and they apply identically whether the tenant runs one region or five.
The regional checklist
A mature multi-region voice rollout answers each of these before it publishes a new region or a new set of numbers:
- Trunk failover chain configured and cycle-safe. Each trunk's
failoverTrunkIdnames a usable secondary (at write time, validated; at dispatch time, bounded). - Route fallback disposition set. Every important number carries a fallback that seizes something other than dead air — usually voicemail — when the primary route cannot terminate.
- Webhook fallback URL stored, where applicable. A number pointed at a tenant-hosted endpoint names its disaster-recovery endpoint, so a failed primary fetch fails over without dropping the call.
- Edge proximity validated. The new region's media path terminates near the expected call volume, on TLS transport, with minimal intermediate SBC hops.
- Registration health visible. Each trunk's recent-auth failures, registration-expiry floor, and per-attempt auth log are on the voice dashboard, so a "my secondary never answered" failure is diagnosed against the actual failing claim rather than a guess.
- The platform default exists. When no candidate in the chain is usable, dispatch degrades to the Devotel platform default rather than dropping the call; the chain extends failover, it never replaces the safe last-resort.
If your architecture answers all six, the regions in the design are genuinely redundant rather than merely plural. If one of them is missing, that is the layer a 3 a.m. incident will reach.
Frequently asked questions
How does Orbit's trunk failover chain decide which secondary trunk to try?
When the primary trunk is unregistered at dispatch time, the platform walks the trunk's configured failoverTrunkId to the first candidate that is enabled, has a resolvable dial address, and is itself registered. The write-time guard rejects any self-referential or cyclic chain when the trunk is saved, and the dispatch walk is hop-capped as defense-in-depth — if no usable candidate exists, dispatch falls back to the Devotel platform default.
What happens when a failover candidate is itself unregistered?
The chain skips it. Each hop must independently meet the enabled/registered/has-an-address bar before the platform dials it, so a secondary that is also down does not get rung as "the failover" and waste the call. The walk keeps trying further candidates in the chain until one qualifies or the hop cap is hit, at which point the platform default is the backstop.
Does the per-number route fallback overlap with trunk failover?
They answer different questions. Trunk failover is "deliver the call to another box when the primary is down." Route fallback is "the call arrived, now the primary disposition can't terminate — do something else instead." A deployment that runs both keeps the call alive at two independent layers: the box layer and the disposition layer.
What is the single most commonly missing failover in an enterprise SIP design?
The per-number route fallback. Teams tend to configure a secondary trunk and stop there, leaving the caller on a working box whose primary queue or ring-all has nobody answering. A voicemail (or an equivalent disposition) fallback on every published number catches that with a message instead of a drop.
Does failover to the Devotel platform default ever lose the failover trunks' billing?
Yes — explicitly. When the chain yields no usable candidate, dispatch falls back to the platform's default voice termination path, over Devotel's own wholesale softswitch, which is also where outbound termination generally runs for Orbit-carrier deployments. The BYO failover chain exists to honor the tenant's own secondary equipment first, not to decouple the tenant from a billable last resort.
The takeaway
Multi-region SIP design is not a data-center count; it is four distinct answers to four distinct failure domains — a per-trunk failover chain in front of the PBX, a per-number route fallback in front of the route, a webhook backup URL in front of a tenant endpoint, and media-path proximity where the caller actually is. Orbit ships a control at each of those layers: the cycle-safe, hop-capped trunk failover chain, the route-level fallback disposition, the fallback webhook URL, and the published per-stage latency budget that names media geography as the region-dependent cost it honestly is. The BYO trunk guide is the single-trunk counterpart; this guide is what changes when there is more than one trunk, more than one region, or more than one way to answer the phone.
Published 26 September 2026.