Re: candidate warm up

Am i reading correctly that you suggest generating oncandidate events
prior to calling createOffer/createAnswer/setLocal? If so, that seems
somewhat awkward. What would I do with those candidates? A
naive implementation would transit them to the other side, but
they seem useless there...

-Ekr


On Wed, Dec 12, 2012 at 2:13 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 12 December 2012 02:45, Harald Alvestrand <harald@alvestrand.no> wrote:
> >
> > - practical experience: How long are candidates usually valid for? If
> they
> > stop working (NAT timeout, TURN sever timeout), how can we tell?
>
> Some can be kept "warm" others can't be.  I would not expect the
> browser to take special steps to ensure validity.  A warning about
> this possibility should be aired.  Most usage patterns I can imagine
> wouldn't be likely to trigger the issue.
>
> That said, a browser might choose to place an expiration time on
> candidates such that old candidate sets are removed from the pool
> after a certain time.  At this point, I would expect that the browser
> could re-gather candidates to ensure that the pool remains at the
> prescribed label, OR (and this is my preference) just let the pool dry
> up.  This is consistent with the answer to the last question.
>
> > - if candidate pool is pre-filled, is the intention that
> > createOffer/createAnswer makes an offer that has the candidates
> available at
> > the time? (I think yes)
>
> Yes, I agree.  Mostly.  Pre-filling provides createOffer/createAnswer
> with some values.  I'm not sure what I would do in the case where only
> some proportion of the necessary candidate sets can be filled from the
> pool.  If we are not permitting incomplete offers (see trickle ICE),
> then this could be different.
>
> > - if candidate pool doesn't have the number of candidates needed, will
> > createOffer return an incomplete offer, and if one wants to have a
> complete
> > one, one has to wait for the necessary number of icecandidate events
> before
> > pulling a completed offer from localDescription (same as without the
> pool)?
> > (I think yes)
>
> Yes, definitely :)  Assuming that we persist with trickle ICE, this
> seems to be the way that the API works.
>
> > - are the candidates gone from the pool when createOffer has been
> called, or
> > will a new createOffer return the same candidates?
>
> I would expect that subsequent calls to createOffer are intended to
> create replacement offers.  That being the case, the same set of
> candidates might be used.
>
> Note: I don't believe that it makes sense to consider createOffer as
> an event that modifies the disposition of the pool.  The offer that is
> created might reference candidate sets that are in the pool, but they
> don't need to withdraw from it.  It's really setLocalDescription that
> needs to take action.  Again, this assumes that we are using trickle
> ICE, otherwise bringing this forward onto createOffer would be
> possible.
>
> > - if the pool has been depleted by a createOffer, is it ever refilled? (I
> > think not - when in established state, new candidates that don't
> correspond
> > to new addresses aren't needed)
>
> There is no sense in topping up the pool.  Then you get a bunch of
> candidates that are of no use to anyone.  The entire purpose of the
> pool is to be depleted by createOffer and setLocalDescription.
>
> There are still open items with respect to trickling.  If we permit
> incomplete offers and answers, then we might need some way to control
> that behavior by having a constraint on createOffer that disables
> trickling, to force the collection of candidates.  For instance, the
> Chrome implementation defers candidate gathering until after
> setLocalDescription, which leads to a need to call setLocalDescription
> and then await the completion of candidate gathering before signaling
> toward a non-trickle peer.
>
> --Martin
>
>