Can't reject the offerer BUNDLE-tag "m=" section when using a=bundle-only

[taylor-b]

In the mailing list, we've established that this should be allowed:

OFFER:

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

ANSWER (rejects A, keeps B and C):

a=group:BUNDLE B C
m=video 0
a=mid:A
m=video 2000
a=mid:B
m=video 2000
a=mid:C

But this isn't currently allowed by the specification, given how "Answerer Selection of Offerer Bundle Address" is written.

[cdh4u]

The above example is not allowed. I think (needs to be verified) the spec also says that the answerer must accept at least one m- line with a non-zero port.

[taylor-b]

I realize it's not allowed by the spec as currently written, but I was pretty confident we agreed this should work on the mailing list. I'm having trouble finding the exact email (the closest I could find is this).

But regardless, if the above example is not supported, I'd consider that a notable issue with the spec. Efficient implementations will want to use "bundle-only", in order to avoid allocating extra resources, and they also would want to allow for any "m=" section to be rejected without preventing the BUNDLE group from being formed.

[cdh4u]

"But regardless, if the above example is not supported, I'd consider that a notable issue with the spec. Efficient implementations will want to use "bundle-only", in order to avoid allocating extra resources, and they also would want to allow for any "m=" section to be rejected without preventing the BUNDLE group from being formed."

Well, again, this is what we got by choosing the approach we did. Having a dedicated "bundle m- line" would have solved this, as the port of that m- line would not have been bound to a specific media stream, but to the whole bundle group.

Note, the following is not a suggestion, but more brainstorming:

One option would be to allow sending "bundle-only" with non-zero ports.

The pro is that the answerer could reject any m- line, and still form the bundle group, because there is a port that can be used.

The con is that an answerer that does not support BUNDLE (read: bundle-only attribute) could accept all m- lines in a legacy manner.

[taylor-b]

Well, again, this is what we got by choosing the approach we did.

I don't see why this is incompatible with the approach chosen. If we already allow matching TRANSPORT/IDENTICAL attributes between different m= sections in the offer and answer, doing the same for ports shouldn't be a problem.

But if, like you said on #21, the mindset is "Make sure the m- line with the actual port is one that the answerer is very unlikely to reject," then maybe this issue is also not worth solving.

[cdh4u]

I will close this issue. If you still think this issue should be solved (personally I'd like to accept the current assumption/mindset/limitation, and not do anything), please raise it on the list.