RE: [webrtc-pc] Impossible to know if ICE agent is "finished checking", for "failed" and "completed" states.

Thank you, Taylor, for filing this Issue.   It exists not only in WebRTC 1.0, but also in ORTC. 

As you noted, JSEP mandates use of the  "a=end-of-candidates" line in a number of places,  including Section 5.2.2 (Subsequent Offers) and Section 5.3.2 (Subsequent Answers),  as well as in multiple places in Section 7 (Examples).  However, because "a=end-of-candidates" is not per m-line, it operates only at the level of the "ICE Agent" rather than individually on each of the RTCIceTransport objects and their "state" attributes.   This means that it is not applicable to ORTC/WebRTC NV.  

Currently, ORTC Is overloading addRemoteCandidate() via use of a "special candidate" signifying "end of candidates".   In some implementations this is interpreted to mean "end of candidates" in the sense described in RFC 5245 and Trickle ICE.  In others, it means "end of candidates (for now)" so that it may be possible to call addRemoteCandidate() after the "special candidate" has been already applied, causing a transition from the "complete" and "failed" states to other states.  

However, since WebRTC 1.0 prohibits a null ICE candidate, use of a "special candidate" in ORTC is somewhat awkward, so that a "candidatesComplete()" method has been suggested as an alternative.   

-----Original Message-----
From: Taylor Brandstetter via GitHub [mailto:sysbot+gh@w3.org] 
Sent: Thursday, December 17, 2015 3:18 PM
To: public-webrtc@w3.org
Subject: [webrtc-pc] Impossible to know if ICE agent is "finished checking", for "failed" and "completed" states.

taylor-b has just created a new issue for
https://github.com/w3c/webrtc-pc:


== Impossible to know if ICE agent is "finished checking", for "failed" and "completed" states. == Focusing first on "failed", it's defined as: "The ICE Agent is finished checking all candidate pairs and failed to find a connection for at least one component."

However, even after finishing gathering and checking all current candidate pairs, a new remote candidate could be applied at any time via addIceCandidate, creating new candidate pairs.

The trickle ICE spec addresses this, saying a check list should only go to the Failed state when "the remote agent has sent an end-of-candidates indication for that check list as described in Section 9.3.". The RTCPeerConnectionIceEvent does signal "end-of-candidates", but there are two problems with this:

1. It's only signaled once, but it needs to be signaled once per check  list (once per m-line).
2. There's no way to pass the end-of-candidates indication into the browser.

I would propose adding a way to indicate "end of remote candidates" to  the browser, either by overloading addIceCandidate or by adding a new  method. This indication would ensure an accurate "failed" state (that  doesn't flip back to "checking"), and it could also be used to optimize the ICE algorithm, as discussed in trickle ICE.

If we *don't* do that, we should at least make the spec clear in the fact that "failed" is temporary, and it could return to "checking" if a new candidate pair is created.

Please view or discuss this issue at
https://github.com/w3c/webrtc-pc/issues/442 using your GitHub account

Received on Thursday, 17 December 2015 20:58:21 UTC