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

[Justin Uberti <[e-mail]>]

On Thu, Jan 28, 2021 at 3:20 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).
>
> 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.


Could be. If max-bundle usage is low, that would be evidence in favor of
this position.