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

From: Peter Thatcher <[email-masked]>
Date: Fri, 4 Mar 2016 17:03:20 -0800

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?

On Fri, Feb 26, 2016 at 1:23 PM, Peter Thatcher <[email-masked]>
wrote:

> Sure.
>
> On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg <
> [email-masked]> 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:[email-masked]]
>> *Sent:* 25 February 2016 08:53
>> *To:* Christer Holmberg <[email-masked]>
>> *Cc:* Roman Shpount <[email-masked]>; [email-masked]; Paul Kyzivat <
>> [email-masked]>
>>
>> *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 <
>> [email-masked]> 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 <[email-masked]>
>> *Sent: *‎21/‎02/‎2016 08:21
>> *To: *Christer Holmberg <[email-masked]>
>> *Cc: *Peter Thatcher <[email-masked]>; [email-masked]; Paul
>> Kyzivat <[email-masked]>
>> *Subject: *Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>>
>> On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg <
>> [email-masked]> 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
>>
>>
>>
>>
>>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 5 Mar 2016 14:04:27 +0000

Hi,

>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 <[email-masked]> wrote:
Sure.

On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg <[email-masked]> 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:[email-masked]] 
Sent: 25 February 2016 08:53
To: Christer Holmberg <[email-masked]>
Cc: Roman Shpount <[email-masked]>; [email-masked]; Paul Kyzivat <[email-masked]>

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 <[email-masked]> 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; [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
On Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg <[email-masked]> 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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Mar 2016 07:47:44 +0000

Hi,

Does anyone else have opinions on this? One would assume that the folks
(Bernard, Martin, Ekr…) representing the other browser vendors would have
an opinion.

Whatever your opinion is (even if you don’t care), please indicate so NOW.
I want to avoid implementing this change, and then have someone saying
he/she doesn’t like it...

Regards,

Christer

On 05/03/16 16:04, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>>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
>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
>
>
>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
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 8 Mar 2016 11:20:27 -0500

> he/she doesn’t like it...

I have lost track - is the intent to limit this de-duplication to 
bundle-only? If it is to apply to m-lines that might be removed from the 
bundle then it gets more complicated.

I guess it couldn't *only* apply to bundle-only - at least one of the 
lines in the group can't have that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Mar 2016 19:08:48 +0000

Hi,

>> Does anyone else have opinions on this? One would assume that the 
>> folks (Bernard, Martin, Ekr…) representing the other browser vendors 
>> would have an opinion.
>>
> I have lost track - is the intent to limit this de-duplication to bundle-only? If it is to apply to m-lines that might be removed from the bundle then it gets more complicated.
>
> I guess it couldn't *only* apply to bundle-only - at least one of the lines in the group can't have that.

It applies to bundled m- lines that contain a previously negotiated *shared* address (not only bundle-only).

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.

Regards,

Christer

>>> 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
>>
>>
>> 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
>>
>> 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
>>
>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE On 
>> Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg 
>> <[email-masked]> wrote:
>>>> 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
>>> 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
>>
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 8 Mar 2016 14:20:56 -0500

> 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.

	Thanks,
	Paul

---

From: Justin Uberti <[email-masked]>
Date: Tue, 8 Mar 2016 20:30:02 -0800

I agree - if we're going to avoid duplication of ICE attributes, we should
do the same for the other transport attributes too.

On Tue, Mar 8, 2016 at 11:20 AM, Paul Kyzivat <[email-masked]> wrote:

>> 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.
>>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 13:43:17 +0000

Hi,

...

> 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

>>> 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
>>>
>>>>> 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 
>>>> offer/answer action (thanks to trickle ICE). ​ So if we just 
>>>> covered that candidates, we'd be getting most of the value.
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 13:46:41 +0000

Another question is whether this would have an impact on draft-ietf-mmusic-mux-attributes. Suhas?

Regards,

Christer

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

Hi,

...

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 9 Mar 2016 06:57:06 -0800

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 <
[email-masked]> wrote:

> >> 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.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 15:21:31 +0000

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:[email-masked]>
Sent: ‎09/‎03/‎2016 16:57
To: Christer Holmberg<mailto:[email-masked]>
Cc: Paul Kyzivat<mailto:[email-masked]>; Peter Thatcher<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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.

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

Regards,

Christer

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

Hi,

...

Regards,

Christer

>> <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>>
>> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Feb 26, 2016 at 1:23 PM, Peter Thatcher
>>> <[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>> Sure.
>>>
>>> On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>> Hi Peter,
>>>
>>> From: Peter Thatcher [mailto:[email-masked]<mailto:[email-masked]>]
>>> To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
>>> Cc: Roman Shpount <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Paul Kyzivat
>>> <[email-masked]<mailto:[email-masked]>>
>>>
>>> On Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>> Hi Roman,
>>>
>>> Cc: Peter Thatcher; [email-masked]<mailto:[email-masked]>; Paul Kyzivat
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>> [email-masked]<mailto:[email-masked]>

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

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 9 Mar 2016 07:26:03 -0800

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 <
[email-masked]> 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
>
> From: Suhas Nandakumar <[email-masked]>
> Cc: Paul Kyzivat <[email-masked]>; Peter Thatcher
> <[email-masked]>; [email-masked]
>
> 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.
>
>
>> >>> <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 15:28:16 +0000

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: ‎09/‎03/‎2016 17:26

Hello Christer

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Suhas,

Regards,

Christer

Hello Christer et al

Regards,

Christer

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

Hi,

...

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 9 Mar 2016 10:02:28 -0800

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 <
[email-masked]> 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
>
> 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
>
>
>
>>   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 ...
>>
>>
>>> >> 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.
>>> >

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 18:28:34 +0000

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:[email-masked]>
Sent: ‎09/‎03/‎2016 20:02
To: Christer Holmberg<mailto:[email-masked]>
Cc: Suhas Nandakumar<mailto:[email-masked]>; Paul Kyzivat<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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:

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

Initial answer:

   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:

   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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Hello Christer

Thanks
Suhas

Regards,

Christer

Hello Christer et al

Regards,

Christer

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

Hi,

...

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 9 Mar 2016 11:03:27 -0800

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 <
[email-masked]> 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
>
> From: Taylor Brandstetter <[email-masked]>
> Cc: Suhas Nandakumar <[email-masked]>; Paul Kyzivat
> <[email-masked]>; [email-masked]
>
> 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
>>>> >> <[email-masked] on behalf of [email-masked]
>>>> >
>>>> >> wrote:
>>>> >>
>>>> >>> Hi,
>>>> >>>
>>>> >>> Cc: Roman Shpount <[email-masked]>; [email-masked]; Paul
>>>> Kyzivat
>>>> >>> <[email-masked]>
>>>> >>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 08:42:29 +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 <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 9 March 2016 at 21:03
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Suhas Nandakumar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Taylor,

Regards,

Christer

Initial offer:

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

Initial answer:

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

Offer:

   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

Regards,

Christer

Hello Christer

Thanks
Suhas

Regards,

Christer

Hello Christer et al

Regards,

Christer

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

Hi,

...

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 17 Mar 2016 10:30:31 -0700

Could you elaborate? I'm not clear on what you mean by "identical", or how
it addresses my point.

On Thu, Mar 17, 2016 at 1:42 AM, Christer Holmberg <
[email-masked]> wrote:

> Cc: Suhas Nandakumar <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
>
>> 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
>>>> 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.
>>>>
>>>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Mar 2016 11:43:38 +0000

Hi,

My point is that, if we in BUNDLE don’t mandate IDENTICAL and TRANSPORT category attributes in each bundled m- line, we need to make sure that draft-mux-attributes is aligned.

Regards,

Christer

Date: Thursday 17 March 2016 at 19:30

Could you elaborate? I'm not clear on what you mean by "identical", or how it addresses my point.

On Thu, Mar 17, 2016 at 1:42 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Taylor,

Regards,

Christer

Regards,

Christer

Initial offer:

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

Initial answer:

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

Offer:

   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

Regards,

Christer

Hello Christer

Thanks
Suhas

Regards,

Christer

Hello Christer et al

Regards,

Christer

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

Hi,

...

Regards,

Christer