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

<Markus.Isomaki@nokia.com> Wed, 25 September 2013 10:23 UTC

Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC1521F9EE5 for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 03:23:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.474
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm6sWysIlsb9 for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 03:23:43 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 98CA421F9F9D for <pntaw@ietf.org>; Wed, 25 Sep 2013 03:23:41 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.50]) by mgw-sa01.nokia.com (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 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.224]) by 008-AM1MMR2-016.mgdnok.nokia.com ([65.54.30.50]) with mapi id 14.03.0136.001; Wed, 25 Sep 2013 10:19:54 +0000
From: <Markus.Isomaki@nokia.com>
To: <andrew.hutton@siemens-enterprise.com>, <pntaw@ietf.org>
Thread-Topic: TURN over websockets or just TURN.
Thread-Index: Ac651aqKgci54WbeToGdcCETWYgQigAANnew
Date: Wed, 25 Sep 2013 10:19:53 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A0CB19C@008-AM1MPN1-042.mgdnok.nokia.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BD44F6@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BD44F6@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7ItiB42TqeK+XzdIfsWVZXuSxummMKzfO6UJxkKHrg3fGAzUUb+LDUMset3A/qORqTiE4t3K8z+/93mQyU9IS1gGgfxoguBVsAgUPBbwDmg1tiOPEVcQmtj6sDQirZQbYixzp9E28TfcVjNy2SO0Gwt6qCWcvUQ57fdEDwVTFiAm1Vb4qdfjSpsinr4ecxyLGa0L6PZPTWxV9t9zXq6cIpCoXl8Hj9p2yJIzUCCRTgj3Z
x-originating-ip: [10.236.10.110]
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-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 10:23:47 -0000

Hi,

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.

Markus 

> -----Original Message-----
> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> Of ext Hutton, Andrew
> Sent: 25 September, 2013 12:59
> To: pntaw@ietf.org
> 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
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw