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. On Wed, Oct 15, 2025 at 5:08 PM Chris Harrelson <[email protected]> wrote: > 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. > > On Tue, Oct 14, 2025 at 7:24 AM Rick Byers <[email protected]> wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_6ArukOP2ohqgHf9pXu%3DgBctH4BYz-jBMNizCN%2Bn5Yxg%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/CAOMQ%2Bw_-P%3DFNn3%3DA9yX5oP37TAh4_JA4YqnHNzgkbyxJodLckQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_-P%3DFNn3%3DA9yX5oP37TAh4_JA4YqnHNzgkbyxJodLckQ%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/CAARdPYfeXS8i0Z58Zitn3CXenfEW8-uyn_iDR1HhYSDaBDE_SA%40mail.gmail.com.
