Route media
Forward selected producer streams instead of mixing every call on the server.
WebRTC engineering guide
Build real-time apps on an SFU without rebuilding the platform around it.
Use an SFU when participants need interactive audio, video, screen sharing, recording, or AI media workflows beyond a simple one-to-one call. MediaSFU uses mediasoup for selective media forwarding, then adds the production services teams otherwise have to assemble around it.
10production SDK paths
500K+supported concurrent viewers
$0bandwidth markup
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
Choose the media topology before the framework
The topology determines bandwidth, server work, recording options, and how far the room can scale. Framework choice comes after that decision.
| 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.
Control quality
Use simulcast or scalable layers so receivers can consume the quality their network supports.
Build the product
Add rooms, permissions, recording, widgets, APIs, and operator workflows around the SFU.
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
Model the room
Estimate participants, concurrent producers, video tiles per page, resolution, and session duration.
- 02
Choose the surface
Start with prebuilt UI or widgets, then use SDK and headless controls where product differentiation matters.
- 03
Plan the media path
Place SFU capacity near users, provide TURN fallback, and decide which streams are recorded or sent to AI.
- 04
Prove production behavior
Test reconnects, device changes, packet loss, recording output, webhooks, and regional failover.
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.
What is a WebRTC SFU?
A selective forwarding unit receives encoded media and forwards chosen streams to other participants without mixing every stream into one composition.
Is MediaSFU the same project as mediasoup?
No. mediasoup is an independent open-source SFU. MediaSFU uses it as a media-routing foundation and supplies a broader managed platform, SDK, UI, API, recording, telephony, and workflow layer.
Can I start with prebuilt UI and move to headless control?
Yes. The same platform supports ready-made applications, embeddable widgets, prebuilt SDK UI, and lower-level SDK control.
Continue the decision
Open the guide for the next constraint.
Build after the architecture is clear