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
WebRTC troubleshooting: diagnose the symptom, not the tool7 articles
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
createOfferorsetRemoteDescription) until the connection reachedconnected. - Live (blue): from
connecteduntil 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?