WebRTC

Why it matters

Video calls, screen sharing and low-latency game state are a different problem from the rest of this module: the payload is large and continuous, a few hundred milliseconds of delay is unacceptable, and sending it all through your servers is expensive. WebRTC is the browser's answer, and it comes up in interviews for video products, where the question is really "what do you still have to build and run when the browsers talk to each other".

The idea

WebRTC lets two browsers (or a browser and a server) exchange audio, video and arbitrary data directly over UDP, encrypted, with adaptive bitrate and packet-loss handling built in. The browser does the media work. What it does not do is find the other peer or get through the network between them. That is your job.

Signalling: the part you build

Before media flows, the peers must exchange session descriptions (SDP: codecs, media tracks, encryption keys) and ICE candidates (addresses they can be reached at). WebRTC deliberately does not specify how; you carry these messages over a channel you already have, typically a WebSocket to your signalling server. The signalling server knows who is in which room and relays offers, answers and candidates between them. It never touches media.

Getting through NAT: ICE, STUN, TURN

Most devices sit behind NAT and have no public address. ICE (Interactive Connectivity Establishment) gathers every candidate address a peer might be reachable at, tries them in pairs and picks the best working one.

Mechanism	What it does	Cost
Host candidates	Local addresses; work on the same LAN	Free
STUN	A server tells the peer its public address and port as seen from outside, so peers behind cone NATs can connect directly	Tiny: a few packets per session; public STUN servers exist
TURN	A relay server forwards all media when direct connection fails (symmetric NATs, strict firewalls)	Real: all media bandwidth flows through your servers; roughly 10 to 20 percent of sessions need it

You must run TURN servers (or pay a provider) in every region you serve, or a meaningful fraction of users cannot connect at all. Budget their bandwidth; it is the main infrastructure cost of a "peer-to-peer" product.

More than two people: mesh, SFU, MCU

In a full mesh, every participant sends their stream to every other participant. Upload bandwidth and encoding cost grow with the group size, so mesh works for two to four people and collapses beyond. An SFU (selective forwarding unit) is a server each participant sends one stream to; it forwards the streams each participant wants without decoding them, so the client uploads once and downloads N-1. It is how nearly every video product works. An MCU (multipoint control unit) decodes everything and composes a single mixed stream per participant: minimal client bandwidth, very high server CPU, and it is used mainly for legacy interop and recording.

	Mesh	SFU	MCU
Client upload	N-1 streams	1 stream (often several quality layers)	1 stream
Client download	N-1 streams	N-1 streams, chosen per viewer	1 mixed stream
Server	Signalling and TURN only	Forwards packets; no decoding; moderate bandwidth	Decodes and re-encodes; heavy CPU
Latency	Lowest	Low	Higher
Fits	1:1 calls, tiny groups	Group calls, webinars, most products	Recording, mixing, legacy endpoints

SFUs use simulcast (the client sends low, medium and high quality layers) so the SFU can forward a small layer to a thumbnail view and a large one to the active speaker, adapting to each receiver's bandwidth without re-encoding.

Data channels and beyond media

WebRTC data channels carry arbitrary bytes peer to peer, reliably or unreliably, ordered or not. Unreliable unordered delivery is what fast-paced games want and what WebSockets cannot offer. The same signalling and ICE machinery applies.

Operating it

Deploy TURN and SFUs regionally and pick the nearest at join time. Monitor connection success rate, time to first frame, and the TURN fallback fraction. Handle network changes: ICE restarts when a user moves from Wi-Fi to cellular. Record on the server side via the SFU if recording is a feature. Expect to use a mature SFU (mediasoup, Janus, LiveKit, Jitsi) or a managed service rather than writing one.

Trade-offs

WebRTC gives encrypted, adaptive, sub-second media with the browser doing the heavy lifting, and in exchange you run signalling, STUN, TURN and (for groups) SFUs across regions, debug NAT traversal, and live with UDP being blocked in some corporate networks. For anything other than real-time media or unreliable low-latency data, the simpler transports in this module are the right call.

In an interview

Separate what the browser does from what you run: "Browsers negotiate and carry media over WebRTC. We run a WebSocket signalling service for rooms and SDP exchange, STUN for address discovery, regional TURN relays for the 15 percent who cannot connect directly, and SFUs with simulcast for calls above two participants. Recording happens at the SFU." Then the cost line: "TURN and SFU egress is the dominant infrastructure cost."