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

Re: RTCIceServer and username

From: Justin Uberti <juberti@google.com>
Date: Tue, 14 Jan 2014 22:22:55 -0800
Message-ID: <CAOJ7v-12dUdYFbW6YkxeCk5-Fm64ixyThuO7G+Gw2rVFYrp6PA@mail.gmail.com>
To: Alexandre GOUAILLARD <agouaillard@gmail.com>
Cc: Gavin Llewellyn <gavin.llewellyn@crocodilertc.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Note that that isn't exactly right, since the AppRTC code was written to
deal with browsers that didn't support an array of URLs.

The correct usage here (assuming an up-to-date browser) is
"iceServers": [ {
 "urls":"stun:stun.l.google.com:19302"
}, {
 "credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=",
 "username":"75763028:1389749771",
 "urls":[
 "turn:23.251.128.79:3478?transport=udp<http://23.251.128.79:3478/?transport=udp>
",
 "turn:23.251.128.79:3478?transport=tcp<http://23.251.128.79:3478/?transport=tcp>
",
 "turn:23.251.128.79:3479?transport=udp<http://23.251.128.79:3479/?transport=udp>
",
 "turn:23.251.128.79:3479?transport=tcp<http://23.251.128.79:3479/?transport=tcp>
"
 ]
} ]


On Tue, Jan 14, 2014 at 5:41 PM, Alexandre GOUAILLARD <agouaillard@gmail.com
> wrote:

> @gavin,
>
> Illustration using today's appRTC if this helps, you can see multiple
> entry in the IceServer list of the same TURN server with identical
> credential, but different transport protocols
>
> "iceServers":
> [
> {"url":"stun:stun.l.google.com:19302"},
> {"url":"turn:23.251.128.79:3478?transport=udp",
> "credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=","username":"75763028:1389749771"},
> {"url":"turn:23.251.128.79:3478?transport=tcp
> ","credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=","username":"75763028:1389749771"},{"url":"turn:
> 23.251.128.79:3479?transport=udp
> ","credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=","username":"75763028:1389749771"},{"url":"turn:
> 23.251.128.79:3479?transport=tcp
> ","credential":"ZeM23JE1oKnuaEG5AZCHuSeQ1RM=","username":"75763028:1389749771"}
> ]
>
>
>
> On Wed, Jan 15, 2014 at 3:25 AM, Justin Uberti <juberti@google.com> wrote:
>
>> The intent was that distinct servers would have distinct RTCIceServer
>> entries.
>>
>> The multiple URLs should be used when a single server has multiple ways
>> of being reached (e.g. multiple transport protocols), but the same
>> credentials should be used for each transport protocol.
>>
>>
>> On Fri, Jan 10, 2014 at 8: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 :.
>>> >
>>>
>>>
>>>
>>
>
>
> --
> Alex. Gouaillard, PhD, PhD, MBA
>
> ------------------------------------------------------------------------------------
> CTO - Temasys Communications, S'pore / Mountain View
> President - CoSMo Software, Cambridge, MA
>
> ------------------------------------------------------------------------------------
> sg.linkedin.com/agouaillard
>
>    -
>
>
Received on Wednesday, 15 January 2014 06:23:43 UTC

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