Having both bundle-only "m=" sections and non-bundle-only in the same offer doesn't work.

[taylor-b]

Suppose the offerer wants to offer two "m=" sections with fallback to being non-bundled, and two bundle-only "m=" sections:

a=group:BUNDLE A B C D
m=video 1000
a=mid:A
m=video 2000
a=mid:B
m=video 0
a=mid:C
a=bundle-only
m=video 0
a=mid:D
a=bundle-only

The answerer wants to keep the bundle-only "m=" sections in the BUNDLE group, but remove the "m=" sections that offer fallback:

a=group:BUNDLE C D
m=video 3000
a=mid:A
m=video 4000
a=mid:B
m=video 5000
a=mid:C
m=video 5000
a=mid:D

This can't possibly work, because the offer only contains 2 unique addresses, but 3 are needed.

I recommend we resolve this by requiring that when using "a=bundle-only", everything in a BUNDLE group is bundle-only, and a BUNDLE-aware answerer is not allowed to remove something from a BUNDLE group.

In the above example, this would mean that both "A" and "B" would be inherently bundle-only, and can't be removed from the BUNDLE group without being rejected.

[cdh4u]

I am not sure I understand. Even if the answerer would not be allowed to remove A and B from the BUNDLE group, the answerer could still choose to reject A and B.

Also, I am not sure not allowing to remove A and B is a very good idea. What if the answerer can't keep A in the BUNDLE group, because it is will send media from a different physical device? The answerer would still like to keep everything else in the BUNDLE group, though.

[taylor-b]

Even if the answerer would not be allowed to remove A and B from the BUNDLE group, the answerer could still choose to reject A and B.

If the answerer rejects A, then it could use the address from A for the BUNDLE group (if we were to specify how that works). Whereas if it simply removes A from the group, it can't use A's address.

Also, I am not sure not allowing to remove A and B is a very good idea. What if the answerer can't keep A in the BUNDLE group, because it is will send media from a different physical device? The answerer would still like to keep everything else in the BUNDLE group, though.

Couldn't the offerer just not use "a=bundle-only", then?

[cdh4u]

If the answerer rejects A, then it could use the address from A for the BUNDLE group (if we were to specify how that works). Whereas if it simply removes A from the group, it can't use A's address.

We previously decided that we are not going to use information (e.g., port) from a rejected m- line.

Couldn't the offerer just not use "a=bundle-only", then?

Sure, but how would the offerer know? The offerer has no clue about the capabilities of the answerer.

[taylor-b]

We previously decided that we are not going to use information (e.g., port) from a rejected m- line.

I don't think that's correct. See: https://mailarchive.ietf.org/arch/msg/mmusic/X3zQdntEuD0J-FfWFBYJ02973bQ

Sure, but how would the offerer know? The offerer has no clue about the capabilities of the answerer.

Ok, let's take a step back then; how would you propose solving this issue? How can I create an offer that requires bundling some media descriptions, but not all of them?

[cdh4u]

In general, there are limitations that we have to live with. Having a dedicated m- line for the whole bundle group would have solved many issues (and created some others), but this is the way the community decided. Rejecting an m- line, but still using some properties (candidates in Ekr's example) from that m- line, while using other properties from the m- line actually accepted, is going to be very messy. There will be cases where the offerer needs to send a second offer.

Regarding your question, I think the example you gave shows how to create an offer the requires bundling some media descriptions, but not all of them. However, the answerer must keep at least one of the "fallback" m- lines in the bundle group.

[taylor-b]

However, the answerer must keep at least one of the "fallback" m- lines in the bundle group.

So, I guess the decision was already made, and this problem isn't worth solving? Fair enough.

[cdh4u]

The mindset has been "Make sure the m- line with the actual port is one that the answerer is very unlikely to reject."

Perhaps someone could define some kind of "dummy" m- line, which won't be used for any actual media, but only to exchange properties associated with the media (candidates, ports etc). However, I think that should be done as a separate task.

[taylor-b]

The mindset has been "Make sure the m- line with the actual port is one that the answerer is very unlikely to reject."

Ah; I assumed the selection of the offerer BUNDLE-tag was arbitrary.

It would be helpful if this recommendation ("choose an offerer BUNDLE-tag that you believe the answerer won't reject") were stated explicitly, somewhere in Section 8.2.

[cdh4u]

There will be text recommending this in version -44.