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

Hey Robin,


On Sat, Apr 12, 2014 at 7:18 PM, Robin Raymond <robin@hookflash.com> wrote:

>
> Hi Emil,
>
> The browser may or may not know when it will deliver the final candidate.
> That's why I put in the "caveat".
>

Right. Seems I missed that.


> 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.
>

OK. I think the importance of avoiding an extra signalling message that
says "it's over" might be a bit exaggerated: it doesn't delay connection
establishment, in the worst case it would delay failures only marginally
(but that would be a very rare situation) and the incurred extra bandwidth
use is basically just an IP+UDP/TCP header.

That said, I don't see any problems arising from this so, if you and others
find it convenient .... :)

Emil



-- 
https://jitsi.org