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

Oleg Moskalenko <> Wed, 25 September 2013 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79DE121F9C87 for <>; Wed, 25 Sep 2013 12:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KEhmFswQ-m6s for <>; Wed, 25 Sep 2013 12:18:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::22a]) by (Postfix) with ESMTP id 785AA21F9C70 for <>; Wed, 25 Sep 2013 12:18:13 -0700 (PDT)
Received: by with SMTP id un15so94496pbc.15 for <>; Wed, 25 Sep 2013 12:18:13 -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=kus70/qoPFh7r5zlgDe3TAyABXkKvlDEPhJeHamYTWI=; b=pggCvu2SJZxIJGyrXOG/rew8pidzMM64CLQ/kiRtrOHzb8kSR9BNBdgwCS1ATAJmtg 8luuPtXhxnfrBbzrKU1vhbyam4E5wRYlrAuxRs1jr1sOKKx0hRdWi4taiP02sCCDtDe0 3YiRFsg6aNeuKB+0o2G/RwyK5E4qv82OkyEDS95R1IA8PHZupWqoBB7gzVaTFckvhkyO Sj1vjntnpVg9iXpp/jLuvbQvpEMwbapsy275Dk5iwMn9VoA+dKdBdFDYdORmrG0bBOeP a/qtcx0/HS62BC1DArGCvqZYif4PM1qgfwbHBOOofJSKYGCmt5pX8lS3zlcrNtRfazD7 ncyg==
MIME-Version: 1.0
X-Received: by with SMTP id ue3mr839167pac.35.1380136692084; Wed, 25 Sep 2013 12:18:12 -0700 (PDT)
Received: by with HTTP; Wed, 25 Sep 2013 12:18:11 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 25 Sep 2013 12:18:11 -0700
Message-ID: <>
From: Oleg Moskalenko <>
To: "Hutton, Andrew" <>
Content-Type: multipart/alternative; boundary=047d7b15a2b146011e04e73a1d2e
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 19:18:17 -0000

Andy, see below:

On Wed, Sep 25, 2013 at 12:03 PM, Hutton, Andrew <> wrote:

> [AndyH] True I was considering that as the simple case and of course there
> is no HTTP CONNECT in that scenario. So are you saying that when there is
> no proxy then a websockets connection is more likely to work than a
> TURN/TCP or TURN/TLS connection. I would be interested in whether there is
> evidence of that I am not sure whether it is true or not certainly in the
> encrypted case I don't see how this can be but I am not an expert on this.

I cannot say that I am exactly an expert in IT firewall world, too. But I
personally observed a rather strict corporate environments where a strict
firewall is used without explicit HTTP proxy. Also, I heard from our TURN
server users the stories about similar cases. The usual story was that the
firewall blocks the outgoing TURN TCP connection unless it is destined to
80/443 port and it has an HTTP handshake.

> >
> > So, if we do not accept TURN inside Websockets then we must start an
> > immediate campaign against media inside TURN TCP connections and
> > through it out of WebRTC specs. These things are totally symmetrical in
> > all senses, and they serve the same purpose - the connectivity purpose,
> > and they have the same problems.
> >
> [AndyH] Sorry I don't get this argument at all the question is simply
> whether the websockets overhead is worthwhile or not.
Andy, I was trying to answer that exactly question. My point was that when
we use TCP to transmit the media, we have extra overhead over UDP (and
significantly more overhead than Websockets over "plain" TCP). Still, we
are OK with that overhead because we have no choice - we want extra
connectivity provided by TCP. I was just trying to make the Websockets vs
TCP story similar to TCP vs UDP story, in the particular media transmission
application. And in a similar way, I was making a conclusion that the
overhead is worthwhile.

Another point is that TCP adds so much overhead to the media transmission
(comparing to UDP) that an extra minor addition by Websockets is virtually
negligible - if we have a good reason for that (and I believe we do have).

But, of course, nobody likes the overhead.