Delivering ICE candidates as packages of "available now" candidates in signaling

In a simple scenario, a web app would collect all ICE candidates and 
wait for the final "null" ICE candidate and then deliver the candidates 
to the remote party. However, this scenario defeats the purpose of 
having trickle ICE which allows candidates to be leaked to the remote 
party as they are available for faster setup times.

In the current model, until a connection to a peer can be made 
candidates are delivered via an intermediate relay (e.g. web socket 
server). A simple implementation may fire each candidate one-at-a-time 
via the relay until all candidates arrive and signaled with a "null" 
onlocalcandidates event.

However, more complex signaling will prefer/require "packaging" the ICE 
candidates into lists of candidates that are "available now" and then 
send updated packages when new blocks of candidates arrive.

The trouble with the current API is that there's no clear distinction 
when a package of candidates is ready. For example, if a host has 3 
"host" candidates, there will be 3 "onlocalcandidate" events and then a 
pause until the network candidates are discovered. There's no indication 
that this is the "last candidate available at this time" and the only 
indication available is "this is the last candidate that will be 
discovered for this gather" via a "null" final "onlocalcandidate" event.

With the API as is, an application programmer requiring packaging of ICE 
candidates in signaling will only have the option of waiting for all 
candidates or having some kind of timeout based upon last delivery of an 
"onlocalcandidate" event. This is not sufficient as it introduces a 
needless timeout waiting for candidates before sending signaling when 
the browser knows in advance no more candidates are available until 
further network operations are completed.

What really needs to happen is as follows:
- all candidates "available now" need to be packages together into a 
list where the 'last available for now candidate' is known
- when the final discoverable candidate is discovered, the 'end of 
gathered candidates' needs to be signaled so the final package of 
candidates can be sent.

There's two ways I can think of to do this:
1) "onlocalcandidate" includes two boolean values of "last available 
candidate for now" and "end of gathered candidates".
2) "onlocalcandidate" fires list of candidate in "available now" 
packages with a single "end of gathered candidates" flag present in the 
event.

I prefer option (2).

Example of how this might work: The browser can gather all host 
candidates, fires a single "onlocalcandidates" with a list of candidates 
available (and end of gathered candidates is false). The web app can 
deliver this package immediately to the remote party without a timeout 
needed. As further network candidates are discovered, the browser fires 
of "onlocalcandidates" with lists of new candidates that are available 
(if any), until the final discoverable candidate(s) arrives and the "end 
of gathered candidates" is set to true and the web app trickles the new 
packages of candidates to the remote party as they become available.

NOTE: I do not want to use a separate "null" list to signal "end of 
gathered candidates" as this would cause a web app to receive a list of 
packaged candidates, send off to the remote side, only to receive an 
immediate event afterwards with "null" candidate list. The result would 
mean yet another needless signaling to the remote party to signal the 
end of gathered candidates when it could have been signaled with the 
final package of candidates available. By having a flag part of the 
"onlocalcandidates" event, the web app can signal the package and 
finality of the candidates in the same signaling event to the remote 
party. Caveat: It's possible the final list might be empty if a pending 
network discoverable candidate fails to discover.

Conclusion: Unless we fix this, it will be very difficult for signaling 
protocols to deliver 'candidates available now' as single 'packages of 
candidates available now' in signaling rather than requiring 
one-at-a-time remote signaling events (or causing needless additional 
delays for timeout events after an "onlocalcandidate" event fires).

filed as: https://github.com/openpeer/ortc/issues/52

Received on Saturday, 12 April 2014 16:10:34 UTC