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

Oleg Moskalenko <> Wed, 25 September 2013 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACB5711E8118 for <>; Wed, 25 Sep 2013 08:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kx-xyVFGoDbg for <>; Wed, 25 Sep 2013 08:45:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22b]) by (Postfix) with ESMTP id 8AAA411E8117 for <>; Wed, 25 Sep 2013 08:45:52 -0700 (PDT)
Received: by with SMTP id z12so6390712wgg.10 for <>; Wed, 25 Sep 2013 08:45:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wlwIz32UZzthRcX2GemSLtfsGXI4IhQyIgSYLkFmR1w=; b=Tjr/ht8R2ruHhK9x/a0a/EPmdLzOQ2ea4Hgnp73xxYlSrTVJ+EDx+xTUs5Dl8azDgz zwFMhZLp/2XHbvwvt9CyHtx2I9tCKkAjCljztYqcw+2H6DFqFSrwBaFwCS0kTKqaZRnV Q8c8uK/OFSpE8TLjoENDpOBC1bW6moptH9jRAqRqcdUtS8Qnd5mbpEVJYgNSI5rnKrsi Li9/3iZJzEFwikPQqx6PeDytlhCRaOcy/E5N6icMdfoUjgH5tOerXH6RNUUXHY6JMX9R D0q6XkfjBFlYz8Haj9hWdAOqLd/3Mo8gXDymoaMtvp+SjQl5NgrJyPn6hJIxL4Y4FwuV rmLQ==
MIME-Version: 1.0
X-Received: by with SMTP id fb1mr23609993wic.61.1380123950166; Wed, 25 Sep 2013 08:45:50 -0700 (PDT)
Received: by with HTTP; Wed, 25 Sep 2013 08:45:50 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 25 Sep 2013 08:45:50 -0700
Message-ID: <>
From: Oleg Moskalenko <>
To: "Hutton, Andrew" <>
Content-Type: multipart/alternative; boundary=001a11c23e68cbba9404e737258a
Cc: "" <>
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 15:45:53 -0000

Hi Andy

please see below in the text:

On Wed, Sep 25, 2013 at 2:59 AM, Hutton, Andrew <> wrote:

> 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.

HTTP CONNECT is used only when an explicit proxy is present. Websockets can
provide improved connectivity when NO explicit proxy is present

> 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.

That overhead is relatively minor.

> 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.

No, in this particular case the purpose is to use HTTP protocol as a tunnel
for TURN 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.

I do not understand how a web server jumped into the picture. The proposal
has nothing to do with the web servers.

> So does encapsulating the TURN data in websocket frames provide any
> benefit.

It provides a benefit of encapsulating TURN protocol into HTTP protocol
that is usually easily understandable and "parseable" by the firewalls. The
firewall can examine the subprotocol header and make a decision.

> 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.

There are scenarios when difference between HTTP and TURN is as simple as
"connectivity" vs "no connectivity". That's rather important.

> The extra websockets overhead for all the media packets is surely a
> drawback of this approach.

When no packets can be passed through, then the network overhead is exactly
0 (zero) but we do not consider it as a great scenario.

> Not encapsulating the TURN in websockets would also probably provide
> better control for those wanting to assert policies on the handling of
> media.

DPI of the TURN packets is a hard task, especially considering that the IP
addresses in the TURN packets are obfuscated. On the other hand, we may
require some headers in the websocket connection to contain information
about the protocol, so it may be more firewall-friendly and "examinable",
without serious investment into new DPI algorithms.

> 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.
I hope I provide an opinion.