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

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jan 2021 09:26:20 +0000

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 <[email-masked]> On Behalf Of Christer Holmberg
Sent: torstai 28. tammikuuta 2021 1.26
To: Roman Shpount <[email-masked]>
Cc: Magnus Westerlund <magnus.westerlund=[email-masked]>; [email-masked]
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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 29 Jan 2021 00:44:30 -0500

Chirster,

This is exactly the language I have remembered. So, it is not explicitly
prohibited but the behavior is undefined.
_____________
Roman Shpount

On Thu, Jan 28, 2021 at 4:26 AM Christer Holmberg <
[email-masked]> wrote:

> 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 <[email-masked]> *On Behalf Of *Christer Holmberg
> *Sent:* torstai 28. tammikuuta 2021 1.26
> *To:* Roman Shpount <[email-masked]>
> *Cc:* Magnus Westerlund <magnus.westerlund=[email-masked]>;
> [email-masked]
> *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?
>
>
>
> 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
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 Jan 2021 18:16:02 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:
This is the test from Section 5.14 of RFC 4566:

(RFC 8843 is BUNDLE)

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> On Behalf Of Christer Holmberg
Sent: torstai 28. tammikuuta 2021 1.26
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: Magnus Westerlund <magnus.westerlund=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Sat, 30 Jan 2021 00:11:42 -0500

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 <
[email-masked]> 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
>
>
>
>
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 30 Jan 2021 11:03:34 +0000

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

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:[email-masked]> wrote:
This is the test from Section 5.14 of RFC 4566:

 
 
(RFC 8843 is BUNDLE)

 
Regards,
 
Christer

From: mmusic <mailto:[email-masked]> On Behalf Of Christer Holmberg
Sent: torstai 28. tammikuuta 2021 1.26
To: Roman Shpount <mailto:[email-masked]>
Cc: Magnus Westerlund <magnus.westerlund=mailto:[email-masked]>; mailto:[email-masked]
Subject: Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE
 
Hi,

 

Regards,
 
Christer

---

From: Justin Uberti <[email-masked]>
Date: Sat, 30 Jan 2021 10:33:28 -0800

On Sat, Jan 30, 2021 at 3:03 AM Christer Holmberg <christer.holmberg=
[email-masked]> 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
> 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.
>

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.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 30 Jan 2021 19:21:15 +0000

Hi,

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

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Sat, 30 Jan 2021 14:31:11 -0800

On Sat, Jan 30, 2021 at 11:21 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> 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

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.

---

From: Roman Shpount <[email-masked]>
Date: Sun, 31 Jan 2021 00:19:54 -0500

> a bundle group, so that these sections can be properly rejected.

Copying the entire m= line from an offer and setting the port to zero was
traditionally a "safe" way to refuse the m= line section which the endpoint
does not understand.

If you want, I can check how various carriers/SBC/phones respond to an
offer with bundle-only m= line and port zero.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Sun, 31 Jan 2021 09:34:00 -0800

> offer with bundle-only m= line and port zero.

No need to go too deep here, but getting a basic understanding of how these
devices react would be useful.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 31 Jan 2021 18:04:49 +0000

Hi,

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

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.

The GOOD thing is that, in this case, an endpoint can detect the error just by looking at the SDP, assuming there session-level group attribute is missing. There are cases where the SDP may look fine, and the problems don't show up until you start sending some traffic.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 1 Feb 2021 00:30:46 -0500

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

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