RTP Sequence Number Wraparound Debugging: 16-bit Rollover, False Packet Loss, Jitter Spikes, and Long Camera Streams

RTP sequence numbers are 16-bit values. They eventually wrap from 65535 back to 0. Users search for "RTP sequence number wraparound", "RTP false packet loss", "RTSP jitter spike after one minute", "RTP sequence rollover", and "camera stream packet loss alarm wrong" when a long-running stream suddenly appears to lose thousands of packets.

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 is a strong SEO topic 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.