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

Hey Robin,

Note that it is not necessarily known when a candidate is the last at the
time when it is being delivered to the application. Gathering may still be
in progress at that point (e.g. for relayed or srflx candidates) and still
fail later.

So some sort of a null/end-of-candidates event will still be necessary.

I don't personally see a problem with also having a "this is the last one"
flag, but I don't quite see the advantage it would bring either. I guess
that, given how you'd also need a dedicated event, it feels a bit redundant.

Cheers,
Emil

--sent from my mobile

On 12 Apr 2014 6:10 PM, "Robin Raymond" <robin@hookflash.com> wrote:
>
>
> 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
>
>