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

Re: RTCIceServer and username

From: Alex Gouaillard <alex.gouaillard@temasys.com.sg>
Date: Sat, 11 Jan 2014 13:34:01 +0800
Message-Id: <A794EBCF-6261-4D2A-935F-F9C89FB6739D@temasys.com.sg>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
To: Gavin Llewellyn <gavin.llewellyn@crocodilertc.net>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC