Subject: [rtcweb] JSEP: Question relating to ICE candidate pool

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Feb 2015 10:40:02 -0800

A question has arisen with respect to draft-ietf-rtcweb-jsep-08 Sections
3.4.4 and 4.1.2.  Exerpts from these sections are enclosed below.

While Section 3.4.4 refers to "pre-gathering" of ICE candidates prior to
calling of setLocalDescription(), Section 4.1.2 states that createOffer()
does not result in candidate gathering.

One way to interpret this is that while createOffer() does not result in
firing of the onicecandidate callback (which needs to wait until
setLocalDescription() is called), it is ok (or even encouraged) for the
implementation to begin "pre-gathering" ICE candidates into the ICE
candidate pool once createOffer() is called.

Is this a reasonable interpretation or is there another way this
could/should be read?

Section 4.1.2 createOffer:

   Calling this method may do things such as generate new ICE
   credentials, but does not result in candidate gathering, or cause
   media to start or stop flowing.

Section 3.4.4 ICE candidate pool:

   JSEP applications typically inform the browser to begin ICE gathering
   via the information supplied to setLocalDescription, as this is where
   the app specifies the number of media streams, and thereby ICE
   components, for which to gather candidates.  However, to accelerate
   cases where the application knows the number of ICE components to use
   ahead of time, it may ask the browser to gather a pool of potential
   ICE candidates to help ensure rapid media setup.

   When setLocalDescription is eventually called, and the browser goes
   to gather the needed ICE candidates, it SHOULD start by checking if
   any candidates are available in the pool.  If there are candidates in
   the pool, they SHOULD be handed to the application immediately via
   the ICE candidate callback.  If the pool becomes depleted, either
   because a larger-than-expected number of ICE components is used, or
   because the pool has not had enough time to gather candidates, the
   remaining candidates are gathered as usual.

   One example of where this concept is useful is an application that
   expects an incoming call at some point in the future, and wants to
   minimize the time it takes to establish connectivity, to avoid
   clipping of initial media.  By pre-gathering candidates into the
   pool, it can exchange and start sending connectivity checks from
   these candidates almost immediately upon receipt of a call.  Note
   though that by holding on to these pre-gathered candidates, which
   will be kept alive as long as they may be needed, the application
   will consume resources on the STUN/TURN servers it is using.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Feb 2015 09:44:55 +1300

I recall that the gathering could start at any point. At one point, Firefox
was gathering immediately after construction. I think that the intent was
to have pre-gathering start when the setting was applied.
On Feb 25, 2015 7:40 AM, "Bernard Aboba" <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 24 Feb 2015 14:40:15 -0800

> candidate pool once createOffer() is called.

The way I understood this was that you would start pre-gathering as soon as
the pool
size was increased to > 0. I.e., potentially before CreateOffer

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Tue, 24 Feb 2015 18:45:16 -0800

Exactly what Eric said. createOffer is probably too late to be useful in
many cases.

On Tue, Feb 24, 2015 at 2:40 PM, Eric Rescorla <[email-masked]> wrote:

> The way I understood this was that you would start pre-gathering as soon
> as the pool