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.
>
> No, these applications are not under our control and may never update (unless there is an extremely clear benefit to doing so).

I think being able to communicate with a remote non-JSEP endpoint that uses port zero + bundle-only would be beneficial, but I guess it would be up to the application vendors to decide whether they see the same benefit or not... Maybe some application vendors do not see the benefit, if their applications are only supposed to work with JSEP-enabled browsers to begin with.

>>>> 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.
>
> We're getting data now on how often max-bundle is used even with this limitation. 
>
>> 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.
> Yes. I had suggested that, and still think that could be a path forward. But we should first see what the aforementioned data says to understand the extent of the need for such a policy.

The limitation could be one reason why people don't use it... Maybe people would like to use it, but they know that it may cause problems with non-JSEP peers.

So, I think the port zero + bundle-only procedures should remain in JSEP - under a new JSEP policy if needed.

As I have said in the off-list discussions, 3GPP has also defined procedures based on receiving offers with port zero + bundle-only, and there are deployments based on those procedures.

Regards,

Christer