WebRTC SFU Architecture: Forwarding, Layers & Scale | Callaba
More live video workflow notes and product updates.
A WebRTC SFU receives encoded tracks from publishers and selectively forwards them to subscribers. It avoids composing every participant into one mixed video, but it does not make media cost disappear. A useful SFU design states who publishes which layers, who subscribes to which tracks, how the server reacts to constrained downlinks, and what operators can inspect when a tile freezes.
An SFU is a selective media forwarder
Do not assume the room topology
Callaba documents browser video rooms, participant authorization, screen sharing, recording, and room or participant outputs to managed media workflows. Those capabilities are enough to design and test a room experience.
Callaba's documentation does not identify the internal room topology as an SFU, describe a per-subscriber forwarding API, or expose operator controls for simulcast layer selection. Do not infer an SFU implementation from the presence of a multi-party room. If a project requires a specific SFU contract, confirm topology, subscription controls, scale limits and statistics with Callaba before treating them as available product features.
| Question | Documented Callaba starting point | SFU-specific confirmation still needed |
|---|---|---|
| Can browsers join a room? | Yes, through the documented video-call flow | Which media topology handles the room |
| Can media leave the room? | Documented recording and output workflows exist | Whether each source track remains independently selectable |
| Can an operator debug one subscriber? | Browser evidence can be collected | Server-side subscription, RID and forwarding telemetry |
SFU, MCU and mesh solve different scaling problems
In a peer mesh, each participant sends media directly to every other participant. That keeps servers out of the media path but multiplies publisher upload as rooms grow. An MCU decodes, composes or mixes streams, and sends a produced result. That can simplify subscriber decoding, but server-side media processing is substantial and the receiver loses independent track control.
An SFU sits between those models. Publishers normally send one encoded track or a small set of alternative encodings. The SFU forwards selected streams without building a single composite program for everyone. Publisher upload becomes more predictable, while SFU egress grows with subscriptions and selected bitrates.
The standards call this selective forwarding
RFC 7667 describes RTP topologies and uses the term Selective Forwarding Middlebox. It receives RTP streams, chooses which sources to forward into an endpoint's RTP session, and may rewrite RTP fields while preserving the media. The middlebox also participates in RTCP processing and codec-control feedback.
This matters in production. An SFU is not an Ethernet switch with no session state. It tracks participants, transports, sources, subscriptions, sequence spaces, feedback and encryption contexts. A capacity model must include packet rate and encryption work as well as aggregate bitrate.
Simulcast gives the SFU useful choices
RFC 8853 defines SDP signaling for simulcast. A publisher can send multiple encodings of the same source, commonly identified with RTP stream identifiers. The SFU can then forward a lower or higher encoding without asking the subscriber to decode a resolution it cannot sustain.
Layer policy should be visible, not magical. Define the preferred layer for a pinned speaker, thumbnails, screen share and recording. Define what happens if that layer stops, how quickly the receiver moves down under congestion, when it moves up, and whether a keyframe is requested during the switch. Automatic selection still needs an observable decision.
Subscription is as important as transport
A subscriber may be authorized for a room yet intentionally receive only a subset of tracks. Layout, active-speaker policy, hidden participants, recording rules and device limits can all alter subscriptions. Debugging therefore starts with two separate questions: was the track subscribed, and did its packets arrive?
Give each publication and subscription stable identifiers across client and server logs. Record the publisher, media kind, source name, SSRC or RID, requested quality, selected quality, reason for a change, forwarded bitrate, loss feedback and keyframe requests. Redact addresses and SDP details that are not needed for diagnosis.
Capacity is asymmetric
For each publisher, estimate ingress bitrate and packets per second for all active encodings. For each subscriber, sum the tracks and layers actually delivered. Server egress is approximately the sum of those subscriber selections, plus protocol overhead and headroom; room count alone hides the difference between a ten-person audio room and a large video grid.
Test CPU, memory, encryption work, network interface throughput and event-loop or packet-processing delay. Then add failure cases: a node drain, many simultaneous keyframe requests, a popular speaker switching to a higher layer, or a regional path change. A node that handles steady bitrate may still stumble during synchronized recovery.
A mobile tile stays black after bandwidth returns
A mobile subscriber drops to a low layer during congestion. Bandwidth later recovers, but the pinned speaker remains black while audio continues. Restarting the room hides the defect. Instead, correlate the subscriber's requested RID, the layer the publisher is still sending, the SFU's selected source, outbound packet growth, packet-loss feedback, PLI or FIR events, and decoded frames in the browser. The subscription points to a high RID that temporarily disappeared, and the fallback policy did not select another available encoding. Correct the missing-layer rule, request a keyframe when switching, and verify the tile resumes without rejoining while the selected-layer event is recorded.
Put the architecture under pressure before launch
- Define topology. State where signaling, ICE, TURN and media forwarding run.
- Name publications. Track camera, microphone and screen sources independently.
- Write subscription policy. Cover layouts, hidden tracks, recording and authorization.
- Exercise layers. Constrain one receiver, remove a RID and restore bandwidth.
- Load the real mix. Use representative codecs, packet rates and subscriptions.
- Prove recovery. Drain a node, interrupt a publisher and inspect keyframe behavior.
WebRTC SFU architecture FAQ
Does an SFU decode and mix every video?
Normally no. It selectively forwards encoded RTP streams. A separate recording, transcoding or composition service may decode and produce media when required.
Why use simulcast with an SFU?
Simulcast gives the forwarder alternative encodings of one source, allowing different subscribers to receive layers suited to layout and network conditions.
What usually limits SFU capacity?
Egress bitrate, packet rate, encryption and session state all matter. The limiting resource depends on codec mix, subscriptions, hardware and implementation.
Does Callaba use an SFU internally?
Callaba documents multi-party browser-room capabilities, but it does not name a specific SFU topology. Confirm that requirement directly before designing around SFU-specific controls.