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

[Christer Holmberg <[e-mail]>]

Hi,

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