videocalling
glossary.backToGlossary

ICE (Interactive Connectivity Establishment)

协议

Framework for establishing peer connections through firewalls and NAT

What is ICE?

Interactive Connectivity Establishment (ICE) is a framework that WebRTC uses to establish direct connections between browsers or devices despite network obstacles like NAT (Network Address Translation) and firewalls. Think of ICE as a smart negotiator that tries multiple connection strategies simultaneously to find the best path between two peers.

ICE doesn't transport media itself—it's the process that figures out HOW to connect two devices so that media (video, audio, data) can flow between them. Once ICE succeeds, the actual WebRTC connection uses the path ICE discovered.

Standardized in RFC 8445, ICE is essential to WebRTC's promise of browser-to-browser communication. Without ICE, most WebRTC calls would fail because participants are typically behind NAT routers that block direct connections.

Why ICE is Necessary

The core problem ICE solves: Most devices don't have public IP addresses that others can directly reach.

Your laptop at home has a private IP like 192.168.1.100. Your router (NAT) translates this to your public IP when accessing the internet. But someone on the internet can't initiate a connection to 192.168.1.100—they can only reach your router's public IP, and the router doesn't know where to send incoming WebRTC packets.

Add firewalls that block unexpected incoming connections, and you have a recipe for connection failure. ICE systematically finds working paths through these obstacles.

How ICE Works: Step by Step

1. Gathering ICE Candidates

When a WebRTC connection starts, each peer gathers "candidates"—potential connection paths. ICE discovers three types of candidates:

  • Host Candidates: Your device's local IP addresses (like 192.168.1.100 for WiFi, 10.0.0.5 for VPN). These work only if both peers are on the same local network
  • Server Reflexive Candidates: Your public IP address as seen from the internet, discovered by querying a STUN server. This is your router's public IP and the port it assigned for this connection
  • Relay Candidates: An address on a TURN relay server that will forward your traffic if direct connections fail. This is the fallback that always works but adds latency

The browser automatically discovers all available candidates and prioritizes them (host > server reflexive > relay).

2. Exchanging Candidates via Signaling

Each peer's candidates are sent to the other peer through a signaling channel (typically WebSockets or HTTPS). This signaling happens outside WebRTC—you need to build this yourself or use a service.

The exchange includes each candidate's IP address, port, protocol (UDP/TCP), and priority. Modern WebRTC uses "Trickle ICE" which sends candidates incrementally as they're discovered, rather than waiting for all candidates before starting negotiations.

3. Connectivity Checks

Once peers have each other's candidates, ICE performs connectivity checks. It pairs local candidates with remote candidates and tests each pair by sending STUN binding requests.

For example, if you have 3 candidates and the remote peer has 3 candidates, ICE tests up to 9 pairs (3 × 3). Tests run in parallel, prioritized by candidate quality (direct connections tested before relayed ones).

4. Selecting the Best Path

ICE identifies which candidate pairs successfully connected and selects the "best" one based on:

  • Lowest latency
  • Candidate type priority (prefer direct over relayed)
  • Connection reliability

Usually, the selected path is the most direct route possible. If both peers are on the same local network, it'll be a direct LAN connection. If they're on the internet with permissive NATs, it'll be a peer-to-peer connection via public IPs. If NATs are restrictive, it'll be through a TURN relay.

5. Connection Established

Once the best candidate pair succeeds, ICE declares success and WebRTC starts sending media over that path. The entire process typically takes 2-5 seconds, though Trickle ICE can establish connections in under 1 second.

Connection Success Rates

In real-world deployments:

  • 75-85% of connections: Succeed via direct peer-to-peer paths using server reflexive candidates (STUN)
  • 15-25% of connections: Require TURN relay due to symmetric NAT, restrictive firewalls, or enterprise networks
  • <1% of connections: Fail completely, usually due to corporate proxies blocking WebRTC entirely

These numbers highlight why TURN servers are essential despite their cost—they ensure the connection succeeds even when direct paths fail.

Trickle ICE: The Modern Optimization

Traditional ICE waited until all candidates were gathered before beginning connectivity checks—often taking 5-10 seconds.

Trickle ICE, now standard in WebRTC, sends candidates incrementally as they're discovered. The moment a host candidate is found, it's sent to the remote peer and connectivity checks begin—even while STUN and TURN queries are still running.

This dramatically reduces connection setup time. In optimal conditions (local network or permissive NAT), connections can establish in under 500ms.

ICE Restart

ICE supports restarting the candidate gathering and selection process without ending the call. This happens when:

  • Network conditions change (you switch from WiFi to cellular)
  • The connection degrades or fails
  • A participant moves between networks

ICE restart seamlessly re-establishes the best path without interrupting the user experience. The video might freeze momentarily, but the call continues.

Challenges and Limitations

Symmetric NAT

The most problematic NAT type. Symmetric NAT assigns different port mappings for each destination, making STUN ineffective. Only TURN relays work, adding latency and server costs.

Enterprise Firewalls

Some corporate networks block all UDP traffic or whitelist only specific ports, breaking WebRTC. ICE can fall back to TCP, but not all networks allow this either.

Candidate Explosion

Devices with multiple network interfaces (WiFi, Ethernet, VPN, cellular) generate many candidates. Testing all pairs takes time and bandwidth. Modern implementations use heuristics to skip unlikely pairs.

Privacy Considerations

ICE exposes local and public IP addresses, raising privacy concerns. Some browsers now limit candidate exposure or require user permission, which can impact connectivity success rates.

ICE in Practice

As a developer or user, you rarely interact with ICE directly—WebRTC handles it automatically. But understanding ICE helps you:

  • Know why STUN and TURN servers are required infrastructure
  • Understand why some connections fail in restrictive networks
  • Debug connection issues by examining ICE candidate types
  • Estimate infrastructure costs (TURN bandwidth for 15-25% of calls)

The Bottom Line

ICE is the unsung hero of WebRTC. It's the reason you can click a link and instantly start a video call with someone across the world, despite both of you being behind NAT routers and firewalls.

By systematically trying multiple connection strategies—direct local connections, peer-to-peer via STUN, and relayed via TURN—ICE maximizes connection success rates while minimizing latency. The framework's intelligence in prioritizing faster paths and its ability to adapt to changing network conditions make it essential for reliable real-time communication.

Without ICE, WebRTC would only work for users on the same local network or with very permissive network configurations—making browser-based video calling impractical for the vast majority of internet users.

References

相关术语

STUN (Session Traversal Utilities for NAT)TURN (Traversal Using Relays around NAT)NAT (Network Address Translation)WebRTC
glossary.backToGlossary