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

wrong sequence

0

Hi, I am new in using Wireshark. I am capturing VoIP calls and I was wondering what happens to the Wrong sequnce packets. Are they dropped at the receiver's end? Are they calculated as part of the lost packets percentage? thank you in advance

asked 06 Jun '11, 08:41

Lefkothea%20Vaitsi's gravatar image

Lefkothea Va...
1333
accept rate: 0%

edited 06 Jun '11, 16:58

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142


2 Answers:

3

The nature of RTP transport over UDP is inherently unreliable. Unreliable for delivery and order. So, wrong sequence numbers are to be expected at the receiver side. For media playout the RTP packets have to be placed in order again in the jitter buffer and the payloads accessed in that order. Therefore Wronng Sequence != Lost Packet.

You should study Some Frequently Asked Questions about RTP, a really informative page.

answered 06 Jun '11, 12:53

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

Hi again, thanks for the answer, the FAQs are really helpful. Let me see if I got it right now. The lost packets percentage are those that never reached the receiver while the wrong sequence packets are lost as well due to the jitter buffer handling. For example if in a call I have total packets=3115, lost=117, seq errors=140 that means only 2858 packets were played at the receiver, 117 were lost on their way there and 140 were lost after reached the receiver. Is that right? Thanks and sorry for being such a pain.

(07 Jun '11, 03:05) Lefkothea Va...

1

Once they reach the receiver they are not lost, they're there! It's only that they are received in an unexpected order. Whether they are in time for playout is a whole different matter. That depends on how large the jitter buffer is.

Let say packet size is 20ms, jitter buffer is 20ms. The packets are received as such:

  1. Rx_time=0, seq=0, RTP_ts=0
  2. Rx_time=20, seq=1, RTP_ts=20

All is fine.

  1. Rx_time=40, seq=2, RTP_ts=40
  2. Rx_time=57, seq=4, RTP_ts=80
  3. Rx_time=60, seq=3, RTP_ts=60
  4. Rx_time=100, seq=5, RTP_ts=100

Here you see that RTP packet sequence number 4 overtook RTP packet sequence number 3 during transport, but is early enough at the receiver for playout. So this one is counted as sequence error, but cannot be considered lost or too late.

Lets continue.

  1. Rx_time=120, seq=6, RTP_ts=120
  2. Rx_time=160, seq=8, RTP_ts=160
  3. Rx_time=180, seq=9, RTP_ts=180
  4. Rx_time=190, seq=7, RTP_ts=140

Now RTP packet sequence number 7 is late. Assuming the Rx_time is the same timebase as used for the jitter buffer, you can see that RTP_ts + jitter buffer size < Rx_time for RTP packet sequence number 7. Therefore it is too late for playout. So this one is counted as sequence error, but cannot be considered lost, only too late.

The notion of 'too late' depends on the intelligence of the (usually adaptive) jitter buffer in the receiver. Since Wireshark it just a Man-in-the-Middle it cannot make that determination.

answered 07 Jun '11, 06:17

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

Thank you for your answer it is clear now. However, what confuses me is the Rx_time. I presume that the RTP_ts(time stamp)is the one I can see in the RTP stream analysis. thank you

(10 Jun '11, 08:20) Lefkothea Va...