W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

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

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Thu, 23 Jan 2014 19:42:08 -0500
Message-ID: <52E1B6E0.9080709@mozilla.com>
To: Justin Uberti <juberti@google.com>, Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 - 

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.


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

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

.: Jan-Ivar :.
Received on Friday, 24 January 2014 00:42:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:54 UTC