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 17:12 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 E9BDD1A02A6 for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 10:12:18 -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 BXERa-bwYcAc for <mmusic@ietfa.amsl.com>; Wed, 30 Jul 2014 10:12:13 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB281A02DE for <mmusic@ietf.org>; Wed, 30 Jul 2014 10:12:13 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id n3so2700978wiv.13 for <mmusic@ietf.org>; Wed, 30 Jul 2014 10:12:11 -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=5c5KFXCtCfE4w6YQ4aT0Nt+AQBSPfbHQXpNN1lA2C5w=; b=Bd1otQiWcOGJ1hv8YzzUJAOp6tBGHKDzNt8CDC3kNVRu/1i2UUI69tlwtWk3dVpzty dYXqHHD/aXadc1exmbEI6hxvzvxwXB8H6ioAKCRZGpJPBsLKQUl+V+R3slOlbadtEY57 ziVnuiO7SeG+843JByPs0eHO6SsvR4BfwdErHugqxev4ZSwEKMmijm9yJLQJWx5YRVQG pUvKau0AaOVX8NgAFgvcXB+WgTf8Xa3mUVGKMca6lKMOr8/kcSLDM9bG5OntMM6kYcv6 A/AUJ2wSf5QRjO0c0ULTgYfL2L8ugM83kbhntGvKRi/u3acmxrbcW5tINT51J6NURwc6 BS4w==
MIME-Version: 1.0
X-Received: by 10.180.84.7 with SMTP id u7mr9053940wiy.1.1406740331878; Wed, 30 Jul 2014 10:12:11 -0700 (PDT)
Received: by 10.194.169.10 with HTTP; Wed, 30 Jul 2014 10:12:11 -0700 (PDT)
In-Reply-To: <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.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>
Date: Wed, 30 Jul 2014 10:12:11 -0700
Message-ID: <CABkgnnXHj+Q8UQQ6ULeSaPSkvmv7AAkv=zcZQ8pQB4A6dGMVdg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/MslEXq8E77L5W30DEjI-x_Y1ZXA
Cc: 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 17:12:19 -0000

(Completing the move)

On 30 July 2014 08:10, Jonathan Lennox <jonathan@vidyo.com> wrote:
> This is equivalent to using regular nomination, but saying that an endpoint can send media on any Confirmed candidate pair, not just the Selected one, right?

I like this idea.  I don't know what this does to other
implementations, but Firefox would probably be OK with that based on
my quick check of the code.

The only caveat on that is that we need to have a remote candidate for
the flow before it gets delivered.  We create candidates based on one
of three conditions, as 5245 requires: we have received a valid check
from that remote address, we have received a check response from that
remote address, or the remote address was signaled.  If we are
trickling, that could mean that valid packets get discarded for some
time.  I think that the only downside there is that the sender needs
to retransmit their DTLS handshake packets.

That approach more or less renders aggressive nomination pointless, doesn't it?

v2.23.0 | Report a Bug | By Email