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

Yeah, that's the paragraph I was referring to as well. Agree with your
conclusion.


On Fri, Jan 24, 2014 at 12:20 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  On 01/23/2014 11:22 PM, Justin Uberti wrote:
>
> 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.
>
>
> The spec is actually pretty harsh on this point:
>
>
>
>    [RFC5389] specifies an authentication mechanism called the long-term
>    credential mechanism.  TURN servers and clients MUST implement this
>    mechanism.  The server MUST demand that all requests from the client
>    be authenticated using this mechanism, or that a equally strong or
>    stronger mechanism for client authentication is used.
>
>
>
> Given that we have no standardized "equally strong or stronger mechanism",
> and any such mechanism would probably require the structure to be extended
> with more information, I think it's valid for the browser to throw an
> exception when TURN is indicated and the username and/or password are
> missing.
>
>
>
>  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.
>>
>>
>>
>
>