SFU vs MCU vs P2P: Choose a WebRTC Architecture 2026

Why Fora Soft wrote this playbook

We build video and real-time communication software, and we have done it since 2005 — 250+ shipped projects, most of them WebRTC-backed: video conferencing, telemedicine, live education, e-commerce live-selling, courtroom archives, webinars, interactive sports and LiveKit-based AI agents. We have debugged every one of these architectures behind real corporate firewalls, on flaky LTE, and under HIPAA and GDPR review.

One of those products, ProVideoMeeting, runs a WebRTC + FreeSWITCH + Kurento stack that mixes SFU forwarding, MCU-style composition and SIP/PSTN dial-in in a single conferencing product. That is the real answer to “SFU vs MCU”: production apps use both, in the right places. This playbook is the scoping conversation we have in week one of a WebRTC project, written down.

For the code-level protocol comparison, our older companion piece — P2P vs MCU vs SFU for video conferencing — digs into the packet path. This one stays at the level a CTO or founder actually decides on: cost, scale, compliance, time to market. For hands-on help, see our WebRTC architecture development work.

The one question: SFU vs MCU vs P2P

The SFU vs MCU vs P2P choice comes down to one number: what is the 95th-percentile concurrent participants per room? Not the demo, not the best case — the routine peak once the product is in real use. Answer that and the topology mostly picks itself; everything after is refinement.

The three models differ in one place: who touches the media. In P2P, nobody — peers send to each other. In an SFU, a server forwards each stream without decoding it. In an MCU, a server decodes every stream, mixes them into one picture, and re-encodes. That single difference drives cost, scale, battery and compliance, in that order.

Figure 1. Who does the work in each topology — and what it costs the server. The SFU forwards; the MCU decodes, mixes and re-encodes.

Peer-to-peer (P2P): fast, cheap, and bounded

In pure P2P, two browsers negotiate SDP through your signalling server and then exchange DTLS-SRTP media directly, with no server in the media path. On a good network, end-to-end latency lands around 50–150 ms. Server cost is near zero: you pay only for signalling and for TURN relay when a direct path fails.

Mesh P2P extends this to small groups: every participant sends their stream to every other. For N participants that is N×(N−1) streams. It holds up for 3–4 people on decent devices; past five it burns mobile batteries and saturates uplinks. That ceiling is the whole story with P2P — wonderful below it, unusable above it.

The non-negotiable: TURN. You need a TURN cluster — coturn on two or three hosts is enough for an MVP, then scale to Cloudflare Realtime TURN, Twilio or Xirsys for global coverage. Roughly 10–20% of corporate and mobile networks block direct ICE and force a relay; the exact number depends on your user mix. Skipping TURN looks cheaper on day one and turns into support tickets on day thirty.

Selective Forwarding Unit (SFU): the 2026 default

An SFU is a media router. Each participant uploads their stream once, and the SFU forwards it to whoever needs it. It does not decode or re-encode, so per-participant CPU stays low and latency stays close to the direct path. That combination is why the SFU is the default for anything past a 1:1 call in 2026.

Modern SFUs lean on two bandwidth tricks. Simulcast has the publisher send three resolutions of the same video, and the SFU forwards whichever layer each subscriber can take; in a typical three-layer setup the publisher’s upload runs about 30–50% above a single high-quality stream (per DigitalSamba’s 2026 measurements), and the receive side saves far more. SVC packs those layers into one encoded stream.

Here’s the 2026 catch worth knowing before you promise AV1: real-time AV1 encoding runs in Chrome (since Chrome 90) but is CPU-heavy with limited hardware acceleration, and Safari exposes no AV1 encode at all and cannot encode VP9 either. Broad cross-browser AV1 SVC is not expected before roughly 2028. Ship H.264 or VP8 simulcast as your floor, and treat AV1/VP9 SVC as a Chromium-only optimization for now.

The 2026 SFU shortlist

LiveKit. Apache-2.0 Go SFU built on Pion, plus a managed cloud. Clean SDKs everywhere, a first-class AI-agent framework (LiveKit Agents hit 1.0 in April 2025 and sits at the 1.6.x line in mid-2026 with native MCP tool support), and it is the open-source WebRTC stack OpenAI runs ChatGPT’s Advanced Voice Mode on. Our default pick for new work; the LiveKit multimodal agent guide has the implementation detail.

mediasoup. A C++ engine you drive from Node.js. Small, composable, and it hands you the routing logic instead of a product. Choose it when you control the signalling and want deep control of the byte path.

Janus. A mature C gateway with a plugin per use case. It is the one project that ships SIP, RTSP and SFU in a single server, which makes it the pick for cross-protocol gateways and broadcast plug-ins.

Jitsi Videobridge. The Kotlin/Java engine inside Jitsi Meet. Simple to operate, sane defaults, mature dominant-speaker and last-N logic. When teams outgrow it on scaling or recording, our guide to Jitsi alternatives maps where they go next.

Pion, and the managed lane. Pion is a Go library you assemble your own SFU on when you want to own everything. Prefer to buy the ops? LiveKit Cloud, Daily, Dolby.io and the Amazon Chime SDK sell managed SFU by the minute. We compare all five open-source engines side by side in our SFU comparison on Learn, and the official WebRTC project is the canonical reference for the underlying standard.

Multipoint Control Unit (MCU): mixer, composer, heavyweight

An MCU decodes every incoming stream, mixes them into one composite, re-encodes, and sends a single stream to each viewer. That one stream is easy on the client: any old smart TV, set-top box or low-end phone can play a single 1080p H.264 feed with no WebRTC client at all. The price is paid on the server. Decoding and re-encoding N streams in real time typically runs 4–10× the compute of an SFU at the same participant count — that is an engineering rule of thumb we plan capacity with, not a fixed constant.

Common MCU tooling: Pexip Infinity for enterprise, Kurento (now maintained mainly as OpenVidu), Wowza Streaming Engine, Dolby.io, and specialist broadcast mixers. The honest framing: a pure MCU at 100+ participants usually costs more to run than an SFU feeding LL-HLS out to tens of thousands of viewers. The MCU earns its keep on composition and legacy-client reach, not on raw scale.

Hybrid architectures: how real products ship

Serious WebRTC products rarely pick one model and stop. A meeting or creator-commerce product usually layers them, escalating only when the room size demands it:

1. Signalling control plane. One service — your own, or LiveKit / Chime SDK — owns auth, rooms and presence.

2. P2P for 1:1. Below a small room threshold (usually 2–3), drop the SFU and connect peers directly. Cheaper, usually lower latency.

3. SFU for groups. Above that threshold, escalate to an SFU with simulcast and dominant-speaker forwarding.

4. SFU cascade + LL-HLS for broadcast. Past a few hundred subscribers, mirror the SFU’s active-speaker feed into an LL-HLS egress on Cloudflare, Mux or AWS; the crowd joins over HLS and never touches a WebRTC connection.

5. Optional MCU for composition. A side MCU produces a branded broadcast feed or a single recording from the same SFU source.

6. TURN underneath everything. Always.

Cost models: what each architecture does to your bill

The unit that matters is dollars per participant-minute, plus egress. The figures below are 2026 ballparks for commodity cloud (an AWS / Hetzner blend); tune them for region and volume. They are ranges on purpose — if a number felt too clean it would be wrong.

Figure 2. Server cost per participant-minute by architecture (log scale). The MCU sits at the top; SFU + LL-HLS pushes the crowd onto a cheaper CDN path.

Concrete 2026 anchors help. LiveKit Cloud bills about $0.004 per audio track-minute and $0.006–$0.024 per video track-minute, with pay-as-you-go participant minutes from $0.0004 (see livekit.com/pricing). Cloudflare Realtime (formerly Cloudflare Calls) charges $0.05/GB of egress for its SFU and TURN, with the first 1,000 GB free each month and TURN free when paired with the Realtime SFU.

Worked example: why broadcast needs a CDN

Take a 200-viewer, 60-minute webinar at 2 Mbps. Each viewer pulls 2 Mbps × 3,600 s = 7,200 Mb = 900 MB ≈ 0.9 GB. Two hundred viewers is 180 GB per event. On Cloudflare Realtime at $0.05/GB that is about $9 of egress — the first few events a month land inside the free tier. Direct SFU fan-out is fine at this size.

Now scale the same feed to a 50,000-viewer campaign day. That is 50,000 × 0.9 GB = 45 TB per event. Over an LL-HLS CDN at roughly $0.02/GB, about $900. A pure-SFU fan-out has to move the same 45 TB and stand up dozens of SFU instances, because one SFU handles hundreds to low-thousands of subscribers, not fifty thousand. The CDN path lands near one-sixth of the all-in cost — the single clearest reason broadcast products go hybrid.

Figure 3. The two curves cross around a few hundred viewers. Below that, direct SFU is simplest; above it, the CDN path wins by a widening margin.

Host choice moves the whole picture. For steady media load we bias toward Hetzner AX-series or dedicated Equinix Metal, with AWS or GCP bursts for peaks; the AWS vs DigitalOcean vs Hetzner breakdown has the raw numbers.

Security and compliance by architecture

WebRTC mandates DTLS-SRTP, so every media path is encrypted in transit on all three topologies. The differences show up in metadata exposure, server-side processing and what regulators will ask you to prove.

P2P. Media never touches a server, so end-to-end confidentiality is the default and your subpoena exposure is minimal. That is why telehealth and legal-consult apps often start here.

SFU. The SFU forwards but does not decrypt, as long as you keep it transparent. For a stricter bar — “the server must never be able to see my video” — add a second encryption layer with the WebRTC Encoded Transform API (the standardized successor to Insertable Streams), so the SFU forwards only ciphertext it cannot read; SFrame handles multiparty keys. One honest 2026 caveat: this is solid on Chromium browsers, and partial and uneven on Safari and Firefox, so design a Chromium-first E2EE path and test the rest. webrtcHacks tracks the moving support.

MCU. By definition the server decodes and re-encodes, so media-layer E2EE is impossible. You compensate with hardened infrastructure, private networking, short-lived tokens, server-side DLP and audit logs. It is still workable under HIPAA and PCI with the right contracts — you just carry the trust on the server instead of the wire.

Hybrid. Apply the right model per session: regulated 1:1 over P2P with E2EE, group training over an SFU with Encoded Transform, marketing broadcast over a CDN behind SSO. One product, three postures.

The AI layer: noise suppression, transcription, agents

In 2026, AI features are often the reason a customer picks one WebRTC product over another. Five integrations keep recurring in our engagements, and all of them sit more naturally on an SFU (where a server-side consumer can tap the media) than on a P2P call.

Noise suppression. RNNoise, Krisp SDK, Dolby Voice. Run it on the publisher where you can, on the server where you must.

Real-time transcription and captions. Deepgram, AssemblyAI, Whisper-class models. A server-side consumer taps the SFU’s audio forwarding; our guide to speech recognition in noise covers accuracy in the wild.

Real-time translation. A strong pull for global sales and events; see our real-time meeting translation comparison.

Synthetic voice agents. LiveKit Agents plus OpenAI Realtime or ElevenLabs makes a voice agent a first-class participant in the room. That is where a lot of support, scheduling and onboarding work is heading.

Recording and smart summaries. Record the SFU composite (or an MCU output), run a post-call LLM for action items, push to the CRM. Shipping this used to be a quarter of work; with our Agent Engineering approach we now deliver it in 3–4 weeks.

Mobile: the architecture that drains batteries fastest

Mobile changes the math. A P2P mesh with four or more participants will flatten a mid-range Android in under an hour, because the device encodes a separate stream for every peer. Move to an SFU with simulcast and hardware H.264 and the same call stretches to three or four hours of continuous use — the phone encodes once and lets the server do the fan-out.

What we enforce on every WebRTC mobile app. Hardware-accelerated codecs only (H.264 baseline, H.265 where supported); simulcast layer selection driven by the on-screen tile size; a screen-off and picture-in-picture pause policy; a dynamic bitrate cap on low battery or thermal throttling; the audio track in communication mode; and lifecycle handling careful enough that tracks actually release when the app backgrounds. Skip the last one and you ship a battery bug that only appears in the wild.

Mini case: telehealth to 50k-viewer live, one platform

Situation. A European digital-health company came to us with a working P2P telehealth product and a new line: live group patient-education sessions, up to 500 concurrent, expected to spike near 50,000 on campaign weeks. HIPAA-adjacent, GDPR-strict, budget-sensitive. A pure managed-SFU quote for the campaign peaks looked frightening.

The 14-week plan. Weeks 1–3: architecture design, a LiveKit pilot, TURN hardening, and an Encoded-Transform E2EE proof. Weeks 4–7: SFU rollout with simulcast, P2P kept for 1:1 consults. Weeks 8–10: LL-HLS egress cascade from the SFU to the CDN for big-audience days. Weeks 11–12: live captions, recording, CRM handoff. Weeks 13–14: load test at 3× projected peak, audit logging, GDPR review.

Outcome. Median publish-to-subscribe latency settled near 180 ms on LTE; the CDN-backed broadcast held under 4 s for 40,000+ concurrent viewers at roughly one-sixth the cost of a pure SFU at that scale. The existing 1:1 flows kept their near-zero P2P bill untouched, and cost per paid participant-minute fell about 35% versus the managed stack they had been scoping against. Want a similar assessment of your stack? Grab 30 minutes.

The 2026 WebRTC vendor and tooling shortlist

One naming trap to clear first: the Amazon Chime application and communication service reach end of support on 20 February 2026, but the Amazon Chime SDK is unaffected and continues. If a vendor slide still lists “Amazon Chime,” ask which one they mean.

Development effort estimates, honestly scoped

Ballpark hours to build each layer from scratch with the tooling above. These reflect our Agent-Engineering delivery; a non-accelerated team should plan for 40–60% more. Treat them as scoping anchors, not quotes — if we doubt a number for your case, we would rather not print it.

A decision framework: pick an architecture in five questions

Answer these in order. The first one settles most of the debate; the rest catch the edge cases that turn a clean SFU plan into a hybrid one.

Figure 4. The first question, drawn out: peak participants per room maps almost directly to a recommended topology.

Q1. What is your p95 concurrent participants per room? 1:1 → P2P. 3–50 → SFU. 50+ broadcast → SFU + LL-HLS, or an MCU.

Q2. Does the server need to decode the media? Composition, a legal archive, a PSTN bridge or thin clients → an MCU joins the mix. If not → SFU only.

Q3. What is your compliance bar? HIPAA / PCI / GDPR-strict → SFU with Encoded-Transform E2EE, or P2P. Commercial only → any model.

Q4. What is your time to market? Under 3 months → managed SFU (LiveKit Cloud, Daily, Chime SDK). 6+ months and enough ops muscle → self-hosted open-source SFU.

Q5. Will the product ever have a broadcast mode? Yes → plan the cascade and egress from day one. No → revisit if the roadmap shifts.

Five pitfalls that sink WebRTC projects

1. Skipping TURN. Corporate firewalls and mobile carrier NATs quietly break 10–20% of sessions without it. This is the single most common launch-day fire we get called into.

2. Picking an MCU by default. An MCU sounds “more professional,” then bills 4–10× more for a plain meeting. Use an SFU unless you genuinely need server-side composition.

3. Ignoring simulcast. A 50-person call without it forces every subscriber to process full-resolution video for a thumbnail-sized tile. Turn simulcast on from day one.

4. A single-region SFU. A London-only SFU serving Tokyo publishers feels broken to those users. Plan for at least two regions once you pass a few hundred monthly actives.

5. No QoE instrumentation. You cannot debug what you cannot see. Log bitrate, packet loss, jitter and round-trip time from day one and push them to a dashboard with alerts.

KPIs: what to measure in a WebRTC product

Quality. Publish-to-subscribe latency under 250 ms p95 in-region and under 400 ms p95 cross-region; packet loss under 2% p95; jitter under 30 ms p95; video freeze rate under 0.4%.

Business. Connection success rate above 99.5%; call setup under 3 s; call drop rate under 0.8%; retention on sessions longer than 5 minutes above 80%.

Reliability and cost. TURN-relay rate under 25%; SFU CPU headroom above 30%; dollars per participant-minute within 10% of target for three straight months.

When WebRTC is the wrong answer

One-way broadcast to 10k+ viewers with no interaction. Use LL-HLS or HLS from a CDN. WebRTC only earns its complexity when the broadcast has to stay interactive — chat, reactions, live Q&A under a second.

On-demand video. OTT and VOD belong on HLS or DASH; see our OTT platform development playbook.

Sub-100 ms audio for pro music collaboration. Esports team-voice and remote jamming sometimes need purpose-built low-latency protocols. WebRTC’s typical sub-150 ms is usually enough, but not always — and it is worth naming when it is not.

FAQ

What is the real difference between SFU vs MCU?

An SFU forwards each participant’s stream without decoding it, so the server stays cheap and the client receives several streams. An MCU decodes every stream, mixes them into one picture, re-encodes, and sends a single stream out — easy on the client, heavy on the server (roughly 4–10× the SFU compute per participant). Choose an SFU for scale and low cost; choose an MCU only when you need server-side composition or must reach clients that cannot run WebRTC.

Do I still need TURN if my SFU is in the public cloud?

Yes. TURN is the fallback when a participant’s network blocks direct UDP or TCP to the SFU, and it fires on roughly 10–20% of corporate and mobile networks even against a public SFU. Without it, those users cannot connect at all.

What is simulcast and why does it matter?

Simulcast has the publisher send several resolutions (usually three) of the same video, and the SFU forwards whichever layer each subscriber needs. A 25-person meeting sends thumbnails at 180p and the active speaker at 720p, instead of pushing full 720p of everyone to everyone. The publisher’s upload rises about 30–50% for three layers, and the receive side saves much more.

Can I switch architectures later without a rewrite?

Yes, if you keep signalling, room management and UI decoupled from the media transport. Most of the clients we move from P2P to SFU, or from Agora to LiveKit, keep their product UI untouched and rewire only the media plumbing.

Is an MCU always more expensive than an SFU?

Per participant, almost always yes. An MCU wins only when it removes a bigger cost elsewhere — for example, when it replaces 10,000 WebRTC subscribers with one encoded HLS output, at which point it is far cheaper than a 10,000-way SFU fan-out.

Does LiveKit replace an SFU or is it one?

LiveKit is an SFU — an Apache-2.0 Go server built on Pion — shipped either self-hosted or as a managed cloud. On top of the SFU it adds SDKs, an AI-agent framework, and egress for recording and LL-HLS. It is the open-source WebRTC stack OpenAI runs ChatGPT’s Advanced Voice Mode on.

Is the Amazon Chime SDK going away in 2026?

No. The Amazon Chime application and communication service end support on 20 February 2026, but the Amazon Chime SDK is a separate product and is not affected. If you build on the SDK today, you are fine; just do not confuse it with the retiring consumer app.

How do WHIP and WHEP fit in?

WHIP (ingest) and WHEP (playback) are HTTP-based signalling profiles that run WebRTC underneath. They simplify broadcast-shaped workflows and are increasingly supported by CDN and LL-HLS providers. Reach for them when the workload is one-to-many and a thin client beats a full WebRTC peer.

What to read next

Ready to ship real-time video that pays back?

Real-time video architecture is a trade-off space, not a menu. P2P is free but bounded. The SFU is the default and scales beautifully with simulcast. The SFU vs MCU call comes down to whether the server must compose the picture — and an MCU only earns its 4–10× bill when it does. Hybrid is how production products actually ship, applying the cheapest model that each session can tolerate.

We have made this call on 250+ products since 2005, across telehealth, education, live commerce and broadcast. If you want a partner that has already solved your version of it, book 30 minutes and we will map the shortest path to a working, scalable WebRTC stack.