Skip to content
Guide

WebRTC Topologies: Mesh vs SFU vs MCU

Mesh, SFU, and MCU are the three ways to architect a multi-participant WebRTC call. Each has a different trade-off between latency, scalability, and cost. Here is how to choose the right one.

Mesh (full mesh)

In a mesh topology, every participant connects directly to every other participant. For N participants, each peer maintains N−1 connections and sends its media to each one. The media flows peer-to-peer with no server in the path, giving the lowest possible latency.

The downside: bandwidth and CPU scale as O(N²). Each peer uploads its media N−1 times. For 4 participants that is 3 uploads each — manageable. For 10 it is 9 uploads — your bandwidth is saturated. Mesh is the right choice for small groups (2–8 participants) where latency matters most.

  • Latency: lowest (no server hop)
  • Scaling: O(N²) — caps at ~8–10 participants
  • Server cost: minimal (signaling only)
  • Best for: 1:1 calls, small group calls, pair programming

SFU (Selective Forwarding Unit)

In an SFU, each participant sends one media stream to the server. The server forwards (selectively) each stream to all other participants. Each peer uploads once and downloads N−1 streams. Bandwidth scales as O(N), not O(N²), so SFUs handle larger groups (20–50 participants) well.

The trade-off: a server hop adds latency (~50–100ms) and you pay for server bandwidth. SFUs are the modern standard for group video (Zoom, Google Meet, Daily.co all use SFUs).

  • Latency: low, but adds ~50–100ms server hop
  • Scaling: O(N) — practical to ~50 participants
  • Server cost: bandwidth for forwarding N streams
  • Best for: team meetings, webinars, online classes

MCU (Multipoint Control Unit)

In an MCU, the server decodes every participant's stream, composites them into a single layout (e.g., a grid), and re-encodes one stream per participant. Each peer downloads only one stream. This minimizes client bandwidth and works for very large groups (hundreds of participants) and low-bandwidth clients.

The trade-offs are significant: the server does heavy encode/decode work (expensive CPU), adds latency (100–300ms), and you lose the ability to individually control participant streams. MCUs are uncommon in modern apps but used in legacy telephony and broadcast scenarios.

  • Latency: highest (server decode + composite + encode)
  • Scaling: hundreds of participants
  • Server cost: very high (CPU-intensive transcoding)
  • Best for: legacy interoperability, very large audiences, low-bandwidth clients

Summary

Mesh wins on latency and cost for small groups. SFU is the workhorse for medium groups. MCU is for special cases. openbnet uses mesh for video calling (optimal for the 2–10 participant range it targets) and bridge-tunnel for multi-host streaming. If you need SFU-scale group calls, openbnet Enterprise includes an SFU media server.

All guides · Explore openbnet APIs · Developer quickstarts

About openbnet

openbnet is the real-time communication infrastructure company founded by Brian. It builds the openbnet platform — six production-ready APIs for voice, video, chat, live streaming, signaling, and AI content moderation — plus solutions on that platform: Ocodey, the CLI coding agent, and Spaces, managed communities. One openbnet account signs you in to every solution.

Website: openbnet.com · GitHub: github.com/openbnet · X: @openbnet