WebRTC: peer-to-peer media, signalling, NATs and media servers

What WebRTC is

WebRTC is a set of browser APIs and protocols for sending audio, video and arbitrary data directly between peers with low delay, for example for calls, screen sharing, games and file transfer. Media travels over UDP-based protocols and is encrypted (DTLS and SRTP) by default.

The problem it must solve

Two browsers behind home routers (NATs) usually have no public addresses and cannot just connect to each other. They first need to learn about each other, exchange what they can send and receive, and discover a network path that works.

100%

Figure SDA-SQR-06-1 · Setting up a call · © forcsguy.com

The pieces

• Signalling is not part of WebRTC; you build it (a WebSocket service works well). It carries the session descriptions (SDP offer and answer) and ICE candidates. It also handles rooms, who is online and permissions.
• ICE (Interactive Connectivity Establishment) gathers candidate addresses and tests pairs to find a working path.
• STUN servers tell a peer its public address as seen from the internet. They are cheap and light.
• TURN servers relay the media when no direct path works, for example behind symmetric NATs or strict firewalls. Relaying costs real bandwidth, so use it as a fallback and monitor how often it is needed.
• Codecs and adaptation: the connection adapts bitrate to the available bandwidth, and can drop quality instead of stalling.

100%

Figure SDA-SQR-06-2 · Direct path versus relay · © forcsguy.com

Beyond one-to-one: mesh, SFU and MCU

Topology	How it works	Good for	Cost
Mesh	Every peer sends to every other peer	2 to 4 people	Upload grows with participants; weak devices struggle
SFU (selective forwarding unit)	Each client sends one stream to a server, which forwards it to others without decoding	Most group calls and webinars	Server bandwidth; no transcoding, so low delay
MCU	Server decodes and mixes all streams into one	Legacy rooms, recording a mixed view	Heavy CPU, higher delay

SFUs often use simulcast (the sender uploads a few quality layers) or scalable coding, so the server can send each receiver a layer that fits its bandwidth.

100%

Figure SDA-SQR-06-3 · Mesh versus SFU for a group call · © forcsguy.com

Design checklist

• Own signalling with authentication and room permissions; it is the control plane and a security boundary.
• Deploy STUN and TURN in several regions near users; measure the relay share and its bandwidth cost.
• Choose SFU for group calls; scale it by placing each room on one server and spreading rooms across servers, with regional placement for latency.
• Handle reconnection, device changes and poor networks (lower resolution, audio first).
• Plan for recording (SFU-side or a bot participant) and moderation separately; they are not free with peer-to-peer.
• For one-way live streaming to huge audiences, WebRTC is costly; HLS or DASH with a CDN scales better at higher latency (see the video streaming lessons).

Real-world reading