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

[Justin Uberti <[e-mail]>]

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

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