JSEP talks about "For each supported RTP header extension", so one might argue that a JSEP-compatible version of this PR that doesn't turn the API into a NO-OP might be to replaces the JSEP modifications with one new step at the end of setHeaderExtensionsToNegotiate: "Modify the underlying set of supported RTP header extensions to match [[HeaderExtensionsToNegotiate]]."

You might want to argue whether that is or is not OK but it seems better than a NO-OP until we have something in JSEP to do what we want.

@henbos RFC 8829bis assumes that "supported" RTP header extensions are always offered, and if offered, are answered. But with the RTP header extension API only the "mandatory to use" RTP header extensions are automatically offered/answered; a "supported" RTP header extension also needs to be in the [[HeaderExtensionsToNegotiate]]. So if we can still change RFC 8829bis, perhaps we can swap out the word "supported" for something better without having to refer to internal slots. If we can't modify RFC 8829bis, your suggestion might work.

rtcweb-wg/jsep#1031

rtcweb-wg/jsep#1032

In order to not derail our work that depends on the JSEP changes, I suggest that we update our JSEP reference to point to the -bis draft as part of this PR.
If we can't say "JSEP needs to change" in our document, we need to be able to point to the WIP document that makes the changes.

(The PR has a "JSEPbis" reference, but it does not resolve)

This issue was discussed in WebRTC May 2023 meeting – 16 May 2023 (Issue #134 / PR #164: Remove JSEP Modifications)

This issue was mentioned in WEBRTCWG-2023-05-16 (Page 24)

PTAL: rtcweb-wg/jsep#1033