Every time you join a Google Meet, a Zoom call, share your screen in Discord, or play a browser-based multiplayer game, there's a protocol working furiously behind the scenes to punch through NATs and firewalls so two endpoints can talk directly. That protocol is ICE.

RFC 8445 is the revised specification (obsoleting the original RFC 5245 from 2010) that defines how two peers discover the best network path between them. The core problem it solves is deceptively brutal: how do two machines, both likely behind NAT devices, establish a direct peer-to-peer connection when neither knows its own public address?

The NAT traversal nightmare. By the mid-2000s, the internet's address space was drowning. NAT was everywhere. VoIP protocols like SIP needed endpoints to exchange media directly, but a machine behind NAT advertises a private 192.168.x.x address that's meaningless to the outside world. Earlier solutions like STUN (RFC 3489) and TURN (RFC 5766) each solved a piece of the puzzle, but ICE is the orchestration layer that ties them together into a systematic, reliable process.

How it works — the candidate dance:

• Candidate gathering: Each peer collects a list of possible addresses (candidates) it might be reachable at. These fall into three types: host candidates (local interface addresses), server-reflexive candidates (public addresses discovered via STUN), and relayed candidates (addresses allocated on a TURN relay server as a fallback).
• Candidate exchange: Both peers exchange their full candidate lists through a signaling channel (SIP, WebSocket, whatever — ICE is agnostic).
• Connectivity checks: Each peer systematically sends STUN Binding Requests to every candidate pair (local candidate × remote candidate), forming a checklist. Pairs are prioritized so that direct host-to-host connections are tried first, reflexive paths second, and relayed paths last.
• Nomination: Once a working pair is found, it's nominated and both sides converge on that path for media flow. The spec defines both regular nomination (keep checking, then pick the best) and aggressive nomination (nominate as you go).

Key design decisions that make ICE elegant:

ICE introduces the concept of a controlling and controlled agent to break symmetry — one side gets to make the final call on which pair wins. It also handles the tricky problem of candidate pair pruning: the combinatorial explosion of checking every possible pair is tamed through priority ordering and early termination once a sufficient path is found. The priority formula itself (defined in section 5.1.2) encodes a preference hierarchy: type preference × 2^24 + local preference × 2^8 + component ID, ensuring that direct connections always outrank relayed ones.

Why the 2018 revision matters: RFC 8445 cleaned up significant ambiguities in the original spec. It simplified the state machine, clarified the interaction between ICE and the "location-independent" candidate types, and removed the controversial "aggressive nomination" mode from the mandatory feature set. It also split out ICE for TCP into a separate document (RFC 6544), keeping the core spec focused.

One underappreciated detail: ICE also provides a form of consent verification. Because both sides must respond to STUN checks, you can't direct media at an arbitrary victim — the target has to actively participate. This was a deliberate anti-amplification design, predating many of today's DDoS concerns.

If you've ever watched a WebRTC connection's RTCPeerConnection.getStats() output, you've seen ICE at work — those candidate-pair, local-candidate, and remote-candidate stats objects map directly to the RFC's data model. The iceConnectionState transitions (checking → connected → completed) are the ICE state machine playing out in real time.