Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle

[Christer Holmberg <[e-mail]>]

Hi,

>> Assume the following case:
>>
>> 1.An SDP offer contains an m- line associated with a BUNDLE group
>>
>> 2.The answerer wants to accept the m- line, but wants to reject it being
>> in the specific BUNDLE group.
>>
>> A few alternatives on how this could be achieved have been presented:
>>
>> Alt 1.      The answerer accepts the m- line, but does not associate it
>> with a BUNDLE group.
>>
>> Alt 2.      The answerer accepts the m- line, associates it with a
>> BUNDLE group, and then sends a new offer which removes the m- line from
>> the BUNDLE group.
>>
>> Alt 3.      The answerer rejects the m- line, and then sends a new offer
>> which adds the m- line outside a BUNDLE group.
>>
>> In my opinion, Alt 1 does not work, at least not if the offer contains
>> identical port values for the m- lines associated with the BUNDLE group.
>> It would mean that the m- line is not added to a BUNDLE group, but still
>> has the same port value (at least at the offerer side) as the m- lines
>> in the BUNDLE group, which is not allowed.
>>
>> So, my suggestion would be to specify that the answerer must use Alt 2
>> and/or Alt 3.
>
> I don't think we should restrict flexibility here when it works and
> makes sense.
>
> I agree that Alt 1 doesn't work *if* the m-line in question shares
> addr/prot with other m-lines that are also accepted, bundled or not. But
> the normal first offer won't present that situation. If the addr/port in
> the m-line in question is unique among all the accepted m-lines, then
> this should be acceptable.
>
> (Note, this is a degenerate case of bundle splitting. There are real use
> cases for it. If it can be done without a 2nd o/a, then lets allow that.)

I was thinking that, by not allowing it, we could have a general rule saying something like:

"If an m- line in an offer is associated with a BUNDLE group, it MUST be associated with a BUNDLE group in the associated answer, unless the answerer sets the port value to zero."

Regards,

Christer