Re: [rtcweb] URI schemes for TURN and STUN

[Harald Alvestrand <[e-mail]>]

On 11/05/2011 06:20 PM, Ned Freed wrote:
>> On 11/04/2011 04:56 PM, Eric Rescorla wrote:
>> > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed<[e-mail]>  
>> wrote:
>> >>> Top-posting a general principle, detailed comment at the bottom....
>> >>> For all URI schemes, I think the URI needs to contain all the
>> >>> information you need in order to make contact with the service; you
>> >>> can't negotiate until you've made contact.
>> >>> (the process may involve things like "resolve through a resolution
>> >>> mechanism like DNS" or "get authorization tokens from somewhere 
>> else").
>> >>> In the case of TURN, you need to distinguish between TCP, UDP and 
>> TLS,
>> >>> and you need to make that determination before you send the first
>> >>> packet. That means the distinguishing information between those 
>> three
>> >>> things belongs in the URL; I don't think the scheme is a good 
>> place to
>> >>> encode it.
>> >> I'm in complete agreement with Harald on all of these points. And 
>> while it
>> >> would have been nice if URL syntax was less messy and more 
>> general, making
>> >> it easier to do these sorts of things in a consistent way, it 
>> quite simply
>> >> isn't and we have to make do with what we have.
>> > I don't have any commitment to the scheme. What's the best place?
>
>> I like parameters, like this:
>
>> turn://user@host?proto=tcp
>
>> Quite hard to misunderstand, and quite easy to extend.
>
>> (Note: // is only allowed if what follows is [user[:pass]@]host - I
>> don't recommend using the password, for the obvious reasons, but the
>> syntax will allow it.)
>
> Given your earlier characterization of the TCP/UDP/TLS distinction being
> a single axis, I assume you mean that you'd say:
>
>  turn://user@host?proto=tls
>
> and not
>
>  turns://user@host?proto=tcp

I was thinking

    turn://<user>@<host>?proto=<udp, tcp or tls>

but thought that this was going too far into details.
>
> I have to say I prefer the parameter approach, but I wonder if these 
> really
> are along a single axis - is DTLS a possibility here?
DTLS is a possibility, if the TURN protocol is extended to support it, 
and would be a fourth parameter value. Currently it's not specified (AFAIK).

My opinion is that the URL needs to contain the context that the TURN 
client needs to know before it can contact the TURN server. There may be 
options that can reasonably be negotiated in the TURN channel setup 
procedure; those don't need to be in the URL.

My current reading is that with the current TURN spec, the initial 
packets sent by the user is different for the 3 cases TCP, UDP and TLS.