Re: RTCIceServer and username

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