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

[Roman Shpount <[e-mail]>]

On Sun, Jan 31, 2021 at 1:04 PM Christer Holmberg <
[e-mail]> wrote:

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

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.
_____________
Roman Shpount