Signaling
Create rooms, authorize members, exchange transport parameters, and coordinate lifecycle events.
Architecture decision
WebRTC SFU architecture: what the server forwards and your product owns.
An SFU receives encoded media from each producer and forwards selected streams to consumers. It avoids the full decode-and-mix cost of an MCU while giving the application control over subscriptions, layouts, recording inputs, and quality layers.
1uplink per producer
Nselectable consumer streams
0server-side mixing required
Selective media flowPublish once. Route by need.
ClientsAudio, video, screen
→SFUSelect and forward
→OutputsClients, recording, AI
Signaling controls the session. Secure WebRTC transports carry media. The SFU forwards the streams and quality layers each receiver needs.
Decision 01
Follow one participant through the media system
Signaling establishes intent and permissions; WebRTC transports carry encrypted media; the SFU routes streams; the application decides who receives what.
| Topology | Best fit | Main tradeoff | Media control |
|---|---|---|---|
| P2P | One-to-one calls and very small sessions | Each participant sends media to every other participant | Application-owned |
| SFU | Interactive rooms, broadcasts, recording, and real-time AI | Requires server routing, capacity planning, and observability | Server selects and forwards streams |
| MCU | A single precomposed output or legacy endpoints | Server decodes and mixes media, increasing compute cost | Server composes the final stream |
System view
The SFU is the routing core, not the whole product.
Media routing
Publish audio, video, or screen tracks and create consumers only for the streams a participant needs.
Product control
Apply roles, pagination, recording rules, moderation, webhooks, and UI state outside the SFU core.
Decision 02
Move from topology to a production plan.
The useful sequence is workload, ownership, media path, and proof. Starting with a UI framework skips the decisions that determine reliability and cost.
- 01
Create the room contract
Define roles, limits, media defaults, and the events your client must observe.
- 02
Establish transports
Negotiate secure WebRTC connectivity and retain TURN as a fallback for restrictive networks.
- 03
Publish and consume
Send producer tracks once and subscribe each participant to the appropriate streams and layers.
- 04
Handle lifecycle changes
Recover from reconnects, paused tracks, device changes, participant exits, and worker movement.
Implementation ownership
Know what you are adopting.
mediasoup is an independent, signaling-agnostic open-source SFU. MediaSFU builds a managed platform around that routing foundation; it does not rename the upstream project or erase the responsibilities your application still owns.
Read the official mediasoup overview- Room and event APIs
- Web, mobile, native, and Unity SDK paths
- Prebuilt UI, widgets, and headless controls
- Recording, telephony, translation, and AI media workflows
- Regional infrastructure and operational tooling
Questions engineers ask
Short answers before you choose the stack.
Does an SFU decode participant video?
Normally it forwards encoded RTP streams and selected quality layers. Decoding and composition are separate workloads used when a mixed output is required.
Where does signaling live?
WebRTC does not prescribe an application signaling protocol. The product layer coordinates rooms, permissions, transports, producers, consumers, and lifecycle events.
Why is TURN still needed with an SFU?
TURN provides a relay path when direct client-to-SFU connectivity is blocked by restrictive NAT or firewall behavior.
Continue the decision
Open the guide for the next constraint.
Build after the architecture is clear