Re: RTCIceServer and username

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

Received on Friday, 10 January 2014 16:38:13 UTC