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

"Reinaldo Penno (repenno)" <> Tue, 12 March 2013 03:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D26421F8563 for <>; Mon, 11 Mar 2013 20:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.162
X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8yVQWGo4Aygj for <>; Mon, 11 Mar 2013 20:05:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8DB7321F856D for <>; Mon, 11 Mar 2013 20:05:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3678; q=dns/txt; s=iport; t=1363057521; x=1364267121; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KjS/cPdFjCnsxlPnX2yBfg6gwAywhDZdQr5HG4UzlR8=; b=Ym+KF7AWgQW4jMjr3Qm0a5eLa4v7Idm4J8JoU3izZThaZRm6r3oRNxJF V+6t3arJNfxh03QP7DwZajDfVi86UFmp+TI92szrLddhnXGHX/Pf+bKRp Rwj52TMY4YE4NXjazE+mBOvipUvlnwL+iZL2c2TcNwL98ukCe4w3wF9m8 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.84,827,1355097600"; d="scan'208";a="186361917"
Received: from ([]) by with ESMTP; 12 Mar 2013 03:05:21 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r2C35KvA010018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 03:05:20 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 22:05:20 -0500
From: "Reinaldo Penno (repenno)" <>
To: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOpihPEwA//+PMoCAANDogP//1DCA
Date: Tue, 12 Mar 2013 03:05:19 +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
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: Tue, 12 Mar 2013 03:05:27 -0000

I think another advantage of PCP is to reduce call setup time in RTCweb.
If a NAT/FW/Middlebox tells us that you have a mapping for 1 hour, during
that hour you can reuse that external IP:port across calls over and over,
or least reuse as your prime ICE candidate.

On 3/11/13 9:42 PM, "" <>

>ICE/STUN/TURN and PCP are not really competitors or alternatives to each
>A browser or any other client will anyway need to implement ICE/STUN/TURN
>to work its way through non-PCP supporting NATs, which will be the
>majority for a long time even if PCP became succesfull. The benefit of
>the ICE/STUN/TURN approach is that every organization or individual who
>deploys NATs or firewalls will not need to deploy STUN and TURN servers,
>but they can be deployed independently e.g. by the WebRTC service
>However, PCP, even gradually deployed, would still be useful as well. As
>Reinaldo is saying, it would improve robustness it produces explict NAT
>mappings with explicit durations. Also, it can serve as an alternative to
>STUN/TURN in case the browser happens to be behind a PCP-capable NAT/FW.
>So, PCP can be seen as an optimization and should be used when it is
>available. PCP can also help clients behind NAT/FW to reduce their
>keep-alive rate which is applicable to WebRTC as well. However, as
>depicted in [1], knowing when a client can entirely rely on PCP is not
>always so easy to detect.
>I hope we will see PCP deployment especially in the mobile/cellular
>access, but as many people have pointed out, the success rate of this
>type of protocols has been quite low. So it will be a nice surprise
>rather than something I would count on if it happens.
>>-----Original Message-----
>>From: [] On Behalf
>>Of ext Reinaldo Penno (repenno)
>>Sent: 11 March, 2013 22:14
>>To: Hutton, Andrew; Harald Alvestrand;
>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
>>On 3/11/13 12:58 PM, "Hutton, Andrew"
>><> wrote:
>>>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
>>The line between Application providers and ISPs is very blurry today.
>>Application provider can be over the top or it can be the ISP itself.
>>>> 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.
>>Yes, certainly.
>>A protocol that allows a host to explicit control FW/NAT
>>(both for incoming and outgoing connections IPv4/IPv6), including
>>knowing when such device restart/reboot, is more deterministic.
>>Client is always free to use STUN/TURN.
>>rtcweb mailing list