What Are ICE Candidates?

ICE candidates are potential network paths that WebRTC evaluates to find the best way to connect two peers for video chat.

ICE (Interactive Connectivity Establishment) candidates are potential network paths that your browser discovers when trying to establish a WebRTC peer-to-peer connection for video chat. Each candidate represents a possible way to reach your device — and the ICE framework tests them all to find the best one.

What Is an ICE Candidate?

An ICE candidate is essentially an address: an IP address and port number where your device can receive data. During the connection process, your browser gathers multiple candidates because there are often several possible ways to reach you.

Each candidate has a type:

Host Candidates

Your device's local network address (e.g., 192.168.1.5:54321). These work when both peers are on the same local network (like the same WiFi) — rare in random video chat but important for completeness.

Server Reflexive Candidates (srflx)

Your public IP address as discovered by a STUN server (e.g., 203.0.113.45:12345). These are the primary candidates used for most internet-based P2P connections. They represent how you look from outside your local network.

Relay Candidates

An address on a TURN server that will relay data on your behalf (e.g., 198.51.100.10:3478). These are the fallback option when direct connection is impossible.

How ICE Candidate Gathering Works

When you start a video chat on a platform like Glimr:

  1. Browser gathers host candidates — Discovers local network addresses
  2. Browser queries STUN server — Discovers server reflexive candidates (public IP)
  3. Browser contacts TURN server — Obtains relay candidates (if TURN is configured)
  4. Candidates are sent to the signaling server — The platform relays them to the other peer
  5. Both peers now have each other's candidate lists

ICE Candidate Pairing and Testing

Once both peers have exchanged their candidate lists, the ICE framework creates pairs (one candidate from each side) and tests them:

  1. Pairs are prioritized — Host-to-host is preferred, then srflx-to-srflx, then relay
  2. Connectivity checks begin — STUN binding requests are sent on each pair
  3. Working pairs are identified — Pairs that successfully exchange data
  4. Best pair is selected — The working pair with the highest priority becomes the active connection

This process typically takes milliseconds to a few seconds. In a random video chat, it happens during the brief "connecting" phase after you're matched with someone.

Why Multiple Candidates Matter

Having multiple candidates provides resilience:

  • If your firewall blocks direct connections → server reflexive candidates might still work
  • If symmetric NAT prevents direct P2P → relay candidates through TURN succeed
  • If one network interface is slow → a candidate on another interface might be faster

The ICE framework tries the best option first and falls back gracefully. This is why modern WebRTC video chat works reliably across vastly different network environments — from open university WiFi to restrictive corporate firewalls.

Trickle ICE

Modern WebRTC implementations use "Trickle ICE" — instead of waiting to gather all candidates before sending them, candidates are sent to the peer as they're discovered. This reduces connection setup time because pairing and testing can begin while more candidates are still being gathered.

You'll notice this on Glimr — the connection phase is typically very fast because Trickle ICE allows the best path to be found quickly without waiting for slower candidates (like TURN allocations) to complete.

ICE in Practice

For users, ICE is completely invisible. You click Start, get matched, and within seconds you're video chatting. Behind the scenes, ICE has discovered dozens of possible connection paths, tested them all, and selected the optimal one — all in the time it takes you to say "hello."

Definition

Potential network connection paths (IP address and port combinations) that WebRTC discovers and evaluates to establish the best possible peer-to-peer connection.

Category: Technology