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

[Justin Uberti <[e-mail]>]

On Thu, Jan 28, 2021 at 1:18 PM Christer Holmberg <
[e-mail]> wrote:

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

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