Re: RTCIceServer and username

@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

   -