WebRTC Video Conferencing (Zoom)

A real-time video conferencing system like Zoom must move audio and video between participants with sub-second latency over unpredictable home networks. It does this with a signaling layer to set up the call, NAT traversal (STUN/TURN) to punch through home routers, Selective Forwarding Units (SFUs) to route media streams, and simulcast plus bandwidth adaptation so each receiver gets the best resolution its connection can sustain.

Mental Model

Think of WebRTC video conferencing like setting up a multi-person phone call. First, you need an operator (Signaling Server) to exchange phone numbers (SDP/ICE) so everyone knows how to reach each other. If peers are behind home firewalls (NAT), they ask a public directory (STUN) for their public address. If they are behind a strict corporate security wall, they can’t connect directly; they must route calls through a paid relay operator (TURN). For the meeting layout, you can either call everyone directly (Mesh), send your feed to a central forwarder who passes copies around (SFU), or send your feed to a TV studio that mixes everyone into one split-screen video before sending it back (MCU).

Concept Flow

graph TD
    A[WebSocket Signaling Server] -->|Exchange SDP & ICE| B[Client A]
    A -->|Exchange SDP & ICE| C[Client B]
    B -->|Binding Query| D[STUN Server]
    C -->|Binding Query| D
    B -->|Fallback Media Relay| E[TURN Server]
    C -->|Fallback Media Relay| E
    B -->|Media Uplink| F[SFU Media Server]
    F -->|Forwarded Downlinks| C

Components and Why They Exist

WebSocket Signaling Server

Coordinates initial peer communication and protocol parameters out-of-band before media connection begins. Relays Session Description Protocol (SDP) payloads and ICE network candidates between participant browsers. In the demo, observe connection metadata packets routing through the signaling server during the call setup step.

STUN Server

Helps client devices determine their public IP addresses and ports to punch through NAT devices. Receives binding requests and returns the client’s public-facing reflexive IP address and port credentials. In the demo, observe the client querying the STUN server to discover its public NAT address.

TURN Server

Serves as a fallback relay for media packets when Symmetric NAT firewalls block direct connection paths. Relays UDP/SRTP packets between clients, proxying all media streams to maintain the call channel. In the demo, watch media data redirect through the TURN relay server when direct P2P connections are blocked.

SFU (Selective Forwarding Unit)

Routes high-volume conference streams efficiently with low server CPU and minimal client upload costs. Receives video/audio streams from each client and forwards exact copies to other participants without transcoding. In the demo, watch the SFU ingest single uplinks and forward multiple raw copies to downlink streams.

MCU (Multipoint Control Unit)

Minimizes subscriber bandwidth and CPU demands by blending all video feeds server-side. Decodes all incoming tracks, composites them into a single split-screen layout, and returns a single stream to each participant. In the demo, observe the MCU merge incoming video inputs into a single mixed stream before encoding and publishing it.

Edge Cases and Misconceptions

• P2P is Not Always Free: A common misconception is that WebRTC is entirely peer-to-peer and incurs no server hosting costs. In real-world environments, up to 20% of calls fail direct connection checks and must route through TURN servers, creating substantial network bandwidth fees.
• SFU vs. MCU Client Constraints: While an SFU is cheap to host, it forces the viewer client’s device to decode $N-1$ separate incoming video streams simultaneously. For large calls, this heats up mobile devices and drains batteries rapidly. MCUs keep client CPU cool by doing the compositing work on the server side.
• Encryption Limits Server Features: When End-to-End Encryption (E2EE) is enabled, media packets are encrypted using SRTP. Since SFUs only route encrypted ciphertext without decrypting it, the server cannot perform advanced features like active speaker detection (via audio volume analysis), server-side virtual backgrounds, or composite recording.