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/ba666064-87a1-4414-9bd2-a3497e1a85f7n%40chromium.org.
