Trickle ICE is an optimization of the ICE specification for NAT traversal.
The main bottleneck in ICE is the time it takes to start initiating connectivity checks – it requires collecting all ICE candidates in advance, which in turn means interacting with external servers (STUN and TURN servers). This takes several round trips.
Trickle ICE makes the whole process parallel by having the ability to send single or multiple ICE candidates when they become available without waiting for the collection of all candidates.
In the realm of WebRTC, the process of ICE (Interactive Connectivity Establishment) negotiation has evolved significantly. Let’s rewind to the older days to better understand how things have changed.
Originally, ICE negotiations were conducted in a sequential manner. First, a user initiated a request to ascertain their IP address or to procure a relay. This was executed via STUN and TURN servers, which essentially served to collect the actual IP addresses required for the ICE negotiation process.
Upon receiving the results, the user transmitted an offer to the counterpart. The receiving user would then replicate the process: ascertain their public IP address via STUN, and get relay IP addresses from the TURN servers. With IP addresses from both sides now known, the receiving user would send their response, paving the way for connectivity checks.
The Challenge with the Traditional ICE Process
This traditional process, while functional, proved to be time-consuming. There was a considerable amount of latency because we were unable to preemptively conduct these operations. For instance, SIP softphones could perform these tasks ahead of time, but browsers lacked this advantage. Each time a new browser tab or context was opened, the entire process had to be repeated from scratch.
Introducing Trickle ICE
So, how can we trim this process to minimize time waste? The answer lies in an improved mechanism known as Trickle ICE. With Trickle ICE, we collect the candidates concurrently with the connectivity checks. We send the offer while simultaneously querying the STUN and TURN servers for our IP addresses.
The response from the other side is received promptly. That party then asks the same queries to their STUN and TURN servers. The beauty of Trickle ICE is that the connectivity checks commence immediately using local IP addresses. As new addresses are discovered, they’re reported via an “a=ice-candidate” message, enabling the addition of these ICE candidates along the way.
The Benefits of Trickle ICE
Trickle ICE effectively shortens the time required to conduct ICE connectivity checks. This mechanism gets its name from the fact that it ‘trickles’ the candidates from the commencement of the session until a connection is established, thereby streamlining the entire process.
If you are keen to dive deeper into this subject or learn more about WebRTC, I recommend checking out webrtcglossary.com or taking a look at my training courses on webrtccourse.com.
Thank you for reading, and I hope this gives you a clearer understanding of the benefits and functionality of Trickle ICE in WebRTC.
