CODEWITHSUNDEEP
webrtc
user2288650
user2288650

Reputation: 450

Ice connection state , Completed vs Connected

Can someone please clarify the difference between iceConnectionstate:completed vs iceConnectionstate:connected.

When I connect to browsers with webrtc I am able to exchange data using datachannel but for some reason the the iceConnectionstate on browser that made the offer reaming completed wheres the browser that accepted the offers changes to connected.

Any idea if this is normal?

Upvotes: 6

Views: 7124

Answers (2)

Ajay
Ajay

Reputation: 2643

ICE Connection state transition is a bit tricky, with below flow diagram you can get clear idea on possible transitions.

ICE Transport State Diagram

In simple words:
new/checking: Not at connected
connected/completed: Media path is available
disconnected/failed: Media path is not available (Whatever data you are sending on data channel won't reach other end)

Read full summary here

Still WebRTC team is working hard to make it stable & spec compliant.
Current chrome behavior is confusing so i filed a bug, you can star it to get notified.

Upvotes: 6

Taylor Brandstetter
Taylor Brandstetter

Reputation: 3623

In short:

  • connected: Found a working candidate pair, but still performing connectivity checks to find a better one.
  • completed: Found a working candidate pair and done performing connectivity checks.

For most purposes, you can probably treat the connected/completed states as the same thing.

Note that, as mentioned by Ajay, there are some notable difference between how the standard defines the states and how they're implemented in Chrome. The main ones that come to mind:

  • There's no "end-of-candidates" signaling, so none of those parts of the candidate state definitions are implemented. This means if a remote candidate arrives late, it's possible to go from "completed" back to "connected" without an ICE restart. Though I assume this is rare in practice.
  • The ICE state is actually a combination ICE+DTLS state (see: https://bugs.chromium.org/p/webrtc/issues/detail?id=6145). This is because it was implemented before there was such thing as "RTCPeerConnectionState". This can lead to confusion if there's actually a DTLS-level issue, since the only way to really notice is to look in a native Chrome log.

We definitely plan on fixing all the discrepancies. But for a while we held off on it because the standard was still in flux. And right now our priority is more on implementing unified plan SDP and the RtpSender/RtpReceiver APIs.

Upvotes: 6

Related Questions