WebRTC meeting architecture: SFU, MCU and hybrid topologies

Every WebRTC meeting product eventually answers the same architecture question: how do media streams reach everyone without exhausting client bandwidth or server capacity? The answer shapes cost, quality and operational complexity for years.

This article explains the main topologies and the practical trade-offs between them, without assuming a specific vendor.

The transport baseline

WebRTC provides encrypted media over UDP (with TCP fallbacks) using ICE for connectivity, DTLS for key exchange and SRTP for media encryption. Signalling is not specified: you design it.

Two properties drive topology choices:

• Uploads are expensive for clients. A participant’s outbound bandwidth is usually the binding constraint, especially on mobile networks.
• Servers are unavoidable for scale. Peer-to-peer is elegant for two participants and impractical for twelve.

Mesh

Every participant connects directly to every other participant.

• Uploads per client: n−1 streams.
• Server media load: none (signalling only).
• Best for: one-to-one calls, tiny group calls, or cases where media must not touch a server.

Mesh quality degrades quickly. With 10 participants each sending 1 Mbit/s, every client uploads roughly 9 Mbit/s and receives the same. Mobile devices and asymmetric links struggle, and there is no central point to apply policy.

SFU (Selective Forwarding Unit)

Each client publishes one stream (or a few simulcast layers) to the server; the server forwards selected streams to subscribers.

• Uploads per client: typically 1–3 layers.
• Server egress: roughly publishers × subscribers × layers, which grows with room size.
• Best for: most meeting products, webinars with limited interaction, and large rooms where selective subscription matters.

An SFU does not decode media, which keeps CPU cost manageable, but it does terminate DTLS/SRTP and therefore carries bandwidth and cryptographic work. Capacity planning is dominated by egress, not encoding.

Simulcast and SVC

With simulcast, the publisher sends multiple resolutions; the SFU forwards the layer appropriate to each subscriber’s network. SVC achieves similar adaptation with layered encoding. Both reduce the need for transcoding and improve behaviour under congestion, at the cost of more upstream bandwidth from publishers.

Cascading SFUs

For geographically distributed or very large rooms, SFUs can cascade: one SFU forwards a published stream to another SFU, which fans out locally. This reduces cross-region traffic but adds latency hops and complicates routing and failure handling. Cascading is an optimisation, not a default.

MCU (Multipoint Control Unit)

The server mixes audio and video into composite streams.

• Uploads per client: one.
• Server work: decode, mix, encode — CPU-intensive and codec-sensitive.
• Best for: very large broadcasts, heterogeneous devices, or strict bandwidth limits on receivers.
• Downsides: compositing limits personalisation (each viewer sees the same layout), adds latency, and the server becomes a costly scaling point.

Modern meeting products often use an SFU with selective forwarding plus server-side compositing only for recording or broadcasting, rather than a classic MCU for every participant.

Comparison

Signalling design decisions

Topology is only half the design. Signalling affects reliability and operations:

• State ownership. Keep authoritative room state in your service, not in client memory.
• Token-based authorisation. Issue short-lived join tokens; validate permissions at the media and signalling layers.
• Idempotent operations. Reconnects and retries will happen; design joins and publishes so they can be repeated safely.
• Version negotiation. Assume client and server versions diverge during rollouts.
• Observability hooks. Emit events for join attempts, negotiation failures and media quality so you can debug without reproducing sessions.

NAT traversal and relays

ICE finds a path, but some networks only allow relayed connectivity. Plan for TURN:

• Place relays close to users to limit added latency.
• Budget relay bandwidth separately; relayed media is carried twice.
• Monitor relay usage; a spike often indicates a network change rather than normal growth.

In private deployments, TURN may be internal only, but cross-site and remote-access scenarios usually require an edge relay.

Recording and processing

Recording is a media pipeline, not a checkbox. Options include client-side recording, server-side compositing, and stream-level capture at the SFU. Each has consequences for CPU, storage, consent and retention. Decide the policy first, then the implementation.

Choosing a topology

Use these questions:

1. What is the largest typical room, and the largest possible room?
2. Are participants mostly on managed networks or mobile and public internet?
3. Do viewers need individual layouts, or is a shared composite acceptable?
4. How much cross-region traffic are you willing to pay for?
5. Do you need recording, and who can access it?

For most private enterprise meetings, an SFU-based design with TURN relays, simulcast and a clear capacity model is the pragmatic choice. Mesh remains useful for edge cases; MCU remains useful for broadcast.

Closing

Architecture choices are constraints in disguise. Decide the room sizes, networks and compliance boundaries first; the topology usually follows. Feiyan RTC is an SFU-based, privately deployable option, and the same questions apply whichever vendor you evaluate.