Re: [pntaw] New version of TURN over websockets draft

Marc Petit-Huguenin <> Fri, 20 September 2013 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A07D521F99ED for <>; Fri, 20 Sep 2013 11:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wkbL15lotyic for <>; Fri, 20 Sep 2013 11:59:20 -0700 (PDT)
Received: from ( [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by (Postfix) with ESMTP id 3F8FE21F9991 for <>; Fri, 20 Sep 2013 11:59:20 -0700 (PDT)
Received: from [IPv6:2601:9:4bc0:1c:fceb:fc0:562e:eeb0] (unknown [IPv6:2601:9:4bc0:1c:fceb:fc0:562e:eeb0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "" (verified OK)) by (Postfix) with ESMTPS id 35DCF20EB1; Fri, 20 Sep 2013 20:59:18 +0200 (CEST)
Message-ID: <>
Date: Fri, 20 Sep 2013 11:59:15 -0700
From: Marc Petit-Huguenin <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8
MIME-Version: 1.0
To: Oleg Moskalenko <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "" <>, Lorenzo Miniero <>, Sergio Garcia Murillo <>, "Chenxin \(Xin\)" <>, Victor Pascual Avila <>
Subject: Re: [pntaw] New version of TURN over websockets draft
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: Fri, 20 Sep 2013 18:59:22 -0000

Hash: SHA256

On 09/20/2013 11:19 AM, Oleg Moskalenko wrote:
> Thank you Marc for your comments and suggestions.
> RFC 6062 is a relatively seldom used specs, this new draft is directed
> mostly toward extension of RFC 5766 for WebRTC users. They will be using
> TURN in RFC 5766 manner, with a single Websocket connection per Allocation.
> RFC 6062 is a rather exotic use case and it is not used in WebRTC. So I'd
> not complicate this draft with a new subprotocol.

Yes, after sending my email, I realized that it was not necessary.

> In practice, even in the case of a few RFC 6062 users, in most cases a
> TURN allocation is created with a single or a few connections, so there
> will be no significant flood of TCP connections if we will keep a new
> Websocket connection for each new peer.
> I'd suggest to keep it as simple as possible and as close to RFC 5766 and
> RFC 6062 as possible for most practical purposes. This draft originated
> mostly out of WebRTC requirements and as I said before the WebRTC
> allocations will be using a single Websocket connection.
> If there will be a significant demand for RFC 6062-style communications
> with Websockets, then we can consider an extension.
> So, I'd suggest to keep a new Websocket connection for every new peer, for
> RFC 6062 - style communications.

OK so I suggest to say in the draft that a new Websocket connection will be
created for each TCP peer, because that have an impact on implementation design.

> Regards, Oleg
> On Fri, Sep 20, 2013 at 10:54 AM, Marc Petit-Huguenin
> < <>> wrote:
> I read the draft and I have some questions:
> After TCP allocation over TURN Websocket, what is the Websocket equivalent
> of initiating a new TCP connection (RFC 6062) after sending a
> ConnectionBind or receiving a ConnectionAttempt?  Is a new Websocket
> connection opened and if it is the case, shouldn't it require a different
> subprotocol?  Perhaps a better alternative would be to use multiplexing 
> (draft-ietf-hybi-websocket-multiplexing) to not have to create multiple 
> Websocket connections to one TURN server?
> See these links for a alternate way of multiplexing data exchanged with 
> multiple TCP peers over one connection:
> On 09/13/2013 12:41 AM, Sergio Garcia Murillo wrote:
>> Hi all
>> We have been working on a new version of the TURN over Websocket draft 
>> originally proposed by Xin, which is now available at:
>> We believe that it is very well aligned with the spirit of 
>> draft-hutton-rtcweb-nat-firewall-considerations and should be considered
>> to be endorsed by WebRTC.
>> Also, in order to address the concerns about the impact on TURN servers
>> we will be working in providing a working prototype over the following
>> weeks by adding a preliminary support of TURN over websockets into the 
>> rfc5766-turn-server.
>> Any kind of feedback would be very welcome.

- -- 
Marc Petit-Huguenin
Version: GnuPG v1.4.14 (GNU/Linux)