Re: [pntaw] TURN over websockets

Hi Markus,

I see some benefits for websockets over HTTP connect, but may be due to 
my own deployment choices, but I would be ok with it also.

One point that I see against http connect is that it is meant to be used 
as a fallback scenario, while with websockets you could use it always, 
regardless if there is any http proxy in place or not.

Best regards
Sergio

El 30/08/2013 14:52, Markus.Isomaki@nokia.com escribió:
> Hi Sergio, Thomas,
>
> I also assume that we should run TURN over TLS directly, or by establishing that connection via a proxy using HTTP CONNECT. The first method would work in networks that allow outbound TLS/TCP connections, while the other would work even in networks that only allow outbound communication via a proxy.
>
> As Thomas says, the benefit of TURN/TLS instead of TURN/WS/TLS is that no changes would need to be applied to existing TURN servers. Only the client side establishment (by the browser) would need to include the use of HTTP CONNECT.
>
> But is there some advantage why Websockets should be used? WS does have the explicit HTTP based handshake, which is supposed to make it somehow middlebox "friendlier". But I don't know how that is better than HTTP CONNECT in that sense.
>
> Regards,
> 	Markus
>
>
>> -----Original Message-----
>> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
>> Of ext Stach, Thomas
>> Sent: 30 August, 2013 15:35
>> To: Sergio Garcia Murillo; pntaw@ietf.org
>> Subject: Re: [pntaw] TURN over websockets
>>
>> Sergio,
>>
>> Some comments inline
>>
>>> -----Original Message-----
>>> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
>> Behalf
>>> Of Sergio Garcia Murillo
>>> Sent: Freitag, 30. August 2013 10:42
>>> To: pntaw@ietf.org
>>> Subject: [pntaw] TURN over websockets
>>>
>>> Hi all,
>>>
>>> I will shoot first.
>>>
>>> It is great to finally see some real interest in what I consider to be
>>> the blocking point for webrtc in order to run business on top of it,
>>> which is the ability to be able to connect through corporate firewalls.
>>>
>>> I have seen some people arguing that with just TURN over TCP on port
>>> 443
>>> the problem will be solved, but I seriously doubt it. Neither TURN
>>> over SSL would do, as most web filters do DPI and will not enable the
>>> connection. Also, I have heard lots of voices that says we are trying
>>> to override network admin policies with dirty tricks. With whom, I
>>> could agree.
>> [TS] I'm not sure if you are referencing draft-hutton-rtcweb-nat-firewall-
>> considerations here.
>> Nevertheless the draft mentions TURN over TCP to port 443.
>> The goal behind this is certainly not to sneak WEBRTC media streams through
>> heavily fortified networks that have DPI deployed.
>> The goal rather to address a scenario e.g. at a small hotel with a not-so-skilled
>> network admin, that opened his firewall on TCP port 80/443 to allow its
>> guests to do some web browsing, but is afraid of opening its firewall for UDP
>> traffic.
>> If we want to deploy WEBRTC in such an environment TURN over TLS to port
>> 443 would do the job.
>>
>>> So, the only way I see to move forward and overcome this issues is by
>>> playing according to the WEB rules, and use HTTP standards to enable
>>> media connectivity in WebRTC that would play nicely with current
>>> corporate HTTP proxies and web filters.
>> [TS] Playing nicely with HTTP proxies is also a use case draft-hutton-rtcweb-
>> nat-firewall-considerations.
>> Usage of the HTTP CONNECT method is proposed here. The request URI
>> would include the TURN server (preferably even to the well-known STUN
>> port). If the network admin put the TURN server into its whitelist, that could
>> hardly be considered as sneaking unwanted traffic through.
>>> And,  for me the most viable solution would be to enable TURN over
>>> websockets.
>> [TS] This would require updates to the TURN protocol and the TURN
>> software, whereas the proposals in draft-hutton-rtcweb-nat-firewall-
>> considerations use the original transports.
>> As most WebRTC services relay on websockets in one way or
>>> another for signaling, we could assume that media would work on 100%
>>> of the cases where signaling is working today.
>>> Also, as it is an http based solution, network administrators could
>>> apply corporate policies and block connections to not-trusted TURN
>>> servers.
>> [TS] which could also be done by white-listing the TURN server address via
>> TCP without any further intermediate HTTP/Websocket layers.
>>
>> Regards
>> Thomas
>>
>>> Best regards
>>> Sergio
>>> _______________________________________________
>>> pntaw mailing list
>>> pntaw@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pntaw
>> _______________________________________________
>> pntaw mailing list
>> pntaw@ietf.org
>> https://www.ietf.org/mailman/listinfo/pntaw