Why we built on mediasoup (and what that means for your call quality)
When we started building Bhet Online, the most consequential infrastructure decision we made was the choice of media server. That choice shapes latency, scalability, quality under poor network conditions, and ultimately the experience every attendee has in every session. We chose mediasoup — and here's why.
MCU vs SFU: the fundamental architecture choice
There are two dominant approaches to WebRTC media routing.
An **MCU** (Multipoint Control Unit) receives all participant streams, mixes them into a single composed stream, and sends that composite to each participant. Conceptually simple, computationally expensive: the server is doing video rendering for every participant at every frame.
An **SFU** (Selective Forwarding Unit) receives each stream and forwards the relevant ones to each participant without touching the media. The server routes packets, not pixels. Participants' devices do the rendering locally, which is what they're designed to do.
The tradeoff: MCUs are easier to reason about for end-to-end quality control (you mix at one point of quality), but they hit CPU walls quickly and add a mixing latency floor. SFUs scale better, add less latency, and push complexity to the edges — but require intelligent forwarding logic to work well across heterogeneous network conditions.
Why mediasoup specifically
Several mature SFUs exist: Janus, Jitsi Videobridge, Pion, LiveKit's underlying stack. We evaluated all of them. mediasoup won on three axes:
Architectural control. mediasoup is a library, not a server. You embed it in your Node.js process and own the signalling completely. We control every routing decision, every consumer/producer lifecycle, every transport. That makes features like our host-forced layout, Open Floor logic, and per-session codec configuration possible without fighting an opinionated server.
Simulcast and SVC support. mediasoup has first-class simulcast handling: a single video track can carry multiple encoding layers (e.g. 1080p, 540p, 270p), and the server selects the appropriate layer per consumer based on their available bandwidth. Attendees on a poor connection automatically receive a lower-resolution stream without the sender re-encoding.
Performance under South Asian network conditions. Our users are predominantly on Indian and Nepali networks, where packet loss and jitter are higher than Western infrastructure benchmarks assume. mediasoup's RTCP feedback handling and NACK/PLI retransmission implementation performs well in these conditions. We benchmarked it against Jitsi Videobridge on a simulated 3% packet loss link — mediasoup produced 40% fewer visible artefacts on the receiving end.
What this means for your sessions
You don't need to think about any of this day-to-day. What it produces is: sessions that hold quality longer under degraded network conditions, lower end-to-end latency (typically 100–200ms on a well-connected session vs 400–600ms on a mixed MCU implementation), and a media stack we can tune specifically for the network profiles of our user base.
It also means that when something goes wrong — a codec negotiation failure, a transport ICE disconnect — we have full visibility into the media layer and can diagnose it without waiting on a third-party platform's support queue.
The tradeoff we accepted is operational complexity. Running mediasoup in production requires real infrastructure work: worker process management, health monitoring, ICE server configuration. Our server/src/mediasoup/ directory reflects this — it's not a thin wrapper around a cloud SDK. We think it's worth it for the quality and control it gives us.
Try Bhet Online
Ready to run sessions that actually work?
Free plan available. No credit card required.
Get started free →