P2P, SFU or MCU: choosing a WebRTC topology

The topology decision is made early, is expensive to reverse, and is usually made by accident — whichever sample app was cloned first.

There are three shapes. The right one follows from your participant count and who is paying for the bandwidth.

Peer-to-peer mesh

Every participant sends their stream directly to every other participant.

For a two-person call this is ideal: minimum latency, no media server, no per-minute cost, and the media is end-to-end encrypted between exactly two parties with nothing in the middle.

It degrades quadratically. With n participants each client maintains n − 1 outbound streams:

Participants	Outbound streams per client	Uplink at 1.5 Mbps each
2	1	1.5 Mbps
4	3	4.5 Mbps
6	5	7.5 Mbps
8	7	10.5 Mbps

Typical residential uplink gives out somewhere around four to five participants, and laptops start encoding several streams in parallel. Mesh is the correct answer for one-to-one and essentially never correct above about four.

SFU — selective forwarding unit

Each client sends one stream up. The server forwards copies to everyone else.

Uplink becomes constant regardless of room size, which is the entire point. The server does no transcoding — it routes packets — so it is comparatively cheap in CPU and scales to large rooms on modest hardware.

This is what LiveKit, mediasoup, Janus and Jitsi are. It is the default choice for group calling in 2026, and unless you have a specific reason otherwise it is probably your answer.

Two things people miss:

• Simulcast is what makes it work. Clients publish the same video at several resolutions; the SFU forwards whichever layer each receiver can handle. Without it, one participant on poor bandwidth degrades the call for everybody. Turn it on.
• End-to-end encryption changes. Media is encrypted to the SFU, decrypted for routing decisions, re-encrypted onward. If you need true end-to-end, you need insertable streams on top, and that is a genuine project.

MCU — multipoint control unit

The server decodes every incoming stream, composites them into one, re-encodes and sends a single stream down.

It is expensive — transcoding is CPU-hungry in a way forwarding is not — and it adds latency. But it remains right in specific cases:

• Receivers too weak to decode several streams, including older set-top hardware
• A single composited output for recording or for broadcasting to RTMP/HLS
• Interoperating with SIP or legacy conferencing that expects one stream

Most products that think they need an MCU actually need an SFU plus a separate recording pipeline.

Choosing

Situation	Topology
1:1 calls, support, telehealth consults	P2P
Group calls up to ~50	SFU
Webinar, one-to-many broadcast	SFU + simulcast
Composited recording or RTMP output	SFU + server-side compositor
Legacy SIP / set-top interop	MCU

The cost consequence

The topology decides who pays for bandwidth.

P2P pushes cost onto participants and gives you a near-zero server bill — until a relay is required, at which point a share of calls quietly becomes TURN traffic you pay for. SFU moves all media through infrastructure you rent, which is predictable and measurable but never free.

This is where the managed-SDK bills that prompt a migration usually come from: per-participant-minute pricing on a group product that grew. Self-hosting an SFU converts a variable per-minute cost into a fixed server cost, and the crossover is arithmetic you can do before committing.

Run that arithmetic on your own numbers first. Migrating a media layer is a real project, and it is only worth doing when the spreadsheet says so.

---

We migrate products off metered SDKs onto self-hosted LiveKit and mediasoup, and model the per-minute cost before and after so the decision is made on numbers.