Re: [rtcweb] Default candidate pool size

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

>
>
>
> On Sun, May 18, 2014 at 10:15 AM, Justin Uberti <juberti@google.com>wrote:
>
>> 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,
>>
>
> 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.
>>
>>
>> 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
>>>>>
>>>>
>>>>
>>>
>>
>