Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Christer Holmberg <[e-mail]>]

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:[e-mail]>
Sent: ‎09/‎03/‎2016 16:57
To: Christer Holmberg<mailto:[e-mail]>
Cc: Paul Kyzivat<mailto:[e-mail]>; Peter Thatcher<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Another question is whether this would have an impact on draft-ietf-mmusic-mux-attributes. Suhas?

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Christer Holmberg
Sent: March 09, 2016 15:43
To: 'Paul Kyzivat'; Peter Thatcher
Cc: [e-mail]<mailto:[e-mail]>
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"
>> <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>>
>> 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
>>> <[e-mail]<mailto:[e-mail]>>
>>> wrote:
>>> Sure.
>>>
>>> On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg
>>> <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
>>> Sent: 25 February 2016 08:53
>>> To: Christer Holmberg <[e-mail]<mailto:[e-mail]>>
>>> Cc: Roman Shpount <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Paul Kyzivat
>>> <[e-mail]<mailto:[e-mail]>>
>>>
>>> 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
>>> <[e-mail]<mailto:[e-mail]>> 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; [e-mail]<mailto:[e-mail]>; Paul Kyzivat
>>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE On
>>> Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg
>>> <[e-mail]<mailto:[e-mail]>> 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
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>

_______________________________________________
mmusic mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic