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

[Oleg Moskalenko <[e-mail]>]

Hi Andy

please see below in the text:

On Wed, Sep 25, 2013 at 2:59 AM, Hutton, Andrew <
[e-mail]> 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.


>
> 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.


>  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.


>
> 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.


> 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.


>
> 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.


>
> 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.


>
> 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.

Thanks
Oleg