Skip to main content
Back to blog

Scaling video in a CPaaS: 1:1 rooms to broadcast, and why embedded support video is table stakes

The room-model decision that decides a video program — 1:1, small-group, interactive broadcast, each with a shipped sample — then the embedded-support case for why video inside the contact center contact record is the 2026 baseline, the recording and retention posture regulated verticals configure, the WebRTC transport reasoning that makes those paths hold, and the Twilio Video migration quick-hop.

Orbit Editorial Team

Every video program starts as a 1:1 support call and ends as a question the first architecture review never asked: what happens when the room stops being two people? The honest answer is that "scaling a video room" is three decisions wearing one name — the room model you run per session, whether the video lives inside your support stack or beside it, and the transport discipline that keeps either path from degrading at 6 p.m. on a bad network. This post walks all three on the shipped Devotel Orbit surface, because the buyer query family behind them — "scale a room from 1:1 to broadcast", "WebRTC vs SFU vs MCU in 2026", "video support embedded in my contact center" — keeps arriving as three separate vendor searches when it is one program decision.

The room-model decision: 1:1, small-group, interactive broadcast

There are three room models worth naming, and each earns its place on a different session shape. The trap is picking one model and forcing every session through it.

1:1 — the consult. Two publishers, trivial topology. The contest at this shape was never about media forwarding; it is about what wraps the room: a join token minted server-side so the browser never holds an API key, a waiting room enforced at join, a recording that lands on the same contact record as the chat thread that escalated into the call. Orbit's shipped sample for this shape is the embedded consultation room — the persistent "video call us" destination documented in the persistent video rooms guide, re-opened by the same customers on their next visit, minted per participant by POST /api/v1/video/rooms-scheduled/:id/join.

Small-group — the pit crew. Two to twelve publishers where everyone sees everyone: an escalation huddle, a four-agent pit crew around one customer's broken configuration, a claims review with the adjuster, the customer, and the repair shop on one screen. This is the shape where the SFU (selective forwarding unit) stops being abstract: each participant publishes once, the SFU forwards each published track to every subscriber, and nobody's browser runs a full-mesh encode for every peer. The room model Orbit runs for every shape — creation, per-role join-token minting, recording and broadcast egress — is the one documented in the video room model concept, which is why the small-group shape inherits the same grant tiers, moderation, and recording controls as the 1:1 consult — one media plane, not a second vendor for the huddle. The room access tokens guide covers minting participant joins per role at this size.

Interactive broadcast — the stage plus the audience. A handful of publishers, an arbitrary count of receive-only viewers, and an RTMP egress that mirrors the room to a public stream. The scaling variable here is not the room at all; it is the subscriber count, which grows linearly while the publish side stays bounded by the hosts. Orbit's shipped sample pairs persistent rooms with RTMP egress — the recording and BYO-storage guide documents the egress side alongside capture into your own bucket — and the room templates guide shows the per-shape presets so the broadcast does not have to be hand-assembled per event.

The 2026 answer to "WebRTC vs SFU vs MCU" is that the question is settled at the platform layer: an SFU forwarding published tracks is the operating model every serious RTC vendor converged on, and a full-mix MCU survives only in legacy interop corners. The buyer decision that remains is the one above — which of the three shapes your sessions actually run, per session, on one account. The room scaling post works the publish-versus-subscribe math in depth; this post's job is the map between shapes and shipped samples.

When video lives inside support

The infrastructure question has a second half: where does the video sit relative to the contact center? A standalone video vendor gives you a room and a separate dashboard; the support team then reassembles the customer story by hand across two systems. The pattern that wins in 2026 contact centers is the escalation ladder inside the inbox — a chat thread that becomes a voice call that becomes a video room, all on one contact record, because the thread that started as "my router shows a red light" is the same thread the video consult resolves.

That is exactly the flow the embedding video for customer support guide walks end to end: the server-minted join token, the <orbit-video-room> element a developer pastes into the support surface, and the room joining the SMS, WhatsApp, email, and voice channels the contact already uses. The operational prerequisite for the ladder is knowing when to escalate and who is free to take it, and Orbit ships both halves on the same account: the IVR and intent routing explainer covers getting the right contact into the right queue, and the workforce management guide covers staffing the queue so a video escalation finds a free agent instead of a hold queue. Embedded support video is table stakes for the same reason a phone number is: the customer does not care which escalation rung resolves the issue, and they notice immediately when the ladder has a missing rung.

Recording, retention, and e-discovery for regulated verticals

Finance, healthcare, and insurance teams read a video program's recording posture before they read its feature list, and the posture that holds up under review is tenant-owned end to end. Orbit ships the controls and defaults every answer to the tenant's configuration: which sessions record, how participants are told, how long captures are retained, and who a capture can be shared with — the same framing the video session recording and co-browse compliance guide applies to the video channel and the call-recording consent rules post applies to voice. For retention that has to live in the tenant's own estate — the e-discovery posture a regulator asks to see — the BYO-storage path puts captures in the customer's own bucket from the start rather than exporting them after the fact.

The surrounding privacy surface follows the same rule. The DSAR self-service portal guide covers how a data-subject request reaches the data you hold — including recordings — and the trust and compliance model page documents the compliance posture the platform itself carries, so the split stays clean: the platform's certifications answer for the platform, your configured controls answer for your data. Nothing in this section is a platform-set policy, by design; a platform that hard-codes a retention window has answered a question only your counsel can answer.

The WebRTC transport reasoning that makes the paths hold

The room model decides what a session is; the transport decides whether it holds up on a hotel Wi-Fi connection. Three settings carry most of the weight, and all three are visible in the shipped surface.

TURN placement is a routing and cost decision, not a checkbox. Browser-to-SFU media wants the direct path; NAT-hostile networks (corporate proxies, carrier-grade NAT) fall back through a relay. If relayed media crosses an ocean, the 1:1 consult that worked in the office dies on the road — so relay placement belongs in the same region as your SFU and your customers. Orbit's media plane runs on wss://media.orbit.devotel.io, the server URL every join receives beside its token, and the video room model concept documents the join-token and egress lifecycle the relay posture sits on.

ICE trickle and token minting belong on the server side. The join response a backend receives carries everything the browser needs to connect — token plus media server URL — so candidate gathering and signaling ride the established session instead of a second handshake the support page has to get right. That is deliberate surface design: the <orbit-video-room> element takes a token and a server URL and owns the connection lifecycle, because an embed that asks the host page to manage ICE by hand is an embed that breaks differently in every iframe it lands in.

Bitrate is a room-scoped policy the SFU enforces. Upside per publisher is bounded by what one person's camera should send; the multiplier is the subscriber count, which is exactly why the broadcast shape caps publishers rather than viewers. Orbit persists per-room media policy in room metadata — the SDK reads it on join and applies the publish budget and screen-share surface to the session — and the video quality monitoring guide shows the per-session view of what the policy produces in the wild: the bitrates, losses, and resolutions a room actually ran. Transport discipline is not a feature row; it is the reason the three room models above survive contact with real networks.

Migration quick-hop: coming from Twilio Video

Twilio Video's sunset made this the most common video program decision of the last two cycles, and the move is shorter than the feature diff suggests, because the room-model map above is the migration map: 1:1 consults become persistent embedded rooms, small-group sessions become granted rooms on the Orbit SFU, and broadcasts become templates with RTMP egress. The Twilio Video to Orbit runbook carries the step sequence — token minting swap, embed swap to the web SDK element, recording and retention re-configuration — and the Vonage Video runbook covers the adjacent case. Both land on the same surface the rest of this post describes, which is the point: you are not migrating to a room API, you are moving the room onto the account your messaging and voice already run on.

Frequently asked questions

Can one Orbit account run 1:1, small-group, and broadcast rooms together?

Yes. The room model is chosen per session — persistent rooms for 1:1 consults, granted rooms for the pit-crew huddle, and broadcast with RTMP egress for audience sessions — on the same media plane and the same account that carries messaging, email, and voice.

Is embedded support video really table stakes in 2026?

For contact centers it is the new baseline, the way a phone number always was: customers expect the escalation ladder — chat to voice to video — to exist inside the conversation they already have, not on a separate vendor's page. The embedded support guide covers shipping it.

Who owns video recording consent and retention — the platform or the tenant?

The tenant, end to end. Orbit ships the controls — which sessions record, how participants are told, retention, revocable sharing — and defaults every answer to your configuration. Regulated verticals pair that with BYO storage for e-discovery; the compliance guide maps the controls.

Do I need an MCU for large rooms?

No — the SFU forwarding published tracks is the settled 2026 model, and the broadcast shape scales by bounding publishers, not by mixing every stream. The scaling math lives in the room scaling post.

What does the WebRTC transport layer need right to scale?

Regioned TURN placement beside the SFU, server-minted tokens that carry the media server URL so the embed owns connection setup, and a per-room bitrate policy the SFU enforces — the three settings the transport section above walks through.

Published 12 October 2026.

Scaling video in a CPaaS: 1:1 rooms to broadcast, and why embedded support video is table stakes — Orbit by Devotel