Re: RTCIceServer and username

You could have several times the same turn server with the same credentials but using different transport protocols, for example. Each transport protocol need to be passed in a separate URI.

Sent from my iPhone

On 11 Jan, 2014, at 12:03 AM, Gavin Llewellyn <gavin.llewellyn@crocodilertc.net> wrote:

> On a related note, I see the RTCIceServer dictionary has been updated
> to accept multiple URLs.  Is this just for convenience when you have
> multiple TURN servers that accept the same credentials?  I'm left
> slightly confused as to whether I should be providing multiple
> RTCIceServer dictionaries in my RTCConfiguration, or a single one with
> multiple URLs - this does not seem to be explained in the current
> text.  I think the confusion stems from the name of the dictionary; it
> suggests that multiple URLs should refer to the same server.
> 
> If it is just for convenience, what about if I am using a TURN server
> and a STUN server (in case the TURN server is unavailable)?  The
> current example puts them in separate dictionaries, but then the
> current example does not demonstrate providing multiple URLs.  Can
> they be specified in a single RTCIceServer dictionary for simplicity
> (assuming the credentials will be ignored when contacting the STUN
> server)?
> 
> Regards,
> Gavin
> 
> --
> Principal Design Engineer
> Crocodile RCS Ltd
> GPG key: 0xF8F6FFF2
> 
> 
> On 8 January 2014 19:38, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> On 1/6/14 4:55 PM, Harald Alvestrand wrote:
>> 
>> On 01/06/2014 05:06 PM, Eric Rescorla wrote:
>> 
>> http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtcconfiguration-members
>> has:
>> 
>> dictionary RTCIceServer {
>>     (DOMString or sequence<DOMString>) urls;
>>     DOMString?                         username = null;
>>     DOMString?                         credential;
>> };
>> 
>> AFAICT, username isn't really optional for TURN servers (RFC 5766 says):
>> 
>>    [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.
>> 
>> (and username and credential should have the same status in any case).
>> 
>> I suspect we either need two classes (one for TURN and one for STUN)
>> or explanatory text saying that you need to provide this for TURN.
>> 
>> 
>> Explanatory text seems like the right path to me. Since it contains URLs,
>> the syntax doesn't constrain it to be TURN or STUN, and the quoted text does
>> seem to make it possible that there will be other ways to do this
>> authentication.
>> 
>> 
>> +1. A separate class wouldn't do any good because dictionary members are
>> inherently optional.
>> 
>> I think the prose should say UAs MUST check and throw for TURN.
>> 
>> While we're looking at this...
>> 
>> Having username and credential be nullable (i.e. explicitly supporting the
>> passing-in of the value null) seems unnecessary and a mistake. Is it too
>> late to tighten this up as follows?
>> 
>> dictionary RTCIceServer {
>>    (DOMString or sequence<DOMString>) urls;
>>    DOMString                          username;
>>    DOMString                          credential;
>> };
>> 
>> If that looks wrong, consider it really being like this:
>> 
>> dictionary RTCIceServer {
>>    optional (DOMString or sequence<DOMString>) urls;
>>    optional DOMString                          username;
>>    optional DOMString                          credential;
>> };
>> 
>> 
>> Which is what it essentially is (optional is inherent in dictionary
>> members).
>> 
>> A common confusion in webidl is between:
>> 
>> Optional (the keyword 'optional' or anything in a dictionary): The ability
>> to omit.
>> Nullable (the '?' operator): Adds null to the values acceptable to pass in
>> or hold.
>> Default (the '=' operator, valid only with optional): in practice removes
>> implementer burden/ability to check whether something was passed in.
>> 
>> .: Jan-Ivar :.
> 
>

Received on Saturday, 11 January 2014 05:34:34 UTC