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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Jan 2021 16:50:56 +0000

Hi,

I am cross posting this to MMUSIC as BUNDLE was a MMUSIC document, and this
issue has to my understanding still not been conveyed to the MMUSIC WG
partipants. 

First, I am a bit concerned that this is done in a RTCWeb WG without any
requirement on interaction with MMUSIC. BUNDLE is a general SDP O/A mechanism
and not specific to RTCWebs usage in JSEP. Thus, I am worried about that changes
are applied to BUNDLE that works fine for JSEP, but affect the interoperability
with general case SDP O/A usages. 

Secondly, the citiation below includes the following: "... and existing browser
implementations." I think that gives an impression that RTCWeb browser 
implementations can be used trump over general SDP O/A interoperability and also other implementation, even of WebRTC, that this alignment fix could potentially impact. 

Thus, I would prefer a different wording than referring to a statement that was
intended to be informative that there exists an issue. I would notet that the
statement was quickly written, that a limited set of people had any chance to
see prior to its publication. 

In addition I think the scope can be narrowed even further than to just the
Bundle-only part of BUNDLE and JSEP, to only the aspect that is missaligned.

Cheers

Magnus Westerlund

On Fri, 2021-01-22 at 17:35 -0800, Murray S. Kucherawy wrote:
> Colleagues,
> 
> In the final run-up to publication of C238, it was observed that the JSEP and
> BUNDLE documents contradict each other in a significant way.
> 
> Rather than send them back to the working group to resolve, delaying
> publication further for an unknown duration, the authors and Area Directors
> involved reached consensus to publish the entire cluster as it was originally
> approved, with a note added that acknowledges the contradiction (without
> proposing solutions), and stating that the IETF will quickly take up the work
> to publish updates.  The specific text is visible as Section 1.3 of RFC 8829
> and 1.4 of RFC 8843.
> 
> The IESG intends to reconstitute the RTCWEB working group to resolve this
> contradiction, with a scope to resolve only that specific issue and publish a
> couple of document updates.  The plan is to have this rechartering in place in
> time for a meeting at IETF 110 in March.
> 
> Below is the proposed re-chartering for the RTCWEB working group.  Feedback on
> this is welcome, either on the [email-masked] list, to me privately, or to
> the IESG.  We will start the formal process of review and approval on the next
> IESG telechat, and have already requested a session during IETF 110 to get the
> work going.
> 
> -MSK, ART AD 
> 
> --
> 
> The RTCWEB working group was originally chartered to standardize mechanisms
> that provide direct interactive rich communication using audio, video,
> collaboration, games, etc. between two peers' web-browsers, without requiring
> non-standard extensions or proprietary plug-ins.  The result was a set of RFCs
> from RTCWEB, in addition to many other RFCs from other working groups, all of
> which are interrelated and had to be published together in what the RFC Editor
> refers to as a “cluster”.  In the end, that cluster comprised more than 40
> RFCs and was finally published in January 2021.
> 
> During the run-up to publication of the cluster, a contradiction was
> identified between what became RFCs 8829 and 8843.  A description of this
> contradiction was added to both documents to highlight the problem, and state
> our intention to proceed with publication but quickly initiate an effort to
> publish updates to the affected documents.
> 
> The key part of the added text was as follows:
> 
> “The specific issue involves the handling of "m=" sections that are designated
> as bundle-only, as discussed in Section 4.1.1 of [RFC 8829].  Currently, there
> is divergence between JSEP and BUNDLE, as well as between these specifications
> and existing browser implementations …”
> 
> The working group is being reconstituted to take up this contradiction, come
> to consensus on a resolution, and issue Standards Track updates for those two
> documents.  Updating any other document, or taking up any other issue, is out
> of scope and will require IESG approval via rechartering.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 26 Jan 2021 10:07:00 +0100

Magnus:

1) IETF is most successful when it creates fora that are focused on 
delivering a product. Using long-lived, generic review mechanisms such 
as MMUSIC has a long history of failure; in particular, this particular 
BUNDLE change was done in MMUSIC without making RTCWEB aware of the 
introduced incompatibility, showing that MMUSIC failed to achieve IETF 
coordination on the issue, despite RTCWEB being the only significantly 
affected IETF WG, and the fact that RTCWEB was the cause of the BUNDLE 
work being started at all.

2) Anyone from MMUSIC is welcome to be part of the RTCWEB discussion on 
the subject. That's how cooperation between IETF WGs is supposed to be 
achieved: By cross-participation.

The solution to this problem needs IETF (rough) consensus. This includes 
the participants of MMUSIC, but does not, and should not, as far as I 
can tell, require that the particular subgroup of the IETF that 
self-identifies as "MMUSIC" have consensus on the issue.

I take my part of the blame (as listed co-author on BUNDLE) for not 
reviewing the change properly and realizing the JSEP impact of the 
change. But you certainly cannot argue that the history is a good 
argument that introducing a formal depenency on MMUSIC increases the 
chance of success for this particular endeavor.

(I have long argued that long-lived fora like MMUSIC should have the 
name of "WG" taken from them and explicitly be barred from taking on new 
work; these long-lived fora serve a very important purpose as 
institutional memory, but their success rate on involvement with new 
work is not something that impresses me.)

Harald

On 1/25/21 5:50 PM, Magnus Westerlund wrote:
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jan 2021 11:57:06 +0000

Hi Harald,

*FIRST*, in order to clarify for the community what the JSEP/BUNDLE misalignment is about, because it is not that clear in the text that was added to the specs: the misalignment is regarding the sending
of the *initial answer*, and *subsequent offers and answers*. BUNDLE says that in such offers and answers all bundled m- lines (except the tagged m- line) contain port zero and a bundle-only attribute.
JSEP says that in such offers and answers all bundled m- lines contain the negotiated bundle port.

*SECOND*, your ”RTCWEB was not made aware” claim is not true.

- Once the BUNDLE change had been done, RTCWEB was made aware that JSEP had to be updated: https://mailarchive.ietf.org/arch/msg/rtcweb/B38bsRBAzfpJmBOCpnNCxM0wDbc/
Unfortunately, that update was never done, and that wasn’t detected until recently.

- draft-ietf-rtcweb-sdp, which is a RTCWEB WG deliverable, *is* aligned with BUNDLE.

*THIRD*, I don’t understand your comments regarding the MMUSIC WG. Cross-participation goes both ways, MMUSIC was chartered to work on a number of documents needed by RTCWEB, anyone could participate in the work, and anyone following the mail discussions would have been aware of the change.

However, arguing about who should have done and known what is not going to solve the misalignment. The charter should be about fixing the BUNDLE/JSEP misalignment, and I haven’t seen anyone objecting to that.

Regards,

Christer

From: mmusic <[email-masked]> On Behalf Of Harald Alvestrand
Sent: tiistai 26. tammikuuta 2021 11.07
To: [email-masked]
Subject: Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE

Magnus:

1) IETF is most successful when it creates fora that are focused on delivering a product. Using long-lived, generic review mechanisms such as MMUSIC has a long history of failure; in particular, this particular BUNDLE change was done in MMUSIC without making RTCWEB aware of the introduced incompatibility, showing that MMUSIC failed to achieve IETF coordination on the issue, despite RTCWEB being the only significantly affected IETF WG, and the fact that RTCWEB was the cause of the BUNDLE work being started at all.

2) Anyone from MMUSIC is welcome to be part of the RTCWEB discussion on the subject. That's how cooperation between IETF WGs is supposed to be achieved: By cross-participation.

The solution to this problem needs IETF (rough) consensus. This includes the participants of MMUSIC, but does not, and should not, as far as I can tell, require that the particular subgroup of the IETF that self-identifies as "MMUSIC" have consensus on the issue.

I take my part of the blame (as listed co-author on BUNDLE) for not reviewing the change properly and realizing the JSEP impact of the change. But you certainly cannot argue that the history is a good argument that introducing a formal depenency on MMUSIC increases the chance of success for this particular endeavor.

(I have long argued that long-lived fora like MMUSIC should have the name of "WG" taken from them and explicitly be barred from taking on new work; these long-lived fora serve a very important purpose as institutional memory, but their success rate on involvement with new work is not something that impresses me.)

Harald

Hi,

partipants.

Cheers

Magnus Westerlund

Colleagues,

and 1.4 of RFC 8843.

this is welcome, either on the [email-masked]<mailto:[email-masked]> list, to me privately, or to

work going.

-MSK, ART AD

--

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 Jan 2021 15:18:50 +0000

Hi Harald,

Let me clarify. My first issue was about the process up to this point that no
one had taken the time to actually inform the participants on the MMUSIC WG
mailing that one specification developed by the WG had an issue in relation to
another one done in RTCWeb when in AUTH48. Independently of where that work
shold be done to fix this, I think there exists a need to inform people about
this plan. And when publishing that plan only to RTCWeb mailing list that got me
annoyed. 

Secondly, I can definitely live with the work being done in a revivied
specifically charted RTCWeb WG. However, SDP Offer/Answer is used in several
places for different usages. Something which was considred very much when
developing BUNDLE. Thus, I think it is relevant that RTCWeb will keep MMUSIC
informed about their work. So that RTCWeb doesn't end up missing an important
aspect of this, a run into issue when forming the IETF consensus needed to
publish this document. 

Cheers

Magnus Westerlund

On Tue, 2021-01-26 at 10:07 +0100, Harald Alvestrand wrote:
> Magnus:
> 1) IETF is most successful when it creates fora that are focused on delivering
> a product. Using long-lived, generic review mechanisms such as MMUSIC has a
> long history of failure; in particular, this particular BUNDLE change was done
> in MMUSIC without making RTCWEB aware of the introduced incompatibility,
> showing that MMUSIC failed to achieve IETF coordination on the issue, despite
> RTCWEB being the only significantly affected IETF WG, and the fact that RTCWEB
> was the cause of the BUNDLE work being started at all.
> 2) Anyone from MMUSIC is welcome to be part of the RTCWEB discussion on the
> subject. That's how cooperation between IETF WGs is supposed to be achieved:
> By cross-participation.
> The solution to this problem needs IETF (rough) consensus. This includes the
> participants of MMUSIC, but does not, and should not, as far as I can tell,
> require that the particular subgroup of the IETF that self-identifies as
> "MMUSIC" have consensus on the issue.
> I take my part of the blame (as listed co-author on BUNDLE) for not reviewing
> the change properly and realizing the JSEP impact of the change. But you
> certainly cannot argue that the history is a good argument that introducing a
> formal depenency on MMUSIC increases the chance of success for this particular
> endeavor.
> (I have long argued that long-lived fora like MMUSIC should have the name of
> "WG" taken from them and explicitly be barred from taking on new work; these
> long-lived fora serve a very important purpose as institutional memory, but
> their success rate on involvement with new work is not something that
> impresses me.)
> Harald
> > implementations can be used trump over general SDP O/A interoperability and
> > also other implementation, even of WebRTC, that this alignment fix could
> > potentially impact. 
> >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Jan 2021 08:08:36 -0800

> this plan. And when publishing that plan only to RTCWeb mailing list that

This was my fault.  The decision had only just been made to reconstitute
RTCWEB to take up this one issue, rather than doing it in MMUSIC (though
thank you to the MMUSIC chairs for being willing).  After we worked on the
new charter, I sent that message to RTCWEB.  I had meant to also send it to
MMUSIC, but instead packed up for the weekend before I did so.  Apologies
for the oversight.

> aspect of this, a run into issue when forming the IETF consensus needed to

I think the revised charter takes this into account.  Please let me know if
it needs any other corrections.

-MSK

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jan 2021 19:02:36 +0000

Hi,

...

> I think the revised charter takes this into account.  Please let me know if it needs any other corrections.

It needs to be clear that the charter is about fixing the misalignment between the BUNDLE and JSEP specifications - nothing more, nothing less.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Tue, 26 Jan 2021 11:16:34 -0800

On Tue, Jan 26, 2021 at 11:02 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> It needs to be clear that the charter is about fixing the misalignment
> between the BUNDLE and JSEP specifications - nothing more, nothing less.
>
>
As noted in the spec blurb, we also need to consider the existing
deployments and how any changes at this point may affect them. Specs that
implementors can't implement are not useful.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jan 2021 19:28:41 +0000

Hi,

...

> As noted in the spec blurb, we also need to consider the existing deployments and how any changes at this point may affect them. Specs that implementors can't implement are not useful. 

Absolutely. When we discuss how to solve the misalignment between the JSEP and BUNDLE specifications we need to take existing deployments into consideration.

But, any issue that is not related to the misalignment between the JSEP and BUNDLE specifications shall be outside the scope.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Tue, 26 Jan 2021 11:43:37 -0800

On Tue, Jan 26, 2021 at 11:28 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> Absolutely. When we discuss how to solve the misalignment between the JSEP
> and BUNDLE specifications we need to take existing deployments into
> consideration.
>
> But, any issue that is not related to the misalignment between the JSEP
> and BUNDLE specifications shall be outside the scope.
>
> Agreed that we want to keep this narrowly focused. I believe the existing
blurbs added to JSEP and BUNDLE outline the scope well, in that we are
trying to solve a specific problem, but the solution space for said problem
may need to consider options beyond what JSEP and BUNDLE currently specify.

On that topic: to understand the importance of the BUNDLE v41 change
regarding answers and subsequent offers, does anyone recall the technical
reasons behind this change?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jan 2021 19:50:43 +0000

Hi,

...

> Agreed that we want to keep this narrowly focused. I believe the existing blurbs added to JSEP and BUNDLE outline the scope well, in that we are trying to solve a specific problem, but the solution space for said
> problem may need to consider options beyond what JSEP and BUNDLE currently specify. 
>
> On that topic: to understand the importance of the BUNDLE v41 change regarding answers and subsequent offers, does anyone recall the technical reasons behind this change?

The change was suggested by Taylor:

https://mailarchive.ietf.org/arch/msg/mmusic/-jENmu4iaapy7NdJ9_SLHpNjSDc/

Based on that text, there doesn't seem to be a technical reason, but rather just a wish to not duplicate unnecessary information (the port number).

I know you have been trying to reach Taylor, so hopefully he can confirm whether there is a technical reason or not :)

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Tue, 26 Jan 2021 13:02:57 -0800

On Tue, Jan 26, 2021 at 11:50 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> >> Absolutely. When we discuss how to solve the misalignment between the
> JSEP and BUNDLE specifications we need to take existing deployments into
> consideration.
> >>
> > Agreed that we want to keep this narrowly focused. I believe the
> existing blurbs added to JSEP and BUNDLE outline the scope well, in that we
> are trying to solve a specific problem, but the solution space for said
> Based on that text, there doesn't seem to be a technical reason, but
> rather just a wish to not duplicate unnecessary information (the port
> number).
>
> I know you have been trying to reach Taylor, so hopefully he can confirm
> whether there is a technical reason or not :)
>
> I haven't heard from him yet, but my read of that thread is that the
change is entirely focused on cleaner syntax.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jan 2021 21:40:42 +0000

Hi,

...

> I haven't heard from him yet, but my read of that thread is that the change is entirely focused on cleaner syntax. 

So, assuming that is true, from a pure technical perspective I see 3 different options:

1) Keep the BUNDLE way
2) Keep the JSEP way
3) Allow both ways (at the end of the day, once the endpoints have negotiated usage of BUNDLE, only the port of the tagged m- line really matters).

Regards,

Christer

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 26 Jan 2021 14:51:32 -0800

> between the BUNDLE and JSEP specifications - nothing more, nothing less.

Do you think the current charter text needs to be adjusted?  If so, do you
have a suggestion?

-MSK

---

From: Roman Shpount <[email-masked]>
Date: Tue, 26 Jan 2021 18:04:15 -0500

I just like to note that the current implementation is not following either
JSEP or BUNDLE. At least one current implementation sends identical ports
in the initial offer, which is not compliant with either specification.
Switching to BUNDLE might not be backward compatible.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Tue, 26 Jan 2021 17:18:25 -0800

On Tue, Jan 26, 2021 at 3:04 PM Roman Shpount <[email-masked]> wrote:

> I just like to note that the current implementation is not following
> either JSEP or BUNDLE. At least one current implementation sends identical
> ports in the initial offer, which is not compliant with either
> specification. Switching to BUNDLE might not be backward compatible.
>
>
Right, which means that we have more possibilities to consider besides the
ones that Christer mentioned.

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?
c) what should all endpoints do in answers and re-offers (regardless of
mode)?

For a), we need to come up with something that doesn't break existing
applications that don't expect to get port zero. Since this is not the
default mode, I don't think we have to worry as much about the particulars
of offer-answer.

For b), given that most apps in this mode won't actually end up offering a
zero port, I think we have a lot of flexibility in what solution we choose
(i.e., the risk of app breakage may not be the dominant constraint).

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.

>> Do you think the current charter text needs to be adjusted?  If so, do
>> you have a suggestion?
>>
>> -MSK

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jan 2021 07:06:24 +0000

Hi,

The initial offer issue has nothing to do with the JSEP/BUNDLE misalignment issue. I don’t think they shall be bundled (no pun intended) together.

Regards,

Christer

From: Justin Uberti <[email-masked]>
Sent: keskiviikko 27. tammikuuta 2021 3.18
To: Roman Shpount <[email-masked]>
Cc: Murray S. Kucherawy <[email-masked]>; Magnus Westerlund <magnus.westerlund=[email-masked]>; [email-masked]; Christer Holmberg <[email-masked]>
Subject: Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE

On Tue, Jan 26, 2021 at 3:04 PM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
I just like to note that the current implementation is not following either JSEP or BUNDLE. At least one current implementation sends identical ports in the initial offer, which is not compliant with either specification. Switching to BUNDLE might not be backward compatible.

Right, which means that we have more possibilities to consider besides the ones that Christer mentioned.

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?
c) what should all endpoints do in answers and re-offers (regardless of mode)?

For a), we need to come up with something that doesn't break existing applications that don't expect to get port zero. Since this is not the default mode, I don't think we have to worry as much about the particulars of offer-answer.

For b), given that most apps in this mode won't actually end up offering a zero port, I think we have a lot of flexibility in what solution we choose (i.e., the risk of app breakage may not be the dominant constraint).

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.

On Tue, Jan 26, 2021 at 5:51 PM Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

Do you think the current charter text needs to be adjusted?  If so, do you have a suggestion?

-MSK

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jan 2021 09:19:29 +0000

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

>c) what should all endpoints do in answers and re-offers (regardless of mode)?

Correct. That is the question we need to answer in order to fix the specification misalignment.

…

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

Regards,

Christer

-MSK

---

From: Justin Uberti <[email-masked]>
Date: Wed, 27 Jan 2021 10:58:22 -0800

On Wed, Jan 27, 2021 at 1:19 AM Christer Holmberg <
[email-masked]> wrote:

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jan 2021 19:28:35 +0000

Hi,

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

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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 27 Jan 2021 15:12:04 -0500

On Wed, Jan 27, 2021 at 2:28 PM Christer Holmberg <
[email-masked]> wrote:

> It would be nice to get input from a few more people - especially from
> those that don't use libwebrtc in the implementations.
>
>
First of all, SDP processing is not technically part of libwebrtc. Firefox,
Chromium, and Safary have different code for that.

Second, our code already works with existing implementations (i.e.
identical ports for m= lines). Switching it to port 0 in Firefox caused
some breakage but it was fixed as well. So, at this point, we do not care.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 27 Jan 2021 12:21:44 -0800

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

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jan 2021 21:54:57 +0000

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.

If port zero caused problems already 6 years ago, I'm just wondering why the issue wasn't brought to IETF.

> 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?
 
Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 27 Jan 2021 18:08:27 -0500

Chirster,

Can you or anyone else provide the reference to the document which
prohibits using the same port in multiple m= lines?

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jan 2021 23:26:03 +0000

Hi,

>Can you or anyone else provide the reference to the document which prohibits using the same port in multiple m= lines?

It is not prohibited, but the SDP spec says that the semantics is undefined.

Now, in BUNDLE we can define semantics for usage of multiple m= lines, and BUNDLE endpoints would support that semantics.

The problem is if you send an initial INVITE that reaches a non-BUNDLE endpoint. There is no way to know how that endpoint will process the offer, and we have seen that the offer gets rejected (in different ways).

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Wed, 27 Jan 2021 16:28:37 -0800

On Wed, Jan 27, 2021 at 1:54 PM Christer Holmberg <
[email-masked]> wrote:

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

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.

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jan 2021 06:51:11 +0000

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

So, will it be fixed now?

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

And, what if the offerer does NOT have prior knowledge of the remote endpoint?

Also, what presents such endpoint from RECEIVING an offer with port zero + bundle-only, if sent e.g., by a non-browser?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jan 2021 09:35:17 +0000

Hi,

> First of all, SDP processing is not technically part of libwebrtc. Firefox, Chromium, and Safary have different code for that.

Ok, so why have people been talking about libwebrtc? My understanding was that it doesn't support bundle-only etc.

> Second, our code already works with existing implementations (i.e. identical ports for m= lines). Switching it to port 0 in Firefox caused some breakage but it was fixed as well. So, at this point, we do not care.

Ok. And, I assume you are talking about an intermediary entity (proxy, SBC etc), right?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jan 2021 09:38:41 +0000

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?

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 28 Jan 2021 11:10:48 -0800

On Thu, Jan 28, 2021 at 1:38 AM Christer Holmberg <
[email-masked]> wrote:

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

The same as now - existing applications would suddenly treat this as a
disabled m= section, when it previously worked fine.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 28 Jan 2021 14:48:17 -0500

On Thu, Jan 28, 2021 at 4:35 AM Christer Holmberg <
[email-masked]> wrote:

> > First of all, SDP processing is not technically part of libwebrtc.
> Firefox, Chromium, and Safary have different code for that.
>

libwebrtc has a reference implementation of  SDP processing. I think it
will at least accept bundle-only.

> Ok. And, I assume you are talking about an intermediary entity (proxy, SBC

It was in the basic SDP processing library that we use. It would short
circuit parsing m= lines with port zero and do not parse any of the
attributes. This code was previously added to avoid failing SDP parsing
with malformed SDP attributes in disabled m= lines.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jan 2021 20:09:04 +0000

Hi,

...

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

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jan 2021 20:15:55 +0000

Hi,

> libwebrtc has a reference implementation of  SDP processing. I think it will at least accept bundle-only.

Ok, but then it won't be able to *receive* an initial offer with port zero + bundle-only either, will it? 

> It was in the basic SDP processing library that we use. It would short circuit parsing m= lines with port zero and do not parse any of the attributes. This code was previously added to avoid failing SDP parsing with malformed SDP attributes in disabled m= lines.

Ok. I can see how that could happen. But, then the result would at least be predictable - the m= lines with port zero would be disabled, but you could still get a session with the non-zero m= lines. 

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 28 Jan 2021 12:16:35 -0800

On Thu, Jan 28, 2021 at 12:09 PM Christer Holmberg <
[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jan 2021 20:20:11 +0000

Hi,

...

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

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?

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 28 Jan 2021 12:36:35 -0800

On Thu, Jan 28, 2021 at 12:20 PM Christer Holmberg <
[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jan 2021 21:18:43 +0000

Hi,

...

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

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

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.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 28 Jan 2021 13:48:54 -0800

On Thu, Jan 28, 2021 at 1:18 PM Christer Holmberg <
[email-masked]> 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
> >>>>> The same as now - existing applications would suddenly treat this as
> a disabled m= section, when it previously worked fine.
> >>>>>
> >>>>> 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...
> >>>

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 Jan 2021 23:20:42 +0000

Hi,

...

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

> We're getting data now on how often max-bundle is used even with this limitation. 
>
> 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.

So, I think the port zero + bundle-only procedures should remain in JSEP - under a new JSEP policy if needed.

As I have said in the off-list discussions, 3GPP has also defined procedures based on receiving offers with port zero + bundle-only, and there are deployments based on those procedures.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 28 Jan 2021 15:32:25 -0800

On Thu, Jan 28, 2021 at 3:20 PM Christer Holmberg <
[email-masked]> wrote:

> >>>>>>> The same as now - existing applications would suddenly treat this
> as a disabled m= section, when it previously worked fine.
> >>>>>>>
> 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.
>
> >> 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.
> >
> >> 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.
> 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.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 30 Jan 2021 21:28:07 +0000

Hi,

...

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

We have been talking mostly about 'max-bundle'. But as far as I understand (and you also mentioned it earlier in the thread) we have the same issue with 'balanced', if the offer contains more than one m- line for the same media type. Or?

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Sat, 30 Jan 2021 14:35:40 -0800

On Sat, Jan 30, 2021 at 1:28 PM Christer Holmberg <
[email-masked]> wrote:

> We have been talking mostly about 'max-bundle'. But as far as I understand
> (and you also mentioned it earlier in the thread) we have the same issue
> with 'balanced', if the offer contains more than one m- line for the same
> media type. Or?
>
> You are correct, but the scope of this issue is believed to be far
smaller, given the slow adoption of unified plan (which is required for
multiple m= lines of the same type). IOW, we may choose a different
solution here than in the max-bundle case.

We should have data to allow us to draw a clearer conclusion on this in the
next few weeks.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 31 Jan 2021 18:07:46 +0000

Hi,

...

> You are correct, but the scope of this issue is believed to be far smaller, given the slow adoption of unified plan (which is required for multiple m= lines of the same type). IOW, we may choose a different solution here than in the max-bundle case.

Are you saying that browsers currently don't support multiple m= lines of the same type?

With 'balanced', as long as you only have one m= line per media type, there is no problem, as each m= line will have a unique port value in the offer.

Regards.

Christer