Re: RTCIceServer and username

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