SFU foundation
mediasoup provides low-level, signaling-agnostic media routing primitives for Node.js applications.
Operating model
Managed mediasoup means owning your product, not every SFU operation.
mediasoup is the independent open-source SFU foundation. A managed platform operates capacity, room placement, regional infrastructure, and supporting services so your team can focus on the client experience, permissions, workflows, and business logic.
6continents at the edge
10SDK paths
$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
Separate the media engine from the production responsibility
Choosing mediasoup does not automatically provide deployment, authentication, room APIs, client UI, recording, telephony, or operational support.
| 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.
Managed runtime
MediaSFU operates routing capacity, room placement, edge access, APIs, recording paths, and observability.
Your product
Your team controls the customer journey, branding, roles, data model, integrations, and differentiated UX.
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
Define ownership
List which infrastructure, signaling, recording, observability, and client responsibilities your team wants to run.
- 02
Validate the client path
Test prebuilt UI, widgets, and SDKs against the product experience you need to ship.
- 03
Model the workload
Compare participant media, recording, AI egress, storage, and operations rather than one isolated API rate.
- 04
Keep an exit path
Use documented APIs, SDKs, webhooks, and direct provider relationships to avoid unnecessary lock-in.
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 does mediasoup provide by itself?
mediasoup provides low-level SFU primitives, including workers, routers, transports, producers, and consumers. Application signaling and product services remain your responsibility.
What does MediaSFU add?
MediaSFU adds managed infrastructure, room and event APIs, SDKs, prebuilt UI, widgets, recording, telephony, translation, AI workflows, and operational tooling.
Can I bring my own AI and SIP providers?
Yes. Supported provider relationships remain direct, which keeps provider choices and their charges visible rather than hiding them inside one bundled rate.
Continue the decision
Open the guide for the next constraint.
Build after the architecture is clear