Published: February 2026
Interactive Connectivity Establishment (ICE) is the intelligent framework that coordinates WebRTC connection establishment. While STUN and TURN provide the tools for NAT traversal, ICE is the brain that decides how and when to use them. In this article, we'll explore how ICE works, its candidate types, and why it's crucial for reliable WebRTC communications.
ICE is a framework defined in RFC 8445 that enables devices to discover the best possible path for peer-to-peer communication. Rather than a single protocol, ICE is a methodology that combines multiple techniques—including STUN and TURN—to overcome network obstacles and establish optimal connections.
The ICE framework solves a fundamental problem: how can two devices on the internet find and connect to each other when neither knows the other's actual network location?
ICE follows a systematic approach to establish connections:
The first step in ICE is gathering all possible ways a device might be reached. These are called ICE candidates, and they come in three types:
Host Candidates: Direct addresses from the device's network interfaces. These include all local IP addresses, whether from Wi-Fi, Ethernet, or mobile data connections.
Server Reflexive (srflx) Candidates: Public addresses discovered through STUN servers. These candidates represent how the device appears to the external internet after NAT translation.
Relay Candidates: Addresses allocated from TURN servers. These are fallback options when direct connections aren't possible.
During candidate gathering, the WebRTC stack simultaneously contacts STUN and TURN servers to discover all possible connection paths. This parallel gathering minimizes connection establishment time.
Once gathered, candidates must be exchanged between peers through the signaling channel. Each peer shares its complete list of candidates, allowing both sides to consider all possible connection paths.
This exchange happens alongside SDP (Session Description Protocol) negotiation, where peers agree on media codecs, formats, and other session parameters.
With candidates exchanged, ICE performs connectivity checks to determine which candidate pairs actually work. This process involves:
Pairing Candidates: ICE creates pairs by combining local candidates with remote candidates from the peer.
Prioritization: Pairs are prioritized based on several factors including candidate type, network interface, and IP address family (IPv4 vs IPv6).
Connectivity Testing: ICE sends STUN binding requests between candidate pairs to verify connectivity.
Response Validation: Successful responses indicate viable connection paths.
After connectivity checks complete, ICE selects the best working candidate pair based on:
Understanding candidate types is crucial for troubleshooting and optimizing WebRTC connections:
These represent the device's actual network interfaces. A typical device might have multiple host candidates:
Created through STUN server interaction, these candidates represent the public IP address and port after NAT translation. They enable direct peer-to-peer connections through NAT devices.
Server reflexive candidates are the sweet spot for WebRTC—they enable direct connections while working through most home and mobile network NAT configurations. They succeed in approximately 80-90% of connection attempts.
Allocated from TURN servers, relay candidates guarantee connectivity but at the cost of additional latency and bandwidth consumption. The relay candidate represents the TURN server's address, not the peer's actual location.
All traffic flows through the TURN server when using relay candidates, making them the most resource-intensive option but ensuring connectivity even in the most restrictive networks.
Discovered during connectivity checks rather than initial gathering, peer reflexive candidates represent addresses learned from responses to STUN checks sent to remote candidates. They're relatively rare but can provide additional connection paths.
Traditional ICE waits for all candidates to be gathered before starting connectivity checks. Trickle ICE improves this by allowing connection establishment to begin as soon as the first candidates are available.
Reduced Connection Time: Connectivity checks start immediately, potentially establishing connections before gathering completes.
Better User Experience: Users see connection establishment progress rather than waiting for a long gathering phase.
Parallel Processing: Gathering and checking happen simultaneously, optimizing the overall process.
Most modern WebRTC implementations support Trickle ICE by default. As candidates are discovered, they're immediately sent to the peer through the signaling channel, and connectivity checks begin without waiting for gathering to complete.
Sometimes existing connections fail or need reconfiguration. ICE restart allows renegotiating the connection without creating an entirely new peer connection:
ICE restart generates new ICE credentials and re-gathers candidates. The existing peer connection remains, but the ICE process starts fresh. This is more efficient than creating a new connection from scratch.
Modern devices frequently change networks—switching between Wi-Fi and mobile data, moving between access points, or experiencing network interruptions. ICE handles these changes gracefully:
The ICE connection state machine tracks the current status:
Even after establishment, ICE maintains connections through periodic consent checks. This ensures the connection remains valid and helps detect network changes quickly.
WebRTC provides configuration options to control ICE behavior:
Controls which ICE candidates are used:
const config = {
iceTransportPolicy: 'all' // Use all candidates (default)
// iceTransportPolicy: 'relay' // Use only TURN relay candidates
};
Setting the policy to 'relay' forces all connections through TURN, useful for ensuring privacy or controlling network paths.
Pre-allocates TURN relays to reduce connection establishment time:
const config = {
iceCandidatePoolSize: 10 // Pre-gather candidates
};
This option is useful when you know TURN will likely be needed and want to minimize latency.
Controls how multiple media streams share ICE candidates:
const config = {
bundlePolicy: 'max-bundle' // Share ICE across all streams
};
This reduces the number of required candidates and connectivity checks.
ICE supports both IPv4 and IPv6, with modern implementations gathering candidates for both address families:
Similar to "Happy Eyeballs" in web browsers, ICE tries both IPv4 and IPv6 paths simultaneously, using whichever succeeds first.
Understanding ICE states and candidates helps diagnose connection problems:
No Candidates Gathered: Usually indicates STUN/TURN server misconfiguration or network blocks.
Connectivity Checks Fail: Can result from firewall rules, incorrect candidate information, or network asymmetry.
ICE Never Completes: Often caused by missing TURN servers when direct connections aren't possible.
Browser developer tools provide detailed ICE information:
Chrome: chrome://webrtc-internals Firefox: about:webrtc
These tools show:
Optimize ICE configuration for better performance and reliability:
Configure Multiple STUN Servers: Provides redundancy if one server is unavailable.
Always Include TURN: Ensures connectivity even in restrictive networks.
Use Trickle ICE: Enables faster connection establishment.
Monitor ICE States: Track connection state changes to detect and respond to issues.
Implement ICE Restart: Handle network changes gracefully without full reconnection.
Test Across Networks: Verify connectivity from various network environments, especially restrictive corporate networks.
Fine-tune ICE for optimal performance:
Continuously assess connection quality and trigger ICE restart when necessary. This ensures users maintain the best possible connection path.
ICE is the intelligent orchestrator that makes WebRTC's peer-to-peer vision a reality. By systematically discovering, testing, and selecting the optimal connection path, ICE ensures that peers can connect reliably across the diverse and complex landscape of the internet.
Understanding ICE—its candidate types, processes, and configuration options—enables developers to build more robust WebRTC applications that work reliably across all network conditions. Whether connections use host candidates on local networks, server reflexive candidates through NAT, or relay candidates through TURN, ICE ensures peers find each other and establish high-quality communication channels.
Use our professional-grade ICE Tester to check your STUN/TURN server connectivity, latency, and ICE candidate collection in real-time.
🚀 Test Your Server Now