W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > December 2022

[webrtc-extensions] FrozenArray on headerExtensionsToOffer a mistake, wrong semantics (#137)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Fri, 09 Dec 2022 22:22:39 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-1487556516-1670624557-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-extensions:

== FrozenArray on headerExtensionsToOffer a mistake, wrong semantics ==
With no explainer or examples showing how `headerExtensionsToOffer` is meant to be used, it's a bit unclear what its requirements are. But https://github.com/w3c/webrtc-extensions/issues/130#issuecomment-1338005567 suggests at least two possible uses I arrived at without any guidance:
1. to filter input meant for setHeaderExtensionsToOffer
2. to serve as a (modifiable) base for input to setHeaderExtensionsToOffer

However, once https://github.com/w3c/webrtc-extensions/issues/136 is fixed, using the output as input is going to no-op in ways that might surprise users:
const headers = transceiver.headerExtensionsToOffer; // not using structuredClone() as workaround!
for (const header of headers) {
  if (header.uri == "urn:ietf:params:rtp-hdrext:ssrc-audio-level") {
    header.direction = "stopped";  // won't work if direction is unmodifiable
JS is going to try to modify headers that are unmodifiable, not get any errors, and call setOfferedRtpHeaderExtensions thinking everything is fine, when nothing got done.

### Proposals
- The simplest fix seems to be to replace it with a familiar `getHeaderExtensionsToOffer()` returning a sequence\<dictionary>

Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/137 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 9 December 2022 22:22:41 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:59 UTC