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

[Justin Uberti <[e-mail]>]

On Wed, Jan 27, 2021 at 11:28 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> ...
>
> >>>I think we need to split the problem into three parts:
> >>>a) what should JSEP endpoints put into initial offers, when in
> max-bundle mode?
> >>>b) what should JSEP endpoints put into initial offers, when in balanced
> mode?
> >>
> >> Whatever JSEP says they should. There is no specification bug or
> specification misalignment etc that would require us to change that.
> >
> > The current charter text points out the issue here, and I think it's
> important that that text be maintained. As I've said, we need to take into
> account what existing applications expect, or else we have specs that can't
> be implemented.
>
> So, every time libwebrtc decides to change their non-compliant behavior,
> without even consulting IETF about it, IETF should update and align their
> specs? I don't think that is how IETF works.
>
> The fact is that libwebrtc has chosen, for whatever reason, to implement
> non-compliant behavior. They were even aware of it, as a ticket regarding
> bundle-only support was raised at some point.
>

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.

>
> In this particular case, what makes things even worse is that the
> suggested solution (initial INVITE with same port in each m- line) is not
> backward compatible with SDP. We have even seen proof that is causes errors.
>
> We decided at day one that BUNDLE has to be backward compatible with
> "legacy" SDP equipment. If we want to change that, I think we are talking
> about a bis - it is not part of a specification alignment task.
>

I think it's quite a stretch that any updates to JSEP's *non-default*
bundle policies require a bis version of BUNDLE. I'm hoping that a) and b)
can be resolved almost entirely in JSEP.


>
> …
>
> >>>c) may actually be the most significant decisioni, since it changes the
> behavior for just about every existing app (i.e., offerers will now start
> getting zero ports in their answers, regardless of mode). So I think we
> really
> >>>just have to decide if there is a technical reason to prefer the BUNDLE
> behavior over the JSEP behavior, given the risks of such a change.
> >>
> >> As I have said in off-list discussions, I am not religious regarding
> how we fix the JSEP/BUNDLE misalignment issue. As it covers a case when
> BUNDLE has been negotiated, we don’t need to consider backward
> compatibility with non-JSEP/BUNDLE endpoints.
> >
> > We certainly have to consider backward compatibility with JSEP endpoints
> that don't expect to receive port zero in answers.
>
> Yes. What I meant was that when solving  the specification misalignment
> issue we don't have to consider endpoints that don't support JSEP and/or
> BUNDLE to begin with.
>
> > If there's not a strong argument in favor of this new behavior, the
> simplest path would be to revert BUNDLE to the v40 (same as JSEP) behavior.
>
> It would be nice to get input from a few more people - especially from
> those that don't use libwebrtc in the implementations.
>
> If people don't care, at least indicate that :)
>
> Regards,
>
> Christer
>