RTCIceTransportState

[aboba]

From: Iñaki Baz Castillo ibc@aliax.net
Date: Wed, 2 Jul 2014 23:26:59 +0200
To: "public-ortc@w3.org" public-ortc@w3.org
Link: http://lists.w3.org/Archives/Public/public-ortc/2014Jul/0010.html

• connected

The ICE Agent has found a usable connection for all components but is still checking other candidate pairs to see if there is a better connection. It may also still be gathering.

• completed

The ICE Agent has finished gathering and checking and found a connection for all components. Open issue: it is not clear how the non controlling ICE side knows it is in the state.

IMHO there is little value in having both (and indeed, for the controlled side there is no way to determine whether it is in connected or completed state. Even more, new gathering may occur N seconds after the controlling agent decides it is in completed state (imagine a new network interface becomes available somehow).

IMHO the completed state has no value having the connected one.

NOTE: I understand that the connected state happens once the ICE agent has sent the definitive STUN request with USE-CANDIDATE, or after it has selected (based on candidate-pair priorities) the selected pair (in case aggressive ICE was used).

[aboba]

Link: http://lists.w3.org/Archives/Public/public-ortc/2014Jul/0011.html

In fact, as you see in the diagram after section "3.10 enum
RTCIceTransportState", there is no difference between connected and
completed states (both may merge into a single one and the other
states may remain the same).

[aboba]

Robin Raymond said:

So I would agree, we probably should drop “completed” in favour of connected (or vice versa).

Inaki said:

"I like "connected" as we name the object ICETransport, so "connected" makes more sense IMHO."

[BA] Sounds like we are agreeing to drop "completed" in favour of connected.

[robin-raymond]

As much as I'd like to drop the "completed" state, I think for backwards compatibility we must maintain it. There's no strong use case for "completed" and the controlled side can't even know when it is completed but regardless WebRTC 1.0 exposes it.

[aboba]

Looking at the non-normative ICE state diagram, there are a number of issues that probably should be discussed (such as the transitions back to NEW).

[ibc]

There's no strong use case for "completed" and the controlled side can't even know when it is completed but regardless WebRTC 1.0 exposes it.

Within the WebRTC 1.0 shim we can safely fire an artificial "completed" event after firing "connected" event. Really. It would work as now.

[robin-raymond]

There's been strong push back whenever I try to "fix" small things (like this) that make differences from the 1.0 API with little value to doing so... While I agree with you, I suggest at the next CG meeting and when we bring up the topic by all means push to fix this issue.

[aboba]

Here is a proposed new state diagram.

[ibc]

Sorry I don't get it. Still "connected" and "completed" which, in fact, are the same box.

[ibc]

About the WebRTC 1.0 backwards compatibility argument: Chrome moves the iceConnectionState from "checking" to "completed", while Firefox moves from "checking" to "connected". This is a no sense based on a bad spec since, as explained in this issue, there is no real difference between "connected" and "complete".