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

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

Hi Andy,

Some comments inline.

Best regards
Sergio

El 25/09/2013 11:59, Hutton, Andrew escribió:
> 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.

So am I  :)

> 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
 From my understanding if you use secure websockets it will use HTTP 
CONNECT as any other HTTPS connection, but if non-secure websockets are 
used over port 80, HTTP CONNECT won't be done. Before anyone jumps in 
regarding using a non-secure websockets, let's remind that this would  
be as secure as TURN over TCP and that data will be already secured by 
DTLS.

> 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.
Yes it is just one HTTP request/response and a max of 8 byte headers. 
However if TURN over websockets is run un-secured, you will have less 
processing overhead due to the TLS encription.
> 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.
No, it isn't, the main purpose is to be able to traverse proxies with 
DPI that will drop the HTTP CONNECT with TURN over TLS. But, been an 
HTTP protocol, you would gain some extra functionalities for free.
> 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.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-------+-+-------------+-------------------------------+
      |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
      |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
      |N|V|V|V|       |S|             |   (if payload len==126/127)   |
      | |1|2|3|       |K|             |                               |
      +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
      |     Extended payload length continued, if payload len == 127  |
      + - - - - - - - - - - - - - - - +-------------------------------+
      |                               |Masking-key, if MASK set to 1  |
      +-------------------------------+-------------------------------+
      | Masking-key (continued)       |          Payload Data         |
      +-------------------------------- - - - - - - - - - - - - - - - +
      :                     Payload Data continued ...                :
      + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
      |                     Payload Data continued ...                |
      +---------------------------------------------------------------+

7 or 8 bytes from client to server (due to masking, which I think it could be avoided in this case) and 2 or 4bytes from server to client.

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pntaw