WebRTC — Peer-to-Peer Real-Time Media and Data
WebRTC is a free, open framework for real-time voice, video, and data communication between browsers, mobile apps, and IoT devices — often directly peer-to-peer, without routing media through a server. It bundles a media engine (codecs, echo cancellation, jitter buffers), a secure transport (DTLS over SRTP), and a NAT-traversal toolkit (ICE, STUN, TURN) into one browser-native API. It is the technology behind Google Meet, Zoom's web client, Discord voice, and every in-browser video call.
How it works
WebRTC's design goal is brutal: sub-second, often sub-150ms, bidirectional media between two browsers across the open internet, ideally without paying for a media server. To do this it bundles four distinct subsystems:
1. Media engine. Captures audio/video from the device, encodes it (Opus, VP8/VP9, H.264, AV1), applies echo cancellation, noise suppression, and automatic gain control on audio, and tunes the bitrate to network conditions. The browser ships a full media pipeline — this is why WebRTC is 'heavy' to enable.
2. Secure transport. Audio and video go over SRTP (Secure RTP); data channels go over SCTP over DTLS. DTLS is TLS-over-UDP — same crypto, different transport. Every WebRTC connection is encrypted end-to-end by default.
3. NAT traversal. Most peers are behind NATs and firewalls; they cannot directly address each other. ICE (Interactive Connectivity Establishment) uses STUN servers to discover public addresses and NAT types, and falls back to TURN servers (relay) when direct connection fails. This is the hardest part to get right in production.
4. Peer connection API. The browser exposes RTCPeerConnection — the orchestration layer that ties signaling, ICE, media, and transport together. The application creates a peer connection, adds media tracks, exchanges SDP offers/answers over a signaling channel, and the API handles the rest.
A surprising fact about WebRTC: the spec does not define signaling. The peers need to exchange two pieces of information before media can flow — an SDP offer/answer (describing codecs, formats, encryption keys) and a set of ICE candidates (network paths). WebRTC leaves it to the application to transport these. Almost always, this means WebSocket or HTTP to a signaling server, which relays messages between the two browsers.
This design choice is deliberate: it keeps WebRTC flexible. You can use any signaling protocol — your own WebSocket server, a third-party service like PubNub, even copy-paste SDP between two laptops for debugging. The signaling server is only needed during setup; once the peer connection is established, media flows directly between browsers and the signaling server can step away.
SDP (Session Description Protocol) is a text format describing the session: which codecs the browser supports, the encryption fingerprint, the media types. It looks like line noise — a=rtpmap:111 opus/48000/2 means payload type 111 is Opus at 48000Hz stereo. Most developers never read SDP directly; the browser parses it. But knowing it exists (and that WebRTC's setLocalDescription and setRemoteDescription consume it) is essential when debugging.
The hard problem WebRTC solves is NAT traversal. Two browsers on home Wi-Fi cannot address each other directly — their private IPs (192.168.x.x) are not routable. ICE (Interactive Connectivity Establishment) is the algorithm that finds a path between them.
ICE tries three classes of candidates, in order:
1. Host candidates. The browser's local network interfaces. Direct LAN connection works only if both peers are on the same network (rare in production).
2. Server-reflexive (srflx) candidates, via STUN. The browser sends a request to a public STUN server; the server replies with the source IP and port it observed. That is the browser's public address as seen through its NAT. ICE then tries connecting from each peer's srflx address. This works for many NAT types (full-cone, restricted-cone) but fails for symmetric NATs (where the source port differs per destination, so the STUN-discovered port is not the one the peer will see).
3. Relay candidates, via TURN. If direct connection fails, the browser allocates a relay on a TURN server. Media is sent from Browser A to the TURN server to Browser B. The TURN server is essentially a media relay — always works, but it costs bandwidth and adds latency. TURN is the fallback that makes WebRTC 'just work' on hostile networks.
In production, you need both STUN (cheap, public servers exist like Google's stun.l.google.com) and TURN (expensive, you operate your own, authenticates clients with short-lived credentials). A common production metric is the TURN relay percentage: if 80% of connections are TURN-relayed, your users are paying for bandwidth on both ends. Reducing this through better STUN, IPv6, or different NATs is a real engineering goal.
Pure peer-to-peer WebRTC works for 1-to-1 calls. For N participants (group video), peer-to-peer-mesh becomes O(N²) connections and O(N²) uplink bandwidth from each client — a 10-person call means each participant uploads 10 video streams. This does not scale.
The production architectures for group calls:
-
Mesh: every peer connects to every other. Works for ~4 participants. No server media cost; each client does N encodes.
-
SFU (Selective Forwarding Unit): each participant uploads one encoded stream to the SFU; the SFU forwards selected streams to each participant. Each client uploads 1 stream (cheap) and downloads N-1 (the others). This is what Google Meet, Jitsi, and most group calls use.
-
MCU (Multipoint Control Unit): the server decodes, composites, and re-encodes one stream per participant. CPU-intensive on the server, but cheapest for the clients. Used in older systems and some legacy enterprise conferencing.
The SFU is the modern sweet spot: server-side forwarding is cheap (no decode/encode), clients only upload once, and the SFU can selectively forward (send only the active speaker's video, or low-resolution for non-speakers — 'simulcast'). Simulcast is the trick that makes 30-person calls work: each client sends 3 resolutions, the SFU forwards high-res to visible tiles and low-res to hidden ones.
WebRTC's congestion control adapts the bitrate to the network in real time using GCC (Google Congestion Control) — a congestion control algorithm designed for media, not bulk transfer. If the network degrades, the encoder drops resolution or framerate to keep latency under control. This is why video calls 'get blurry' instead of 'lagging' when your network is bad.
WebRTC is not only for voice/video. RTCDataChannel provides a reliable (or unreliable) ordered (or unordered) message channel over SCTP/DTLS, with the same NAT-traversal benefits. Use cases: in-browser multiplayer games, low-latency file transfer, collaborative editing, P2P file sharing (WebTorrent). Data channels are an underrated feature — they give browsers a true low-latency peer-to-peer messaging path that WebSocket (which goes through a server) cannot match.
Two browsers want to establish a WebRTC connection. Why can they not simply open a TCP connection to each other, like a normal client-server request?
Pick one answer.
You are building a 20-person video conferencing app. Which media architecture is most appropriate, and why?
Pick one answer.
A WebRTC call is established via TURN relay. What does that mean, and what are the implications?
Pick one answer.
Engineering mental model
Mental model. Think of WebRTC — Peer-to-Peer Real-Time Media and Data as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does WebRTC — Peer-to-Peer Real-Time Media and Data mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing WebRTC — Peer-to-Peer Real-Time Media and Data, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = webrtc(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: WebRTC — Peer-to-Peer Real-Time Media and Data
Change the variables below and predict what breaks first in WebRTC — Peer-to-Peer Real-Time Media and Data. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on WebRTC — Peer-to-Peer Real-Time Media and Data, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using WebRTC — Peer-to-Peer Real-Time Media and Data. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using WebRTC — Peer-to-Peer Real-Time Media and Data?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses WebRTC — Peer-to-Peer Real-Time Media and Data, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose WebRTC — Peer-to-Peer Real-Time Media and Data, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for WebRTC - Peer-to-Peer Real-Time Media and Data: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using WebRTC - Peer-to-Peer Real-Time Media and Data. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +Peer-to-peer media — no media server cost for 1-to-1 calls.
- +Sub-second latency, designed for real-time voice and video.
- +Browser-native — no plugin or app install required.
- +End-to-end encrypted by default (DTLS/SRTP).
- +Data channels give browsers a low-latency P2P messaging path beyond media.
- +Adaptive bitrate and congestion control keep calls usable on flaky networks.
- −Extremely complex API surface — signaling, ICE, SDP, codecs, simulcast.
- −NAT traversal is unreliable without TURN — which costs bandwidth.
- −Scales poorly beyond 1-to-1 without an SFU — which adds server cost.
- −Browser implementations vary subtly; cross-browser debugging is painful.
- −Codec support differs by browser (Safari vs Chrome vs Firefox — especially VP9, AV1).
- −TURN bandwidth and SFU compute are real operational costs at scale.
How this breaks in production
- TURN relay percentage too high — users on carrier-grade NATs cannot connect directly; bandwidth bill spikes.
- Symmetric NAT blocks STUN-discovered candidates; only TURN works.
- Signaling server is a single point of failure — if it is down, no new calls can be set up.
- SFU overloaded on large calls — CPU saturates, frames drop, calls degrade.
- Codec mismatch — one browser supports only H.264, another only VP8; transcoding is required or call fails.
- Network jitter exceeds jitter buffer — audio glitching, video freezing.
Don't fall into these traps
- •Treating signaling as part of WebRTC — it is not; you must build it (usually WebSocket).
- •Skipping TURN — 'most users have STUN-friendly NATs' is true until your enterprise customer's firewall blocks everything.
- •Using mesh topology for group calls — does not scale past ~4 participants.
- •Forgetting to negotiate ICE candidates after the offer/answer — 'trickle ICE' avoids blocking but is easy to skip.
- •Assuming video is video — codec, simulcast, and resolution negotiation are real and per-browser.
- •Forgetting to keep the signaling channel alive during the call — needed for renegotiation (adding a participant, muting).
- •Not monitoring TURN bandwidth — a silent cost driver.
Real systems using this
How real systems implement this
- Google Meet — Browser-native video conferencing using WebRTC with a Google-operated SFU backend. Uses simulcast to scale to 100+ participant calls; adaptive bitrate via GCC keeps calls usable on flaky networks.
- Jitsi Meet — Open-source WebRTC video conferencing with a custom SFU (Jitsi Videobridge). Powers many self-hosted deployments and was the basis for 8x8's commercial service.
- Discord voice — Originally built on WebRTC for browser and desktop clients. Uses Opus audio codec with adaptive bitrate and a custom SFU for group voice channels.
Practice saying it out loud
- Q1Walk through how two browsers establish a WebRTC peer connection. What is signaling, and why is it not part of the spec?
- Q2Explain STUN, TURN, and ICE. When does each one kick in?
- Q3You are building a 50-person video conferencing app. What media architecture do you use, and why?
- Q4Your users on corporate Wi-Fi cannot establish calls — they all hit TURN relay. What is happening, and what are your options?
- Q5WebRTC is encrypted by default. Walk through how DTLS/SRTP provides that, and what the threat model is.
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
WebSockets — Full-Duplex Real-Time Over TCP