Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

Marc Petit-Huguenin <> Fri, 24 May 2013 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09A8C21F969D; Fri, 24 May 2013 09:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nNynIe1j-gFV; Fri, 24 May 2013 09:02:33 -0700 (PDT)
Received: from ( [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by (Postfix) with ESMTP id 824AB21F9615; Fri, 24 May 2013 09:02:32 -0700 (PDT)
Received: from [IPv6:2601:9:4bc0:2d:d9af:d9c7:dae0:e111] (unknown [IPv6:2601:9:4bc0:2d:d9af:d9c7:dae0:e111]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "" (verified OK)) by (Postfix) with ESMTPS id C4FC4204BA; Fri, 24 May 2013 18:02:29 +0200 (CEST)
Message-ID: <>
Date: Fri, 24 May 2013 09:02:27 -0700
From: Marc Petit-Huguenin <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5
MIME-Version: 1.0
To: Lorenzo Miniero <>
References: <> <> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: "" <>, "" <>, =?UTF-8?B?R3VzdGF2byBHYXJjw61h?= <>
Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 May 2013 16:02:34 -0000

Hash: SHA256

On 05/20/2013 02:15 AM, Lorenzo Miniero wrote:
> Il giorno Sun, 19 May 2013 23:20:41 -0700 Gustavo García <>
> ha scritto:
>> I agree that TURN over websockets doesn't solve much more scenarios than
>> TURN/TLS.   If trying to fix HTTP Proxy traversal why not doing it over
>> HTTP that aside of philosophical discussions would be the solution with
>> better success rate?  Otherwise we will have to continue answering for
>> another 10 years "why is this app not working if skype does".
>> Something like this draft sent some months ago but perhaps for TURN 
>> instead of direct connections: 
> When I submitted that draft this summer, I had that exact purpose in mind,
> that is taking care of corner edge cases like restrictive proxies and the
> like. Of course it was not meant to be a solution, just a way to foster
> discussion in that direction. In that discussion I also mentioned some work
> we did about this in the past, which in part apparently ended up in
> draft-hutton-rtcweb-nat-firewall-considerations:
> At the time most people in the ML thought it was either too useless, too
> complex or even harmful, considering it could be considered as a "sneaky"
> way to circumvent rules added by a network administrator, and so
> unacceptable. Anyway, as I said back then, a solution like this doesn't
> have to be sneaky, and it could very well be conceived in order to be
> admin-friendly rather than have a parrot and a wooden leg.

About circumventing rules added by a network administrator, I do think that
using TURN over Websocket or HTTP is doing in fact the opposite:  It is the
only way to obey the wish of the network administrator, as long as you
classify Webrtc is a *web* technology and not as a VoIP technology.

Think about it this way:  An administrator restricting UDP but authorizing
HTTP is basically saying: All web applications are fine, and Webrtc being a
Web application, it should just work fine, and should not be a collateral
damage of restricting UDP.  So TURN over Websocket/HTTP should be a mandatory
part of Webrtc.

Now the administrator should also have access to tools to restrict some
classes of web applications, and Webrtc should be one of these classes.  But
that should not be done as a side-effect of closing the UDP ports.

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