WebRTC ICE candidate pairs: how to read pair states and flags
What ICE candidate pairs are, how to read the ICE Connectivity table in rtcStats, and what each pair state and flag means.
Last updated Applies toany rtcStats setup
WebRTC troubleshooting: diagnose the symptom, not the tool7 articles
On this page5 sections
Before a WebRTC connection can carry media, ICE has to find a network path between the two peers. The ICE Connectivity table in the Session tab shows every path it tried and which one it used.
What ICE does
Each side gathers candidates: the addresses it can be reached on. A host candidate is a local address of the device, a server reflexive (srflx) candidate is the public address a STUN server saw, and a relay candidate is an address on a TURN server. A peer reflexive (prflx) candidate is an address that showed up during the checks without being signaled.
ICE pairs each local candidate with each remote candidate and runs connectivity checks on the pairs. A pair whose checks succeed can carry media. ICE then picks one of the working pairs, and that pair carries the media of the connection.
Reading the ICE Connectivity table
Each row is one candidate pair:
- All shows every pair, sorted by priority. Active shows only the pairs that were selected to carry media.
- State is how far the pair got. See Pair states.
- The up and down arrows are the bytes this user sent and received on the pair.
- Type is the path the media takes from this side: DIRECT when it goes straight to the other peer, RELAY when it goes through a TURN server, plus the transport protocol (UDP or TCP).
- Timeline draws the pair's states over time. Hover it to see when the pair was created, connected, used and ended, and how long it spent in each state.
Expand a row to see the local and remote candidates of the pair and its flags.
Pair states
| State | What it means |
|---|---|
| Used | The checks succeeded and the pair carried the media |
| Unused | The checks succeeded, but ICE never picked this pair |
| Unwritable | The checks succeeded once, but recent checks got no response |
| Waiting | Connectivity checks have not started on this pair |
| Frozen | The pair is waiting for checks on another pair first |
| In progress | Connectivity checks are running on this pair |
| Failed | Connectivity checks failed on this pair |
The state in the table is the best state the pair reached during the session. A pair that carried media at any point shows as Used, even if it later stopped. The timeline shows how the state changed over time.
Many Unused and Failed pairs are normal. ICE tries more pairs than it needs and keeps one. It is a problem only when no pair reaches Used: see WebRTC ICE failed.
Pair flags
The details of a pair show its flags. A lit flag means the pair had it at some point during the session:
- Writable: connectivity checks on the pair got a response. When the browser does not report it, rtcStats treats a pair whose checks succeeded as writable.
- Nominated: ICE picked this pair to carry the media. Nomination tells you which side picked it: locally (this side controls ICE) or remotely (the other side does).
- Selected: the connection sent its media on this pair.
- Highest: this pair has the highest priority of all the pairs on the connection. ICE prefers it, but a lower priority pair can still be the one selected.
A pair that is nominated and selected is the path the call used. When the selected pair changes during a call, the connection moved to a different network path.
See also
Was this page helpful?