W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2015

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

From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
Date: Thu, 17 Dec 2015 20:17:54 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-122815124-1450383471-sysbot+gh@w3.org>
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:17:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:47 UTC