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

[Christer Holmberg <[e-mail]>]

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.

Regards,

Christer



 
 
 
 
On Thu, Jan 28, 2021 at 4:26 AM Christer Holmberg <mailto:[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 <mailto:[e-mail]> On Behalf Of Christer Holmberg
Sent: torstai 28. tammikuuta 2021 1.26
To: Roman Shpount <mailto:[e-mail]>
Cc: Magnus Westerlund <magnus.westerlund=mailto:[e-mail]>; mailto:[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