Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt

Harald Alvestrand <harald@alvestrand.no> Tue, 21 January 2014 14:46 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D32D1A0163 for <pntaw@ietfa.amsl.com>; Tue, 21 Jan 2014 06:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level:
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MQ1M_RYHlvi for <pntaw@ietfa.amsl.com>; Tue, 21 Jan 2014 06:46:01 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [IPv6:2001:700:1:2:213:72ff:fe0b:80d8]) by ietfa.amsl.com (Postfix) with ESMTP id B72C41A015D for <pntaw@ietf.org>; Tue, 21 Jan 2014 06:46:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9164B39E1FC for <pntaw@ietf.org>; Tue, 21 Jan 2014 15:46:07 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ULl2lMpre-M for <pntaw@ietf.org>; Tue, 21 Jan 2014 15:46:05 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7646:a0ff:fe90:e2bb]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 252DF39E132 for <pntaw@ietf.org>; Tue, 21 Jan 2014 15:46:05 +0100 (CET)
Message-ID: <52DE8824.9010601@alvestrand.no>
Date: Tue, 21 Jan 2014 15:45:56 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: pntaw@ietf.org
References: <9F33F40F6F2CD847824537F3C4E37DDF17CBE35E@MCHP04MSX.global-ad.net> <CALDtMr+_jUti7BNVRubuncCU9rAZx4NqM3Ru1jtEbRF+uBMMEw@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17CBFD95@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17CBFD95@MCHP04MSX.global-ad.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw/>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 14:46:04 -0000

On 01/21/2014 12:01 PM, Hutton, Andrew wrote:
> Hi Oleg,
>
> I am thinking this maybe should be a comment against http://tools.ietf.org/html/draft-ietf-rtcweb-transports-01#section-2.2 but would be happy to add it to draft-hutton-rtcweb-nat-firewall-considerations if people think it is the right place.

It's not specifically a firewall issue (it applies every time you have a 
NAT), so I think -transport- is the right place for it (and discussion 
should be on the RTCWEB list).


>
> Regards
> Andy
>
>
>
>> -----Original Message-----
>> From: Oleg Moskalenko [mailto:mom040267@gmail.com]
>> Sent: 21 January 2014 09:37
>> To: Hutton, Andrew
>> Cc: pntaw@ietf.org
>> Subject: Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>> considerations-03.txt
>>
>> I have a comment on section 5 of the document.
>>
>> One thing that I'd definitely like to see enforced in the browser's
>> implementation of the TURN client protocol is the support of 300
>> Alternate Server error message. This is becoming an issue because of
>> the possible volume of the WebRTC media traffic. If the browsers are
>> supporting the error 300, then a TURN server administrator can
>> relatively easy set a load balancing scheme. If the browsers do not
>> support it, then it becomes a more complicated issue and an
>> implementation-dependent procedure.
>> As far as I know, no current browser supports 300 response from TURN
>> server. It would be very nice if the TURN server administrator could
>> rely on that feature.
>>
>> Oleg
>>
>> On Mon, Jan 20, 2014 at 4:09 AM, Hutton, Andrew
>> <andrew.hutton@unify.com> wrote:
>> I updated draft-hutton-rtcweb-nat-firewall-consideration.
>>
>> The main change is that the draft now explores the different options
>> that are available for handling such things as HTTP Proxies in a WebRTC
>> environment and no longer recommends a specific solution.
>>
>> Would be good to restart the discussion on these options and
>> determining the best way forward to ensuring we get some defined
>> standardized behavior for WebRTC for these scenarios.
>>
>> So please go ahead and make comments.
>>
>> Regards
>> Andy
>>
>>
>>
>> -----Original Message-----
>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>> internet-drafts@ietf.org
>> Sent: 20 January 2014 11:35
>> To: i-d-announce@ietf.org
>> Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-
>> 03.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>          Title           : RTCWEB Considerations for NATs, Firewalls and
>> HTTP proxies
>>          Authors         : Thomas Stach
>>                            Andrew Hutton
>>                            Justin Uberti
>>          Filename        : draft-hutton-rtcweb-nat-firewall-
>> considerations-03.txt
>>          Pages           : 14
>>          Date            : 2014-01-20
>>
>> Abstract:
>>     This document describes mechanism to enable media stream
>>     establishment for Real-Time Communication in WEB-browsers (WebRTC)
>> in
>>     the presence of network address translators, firewalls and HTTP
>>     proxies.  HTTP proxy and firewall deployed in many private network
>>     domains introduce obstacles to the successful establishment of media
>>     stream via WebRTC.  This document examines some of these deployment
>>     scenarios and specifies requirements on WebRTC enabled web browsers
>>     designed to provide the best possible chance of media connectivity
>>     between WebRTC peers.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-
>> considerations/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-
>> considerations-03
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-hutton-rtcweb-nat-firewall-
>> considerations-03
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> _______________________________________________
>> pntaw mailing list
>> pntaw@ietf.org
>> https://www.ietf.org/mailman/listinfo/pntaw
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw