Re: [rtcweb] Default candidate pool size

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 <ekr@rtfm.com> wrote:

>
>
>
> On Sun, May 18, 2014 at 10:05 AM, Justin Uberti <juberti@google.com>wrote:
>
>> 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.
>>
>
> 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
>
>
>> On Sun, May 18, 2014 at 9:56 AM, Cullen Jennings <fluffy@iii.ca> wrote:
>>
>>>
>>> how about just adding the pool size to RTCConfiguration ?
>>>
>>> On May 18, 2014, at 9:26 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>> > As far as I know, this has been agreed on, but the W3C spec has
>>> > never been updated to reflect it.
>>> >
>>> > -Ekr
>>> >
>>> >
>>> >
>>> > On Sat, May 17, 2014 at 11:04 AM, Cullen Jennings <fluffy@iii.ca>
>>> wrote:
>>> >
>>> > 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 <martin.thomson@gmail.com>
>>> wrote:
>>> >
>>> > > On 11 May 2014 17:18, Eric Rescorla <ekr@rtfm.com> wrote:
>>> > >>
>>> > >> 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.
>>> > >
>>> > > 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.
>>> > >
>>> > > _______________________________________________
>>> > > rtcweb mailing list
>>> > > rtcweb@ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/rtcweb
>>> > >
>>> >
>>> >
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>>
>