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

From: Justin Uberti <[email-masked]>
Date: Fri, 8 Jan 2016 17:22:49 -0800

[late to the party]

I'd be reluctant to add any more complexity to the operation of the
candidate pool - as Martin points out, it is already quite complex.

If you don't want to pregather all types of candidates, just don't use it.

On Sat, Dec 5, 2015 at 1:40 AM, Martin Thomson <[email-masked]>
wrote:

> On 5 December 2015 at 04:29, Philipp Hancke <[email-masked]>
> wrote:
> > 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)?
>
> 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.
>
> >> No, this counts components.
> >
> >
> > 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.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 10 Jan 2016 09:23:25 -0800

I agree with Justin. Remember that this is an optimization and it only
impacts
the *timing* of the delivery of the candidates. If we get to the point
where w
find that this wasn't enough control, we should be able deal with that
later i
a backward compatible way.

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Jan 2016 12:37:41 -0700

+1

I think that most people that want to use the pre-gather can make a reasonable guess of how many candidates they need to get "quickly" (to get the main call up). If it takes a bit longer for all the variable things such as thumb nails, that does not impact the UX in the same way.

> On Jan 10, 2016, at 10:23 AM, Eric Rescorla <[email-masked]> wrote:
> 
> I agree with Justin. Remember that this is an optimization and it only impacts
> the *timing* of the delivery of the candidates. If we get to the point where w
> find that this wasn't enough control, we should be able deal with that later i
> I'd be reluctant to add any more complexity to the operation of the candidate pool - as Martin points out, it is already quite complex.
> 
> On Sat, Dec 5, 2015 at 1:40 AM, Martin Thomson <[email-masked]> wrote:
> On 5 December 2015 at 04:29, Philipp Hancke <[email-masked]> wrote: