WebRTC — Peer-to-Peer

How It Works

WebRTC is the most complex protocol stack in web development. It is not one protocol — it is an orchestra of protocols working together to establish a direct, encrypted, real-time media connection between two browsers. Understanding the full lifecycle is essential before trying to build anything with it.

The Connection Lifecycle

Every WebRTC connection goes through five phases:

Phase 1: Signaling (Application Responsibility)

WebRTC deliberately does not define how peers discover each other. A signaling mechanism — typically a WebSocket server — is needed to exchange two pieces of information:

• SDP (Session Description Protocol): Describes what each peer can send/receive — codecs, media types, encryption fingerprints. Peer A creates an "offer," Peer B responds with an "answer."
• ICE Candidates: Network addresses (IP:port pairs) where each peer can be reached.

// Peer A: Create offer
const peerConnection = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    { urls: 'turn:turn.example.com', username: 'user', credential: 'pass' }
  ]
});

const offer = await peerConnection.createOffer();
await peerConnection.setLocalDescription(offer);

// Send offer to Peer B via the signaling server
signalingServer.send({ type: 'offer', sdp: offer });

Phase 2: ICE Candidate Gathering

Once the local description is set, the browser starts discovering its own network addresses:

• Host candidates: Local IP addresses (192.168.1.x) — works when peers are on the same LAN.
• Server-reflexive candidates: Public IP:port as seen by a STUN server — works when at least one side has a permissive NAT.
• Relay candidates: Allocated address on a TURN server — always works, but adds latency and server cost.

peerConnection.onicecandidate = (event) => {
  if (event.candidate) {
    // Send each candidate to the remote peer via signaling
    signalingServer.send({ type: 'candidate', candidate: event.candidate });
  }
};

Phase 3: ICE Connectivity Checks

ICE pairs up local and remote candidates and tests connectivity by sending STUN binding requests. It tries all pairs in priority order — direct connections first, then STUN-derived, then TURN relay. The first pair that gets a response wins.

This is the magic of ICE: it tries every possible network path in parallel and picks the best one that actually works.

Phase 4: DTLS Handshake + SRTP Key Exchange

Once ICE finds a working path, DTLS (Datagram TLS) runs over that path to establish encryption keys. These keys are then used to encrypt media via SRTP (Secure Real-Time Protocol). This is not optional — WebRTC mandates encryption.

Phase 5: Media and Data Flow

Audio and video flow as SRTP packets directly between peers. Data channels use SCTP over DTLS for reliable or unreliable data delivery. The connection continuously monitors quality and adapts — reducing video resolution if bandwidth drops, switching ICE candidates if the network path changes.

NAT Traversal: The Hard Part

The reason WebRTC needs STUN and TURN is that most devices sit behind NAT (Network Address Translation). A laptop's IP might be 192.168.1.50, but the internet sees the router's IP 203.0.113.10. For a direct connection, both peers need to know each other's public IP and port.

STUN solves the easy case. The browser sends a packet to a STUN server, which replies with the public address: "203.0.113.10:54321." Now the peer knows its public-facing address and can share it with the other peer.

This works for most NAT types (full cone, restricted cone, port-restricted cone). But symmetric NATs assign a different external port for every destination. The port STUN discovers is only valid for talking to the STUN server, not the peer. About 20% of connections hit this problem.

TURN solves the hard case. The TURN server allocates a public address and relays all traffic. Both peers talk to the TURN server, which forwards packets between them. It always works, but every byte of media flows through the relay server — which is expensive.

Without TURN (80% of cases):
Peer A ←——direct P2P——→ Peer B

With TURN (20% of cases):
Peer A ←——→ TURN Server ←——→ Peer B

This is why TURN infrastructure is critical for production WebRTC. Skipping it means 1 in 5 users cannot connect.

Scaling Beyond Two Peers

WebRTC's peer-to-peer model works beautifully for 1-to-1 calls. But group calls expose a fundamental scaling problem: full mesh topology.

In a 4-person call with full mesh, each participant maintains 3 peer connections, sending their audio+video to each. That is 3 upload streams per person. In a 10-person call, it is 9 upload streams. A typical laptop's CPU and upload bandwidth cannot handle this.

Three architectures solve this:

Mesh (2-4 participants)

Every peer connects to every other peer. Simple, but upload bandwidth scales as O(n-1).

SFU — Selective Forwarding Unit (4-50 participants)

Each participant sends one stream to a central server. The SFU selectively forwards streams to each participant based on who is speaking, screen layout, and bandwidth. This is what Google Meet, Zoom, and most production systems use.

Peer A ──video──→ SFU ──→ Peer B (forwarded)
Peer B ──video──→ SFU ──→ Peer A (forwarded)
Peer C ──video──→ SFU ──→ Peer A, Peer B (forwarded)

The SFU does not transcode — it just forwards packets. This keeps CPU usage low while centralizing the routing decision.

MCU — Multipoint Control Unit (legacy)

The MCU receives all streams, mixes them into a single composite stream, and sends that back. This uses massive server CPU but minimizes client bandwidth. Rarely used in modern systems — SFUs won.

Data Channels: The Hidden Gem

Most engineers associate WebRTC with video calls, but RTCDataChannel might be the more interesting API. It provides a direct, encrypted, peer-to-peer data pipe between browsers.

const dataChannel = peerConnection.createDataChannel('files', {
  ordered: true,      // Guarantee order (like TCP)
  // ordered: false,  // No ordering (like UDP, lower latency)
});

dataChannel.onopen = () => {
  dataChannel.send('Hello from peer A!');
  // Or send binary data
  dataChannel.send(fileArrayBuffer);
};

dataChannel.onmessage = (event) => {
  console.log('Received:', event.data);
};

Data channels support both reliable (ordered, retransmitted) and unreliable (unordered, no retransmit) modes. This makes them viable for:

• Peer-to-peer file transfer: ShareDrop, Snapdrop
• Multiplayer gaming: Low-latency game state sync
• Collaborative editing: Conflict-free replicated data types (CRDTs) synced directly between clients
• Decentralized applications: No server needed for data exchange

Production Considerations

Codec negotiation matters. VP8 is universally supported but aging. VP9 is better quality at lower bitrate. H.264 has hardware acceleration on most devices. AV1 is the future but adoption is still growing. The SDP configuration determines which codecs are offered and preferred.

Bandwidth estimation is automatic but imperfect. WebRTC's built-in congestion control (GCC — Google Congestion Control) adapts to available bandwidth, but it can be slow to ramp up and aggressive in ramping down. Monitor RTCStatsReport to track bitrate, packet loss, and jitter.

ICE restart is essential for mobile. When a phone switches from WiFi to cellular (or vice versa), the ICE candidates change. Without calling peerConnection.restartIce(), the connection dies. Detect network changes with the Navigator.connection API and trigger ICE restart proactively.

Firewall traversal in enterprise. Corporate firewalls often block UDP entirely. WebRTC can fall back to TURN over TCP (port 443), which looks like HTTPS traffic. Configure the TURN server to listen on 443/TCP as a last resort — it adds latency but gets through almost any firewall.

WebRTC is complex because real-time communication over the open internet is genuinely hard. But once the signaling → ICE → DTLS → media pipeline is understood, the complexity becomes manageable. Start with a 1-to-1 call, get that working end-to-end, then tackle group calls with an SFU.