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

"Olle E. Johansson" <> Fri, 24 May 2013 08:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9955921F87D1; Fri, 24 May 2013 01:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.544
X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, PLING_QUERY=1.39]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kUEG0PPw7WmK; Fri, 24 May 2013 01:05:09 -0700 (PDT)
Received: from ( [IPv6:2a02:920:212e::205]) by (Postfix) with ESMTP id 02B1921F89EB; Fri, 24 May 2013 01:05:06 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPA id 4EBD593C2A1; Fri, 24 May 2013 08:05:03 +0000 (UTC)
Content-Type: text/plain; charset=GB2312
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: "Olle E. Johansson" <>
In-Reply-To: <>
Date: Fri, 24 May 2013 10:05:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl> <> <> <> <> <> <> <000001ce5677$4b471650$e1d542f0$> <> <005f01ce56cb$6acb47e0$4061d7a0$> <> <>
To: "Chenxin (Xin)" <>
X-Mailer: Apple Mail (2.1503)
X-Mailman-Approved-At: Fri, 24 May 2013 08:36:13 -0700
Cc: "" <>, "Olle E. Johansson" <>, "" <>, Karl Stahl <>
Subject: Re: [BEHAVE] [rtcweb] Why? Quality! 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 08:05:10 -0000

I do agree with SImon here. Firewall traversal in the sense "let's bypass the firewall admin policys" is not something for the IETF,

Why not focus on discussing best behaviour for firewalls, so we don't end up in the mess we have in SIP with most
firewalls breaking communication. We also have huge problems with firewall/CPE/routers that are starting to implement
broken SIP application layer gateways.

Maybe "run a TURN server on the firewall" is a good recommendation to start with.


24 maj 2013 kl. 04:26 skrev "Chenxin (Xin)" <>om>:

>   I agree that we should not try to battle with network administrator, and we are not doing that. We just supply some technical tools to rtcweb implementer, to make the users could get benefit and convenience when using rtcweb. Fallback methods and proposals are for this purpose.  We could not decide that how will a kind of technique be used. Every technique could be used in a good way and a bad way.  I believe that rtcweb is a good and trustworthy technique which is different with the some harmful things which should be blocked by the administers. So let us back to the technical aspect: should we need to support a fallback method in rtcweb now? Which one should we support to MTI? Which one should we support to be a option? I think now there is three method to solve the fallback requirement:TURN/TLS, HTTP channel , TURN/WS or HTTP. I am willing to write a mail these days to make a simple conclusion and comparison between these methods, which will provide a material to WG for future discussion and decision.
> Best Regards,
>     Xin 
>> -----Original Message-----
>> From: [] On Behalf Of
>> Simon Perreault
>> Sent: Wednesday, May 22, 2013 5:31 PM
>> To: Karl Stahl
>> Cc:;
>> Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for
>> draft-chenxin-behave-turn-websocket-00.txt
>> Le 2013-05-22 11:04, Karl Stahl a écrit :
>>>> Firewall traversal is a completely different beast.
>>> Not really. There are always firewall functions included in "a NAT" (e.g.
>>> open for traffic from inside to outside and you can then get traffic back
>>> the same path - with some timeout), even if the RFCs only call the box "a
>>> NAT". I prefer to say NAT/Firewall.
>> You're focusing on the technical aspect. The difference I'm considering
>> is not technical.
>> NAT traversal is performed with the agreement of everyone involved,
>> whereas firewall traversal is a battle between the client implementer
>> and the firewall administrator. There's also a potential arms race:
>> firewalls will evolve with the ability to block whatever we standardize,
>> so we will need a newer traversal method, which firewalls will end up
>> blocking as well, etc. etc. etc. We don't want to play that game.
>> NAT traversal: ok
>> Firewall traversal: not for the IETF
>> Simon
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list