ICE stands for Interactive Connectivity Establishment.
It is a standard method of NAT“) traversal used in WebRTC. It is defined in IETF RFC 5245.
ICE deals with the process of connecting media through NATs by conducting connectivity checks.
ICE collects all available candidates (local IP addresses, reflexive addresses – STUN ones and relayed addresses – TURN ones). All the collected addresses are then sent to the remote peer via SDP.
Once the WebRTC Client has all the collected ICE addresses of itself and its peer, it starts initiating connectivity checks. These checks essentially try sending media over the various addresses until success.
The downside of using ICE is the time it takes, which can be 10s of seconds. To run faster, a new mechanism was added in WebRTC called Trickle ICE.
Once a connection is established, ICE doesn’t stop mattering. 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.
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.
