- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Tue, 22 Jan 2013 19:49:47 +0000
- To: Adam Roach <adam@nostrum.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
I think that URI are much more than a resolution mechanism and are meant to specify the resources - thus they should have the username as that is part of the resource for TURN. That said, totally agree the really important thing is to get these draft to agree.
On Jan 22, 2013, at 11:38 AM, Adam Roach <adam@nostrum.com>
wrote:
> In discussing our implementation of STUN and TURN URIs, it became apparent that there is a mismatch between what is currently proposed in the IETF and what is given as an example in the most recent W3C WebRTC editor's draft (as well as assumptions around what parameters are needed for defining an ICE server configuration record).
>
> From http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-03#appendix-A.4
>
> <username> is not used in the URIs because it is not used to guide
> the resolution mechanism.
>
>
> From http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcconfiguration-type
>
>> An example array of RTCIceServer objects is:
>>
>> [ { url:"stun:stun.example.net" } , { url:"turn:user@turn.example.org", credential:"myPassword"} ]
>>
>
> These need to be harmonized. I suspect we really need to define RTCIceServer to contain an optional "user" parameter of type DOMString, and give the example as:
>
> [ { url:"stun:stun.example.net" } , { url:"turn:turn.example.org", user:"myUsername", credential:"myPassword"} ]
>
> /a
Received on Tuesday, 22 January 2013 19:50:17 UTC