Re: [pntaw] TURN over websockets or just TURN.

Hi,

I completely agree with Andy. The main point is this:

> In the presence of an explicit proxy the websockets approach is to use HTTP
> CONNECT to traverse the proxy (RFC 6455)

So, basically both approaches (to connect to a TURN server via a proxy), with or without WebSockets, use the same initial step. WS to my understanding would just introduce 1) an additional HTTP Upgrade handshake and 2) an additional encapsulation header. 

I don't think we need 1) because both ends already know that the protocol is TURN. 2) I think is just overhead.

Markus 

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> Of ext Hutton, Andrew
> Sent: 25 September, 2013 12:59
> To: pntaw@ietf.org
> Subject: [pntaw] TURN over websockets or just TURN.
> 
> Some thoughts on comparing the TURN over Websockets approach in draft-
> chenxin-behave-turn-websocket and the HTTP Connect (Without
> websocket) approach discussed in draft-hutton-rtcweb-nat-firewall-
> considerations.
> 
> Please note that my motivation is simply to find a good solution to deploying
> WebRTC in the presence of web proxies / firewalls and I am not tied to any
> particular solution.
> 
> In the presence of an explicit proxy the websockets approach is to use HTTP
> CONNECT to traverse the proxy (RFC 6455) so the question is whether there
> are any advantages or disadvantages to wrapping TURN with the websockets
> layer as this cannot be about the use of HTTP CONNECT which is used by in
> both solutions.
> 
> Websockets adds some overhead as there is an extra handshake that takes
> place with the server and there is some extra overhead in the data
> encapsulation.
> 
> The purpose of the extra HTTP handshake to upgrade to HTTP to a
> websockets connection is to allow an HTTP Server to use the same port for
> both HTTP and the websockets protocol.  However I don't think this is
> necessary for WebRTC media connections as it is very unlikely that a web
> server will want to handle WebRTC media/TURN at all never mind on the
> HTTP port as the media.
> 
> So does encapsulating the TURN data in websocket frames provide any
> benefit. I can imagine that there might be some scenarios in which using a
> websockets connection might work when TURN might not simply because
> the media is buried in further layers of encapsulation. However I don't know
> if this is really the case and also we are of course not trying to hide the fact
> that this is media.
> 
> The extra websockets overhead for all the media packets is surely a
> drawback of this approach.
> 
> Not encapsulating the TURN in websockets would also probably provide
> better control for those wanting to assert policies on the handling of media.
> 
> Therefore as you can see I don't see the benefit of encapsulating TURN in
> websockets but I look forward to hearing other opinions and maybe I have
> missed something important.
> 
> Regards
> Andy
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw