WebRTC: True Peer-to-Peer Media in the Browser

WebRTC is the only protocol that lets video and audio travel directly between two browsers without passing through a server. That is why Google Meet, Discord, and Zoom on the web have low latency, and it is also why WebRTC is genuinely complex.

What it is

WebRTC, standardized by the W3C and IETF and originally initiated by Google, enables real-time peer-to-peer communication between browsers. Media and data flow directly between two peers rather than through a central server, which reduces both latency and server bandwidth costs. It consists of three main components: a media engine that handles audio and video codecs, echo cancellation, and noise suppression; a transport layer using SRTP and DTLS for encrypted media; and a data channel using SCTP for binary peer-to-peer messaging.

Think of WebRTC like a FaceTime call. You need a server to set up the call the first time, but once the connection is established, audio and video travel directly between the two devices. The server steps out of the way. The browser supports it natively, with no plugin required.

Why it matters

• Peer-to-peer delivery reduces latency and server bandwidth, since media does not round-trip through a central server.
• The media engine is built in: Opus for audio, VP8/VP9/H.264 for video, plus echo cancellation, noise suppression, and automatic gain control.
• The data channel allows binary peer-to-peer messaging for file transfer or game state sync, with no server in the middle.
• It is browser-native, so there is no plugin or special client to install.
• It is the foundation of every modern web video call platform.

How it works

WebRTC does not define signaling. You choose your own mechanism, usually WebSocket, to exchange session descriptions. Two browsers trade SDP offers and answers, which describe codecs and media capabilities, through a signaling server. Once that exchange is complete, the signaling server is no longer needed.

The hard part is NAT traversal. Most browsers sit behind NAT routers and do not know each other's public IP. ICE gathers candidate addresses, STUN servers reveal the public IP, and if a symmetric NAT blocks direct connection, a TURN server relays the media. So WebRTC is not always purely peer-to-peer; when direct connection fails, TURN acts as a fallback relay. After connection, the media engine handles the rest: encoding, decoding, echo cancellation, noise suppression, and codec negotiation, all built into the browser.

Caveats

WebRTC requires a signaling server outside the protocol itself, so you build and maintain that piece. NAT traversal needs STUN and often TURN, which means running a TURN server and paying for its bandwidth. The stack is complex: ICE, DTLS, SRTP, and SCTP are all in play, making WebRTC significantly harder to implement than WebSocket. It is also not suited for broadcasting to many viewers, where HLS or WHIP-based ingest is more appropriate.