Nicholas Clooney

WebRTC — How it actually works

WebRTC lets browsers and native apps exchange audio, video, and arbitrary data in real time - without routing everything through a server. The "peer-to-peer" framing is appealing, but it elides a lot: you still need to build signaling, operate STUN/TURN servers, and design fallback paths for the connections that never go direct.

Under the hood, WebRTC is two largely separate concerns stacked together: a signaling layer you design entirely yourself, and a transport layer the browser owns.

Mental model: Signaling (you build) + NAT traversal via STUN/TURN + encrypted P2P transport (browser) = WebRTC

Key components

Five pieces interact to get a connection established. Three of them you operate; two are handled by the browser runtime.

Signaling server
Not part of the WebRTC spec. You build it. Exchanges SDP offers/answers and ICE candidates between peers. Commonly WebSocket or Socket.IO.
STUN
Answers "what does my public IP/port look like?" Cheap to run, needed for most P2P paths.
TURN
Full relay fallback. Traffic routes through your server when direct P2P fails. Bandwidth costs scale with usage.
ICE
Gathers candidate paths (host, STUN-reflexive, TURN-relay), tests them in parallel, picks the best working route.
SFU (optional)
For multi-party calls. Each peer sends once; the SFU fans out. Avoids O(n²) mesh connections. Examples: mediasoup, LiveKit.

Connection flow

A connection goes through six ordered phases. The first three happen over your signaling channel; the rest are handled by the browser.

01 — Signaling setup Both peers connect to the signaling server and join a session or room.

02 — Offer / Answer (SDP exchange) Caller generates an SDP offer; callee responds with an SDP answer. Encodes codecs, media types, and encryption params.

03 — ICE candidate exchange Each peer gathers candidates (local, STUN-reflexive, TURN-relay) and sends them through the signaling channel.

04 — Connectivity checks ICE runs STUN binding requests on every candidate pair until it finds a working path.

05 — Secure transport setup DTLS key exchange, SRTP for media, SCTP over DTLS for data channels. All mandatory - WebRTC is always encrypted.

06 — Transmission Direct P2P if ICE found a working path. Relay via TURN otherwise. Most corporate/mobile connections fall back to relay.

Protocol stack

Protocol Layer What it does
SDP Signaling Session description - codecs, media types, crypto params
ICE Transport Path discovery, candidate testing, route selection
STUN Transport NAT mapping discovery - "what is my public address?"
TURN Transport Relay server when direct P2P fails
DTLS Security Encryption handshake over UDP
SRTP Media Encrypted audio/video transport
SCTP Data Data channel transport, runs over DTLS

Tradeoffs

Strengths
  • -Sub-100ms latency on good P2P paths
  • -Encryption is mandatory, not optional
  • -Ships in every browser - no plugin
  • -Carries both media and arbitrary data
Watch out for
  • -Signaling + NAT setup complexity is non-trivial
  • -TURN bandwidth costs scale with load
  • -Not always truly P2P - TURN relay is common
  • -Debugging ICE failures is painful

Key insight: Despite the "peer-to-peer" marketing, many real-world WebRTC connections route through TURN relays - particularly on mobile networks and in corporate environments with strict NAT or firewalls. Plan for your TURN server to carry a meaningful fraction of your traffic.