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

[Roman Shpount <[e-mail]>]

Hi Christer,

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


On Fri, Jan 29, 2021 at 1:16 PM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
>
> > This is exactly the language I have remembered. So, it is not
> explicitly prohibited but the behavior is undefined.
>
>
>
> ...which is why you cannot make any assumptions regarding how the receiver
> will process such SDP - unless you have prior knowledge about the
> capabilities of the receiver.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
> On Thu, Jan 28, 2021 at 4:26 AM Christer Holmberg <
> [e-mail]> wrote:
>
> This is the test from Section 5.14 of RFC 4566:
>
>
>
>       “The semantics of multiple "m=" lines using the same transport
>
>       address are undefined.  This implies that, unlike limited past
>
>       practice, there is no implicit grouping defined by such means and
>
>       an explicit grouping framework (for example, [18]) should instead
>
>       be used to express the intended semantics.”
>
>
>
> ([18] refers to the SDP grouping framework defined in RFC 5888)
>
>
>
>
>
> This is the corresponding (slightly modified) text from Section 5.12 of
> RFC 8866:
>
>
>
>      “This document gives no meaning to assigning the same media address
>
>       to multiple media descriptions.  Doing so does not implicitly
>
>       group those media descriptions in any way.  An explicit grouping
>
>       framework (for example, [RFC5888]) should instead be used to
>
>       express the intended semantics.  For instance, see [RFC8843].”
>
>
>
> (RFC 8843 is BUNDLE)
>
>
>
>
>
> So, again, it is ok to use the same port in multiple m- lines, if the
> semantics is defined, and if the participants support that semantics.
>
>
>
> When you send an initial INVITE, from a standards viewpoint, you don’t
> know whether the participants in the path support that semantics.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* mmusic <[e-mail]> *On Behalf Of *Christer Holmberg
> *Sent:* torstai 28. tammikuuta 2021 1.26
> *To:* Roman Shpount <[e-mail]>
> *Cc:* Magnus Westerlund <magnus.westerlund=[e-mail]>rg>;
> [e-mail]
> *Subject:* Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE
>
>
>
> Hi,
>
>
>
> >Can you or anyone else provide the reference to the document which
> prohibits using the same port in multiple m= lines?
>
>
>
> It is not prohibited, but the SDP spec says that the semantics is
> undefined.
>
>
>
> Now, in BUNDLE we can define semantics for usage of multiple m= lines, and
> BUNDLE endpoints would support that semantics.
>
>
>
> The problem is if you send an initial INVITE that reaches a non-BUNDLE
> endpoint. There is no way to know how that endpoint will process the offer,
> and we have seen that the offer gets rejected (in different ways).
>
>
>
> Regards,
>
>
>
> Christer
>
>