W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: RTCIceServer and username

From: Justin Uberti <juberti@google.com>
Date: Tue, 7 Jan 2014 15:57:27 -0800
Message-ID: <CAOJ7v-3OW6kXSG9jd_2xgW-N2rDs_UoJU+M-7R6TtcPe=8C9Dg@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Agree with Harald. This would probably be less of an issue if we had an API
mechanism to indicate that the TURN server could not provide candidates due
to an authentication failure.


On Mon, Jan 6, 2014 at 1:55 PM, Harald Alvestrand <harald@alvestrand.no>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.
>
>
Received on Tuesday, 7 January 2014 23:58:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC