← Back to WebRTC troubleshooting: diagnose the symptom, not the tool

WebRTC connection states: how a peer connection lives, and where it failed

How to read a peer connection in rtcStats - its timeline from creation to the end, how it ended, why it failed to connect, and what each offer/answer round did.

Last updated Applies toany rtcStats setup

On this page5 sections

Every row in the Session tab's connections table is one RTCPeerConnection. The bar next to it shows its life, the dot shows how it ended, and the details tell you why a connection that never connected failed.

The life of a connection

A peer connection goes through up to three stages. Hover the bar to see how long it spent in each:

  • Warm-up (grey): the connection was created, but negotiation has not started yet. Some apps create connections ahead of time, so a long warm-up is not a problem by itself.
  • Setup Time (amber): from the start of negotiation (the first createOffer or setRemoteDescription) until the connection reached connected.
  • Live (blue): from connected until the connection ended.

When a live connection loses its network path, the bar shows a Disconnected stretch (red stripes) until it recovers, or until the end if it never does.

A connection that never connected has no blue at all: its bar stays amber from the start of negotiation to the end.

How a connection ended

The dot next to the connection tells you how it ended:

  • Connected: the connection reached connected.
  • Failed: the connection never connected, or it connected and later ended in failed.
  • Signaling: only one side of the offer/answer was applied. An offer went out and no answer came back, or the other way around.
  • Aborted: the connection was closed before any offer or answer was applied. Nothing was negotiated.

Why a connection never connected

When a connection never reached connected, rtcStats looks at how far it got and names the step where it stopped. You find the reason in the connection's details:

Reason What happened
DTLS failure ICE found a working path, but the connection never completed. The DTLS handshake that secures the media did not finish
ICE disconnection ICE connected, then lost the path before the connection completed
Connection failure The connection went to disconnected without ever connecting
ICE failure ICE tried the candidate pairs and none worked. See WebRTC ICE failed
ICE checks stalled ICE started checking candidate pairs, and the checks never reached a result before the connection ended
No remote candidate Both sides applied their descriptions and local candidates were gathered, but no check ever ran: no candidate from the other side reached this one
ICE gathering not observed The local description was applied, but candidate gathering never started
Signaling incomplete Only one side of the offer/answer was applied
Aborted Closed before any offer or answer was applied

The reasons are listed from the furthest step to the earliest. The top of the table means negotiation worked and the network path did not. The bottom means the connection stopped before the network was even tried.

Reading the negotiation ledger

Expand a connection to see its negotiations. Each offer/answer round gets a chip with its outcome and how long it took:

Outcome What it means
Completed The offer and the answer were applied, and signaling went back to stable
Answered The answer was applied, but no signaling state was logged to prove the round completed
Failed A step of the round failed
No answer An offer was made, but no answer was applied before the log ended
Rolled back The offer was rolled back
No offer The round started, but no offer was made
Closed The connection closed while waiting for the answer

Select a round to see its ledger: every call in order (createOffer, setLocalDescription, setRemoteDescription, addIceCandidate and so on), the time since the previous step, and the result:

  • OK or Failed: what the call returned.
  • Never called: a call the round needed was never made.
  • Not reached: the round stopped before this step.
  • no data: the end of the call was not logged.

An amber time marks a noticeable wait since the previous step. That is where to look when setup is slow. A step marked as inferred was not in the log: rtcStats deduced it from what came after.

See also

Was this page helpful?