Open Bug 1749749 Opened 3 years ago Updated 2 years ago

packetsReceived in remote rtp stats can jump

Categories

(Core :: WebRTC, defect)

defect

Tracking

()

Tracking Status
firefox-esr91 --- unaffected
firefox96 --- wontfix
firefox97 --- wontfix
firefox98 --- fix-optional

People

(Reporter: pehrsons, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Nils reported seeing "packetsReceived" in "remote-inbound-rtp" jumping from 618 to 4294903779. This is likely due to the logic here where aRtcpData.report_block().extended_highest_sequence_number is higher than *base_seq but aRtcpData.report_block().extended_highest_sequence_number - aRtcpData.report_block().packets_lost is lower, so we go negative and wrap around the uint.

I'm not sure how this is possible. That code is from D108671 so perhaps Byron has an idea?

Flags: needinfo?(docfaraday)
Regressed by: 1654112
Has Regression Range: --- → yes

Maybe the RTCP has garbage in it? We aren't sanity-checking these values in our code, and maybe libwebrtc isn't checking them either? I guess I'd need to see some output with MOZ_LOG=RtpLogger:5

Flags: needinfo?(docfaraday)

Garbage (as in random) seems unlikely, 4294903779 is too close (63516) to the upper bound of uint32_t.

In fact if we offset this number by uint16_t's max (65535, aka -1), packetsReceived would be 2019 which seems entirely plausible. An RTP sequence number is 16 bits and is represented as uint16_t in various places. I looked around a bit for this in libwebrtc, but nothing stood out.

Nils, have you been able to reproduce this locally, or is it showing in your telemetry or something? Do you know what app was running the remote side?

Flags: needinfo?(drno)

Set release status flags based on info from the regressing bug 1654112

(In reply to Andreas Pehrson [:pehrsons] from comment #3)

Garbage (as in random) seems unlikely, 4294903779 is too close (63516) to the upper bound of uint32_t.

By "garbage", I meant just incorrect values. It is hard to say without any sort of logging or pcap.

Severity: -- → S4

I noticed this in stats recorded on a Jitsi call between two Firefox tabs on the same laptop. I can try to repro.

do you happen to know the user impact on this?

Flags: needinfo?(apehrson)

End user impact should be low to none, but webrtc services may see weird data and so won't be able to carry out proper analysis of their network stats.

Flags: needinfo?(apehrson)
See Also: → 1759696

Declaring NI bankruptcy.

Flags: needinfo?(drno)
You need to log in before you can comment on or make changes to this bug.