2026-06-03

RTP Sequence Number Wraparound: Loss Analysis Guide

Diagnose RTP sequence-number wraparound without false packet-loss alarms: inspect 16-bit rollover, extended sequence tracking, SSRC, timestamps, reordering, and RTCP evidence.

An RTP sequence-number counter changing from 65535 to 0 is expected protocol behavior, not evidence that a camera stream dropped 65,536 packets. The RTP header sequence field is 16 bits wide, so a long-running stream must roll over. A false packet-loss spike at that boundary usually means that an analyzer, gateway, archive, or dashboard compared raw 16-bit values as ordinary signed or ever-increasing integers.

The safe diagnosis is evidence-led: examine the packets immediately before and after the boundary, calculate continuity modulo 65,536, confirm stream identity with SSRC and payload type, compare RTP timestamp cadence, and consult RTCP reports where available. RTSP Inspector can preserve the protocol evidence in a case, but it should not be used to invent a network failure that the capture does not show.

This guide explains what normal rollover looks like, how real loss can occur at the same time, and how to write a defensible conclusion for a camera, NVR, gateway, or monitoring team.

The protocol fact behind the alarm

The RTP sequence number increments for each RTP packet sent by one source. Because the field contains only 16 bits, it wraps after 65535:

For a single continuing RTP source, that sequence is normal. A receiver needs rollover-aware continuity logic. It may retain the raw header value for evidence, but its loss and ordering calculations should use a conceptual extended sequence number: increment a higher-order cycle when a verified forward rollover occurs.

The exact elapsed time before rollover is not a fixed number of minutes. It depends on packet rate, not simply frame rate. H.264 or H.265 video may emit many RTP packets for one large frame, especially with a smaller MTU or heavily fragmented keyframes. Audio and video use separate RTP streams and can roll over on very different schedules.

Observation	Normal rollover likely	Actual loss or another event more likely
Raw sequence values	`65535` followed by `0`	A value is absent in the expected modulo sequence
SSRC	Unchanged	New SSRC or a source restart
RTP timestamps	Continue at expected cadence	Large unexplained timestamp discontinuity
Payload type	Unchanged	Payload type or SDP mapping changes unexpectedly
RTCP evidence	No corresponding loss increase	Receiver report shows loss in the same interval
Media result	No visible interruption	Missing frame, decoder error, or audio gap

No one row is a complete diagnosis. The pattern across rows matters. For example, a rollover plus an SSRC change is not merely a rollover; it may be a camera encoder restart or source replacement.

Why raw-number comparison fails

A naïve counter computes current - previous. At the boundary that becomes 0 - 65535, which looks like a huge negative jump. Other faulty implementations sort packets by raw sequence value, placing packets numbered 0, 1, and 2 before packets numbered 65534 and 65535. Both errors make a healthy long stream look disordered.

Rollover-aware tracking needs a small amount of context. It should distinguish a likely forward rollover from out-of-order arrival, a late duplicate, or a restart. That means sequence values must never be interpreted alone. Arrival time, expected next value, a reordering window, and SSRC all matter.

Do not “fix” the finding by discarding packets around 65535. That erases the exact evidence needed to tell a false alarm from real loss. Preserve a short window before and after the transition in the case file instead.

A repeatable RTP wraparound investigation

Use the following procedure with an RTSP capture. It is deliberately narrow: the goal is to answer whether this particular loss event is real, not to diagnose every camera problem at once.

1. Identify one RTP stream

Start with the RTSP control session and identify the media track, negotiated transport, payload type, and clock rate from SDP. Then filter the matching RTP stream by SSRC. If interleaved RTP is carried over TCP, keep the RTSP conversation with it; if it uses UDP, retain both media directions when possible.

The RTSP connection guide helps establish the control-side context. A packet sequence without the corresponding track information is much easier to misattribute when a device carries audio and video simultaneously.

2. Locate the boundary and keep surrounding packets

Find the event where raw sequence 65535 is followed by a small value. Keep at least several packets on each side, plus the nearest relevant RTCP sender or receiver report. Do not trim to only two headers: frame fragmentation and reordering can require more context.

Record the capture timestamps, raw sequence values, extended interpretation, SSRC, payload type, RTP timestamps, marker-bit state, and arrival order. RTSP Inspector case replay is useful for preserving this narrow evidence window for another engineer without sending a whole multi-hour capture.

3. Test forward continuity modulo 65,536

For a simple in-order run, the expected next value after 65535 is 0. After 0, it is 1. A missing number at the boundary can be real loss: 65534, 65535, 1 means raw sequence 0 is absent unless another packet arrived late or through a different observed path.

Do not make a loss finding until you have checked whether the supposedly missing packet is in the capture out of order. A reordering window should be applied before declaring a gap. Capture placement matters here: a trace taken on one congested interface may see a different arrival order than the endpoint.

4. Verify stream identity

Same SSRC, same payload type, a sensible timestamp progression, and no RTSP reconnect strongly support normal rollover. A changed SSRC means a new source identity and generally starts a new sequence space. It may coincide with rollover by chance, but it should not be silently merged with the old stream.

Use the SSRC change troubleshooting guide when the source identity changes. Use the RTP timestamp drift guide when sequence is continuous but media pacing appears wrong. These are separate hypotheses with different evidence.

5. Read timestamps and marker bits in context

RTP timestamps describe media timing in the negotiated clock domain; they are not wall-clock arrival timestamps. A normal sequence rollover should not itself create a timestamp jump. For video, look at the RTP marker bit together with packetization: a marker transition near a frame boundary can be normal, while a missing fragment within a frame can explain a visible decoder artifact.

The RTP marker-bit frame-boundary guide describes why marker bits are supporting evidence, not an independent loss counter. For camera streams, timestamp, marker, payload format, and decoder result should be read together.

6. Compare RTCP without treating it as magic

RTCP receiver reports can corroborate loss and jitter observed by the receiver. They are valuable because they represent endpoint-side accounting, but they may arrive less frequently than RTP and can be absent in some captures. If a receiver report does not show a loss increase while your dashboard reports tens of thousands of missing packets precisely at rollover, the dashboard calculation deserves suspicion.

Conversely, an RTCP loss increase, a missing raw sequence number after reordering is considered, and a visible artifact create a much stronger real-loss finding. Preserve the report's timing and source rather than reducing it to a single percentage.

Distinguish rollover, reordering, duplication, and restart

The same raw sequence values can mean different things depending on stream context.

Pattern near the boundary	Likely interpretation	Next evidence to check
`65535`, `0`, `1`, same SSRC	Normal forward rollover	Timestamp cadence and no media interruption
`65535`, `1`, same SSRC	Possible missing `0`	Reordering window, RTCP loss, frame impact
`0` then late `65535`	Late packet or capture-order reordering	Arrival timestamps and duplicate policy
`65535`, `0`, new SSRC	Source restart or switch	RTSP reconnect, SDP, encoder logs
Repeated values with same SSRC	Duplicate packets	Arrival time and payload equality
Abrupt lower values far from boundary	Counter reset or another source	SSRC, reconnect, device restart

This table is intentionally conservative. A packet capture establishes what was visible at the observation point. It cannot prove an upstream packet was never sent unless capture position and coverage justify that conclusion.

Failure modes in analyzers, gateways, and archives

Sequence rollover bugs often appear only after long uptime, which makes them expensive to reproduce. Short smoke tests pass because they never reach the boundary. Common implementation errors include sorting raw header values, using signed deltas, resetting jitter calculations when the sequence wraps, and treating a new SSRC as a continuation without documenting it.

For an archive or replay tool, keep both values: the exact 16-bit sequence value from the packet and a rollover-aware continuity value derived from the evidence. Presenting both lets an investigator check the conclusion later. A dashboard should also label whether “loss” comes from a direct observed gap, an RTCP report, or a heuristic; mixing those quantities hides uncertainty.

When a long stream fails only at rollover, preserve the case and run it through the same analyzer version in a test environment. RTSP Inspector reports can help structure a handoff around observed evidence, affected stream, time window, and conclusion rather than a vague “camera dropped packets” report.

FAQ: RTP sequence-number wraparound

Is RTP sequence wraparound a protocol error?

No. The 16-bit RTP sequence field must wrap. It becomes an error only when a receiver or analyzer treats the expected rollover as an impossible gap, reset, or massive loss event.

Can packet loss occur exactly at wraparound?

Yes. Rollover does not protect packets from loss. Test for the expected modulo next value, apply a reordering window, and corroborate with timestamps, marker-bit/frame evidence, and RTCP before concluding that the absent number represents loss.

Does a new SSRC mean sequence wraparound?

No. SSRC identifies the source within an RTP session. A new SSRC is a different stream identity or a restart condition that needs its own analysis. Do not simply extend the former sequence counter across it.

Why does the graph show a jitter spike at 65535?

The media may be stable while the graphing code uses raw sequence arithmetic or resets its state at rollover. Compare actual arrival timing, RTP timestamps, and the recorded media behavior before calling it network jitter.

Conclusion: write the finding at the right confidence level

RTP sequence wraparound is normal; false loss alarms are not. A defensible conclusion names the observed stream, notes the raw transition from 65535 to 0, records SSRC/payload/timestamp continuity, states whether a reordering window was applied, and distinguishes an observed gap from a software-accounting defect.

Use RTSP Inspector to keep the RTSP setup, RTP evidence, and replayable case together. If the stream has a visible interruption as well as a sequence anomaly, continue with the RTSP troubleshooting guide rather than assuming the rollover itself is the root cause.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: