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/dbd6a303-7695-4f54-9ae8-96e1979320e0n%40chromium.org.
