Subject: [rtcweb] Default candidate pool size

From: Eric Rescorla <[email-masked]>
Date: Sun, 11 May 2014 17:18:52 -0700

https://github.com/rtcweb-wg/jsep/issues/12

JSEP says:
S 4.1.1.
" The PeerConnection constructor allows the application to specify
global parameters for the media session, such as the STUN/TURN servers
and credentials to use when gathering candidates. The size of the ICE
candidate pool can also be set, if desired; by default the candidate
pool size is zero."

The WebRTC spec says:
"At this point the ICE Agent does not know how many ICE components it
needs (and hence the number of candidates to gather), but it can make
a reasonable assumption such as 2. As the RTCPeerConnection object
gets more information, the ICE Agent can adjust the number of
components"

These need to be harmonized.

My personal opinion is that candidate pooling is useful here and we
should probably leave the default in the hands of the browser. I
could live with 0 however.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 May 2014 10:15:43 -0700

> could live with 0 however.

I tend to agree.  The selection of a default seems like a good
opportunity for browsers to optimize.  For instance, a mobile device
might choose to defer gathering until it knows that it needs them;
whereas a device with a good source of power might prefer the latency
benefits associated with early gathering.  No point in us specifying
this.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 17 May 2014 13:04:44 -0500

I think the JS app needs a way to say what it needs in the way of pool size. 

On May 12, 2014, at 12:15 PM, Martin Thomson <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 May 2014 06:26:10 -0700

As far as I know, this has been agreed on, but the W3C spec has
never been updated to reflect it.

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 18 May 2014 12:56:31 -0400

how about just adding the pool size to RTCConfiguration ?

---

From: Justin Uberti <[email-masked]>
Date: Sun, 18 May 2014 10:05:54 -0700

Sounds good to me. As to the default, I'm fine with leaving it unspecified.

Regarding the email from Kiran:
- onicecandidate never fires until after setLocalDescription is called,
regardless of candidate pooling. Candidate pooling just causes any pooled
candidates to be emitted immediately once setLocalDescription is called.
- candidates specified in setLocalDescription are ignored. We could make it
an error to pass in candidates that the browser hasn't given to you, but
that doesn't seem super critical.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 May 2014 10:11:00 -0700

On Sun, May 18, 2014 at 10:05 AM, Justin Uberti <[email-masked]> wrote:

> - candidates specified in setLocalDescription are ignored. We could make
> it an error to pass in candidates that the browser hasn't given to you, but

This seems like it's coupled to the more general question of how
we behave when someone passes in stuff in SetLocal that doesn't
correspond to stuff we allow you to change in the SDP. My general
preference would be an error in all such cases, but I could be talked
out of that.

-Ekr

---

From: Justin Uberti <[email-masked]>
Date: Sun, 18 May 2014 10:15:28 -0700

That would be my preference as well. Due to timing, it shouldn't be an
error to pass in a local desc that has *fewer* candidates than the ICE
agent knows about, but you should never be able to pass in more.

On Sun, May 18, 2014 at 10:11 AM, Eric Rescorla <[email-masked]> wrote:

>
>
>
> On Sun, May 18, 2014 at 10:05 AM, Justin Uberti <[email-masked]>wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 May 2014 10:38:32 -0700

On Sun, May 18, 2014 at 10:15 AM, Justin Uberti <[email-masked]> wrote:

> agent knows about,

However, i would prefer it doesn't have any impact on which
candidates are used, since nothing makes you do setLocalDescription()
with any ICE candidates. If we need some way to refuse an ice candidate
(which I don't think we do) it should be in onicecandidate.

-Ekr

>  but you should never be able to pass in more.
>
>

---

From: Justin Uberti <[email-masked]>
Date: Sun, 18 May 2014 10:54:58 -0700

It should have absolutely no impact on which candidates are used, given
that the ICE agent is cranking away on its own and any preferences
expressed here (or even in onicecandidate) will suffer from races.

IOW, we should ignore the candidate list supplied completely, unless we
want to just ensure that we haven't been given garbage, in which case we
can check for that and error out.

On Sun, May 18, 2014 at 10:38 AM, Eric Rescorla <[email-masked]> wrote:

>
>
>
> On Sun, May 18, 2014 at 10:15 AM, Justin Uberti <[email-masked]>wrote:
>
>>>> - candidates specified in setLocalDescription are ignored. We could
>>>> make it an error to pass in candidates that the browser hasn't given to
>>>> you, but that doesn't seem super critical.
>>>>
>>>

---

From: Martin Thomson <[email-masked]>
Date: Sun, 18 May 2014 19:13:22 -0700

On 18 May 2014 10:54, Justin Uberti <[email-masked]> wrote:
> IOW, we should ignore the candidate list supplied completely, unless we want
> to just ensure that we haven't been given garbage, in which case we can
> check for that and error out.

I think that's a fine idea; all options.  Pick one.