IETF Logo Mail Archive

Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

Martin Thomson <martin.thomson@gmail.com> Wed, 30 July 2014 22:06 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DF71A07AB for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 15:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9060RIdEFCCv for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 15:06:07 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BA41A01CA for <mmusic@ietf.org>; Wed, 30 Jul 2014 15:06:06 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id a1so1826895wgh.23 for <mmusic@ietf.org>; Wed, 30 Jul 2014 15:06:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=28QpCY8Dhl2NDMlYgjvGafOw5sp7RjyAPPgLTX8e/LA=; b=pzP5tXRCduv7sK6R/XF96EcYFHqJIsQQ1RjPhcb+y2JL+IwBTXx5zcO1yQmuvGt8MX Qataa0w8cxAvNXDpoC0p+MwTegftAgwcoYgyjATgvN01GnPH2YUXbAKtRy7S7YSkyIkd EdYsInY42tTxAuTddQoCistTq0IomuXvgZVKK7y/ZiAENUvDZuTYtfsEcZ32FkET09n6 T+CQIN8dXgw1TZhG8TSkPHtneq7E990prJ4fIYdM3zILh+Zl4UN8svNfjqJhXjfOBeeH Y42ykDJzrYGz51y18kOhxLAklgs5oNRdNUu6BiepXg2OC0GDa6oIOsackoM472QfRzJz 1d7Q==
MIME-Version: 1.0
X-Received: by 10.180.103.74 with SMTP id fu10mr9932234wib.47.1406757965464; Wed, 30 Jul 2014 15:06:05 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 15:06:05 -0700 (PDT)
In-Reply-To: <CAOJ7v-2O3TwNcsKqp48PjDRu+Yu_+jEurecbO2GctD4Hsuu+NA@mail.gmail.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <CAOJ7v-1jLK7dWDkWHKwHJ6qXicZWDNrAqOtw9R=6zAcWzkh5+g@mail.gmail.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <CAOJ7v-0HEjQQ+j0cAVc5r3Y4LxaoGF7EN2twGG6vTuMmEeragQ@mail.gmail.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <CAOJ7v-1HzGoUNXjvXph0-8WfpM6-vFJ+yDWhVw1_1grfrVD1Vw@mail.gmail.com> <B2794643-ADB5-4B66-98DC-841990C85437@vidyo.com> <CAOJ7v-2O3TwNcsKqp48PjDRu+Yu_+jEurecbO2GctD4Hsuu+NA@mail.gmail.com>
Date: Wed, 30 Jul 2014 15:06:05 -0700
Message-ID: <CABkgnnVmvq3oOyThL7bhvJ-FFnUeSk1hjHcvip2c8=nkgfJgKw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Kh4-38XzFpiB_tkdsBZVPdMLxyA
Cc: Jonathan Lennox <jonathan@vidyo.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 30 Jul 2014 22:06:09 -0000

On 30 July 2014 14:59, Justin Uberti <juberti@google.com> wrote:
> Basically, controlled side uses the pair that it most recently received
> USE-CANDIDATE on as its selected pair.

That's pretty good.  It would potentially allow us to move the active
pair around in future (i.e., mobility stuff) without massive backward
compatibility breaks too.  Unilaterally even.

> Since the controlled side sends the ClientHello in the typical case, this
> isn't usually a problem. The issue that is most often seen is that the
> ServerHello comes from B instead of A and is ignored.

Yeah, this works out pretty well, unless you have the offerer picking
an active role intentionally.  (We've had some errors come up recently
where there was confusion about which role was which; we definitely
want to avoid that.)

v2.23.0 | Report a Bug | By Email