Remove JSEP Modifications #164
Conversation
There is an existing process for submitting RFC 8829 errata, as well as for updating RFC 8829bis (now in the RFC Editor queue). Let's see if we can address these JSEP issues some other way.
|
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 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. |
|
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. (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 |
Fixes #134
There is an existing process for submitting RFC 8829 errata, as well as for updating RFC 8829bis (now in the RFC Editor queue). Let's see if we can address these JSEP issues some other way. Justin Uberti will join us at the May 4 WEBRTC WG Editor's meeting to discuss alternatives.
Preview | Diff