WebRTC

WebRTC (Web Real-Time Communication) is the browser's built-in stack for realtime audio, video, and peer-to-peer data. It's what powers Google Meet, Discord voice, WhatsApp calls, and every "join call" button on the web — low-latency media without plugins, straight from navigator.mediaDevices to an encrypted peer connection.

Unlike WebSockets (a client↔server pipe over TCP), WebRTC establishes direct peer-to-peer connections over UDP, optimized for media: sub-second latency, packet-loss tolerance, and mandatory encryption. The price is the most involved connection setup in web development — signaling, NAT traversal, and topology decisions.

TL;DR

Quick Example

The core browser API — capture media, create a connection, exchange session descriptions:

The WebRTC API handles media; you handle delivering those messages between peers — that's signaling.

Core Concepts

Signaling

Two peers must exchange, before any media flows:

WebRTC deliberately doesn't specify how — any channel works, but in practice it's a WebSocket server (or a platform's SDK doing it for you). The signaling server is lightweight: it introduces peers; media does not flow through it.

ICE, STUN, and TURN — NAT Traversal

Most devices sit behind NAT and can't be dialed directly. ICE (Interactive Connectivity Establishment) tries every path and picks the best:

⚠️ Symmetric NATs and strict corporate firewalls defeat STUN — 10–20% of real-world connections need TURN. An app tested only on your office Wi-Fi will mysteriously fail for those users. Deploy coturn or use a managed TURN service, always.

Media Transport

Media rides SRTP over UDP: losing a packet means a momentary glitch, not a TCP-style stall — the right trade for realtime. The stack continuously adapts bitrate to congestion, and codecs (Opus for audio; VP8/VP9/H.264/AV1 for video) are negotiated in the SDP. Encryption (DTLS-SRTP) is mandatory — there is no unencrypted WebRTC.

Data Channels

RTCDataChannel sends arbitrary data peer-to-peer with configurable reliability:

Use cases: multiplayer game state, P2P file transfer, collaborative-editor sync, low-latency IoT control — anywhere a server round-trip is wasted motion.

Scaling Beyond Two Peers

Peer-to-peer meshes explode combinatorially — each participant uploads to every other:

The SFU is the industry answer: clients send one stream up (often as simulcast — multiple quality layers), and the SFU forwards the right layer to each receiver based on their bandwidth and layout. Open-source SFUs: LiveKit, mediasoup, Janus, Jitsi.

Build vs Buy

Raw WebRTC is famously fiddly: signaling, TURN operations, SFU scaling, mobile quirks, and reconnection logic. The pragmatic ladder:

  1. Managed platforms — LiveKit Cloud, Daily, Twilio Video, Agora: SDKs + global infrastructure; you write UI. Right answer for most products.
  2. Self-hosted SFU — LiveKit/mediasoup on your infra when data control or cost-at-scale demands it.
  3. Raw RTCPeerConnection — 1:1 calls, data channels, and learning. Entirely feasible for two-party apps.

Adjacent tech worth knowing: WHIP/WHEP standardize WebRTC-based broadcast ingest/playback (sub-second live streaming), and WebTransport offers UDP-like client↔server transport where you don't need P2P.

Common Mistakes

Shipping Without TURN

Works in the demo, fails for every user behind a symmetric NAT. TURN isn't optional in production — budget for its bandwidth.

Treating Signaling as an Afterthought

Reconnection, renegotiation (screen share added mid-call), and "glare" (both peers offering simultaneously — the "perfect negotiation" pattern handles it) all live in your signaling logic. This is where most homegrown WebRTC apps rot.

Using WebRTC Where WebSockets Suffice

Chat messages, notifications, and dashboards don't need P2P, NAT traversal, or UDP. If it's client↔server and latency tolerance is >100 ms, WebSockets (or SSE) are radically simpler.

Mesh Topology for Group Calls

Five participants × 4 outgoing streams each saturates home upload links. Group calling means an SFU — plan for it from the start.

Forgetting Permissions UX

getUserMedia requires HTTPS and a user-granted permission prompt; denial and device-missing paths need real handling, not console errors.

FAQ

WebRTC or WebSockets?

Different jobs: WebSockets = client↔server messages over TCP (chat, live updates); WebRTC = peer-to-peer media/data over UDP (calls, screen share, game state). Most WebRTC apps use both — WebSocket for signaling, WebRTC for media.

Is WebRTC secure?

Encryption is mandatory (DTLS for data, SRTP for media) and peers verify each other via fingerprints exchanged in signaling — so secure your signaling channel with TLS and authentication. Note that a standard SFU decrypts and re-encrypts media; true end-to-end encryption in group calls requires insertable frames (as Signal does).

Why does my call connect on Wi-Fi but not on corporate networks?

Strict firewalls block UDP entirely. TURN over TCP/TLS on port 443 is the escape hatch — traffic looks like HTTPS. This is a configuration you must enable on your TURN server.

Can I use WebRTC outside the browser?

Yes — native SDKs (libwebrtc), Pion (Go), aiortc (Python), and mobile SDKs speak the same protocol. IoT devices, servers, and phones interoperate with browsers directly.

How does Zoom relate to WebRTC?

Zoom's native clients historically used a proprietary stack (its web client uses WebRTC tech); Google Meet, Teams (web), Discord, and most newer platforms are WebRTC through and through. For anything you build in a browser, WebRTC is effectively the only option.

Related Topics

References