Re: [MMUSIC] Bundle rejection oddities

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 04 March 2016 16:46 UTC

Return-Path: <christer.holmberg@ericsson.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 DA7FB1A1A4D for <mmusic@ietfa.amsl.com>; Fri, 4 Mar 2016 08:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Level:
X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 XdFHPvC8cuYt for <mmusic@ietfa.amsl.com>; Fri, 4 Mar 2016 08:46:42 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548EC1A1A48 for <mmusic@ietf.org>; Fri, 4 Mar 2016 08:46:41 -0800 (PST)
X-AuditID: c1b4fb30-f79d26d000006389-6a-56d9bbef33b9
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.1E.25481.FEBB9D65; Fri, 4 Mar 2016 17:46:39 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Fri, 4 Mar 2016 17:46:04 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [MMUSIC] Bundle rejection oddities
Thread-Index: AQHRdbAze3OVqIuh4UG8lpLJiZIPzJ9Ip1fEgAA8meCAADmsAIAAGfeA///0wACAAEjsQA==
Date: Fri, 04 Mar 2016 16:46:03 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37E5C221@ESESSMB209.ericsson.se>
References: <CABcZeBO4FEACT851653xA5=onorvPe30Hoc6Lp79KRftRtoZGA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E591A9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E59A2E@ESESSMB209.ericsson.se> <CABcZeBMfvvhQmF4+G+9fXfDHq50caBqP3wG=nVNVTD-m0=4iew@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E5BC45@ESESSMB209.ericsson.se> <CABcZeBMZ2Z9Rgzx_4FWKyEE51SC=DXC18Kwzqah6L1xxX311BQ@mail.gmail.com>
In-Reply-To: <CABcZeBMZ2Z9Rgzx_4FWKyEE51SC=DXC18Kwzqah6L1xxX311BQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdS/f97pthBit3yFiseH2O3WLq8scs DkweS5b8ZPKY/LiNOYApissmJTUnsyy1SN8ugSvj/rofzAXXXCvu/ZrG3sD4wbmLkZNDQsBE ov/pZCYIW0ziwr31bCC2kMBhRolFF4y7GLmA7EWMEl867jF2MXJwsAlYSHT/0wapERFQkPj1 5wQLiM0sIC9xYckasDnCAvoS76Y8YoeoMZCYcPEtK4QdJnH3yhOwOIuAisSSXa2sICN5BXwl 7n7PhVi1ilnizs49YDM5BQIlPp45CnYPI9Bt309BzGcWEJe49WQ+1M0CEkv2nGeGsEUlXj7+ xwphK0ms2H4J7GRmAU2J9bv0IVoVJaZ0PwQ7gVdAUOLkzCcsExjFZiGZOguhYxaSjllIOhYw sqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIycg1t+G+xgfPnc8RCjAAejEg/vhhXXw4RY E8uKK3MPMUpwMCuJ8O6adTNMiDclsbIqtSg/vqg0J7X4EKM0B4uSOC/rp8thQgLpiSWp2amp BalFMFkmDk6pBkaud2tO99ZeUth3x31izwzDCfUnzyRfmqdZat7FxPtm06r8PyrHu9rEl3qZ Zzd//XHvgVEBb//7c5mHJpzkPdIhHelnyH3jp2GOcUbD4g1R14R8mLfq8dhW3Ipr8WFNnFh8 Z1dLaZiEz69zszbNl+8XaGSY6PnULXHuhXeb83OfmM5JPGnkb6vEUpyRaKjFXFScCADv0CQK mAIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/PLROYZ9SOs3-DmaTPMBfS8rwWrs>
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 16:46:44 -0000

Hi,

>>>>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.
>
>> That could e.g. be covered by adding the following sentence to the note:
>>
>> "This could happen e.g. if the "m=" line in the offer is rejected and moved out
>>of the bundle group by the answerer."
>
> Well, I think the key point here is that you need to take the attributes out of the
> defunct line, which neither this text nor the previous text really captures.

The 3rd bullet in the bullet list does say:

      "the answerer only associates ICE-related media-level SDP attributes with the "m=" line associated with the
      answerer BUNDLE-tag."

Perhaps we could add to that statement:

"The answerer MUST NOT associated ICE-related media-level SDP attributes with any other "m=" lines within the bundle group."

(And a similar statement to the bullet talking about the offer)


-------------


>>>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
>>
>> I agree that "associated" is used in many places. But, I have had to change the terminology so many 
>> times already, because every time someone has reviewed the document he/she has had ideas on how to modify the terminology.
>>
>> The current terminology is what we have been able to agree upon, so I do not want to change it again. I really think it's time to ship BUNDLE.
>
> I'm happy to have different terminology but not to have the same term used for multiple
> purposes, which is the current situation. I'm sympathetic to editor fatigue, but I think
> having the document be readable is more important.

Just a few comments on your suggestions:

- You suggest saying "member of bundle group". But, I don't think I say "associated with bundle group", but "within bundle group". At least that is my intention, so please let me know if you've found some places where that's not the case.

- You suggest saying "attribute appearing in m- line". Such terminology has been used in the past, and I was asked to change it, because attributes are not part of m- lines.

- I do use "corresponding" when I talk about m- lines in offers and answers. If we use it "corresponding" also for offers and answers we would end up with text like "the corresponding m- line in the corresponding answer".

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
Sent: ‎04/‎03/‎2016 02:53
To: mmusic WG
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