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

"Karl Stahl" <> Fri, 24 May 2013 08:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68C0F21F967F; Fri, 24 May 2013 01:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.488
X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, PLING_QUERY=1.39]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ntDo-g0iolCJ; Fri, 24 May 2013 01:58:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E24E21F9676; Fri, 24 May 2013 01:58:39 -0700 (PDT)
Received: from ([]) by (Telecom3 SMTP service) with ASMTP id 201305241058222555; Fri, 24 May 2013 10:58:22 +0200
From: "Karl Stahl" <>
To: "'Chenxin \(Xin\)'" <>, "'Simon Perreault'" <>
References: <> <> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl> <> <> <> <> <> <> <000001ce5677$4b471650$e1d542f0$> <> <005f01ce56cb$6acb47e0$4061d7a0$> <> <>
In-Reply-To: <>
Date: Fri, 24 May 2013 10:58:20 +0200
Message-ID: <02cb01ce585c$d70aae40$85200ac0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOVs8m6PhKpPzBWESvuGMiUrIKUZkTliFQgABzLfA=
Content-Language: sv
X-Mailman-Approved-At: Fri, 24 May 2013 08:36:13 -0700
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:58:45 -0000

Leaving my quality concern of a such fallback channel for a moment...

How do you mean that tunneling rtcweb media through a firewall that is configured to only allow surfing is not to  "battle with network administrator"?

Isn't it exactly just that, whatever technique we chose to it with?


-----Ursprungligt meddelande-----
Från: Chenxin (Xin) [] 
Skickat: den 24 maj 2013 04:26
Till: Simon Perreault; Karl Stahl
Ämne: RE: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

   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,

>-----Original Message-----
>From: [] On 
>Behalf Of Simon Perreault
>Sent: Wednesday, May 22, 2013 5:31 PM
>To: Karl Stahl
>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
>rtcweb mailing list