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

[Justin Uberti <[e-mail]>]

On Sat, Jan 30, 2021 at 3:03 AM Christer Holmberg <christer.holmberg=
[e-mail]> wrote:

> Hi Roman,
>
> >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.