ICE stands for Interactive Connectivity Establishment.
It is a standard method of NAT traversal used in WebRTC. It is defined in IETF RFC 5245.
ICE deals with the process of connecting media through NATs by conducting connectivity checks.
ICE collects all available candidates (local IP addresses, reflexive addresses – STUN ones and relayed addresses – TURN ones). All the collected addresses are then sent to the remote peer via SDP.
Once the WebRTC Client has all the collected ICE addresses of itself and its peer, it starts initiating connectivity checks. These checks essentially try sending media over the various addresses until success.
The downside of using ICE is the time it takes, which can be 10s of seconds. To run faster, a new mechanism was added in WebRTC called Trickle ICE.
Understanding Interactive Connectivity Establishment (ICE) in WebRTC
At the heart of ICE is a robust mechanism that gathers a plethora of IP address candidates from the participating entities in a communication session. These candidates encompass local IP addresses, reflexive addresses obtained via STUN, and relayed addresses acquired through TURN.
The aggregation of these addresses is a precursor to the connectivity checks, which are necessary for establishing a viable media path between the peers. This is because we don’t really know which of these addresses can be used in the specific situation to connect the peers properly.
Upon the collation of address candidates, ICE orchestrates the exchange of these candidates between the peers using SDP message blobs. This exchange is instrumental in ensuring that both peers have a comprehensive understanding of each other’s reachable network endpoints, thereby setting the stage for the ensuing connectivity checks.
Connectivity Checks
The connectivity checks are at the heart of the ICE algorithm. They offer a pragmatic approach to ascertain the most efficient path for media transmission. These checks are conducted by attempting to send media packets across the various address pairs, evaluating the success of each attempt.
The objective is to unearth a pair of addresses that allow for successful media transmission, thereby ensuring an uninterrupted communication session.
However, a notable caveat associated with ICE is the latency incurred during the gathering of address candidates and the connectivity checks. The process can span tens of seconds, which might not be conducive for real-time communications. To improve this, WebRTC introduced a mechanism known as Trickle ICE.
This enhancement expedites the ICE process by allowing the incremental sending and processing of ICE candidates, thereby significantly reducing the setup time required for establishing a connection.
