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

"Reinaldo Penno (repenno)" <> Mon, 11 March 2013 20:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5965B21F8F63 for <>; Mon, 11 Mar 2013 13:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.443
X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZfxM5PHMO95d for <>; Mon, 11 Mar 2013 13:11:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 19F0421F8F5C for <>; Mon, 11 Mar 2013 13:11:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1910; q=dns/txt; s=iport; t=1363032697; x=1364242297; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=THDXfsbXRfvr1ntPawXLZKN9DdrfBaqve8cz/KAWKsY=; b=arylarLyX6BGP0p4SMGPG5tcxhp9ZphcXqCJTB6pF6lZ7QX1sUpVGlH7 oxOsxO2XsdUaniMpMedyrHjQKhvttujOngCZcvfPbD+HD6Q8zGJ96D1SH FxRKd1hyO1m5zi+ygvHU0COg2P3HMxV6+q0j51Ya9Zi8q8igzW2qbHlV7 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFABM5PlGtJV2c/2dsb2JhbABDxGaBXxZ0gikBAQEDATo/EgEIGAoUQhwJAgQOBQgTh2YDCQa/XoxGghcxB4JfYQOTEJQ6gVSBNoIo
X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="186291048"
Received: from ([]) by with ESMTP; 11 Mar 2013 20:11:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r2BKBaHQ030797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 20:11:36 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 15:11:36 -0500
From: "Reinaldo Penno (repenno)" <>
To: Harald Alvestrand <>
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOpihNayA//+PwQCAAHiSgP//jLSA
Date: Mon, 11 Mar 2013 20:11:35 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Mar 2013 20:11:38 -0000

On 3/11/13 1:04 PM, "Harald Alvestrand" <> wrote:

>On 03/11/2013 08:52 PM, Reinaldo Penno (repenno) wrote:
>> On 3/11/13 12:34 PM, "Hannes Tschofenig" <>
>>> On Mar 11, 2013, at 2:02 PM, Reinaldo Penno (repenno) wrote:
>>>>>> Why not use Port Control Protocol (PCP) to control Firewalls and
>>>>>> explicitly?
>>>>> We can switch to that as soon as 100% of firewalls support it - until
>>>>> then, we have to be able to rely on other techniques.
>>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
>>>> ISP networks either.
>>> STUN and TURN don't require any support from ISPs.
>> If ISPs want to provide RTCweb like services don't they need STUN and
>> Servers so that ICE can gather candidates?
>ISPs may want to offer services. But that's independent of their role as
>Anyone can offer a STUN or TURN server, and they can be anywhere on the
>PCP, on the other hand, has to be available on the specific firewall or
>NAT box you intend to traverse. If it isn't there, it won't work.

Yes, but on the other hand you deterministically get an IP address:port or
pinhole (both for incoming and outgoing connections) for a specific
lifetime instead of relying on outbound connections, keep-alives, and
external server. 

The point is that if the FW/NAT supports PCP, the solution is certainly
cleaner. Client is always free to fallback to STUN/TURN/indirect ways.

>>> Both protocols are used today.
>> Yes, today. But that did not stop design decisions to include these
>> protocols in ICE at a they time were not deployed at all.
>Sorry, I can't parse that.
>ICE was deployed to support applications that needed ICE; there was no
>need to deploy more than 1 STUN/TURN server in order to start using STUN
>and TURN.