Re: [MMUSIC] Updating the pacing of ICE connectivity checks

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Fri, 15 February 2013 16:47 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66AB21F8869 for <mmusic@ietfa.amsl.com>; Fri, 15 Feb 2013 08:47:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.195
X-Spam-Level:
X-Spam-Status: No, score=-106.195 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy4Ur-6QQl9C for <mmusic@ietfa.amsl.com>; Fri, 15 Feb 2013 08:47:20 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8E70921F8733 for <mmusic@ietf.org>; Fri, 15 Feb 2013 08:47:20 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-23-511e6697747a
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E6.B3.19728.7966E115; Fri, 15 Feb 2013 17:47:19 +0100 (CET)
Received: from [131.160.126.243] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Fri, 15 Feb 2013 17:47:19 +0100
Message-ID: <511E6696.6090609@ericsson.com>
Date: Fri, 15 Feb 2013 18:47:18 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <511CEB64.6070306@ericsson.com> <05a401ce0ac6$db547230$91fd5690$@cisco.com> <511D03A7.1060008@ericsson.com> <511D0498.3030909@jitsi.org> <511D07F1.3070808@ericsson.com>
In-Reply-To: <511D07F1.3070808@ericsson.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvje70NLlAg30v9C0uXnvIZLFm5wQW i6nLH7M4MHtM+b2R1WPJkp9MHv/fBAYwR3HZpKTmZJalFunbJXBltN5aylSwlLViZc9x9gbG qSxdjJwcEgImEofu/4GyxSQu3FvP1sXIxSEkcJJRomHvZChnLaPE6d2HmUGqeAW0JT58+c4I YrMIqEq0tC0Ai7MJWEhsuXUfbJKoQJTE+6tNUPWCEidnPgGLiwiYSTycsB9sKLPAdEaJlYsO soEkhAVcJF43fYPatoVR4k7XTaYuRg4OTgEdiUdnCiHOk5RYNK0TbBCzgJ7ElKstjBC2vMT2 t3PAlgkBHbf8WQvLBEahWUh2z0LSMgtJywJG5lWM7LmJmTnp5UabGIEBfHDLb9UdjHfOiRxi lOZgURLnDXe9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUWWLKPcExkb+HNbDi40OTfpV 3tM84+aj1smfH3wqSvP6fevU0p3+XjtWRb/r2NeRYVNbcEWBifvbmk8VF9I1nUyEN/ZPE776 LfzLg2eMjoed9bWmeSZd333gy5xD32YoTQo5dsZwWkD7K/dpN973/puwdr2tVPNSpy39tqLp 133PbRIpdy1lna/EUpyRaKjFXFScCAC8yrT0LgIAAA==
Cc: Ari Keränen <ari.keranen@ericsson.com>, 'mmusic' <mmusic@ietf.org>, Dan Wing <dwing@cisco.com>
Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2013 16:47:21 -0000

Hi,

to add to what Magnus said, it is important that we understand what
implementations have been doing so far (regardless of what the RFC says)
and that we come up with recommendations implementers will actually
follow. Keep in mind we are here to write specifications, not fiction ;-)

Thanks,

Gonzalo


On 14/02/2013 5:51 PM, Magnus Westerlund wrote:
> Thus I would be careful with speeding up Ta for RTP to much, and I think
> someone needs to fine empiric data that it would work.
> 
> For the the 500 ms that can likely be significantly lowered without any
> issues. But some considerations around the wider usage needs to be taken
> into account.