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

[Justin Uberti <[e-mail]>]

On Wed, Jan 27, 2021 at 1:54 PM 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.
>
> If port zero caused problems already 6 years ago, I'm just wondering why
> the issue wasn't brought to IETF.
>

Those details are lost to the ages, but most likely we simply meant to do
it, and then when nobody asked for it to be fixed, it never happened.

>
> >> 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.
>
> So, to make sure I understand: we would define a new
> same-port-in-initial-offer policy in JSEP, but the
> same-port-in-initial-offer case would not be defined in BUNDLE?
>

Something like that. Or we could just have a sentence in BUNDLE saying that
same-port is allowed if the offerrer has some a priori knowledge of the
remote endpoint, as would be indicated by use of said JSEP policy.