> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Multi-region media routing > How Orbit's media fabric is split across EU and US regions — the per-region SFU, TURN fleet, and room-state store; how a region is picked at room creation; and why cross-region failover is opt-in by design # 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](/compliance/voice-data-residency), 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](/concepts/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-.`), 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. This regional media fabric is independent of the single GCP compute region that hosts the platform's core services (the API pods and the primary database). The compute region does not change where a given room's media runs — region selection governs that. ## 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. | Region | Location | Serves | | ------ | -------------------- | --------------------------- | | `eu` | Europe (Belgium) | Europe, Africa, Middle East | | `us` | North America (Iowa) | North & South America | 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](/introduction) 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: `/` 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 Which calls ride the Orbit Media SFU versus the Jambonz carrier plane — the plane split runs orthogonally to the region split. The deeper architecture of the SFU and the SBC + RTPengine carrier plane that per-region clusters host. The tenant-facing controls: how to pin a region, and how long voice data is kept. How workspace data is isolated across the rest of the platform.