Intent to Ship: [WebRTC getStats] Align implementations on when RTP stats should be created

[Henrik Boström]

Contact emails

hb...@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?

The fact that SSRCs can be signalled in SDP is only done for backwards compatibility reasons, 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). 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.

- We want Chromium to align with Firefox and spec behavior here.

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 for nerdy details. 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.

Blink component

Blink>WebRTC>PeerConnection

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.

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?

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

[Philipp Hancke]

4

Am Fr., 28. März 2025 um 05:47 Uhr schrieb Henrik Boström <hb...@chromium.org>:

Contact emails

hb...@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 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

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?

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+...@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.

[Henrik Boström]

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.

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.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Harald Alvestrand]

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], Section 4.1, and their values stored.¶

It never says to generate an a=ssrc attribute.

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.

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

--

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+...@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.

[Philipp Hancke]

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], Section 4.1, and their values stored.¶

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 <hb...@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.

[Yoav Weiss (@Shopify)]

Just to clarify - currently both Chromium, WebKit and (most?) deployments in the wild match one behavior and the spec calls for another?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Henrik Boström]

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".

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.

[Harald Alvestrand]

There is an use case that is enabled in Firefox by the change: Where the SSRC is *not* present in the SDP (which is legal and implicitly encouraged in the spec), the SSRCs that will be used for sending can be discovered before the first packet is sent.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

--
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+...@chromium.org.

[Philipp Hancke]

Am Mo., 31. März 2025 um 01:05 Uhr schrieb Henrik Boström <hb...@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.

but you do it on getStats() instead of doing it on getParameters()?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

--
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+...@chromium.org.

[Henrik Boström]

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.

- 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.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.

--
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+unsubscribe@chromium.org.

[Alex Russell]

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

[Daniel Bratell]

LGTM2 (with flag)

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

[Philip Jägenstedt]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.

--
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+...@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.

--
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+...@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.

--
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+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fa61ffef-0525-4117-a0da-b91d414d89c2%40sarasas.se.