WebRTC Explained: A Developer's Guide

WebRTC is a free, open-source technology that gives web browsers native real-time peer-to-peer audio, video, and data communication — no plugins required. This guide explains how WebRTC works, when to use it, and the architecture choices you face.

What is WebRTC?

WebRTC (Web Real-Time Communication) is a W3C/IETF standard — protocol and browser API — for real-time peer-to-peer audio, video, and arbitrary data. Supported in every modern browser (Chrome, Firefox, Safari, Edge) and on iOS/Android via native SDKs. It handles media capture, encoding, NAT traversal, and adaptive bitrate — the hard parts of real-time media — so you can build video calls in the browser.

How WebRTC works

WebRTC establishes a direct peer-to-peer connection in three steps: (1) signaling, (2) ICE candidate exchange, and (3) connection. The signaling step (using a signaling server over WebSocket — see "What is a Signaling Server") exchanges session descriptions (SDP). The ICE step discovers network paths (candidates) through which the peers can reach each other, using STUN and TURN servers. Once the peers select a working candidate, they connect and media flows directly between them.

The beauty of WebRTC is that after connection, audio/video packets do not touch your servers. The conversation flows directly between participants. This gives the lowest possible latency and keeps bandwidth costs near zero for the platform.

The key browser APIs

• getUserMedia — request camera/microphone access, returns a MediaStream
• RTCPeerConnection — the core object that manages the peer connection
• RTCDataChannel — bidirectional arbitrary-data channel between peers
• createOffer / createAnswer — generate SDP session descriptions
• setLocalDescription / setRemoteDescription — apply session descriptions
• addIceCandidate — add network-path candidates

NAT traversal: STUN and TURN

Most browsers sit behind NAT (home routers, corporate firewalls). To connect peers behind NAT, WebRTC uses STUN servers (which tell a peer its public IP address) and, when direct connection fails, TURN servers (which relay media). STUN is cheap and works for ~80% of connections; TURN is a relay (media passes through it) that handles the remaining ~20% but costs bandwidth. openbnet provides STUN/TURN support — you do not run them yourself.

Mesh vs SFU vs MCU

For group calls, there are three topologies: (1) Mesh — every peer connects to every other peer (low latency, but O(N²) connections, caps at ~10 participants). (2) SFU (Selective Forwarding Unit) — each peer sends one stream to a server that forwards to others (O(N) scaling, supports ~50 participants, adds a server hop). (3) MCU (Multipoint Control Unit) — server decodes, composites, and re-encodes one stream for each peer (scales to hundreds, but expensive and high latency). openbnet uses mesh for video calls (optimal for small groups) and bridge-tunnel for streaming.

All guides · Explore openbnet APIs · Developer quickstarts