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

On 1/23/14 5: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.

Oh, I missed that. They're not required by the spec? A TURN server 
without username and password?

> 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

Hmm, right now we throw on missing username or credential for TURN - 
http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0007.html

Is the requirement then that we should fail later when it fails to 
connect instead?

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

+1.

>             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)
>

+1.

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

+1.

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

Just checking: updateIce would still be synchronous and throw exceptions 
like a normal method yes?

.: Jan-Ivar :.