Re: [rtcweb] NAT behavior heuristics

Martin Thomson <> Thu, 02 August 2012 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD0FF11E814E for <>; Thu, 2 Aug 2012 16:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.015
X-Spam-Status: No, score=-4.015 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yl9ULEE6n2XH for <>; Thu, 2 Aug 2012 16:02:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 98F8611E8120 for <>; Thu, 2 Aug 2012 16:02:28 -0700 (PDT)
Received: by lahm15 with SMTP id m15so36335lah.31 for <>; Thu, 02 Aug 2012 16:02:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bjpknQBSeZeuU6ds9Ho2BHt/qAdByd33c4d4NpanbY0=; b=y6dc7EQlunxFOEGC/UrVNdchfr3p6ahsJRvcnxGIRBMp3IXgE6MuUeSPSIKkuzuW+4 WNtoq1JYJL8XAuBqKUl/vaFrtAlf6ShWNEl/OAsESZEWW8HFkXt/9NGfqaGPb/1N1Z7s Rq+8I9scjgFhumB2t/87/CboZTaZ0TLDKfgincN4JiH4rdJluEq2doCUqcS/ulfHUmCQ 7t0VTrkfjgJQC00VXorP+uGNT0MOo8MhvOIweLMWUpIZP49voUQH9yUlS/fuR8KIYgvW uiI6OtJUtGEnnIEV/5l1+7/xN72GVqk15krvM7ErSi0/ESikSIa16pO6lJ75PTHMv7jZ KTMw==
MIME-Version: 1.0
Received: by with SMTP id hu6mr22923697lab.21.1343948547496; Thu, 02 Aug 2012 16:02:27 -0700 (PDT)
Received: by with HTTP; Thu, 2 Aug 2012 16:02:27 -0700 (PDT)
In-Reply-To: <038b01cd70d6$8c5bc870$a5135950$@com>
References: <038b01cd70d6$8c5bc870$a5135950$@com>
Date: Thu, 2 Aug 2012 16:02:27 -0700
Message-ID: <>
From: Martin Thomson <>
To: Dan Wing <>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [rtcweb] NAT behavior heuristics
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: Thu, 02 Aug 2012 23:02:29 -0000

I assume that this applies only to the NAT that doesn't exist yet and
that we will have to live with status quo (and the current keep-alive
recommendations) until PCP becomes bountiful.

We might want to consider other options for things like power saving
in addition to this.  One option that springs to mind is the ability
to explicitly shut down streams that aren't in use and pay the price
for warm-up.  Optimizations to candidate pair select at warm-up might
be handy in this case.

On 2 August 2012 10:45, Dan Wing <> wrote:
> In today's RTCWEB meeting I said that NAT heuristics do not work reliably,
> especially if a NAT is busy (high CPU or lots of ports consumed), but there
> are other situations with a NAT that cause heuristics to be inaccurate.  The
> IETF document regarding this is, and be
> sure to read its Applicability Statement in Section 1,
> An explicit protocol, such Port Control Protocol (PCP, draft-ietf-pcp-base)
> is the only reliable way to communicate with a NAT and reduce application
> keepalive traffic.  Several of us have noticed the need to document exactly
> how PCP can be reliably used to reduce UDP keepalive traffic.  We will write
> down those details before the next IETF, probably in an Internet Draft.
> -d
> _______________________________________________
> rtcweb mailing list