User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

Send a simulcast video stream(1 m-line, recvonly, 3 spatial layers) to an SFU.

The server in this case is based on str0m and the code to generate receiver report blocks is here: https://github.com/algesten/str0m/blob/cadda0193391279037d2b31ddc02dedf7fdf0ab3/src/streams/register.rs#L97-L116

It's possible that we have a bug in str0m, but Firefox shouldn't overflow in any case.

Actual results:

The value reported for RTCReceivedRtpStreamStats.receviedPackets overflows

Expected results:

Firefox to report correct stats for RTCReceivedRtpStreamStats.receivedPackets

We definitely have a bug on our side it seems. These are two consecutive RRs. We reported that 9697 packets were lost in a 1 second window and many of the other values are bit wonky too.

Here's a ReceiverReport block that caused the overflow immediately, this was the first receiver report we sent for the RTP stream, we obviously have a bug in how this was generated.

I did further digging into this. The reason we generate these weird Receiver Reports is that Firefox sometimes sends spurious RTX on the wrong SSRC, e.g., it will resends a packet from layer rid=l on the RTX stream for layer rid=m. This in turn causes us to generate these very strange Receiver Reports. The underlying issue with Firefox using the wrong RTX stream was fixed in 1852775

Seeking feedback from Byron.

Did bug 1852775 resolve this?

Yes we don't generate these weird Receiver Reports anymore after 1852775, my hunch was always that we were generating garbage data. pehrsons suggested I raise this bug as they thought Firefox shouldn't overflow even on garbage data.

Hmm. Spec doesn't say to ignore obvious garbage data, and having the stats reflect garbage data is helpful in noticing bugs, especially given that the spec doesn't have any error reporting mechanism for this. I do agree that overflow is pretty much the ugliest flag we could raise, but I'm not sure what the alternative is...

The spec says this is an unsigned long long which should overflow at 64 bits, not 32. But given that this can overflow on external data maybe that is a case for making the spec handle this case, or at least for making it signed like packetsLost?

What do you think about a spec modification here?

Makes sense. I've filed https://github.com/w3c/webrtc-stats/issues/772.

Can this report be closed considering that the issue was it was fixed in bug 1852775 (as per comment 8)? Is there another reason to keep it open? Thank you!

Let's leave this open for changing the type of packetsReceived to a signed int, if jib's issue is handled in that manner.