Re: [MMUSIC] Bundle rejection oddities

Eric Rescorla <ekr@rtfm.com> Fri, 04 March 2016 11:57 UTC

Return-Path: <ekr@rtfm.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 0C0801B3725 for <mmusic@ietfa.amsl.com>; Fri, 4 Mar 2016 03:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.823
X-Spam-Level: *
X-Spam-Status: No, score=1.823 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6] autolearn=no
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 kyUTKhu93ZSZ for <mmusic@ietfa.amsl.com>; Fri, 4 Mar 2016 03:57:04 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A071B3724 for <mmusic@ietf.org>; Fri, 4 Mar 2016 03:57:04 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id h129so42446542ywb.1 for <mmusic@ietf.org>; Fri, 04 Mar 2016 03:57:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9LMKUgKJgduv0lbVvzCPPOJcEM4LiBpKR6i4koMISyw=; b=MswU3TaXORWEdOWocoG1xr2etC8EMktLfJJ18FkZohLd3e5IOZlCoXa8jC3JyXvCXX yPJ8veX0PEnSXKEl4Bl6h5KdECCtFoYj10eGi+6mFd0sRfyc4b3S/Zk5mrdvXu2Bx7Qz pp+dJi4XpCRphlerAQ/flmzyxtkmTkMtMASJIn47yq506r4AT59Ybu60gCccuTpT5T5I V/VRHjUa3RqdDYHT3SI4usN/M/uwh02rqxGRqxKA9IgJh7OB03SlpM0Ot/Gq1+6/UNxd ya8S9C5wB5LLyRb7ciz/Jo1cmHPvZh1rgLRaIokGNwZIPyxJjt3uqRsco1HFEUeJ1DWg GpgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9LMKUgKJgduv0lbVvzCPPOJcEM4LiBpKR6i4koMISyw=; b=bTDEK4nMH5H0j/JvmElT8F7+thtcWJzeyLKgYdwIz+KEIVUK/WJzlXlDSueJjsvW/j RYsWK2cHIyjXYyD22CoD4jTXCHvK43pU0ExIgUX8ZOvzyM3XCx2/h7dhmC1Nb4W2dnr/ jECwjzXhXoZaD4286Ayaa8G66x2vS3pCOrCvcCEI0lZVig1AGJf/jExpZUFr7wif3xa2 F6DNYPGPJon1q8j2rVpXwaldmd7bkJ4YRVq4TLdMKXPp60qcbt8hxfPYMER3C4uTnLxQ a8h8aAdianxNqdX9k5CZTlV9w4HzDB1VOhNBcsS6qPo2UfjnHRsPiNai4HLrGCWB9bS3 +A4w==
X-Gm-Message-State: AD7BkJJlpjK29ozlL+Bt/Q4Uknf74ESMkWCNIrzHR44PvVzCGKUnsWlXzMfv50/fEPBFTowN69tzA+kCep3dGg==
X-Received: by 10.129.38.135 with SMTP id m129mr4265195ywm.155.1457092623463; Fri, 04 Mar 2016 03:57:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Fri, 4 Mar 2016 03:56:24 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E59A2E@ESESSMB209.ericsson.se>
References: <CABcZeBO4FEACT851653xA5=onorvPe30Hoc6Lp79KRftRtoZGA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E591A9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E59A2E@ESESSMB209.ericsson.se>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 04 Mar 2016 03:56:24 -0800
Message-ID: <CABcZeBMfvvhQmF4+G+9fXfDHq50caBqP3wG=nVNVTD-m0=4iew@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a1141618c3a5261052d37d06b"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/6YGo_gu-YZI3JgWlLZ1dTLJNfOo>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Bundle rejection oddities
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: <https://mailarchive.ietf.org/arch/browse/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, 04 Mar 2016 11:57:06 -0000

On Thu, Mar 3, 2016 at 11:32 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> What about adding the following note to section 11.1:
>
>
>
>    “NOTE: The ICE-related media-level SDP attributes might end up being
> associated with
>
>    with an "m=" line in the answer that does not correspond to the "m="
> line
>
>    to which the ICE-related SDP attributes were associated in the
> associated offer.”
>
>
>
I think the key point here is not that but that the attributes may be
attached in the
offer to an m= line which ends up being defunct.

I'd also like to observe that this paragraph exemplifies an infelicity in
the current
draft, which is the overloading of the term "associated", which appears
three times
in this paragraph alone with two different meanings. I think it would be
clearer if
instead different terms were used. I suggest "member of" for being in a
bundle group,
"appears in" or "attached to" for being in a given m= section, and
"corresponding"
for "the SDP offer/answer that this answer/offer" goes with

-Ekr





> Regards,
>
>
>
> Christer
>
>
>
> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer
> Holmberg
> *Sent:* 4. maaliskuuta 2016 5:53
> *To:* Eric Rescorla; mmusic WG
> *Subject:* Re: [MMUSIC] Bundle rejection oddities
>
>
>
> Hi Ekr,
>
> I think I presented exactly the same use-case when it was first suggested
> to not associate shared candidates with each bundled m- line.
>
> I'll look if I can add some additional text somewhere, to point out that
> the candidates can be associated with different m- lines in offers and
> answers, e.g. due to the use-case you described.
>
> Regards,
>
> Christer
>
>
> Sent from my Windows Phone
> ------------------------------
>
> *From: *Eric Rescorla <ekr@rtfm.com>
> *Sent: *‎04/‎03/‎2016 02:53
> *To: *mmusic WG <mmusic@ietf.org>
> *Subject: *[MMUSIC] Bundle rejection oddities
>
> Hi folks,
>
>
>
> I've been working through the bundle draft and I've come across a sort
>
> of surprising consequence that I wanted to share with the group. Sorry
>
> for the extended example, but I think it's hard to get without that.
>
>
>
> Consider the case where an offerer has three m= lines, alpha, bravo,
>
> and charlie. This creates an initial offer that's (schematically) like
>
> this:
>
>
>
>    a=group:BUNDLE alpha bravo charlie
>
>    m=audio 1111
>
>    a=mid:alpha
>
>    a=candidate
>
>
>
>    m=video 2222
>
>    a=mid:bravo
>
>    a=candidate
>
>
>
>    m=video 3333
>
>    a=mid:charlie
>
>    a=candidate
>
>
>
> Per 8.2, and because this isn't bundle-only, each m= line has a unique
>
> address and a set of candidates (I'm ignoring the ufrag and ice-pwd
>
> for now).
>
>
>
> Assume that the answerer rejects the first m= line, so per 8.3, it
>
> pulls alpha out of the bundle group and sets is port number to 0.  Per
>
> 11.2, it only associates candidates with the answerer bundle tag,
>
> which is bravo:
>
>
>
>    a=group:BUNDLE bravo charlie
>
>    m=audio 0
>
>    a=mid:alpha
>
>
>
>    m=video 4444
>
>    a=mid:bravo
>
>    a=candidate
>
>
>
>    m=video 4444
>
>    a=mid:charlie
>
>
>
>
>
> So far so good. Now consider what happens if the offerer does an
>
> ICE restart and (for instance) changes some property about the
>
> second m= line. Per S 11.1 bullet 1, it only uses a shared address
>
> for the second two m= lines and only attaches a candidate to the
>
> second one (bravo). I.e.,
>
>
>
>    a=group:BUNDLE bravo charlie
>
>    m=audio 0
>
>    a=mid:alpha
>
>
>
>    m=video 5555
>
>    a=mid:bravo
>
>    a=candidate
>
>
>
>    m=video 5555
>
>    a=mid:charlie
>
>
>
>
>
> If the answerer decides to reject bravo (leaving only charlie),
>
> it now sets its port to 0 and pulls it out of the bundle group,
>
> giving us:
>
>
>
>    a=group:BUNDLE charlie
>
>    m=audio 0
>
>    a=mid:alpha
>
>
>
>    m=video 0
>
>    a=mid:bravo
>
>
>
>    m=video 4444
>
>    a=mid:charlie
>
>    a=candidate     <-- See here
>
>
>
>
>
> Note that the candidate here is on the third m= line but it needs to
>
> be paired with the candidates on the second (rejected) m= line from
>
> the offerer. I'm not saying that this is fatal: the logical
>
> interpretation is that the candidates (and other ICE parameters) are
>
> associated with the whole bundle group (and implicitly duplicated) and
>
> just appear with one m= line. However, it is a bit odd and probably
>
> should be called out in the spec lest people get confused.
>
>
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>