https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3763
Summary: Cumulative number of packets lost in RTCP sender report
should be a signed number
Product: Wireshark
Version: 1.2.1
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: hoiho.chan@xxxxxxxxx
Build Information:
N/A
--
>From page 38 of RFC3550, the definition of the cumulative number of packets
lost in RTCP sender report is defined as:
cumulative number of packets lost: 24 bits
The total number of RTP data packets from source SSRC_n that have
been lost since the beginning of reception. This number is
defined to be the number of packets expected less the number of
packets actually received, where the number of packets received
includes any which are late or duplicates. Thus, packets that
arrive late are not counted as lost, and the loss may be negative
if there are duplicates. The number of packets expected is
defined to be the extended last sequence number received, as
defined next, less the initial sequence number received. This may
be calculated as shown in Appendix A.3.
This number could be negative in case of duplicated packets, however in the
code it appears the number was dissected as an unsigned int (in
epan/dissectors/packet-rtcp.c)
/* Cumulative number of packets lost, 24 bits */
cum_nr = tvb_get_ntohl( tvb, offset ) >> 8;
proto_tree_add_uint( ssrc_sub_tree, hf_rtcp_ssrc_cum_nr, tvb,
offset, 3, cum_nr );
offset += 3;
I can provide a patch if this is confirmed a bug.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
