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

Relation between packets and sequence number + know the moment of packet lost

0

Hi, I can't understand the relation between packet and sequence, because when I go to analyse the RTP packets with the option RTP stream analysis, in the column paket starts the packet with the number 33 and the seq number with the number 38761, but if I continue analysing, in the packet 29146 has the number of sequence equal to 0. I attached a picture with two captures of the same analysis in order to be able to see what i want to say better.

Another doubt that I have is: How I can know, in wich moment of the communication had a lost packet? Because with these analysis I can see that I have 5 packets lost, but I don't know in wich moment this happened.

Thanks alt text

asked 06 Nov '12, 01:06

Vickynp123's gravatar image

Vickynp123
1447
accept rate: 0%

edited 06 Nov '12, 01:09


One Answer:

1

The RTP sequence number is a 16 bit value. So, you will get an wrap-around at 65535 for a long session. That caused problems with all sorts of VoIP clients in the past.

Because with these analysis I can see that I have 5 packets lost, but I don't know in wich moment this happened.

did you check the "Expert Info"?

Analyze -> Expert Info

I'm not sure if the RTP dissector adds messages if it detects packet loss (if it detects it at all).

If there is nothing in the Expert Info, you would have to analyze the RTP sequence number with an external script, by using tshark

tshark -r input.cap -T fields -e frame.number -e rtp.seq

Then analyze the output of tshark with a script to find lost packets (missing RTP sequence number).

Regards
Kurt

answered 06 Nov '12, 01:22

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 06 Nov '12, 01:26

Hi, thanks for your answer. I checked the "Expert Info" but there are nothing from the rtp messages, so I have used the command that you told me "tshark -r input.cap -T fields -e frame.number -e rtp.seq" I understand that supposedly if there are a packet lost, there will be a jump in a seq number, will not?
So, I can't understand the big jumps that are in the capture (supposedly only there are 15 lost packets) and the repetition of some of them. I attached a capture that shows what i'm saying.alt text

(06 Nov '12, 17:44) Vickynp123

Now i see that the "big jump" is because it depends from which source comes, so the communication between PC(A)-->PC(B) have different seq number that PC(B)-->PC(A). But if i was correct in how detect the lost packets (jump in a seq number) i checked and i don't have any jump, and it have to be 15 jumps (15 packets lost). I can't understand why I don't have any jump :P.

(06 Nov '12, 19:45) Vickynp123

is it possible to post the complete capture file somewhere?

(06 Nov '12, 23:42) Kurt Knochner ♦

Yes, I have uploaded it in dropbox : https://www.dropbox.com/sh/291mn57h9ues5lh/GLzFUz7cmX I was trying to upload it in cloudshark.org but was impossible because the file exceed the 10Mb.

(07 Nov '12, 01:19) Vickynp123

O.K. if you repeat the following steps, you will find the missing seq numbers pretty easily (you must have missed them in your analysis).

  • Telephony -> RTP -> Show all Streams
  • Select the first stream (the one with the 15 lost packets) and click on the button Analyze

In the pop-up window, click on the button Save as CSV and save the analysis into a file.

Open the file with an editor and search for this string: Wrong sequence nr

You will find the first entry at frame #1683. This frame contains seq nr. 52493. The previous frame contains seq nr. 52490. So, seq nr. 52491 and 52492 are missing in that sequence.

Repeat the search until you have found all occurrences.

Regards
Kurt

(07 Nov '12, 07:38) Kurt Knochner ♦

Thanks very much!!

(07 Nov '12, 17:32) Vickynp123

Thanks very much!!!

(07 Nov '12, 18:04) Vickynp123

If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(08 Nov '12, 00:25) Kurt Knochner ♦
showing 5 of 8 show 3 more comments