Thanks both - that's helpful.
LGTM1
On 10/10/25 7:09 a.m., Philipp Hancke wrote:
i'd expect the typical usage to be iterating over the extensions and
setting the desired state for each one you care about without looking
at the current state which should, fingers crossed, work just the same.
Am Fr., 10. Okt. 2025 um 11:29 Uhr schrieb 'Harald Alvestrand' via
blink-dev <[email protected]>:
Longer explanation....
This API has been used up to now to turn on behavior (in the form
of RTP header extensions) on the RTP connection that was shipped
as off-by-default. We don't believe that anyone has actively used
it to turn off features.
This usage should see no change (therefore no risk). What will
change is that when features that are on by default are turned off
in negotiation, they will remain off in subsequent negotiation rounds.
There are two normal cases I can think of, and one abnormal one:
- The responder does not support the feature, and therefore always
replies with "feature off". Result is that it will not be turned
on - no change.
- The responder supports the feature, but has rejected it in
initial negotiation because it does not want to use it. In that
case, under previous behavior, it would have to respond to all
subsequent negotiation rounds by turning off the feature again.
Under the new behavior, it will already be off in the offer, so
the result of turning it off again will not make any difference -
no change.
The abnormal case:
- The responder supports the feature, but has rejected it in
initial negotiation because it does not want to use it, but does
not have code to turn it off in subsequent negotiation (likely due
to this code path not being tested). In this case, the feature
will presently turn on after a subsequent round of negotiation
despite being initially rejected. This is not likely to be a
desired behavior.
So we think that this change brings no change to expected behavior
for current users, and if the hypothetical user that turns off
features using this API exists, it is more likely to fix an
undetected bug in their code than to introduce undesired behavior.
Does that answer the question?
On Wed, Oct 8, 2025 at 2:54 PM Mike Taylor
<[email protected]> wrote:
On 10/7/25 8:39 a.m., 'Harald Alvestrand' via blink-dev wrote:
*Contact emails*
[email protected], [email protected]
*Specification*
https://w3c.github.io/webrtc-extensions/#rtp-header-extension-control-modifications
*Summary*
Users of
https://chromestatus.com/feature/5680189201711104 found that
the API as specified was not ergonomic for subsequent
offer/answer. The WG has adopted a revised behavior, merged
to spec in https://github.com/w3c/webrtc-extensions/pull/238,
that ensures that subsequent offer/answer does not permute
the header extensions negotiated unless the user wants that
to happen.
*Blink component*
Blink>WebRTC>PeerConnection
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebRTC%3EPeerConnection%22>
*Web Feature ID*
webrtc <https://webstatus.dev/features/webrtc>
*TAG review*
None
*TAG review status*
Not applicable
*Risks*
*Interoperability and Compatibility*
None
As a non WebRTC expert, could you help me understand what kind
of risk this change might bring to applications relying on the
current shipping behavior?
/Gecko/: No signal
/WebKit/: No signal
/Web developers/: No signals
/Other signals/:
*WebView application risks*
Does this intent deprecate or change behavior of existing
APIs, such that it has potentially high risk for Android
WebView-based applications?
Low risk. Protected by WebRTC field trial
"WebRTC-HeaderExtensionNegotiateMemory".
*Debuggability*
No DevTools support needed. Existing webrtc-internals should
be sufficient for debugging.
*Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?*
Yes
*Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
Yes
webrtc-extensions/RTCRtpTransceiver-headerExtensionControl.html
will be affected by the spec change. A test update will be
shipped together with enabling the feature. wpt.fyi link:
https://wpt.fyi/results/webrtc-extensions/RTCRtpTransceiver-headerExtensionControl.html
*Flag name on about://flags*
WebRTC-HeaderExtensionNegotiateMemory (WebRTC field trial)
*Finch feature name*
None
*Non-finch justification*
The change is in webrtc, so it uses WebRTC field trials which
provide the same functionality as finch flags in practice
(including the ability to do Finch experiments/kill switches)
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
False
*Tracking bug*
https://issues.webrtc.org/439514253
*Availability expectation*
The base spec being modified is only available in Chromium
browsers so far. Given support from other vendors in WG, we
expect that when others ship this, they will conform to the
modified spec.
*Adoption expectation*
Feature will be used by partners utilizing WebRTC advanced
features.
*Adoption plan*
Feature will be used in the rollout of L4S congestion control
in Meet, with other interactive video products expected to
follow.
*Estimated milestones*
Shipping on desktop 144
Shipping on Android 144
Shipping on WebView 144
*Anticipated spec changes*
All spec changes merged.
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5135528638939136?gate=5170761664954368
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVGGxvwJcjsJ1gf3VzhoyOBHiQiqWpL15FUWWHjZS0m0jw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVGGxvwJcjsJ1gf3VzhoyOBHiQiqWpL15FUWWHjZS0m0jw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVGk6v_KV4DOpghk%3DKscgxMRA%3D%2BCd38%2B_JjjdCEMvXg8bA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVGk6v_KV4DOpghk%3DKscgxMRA%3D%2BCd38%2B_JjjdCEMvXg8bA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d7d13930-0d66-40e8-a33c-d44bb30deaa7%40chromium.org.
