Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE: Semantics of same port in multiple m- lines

[Christer Holmberg <[e-mail]>]

Hi,

>>>>>>> One other thing I would like to point out, that if you are dealing with an end-point that does not support BUNDLE, for the m= lines where the port is set to zero, you would often get something that will copy
>>>>>>> all the RTP attributes to the answer from the offer, including the a=bundle-only attribute. Of course, you should not get the session-wide "a=group:BUNDLE" and would be able to detect that the m= line was
>>>>>>> rejected that way.
>>>>>>>
>>>>>>> If the remote endpoint does not support the grouping framework, your actual mileage with the "a=group:BUNDLE" line may wary. There was never an explicit requirement that unsupported attributes must not be copied
>>>>>>> from the offer to the answer. RFC 4566 and RFC 8866 only say that the parser must ignore such attributes. Because of this, some endpoints will copy all unknown attributes to the answer, including a=group. Of course, anything
>>>>>>> that supports RFC 5888 will not do this.
>>>>>>
>>>>>> Correct.
>>>>>>
>>>>>> However, endpoints copying SDP attributes they don't understand can in general cause all kind of issues. It is not a problem unique to the grouping framework, or to  BUNDLE, or to m- lines with port zero.
>>>>>>
>>>>>> But, at least there is standardized semantics of the meaning of port zero.
>>>>>
>>>>> Does the BUNDLE doc talk about what to do in this case, I.e., use of bundle-only in m= sections that are not part of an a=group:BUNDLE group? I think this is mostly separate from the issue at hand, but this seems like something endpoints should be robust against.
>>>>
>>>>bundle-only outside a bundle group is unspecified.
>>>>
>>>>   "The usage of the 'bundle-only' attribute is only defined for a
>>>>   bundled "m=" section with a zero port value.  Other usage is
>>>>   unspecified."
>>>>
>>>> (Section 6 of BUNDLE)
>>>
>>> Thank you for finding that section. If bundle-unaware entities do in fact copy attributes to the offer, I think it would be useful to amend this text to say that a=bundle-only must be ignored for any sections that are not in a bundle group, so
>>> that these sections can be properly rejected.
>>
>>Sure, we could have done that. However, as has been discussed that in the past (in MMUSIC, SIPCORE etc), we typically don't describe situations that can occur when endpoints behave strangely, because it would easily become a slippery slope. 
>> Also note that, in addition to bundle-only there can also be other attributes that have been copy/pasted by the remote endpoint.
>
> This is not "endpoints behaving strangely". This is the expected behavior of an endpoint that does not support bundle.

I don't think copy/pasting attributes you don't understand is expected behavior. That in general can cause lots of problems.

But, I do buy the argument that some endpoints do that, and that it is not (as far as I remember) explicitly forbidden.

>> Having said that, section 7.4 does say:
>>
>>   "If the answer does not contain a BUNDLE group, the offerer MUST
>>   process the answer as a normal answer."
>>
>> So, that means that a port zero indicates a disabled m- line, no matter if the m- line contains a bundle-only attribute or not.
>
>I think this section should take care of this specific issue (i.e. ignore bundle-only if session-level BUNDLE group is absent). Providing an example of interaction with a legacy endpoint or spelling this out might help.

It could be more explicit, but I think the text above takes care of it. If the m- line is not listed in the SDP group attribute, it is not part of the bundle group. 

Regards,

Christer