​

Multi-region media routing

Orbit’s media fabric — the Orbit Media SFU, the coturn TURN fleet, and the Redis room-state store — runs as independent per-region clusters, not as a single global deployment. Every WebRTC room is created in one region, keeps its live state in that region, and writes its recordings to that region’s storage. This page explains how regions are structured, how a region gets picked when you create a room, and why a room never silently moves regions. This is the architecture counterpart to Voice Data Residency & Retention, which describes what you configure as a tenant; this page describes how the platform resolves and enforces it.

​

The shared media fabric, per region

Each region is a complete, self-contained media cluster:

• Orbit Media SFU — the WebRTC selective-forwarding unit described in Transport architecture. Every video room and every browser-softphone session terminates on that region’s SFU pods.
• coturn TURN fleet — the same-region relay servers your client connects to when direct connectivity fails. TURN URLs are per-region (turn-<region>.<your TURN domain>), so the relay hop never crosses regions.
• Redis room-state store — a dedicated per-region Memorystore instance holding live room membership and session state. Room state for one region never lives in another region’s cluster.
• Recording storage — a same-region storage bucket (devotel-media-eu / devotel-media-us) that Orbit Media’s egress pipeline writes recordings to.

Because each cluster is self-contained, a room in one region is fully served by that region — signaling, media, TURN, state, and recording.

​

Region registry

The media fabric’s region identifiers are append-only: eu and us are live today, and new regions are added by provisioning a new cluster, never by renaming an existing one. Your workspace’s region preference accepts one extra value: auto, which means “pick per room at creation time” (see the next section). auto always resolves to a concrete eu or us before any media runs — it is never a region on its own. APAC, Middle East, and LATAM are reserved — provisioned on demand for tenants that need them. Until a point of presence exists there, tenants in those areas are served by the closer of the two live regions (Middle East and Africa route to eu; APAC splits by longitude between the two). Contact support to request a reserved region.

​

How a region is picked at room creation

Region selection runs once, when the room is created. The algorithm is a layered priority ladder — the first signal that resolves wins:

1. Workspace region pin. If your workspace sets preferred_region to eu or us, every room lands there regardless of where the creator or participants are. This is the highest-priority signal, so a residency pin cannot be silently overruled by geography.
2. SIP-bridge rooms follow the trunk. For SIP-bridge rooms, the carrier-side SBC reports which region it terminated the SIP leg in, and the room is created there — otherwise the audio would cross the Atlantic twice.
3. Creator’s country. The room creator’s country (from the geo-IP signal on the API request, or their profile country) maps to the lower-latency region.
4. Participant majority. When the creator signal is missing — for example a scheduled room started by a backend job — the known participants’ countries vote by majority. Ties fall through to the platform default.
5. Platform default. The API’s own region, used when nothing else is known.

Two room kinds get special handling: AI voice bridge rooms bypass the SFU entirely (the WebSocket bridge carries the audio), but a region is still picked so the bridge pod lands near the user. Whichever rule resolved the region is recorded on the room as a region_selection_reason (for example tenant_pinned, sbc_region, or creator_country), so you can audit why any individual call landed where it did. The region appears in the room-mint response as the signaling_url — region-specific, so the client connects straight to the right cluster without a second geo-hop.

​

The room-name convention: <region>/<id>

Every minted room name is prefixed with its region — eu/... or us/... — and that prefix does two jobs:

• Room-state isolation. Room state in Redis is keyed by room name, so the prefix guarantees a region’s state lives only in that region’s Redis instance. There is no cross-region key overlap to disambiguate.
• Recording residency. The egress pipeline derives the destination bucket from the room’s region, so recordings write to devotel-media-eu or devotel-media-us accordingly.

Playback works regardless of which region the recording lives in: the recording’s address carries its bucket, so a recording written in the EU still plays back correctly from a US-based session, without copying the audio out of its home region. Changing your workspace’s region preference affects new rooms only. Rooms already created and recordings already written stay where they are — switch before you start if you need everything in one region.

​

Why cross-region failover is opt-in, not automatic

If a region degrades, Orbit does not automatically move rooms to the other region. There is no automatic cross-region failover, and that is a deliberate design decision, not a gap:

• Tenants pin a region for data-residency reasons. Silently routing an EU-pinned workspace’s calls through US infrastructure during a degradation would violate the guarantee the pin exists to provide.
• Tenants on regulated workloads (GDPR residency, FINMA, and similar) explicitly refuse cross-region failover — for them it must never happen.

Cross-region failover is planned as an explicit per-workspace opt-in for tenants who value availability over strict residency — the platform will never substitute a region silently on its own. Until that opt-in ships, a degraded region affects that region’s rooms rather than rerouting them.

​

Related