Thanks - I have entered a shortened version of the "longer explanation" under "interoperability risks".
On Wed, Oct 15, 2025 at 5:13 PM Philip Jägenstedt <[email protected]> wrote: > 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/CAOqqYVH%2BCJQfUTpiRAfygUWzm-1GRz4EWXx4GC5ZuctuqSbZAg%40mail.gmail.com.
