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

Hi Emil,

The browser may or may not know when it will deliver the final 
candidate. That's why I put in the "caveat". Sometimes it won't know 
because the browser discovers the pending network operation for a relay 
candidate is for a redundant server reflexive candidate and thus is not 
a valid candidate. Other times it may not know because of a failure to 
allocate or discover a relay candidate. It is a matter of operation timing.

However, under many scenarios the browser fully knows that this it has 
gathered the final candidate so delivering that candidate so it doesn't 
need to fire a distinct event later. Delivering that candidate with the 
"end of gathered candidates" flag as part of remote signaling is 
important to avoid an extra needless remote signaling event for the sole 
purpose of indicating the final gathered candidate has arrived. In the 
case where the browser discovers that it has no more candidates to 
gather too late, there's not much that can be done except fire the final 
"onlocalcandidates" event with the "end of gathered candidates" flag set 
to true.

...

Having said all this, I still would implement my web application in a 
different way entirely. I'd ignore the candidates fired as part of the 
"onlocalcandidates" and instead go directly to the object and fetch 
"getLocalCandidates" when I received the event to minimize needless 
signaling because of timing. As the "onlocalcandidates" event may fire 
many times by the browser before my web application even processes those 
events, the "getLocalCandidates" may have additional candidates 
available before I've had a change to process the remaining 
"onlocalcandidates" events. I'd prefer to get every single candidate 
possible in one swoop and send those to the remote party if they are 
available rather than needlessly emit additional network signaling events.

I'd also check the IceListener gather state to see if it was active or 
not and use that to indicate the "final" candidate rather than relying 
upon the final boolean value for the same reason. I'd like to be sure if 
I've got all candidates (including the final gathered) even if I've not 
processed all the browser fired "onlocalcandidate" events yet. Having 
already implemented ICE as an event driven library, I've found in 
practice this is more more efficient and successful at reducing needless 
remote signaling chatter.

So if I'd truly have "my way", I'd have an "onLocalCandidatesChanged" 
event, upon which the web developer would call "getLocalCandidates" 
which would return a candidates version string (i.e. a quick check for 
the web developer to see if the list has changed from last "get" call) 
and a resultant list of candidates with the "final candidate" flag as 
part of the return result. That would be my true preference for an API 
rather than receiving the candidates as trickled events because I 
dislike sending needless remote signaling. I can simulate this behaviour 
of course with the current API but that would be my ideal API.

-Robin

> Emil Ivov <mailto:emcho@jitsi.org>
> April 12, 2014 at 12:49 PM
>
> 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
>
>