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

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Feb 2021 08:15:39 +0000

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

I don't think copy/pasting attributes you don't understand is expected behavior. That in general can cause lots of problems.

But, I do buy the argument that some endpoints do that, and that it is not (as far as I remember) explicitly forbidden.

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

It could be more explicit, but I think the text above takes care of it. If the m- line is not listed in the SDP group attribute, it is not part of the bundle group. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 1 Feb 2021 11:47:28 -0500

> But, I do buy the argument that some endpoints do that, and that it is not (as far as I remember) explicitly forbidden.

Shooting yourself in the head isn't AFAIK explicitly forbidden. But 
unless you understand and desire the consequences it is generally an 
unwise thing to do.

I don't think an IETF document is obligated to protect against people 
doing either.

Also, if we have an implementation that doesn't support bundle that is 
copying an a=bundle-only it doesn't understand, won't it also likely be 
copying a=group:bundle and a=mid???

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Feb 2021 17:27:16 +0000

Hi,

> Shooting yourself in the head isn't AFAIK explicitly forbidden. But unless you understand and desire the consequences it is generally an unwise thing to do.
>
> I don't think an IETF document is obligated to protect against people doing either.
>
> Also, if we have an implementation that doesn't support bundle that is copying an a=bundle-only it doesn't understand, won't it also likely be copying a=group:bundle and a=mid???

My understanding was that it only affected media-level attributes.

But, sure, in theory an endpoint could copy ANYTHING it doesn't understand...

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 1 Feb 2021 12:43:16 -0500

On Mon, Feb 1, 2021 at 12:27 PM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> >>>> 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.
> >>
> >> I don't think copy/pasting attributes you don't understand is expected
> behavior. That in general can cause lots of problems.
> >>
> >> But, I do buy the argument that some endpoints do that, and that it is
> not (as far as I remember) explicitly forbidden.
> >
> unless you understand and desire the consequences it is generally an unwise
> thing to do.
> >

The issue is how does an endpoint generate an m= line to refuse something
that the endpoint does not understand. For instance, the endpoint gets an
application webrtc-datachannel m= line but has no idea what any of the SDP
attributes mean and which ones are required to form a valid m= line. The
simplest way is to refuse such an m= line was to copy the entire m= line in
the answer and set the m= line port to 0. As far as the endpoint is
concerned, there is no difference between a=sctp-port or a=bundle-only, if
neither are supported.

If this is an invalid procedure to refuse an m= line, please point out
where it says this is invalid and let me know where the correct procedure
is described.

Session level attributes are different since this is something that is
negotiated, it would be logical not to include them if the endpoint does
not support them.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Feb 2021 18:52:00 +0000

Hi,

> The issue is how does an endpoint generate an m= line to refuse something that the endpoint does not understand. For instance, the endpoint gets an application webrtc-datachannel m= line but has no idea what any of the SDP attributes mean and which ones are required to form a valid m= line. 
> The simplest way is to refuse such an m= line was to copy the entire m= line in the answer and set the m= line port to 0.
>
> As far as the endpoint is concerned, there is no difference between a=sctp-port or a=bundle-only, if neither are supported.
>
> If this is an invalid procedure to refuse an m= line, please point out where it says this is invalid and let me know where the correct procedure is described.

In my opinion the correct procedure is to set the m= line port to 0 - nothing more, nothing less :)

But, as I said earlier, I don't think it is explicitly forbidden to copy/paste unsupported attributes.

However, Section 6 of RFC 3264 does say:

   "An offered stream MAY be rejected in the answer, for any reason.  If
   a stream is rejected, the offerer and answerer MUST NOT generate
   media (or RTCP packets) for that stream.  To reject an offered
   stream, the port number in the corresponding stream in the answer
   MUST be set to zero."

There is nothing in the text about inserting attributes.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 1 Feb 2021 18:26:12 -0500

On 2/1/21 12:43 PM, Roman Shpount wrote:
> On Mon, Feb 1, 2021 at 12:27 PM Christer Holmberg 
> <christer.holmberg=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      >>>> 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.
>      >>
>      >> I don't think copy/pasting attributes you don't understand is
>     expected behavior. That in general can cause lots of problems.
>      >>
>      >> But, I do buy the argument that some endpoints do that, and that
>     it is not (as far as I remember) explicitly forbidden.
>      >
>      > Shooting yourself in the head isn't AFAIK explicitly forbidden.
>     But unless you understand and desire the consequences it is
>     generally an unwise thing to do.
>      >
>      > Also, if we have an implementation that doesn't support bundle
>     that is copying an a=bundle-only it doesn't understand, won't it
>     also likely be copying a=group:bundle and a=mid???
> 
> The issue is how does an endpoint generate an m= line to refuse 
> something that the endpoint does not understand. For instance, the 
> endpoint gets an application webrtc-datachannel m= line but has no idea 
> what any of the SDP attributes mean and which ones are required to form 
> a valid m= line. The simplest way is to refuse such an m= line was to 
> copy the entire m= line in the answer and set the m= line port to 0. As 
> far as the endpoint is concerned, there is no difference between 
> a=sctp-port or a=bundle-only, if neither are supported.
> 
> where it says this is invalid and let me know where the correct 
> procedure is described.

I will grant you that the guidance on what do do in this situation is 
lacking.

BUT, it cannot be assumed that attributes are symmetric in their use in 
offers and answers. While that is true of some, it is definitely not 
true of others. So it is unreasonable to assume you should copy 
un-understood attributes from offer to answer. The only thing it is 
reasonably safe to do is what Christer says.

> negotiated, it would be logical not to include them if the endpoint does 

I don't see it as much different. In both cases, your answer should only 
contain stuff you understand and support. The only exception is for 
m-lines themselves, where you can copy the rejected m-line except for 
replacing the port with zero.

Perhaps we should have instead specified a placeholder <media>, <proto>, 
and <fmt> to use in rejected m-lines. But that is water over the dam.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 1 Feb 2021 22:38:35 -0500

> reasonably safe to do is what Christer says.

What does Christer say, exactly? Copy just an m= line from the offer and
set the port to zero, or copy the entire m= section with attributes from
the offer and set the port to zero?

RFC 3264 Section 6 Says:
An offered stream MAY be rejected in the answer for any reason.  If a
stream is rejected, the offerer and answerer MUST NOT generate media (or
RTCP packets) for that stream.  To reject an offered stream, the port
number in the corresponding stream in the answer MUST be set to zero.  Any
media formats listed are ignored.  At least one MUST be present, as
specified by SDP.

So, it implies that an m= line must be valid and include at least one media
format. What if all the payloads are dynamic? Should it include the
corresponding a=rtpmap attribute? What if this payload format requires
other attributes to be valid? What if the m= line refers to an application
type stream and the receiving endpoint does not support it and does not
know how to generate the valid m= line or section in response. What should
be done then? What if this is an m= line with an unknown proto? In this
case, media formats are just a list of unspecified tokens.

> replacing the port with zero.

As I have mentioned earlier, an m= line might not be valid without the
corresponding attributes. Since these attributes per RFC 3264 MUST be
ignored if the m= line port is zero, they were often included. BUNDLE RFC
changes this, so it should specify what happens in this case, which used to
be legal before.

> and <fmt> to use in rejected m-lines. But that is water over the dam.

We should have just specified that none of the fmt or attributes MUST be
included, but this is, indeed, water under the dam.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Feb 2021 09:59:40 +0000

Hi,

...
 
>> I will grant you that the guidance on what do do in this situation is lacking.
>>
> What does Christer say, exactly? Copy just an m= line from the offer and set the port to zero, or copy the entire m= section with attributes from the offer and set the port to zero?

Christer says copy just the m= line and set the port to zero.

> RFC 3264 Section 6 Says:
>
> An offered stream MAY be rejected in the answer for any reason.  If a stream is rejected, the offerer and answerer MUST NOT generate media (or RTCP packets) for that stream.  To reject an
> offered stream, the port number in the corresponding stream in the answer MUST be set to zero.  Any media formats listed are ignored.  At least one MUST be present, as specified by SDP.
>
> So, it implies that an m= line must be valid and include at least one media format.
> What if all the payloads are dynamic? Should it include the corresponding a=rtpmap attribute? What if this payload format requires other attributes to be valid?
>
> What if the m= line refers to an application type stream and the receiving endpoint does not support it and does not know how to generate the valid m= line or section in response. What should be done then?
> What if this is an m= line with an unknown proto? In this case, media formats are just a list of unspecified tokens.

The only reason one media format is needed is because it is required by the ABNF. It doesn't really mean anything, as the m- line is rejected.

Yes, that could probably have been clarified too.

> As I have mentioned earlier, an m= line might not be valid without the corresponding attributes. Since these attributes per RFC 3264 MUST be ignored if the m= line port is zero,
> they were often included.
>
> BUNDLE RFC changes this, so it should specify what happens in this case, which used to be legal before.

BUNDLE says that bundle-only does not have any semantics if it's not part of a bundle group. So, unless the answerer also copies the group:bundle attribute, the m- line will not be part of a bundle group.

>We should have just specified that none of the fmt or attributes MUST be included, but this is, indeed, water under the dam.

We did discuss the fmt. But, again, it's there for backward compatibility, as the ABNF requires it.

Regards,

Christer