Re: ACTION-95: Constraints usage in the WebRTC spec

Practically speaking, username/credential is useless when using a STUN
server, and required when using a TURN server, but they aren't required by
spec, and so I'm not sure it helps to do any much verification on those
inputs.

So I would say we should
- ensure urls contains at least one entry
- ensure each url protocol is something we understand
- ensure (probably) the url syntax is correct
- if username or password is specified, both have to be present


On Thu, Jan 23, 2014 at 4:32 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 01/23/2014 07:52 AM, Adam Bergkvist wrote:
>
>> On 2014-01-23 02:49, Justin Uberti wrote:
>>
>>>
>>> On Wed, Jan 22, 2014 at 4:01 AM, Adam Bergkvist
>>> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>>
>>> wrote:
>>>
>>>     The other values could then be left unchanged. I anyhow think we
>>>     need to make the configuration, or the components of the
>>>     configuration, gettable from the object when it has been created.
>>>
>>>
>>> Are you suggesting adding a pc.configuration getter?
>>>
>>
>> Yes (it would have to be a getter method though)
>>
>>      The other question remains. What happens if I do:
>>>
>>>     pc.updateIce({ "iceServers": totallyNewListOfServers });
>>>
>>>
>>> I think that the new list of servers should replace the previous list,
>>> but no other actions should happen at that time. Upon the next
>>> transition back to a "gathering" state, the new ICE servers should be
>>> used; if the app wants that to happen immediately, it should do an ICE
>>> restart. With this approach, .iceServers is idempotent.
>>>
>>
>> Let's document this is the spec. We can change it if it's turns out to be
>> the wrong approach.
>>
>> The only remaining question mark is what can go wrong when setting
>> iceServers. What do we have except SyntaxError on unparsable urls. Any
>> invalid combinations of protocol, username and credential?
>>
>
> We have follow-on bugs such as invalid credentials that are discovered
> when trying to contact the TURN server. But it's unrealistic to have those
> as return values from updateIce.
>
>
>