wrong sequence

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.

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.