ICE coordinates everything between "two peers want to talk" and "media is flowing". Each endpoint gathers candidate addresses — its local interface IPs, its STUN-reported public address, and a TURN-allocated relay address — and exchanges them with the other peer through a signalling channel (typically SDP offer/answer over WebSocket). Each side then performs connectivity checks against every pairing of local and remote candidates, in priority order, until one pair works.
The priority order matters. ICE tries host candidates first (same LAN), then server-reflexive (STUN, direct internet), then relayed (TURN). The first working pair is "nominated" and used for media. If the path later degrades — Wi-Fi to cellular handoff, for instance — ICE restart can re-run the gathering and re-pick. ICE Trickle (RFC 8838, January 2021) lets candidates flow incrementally so connection establishment can begin as soon as the first viable pair is found, rather than waiting for the whole gathering to finish.
For developers, ICE is mostly hidden inside RTCPeerConnection. The visible parts are configuring iceServers (STUN and TURN URLs and credentials) and listening to iceconnectionstatechange events. The operational visibility is in TURN traffic ratios and connection-failure rates — both reported by every commercial WebRTC observability tool.
The book · Volume 3 of 7
Video Streaming: A Complete Guide to Video Delivery: From ABR and CDNs to Players, WebRTC, DRM, and the Economics of Streaming
ICE decides whether two WebRTC endpoints connect directly or through a relay, so it drives both call success rates and TURN costs. Volume 3 covers ICE in detail within WebRTC and real-time media, alongside video calls and conferencing, SFU topologies and QoE monitoring. Written by Nikolay Sapunov, CEO at Fora Soft.
Seeing failed WebRTC calls and suspect ICE or TURN setup?
We will audit your ICE, STUN and TURN configuration and give you fixes that raise call connection rates. 250+ video products shipped since 2005.
