Subject: [rtcweb] JSEP: why is iceCandidatePoolSize an integer?

From: Philipp Hancke <[email-masked]>
Date: Thu, 3 Dec 2015 13:46:12 -0800

I'm not sure where this has been discussed... so:
why is the iceCandidatePoolSize an integer?

Is the application supposed to guess (taking rtcp-mux and 
bundle-strategy into account) what is a good number of candidates to 
gather in advance? Do multiple local interfaces/candidates count toward 
this?

Being able to specify a strategy (host/srflx/relay?) to indicate that 
candidates of a certain type shall be pre-gathered seems like a more 
direct way to accomplish the goal and would also be more transparent 
about the kind of resources that will be used.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 4 Dec 2015 15:48:34 +1100

On 4 December 2015 at 08:46, Philipp Hancke <[email-masked]> wrote:
> Is the application supposed to guess (taking rtcp-mux and bundle-strategy
> into account) what is a good number of candidates to gather in advance?

No, though it benefits most if it is able to make a good guess.  Too
high and there are candidates gathered that aren't used.  Too low and
gathering for those components is delayed.  Note that in most cases,
with trickle, aiming low is probably OK since you don't move on to a
component until you have connected the first (**caveat on a bunch of
things regarding trickle of course).

> Do
> multiple local interfaces/candidates count toward this?

No, this counts components.

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 4 Dec 2015 09:29:56 -0800

> things regarding trickle of course).

That clears up things a bit, thanks.

But if this is about components, how can the application make a decision 
whether to pre-gather and hold on to stun or relay candidates (which 
consumes resources)?

> No, this counts components.

Calling it iceCandidatePoolSize in the w3c spec seems odd to me then ;-)

---

From: Martin Thomson <[email-masked]>
Date: Sat, 5 Dec 2015 20:40:56 +1100

> whether to pre-gather and hold on to stun or relay candidates (which

The application might be able to defer the gathering of candidates via
relays (I don't think that STUN is a real resource concern) by only
providing the relays as stun URIs, or not providing them at all, then
updating the iceServers with setConfiguration.

I don't know if this is something that would work, we'd have to spec that.

I'm actually beginning to question the utility of the pre-warming
thing.  Maybe it's a performance gain, but it's certainly quite
complex.

> Calling it iceCandidatePoolSize in the w3c spec seems odd to me then ;-)

Yeah, I'm sure that - given it's current level of interoperability
(i.e., zero) - the working group might be receptive to suggestions of
a more accurate name.