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

<> Wed, 25 September 2013 10:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBC1521F9EE5 for <>; Wed, 25 Sep 2013 03:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.474
X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vm6sWysIlsb9 for <>; Wed, 25 Sep 2013 03:23:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 98CA421F9F9D for <>; Wed, 25 Sep 2013 03:23:41 -0700 (PDT)
Received: from ([]) by (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8PAJsfJ001884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 25 Sep 2013 13:19:55 +0300
Received: from ([]) by ([]) with mapi id 14.03.0136.001; Wed, 25 Sep 2013 10:19:54 +0000
From: <>
To: <>, <>
Thread-Topic: TURN over websockets or just TURN.
Thread-Index: Ac651aqKgci54WbeToGdcCETWYgQigAANnew
Date: Wed, 25 Sep 2013 10:19:53 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7ItiB42TqeK+XzdIfsWVZXuSxummMKzfO6UJxkKHrg3fGAzUUb+LDUMset3A/qORqTiE4t3K8z+/93mQyU9IS1gGgfxoguBVsAgUPBbwDmg1tiOPEVcQmtj6sDQirZQbYixzp9E28TfcVjNy2SO0Gwt6qCWcvUQ57fdEDwVTFiAm1Vb4qdfjSpsinr4ecxyLGa0L6PZPTWxV9t9zXq6cIpCoXl8Hj9p2yJIzUCCRTgj3Z
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [pntaw] TURN over websockets or just TURN.
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Sep 2013 10:23:47 -0000


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.


> -----Original Message-----
> From: [] On Behalf
> Of ext Hutton, Andrew
> Sent: 25 September, 2013 12:59
> To:
> 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