1853717 - "remote-inbound-rtp" received packets overflow

Status: UNCONFIRMED

(Core :: WebRTC, defect)

Description

[Hugo Tunius[:k0nserv]]

Attachment: Screenshot 2023-09-18 at 15.38.44.png

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

Comment 1

[Hugo Tunius[:k0nserv]]

Attachment: Unreasonable RR

Comment 2

[Hugo Tunius[:k0nserv]]

Attachment: Reasonable RR

Comment 3

[Hugo Tunius[:k0nserv]]

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.

Comment 4

[Hugo Tunius[:k0nserv]]

Attachment: example-rr

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.

Comment 5

[Hugo Tunius[:k0nserv]]

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

Comment 6

[Jim Mathies [:jimm]]

Seeking feedback from Byron.

Comment 7

[Byron Campen [:bwc]]

Did bug 1852775 resolve this?

Comment 8

[Hugo Tunius[:k0nserv]]

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.

Comment 9

[Byron Campen [:bwc]]

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

Comment 10

[Andreas Pehrson [:pehrsons]]

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?

Comment 11

[Byron Campen [:bwc]]

What do you think about a spec modification here?

Comment 12

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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

Comment 13

[Daniel Bodea [:danibodea]]

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!

Comment 14

[Byron Campen [:bwc]]

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