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

[Christer Holmberg <[e-mail]>]

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

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

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