Re: [rtcweb] NAT behavior heuristics
Harald Alvestrand <harald@alvestrand.no> Mon, 06 August 2012 10:31 UTC
Return-Path: <harald@alvestrand.no>
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 CE43621F863B for <rtcweb@ietfa.amsl.com>; Mon, 6 Aug 2012 03:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 PxuztBuChfbs for <rtcweb@ietfa.amsl.com>; Mon, 6 Aug 2012 03:31:49 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 02D5021F85E6 for <rtcweb@ietf.org>; Mon, 6 Aug 2012 03:31:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64A8039E0FA for <rtcweb@ietf.org>; Mon, 6 Aug 2012 12:31:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzuNfuuHXx3O for <rtcweb@ietf.org>; Mon, 6 Aug 2012 12:31:45 +0200 (CEST)
Received: from [192.168.1.107] (unknown [188.113.88.47]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id B79B539E062 for <rtcweb@ietf.org>; Mon, 6 Aug 2012 12:31:45 +0200 (CEST)
Message-ID: <501F9D18.4080909@alvestrand.no>
Date: Mon, 06 Aug 2012 12:31:52 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <038b01cd70d6$8c5bc870$a5135950$@com> <CABkgnnW+pCnDZuYHDj6=7xdqRwM6AO48RrC1xhMrvFZbUBgtyw@mail.gmail.com> <04ff01cd7104$be09bed0$3a1d3c70$@com> <501E1E40.8070203@jesup.org> <913383AAA69FF945B8F946018B75898A1477C16C@xmb-rcd-x10.cisco.com>
In-Reply-To: <913383AAA69FF945B8F946018B75898A1477C16C@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] NAT behavior heuristics
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: Mon, 06 Aug 2012 10:31:50 -0000
On 08/05/2012 11:49 PM, Tirumaleswar Reddy (tireddy) wrote: >> And that's a rub, since in many/most cases, the 3G/LTE people will >> likely be talking to non-3G/LTE people, and if either side needs >> keepalives, then radio will be kept active. Note we're talking >> long-term inactive media flows and an inactive (or rarely active) >> datachannel, such as a client using PeerConnection and DataChannels to >> keep a registration or empty conference alive, or various non-phone- >> like applications. > If just 3G/LTE supports PCP and non-3G/LTE does not support PCP -> Any STUN indications coming from the non-3G can be dropped by the Mobile Network itself to avoid reaching the Mobile Node, since it knows NAT binding is alive using PCP. > 1) the at-the-moment theory is that consent verification will use ICE Bind requests, not indications 2) if the mobile network drops these, the end node will assume that consent is withdrawn, and stop. Agreed with those who argue that we shouldn't spend too much energy on optimizing for a moving target.
- [rtcweb] NAT behavior heuristics Dan Wing
- Re: [rtcweb] NAT behavior heuristics Martin Thomson
- Re: [rtcweb] NAT behavior heuristics Dan Wing
- Re: [rtcweb] NAT behavior heuristics Martin Thomson
- Re: [rtcweb] NAT behavior heuristics Dan Wing
- Re: [rtcweb] NAT behavior heuristics Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] NAT behavior heuristics Harald Alvestrand
- Re: [rtcweb] NAT behavior heuristics Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] NAT behavior heuristics Randell Jesup
- Re: [rtcweb] NAT behavior heuristics Cameron Byrne
- Re: [rtcweb] NAT behavior heuristics Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] NAT behavior heuristics Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] NAT behavior heuristics Cameron Byrne
- Re: [rtcweb] NAT behavior heuristics Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] NAT behavior heuristics Harald Alvestrand
- Re: [rtcweb] NAT behavior heuristics Markus.Isomaki
- Re: [rtcweb] NAT behavior heuristics Cameron Byrne
- Re: [rtcweb] NAT behavior heuristics Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] NAT behavior heuristics Cameron Byrne
- Re: [rtcweb] NAT behavior heuristics Tirumaleswar Reddy (tireddy)