WebRTC in 2026: SFU, MCU or P2P, how to choose?
When you build or choose a video conferencing system, the first technical decision is the architecture that carries the media streams. Three models exist: peer-to-peer (P2P), the server that merges (MCU) and the server that relays (SFU). In 2026 the SFU dominates by a wide margin, but understanding all three is necessary to make an informed choice and avoid the traps.
What is P2P (peer-to-peer)?
In P2P, participants send each other their audio and video streams directly, without a server in between. Each browser establishes a WebRTC connection with every other participant.
The advantage is minimal latency: no intermediate server processes or relays the packets. For a two-person call, it is the most efficient model.
The limit is arithmetic. With N participants, each has to send N-1 streams. For five people in 720p video (roughly 1.5 Mbit/s per stream), each participant has to send 4 × 1.5 = 6 Mbit/s upstream. At ten participants, that is 13.5 Mbit/s upstream per person. The bandwidth required grows as O(N²), which makes P2P impractical beyond three or four participants on home connections.
P2P also has no central point for recording, moderation or stream control. It is the simplest model and the least flexible.
Who uses P2P in 2026? Jitsi Meet switches automatically to P2P for two-person calls (jitsi.org). Native WebRTC in browsers works in P2P by default. But no serious video conferencing system relies on P2P for group meetings.
What is an MCU (Multipoint Control Unit)?
The MCU is the historic video conferencing architecture. A central server receives every participant’s stream, decodes them, merges them into a single composite stream (a video mosaic and an audio mix), then sends that single stream to each participant.
The advantage is low bandwidth on the participant side: everyone receives only one stream, whatever the size of the group. It is also the only model that can send a composite stream to SIP systems or classic telephony endpoints.
The limit is the server’s CPU consumption. Decoding, merging and re-encoding N video streams in real time is the most resource-hungry operation in video conferencing. The MCU is a bottleneck that drastically limits scalability.
BigBlueButton still uses an MCU for audio: FreeSWITCH decompresses every participant’s audio, mixes it, and re-encodes the result. That partly explains BBB’s hardware requirements (16 GB of RAM, 8 cores, bare metal recommended) (BBB architecture docs) and FreeSWITCH’s high CPU use (4.5 to 7 threads for 167 users according to Octopuce).
Who uses an MCU in 2026? Almost nobody, for video. The MCU remains present in SIP gateways (Janus, jigasi for Jitsi) and in BigBlueButton’s audio mixing. But new projects no longer choose the MCU as their main architecture.
What is an SFU (Selective Forwarding Unit)?
The SFU is the dominant model in 2026. A central server receives each participant’s stream (once) and redistributes it selectively to the others, without decoding it, re-encoding it or merging it.
The advantage on the participant side: everyone sends their stream only once (to the server), which saves upstream bandwidth compared with P2P. Downstream bandwidth stays proportional to the number of streams subscribed to, but the SFU can handle that intelligently (simulcast, active-speaker selection, adaptive reduction of the number of streams).
The advantage on the server side: the SFU does not touch the content of the packets. It receives them and sends them back out. The CPU work is a fraction of an MCU’s. A well-implemented SFU can carry hundreds of participants on a modest server.
The security advantage: because the SFU does not decode the streams, an end-to-end encryption layer can be added on top of DTLS-SRTP. The server relays encrypted packets without being able to read their content. That is what Jitsi does with Insertable Streams (jitsi.org). Vuisio also relays without decoding, but does not claim end-to-end encryption: the data it keeps is encrypted at rest with AES-256-GCM.
The limit: the participant’s downstream bandwidth grows with the number of streams received. In practice, modern SFUs work around this with simulcast (each participant publishes several qualities and the SFU picks the right one for each receiver) and active-speaker selection (only the video of people speaking is sent at high quality).
A summary comparison
| Criterion | P2P | MCU | SFU |
|---|---|---|---|
| Server required | No | Yes (very powerful) | Yes (modest) |
| Upstream bandwidth | O(N) per participant | O(1) | O(1) |
| Downstream bandwidth | O(N) per participant | O(1) | O(N), optimisable |
| Server CPU | None | Very high (decode plus encode) | Very low (packet relay) |
| Scalability | 2 to 3 participants | Tens (depending on CPU) | Hundreds to thousands |
| Latency | Minimal | High (server processing) | Low (direct relay) |
| End-to-end encryption | Native (DTLS-SRTP) | Impossible (the server decodes) | Possible (Insertable Streams, E2EE) |
| Server-side recording | Impossible | Possible (composite stream) | Possible (capturing the relayed streams) |
| Adaptive quality | No | No (a single stream) | Yes (simulcast, layer selection) |
| Use case in 2026 | One-to-one calls | SIP gateways, legacy | Video conferencing, virtual classes, AI agents |
Why the SFU dominates in 2026
Three factors explain the industry’s convergence on the SFU.
Bandwidth has grown, CPU stays expensive
In 2026, fibre and 5G make downstream bandwidth abundant. Receiving five or ten video streams is no longer a problem for most participants. Server CPU, on the other hand, remains the most expensive resource and the hardest to scale. The SFU makes the right trade: it spends bandwidth (abundant) instead of CPU (expensive).
Simulcast and adaptive quality
A modern SFU does not simply relay blindly. With simulcast, each participant publishes their stream at two or three qualities (low, medium, high). The SFU picks the right quality for each receiver based on their bandwidth and display size. It is the best of both worlds: the flexibility of individual streams (SFU) with the bandwidth savings of adaptive streaming.
Vuisio implements that logic in its Rust SFU: it identifies the active speaker automatically and prioritises sending only the video of active speakers in large meetings, which naturally limits bandwidth consumption (docs.vuis.io).
Hybrid architecture becomes the norm
A reference article on WebRTC architectures in production notes that hybrid topology dominates in 2026: P2P for one-to-one calls, SFU for groups, selected dynamically per session (Forasoft). That is exactly Jitsi Meet’s approach. Vuisio simplifies by using the SFU in every case, which removes the complexity of switching between P2P and SFU.
Not all SFUs are equal
The SFU model is an architectural choice, not a guarantee of quality. The implementation makes the difference.
| Criterion | JVB (Jitsi) | LiveKit | mediasoup | Vuisio |
|---|---|---|---|---|
| Language | Java | Go (Pion) | C++ (worker) plus Node.js | Rust (str0m) |
| Garbage collector | Yes (JVM) | Yes (Go GC) | No (C++) / Yes (V8) | No |
| Transcoding | No (pure SFU) | No (pure SFU) | No (pure SFU) | No (pure SFU, raw RTP relay) |
| I/O architecture | JVM threads | Go goroutines | libuv (Node.js) plus C++ threads | Natively multi-threaded, one UDP socket per thread (docs.vuis.io) |
| Memory safety | JVM (managed) | Go (managed) | C++ (not guaranteed) | Rust (guaranteed at compile time) |
| Complete product included | Yes (Jitsi Meet) | No (toolkit) | No (library) | Yes (Vuisio, web client, modules) |
| Vendor | 8x8 (United States) | LiveKit Inc. (United States) | Open source community | Geezot (France) |
The fundamental difference between a Go or Java SFU and a Rust SFU is predictability. Go and Java have a garbage collector that can introduce unpredictable latency pauses (10 to 50 ms under load in Go, according to golang/go #37116). OpenAI, which uses Go for its real-time WebRTC infrastructure, had to work around the problem with pre-allocated buffers (OpenAI). Rust removes the GC entirely: latency is constant, not merely low on average.
How to choose for your project
Choose P2P if your use case is strictly limited to one-to-one calls (telemedicine, customer support) and you need neither recording nor server-side moderation.
Choose an SFU if you do group video conferencing, virtual classes, webinars or AI voice agents. It is the default choice in 2026.
Avoid the MCU unless you have a SIP or classic telephony compatibility constraint. The CPU cost and the complexity are no longer justified.
Among the SFUs, the choice depends on your need.
If you are building a custom application (an AI agent, a bespoke platform) and you have WebRTC developers, LiveKit or mediasoup are good infrastructure choices. If you are looking for a complete video conferencing product, sovereign, Moodle-compatible, with no development required, Vuisio is the only Rust SFU offering all of that in a finished product, hosted in France.
In summary
P2P works for two-person calls. The MCU belongs to telephony’s past. The SFU is the architecture of video conferencing’s present and future.
But the SFU is only a model. What counts is the implementation: the language (Rust removes the GC and memory bugs), the design (raw RTP relay, multi-threading, bounded queues) and the product around it (interface, moderation, encryption, LMS integration). Vuisio combines all of that in a complete, sovereign product that is free to start with.
Frequently asked questions
What is the difference between SFU, MCU and P2P?
In P2P, each participant sends their streams directly to the others (no server). In MCU, a server decodes every stream and merges them into one. In SFU, a server receives each stream once and redistributes it without decoding it. The SFU is the best compromise between quality, performance and scalability.
Why does P2P stop working beyond three participants?
In P2P, each participant has to send their stream to every other one. With five participants, each has to send four simultaneous video streams. The upstream bandwidth required explodes and quickly exceeds what a home connection can do.
Is the MCU still used in 2026?
Very little. The MCU (Multipoint Control Unit) is the historic technology of telephony systems. BigBlueButton still uses an MCU for audio (FreeSWITCH). But the MCU is CPU-hungry (it decodes and re-encodes every stream) and does not scale. Modern projects choose the SFU.
Does an SFU use a lot of server resources?
Far less than an MCU. The SFU does not decode streams, it relays them. The work comes down to receiving a packet and sending it back out. In Rust (Vuisio), the media relay uses only a few per cent of the processor, and the server carries 450 to 500 participants on 6 vCPU.
Is Vuisio an SFU or an MCU?
Vuisio is a pure SFU. It relays audio and video packets without ever decoding or re-encoding them (a raw RTP relay). That is what lets it use very few resources and run on modest hardware, from 1 GB of RAM upwards.
Can P2P and SFU be combined in the same product?
Yes, that is the hybrid approach used by Jitsi Meet: P2P for two-person calls (minimal latency), SFU for groups. Vuisio uses the SFU in every case, which simplifies the architecture and the deployment.
