What is Trickle ICE and How Does It Speed Up WebRTC?

Trickle ICE is an optimization framework for the Interactive Connectivity Establishment (ICE) protocol, designed to significantly accelerate the connection establishment process in WebRTC. In traditional WebRTC setups, peers must gather all potential network routing paths—known as ICE candidates—before exchanging them to establish a connection, which introduces noticeable latency. Trickle ICE solves this bottleneck by allowing peers to transmit ICE candidates incrementally as they are discovered. This article explains the mechanics of Trickle ICE, compares it to the traditional “Vanilla” ICE approach, and details how it drastically reduces connection startup times for real-time communication.

Vanilla ICE vs. Trickle ICE: The Core Difference

To understand why Trickle ICE is so effective, it helps to compare it to the original, traditional method of candidate gathering, often referred to as Vanilla ICE.

In Vanilla ICE, the connection process follows a strict, sequential order: 1. Gathering: The browser gathers all local IP addresses, STUN candidates (public IPs), and TURN candidates (relay IPs). 2. Waiting: The browser waits until the entire gathering process is 100% complete. This includes waiting for slow network interfaces or STUN/TURN server timeouts. 3. Signaling: A single Session Description Protocol (SDP) packet containing the complete list of candidates is sent to the remote peer. 4. Checking: Only after receiving this complete package can the remote peer begin testing connection paths.

In Trickle ICE, this sequential bottleneck is removed. The connection process becomes continuous and parallel: 1. Immediate signaling: The initial SDP offer/answer is sent immediately, containing no candidates (or only the initial local host candidates). 2. Incremental gathering and sending: As soon as the browser discovers a single candidate, it “trickles” it to the remote peer via the signaling server. 3. Immediate checking: The remote peer receives candidates one by one and starts testing them instantly, without waiting for the entire gathering process to finish.

How Trickle ICE Significantly Improves Startup Speeds

Trickle ICE reduces WebRTC connection setup times from several seconds to a fraction of a second. It achieves this dramatic speed improvement through three primary mechanisms.

1. Elimination of Gathering Timeouts

When gathering ICE candidates, a browser queries multiple network adapters and external STUN/TURN servers. If a particular network interface is inactive or a STUN server is slow to respond, Vanilla ICE forces the entire connection to stall until those queries either succeed or time out (which can take up to several seconds). Trickle ICE bypasses this delay entirely. If a local or STUN candidate is found within milliseconds, it is sent and tested immediately, allowing the connection to succeed before the slower queries even finish.

2. Parallel Connectivity Checks

Instead of waiting for the gathering phase to end before starting the connectivity checks, Trickle ICE overlaps these two phases. While the local ICE agent is still querying a TURN server for relay candidates, it is already actively testing direct P2P connections using the host and STUN candidates it gathered first. In most scenarios, a successful connection path is found and established using these early candidates, rendering the later, slower candidates unnecessary.

3. Faster Time to Media (TTM)

Because connectivity checks happen in parallel with candidate gathering, the time to establish a media connection (Time to Media) drops dramatically. Users experience nearly instantaneous call connection times, reducing the frustrating “connecting…” delay common in older VoIP and video conferencing systems.

The Step-by-Step Trickle ICE Workflow

The practical implementation of Trickle ICE in a WebRTC application follows a highly coordinated workflow:

  1. Create the Peer Connection: The calling peer creates an RTCPeerConnection object.
  2. Send Initial SDP: The caller generates an SDP offer and sends it to the receiver via the signaling channel immediately, before candidate gathering begins.
  3. Listen for Candidates: The caller sets up an event listener for the icecandidate event.
  4. Trickle Candidates: Every time the browser finds a candidate, the onicecandidate event fires. The caller immediately packages this single candidate and sends it to the remote peer.
  5. Process Candidates On-the-Fly: The receiving peer receives the individual candidate and immediately passes it to its own peer connection instance using the addIceCandidate() method.
  6. Establish Connection: The moment a compatible, high-performance path is verified by both sides, the WebRTC media channel opens, even if the browsers are still actively gathering and trickling alternative candidates in the background.