IETF Logo Mail Archive

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

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Tue, 12 March 2013 03:57 UTC

Return-Path: <mperumal@cisco.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 42FE221F8A5E for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 20:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.521
X-Spam-Level:
X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
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 fuQgrXHyrg1G for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 20:57:56 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8728321F8A52 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 20:57:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1835; q=dns/txt; s=iport; t=1363060676; x=1364270276; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=goiGArqahaTrum/V+tnfa5yXF5wMGg0euhdVNUijV/o=; b=mqla2txo9Tqq+AwOdQ1uxdSxGuhPH4QRGcKX6upmtOu/mwGNUxP3/jCY 7Yrd4ibaIA+3jG82CscIqjWyE3tCBeTz1WgfGW/H/p9HVOQhSRQbPOfie bmKNuJsb2GycpxvxvXpfpvfSauXUfDMGMPc34iIizb7+ysGTUwRXctcB4 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFADKmPlGtJV2Y/2dsb2JhbABDxGuBYhZ0gikBAQEEAQEBNzQXBAIBCBEEAQELFAkHJwsUCAEIAgQBEgiICwyva5ANEwSNQoEaJhIGgllhA6dKgVSBKQ2BczU
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="183379558"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 12 Mar 2013 03:57:56 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2C3vu3B007652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 03:57:56 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 22:57:55 -0500
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>, "Reinaldo Penno (repenno)" <repenno@cisco.com>, Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpQPNB80XASUa1nEzDk7aFy5ig5ncwgACByzA=
Date: Tue, 12 Mar 2013 03:57:55 +0000
Message-ID: <E721D8C6A2E1544DB2DEBC313AF54DE22403B3DF@xmb-rcd-x02.cisco.com>
References: <513E146D.4060009@alvestrand.no> <45A697A8FFD7CF48BCF2BE7E106F06040901B3A9@xmb-rcd-x04.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF06895013@MCHP04MSX.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.86.58]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-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, 12 Mar 2013 03:57:57 -0000

|It is not required for an ISP to deploy a TURN server the webrtc TURN server 
|is much more likely to be deployed by the web application provider which will
|instruct the browser to use it when accessing its service.

Right, and the application provider could be also an enterprise hosting a TURN server for a number of reasons in addition to NAT/firewall traversal -- media anchoring, monitoring, recording etc. I think TURN servers aren't going away, especially with WebRTC where the session signaling protocol between the browser and the web server could be proprietary (and encrypted), making ALG techniques in NATs/Firewalls/SBCs fail miserably.

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hutton, Andrew
|Sent: Tuesday, March 12, 2013 1:28 AM
|To: Reinaldo Penno (repenno); Harald Alvestrand; rtcweb@ietf.org
|Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
|
|On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
|
|
|>
|> I'm sure STUN and TURN servers are not universally deployed ('100%') in
|> ISP networks either.
|
|It is not required for an ISP to deploy a TURN server the webrtc TURN server is much more likely to be
|deployed by the web application provider which will instruct the browser to use it when accessing its
|service.
|
|>
|> But I'm not proposing dropping STUN/TURN in lieu of PCP, but using PCP
|> as
|> an additional technique. Maybe you misunderstood what I was proposing.
|>
|
|Understood but would need to understand what the benefits of doing so would be.
|
|Regards
|Andy
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email