What is ICE in WebRTC Routing

This article provides an overview of Interactive Connectivity Establishment (ICE) and its critical role in WebRTC routing. You will learn how the ICE framework overcomes network barriers like firewalls and Network Address Translators (NATs) to establish reliable, low-latency peer-to-peer connections using STUN and TURN servers.

At its core, the primary function of Interactive Connectivity Establishment (ICE) is to find the best possible network path for two WebRTC clients to connect and exchange real-time media. Because most modern devices sit behind security firewalls and Network Address Translators (NATs), they do not have public, easily reachable IP addresses. ICE acts as a negotiator that discovers, tests, and selects the most efficient route between these peers.

To establish this connection, ICE goes through a process called candidate gathering. An “ICE candidate” is simply a combination of an IP address and a port that a device can use to receive data. ICE gathers three main types of candidates:

• Host Candidates: These are the local IP addresses of the device, typically assigned by a local router on a private Wi-Fi or Ethernet network.
• Server Reflexive Candidates: These are the public-facing IP addresses and ports of the device, as seen from the outside Internet. ICE discovers these by querying a STUN (Session Traversal Utilities for NAT) server.
• Relay Candidates: If a direct connection is impossible due to strict firewalls, ICE utilizes a TURN (Traversal Using Relays around NAT) server. The TURN server acts as an intermediary, relaying all media traffic between the peers.

Once both peers have gathered their respective candidates, they exchange them via a signaling server. This exchange allows each peer to compile a list of potential connection pairs.

The final step is connectivity checking. ICE systematically tests these candidate pairs in a prioritized order—always favoring direct, peer-to-peer connections (host and server reflexive candidates) because they offer the lowest latency and cost. If a direct path is blocked, ICE falls back to the relay candidate. Once a working pair with the highest priority is verified, the media channel is opened, and WebRTC routing is successfully established.