On Thu, Oct 16, 2025, 2:58 AM 'Harald Alvestrand' via blink-dev < [email protected]> wrote:
> Thanks - I have entered a shortened version of the "longer explanation" > under "interoperability risks. > Great! Thanks. > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVH%2BCJQfUTpiRAfygUWzm-1GRz4EWXx4GC5ZuctuqSbZAg%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-NetxXK_p%2BwB9WSd1oV4YF_wTkJniaJf9si99uH%2Bu9yQ%40mail.gmail.com.
