RTP Sequence Number Wraparound Debugging

A long-running camera stream that reports thousands of “lost” RTP packets exactly as sequence 65535 rolls to 0 may have an analyzer bug, not a network outage. Evaluate sequence numbers modulo 16 bits, alongside SSRC, timestamp, arrival order, duplicates, and the few packets surrounding rollover. The capture can distinguish valid RTP sequence wraparound from real gaps and reordering; it cannot correct downstream counters that expanded the sequence number incorrectly.

RTSP Inspector is useful because this is a media-header accounting problem. The stream may be healthy, but the analyzer, gateway, or monitoring logic may treat rollover as loss.

What wraparound looks like

Normal RTP sequence progression near rollover looks like:

65533
65534
65535
0
1
2

That is not a gap. It is expected 16-bit rollover.

If a tool calculates 0 - 65535 as a huge negative jump or treats it as missing packets, it will report false loss.

Common symptoms

Wraparound bugs show up as:

• Packet loss spikes at regular intervals.
• Jitter graph jumps suddenly.
• Recording marks a healthy stream as unstable.
• RTP replay stops at sequence 65535.
• Analyzer reports negative sequence delta.
• Gateway resets statistics incorrectly.
• Long streams fail while short tests pass.

This case matters because many test streams are too short to expose the bug.

How fast rollover happens

Rollover timing depends on packet rate. A high bitrate video stream with many RTP packets per second can wrap relatively often. Low bitrate audio wraps much later.

Factors:

• Frame rate.
• Resolution.
• Bitrate.
• Fragmentation.
• MTU.
• Codec.
• Whether audio and video are analyzed separately.

If an H.264 keyframe is heavily fragmented, sequence numbers advance faster.

Loss vs rollover

A real loss near rollover is possible, so the analyzer must handle both cases.

Compare:

• Expected next sequence modulo 65536.
• Payload continuity.
• RTP timestamp continuity.
• Marker bit behavior.
• SSRC continuity.
• RTCP receiver reports.

If SSRC, timestamp, and payload cadence continue normally, rollover is likely benign.

SSRC changes are different

Do not confuse sequence wraparound with SSRC change. When SSRC changes, a new sequence space may start. When only sequence number wraps, the same stream identity continues.

Evidence:

• Same SSRC before and after.
• Same payload type.
• Same clock rate.
• Timestamp continues.
• No RTCP BYE.
• No RTSP reconnect.

That is sequence rollover, not source replacement.

Replay and archive bugs

Tools that archive RTP events can fail at wraparound if they sort by raw sequence number instead of extended sequence number.

Bad behavior:

• Packets after zero are sorted before older packets.
• Replay jumps backward.
• Loss calculation resets incorrectly.
• Exported evidence looks out of order.

RTSP Inspector should preserve raw sequence numbers but calculate continuity with rollover-aware logic.

Debug checklist

Use this process:

1. Find the sequence boundary near 65535.
2. Check next packets after zero.
3. Confirm SSRC stays the same.
4. Confirm payload type stays the same.
5. Compare RTP timestamp deltas.
6. Check marker bit around frame boundary.
7. Check RTCP loss reports.
8. Separate rollover from actual missing packets.
9. Preserve packets before and after rollover.
10. Test long enough streams, not only short samples.

Final diagnosis

RTP sequence wraparound is normal. False alarms happen when tools treat 16-bit rollover as packet loss or stream reset.

RTSP Inspector helps diagnose long-running camera streams by showing sequence continuity, SSRC continuity, timestamp behavior, and real packet-loss evidence across rollover.