-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RTCIceTransportState #122
Comments
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 |
Robin Raymond said:
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. |
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. |
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). |
Within the WebRTC 1.0 shim we can safely fire an artificial "completed" event after firing "connected" event. Really. It would work as now. |
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. |
Sorry I don't get it. Still "connected" and "completed" which, in fact, are the same box. |
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
About the WebRTC 1.0 backwards compatibility argument: Chrome moves the |
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
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).
The text was updated successfully, but these errors were encountered: