WebRTC Primer
A concise walkthrough of the WebRTC handshake — ICE, STUN, TURN, SDP, and the signaling channel that ties it all together.
The Core Idea
WebRTC enables peer-to-peer media and data channels between browsers without plugins. The heavy lifting happens during connection establishment — two peers must exchange network topology information before a single byte of media flows.
Step 1 — Signaling
WebRTC does not specify a signaling protocol. You bring your own — WebSockets, SSE, or even a pastebin link. Signaling exchanges SDP offers and answers plus ICE candidates between peers. Think of it as the handshake courier.
Step 2 — SDP
Session Description Protocol blobs describe media capabilities — codecs, resolutions, transport addresses. The offer/answer model means one peer proposes, the other responds. SDP is plain text, verbose, and entirely generated by the browser API.
Step 3 — ICE
Interactive Connectivity Establishment finds the best network path. Each peer gathers candidates — host (local IP), srflx (STUN-reflected public IP), and relay (TURN server). Candidates are exchanged over signaling, then connectivity checks run pairwise until a working pair emerges.
STUN vs TURN
STUN servers tell a peer its public IP and port. They are lightweight and handle ~85% of NAT scenarios. TURN servers relay media when direct paths fail — symmetric NATs, restrictive firewalls. TURN is expensive; use it as a fallback, not a default.
The Data Channel
Beyond media, WebRTC offers an arbitrary data channel — SCTP over DTLS over UDP. Low latency, ordered or unordered delivery, perfect for game state, file transfers, or signaling bypass once the connection is live.
Ready to build? See the WebRTC Data Channel recipe for a working implementation with signaling and TURN fallback.