RTCIceTransportState #122

Closed
aboba opened this Issue Jul 2, 2014 · 9 comments

Projects

None yet

3 participants

@aboba
Contributor
aboba commented Jul 2, 2014

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
Contributor
aboba commented Jul 2, 2014

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
Contributor
aboba commented Jul 8, 2014

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 robin-raymond added the 1.1 label Jul 8, 2014
@robin-raymond
Contributor

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
Contributor
aboba commented Jul 15, 2014

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
Contributor
ibc commented Jul 16, 2014

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
Contributor

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
Contributor
aboba commented Jul 21, 2014

Here is a proposed new state diagram.
icestates3

@aboba aboba closed this Jul 30, 2014
@ibc
Contributor
ibc commented Jul 30, 2014

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

@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Aug 19, 2014
Robin Raymond Clarification of the ICE restart issue, as noted in:
w3c#93

Clarified onerror usage in sender and receiver objects, as noted in:
w3c#95

Clarified SST-MS capability issue noted in:
w3c#108

Clarification of send() and receive() usage as noted in:
w3c#119

Changed ICE state diagram as noted in:
w3c#122

Removed getParameters methods and changed send() method as noted in:
w3c#136

Changed definition of framerateScale and resolutionScale as noted in:
w3c#137

Substituted "muxId" for the "receiverId" as noted in:
w3c#138
w3c#140

Clarified the setting of track.kind as described in:
w3c#141

Added SSRC conflict event to the RTCRtpSender, as described in:
w3c#143

Addressed the "end of candidates" issues noted in:
w3c#142
w3c#144
4916cd5
@ibc
Contributor
ibc commented Aug 20, 2014

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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment