Re: [rtcweb] JSEP-bis and WebRTC-Extensions Section 5.2

[Justin Uberti <[e-mail]>]

Oops, I now see there was another thread on this topic from yesterday.
Please disregard this one, sorry for any confusion.

On Fri, May 5, 2023 at 5:30 PM Justin Uberti <[e-mail]> wrote:

> The WebRTC W3C WG is working on an extension spec
> <https://w3c.github.io/webrtc-extensions/#rtp-header-extension-control-modifications>
> that suggests behavior for RTP header extension O/A that conflicts slightly
> with the current version of JSEP. Rather than have this sort of ad-hoc
> extensions extension to JSEP in the W3C spec, it was suggested that we
> could apply a tiny patch to JSEP before JSEP-bis is finalized (it's
> currently in the RFC Editor state). Murray was supportive of this but
> wanted to make sure the WG was fully behind this change first.
>
> For context, Section 5.2 in the W3C extension spec basically says that
> WebRTC endpoints can control the extensions that are in use, and as a
> result O/A negotiation should a) use only the extensions that are enabled
> by the endpoint, and b) always reoffer all extensions, rather than the
> previously negotiated set.
>
> I've made a PR that captures this request at
> https://github.com/rtcweb-wg/jsep/pull/1033/files, and it basically makes
> two surgical changes:
> 1) replaces the use of "supported RTP header extensions" with "enabled RTP
> header extensions"
> 2) changes the text around "extensions... present in the most recent
> answer" to instead say "extensions... enabled on the associated
> transceiver" (similar to how codecs are handled in JSEP).
>
> Please let me know if this sounds reasonable to you or you have concerns.
>
> Thanks,
> Justin
>
>