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

No more candidates arriving from remote party #142

Closed
aboba opened this Issue Aug 5, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@aboba
Copy link
Contributor

aboba commented Aug 5, 2014

In WebRTC 1.0 API Section 4.4.3, the "Completed" state contains the following statement:

"Open issue: it is not clear how the non controlling ICE side knows it is in the state."

There is a similar problem in ORTC, which is that it is not clear how to tell the RTCIceTransport that no more candidates will arrive from the remote party.

@robin-raymond

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Aug 5, 2014

Just to be clear, we can tell all candidates have been gathered locally by way of the gathering state (and thus can signal it remotely).

However, when we receive a remote signal that no more candidates will arrive from the remote party we can't tell the ORTC RTCIceTransport that no more candidates are to arrive and thus you are free to go into the completed state and clean up and resources.

@ibc

This comment has been minimized.

Copy link
Contributor

ibc commented Aug 5, 2014

And that is why I strongly suggest the removal of the "completed" state, as it adds zero value to the "connected" one (in fact, it is the same box in the diagram).

@robin-raymond

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Aug 5, 2014

@ibc we will post this to the list too, just capturing as an issue. There is "some" value to the completed state because some implementation can know it's safe to shutdown non used candidates (like turn) when completed.

@robin-raymond robin-raymond added the 1.1 label Aug 8, 2014

@robin-raymond

This comment has been minimized.

Copy link
Contributor

robin-raymond commented Aug 8, 2014

In SDP for 1.0, it's signalled with a=end-of-candidates so that's how 1.0 works (although I don't know any implementation that actually does it).

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

@aboba aboba closed this Aug 19, 2014

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