Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 17 March 2016 08:42 UTC

Return-Path: <christer.holmberg@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 25CB312D681 for <mmusic@ietfa.amsl.com>; Thu, 17 Mar 2016 01:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 s5ppV9hoJ7-0 for <mmusic@ietfa.amsl.com>; Thu, 17 Mar 2016 01:42:33 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB14712D515 for <mmusic@ietf.org>; Thu, 17 Mar 2016 01:42:31 -0700 (PDT)
X-AuditID: c1b4fb3a-f79d86d000005b69-40-56ea6df54af6
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FD.47.23401.5FD6AE65; Thu, 17 Mar 2016 09:42:30 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Thu, 17 Mar 2016 09:42:29 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Taylor Brandstetter <deadbeef@google.com>
Thread-Topic: [MMUSIC] Questions about ICE candidates with BUNDLE
Thread-Index: AQHRHYnoiYnnoBeSf02zTdZqfDK2qp6Y3iNggABJvwCAAPE6oIAAZwIAgACl+dCABARVgIAAGXLg///2/wCAkCNi4IAC75iggAA8gYCAADDekIACZK0AgACy7bCAAMFzgIAAUWfNgAYA1QCAADZUAIACTzoAgAs9uQCAAOpNEIAEXzeAgABtuICAAD8/oP//8y4AgAFEVNCAAAE0EIAAAxYAgAAXlcT///CCgAACLFiEAANKJAAAAwHjRv//+PqAgAwGrYA=
Date: Thu, 17 Mar 2016 08:42:29 +0000
Message-ID: <D3103982.5BA2%christer.holmberg@ericsson.com>
References: <CAJrXDUHutBgaPOV73-CyD_Knz+G5RFE0VX4s3+GqGV8K=B1LNA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E061CD@ESESSMB209.ericsson.se> <56C5F405.1020305@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E07AE0@ESESSMB209.ericsson.se> <CAJrXDUGU8SuBHJNQ+Y5DBYcj5pukfXQc742dEFAPCiUKDxN2Cw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E21B6C@ESESSMB209.ericsson.se> <CAD5OKxvj25TE-RCvGOU4LQV=a+3aCzZLEB6U=SbTTUmoKVbXeA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E24284@ESESSMB209.ericsson.se> <CAJrXDUG-9CE=vx31gpJZ+Yeb_4LEqUfWWqDsyQNFk1MWfbcTng@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E40FC1@ESESSMB209.ericsson.se> <CAJrXDUFAFymTO+wZnv-8c4pbEbEPSmPprevX_BZY9GS6PNeOXA@mail.gmail.com> <CAJrXDUEGOyASOErt_DHFpaAS-TScxQ=5NHexpjeKS9LPCJ+Qvg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E7032B@ESESSMB209.ericsson.se> <D3044F95.55CF%christer.holmberg@ericsson.com> <56DEFBCB.70203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E9EAC2@ESESSMB209.ericsson.se> <56DF2618.2080204@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37EA3F10@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EA43A9@ESESSMB209.ericsson.se> <CAMRcRGSJMNcASmvnZuqOh=ZGF0QY8+WX2HWRxqRdAaN8pfzMpA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37EA5E65@ESESSMB209.ericsson.se> <CAMRcRGRa1mNPwsCS3VQ1+ejUa7FUXgO2sKXYTr5p8DP7TRa=Ew@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37EA5F18@ESESSMB209.ericsson.se> <CAK35n0YTOyg9xF1Tur=FXCE83bgs_3iCe0VfnfCyqxRwP9QLFQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37EA6D33@ESESSMB209.ericsson.se> <CAK35n0aY_Lw8Mau22ZSDZt9WnMuFG37DNum-1cVuuPAf2Fs=Yg@mail.gmail.com>
In-Reply-To: <CAK35n0aY_Lw8Mau22ZSDZt9WnMuFG37DNum-1cVuuPAf2Fs=Yg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_D31039825BA2christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUyM2K7ve633FdhBg8Xs1hcXvGQ1WLq8scs Fis2HGC12Dm3g9mBxePv+w9MHjtn3WX3WLCp1GPJkp9MASxRXDYpqTmZZalF+nYJXBmXnv9i KTjZyVzxof0bUwPjsv9MXYycHBICJhKt2yeyQNhiEhfurWfrYuTiEBI4zCjxaf4lKGcJo8TG GVeBHA4ONgELie5/2iANIgK6Eje/LmQDsZkFyiW2XzzFDmILCzhITLrdzA5R4ygxZ8U5sDki AtOYJN63PGUGSbAIqEr8nL6SEcTmFbCSuNLWxAyxbBKvxPFrL8GmcgoESnz78hqsgRHovO+n 1jBBbBOXuPVkPtQLAhJL9pxnhrBFJV4+/scKYosK6EnsOAdhSwgoSSy6/RmqN16i/chzJojF ghInZz5hmcAoNgvJ2FlIymYhKZsF9D+zgKbE+l36ECWKElO6H7JD2BoSrXPmQtnWEtf/g5Qj 1Cxg5FjFKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERjLB7f8ttrBePC54yFGAQ5GJR7egqcv w4RYE8uKK3MPMUpwMCuJ8DLGvAoT4k1JrKxKLcqPLyrNSS0+xCjNwaIkzsv26XKYkEB6Yklq dmpqQWoRTJaJg1OqgdHex2G3xM/TD/qmnFOYs6U08WvFHCHO/A/zkleezVjYeP+W+c107kUe tg9+G3oKOlTInbrKxuosr/Z0dmyCatvk1XIT5CK0F2y+ock24T/XhsqrvMdPpF43F+j76/NW 4pG+bdFpj44sYcXVd2U1OS9ue/KospKDg3G/V4DFvTcnT//9de3z0xolluKMREMt5qLiRADS rhTb4QIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/GDq4MAKS-9-28G3VfFpsigpUsWU>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 17 Mar 2016 08:42:35 -0000

Hi Taylor,

When a shared address is use, the ICE attributes etc should be identical.

In any case, we do need to double check that the text is aligned between the drafts.

Regards,

Christer

From: Taylor Brandstetter <deadbeef@google.com<mailto:deadbeef@google.com>>
Date: Wednesday 9 March 2016 at 21:03
To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Cc: Suhas Nandakumar <suhasietf@gmail.com<mailto:suhasietf@gmail.com>>, "pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>" <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>>, "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Well, currently draft-mux-attributes says that for TRANSPORT attributes, "software MUST pick the [attribute value] that's associated with the "m=" line whose information is used for setting up the underlying transport." I assume this refers to the m= line associated with the answerer BUNDLE-tag.

However, the BUNDLE draft implies that when a shared address is used, the software should use the offerer's ICE attributes associated with the offerer BUNDLE-tag, which in some cases (as in the example above) differs from the answerer BUNDLE-tag. So it seems like there's an inconsistency between the two drafts for this

On Wed, Mar 9, 2016 at 10:28 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Hi Taylor,

You are right, it applies to both TRANSPORT and IDENTICAL. But, based on Suhas' response we would not need any changes for TRANSPORT in draft-mux-attributes.

Also note that the rules also only apply to bundled m- lines with a shared address. m- lines with a unique address must still contain explicit attributes, in case the m- line is moved out if the bundle group by the answerer.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Taylor Brandstetter<mailto:deadbeef@google.com>
Sent: ‎09/‎03/‎2016 20:02
To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>
Cc: Suhas Nandakumar<mailto:suhasietf@gmail.com>; Paul Kyzivat<mailto:pkyzivat@alum.mit.edu>; mmusic@ietf.org<mailto:mmusic@ietf.org>

Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Isn't it true that even within the TRANSPORT category, the scenario Ekr brought up could have unexpected effects? Specifically, the scenario where the "BUNDLE negotiated m= line" changes between the offer and answer, as a result of a media section being rejected. For example:

Initial offer:

   a=group:BUNDLE alpha bravo
   m=audio 1111
   a=mid:alpha
   a=fingerprint:foo

   m=video 2222
   a=mid:bravo
   a=fingerprint:bar

Initial answer:

   a=group:BUNDLE alpha bravo
   m=audio 3333
   a=mid:alpha
   a=fingerprint:baz

   m=video 4444
   a=mid:bravo
   a=fingerprint:qux

At this point the BUNDLE negotiated m= line is "alpha", so both endpoints know what fingerprint to use. Now, what if the initial offerer decides to change some attributes of the first media section (not described here), and the answerer rejects it, changing the BUNDLE negotiated m= line?

Offer:

   a=group:BUNDLE alpha bravo
   m=audio 1111
   a=mid:alpha
   a=fingerprint:foo

   m=video 1111
   a=mid:bravo
   a=fingerprint:bar

Answer:

   a=group:BUNDLE bravo
   m=audio 0
   a=mid:alpha
   a=fingerprint:baz

   m=video 3333
   a=mid:bravo
   a=fingerprint:baz

The answerer updated the fingerprint of the second m= section, to try to use the same DTLS session. But the offerer didn't, because it assumed the bundled m= line wouldn't change. So it seems like this would be interpreted as the offerer changing its fingerprint from "foo" to "bar".

If that's the way other people interpret this situation as well, should there at least be a warning calling out this situation? For example, "If an offerer desires that a TRANSPORT attribute for a BUNDLE group stays the same even if the answerer rejects the media section currently associated with the BUNDLE group, the attribute SHOULD be duplicated within each media section in the BUNDLE group."

Of course, this would go completely contrary to how the ICE attributes work (as of recently). Which is why I think whatever rule we decide for the ICE attributes (be it duplicating them or not duplicating them) should be generalized for all TRANSPORT attributes.



On Wed, Mar 9, 2016 at 7:28 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Hi,

Perhaps we would then need to change the text for IDENTICAL, or do you think there is a reason to associate them with each m- line?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Suhas Nandakumar<mailto:suhasietf@gmail.com>
Sent: ‎09/‎03/‎2016 17:26

To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>
Cc: Paul Kyzivat<mailto:pkyzivat@alum.mit.edu>; Peter Thatcher<mailto:pthatcher@google.com>; mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Hello Christer

 I don't think the mux draft says that independent of the categories.

However for the IDENTICAL category, it does say that the attribute (and its associated value) must be repeated across all the m=lines in the bundled group. For the rest of the categories , we don't really say anything about how the attribute exists in a given m=line but leave it to its normal usages.

Thanks
Suhas



On Wed, Mar 9, 2016 at 7:21 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Hi Suhas,

My question is not about the semantics of the categories, but whether there is text saying that all attributes must explicitly be associated with each m- line (no matter the category).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Suhas Nandakumar<mailto:suhasietf@gmail.com>
Sent: ‎09/‎03/‎2016 16:57
To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>
Cc: Paul Kyzivat<mailto:pkyzivat@alum.mit.edu>; Peter Thatcher<mailto:pthatcher@google.com>; mmusic@ietf.org<mailto:mmusic@ietf.org>

Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Hello Christer et al

  I am traveling this week and having difficulty in following lot of these discussions. So please bare with me if I am mis-representing the question here ...


From the mux spec, the TRANSPORT category implies that no matter if a particular attribute is repeated or has different values across the m=lines , the one to be chose MUST correspond to the BUNDLE negotiated m= line.

Thus, if we apply de-duplication in the way Offer/Answer is constructed, as long as the above rule applies when an attribute is selected for its value, things should be OK.


Does this answer the question ?



On Wed, Mar 9, 2016 at 5:46 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Another question is whether this would have an impact on draft-ietf-mmusic-mux-attributes. Suhas?

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org>] On Behalf Of Christer Holmberg
Sent: March 09, 2016 15:43
To: 'Paul Kyzivat'; Peter Thatcher
Cc: mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE

Hi,

...

>> We already specified this for ICE-related attributes, and the question is whether we should do it also for other attributes that must share the same value.
>
> OK. At the moment I can't think of any reason not to generalize this.

One reason would be if nobody gives a **** :)

Regards,

Christer



>> On 05/03/16 16:04, "mmusic on behalf of Christer Holmberg"
>> <mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org> on behalf of christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
>> wrote:
>>
>>> Hi,
>>>
>>>> I took a look, and it seems fine to me.
>>>>
>>>> One question that was brought up to me about this is, though is:
>>>> would it make sense to expand this de-duplication rule to all
>>>> transport-level attributes (like a=fingerprint) and not just ICE
>>>> attributes?  We talked about this before, and my response was
>>>> basically "the ICE candidates are my biggest pain point", but now I
>>>> think I'm more in favor of saying all transport-level attributes
>>>> should be de-duplicated.  What does everyone else think?
>>>
>>> I guess it would apply to transport-level attributes AND other
>>> attributes that must have identical values within a bundle group,
>>> i.e. attributes within the TRANSPORT and IDENTICAL categories [draft-mux-attributes].
>>>
>>> I don't have any strong opinions. If you think it make life easier
>>> for implementers we should definitely consider it :)
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>> On Fri, Feb 26, 2016 at 1:23 PM, Peter Thatcher
>>> <pthatcher@google.com<mailto:pthatcher@google.com>>
>>> wrote:
>>> Sure.
>>>
>>> On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg
>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
>>> Hi Peter,
>>>
>>> I submitted a new version (-27) of BUNDLE a few days ago. Could you
>>> take a look at the ICE Considerations section, and say whether you
>>> are ok with the text?
>>>
>>> Thanks!
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> From: Peter Thatcher [mailto:pthatcher@google.com<mailto:pthatcher@google.com>]
>>> Sent: 25 February 2016 08:53
>>> To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
>>> Cc: Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>>; mmusic@ietf.org<mailto:mmusic@ietf.org>; Paul Kyzivat
>>> <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>>
>>>
>>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>>>
>>> That makes sense to me.
>>>
>>> On Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg
>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
>>> Hi Roman,
>>>
>>> I didn't check whether some of the ICE attributes were
>>> session-level, but I agree with what you say: the same rule should
>>> apply to all media-level ICE attributes.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> Sent from my Windows Phone
>>> ________________________________________
>>> From: Roman Shpount
>>> Sent: ‎21/‎02/‎2016 08:21
>>> To: Christer Holmberg
>>> Cc: Peter Thatcher; mmusic@ietf.org<mailto:mmusic@ietf.org>; Paul Kyzivat
>>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE On
>>> Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg
>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
>>>>> Correct, and that's one reason I suggest that we limit the scope
>>>>> to ICE, eventhough we probably could do the same thing for any
>>>>> IDENTICAL and TRANSPORT category attribute.
>>>>
>>> ​> While it would be nice to remove any duplication, the duplication
>>> is particularly painful for ICE candidates, because
>>>> there can be a lot of them, and because they change without any
>>>> offer/answer action (thanks to trickle ICE). ​ So if we just
>>>> covered that candidates, we'd be getting most of the value.
>>>
>>> Assuming the scope is ICE, shouldn't the same still apply also to
>>> other ICE related attributes? I assume the values for the
>>> "remote-candidates", "ice-lite", "ice-mismatch", "ice-ufrag",
>>> "ice-pwd", "ice-pacing" and "ice-options" attributes will be identical within a BUNDLE group, so...
>>>
>>> "ice-lite" and "ice-options" are session level only candidates, so
>>> they should not be in the m= line BUNDLE or any other type. The same
>>> logic that applies to ICe candidates should apply to other media
>>> level ICE SDP attributes or things will break
>>>
>>> Regards,
>>> _____________
>>> Roman Shpount
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org<mailto:mmusic@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic



_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic