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

"Hutton, Andrew" <> Tue, 28 May 2013 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10A5721F9817; Tue, 28 May 2013 08:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SwSjNsIi7EKU; Tue, 28 May 2013 08:03:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ACC2C21F9814; Tue, 28 May 2013 08:03:56 -0700 (PDT)
Received: from (unknown []) by (Server) with ESMTP id C2AE91EB8529; Tue, 28 May 2013 17:03:55 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 28 May 2013 17:03:55 +0200
From: "Hutton, Andrew" <>
To: Marc Petit-Huguenin <>, Lorenzo Miniero <>
Thread-Topic: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
Thread-Index: AQHOWJgguR8PhNxiQUuYi4Iujc603Jkaseag
Date: Tue, 28 May 2013 15:03:54 +0000
Message-ID: <>
References: <> <> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Tue, 28 May 2013 15:04:01 -0000

On: 24 May 2013 17:02 Marc Petit-Huguenin Wrote:
> 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.

I certainly agree with this. WEBRtc is a new technology embedded in the browser for web applications to use so we need to define the mechanism used by the browser to handle firewall scenarios and give the network administrators the tools to do what they want.

This is not about circumventing rules but about putting tools in place so rules can be defined for this new web technology and we need to move on this otherwise webrtc will be unnecessarily restricted in where/how it can be used.

So far I still think the HTTP Connect mechanism described in is the best option as it requires only browser implementation and existing infrastructure to work. 

However let's debate the merits of all solutions and move this forward.