WebRTC SFU Max Concurrent Participants Per Room

This article examines the theoretical and practical limits of concurrent participants in a single room when using a standard WebRTC Selective Forwarding Unit (SFU). It explains the underlying routing mathematics, details the server-side and client-side bottlenecks, and establishes the realistic maximum capacities for different video conferencing scenarios.

The Core Scaling Problem: \(N^2\) Complexity

To understand the maximum capacity of an SFU, you must first understand how media streams scale. Unlike a Mesh network where clients connect directly to each other, an SFU acts as a central hub. Each participant sends their media (audio and video) upstream to the SFU once. The SFU then routes (forwards) these streams downstream to all other participants.

If there are \(N\) participants in a room and everyone is publishing and subscribing to everyone else: * Upstream streams: \(N\) * Downstream streams: \(N \times (N - 1)\) * Total streams managed by the SFU: \(N^2\)

Because the number of streams increases quadratically (\(O(N^2)\)), resource consumption on both the SFU server and the client machines spikes rapidly as the room size grows.

Client-Side Bottlenecks

While the SFU server is powerful, the absolute bottleneck for interactive WebRTC rooms is almost always the client (the user’s browser and hardware).

  1. CPU and Decoding Limits: A standard user device (laptop or smartphone) must decode every incoming video stream. Most consumer hardware and web browsers struggle to decode more than 30 to 50 concurrent video streams simultaneously before experiencing CPU exhaustion, frame drops, and severe lag.
  2. Download Bandwidth: If 50 participants each stream video at 1 Mbps, a single client would require a consistent 49 Mbps download connection. This exceeds the average residential download bandwidth of many users.

Server-Side Bottlenecks

On the server hosting the SFU, the limitations are defined by network throughput and CPU processing:

  1. Packet Forwarding Rate: An SFU does not decode video, but it decrypts and inspects SRTP packet headers to route them. A single CPU core can route hundreds of thousands of packets per second, but a single highly active room cannot easily be parallelized across multiple CPU cores without introducing latency.
  2. Network Bandwidth: A single room with 100 participants streaming at 1 Mbps requires the SFU to egress roughly 9.9 Gbps of data (\(100 \times 99 \text{ Mbps}\)) for that single room. This quickly saturates standard 10 Gbps server network interfaces.

Theoretical Maximum Capacities

Depending on how the SFU room is configured, the theoretical maximum number of concurrent participants per room varies:

1. Fully Interactive Mode (Everyone Publishing Video & Audio)

2. Optimized Interactive Mode (Simulcast & Active Speaker Detection)

By utilizing Simulcast (sending multiple qualities of a video stream) and Active Speaker Detection (only forwarding video for the top 5–10 active talkers while pausing video for muted participants): * Theoretical Limit: 1,000 to 2,000 participants * The Reality: Only 5 to 10 people are seen and heard at any given moment, keeping client-side CPU usage low, while the remaining hundreds of participants act as passive listeners who can be instantly unmuted.

3. Large-Scale Webinar Mode (Few Publishers, Many Subscribers)

In a 1-to-Many or Few-to-Many scenario (e.g., 5 presenters and thousands of viewers): * Theoretical Limit on a Single SFU Node: 5,000 to 10,000 participants * The Reality: Since the egress is linear (\(5 \times N\)), the only bottleneck is the server’s network bandwidth. By cascading multiple SFU servers together (forwarding the presenters’ streams to edge SFUs), this limit can theoretically scale to tens of thousands of concurrent participants in a single room.