How WebRTC finds a path between peers
Before media can flow, WebRTC’s ICE (Interactive Connectivity Establishment) agent gathers every address at which each peer might be reachable, called candidates, then probes pairs of them to pick the best working route. This reference explains the four candidate types, the SDP attribute that encodes them, and how each fits into NAT traversal — plus a parser for any candidate line.
How it works
Each candidate is encoded as a single SDP attribute line:
a=candidate:842163049 1 udp 1677729535 203.0.113.5 54123 typ srflx raddr 192.168.1.7 rport 54123
The fields are foundation, component (1 = RTP, 2 = RTCP), transport,
priority, connection address, port, the keyword typ, and the candidate type.
Server-reflexive and relayed candidates also carry raddr/rport pointing back
at the base host candidate. ICE assigns each pair a priority and runs STUN
connectivity checks, preferring direct host and srflx paths and only falling
back to a TURN relay when symmetric NATs or firewalls block everything else.
Tips and notes
- Host candidates win when peers share a network; browsers now mask the LAN IP behind an mDNS
.localname. - A
srflxcandidate needs a STUN server; arelaycandidate needs a TURN server with credentials. - Peer-reflexive candidates appear only during the handshake and are never signalled ahead of time.
- Always provide a TURN server for reliability — a meaningful share of real-world calls cannot establish a direct path.