Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE

[Christer Holmberg <[e-mail]>]

Hi,

...

>>>>>>> Look, I am as unhappy as anyone else that we have this issue to deal with. But this isn't an issue about what libwebrtc did or didn't do; this is an observation on the state of the WebRTC ecosystem in 2021. libwebrtc was unable to implement the standard
>>>>>>> behavior 6 years ago because of application (not in libwebrtc!) incompatibilities when receiving port zero, and those incompatibilities have likely only multiplied over time. Ergo, we have to consider this situation as part of the problem space and resultant document update.
>>>>>>
>>>>>> So, what exactly were the issues with receiving port zero?
>>>>>
>>>>> The same as now - existing applications would suddenly treat this as a disabled m= section, when it previously worked fine.
>>>>>
>>>>> What do you mean by "previously"?
>>>>>
>>>>> Just to make sure I understand: if the application receives port zero + bundle-only, why does it treat is as a disabled m= section? Why doesn't it check the bundle-only attribute? I am just trying to understand what causes the problem...
>>>
>>> Because applications exist that understand BUNDLE, but not port-zero with a=bundle-only. So if one were to suddenly change the behavior of clients to start using a=bundle-only, those applications would interpret these m= sections as disabled. This is what I have been trying to say all along.
>>
>> But, what if such application receives an offer with port-zero and a=bundle-only, e.g., from a non-JSEP offerer?
>
> It will malfunction as described, if it supports non-JSEP offers at all. 

Can support be added? Because, eventhough it does not work today, it would work tomorrow.

>> And, as I asked in another reply, what would the JSEP max-bundle behavior be if the JSEP offerer does NOT have knowledge about the answerer?
> 
> Then you don't use max-bundle.

The main advantage of max-bundle is that you only have to reserve a single port (and ICE candidates etc associated with that). I think it is very restrictive if you can only use it when you KNOW that the other endpoint uses JSEP.

If I remember correctly, there was a suggestion to keep the existing port zero + bundle-only procedure in JSEP, but define a NEW policy for it. Then, once the new policy gets implemented, it can be used.

Regards,

Christer