Intent to Ship: WebRTC RTP header extension behavior change

[Harald Alvestrand]

Contact emails

h...@chromium.org, gui...@chromium.org

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

Web Feature ID

webrtc

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

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?

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.

[Mike Taylor]

On 10/7/25 8:39 a.m., 'Harald Alvestrand' via blink-dev wrote:

Contact emails

h...@chromium.org, gui...@chromium.org

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

Web Feature ID

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?

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVGGxvwJcjsJ1gf3VzhoyOBHiQiqWpL15FUWWHjZS0m0jw%40mail.gmail.com.

[Harald Alvestrand]

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?

[Philipp Hancke]

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.

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.

[Mike Taylor]

Thanks both - that's helpful. 

LGTM1

[Rick Byers]

Sounds low risk of compat issues to me and the WebRTC field trial system should be sufficient to ensure any unexpected breakage can be quickly mitigated.

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d7d13930-0d66-40e8-a33c-d44bb30deaa7%40chromium.org.

[Chris Harrelson]

Hi, Please update the Interoperability and Compatibility of your Chromestatus entry to include the comments made here. Currently it says "none", which is not quite right.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_6ArukOP2ohqgHf9pXu%3DgBctH4BYz-jBMNizCN%2Bn5Yxg%40mail.gmail.com.

[Philip Jägenstedt]

LGTM3 with the chromestatus entry updated with the "Longer explanation" text or a summary of it.

The "abnormal case" described indeed sounds unlikely, and if we're wrong about this, we can use the kill switch.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_-P%3DFNn3%3DA9yX5oP37TAh4_JA4YqnHNzgkbyxJodLckQ%40mail.gmail.com.