This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

How wire shark calculated the lost RTP packets

0

How wire shark calculated the lost RTP packets. When I do select Telephony->RTP->Show All streams it shows the number of RTP packets received from a source ip:port to dest ip:port. It also shows number of packets lost under LOST tab. How wireshark is calculating the packet loss here from a source.

asked 12 Feb '16, 03:27

Subhendu%20Kumar%20Das's gravatar image

Subhendu Kum...
6112
accept rate: 0%


One Answer:

0

The RTP header contains a sequence number which monotonously grows by 1 (and rolls over from 65535->0). Wireshark (and also normal applications processing RTP) use this field to verify correct ordering and loss of RTP packets.

This also means that Wireshark may report lost packets even in RTP flows where no actual loss has happened if the source of the RTP has created a gap in the RTP sequence numbers for any reason.

answered 12 Feb '16, 03:47

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 12 Feb '16, 03:50

Note that the actual implementation is (IIRC) a bit more simplistic than this which has been known to cause problems (like Wireshark reporting negative 95% packet loss). IIRC Wireshark basically subtracts (modulo 65535) the last sequence number from the first and then compares this to the number of packets received. When the sequence numbers jump around this can cause funny results (I think there's at least one bug open about this).

But fundamentally this answer is spot-on.

(12 Feb '16, 06:26) JeffMorriss ♦

@JeffMorriss, I assume your description is only applicable for the statistics part, and that the detailed analysis still allows to "jump at next anomaly" the way it did before, i.e. if there is a single lost packet, this fact is highlighted in the packet list of the stream?

(12 Feb '16, 07:05) sindy

Well the part I was talking about was the statistics part (based on experience I got while trying to fix some bug). I've never worked with the "jump to next anomaly" part (I don't normally work with the VoIP stuff).

(12 Feb '16, 07:23) JeffMorriss ♦

FWIW the bug I'm thinking about is bug 10665.

(12 Feb '16, 07:57) JeffMorriss ♦