WebRTC Metrics
A comprehensive overview of WebRTC statistics, derived calculations, extracted features, and observable signals, to better understand call quality, connectivity, and user experience in rtcStats
On this page4 sections
High remote candidate delay
Last updated Applies tortcstats-enrichmentrtcstats.com
The first ICE candidate from the remote peer took a long time to arrive after negotiation started. This can point to slow candidate gathering on the remote side or a delay in relaying the candidate back over signaling.
Description
With trickle ICE, each peer gathers its own candidates locally and sends them to the other side over the signaling channel as soon as they are found, instead of waiting for the full offer/answer exchange to complete. The time between negotiation starting on this peer connection and the first candidate arriving from the remote peer reflects how quickly the remote side gathered a candidate and how quickly signaling relayed it back.
Is it a problem?
Often yes, but the two possible causes point in different directions. A slow first remote candidate can mean the remote peer itself is slow to gather (a poor remote network, a delayed TURN allocation, or the remote application deferring candidate collection), or it can mean the signaling channel is slow to relay trickled candidates specifically, independently of how fast the offer/answer messages themselves travel. Either way, it delays when this peer connection can start checking candidate pairs, which delays connection setup.
What do we do here?
This observation only applies to trickle ICE: if the remote SDP already contained candidates, the metric is meaningless and we skip it. Otherwise, we measure the delay between negotiation starting and the first remote candidate being applied on this peer connection. If that delay exceeds 1500 ms, we mark an observation.
