Sequence Number Resets
Count of RTP sequence counter restarts — indicates SRTP re-keying, SSRC changes, or stream interruptions during the call.
Sequence Number Resets
| Property | Value |
|---|---|
| Key | sequence_number_resets |
| Unit | Resets (count) |
| Type | Counter |
| Direction | Receive |
| RFC | RFC 3550 |
What It Measures
Sequence Number Resets counts the number of times the RTP sequence number counter restarts from a low value after having reached a higher value. In normal operation, the sequence number increments by one for each packet and wraps around naturally at 65,535 (the maximum for the 16-bit field). A reset is different from a natural wraparound — it is a sudden jump back to a low sequence number outside the expected progression.
Think of it like a page counter in a printer that suddenly resets to page 1 in the middle of a print job. The document continues, but something caused the counter to start over.
Why It Matters
Sequence resets are event markers that reveal structural changes in the media stream:
- SRTP re-keying — When SRTP rotates encryption keys, some implementations reset the sequence number as part of the new cryptographic context.
- SSRC changes — A new SSRC (synchronization source identifier) implies a new RTP stream with its own sequence space. If the receiver treats it as the same stream, the new starting sequence number appears as a reset.
- Stream restart — If the media encoder crashes and restarts, the sequence number starts from a random initial value per RFC 3550.
- Call transfer — A SIP REFER or re-INVITE that changes the media source introduces a new sequence number space.
A call with zero resets had an uninterrupted media stream with consistent encryption and identity. Multiple resets warrant investigation into what events triggered them.
How CallMeter Measures It
CallMeter monitors the RTP sequence number progression. When the sequence number drops to a value significantly lower than the current expected sequence (beyond what normal reordering or loss would produce), it is counted as a reset. The counter increments throughout the call.
Thresholds
This metric does not have fixed thresholds because resets are event-driven:
| Resets | Typical Interpretation |
|---|---|
| 0 | Clean, uninterrupted stream |
| 1 - 2 | SRTP re-key, call transfer, or SSRC change |
| 3+ | Investigate — multiple stream restarts unusual |
What Causes Sequence Resets
- SRTP key rotation — Periodic re-keying for security. The frequency depends on the SRTP configuration.
- SSRC collision resolution — RFC 3550 mandates SSRC change on collision, which starts a new sequence space.
- Encoder restart — Software crash or intentional restart of the media encoder.
- SBC or B2BUA intervention — Session Border Controllers that re-encode or re-packetize media may reset sequence numbers.
- Call transfer — New media source after a REFER or re-INVITE.
How to Fix It
- Correlate with call events. Match each reset against SIP signaling events (REFER, re-INVITE) and SRTP key rotation logs.
- Check SRTP configuration. If resets are frequent and regular, review the key rotation interval. Very short intervals cause unnecessary resets.
- Investigate unexpected resets. Resets without corresponding SIP events may indicate encoder instability or SBC issues.
- Monitor SSRC changes. Use sequence resets alongside Timestamp Jumps to confirm SSRC-level events.
Related Metrics
- Timestamp Jumps — Often co-occurs with sequence resets during stream restarts
- Sequence Jumps — Large forward discontinuities in sequence numbers
- Sequence Gaps — Loss events that may follow a reset as the receiver re-synchronizes
Out-of-Order Packets
Count of RTP packets arriving in the wrong sequence — indicates multipath routing, network instability, or QoS issues that cause audio glitches and video artifacts.
Sequence Number Gaps
Size of consecutive packet loss events — reveals burst loss magnitude that average loss statistics hide.