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

On Thu, Jan 23, 2014 at 4:42 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

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

I was wrong. RFC5766, Section 4, Para 3 indicates that long-term
credentials MUST be used to authenticate all TURN requests. This might
change with the work we are doing to spec the use of 'ephemeral'
credentials, but for now it should be illegal to omit username/credential
from a TURN server.

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

Yes.