> ## 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. # Media planes > When a call or video room rides the Orbit Media SFU versus the Jambonz SBC + RTPengine carrier plane — and when one call spans both # Media planes A video room and a PSTN call look like the same thing from the API — "real-time media" — but they ride two different planes, and the plane is decided by the endpoint you call and the leg type, not by a request flag. * **Orbit Media (SFU)** carries WebRTC media: video rooms and the browser softphone. * **Jambonz SBC + RTPengine** carries PSTN/SIP carrier media: inbound DIDs and outbound calls. Pick the endpoint for the experience you want, and the plane follows. One call can span both planes — a browser softphone dialling a PSTN number rides Orbit Media on the browser leg and crosses to the carrier plane through the Jambonz bridge. ## The two planes ### Orbit Media (SFU) Orbit Media is Orbit's Selective Forwarding Unit. It handles everything that needs server-side fan-out or mixing of WebRTC media: simulcast, per-subscriber bitrate adaptation, codec negotiation, DTLS/SRTP, and server-side recording via egress. Use this plane when every participant is a WebRTC client — browsers, the dashboard softphone, or a native SDK. There is no non-SFU mode for video. ### Jambonz SBC + RTPengine PSTN and SIP carrier media never touches the SFU. It terminates on the Jambonz session border controller, with RTPengine bridging RTP/SRTP between the carrier and Orbit: * **Inbound** — Telnyx and DIDWW DIDs route through Jambonz, which applies your number-handler routing. * **Outbound (MT)** — `POST /api/v1/voice/calls` initiates the call through Jambonz, which terminates it on the Devotel wholesale softswitch. Outbound voice exits only via Devotel. Recording on this plane is in-call SIPREC (`POST /api/v1/voice/calls/:id/recording/start`), not SFU egress. ## Which plane picks you | What you're doing | Plane | Why | | ---------------------------------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------- | | Any video room (`/api/v1/video/rooms`, `/rooms-scheduled`) | **Orbit Media (SFU)** | Simulcast, per-subscriber bitrate, server-side recording (egress) | | Browser softphone session | **Orbit Media (SFU)** or **SIP/WSS gateway** | Depends on the client SDK — see [Browser softphone](#browser-softphone) | | Inbound PSTN/SIP call (Telnyx / DIDWW DID) | **Jambonz SBC + RTPengine** | Carrier SIP terminates on the SBC; RTPengine bridges media | | Outbound (MT) voice (`POST /api/v1/voice/calls`) | **Jambonz SBC → Devotel softswitch** | Outbound termination exits only via the Devotel wholesale softswitch | The deeper architecture narrative for both planes lives in [Transport architecture](/concepts/transport-architecture). ## Tokens and credentials per plane Clients never talk to a plane with a long-lived key. Each plane has its own short-lived credential path: * **Video rooms (SFU)** — `POST /api/v1/video/rooms` (or `/api/v1/video/rooms-scheduled`) creates the room and mints a participant token against Orbit Media. See [Video API](/api-reference/video). * **Browser softphone (SFU)** — `POST /api/v1/voice/softphone/token` mints an Orbit Media token for the deterministic per-user room `softphone::`, so reconnects rejoin the same room and are idempotent. The token is short-lived (default 60 seconds). See [Softphone token](/api-reference/voice#softphone-token). ## Browser softphone: SFU or SIP/WSS gateway The browser softphone has two client transports, chosen by the SDK in use — not by a request flag: * **Orbit Media (WebRTC)** — the dashboard softphone calls `POST /api/v1/voice/softphone/token` and joins an Orbit Media room. * **SIP over WSS** — the `@devotel-orbit/web` `Softphone` calls `POST /api/v1/voice/softphone/register` to obtain a short-lived SIP credential and `REGISTER`s against Orbit's WebRTC-to-SIP gateway over a secure WebSocket. The SIP password is HMAC-derived and never stored; issuance and revocation metadata (issue/expiry times, the owning org, a revoked flag) is persisted server-side so you can revoke a credential before it expires. Call `DELETE /api/v1/voice/softphone/credentials/:username` to revoke — the gateway rejects the HMAC on its next validation, even within its original lifetime. Either way, when the call has a carrier leg it crosses to the Jambonz plane as described above. ## End-to-end: browser softphone to PSTN When a single call spans both planes, the path looks like this: 1. Your browser client mints a softphone token via `POST /api/v1/voice/softphone/token` (SFU plane) or a SIP credential via `POST /api/v1/voice/softphone/register` (gateway plane). 2. The client dials out — either `POST /api/v1/voice/softphone/dial` from an SFU session, or a SIP `INVITE` over the WSS gateway. 3. Jambonz bridges the browser leg onto the carrier plane and terminates the outbound leg on the Devotel wholesale softswitch. 4. RTPengine bridges RTP/SRTP between the browser-side leg and the carrier for the duration of the call. 5. Recording, if started, runs on the carrier plane as SIPREC; an SFU-only session would use Orbit Media egress instead. The same bridge applies inbound: a PSTN caller reaches Jambonz on the carrier plane, and your browser softphone answers it on the SFU or gateway leg. ## What the API does *not* expose To keep this page honest against the code: * There is no `transport` field on `POST /api/v1/voice/calls` and no `INVALID_TRANSPORT` error code. The plane is implied by the endpoint and leg type. * There is no client-facing "decision tree" endpoint that ranks SFU vs. WebSocket bridge per call, and no per-call latency-budget selection. Choose the endpoint for the media you have; the plane follows.