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
On Mon, Oct 13, 2025 at 10:33 AM Mike Taylor <[email protected]> wrote: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d7d13930-0d66-40e8-a33c-d44bb30deaa7%40chromium.org?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/CAFUtAY_6ArukOP2ohqgHf9pXu%3DgBctH4BYz-jBMNizCN%2Bn5Yxg%40mail.gmail.com.
