Re: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-rtcweb-transports-00.txt)

Salvatore Loreto <salvatore.loreto@ericsson.com> Tue, 27 August 2013 14:52 UTC

Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA1811E8161 for <rtcweb@ietfa.amsl.com>; Tue, 27 Aug 2013 07:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.423
X-Spam-Level:
X-Spam-Status: No, score=-108.423 tagged_above=-999 required=5 tests=[AWL=-2.175, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaP9lK-Qsmby for <rtcweb@ietfa.amsl.com>; Tue, 27 Aug 2013 07:52:35 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D179311E819A for <rtcweb@ietf.org>; Tue, 27 Aug 2013 07:52:34 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-dc-521cbd311267
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 82.2D.03802.13DBC125; Tue, 27 Aug 2013 16:52:33 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.183.146) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Tue, 27 Aug 2013 16:52:31 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3AB6B110451 for <rtcweb@ietf.org>; Tue, 27 Aug 2013 17:52:31 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8246E55C02 for <rtcweb@ietf.org>; Tue, 27 Aug 2013 17:52:25 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 053B355709 for <rtcweb@ietf.org>; Tue, 27 Aug 2013 17:52:24 +0300 (EEST)
Message-ID: <521CBD2E.9030905@ericsson.com>
Date: Tue, 27 Aug 2013 16:52:30 +0200
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: <rtcweb@ietf.org>
References: <E44893DD4E290745BB608EB23FDDB7620A0906A4@008-AM1MPN1-041.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A0906A4@008-AM1MPN1-041.mgdnok.nokia.com>
Content-Type: multipart/alternative; boundary="------------030305090700080103040406"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvja7hXpkggxtrFCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp/5D5kLptRX7L//hrmBsT25i5GTQ0LARGL15lZGCFtM4sK9 9WxdjFwcQgKHGSU2LPzICOFsYJR48G0ZK0iVkMBlRoltt9Uh7COMEofW8kHYZxklHi2UBrF5 BbQlbq/bzgxiswioSlw6cJcFxGYTMJN4/nALWFxUIFmi6fJ9Foh6QYmTM5+A2SICohKvH08D 2yUskC7RduEoM8T8cIm19yeCxTkFIiT6trQxgdjMAmESN6esYYL4QE3i6rlNUPVaEr1nO5km MArPQrJiFpIWCNtW4sKc61BxeYntb+cwQ9i6Ehf+T0ERX8DItoqRPTcxMye93GgTIzDwD275 rbqD8c45kUOM0hwsSuK8m/XOBAoJpCeWpGanphakFsUXleakFh9iZOLglAKGueVJJtOYh4w1 FwVa5NnVOPbkzPmy6k2zj7DLqg7rwgmcVQc3N4sIX2x4uGP75Ws3tJd0Gl26YrRo6yKG70VS jSJyUzboqafI1s6/ekNayHDWthmVWQF3Np+6ouqi0O8a0HjdbtNdQfm01I3+7y7oRczYmyb5 zKbxrPgML44batsCRQpuuKxXYinOSDTUYi4qTgQAmKqxr0oCAAA=
Subject: Re: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-rtcweb-transports-00.txt)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Aug 2013 14:52:41 -0000

+1


On 8/27/13 2:53 PM, Markus.Isomaki@nokia.com wrote:
>
> Hi,
>
> I would support the adoption of the NAT and Firewall considerations 
> (http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01) 
> as a WG document. Or to be more precise, I very much agree with the 
> requirements summarized in Section 5. Especially this one seems 
> important to me:
>
> o  connect to a TURN server via a HTTP proxy using the HTTP connect
>        method,
>
> If we want WebRTC to work from many corporate networks I'm aware of, 
> it would not be possible without this as a fallback capability.
>
> Markus
>
> *From:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On 
> Behalf Of *ext Bernard Aboba
> *Sent:* 21 August, 2013 00:44
> *To:* Hutton, Andrew; rtcweb@ietf.org; Harald Alvestrand
> *Subject:* Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
>
> The NAT/Firewall considerations document does go into detail on the 
> various traversal scenarios, which helps inform the discussion of what 
> should or should not be supported in terms of transport.  Section 5 
> summarizes the recommendations as follows:
>
>
>     5
>     <http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01#section-5>.
>     Requirements for RTCWEB-enabled browsers
>
>   
>   
>     For the purpose of relaying RTCWEB media streams or data channels a
>     browser needs to be able to
>   
>     o  connect to a TURN server via UDP, TCP and TLS,
>   
>     o  connect to a TURN server via a HTTP proxy using the HTTP connect
>        method,
>   
>     o  connect to a TURN server via the HTTP(s) ports 80/443 instead of
>        the default STUN ports 3478/5349,
>   
>     o  upgrade the HTTP proxy-relayed connection to the TURN server to
>        use TLS,
>   
>     o  use the same proxy selection procedure for TURN as currently done
>        for HTTP,
>   
>     o  switch the usage of the HTTP proxy-relayed connection with the
>        TURN server from HTTP to STUN/TURN,
>   
>     o  use a preconfigured or standardized port range for UDP-based media
>        streams or data channels,
>   
>     o  learn from the proxy configuration script about the presence of a
>        local TURN server and use it for sending UDP traffic to the
>        internet,
>   
>     o  support ICE-TCP for TCP-based direct media connection to the
>        RTCWEB peer.
>
> > From: andrew.hutton@siemens-enterprise.com 
> <mailto:andrew.hutton@siemens-enterprise.com>
> > To: rtcweb@ietf.org <mailto:rtcweb@ietf.org>; harald@alvestrand.no 
> <mailto:harald@alvestrand.no>
> > Date: Tue, 20 Aug 2013 16:31:28 +0000
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
> >
> > Section 2.2 "Middle Box Related Functions" should also I assume 
> cover the case of using a HTTP Proxy or an enterprise TURN server and 
> reference 
> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-01 
> assuming we can get this adopted.
> >
> > Regards
> > Andy
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb