1

I have several transport stream videos which are encapsulated within a PCAP file. It is known that they have packet losses. I would need to know a way to detect all of these losses. The protocols used are: Ethernet, IP, UDP, RTP and finally TS (Transport Stream). Do you know if there's any flag or field to detect the losses? I know that there are some fields like the sequence number that could allow me to know that information. Nonetheless, I can't see any jump in any sequence number.

I am using WireShark, do you know whether it exists a more suitable tool just to analyze the packet losses? Here you have the PCAP file I am using: https://drive.google.com/file/d/1vdyBYlUl0P9LXNshf_jISPkCP6_Mxlev/view?usp=sharing

user9013612
  • 11
  • 1
  • 3
  • Your capture file only contains UDP packets. How exactly did you check sequence numbers??? – pchaigno Feb 14 '18 at 09:02
  • @pchaigno It's time to learn magic of "Decode as" functionality. – nnovich-OK Feb 14 '18 at 16:24
  • @nnovich-OK Thanks for the suggestion! Looks like a read a bit too quickly. – pchaigno Feb 15 '18 at 06:28
  • @pchaigno I havent read UDP sequence numbers because basically the don't exist. If you have a look at each packet information, you will notice that RTP protocol is used. Funnily enough, RTP sequence numbers don't show any jump. – user9013612 Feb 15 '18 at 09:23

2 Answers2

3

Did you try using Wireshark's "Analyze -> Expert Information"? (You can also view it by clicking on the little red circle in the lower-left corner of the status bar, although the color of the circle will vary depending on the highest error level present in the capture file.)

Edit: Expanded my original answer with more information below ...

You can also view the RTP statistics under "Telephony -> RTP -> RTP Streams", which lists 23 lost packets. "Telephony -> RTP -> Stream Analysis" also provides potentially useful information.

Another potentially useful way to view the data is to use the I/O Graph. For example, "Statistics -> I/O Graph". Disable anything being plotted and add a new one, something like this:

Enabled  Graph Name  Display Filter  Color  Style  Y Axis       Y Field  SMA Period
X        RTP Seq     rtp.seq         X      Line   MIN(Y Field) rtp.seq  None

You should see a rather straight diagonal line starting from the lower-left corner and ending at the top-right corner. Now change the Interval to 10ms and you'll see some sequence number gaps - for me, 3 gaps are easily observed, which are probably good indicators of where packet loss has occurred. For example, around 12:16:38, there's a gap and it can be seen that the RTP sequence # of 11634 is missing, which should be between Frames 10271 and 10272.

But if you want to more easily see where all the sequence number gaps are, then you probably want to export the Wireshark data into a spreadsheet program, such as Excel. For example:

  • Right-click on the RTP sequence number field of any packet and choose, "Apply as Column"
  • Export the file to CSV: File -> Export Packet Dissections -> As CSV...
  • Open the .csv file with your speadsheet program
  • Add a column whose contents is the difference between the RTP sequence number in the previous row and the RTP sequence number in the current row. For example, if the RTP sequence number is in column G, then the cell will contain =G2-G1-1. If you select the entire column first and use "Ctrl-Enter" instead of just "Enter" when you add the formula, the formula will be quickly applied to all rows. (You might have to clean up some of the extraneous data past the last valid row.)
  • Fix the first row of the new column by replacing the undefined value with a heading, such as "RTP Seq # diff".
  • Any value other than 0 represents a gap in RTP sequence numbers.
  • To more easily find all gaps, select the entire table and filter on this new column for all values other than 0 You should end up with a relatively small table that looks something like this:

No. AbsTime Time DeltaT Proto Length RTP Seq # RTP Seq # Diff 3405 16:33.7 2.199559 0.001005 MPEG TS 1370 4748 3 6505 16:35.7 4.203210 0.000139 MPEG TS 1370 7851 1 6631 16:35.8 4.287576 0.001001 MPEG TS 1370 7978 1 8781 16:37.2 5.728671 0.000102 MPEG TS 1370 10129 1 8855 16:37.3 5.781427 0.000254 MPEG TS 1370 10204 1 9476 16:37.7 6.213582 0.000816 MPEG TS 1370 10826 1 9728 16:37.9 6.389564 0.000634 MPEG TS 1370 11079 10 9981 16:38.1 6.572582 0.000978 MPEG TS 1370 11342 1 10271 16:38.3 6.774569 0.000796 MPEG TS 1370 11633 1 10311 16:38.3 6.803568 0.000995 MPEG TS 1370 11674 1 10979 16:38.8 7.268695 0.000068 MPEG TS 1370 12343 1 12361 16:39.7 8.186596 0.000177 MPEG TS 1370 13726 1

This should tell you where all the gaps are and how many packets were lost, which is just a sum of the last column, or 23, which exactly matches what Wireshark reported in the RTP analysis as lost packets.

Note: For anyone not familiar with decoding traffic on non-standard ports, in order to have Wireshark decode the UDP payload as RPT, you must use the "Decode As" feature as @nnovich-OK alluded to above. To do this, either select a UDP packet and right-click "Decode As", or choose "Analyze -> Decode As... -> + -> " and then set UDP port 4000 to be decoded as RTP by selecting RTP under the Current column.

Christopher Maynard
  • 5,702
  • 2
  • 17
  • 23
  • His packet capture contains only UDP packets. That said, even if it contained TCP packets, Expert Information wouldn't directly give him packet losses. – pchaigno Feb 14 '18 at 22:06
  • Maybe you should try the "Decode as -> RTP" feature first and then look at the Expert information before you start downvoting people. (Select packet, then right-click or choose "Analyze -> Decode As... -> + -> " and then set Current to RTP and click OK. Then go look at the Expert information as I suggested. You could try reading about RTP a bit too, e.g., https://en.wikipedia.org/wiki/Real-time_Transport_Protocol – Christopher Maynard Feb 14 '18 at 22:34
  • Oh, my bad. Thanks for the details! If you can add those to your answer, I can change my vote :-) – pchaigno Feb 15 '18 at 06:16
  • I've tried what you have said. However, I just see 821 errors in the stram, does it mean that 821 packets are lost? Would you manage to tell me how many packets were lost in the .pcap uploaded above? @ChristopherMaynard – user9013612 Feb 15 '18 at 09:18
0

This helped me,

  1. with WireShark first Stop the capture (after you have captured all you need/want),
  2. then go to Statistics -> Capture File Properties

A statistic for overall dropped packets is there - better than nothing. The same can be accomplished with dumpcap command as well

Tomasz Janicki
  • 69
  • 3