[pntaw] TURN over websockets or just TURN.

"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Wed, 25 September 2013 09:59 UTC

Return-Path: <andrew.hutton@siemens-enterprise.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9F54121F9FF0 for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 02:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id W3dENJmwXEk2 for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 02:59:32 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3B30121F9F51 for <pntaw@ietf.org>; Wed, 25 Sep 2013 02:59:32 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown []) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 426F51EB85D8 for <pntaw@ietf.org>; Wed, 25 Sep 2013 11:59:29 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([]) by MCHP02HTC.global-ad.net ([]) with mapi id 14.03.0123.003; Wed, 25 Sep 2013 11:59:09 +0200
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: "pntaw@ietf.org" <pntaw@ietf.org>
Thread-Topic: TURN over websockets or just TURN.
Thread-Index: Ac651aqKgci54WbeToGdcCETWYgQig==
Date: Wed, 25 Sep 2013 09:59:09 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17BD44F6@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [pntaw] TURN over websockets or just TURN.
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2013 09:59:37 -0000

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.