Peer
Pressure

Your browser can place an encrypted video call to another browser — no app, no plugin, and no server sitting in the middle of the media. That machine is called WebRTC, and it is one of the strangest, most over-engineered, most interesting pieces of the web platform. This doc rebuilds it from first principles: first the problem, then the predecessors, then every individual part, then the whole machine assembled.

"Real-time" sounds like a vibe. It's actually a number, and the number comes from human conversation. Telephone engineers measured this decades ago (it's codified in ITU-T G.114): when mouth-to-ear delay — the time from sound leaving my mouth to reaching your ear — stays under roughly 150 ms one way, conversation feels natural. Past ~250 ms, people start accidentally talking over each other. Past ~400 ms, turn-taking collapses and you're on a walkie-talkie.

Here's the part that makes it hard: the network is only one slice of that budget. Capturing audio, compressing it, buffering against jitter, decompressing, and playing it out all spend milliseconds before a single packet touches a wire. Drag the network slider and watch how little room there actually is.

In 2011 the hacks were finally retired by an actual protocol. A WebSocket starts life as a normal HTTP request with a magic header — Upgrade: websocket — and if the server agrees (101 Switching Protocols), the two sides stop speaking HTTP entirely. The underlying TCP connection stays open, and both ends may now send frames — small binary or text messages — at any time, in either direction.

Everything the hacks bled for comes free. Server speaks first? Yes — it's a raw pipe. Overhead? A frame header is 2–14 bytes, versus ~700 bytes of HTTP headers per polled message. Lag? One network traversal, no request cycle. Chat, multiplayer lobbies, live dashboards, collaborative editors — from 2011 on, these are simply solved problems, and WebSockets remain the right tool for them today.

TCP's reliability machine is beautiful: every byte is numbered, the receiver acknowledges what it has, the sender retransmits what's missing. But the promise it makes to your application is precise and merciless: you receive bytes in order, or you receive nothing. There is no API to say "give me what you've got." Step through what that means when one packet — just one — dies while five friends travel behind it:

The same 10 seconds of voice — 500 frames, 20 ms each — sent over both transports through the same lossy network. Set the packet loss and the round-trip time, and compare what actually reaches your ear. On the UDP row, a lost frame is a pink blip the decoder papers over. On the TCP row, every loss inserts a black stall (≈ RTT + one frame to detect and repair) — and pushes everything after it further behind live.

A NAT is not magic — it's a table and a pen. For every outbound packet it picks a free public port, writes a row mapping inside address:port ⇄ public port, and rewrites the packet on the way through. Everything WebRTC fights in the next module falls out of three properties of that table. Watch one mapping live and die:

Now put a NAT on both ends — the normal case — and feel the deadlock. Alice can't send to Bob: Bob's mapping doesn't exist (mappings are born on outbound), and even if it did, she doesn't know its public port. Bob is in exactly the same trap. Each side is waiting for the other to become reachable first. It's module 1's "servers can't speak first" problem again — except now nobody can speak first.

The escape is a genuinely beautiful trick, and module 4 builds it properly — but here's the shape. A third machine both peers can reach tells each one the other's public ip:port guess. Then both fire packets at each other at the same time. Each NAT sees its own side's outbound packet first — row written, filter satisfied — so when the other side's packet arrives moments later, it finds a warm mapping and walks straight in. Both doormen think their own resident invited the guest. That's hole punching: it works on cone NATs, and dies on symmetric ones — which is why a relay (TURN) must always be standing by.

Module 3 promised that when hole punching fails — symmetric NATs, hostile firewalls, UDP blocked outright — there must be a relay standing by. TURN (Traversal Using Relays around NAT) is that relay, formalized: you authenticate to a TURN server and it allocates you a public address on itself. Anything your peer sends to that address, the server forwards down your already-open outbound connection — the one thing every NAT permits.

Wait — isn't this exactly module 1's "relay tax," the wall we built WebRTC to avoid? Yes, and the difference is the terms. The relay is no longer the architecture; it's the last resort, used only when the tournament proves nothing direct works. It carries one call's media, not every call's. You choose where it runs (close to users, not wherever your web server lives). And unlike STUN's one-packet favor, TURN moves your actual media — which is why it's the expensive line in every WebRTC infra bill, why it requires credentials, and why providers meter it per gigabyte.

Both sides now hold two candidate lists — their own and their peer's (traded through the mutual friend module 5 will finally introduce). ICE crosses them into candidate pairs, sorts by priority, and then does the beautifully dumb thing: tries them all. Each "try" is a STUN binding request fired directly at the peer — and here's the payoff of module 3: because both sides run checks at once, the checks themselves are the simultaneous sends. The probe is the hole punch. Pick a scenario:

Details worth keeping: checks are authenticated (each side's SDP carries a username fragment and password, so a stranger can't hijack the race). A check arriving from an address you'd never heard of births a peer-reflexive candidate mid-tournament — sometimes rescuing NATs the theory said were hopeless. The winning pair gets nominated by the controlling side and becomes the path; the others are abandoned. And the tournament never really ends — keepalives guard the path, and if it dies mid-call, an ICE restart runs the whole race again without dropping the session.

What travels over signaling is a Session Description — everything the other side needs to receive your media: codec menu, ICE credentials, candidates, crypto fingerprint. The format, SDP, is a line-oriented text relic of the mid-90s multicast era that WebRTC inherited from the telephony world — ugly, ancient, and carrying the entire handshake. When you call createOffer(), this is what comes out. Click any line:

Notice the pattern in the annotations: the ICE credentials are module 4's tournament passwords, the fingerprint is module 6's anchor, the FEC knob is module 8 waving hello, and the addresses are deliberately useless because the candidates carry the truth. SDP isn't a config file — it's the rendezvous document where every part of WebRTC files its paperwork.

DTLS (Datagram TLS) is not a new protocol — it's TLS with storm shutters. Same cipher suites, same ECDHE key exchange (fresh keys per call: forward secrecy), same ClientHello → certificates → Finished choreography, with the roles assigned by module 5's a=setup line (the answerer usually goes active and dials as the client). What's new is exactly the set of patches UDP forces. Break TLS three ways and watch DTLS cope:

Cost of the whole ceremony: one or two round trips, once per connection — it runs the instant module 4 nominates a pair, before the first media packet. After that, DTLS mostly steps aside: media won't travel inside DTLS records at all. It gets something lighter.

Audio is the well-behaved half. Every 20 ms, the browser grabs 960 samples per channel from the mic and hands them to Opus — module 5's payload 111, the codec that ended the codec wars by being best at everything: speech at 6 kbps, stereo music at 510, switching modes mid-stream. It works the way all modern compression works — predict, then encode only the surprise. Speech is highly predictable (a vocal tract is a physical system), so 3,840 raw bytes of stereo audio routinely become ~80 bytes: one small packet, fifty times smaller, every 20 ms, forever.

• 1
  The frame is the atom. One 20 ms Opus frame per RTP packet, each decodable on its own — which is precisely what made module 2's "a loss costs exactly 20 ms" true, and what packet-loss concealment leans on to fake a missing frame from its neighbors.
• 2
  Silence is nearly free. DTX (discontinuous transmission) collapses the not-talking half of every conversation to a whisper of comfort-noise updates. Your call's audio bitrate breathes with the conversation.
• 3
  Each packet carries a spare of the last. Remember useinbandfec=1 from module 5's SDP? Every Opus packet can embed a low-fidelity copy of the previous frame — lose a packet and its successor partially resurrects it. Module 8 will call this FEC; Opus has it built into the codec itself.

Encoded frames now need packaging. UDP delivers anonymous datagrams — unordered, unlabeled, occasionally missing — and out of that hail the receiver must reconstruct media time: what plays when, what's late, what's gone. RTP (Real-time Transport Protocol) is a 12-byte header that carries exactly the facts needed and nothing else. Click every field:

On the receiving side these fields feed the jitter buffer — module 1's 40 ms line item, finally explained: packets arrive with uneven spacing, the buffer holds just enough of them to reorder by sequence number and release by timestamp, converting network chaos back into a steady 33 ms heartbeat. Too small and every hiccup glitches; too big and you've spent the latency budget. Module 8 makes that buffer adaptive — and builds the whole feedback loop that keeps the pipeline honest.

Module 1 charged 40 ms for the jitter buffer; module 7 showed its mechanics. The production version has one more trick: the 40 is not a constant. Packets arrive with uneven spacing — jitter — and the buffer's depth is a live bet on the next second's jitter. Buffer too little and every hiccup becomes a glitch; too much and you're mailing module 1's budget back. So the buffer tracks the recent arrival-spread and continuously re-sizes to cover roughly the 95th percentile — deepening the instant the network gets choppy, thinning quietly when calm returns.

The audio version (WebRTC's is a famous piece of engineering called NetEQ) hides the resizing itself: it time-stretches speech a few percent when it needs to grow the buffer and compresses when shrinking — no pitch shift, no dropped words, just conversation elastic enough that you never notice the network under it. Video needs no such subtlety: a frame can simply wait, or be late.

The oldest IOU in this course comes due. Module 2: "UDP has no congestion control — you must be polite yourself." But how do you even know your share of a link nobody advertises? TCP's answer is to push until packets drop. For media that's a catastrophe — queues fill before they overflow, so by the time loss appears, seconds of latency already have. WebRTC's congestion controller watches a better smoke alarm: delay. Every packet carries a transport-cc number (module 7), the receiver echoes arrival times (section 01), and the sender watches the trend — one-way delay creeping up means a queue is building somewhere. Back off before the queue fills; probe gently upward when it drains. Try to break it:

Watch what the estimate feeds: the number isn't advisory — it becomes the encoder's bitrate target within milliseconds. Video re-targets, drops resolution or framerate down a ladder, climbs back when the estimate recovers. A pacer smooths module 7's keyframe spikes so one big frame doesn't read as a fake congestion event. And loss isn't ignored — sustained heavy loss still triggers a hard back-off; delay is just the early signal. This loop — measure, estimate, re-encode, repeat, forever — is the single biggest difference between a demo that works on office Wi-Fi and a call that survives a train ride.

Every data channel is created with two decisions — ordered: true|false and a reliability cap (maxRetransmits or maxPacketLifeTime; unset = fully reliable). That's the whole API surface of the transport bargain. And here's the exam question this course has been building toward: the default setting quietly rebuilds TCP — module 2's monster, back by opt-in. Watch the same nine messages, with message 4 lost in transit, under three settings:

One subtlety in the reliability caps: maxRetransmits caps effort ("try twice, then move on") while maxPacketLifeTime caps time ("useless after 150 ms, stop sending it") — the second is exactly the shape of live state, where the deadline, not the attempt count, is what defines worthless. And because SCTP is multi-streamed, these choices are per channel: your reliable file channel stalling on a loss does not block your unreliable game-state channel riding the same connection.

Call setup isn't a sequence — it's three overlapping progressions, each with its own state property and its own change event: signalingState (module 5's dance), iceGatheringState (module 4's candidate hunt), and connectionState (the rollup of ICE checks + DTLS). Most WebRTC confusion is reading one machine's state and expecting another machine's behavior. Step through a real setup:

Three answers to "who makes the copies", from no-server to all-server. Drag the room size and watch each architecture's bill:

The loopback above cheats exactly once: its "signaling" is two variables in the same page. The real app replaces that with module 5's mutual friend — and that's the only difference. Here is a complete two-browser video call. File one, the entire signaling server — a dumb forwarder with rooms:

import { WebSocketServer } from "ws";
const wss = new WebSocketServer({ port: 8443 });
const rooms = new Map();

wss.on("connection", ws => {
  ws.on("message", data => {
    const msg = JSON.parse(data);
    if (msg.join) {
      ws.room = msg.join;
      const peers = rooms.get(ws.room) ?? [];
      ws.polite = peers.length > 0;          // second to arrive = polite (module 5's glare fix)
      peers.push(ws); rooms.set(ws.room, peers);
      ws.send(JSON.stringify({ polite: ws.polite }));
      return;
    }
    for (const peer of rooms.get(ws.room) ?? [])
      if (peer !== ws && peer.readyState === 1) peer.send(data);
  });
});

const ws = new WebSocket("wss://your.host:8443");
const pc = new RTCPeerConnection({ iceServers: [
  { urls: "stun:stun.l.google.com:19302" },
  { urls: "turns:turn.your.host:443", username: U, credential: C }]});
let polite = false, makingOffer = false;

ws.onopen = () => ws.send(JSON.stringify({ join: location.hash || "room1" }));
const send = obj => ws.send(JSON.stringify(obj));

const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
document.querySelector("#me").srcObject = stream;
stream.getTracks().forEach(t => pc.addTrack(t, stream));

pc.ontrack = e => document.querySelector("#them").srcObject = e.streams[0];
pc.onicecandidate = e => e.candidate && send({ candidate: e.candidate });
pc.onnegotiationneeded = async () => {           // fires when tracks/channels change
  makingOffer = true;
  await pc.setLocalDescription();                 // no-arg: makes the right offer
  send({ description: pc.localDescription });
  makingOffer = false;
};
pc.onconnectionstatechange = () =>
  pc.connectionState === "failed" && pc.restartIce();

ws.onmessage = async ({ data }) => {
  const msg = JSON.parse(data);
  if (msg.polite !== undefined) { polite = msg.polite; return; }
  if (msg.description) {
    const clash = msg.description.type === "offer" &&
                  (makingOffer || pc.signalingState !== "stable");
    if (clash && !polite) return;                 // impolite: ignore the collision
    await pc.setRemoteDescription(msg.description);  // polite: rollback is automatic
    if (msg.description.type === "offer") {
      await pc.setLocalDescription();             // no-arg: makes the answer
      send({ description: pc.localDescription });
    }
  }
  if (msg.candidate) await pc.addIceCandidate(msg.candidate);
};