Discussed at today's API OWNERs. LGTM1 on the condition that we make sure there's a flag for rollout so that this can be kill-switched if the compat issues turn out to be problematic for other sites.
Best, Alex On Tuesday, April 1, 2025 at 12:29:50 AM UTC-7 Henrik Boström wrote: > We can discuss lifetimes of other stats objects, but that seems largely > tangential to this I2S thread. Good to hear you are supportive of delating > the outbound RTP stats objects until "stable" which is half of this I2S. > The other half being delaying inbound. > > But I think browser alignment here is looking promising: > - Firefox is positive to this change > <https://github.com/mozilla/standards-positions/issues/1202>. > - I asked Google Meet developer about this change and they said "it really > shouldn't matter". > - Web developers have already had to deal with inbound missing until > packet reception due to Firefox shipping this years ago. > On Monday, March 31, 2025 at 10:12:25 PM UTC+2 philipp...@googlemail.com > wrote: > >> Am Mo., 31. März 2025 um 01:05 Uhr schrieb Henrik Boström < >> h...@chromium.org>: >> >>> That's correct, but getStats() does not really contain any useful >>> information during the period of time where we want to not expose it to the >>> web anymore. All counters in the objects are 0s because they haven't "been >>> used yet". >> >> >> I filed >> https://github.com/w3c/webrtc-stats/issues/804 >> because why are you applying the "no packets no stats" rule to RTP but >> not the underlying transport? >> (which notably is implemented and exposed by Chromium and Safari, Firefox >> still lacks an implementation) >> And since I am in such a joyful mood I also filed >> https://github.com/w3c/webrtc-stats/issues/805 >> which shows datachannel stats also violate the "no packets no stats" rule >> (in Firefox too!) >> May I suggest the WG does an evaluation of whether it would be easier to >> keep the current behavior and make RTP consistent with the rest of the >> specification and implementations? >> >> Not exposing the stats before negotiation happened is generally something >> that I consider a good idea to reduce create-then-delete-churn but 50/50 on >> whether it flies. >> >> >>> So the delta is about whether you have access to the SSRC value or not. >>> The use case that is being affected by this change is "I depend on SSRCs >>> being signalled in the SDP but I don't want to parse the SDP for SSRC >>> information and I need to know them before the first packet is received". >>> So it's a dependency on the UA implementing an RFC that is not mandated to >>> implement, and a use case where the app can work around it by parsing the >>> SSRC values themselves. >>> >> >>> Use cases that don't depend on this RFC are largely unaffected - even if >>> SSRCs are not exposed in the SDP we will continue to expose send-side SSRCs >>> in getStats early, and receive-side SSRCs were never exposed early in this >>> case to begin with so that's a NO-OP change. >>> >> >> I believe you are reopening the 2017 >> https://github.com/w3c/webrtc-pc/issues/1174, in particular the 2019 >> discussion here >> <https://github.com/w3c/webrtc-pc/issues/1174#event-2171339414>. >> but you do it on getStats() instead of doing it on getParameters()? >> >> On Monday, March 31, 2025 at 6:13:35 AM UTC+2 Yoav Weiss wrote: >>> >>>> Just to clarify - currently both Chromium, WebKit and (most?) >>>> deployments in the wild match one behavior and the spec calls for another? >>>> >>>> On Friday, March 28, 2025 at 6:20:28 PM UTC+1 philipp...@googlemail.com >>>> wrote: >>>> >>>>> Am Fr., 28. März 2025 um 08:31 Uhr schrieb Harald Alvestrand < >>>>> h...@google.com>: >>>>> >>>>>> WRT "no SSRC signalling": Of course it's allowed to include RFC 5576 >>>>>> style signalling if you want to. >>>>>> But RFC 8829 (JSEP) has only this reference to 5576: >>>>>> >>>>>> >>>>>> - Any "a=ssrc" attributes MUST be parsed as specified in [RFC5576 >>>>>> <https://datatracker.ietf.org/doc/html/rfc5576>], Section 4.1 >>>>>> <https://www.rfc-editor.org/rfc/rfc5576#section-4.1>, and their >>>>>> values stored.¶ >>>>>> <https://datatracker.ietf.org/doc/html/rfc8829#section-5.8.2-8.6> >>>>>> >>>>>> >>>>>> It never says to generate an a=ssrc attribute. >>>>>> >>>>> >>>>> But if it is parsed and stored it can be used for stats? >>>>> As the fiddle above demonstrates this gets causes the creation of the >>>>> object in the underlying C++ code. >>>>> >>>>> >>>>>> This means that a) we can't depend on JSEP-compatible browsers to >>>>>> generate SSRC attributes, and b) we can't write Web Platform tests that >>>>>> check for the result of SSRC attributes, since none are specified. >>>>>> >>>>> >>>>> Yes and we have >>>>> https://wpt.fyi/results/webrtc/simplecall-no-ssrcs.https.html?label=experimental&label=master&aligned >>>>> >>>>> which is all green. >>>>> >>>>> >>>>>> The various WGs have discussed SSRC signaling many times, and always >>>>>> came down on rejecting it. I even had an internet-draft >>>>>> (draft-alvestrand-mmusic-simulcast-ssrc-01) specifying a way to use it >>>>>> in >>>>>> order to increase backwards compatibility, but the WGs declined to >>>>>> pursue >>>>>> that effort, and I let the draft expire. >>>>>> Hope that this clarifies a bit. >>>>>> >>>>>> Harald >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 28, 2025 at 4:16 PM Henrik Boström <h...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Hello Philipp. Philipp is the "vocal member of our community" that I >>>>>>> referenced earlier as you may have guessed. >>>>>>> >>>>>>> Regarding "for what gain?", I think it is good that all browsers >>>>>>> align on behavior to avoid edge case surprises. That is good in and of >>>>>>> itself. Considering the latest spec changes incorporate the use case of >>>>>>> obtaining SSRCs prior to sending, I fail to see any use case that is >>>>>>> hurt >>>>>>> my making the browsers align. >>>>>>> >>>>>> >>>>> This changes Chromium (and by virtue of being a pass-through libwebrtc >>>>> user Safari) to what the WG decided to restrict. Or tried to restrict but >>>>> the issue popped up again and again and again. >>>>> This is a web-facing change. >>>>> >>>>> >>>>>> Regarding code links that filtering is happening in Firefox: when an >>>>>>> object is created in these discussions refers to the point of time that >>>>>>> it >>>>>>> becomes observable in JavaScript for the first time, so whether Firefox >>>>>>> implements this via filtering on top of the libwebrtc or through other >>>>>>> means is an implementation detail that is not observable and is thus >>>>>>> irrelevant to our discussions. >>>>>>> >>>>>>> Harald may have more information about the rationale for why we >>>>>>> don't want to signal SSRCs in the SDP, but it would be good to decouple >>>>>>> that question from the question of when RTP stats objects should be >>>>>>> created >>>>>>> considering they contain 0 useful information during the period of time >>>>>>> that we want them not to be exposed to JavaScript. >>>>>>> >>>>>> >>>>> The information they contain is the mapping from mid to ssrc. Which >>>>> you argued for in https://issues.chromium.org/issues/404853839 for >>>>> outbound-rtp. >>>>> https://jsfiddle.net/fippo/v6jf2cs5/ (outbound-rtp) >>>>> contains the same information as >>>>> https://jsfiddle.net/fippo/vcmnx6wy/ (inbound-rtp) >>>>> We agree that they should not be exposed prior to full negotiation. >>>>> But knowing that you are supposed to receive packets for a SSRC and >>>>> your infrequent polling of getStats shows no change in packetsReceived >>>>> for >>>>> five seconds is more integrated into how getStats is typically used than >>>>> developers keeping track of which mids were negotiated in the SDP (which >>>>> is >>>>> available through getTransceivers()) and then figuring out for which >>>>> receiving mids inbound-rtp stats are missing. >>>>> >>>>> >>>>> On Friday, March 28, 2025 at 4:03:11 PM UTC+1 >>>>>>> philipp...@googlemail.com wrote: >>>>>>> >>>>>>>> >>>>>>>> 4 >>>>>>>> Am Fr., 28. März 2025 um 05:47 Uhr schrieb Henrik Boström < >>>>>>>> h...@chromium.org>: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> h...@chromium.org, h...@chromium.org >>>>>>>>> >>>>>>>>> ExplainerNone >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> https://w3c.github.io/webrtc-stats/#the-rtp-statistics-hierarchy >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> RTP stats objects, of type "outbound-rtp" or "inbound-rtp" in this >>>>>>>>> case, represents a WebRTC stream. The identifier of this stream is >>>>>>>>> the SSRC >>>>>>>>> (a number). We should collect stats for streams that "exist", but >>>>>>>>> implementations and spec has disagreed on when the stream should >>>>>>>>> exist: if >>>>>>>>> the SSRC information is conveyed via SDP, does the stream still exist >>>>>>>>> before packets are sent or received? >>>>>>>>> >>>>>>>> >>>>>>>> We have been mulling over this for a while: >>>>>>>> https://github.com/w3c/webrtc-stats/issues/619 >>>>>>>> https://github.com/w3c/webrtc-stats/issues/667 >>>>>>>> https://github.com/w3c/webrtc-stats/issues/781 >>>>>>>> https://github.com/w3c/webrtc-stats/issues/797 >>>>>>>> >>>>>>>> The fact that SSRCs can be signalled in SDP is only done for >>>>>>>>> backwards compatibility reasons >>>>>>>>> >>>>>>>> >>>>>>>> Source for this? RFC 5576 is not deprecated and I keep on looking >>>>>>>> for the rationale that backs Chromiums decision to not include ssrcs >>>>>>>> line >>>>>>>> in the SDP for simulcast (I could not find a source for that as >>>>>>>> presented >>>>>>>> in https://github.com/w3c/webrtc-pc/issues/1174 either) >>>>>>>> For context: Chromium continues to put these lines into the SDP. >>>>>>>> For "backward compat" SDP offers even contain ssrc lines with msid >>>>>>>> related >>>>>>>> to the long-unshipped "plan b". >>>>>>>> >>>>>>>> , yet Chromium-based browsers currently create the "inbound-rtp" >>>>>>>>> stats object if the SSRC is signalled in the SDP, which means you can >>>>>>>>> end >>>>>>>>> up with subtly different behavior depending on which endpoint you are >>>>>>>>> setting up a WebRTC call with (if they include SSRCs or not). >>>>>>>>> >>>>>>>> >>>>>>>> Safari behaves the same as Chromium (which is not surprising): >>>>>>>> >>>>>>>> https://wpt.fyi/results/webrtc-stats/rtp-stats-creation.html?label=experimental&label=master&aligned >>>>>>>> >>>>>>>> What the spec says to do here, which is what Firefox has already >>>>>>>>> implemented, is to delay the creation of the "inbound-rtp" stats >>>>>>>>> object >>>>>>>>> until the first packet is received. This is future-proof, because the >>>>>>>>> packet contains the SSRC information and will always work, while the >>>>>>>>> current behavior can result in "early" creation depending on SSRC >>>>>>>>> signalling. >>>>>>>>> >>>>>>>> >>>>>>>> Firefox notably decided to signal SSRCs even in cases where >>>>>>>> Chromium does not. >>>>>>>> >>>>>>>> >>>>>>>>> - We want Chromium to align with Firefox and spec behavior here. >>>>>>>>> >>>>>>>> >>>>>>>> For what gain? >>>>>>>> >>>>>>>> Firefox decided to filter the result of the underlying >>>>>>>> implementation: >>>>>>>> >>>>>>>> https://searchfox.org/mozilla-central/source/dom/media/webrtc/jsapi/RTCRtpReceiver.cpp#356 >>>>>>>> It would be trivial for Firefox to remove that block (for both >>>>>>>> media kinds) and increase their compat with what web(rtc) developers >>>>>>>> expect. >>>>>>>> >>>>>>>> Notably anything based on libWebRTC will not create a stats report >>>>>>>> until the SSRC is known (which is reasonable): >>>>>>>> https://jsfiddle.net/fippo/vcmnx6wy/ >>>>>>>> The SDP is a source of that information that information is used in >>>>>>>> other parts of the stack already (e.g. to associate the packet with a >>>>>>>> receiver object) >>>>>>>> >>>>>>>> >>>>>>>>> Next up is when to create "outbound-rtp" stats objects. In this >>>>>>>>> case the SSRCs are configured by the local sender and are known >>>>>>>>> whether or >>>>>>>>> not the SSRC information is put in the SDP, so creating them "early" >>>>>>>>> is >>>>>>>>> also future-proof. In this case, we want the stats objects to be >>>>>>>>> created >>>>>>>>> BEFORE packets are sent, because they are needed to know which >>>>>>>>> encoding has >>>>>>>>> which SSRC, see slides >>>>>>>>> <https://docs.google.com/presentation/d/1XOyWSPufsvDpK18GXZvq_j1rF3gs34QvPlOWWyB0CjU/edit?slide=id.g3426753bdd0_1_17#slide=id.g3426753bdd0_1_17> >>>>>>>>> for >>>>>>>>> nerdy details. >>>>>>>>> >>>>>>>> >>>>>>>> Hold a bit here. The original rationale for >>>>>>>> https://github.com/w3c/webrtc-pc/issues/1174 was not not create a >>>>>>>> conflict between ssrc and rid. >>>>>>>> You are now exposing that conflict on the sender? (I never bought >>>>>>>> that argument) >>>>>>>> >>>>>>>> The spec was recently updated to reflect that "outbound-rtp" stats >>>>>>>>> objects should be created before packets are sent, but not until the >>>>>>>>> SDP >>>>>>>>> negotiation has completed. >>>>>>>>> - Chromium is slightly too early here, creating them before O/A >>>>>>>>> has completed, but is almost spec-compliant. >>>>>>>>> - Firefox creates them too late (after first packet is sent which >>>>>>>>> is what the spec previously said). They will also need to update >>>>>>>>> their >>>>>>>>> behavior. >>>>>>>>> >>>>>>>> >>>>>>>> Not quite, Firefox intentionally filters the libWebRTC result here: >>>>>>>> >>>>>>>> https://searchfox.org/mozilla-central/source/dom/media/webrtc/jsapi/RTCRtpSender.cpp#347 >>>>>>>> >>>>>>>> >>>>>>>>> Blink component >>>>>>>>> Blink>WebRTC>PeerConnection >>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebRTC%3EPeerConnection%22> >>>>>>>>> >>>>>>>>> TAG review >>>>>>>>> N/A >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> We are trying to reduce risk of interop by having browsers align. >>>>>>>>> There is a small risk of backwards-compat when the lifetime logic is >>>>>>>>> update, however considering web apps are already dealing with >>>>>>>>> Chrome's "too >>>>>>>>> early" logic and Firefox's "too late" logic, it seems that web apps >>>>>>>>> should >>>>>>>>> be well prepared for updating them to being created at a point in >>>>>>>>> time that >>>>>>>>> is in-between these two extremes. >>>>>>>>> >>>>>>>>> *Gecko*: >>>>>>>>> https://github.com/mozilla/standards-positions/issues/1202 >>>>>>>>> *WebKit*: https://github.com/WebKit/standards-positions/issues/478 >>>>>>>>> >>>>>>>>> *Web developers*: No signals, except for one vocal member of our >>>>>>>>> community who would prefer to see everyone align on Chrome's current >>>>>>>>> behavior, but we are unlikely to get consensus on that. >>>>>>>>> >>>>>>>> >>>>>>>> Oh, you are asking me to ask around? Shall do! >>>>>>>> >>>>>>>> I'll continue to question the WGs decision making but enjoying the >>>>>>>> break I decided to take a year ago. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 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 this is fully testable here: >>>>>>>>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/rtp-stats-lifetime.https.html >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> None >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/4580748730040320?gate=5113159150731264 >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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+unsubscr...@chromium.org. >>>>>>>>> To view this discussion visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c8b53bd3-6fed-466e-be5d-d53bc31c8dafn%40chromium.org >>>>>>>>> >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c8b53bd3-6fed-466e-be5d-d53bc31c8dafn%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 blink-dev+unsubscr...@chromium.org. >>>>>>> To view this discussion visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3e542d12-7e1b-45e4-9129-bace5b1b9840n%40chromium.org >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3e542d12-7e1b-45e4-9129-bace5b1b9840n%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a7146450-2c5d-45f7-b62f-040f7c4921e3n%40chromium.org.
