ICE stands for Interactive Connectivity Establishment.
It is a standard for establishing real-time media sessions between two endpoints across NATs and firewalls. ICE works by gathering every possible network path between two peers, then systematically testing each one to find the best working route. The protocol was originally defined in IETF RFC 5245 and updated in RFC 8445.
In WebRTC, ICE is the mandatory NAT traversal mechanism. It uses STUN servers to discover public IP addresses and TURN servers as a relay fallback when direct paths fail.
Many mistake ICE for a server component, where in fact, ICE is a network protocol that orchestrates connectivity checks using STUN and TURN servers: ICE collects all available candidates (local IP addresses, reflexive addresses from STUN servers, and relayed addresses from TURN servers). All collected addresses are then sent to the remote peer via SDP.
Once both sides have each other's candidates, ICE starts connectivity checks. These tests send packets over each candidate pair until one succeeds in both directions - that becomes the active media path.
The downside of using ICE is the time it takes, which can be tens of seconds in the worst case. To speed this up, WebRTC uses Trickle ICE, which sends candidates as they are discovered rather than waiting for the full list.
Once a connection is established, ICE keeps monitoring the path. If the network changes mid-call - switching from Wi-Fi to cellular, a NAT binding expiring, or connectivity otherwise failing - an ICE restart runs a fresh round of candidate gathering and connectivity checks on the same PeerConnection to recover the session without dropping it.
How ICE Works Step by Step
ICE runs in three phases:
1. Candidate gathering. Each peer collects every address it might be reachable at. These are called ICE candidates, and they fall into three types:
- Host candidates: Local IP addresses directly on the device's network interfaces
- Server-reflexive candidates: The public IP and port the device appears to have, as seen by a STUN server on the internet
- Relayed candidates: An address on a TURN server that will forward media on the peer's behalf
2. Candidate exchange. Each peer sends its candidate list to the other through signaling, embedded in SDP. With Trickle ICE, candidates are sent as they are discovered rather than waiting for the full list - this cuts connection setup time significantly.
3. Connectivity checks. ICE pairs up every local candidate with every remote candidate and sends test packets (STUN binding requests) across each pair. The first pair that succeeds in both directions becomes the active media path. If a higher-priority pair succeeds later, ICE switches to it.
The priority order is: host > server-reflexive > relayed. ICE tries direct paths first and falls back to TURN only when nothing else works.
ICE and Mid-Call Network Changes
Once a call is connected, ICE keeps monitoring the path. If the network changes - a user switches from Wi-Fi to cellular, a NAT binding expires - an ICE restart re-runs candidate gathering and connectivity checks on the existing PeerConnection without dropping the session.
