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

"Roy, Radhika R CIV USARMY (US)" <> Tue, 12 March 2013 14:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D077B21F87F6 for <>; Tue, 12 Mar 2013 07:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rX0I7R+kzcGv for <>; Tue, 12 Mar 2013 07:45:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D40AE21F85D4 for <>; Tue, 12 Mar 2013 07:45:52 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 12 Mar 2013 14:45:39 +0000
Received: from ([]) by ([]) with mapi id 14.02.0309.003; Tue, 12 Mar 2013 14:45:40 +0000
From: "Roy, Radhika R CIV USARMY (US)" <>
To: Harald Alvestrand <>, "" <>
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt (UNCLASSIFIED)
Thread-Index: AQHOHyb5/9U6NQLV2EWTHf5XQuc2iJiiH4rg
Date: Tue, 12 Mar 2013 14:45:39 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_002A_01CE1F0E.BAD29850"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt (UNCLASSIFIED)
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 14:45:57 -0000

Classification: UNCLASSIFIED
Caveats: NONE


I also agree with Harald on his proposal that PCP would be considered later.
In addition, I like to add the following:

1. Let PCP becomes an RFC.
2. Let there be some use cases/call-flows (as a PCP call-flow IETF draft is
there) using PCP for FW/NAT crossing by RTCWEB, SIP (audio/video)
conferencing, and related real-time applications.

Once above two items are completed, a separate draft using PCP for FW/NAT
crossing by RTCWEB applications can be written as soon as possible including
co-existing with ICE/STUN/TURN complementing each other capabilities.

Best regards,

-----Original Message-----
From: [] On Behalf Of
Harald Alvestrand
Sent: Tuesday, March 12, 2013 9:39 AM
Subject: Re: [rtcweb] FW: I-D Action:

On 03/12/2013 02:42 AM, wrote:
> Hi,
> 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 provider.
> 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.

I absolutely agree with this summary about the usefulness and status of PCP.

My concern with RTCWEB at the moment is getting things out the door with all
the features we really need to have, and as few additional features as

That's why I don't want to add PCP into the mix at this time - once we're
finished with the basic stuff, we can discuss adding support for new
features at our leisure, but making the specs more complex than they
currently are really should be done only when it's a really important
feature that needs adding.


rtcweb mailing list

Classification: UNCLASSIFIED
Caveats: NONE