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?

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?

Regards,

Christer