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

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 <mailto: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>
>             <mailto: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.
>
>
>