Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

[Sergio Garcia Murillo <[e-mail]>]

Sergio Carcia Murillo wrote:
>> El 22/09/2013 0:48, Hutton, Andrew escribió:
>>> I just don't see any advantage in the TURN over Websockets approach over
>> the HTTP Connect initiated tunnel which works without any new protocol and
>> therefore works with existing TURN servers.
>>
>> How about transparent proxying?
>>
> Can you elaborate on this?
>
> I think in either case the proxy sees possibly one transaction. In TURN over HTTP CONNECT established TLS connection, the proxy sees the HTTP CONNECT transaction and it's destination URI. If it's just "transparently" proxying, things will work, which is what we want. On the other hand, if there is some explicit policy, the proxy can also apply it - for instance if the destination domain is now allowed. I'm not sure if the TURN over WS has any advantages in this regard.
I was meaning that if a transparent proxy is in place you won't be able 
to do directly the HTTP connect request.

> The disadvantage is that TURN over WS would require a change to TURN servers. I know you have argued that it is a very trivial change and I believe you, but nevertheless all existing servers would need to be upgraded and that's the problem.
>
While I agree, this issue has not been a show-stopper for adopting new 
technologies in WebRTC ;) . Also, there are already other proposals 
(like HTTP REST apis for TURN servers) that would require changes to the 
existing TURN server deployments.

Anyway, in our first prototype, we would try to demonstrate how TURN 
over websockets could be used with an un-modified  TURN server via a 
websockify proxy.

Best regards
Sergio