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. 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 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. > > 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. > 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/CAOqqYVFvAkJ7O1H5b8ovAFneHdZZx4mgmvLZ7G0_OsD3euZJJQ%40mail.gmail.com.
