packetsReceived in remote rtp stats can jump
Categories
(Core :: WebRTC, 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.
Reporter | ||
Comment 1•3 years ago
|
||
I'm not sure how this is possible. That code is from D108671 so perhaps Byron has an idea?
Updated•3 years ago
|
Comment 2•3 years ago
|
||
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
Reporter | ||
Comment 3•3 years ago
|
||
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?
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Set release status flags based on info from the regressing bug 1654112
Comment 5•3 years ago
|
||
(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.
![]() |
||
Updated•3 years ago
|
Comment 6•3 years ago
|
||
I noticed this in stats recorded on a Jitsi call between two Firefox tabs on the same laptop. I can try to repro.
Reporter | ||
Comment 8•3 years ago
|
||
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.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Description
•