W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2012

Re: candidate warm up

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 12 Dec 2012 14:13:06 -0800
Message-ID: <CABkgnnUVbJKh5fqi03PTRUWat2VPj=a--H7edDGT74ewE2os-w@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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

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

Received on Wednesday, 12 December 2012 22:13:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:32 UTC