Re: [rtcweb] When are ICE candidates added to the SDP

[Harald Alvestrand <[e-mail]>]

On 05/19/2014 06:14 AM, Justin Uberti wrote:
> Agree with Martin's analysis.
>
> Regarding what we should do after a new setLocalDescription, the
> implementation does need to change the value of iceGatheringState if
> new gathering is going to occur. As pointed out, since we don't have a
> callback for iceGatheringState, firing onicecandidate(null) if no
> gathering needs to happen seems reasonable, if inelegant. 
>
> But the reason for not having an iceGatheringState callback was
> because we felt that it was redundant with onicecandidate. That now
> seems debatable, and I'd rather add that callback than pound
> onicecandidate until it looks like said callback.

The onicecandidate(NULL) always seemed inelegant to me; it wasn't
supplying a candidate, it was indicating something else.

I'd be happy with replacing it with an iceGatheringState change callback
(if we can ensure that this will do the Right Thing in all cases...)

>
>
> On Sat, May 17, 2014 at 5:28 PM, Eric Rescorla <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
>
>     On Sat, May 17, 2014 at 11:19 AM, Cullen Jennings <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>
>         On May 11, 2014, at 6:51 PM, Eric Rescorla <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>         > However, we agreed in London that we would do "always
>         trickle", and
>         > that even if there were candidates available at the time
>         when CreateOffer
>         > (because of candidate pooling) was called, they would not be
>         included
>         > in the initial offer.
>
>         Hmm - did we agree they would not be there or they might not
>         be there?
>
>
>     My memory is that Justin argued that it would be more consistent to
>     not have them and I agreed to check to see if that was a big deal
>     for Firefox. It's not.
>
>      
>
>         Either way, I think that things will work better if we can
>         provide whatever information we have available at the time the
>          call returns. So my preference would be that if they are in
>         the pool, they are returned as early as possible.
>
>
>     We're talking about having the onicecandidate callbacks called
>     immediately
>     on setLocal(), so this should't have much latency impact.
>
>  
>
>
>
>      
>
>         I can not really see any good reasons for delaying the return
>         of the candidates that are available.  Even when you are doing
>         trickily ICE, this is going to result in less round trips of
>         "trickle" and result in closer synchronization of the
>         connectivity checks from both sides for the candidates that
>         are returned in the first offer. That will help up the success
>         rate of trickle ICE.
>
>
>     See above. I don't think this analysis is really correct.
>
>     -Ekr
>
>
>
>     _______________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.