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

["Hutton, Andrew" <[e-mail]>]

See below.

Andy

> -----Original Message-----
> From: Oleg Moskalenko [mailto:[e-mail]]
> Sent: 25 September 2013 16:46
> To: Hutton, Andrew
> Cc: [e-mail]
> Subject: Re: [pntaw] TURN over websockets or just TURN.
> 
> Hi Andy
> 
> please see below in the text:
> 
> On Wed, Sep 25, 2013 at 2:59 AM, Hutton, Andrew <andrew.hutton@siemens-
> enterprise.com> wrote:
> 
> 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.
> 
> HTTP CONNECT is used only when an explicit proxy is present. Websockets
> can provide improved connectivity when NO explicit proxy is present
> 
> 
> 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.
> 
> That overhead is relatively minor.

[AndyH] But it is still something that we would be better without unless it serves a good purpose.

> 
> 
> 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.
> 
> No, in this particular case the purpose is to use HTTP protocol as a
> tunnel for TURN protocol.
>

[AndyH] Not really the proposal is to encapsulate TURN within a websockets connection not HTTP. 


> 
>  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.
> 
> I do not understand how a web server jumped into the picture. The
> proposal has nothing to do with the web servers.
> 

[AndyH] Exactly the media handling has nothing to do with the web server but websockets uses HTTP upgrade mechanism because it was designed to allow the web server to use the same port for HTTP and websockets (See http://tools.ietf.org/html/rfc6455#section-1.3). This mechanism is not needed in WebRTC because the web server and TURN server are not the same server.

> 
> So does encapsulating the TURN data in websocket frames provide any
> benefit.
> 
> It provides a benefit of encapsulating TURN protocol into HTTP protocol
> that is usually easily understandable and "parseable" by the firewalls.
> The firewall can examine the subprotocol header and make a decision.
> 

[AndyH] The subprotocol is nice but I assume the firewall only sees this if the websockets connection is not encrypted it seems to me that it might be better to have something like the subprotocol indicating TURN in the HTTP CONNECT making it clear to the proxy the purpose of the connection encrypted or not.

> 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.
> 
> There are scenarios when difference between HTTP and TURN is as simple
> as "connectivity" vs "no connectivity". That's rather important.
> 

[AndyH] Can you explain in what scenarios TURN over Websockets would work and TURN/TCP with HTTP Connect would not?


> 
> The extra websockets overhead for all the media packets is surely a
> drawback of this approach.
> 
> When no packets can be passed through, then the network overhead is
> exactly 0 (zero) but we do not consider it as a great scenario.
> 

[AndyH] I am not sure I understand your point here. If there are no significant advantage to using the websockets encapsulation and I have not heard one yet, then the overhead is again something we could do without.


> 
> Not encapsulating the TURN in websockets would also probably provide
> better control for those wanting to assert policies on the handling of
> media.
> 
> DPI of the TURN packets is a hard task, especially considering that the
> IP addresses in the TURN packets are obfuscated. On the other hand, we
> may require some headers in the websocket connection to contain
> information about the protocol, so it may be more firewall-friendly and
> "examinable", without serious investment into new DPI algorithms.
> 

[AndyH] I don't think we should discuss DPI it should simply be out of scope.

> 
> 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.
> 
> 
> I hope I provide an opinion.

[AndyH] You have but I am not yet convinced of the benefit I think we need concrete examples of why a websockets approach would be more successful than just TURN/TCP using HTTP CONNECT.


> Thanks
> Oleg
>