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> 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 <suhasietf@gmail.com>
> Sent: ‎09/‎03/‎2016 16:57
> To: Christer Holmberg <christer.holmberg@ericsson.com>
> Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>; Peter Thatcher
> <pthatcher@google.com>; 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> 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] On Behalf Of Christer
>> Holmberg
>> Sent: March 09, 2016 15:43
>> To: 'Paul Kyzivat'; Peter Thatcher
>> Cc: 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 on behalf of 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>
>> >>> wrote:
>> >>> Sure.
>> >>>
>> >>> On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg
>> >>> <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]
>> >>> Sent: 25 February 2016 08:53
>> >>> To: Christer Holmberg <christer.holmberg@ericsson.com>
>> >>> Cc: Roman Shpount <roman@telurix.com>; mmusic@ietf.org; Paul Kyzivat
>> >>> <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> 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; 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> 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
>> >>> https://www.ietf.org/mailman/listinfo/mmusic
>> >>
>> >
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>