Connecting

Before any audio, video, or data moves, two browsers have to find each other and agree on a path. Neither one knows the other's address. Both sit behind routers that drop unexpected incoming traffic. Connecting is the work of crossing that gap.

WebRTC splits the job in two. Signaling exchanges the metadata needed to start. ICE finds a route that survives the network in between.

What it enables

A direct, encrypted link between two peers with no media server in the middle. Once the link is open, latency stays low because packets take the shortest path available. The application server, if there is one, only helps with introductions. It never sees the traffic.

This is the foundation every other use-case sits on. Calls, streaming, messaging, and file transfer all assume a connection already exists.

How it works (high level)

Each peer describes itself with an SDP document: codecs, transport details, and capabilities. WebRTC produces the document but does not deliver it. The application carries it across a signaling channel of its choosing, often a WebSocket, sometimes a URL or a copy-paste code.

One peer sends an offer. The other replies with an answer. This is the offer/answer exchange defined by JSEP.

In parallel, each peer gathers ICE candidates: the possible addresses it can be reached on. A host candidate is a local network address. A server-reflexive candidate is the public address a STUN server reports back. A relay candidate routes through a TURN server when nothing else works. The peers trade candidates, test them in pairs, and keep the first pair that connects.

Peer Abrowser Peer Bbrowser Signalingoffer / answer STUN / TURNnetwork discovery Direct P2P connection SETUP ONLY, NOT IN THE DATA PATH

NAT is the reason this is hard. Home and office routers translate private addresses to a shared public one and block traffic they did not request. STUN lets a peer learn its own public address. TURN relays data when two NATs refuse to let a direct path form. Most connections succeed without a relay.

Where it's used

Every WebRTC application begins here. A video call connects two people. A multiplayer game connects players to a host. A file-sharing tool connects sender and receiver. The signaling transport and the candidate types vary, but the offer/answer and ICE steps stay the same.

This site connects two browser tabs to play games peer-to-peer, using STUN only and three swappable signaling modes.

Open the connecting deep dives