Re: RTCIceServer and username

Thanks, that clears up my understanding.  I think a bit of extra
detail in section 4.2.2 could make this clearer, particularly the
description of the "urls" property.

Regards,
Gavin
--
Principal Design Engineer
Crocodile RCS Ltd
GPG key: 0xF8F6FFF2


On 15 January 2014 06:22, Justin Uberti <juberti@google.com> wrote:
> 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",
> "turn:23.251.128.79:3478?transport=tcp",
> "turn:23.251.128.79:3479?transport=udp",
> "turn: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 12:29:59 UTC