WebRTC Fundamentals — Core Vocabulary

WebRTC is P2P for media but requires server infrastructure for signaling, STUN, and TURN — "no servers needed" is a common misconception.

The three server components: (1) Signaling server — a WebSocket server your application provides to relay SDP offers/answers and ICE candidates between peers before the P2P connection exists. WebRTC deliberately doesn't specify the signaling protocol — you build it. (2) STUN server — a stateless service peers query to discover their public IP/port (e.g., Google's stun.l.google.com:19302). Required for NAT traversal in most networks. (3) TURN server — a relay server that forwards media when direct P2P is blocked by symmetric NAT (corporate firewalls, carrier-grade NAT). TURN is expensive: all media flows through it. Good news: TURN is only needed for ~20-30% of connections in typical deployments.

Key vocabulary:
• signaling server — application-provided WebSocket server relaying SDP and ICE candidates between peers before P2P is established
• STUN server — discovers public IP/port; stateless; needed for NAT traversal
• TURN server (relay) — forwards media when direct P2P is impossible; required for symmetric NAT

ICE collects all possible network paths (host, server-reflexive, relay) and systematically tests them to find the best working pair.

The three candidate types serve different scenarios: host candidates work when both peers are on the same LAN (office or home network). Server-reflexive candidates (public IP from STUN) work when both peers are behind NAT but the NAT types are compatible (most home routers). Relay candidates (TURN) are the last resort when both peers are behind symmetric NAT that prevents direct connections. ICE connectivity checks test every candidate pair combination — source A's host → destination B's host, source A's reflexive → B's host, etc. The highest-priority working pair is selected as the active candidate pair. This process is called the ICE check list.

Key vocabulary:
• host candidate — local network IP:port; works for same-LAN connections
• server-reflexive candidate — public IP:port discovered via STUN; works for most NAT scenarios
• relay candidate — TURN server address; fallback when direct P2P is blocked by symmetric NAT

Symmetric NAT is the #1 cause of WebRTC connection failures in enterprise environments — TURN relay is required, and TURN itself may need to be configured for TCP port 443 to pass through firewalls.

Symmetric NAT assigns a unique external IP:port combination for each remote destination. STUN discovers the external port for the STUN server connection — but when the browser tries to connect to the remote peer using that port, the NAT assigns a different port for the peer's IP. The remote peer's ICE connectivity check fails. Solution: TURN relay. But corporate firewalls often block UDP entirely. TURN servers should be configured to listen on TCP port 443 (same as HTTPS) so traffic passes through corporate HTTP proxies. This is why enterprise-ready WebRTC deployments must run TURN on port 443 TCP.

Key vocabulary:
• symmetric NAT — NAT assigns a unique external port per (source IP, source port, destination IP, destination port) tuple; defeats STUN hole punching
• hole punching — technique where both peers send packets simultaneously to create NAT mappings; fails with symmetric NAT
• TURN on TCP 443 — TURN configured to use the HTTPS port so traffic passes through corporate firewalls

SDP offer/answer is a capability negotiation — peers exchange what they can send/receive and agree on codecs, encryption parameters, and ICE credentials.

The SDP offer contains: media sections (audio, video, data channel) each with supported codecs and their parameters, ICE credentials (username/password for connectivity checks), DTLS fingerprint (certificate hash for secure key exchange), and RTP/RTCP port information. The remote peer's answer accepts compatible codecs and provides its own ICE credentials and DTLS fingerprint. The offer/answer model is an IETF standard (RFC 3264) that WebRTC builds on. After both setLocalDescription and setRemoteDescription are called, ICE gathering begins and candidates are exchanged via the signaling channel in parallel.

Key vocabulary:
• SDP (Session Description Protocol) — text format describing media capabilities, ICE credentials, and DTLS fingerprint
• setLocalDescription — stores own SDP and starts ICE gathering
• setRemoteDescription — stores the peer's SDP; triggers ICE connectivity checks with newly gathered candidates

TURN is expensive because it handles the full media stream — not just a small signaling message — so every TURN-relayed call consumes bandwidth proportional to audio/video bitrate times duration.

Cost calculation example: a 30-minute HD video call at 2Mbps through TURN = 450MB of relay traffic. At 1000 such calls per day = 450GB/day. At $0.10/GB bandwidth, that's $45/day just for TURN. Compare to STUN: the entire STUN exchange for a call is a few hundred bytes. Target metrics for a healthy WebRTC deployment: relay (TURN) candidate type should be under 20-30% of all calls. Above 50% indicates network configuration problems. Monitoring: log the selected candidate pair type (host/srflx/relay) for every call — srflx and host are essentially free; relay is the cost driver.

Key vocabulary:
• relay candidate — TURN-based candidate; all media flows through the TURN server; expensive at scale
• srflx candidate — server-reflexive; discovered via STUN; free (STUN is stateless)
• ICE candidate type breakdown — metric showing what percentage of calls use host/srflx/relay paths; key infrastructure health indicator