Timestamp Jumps

What It Measures

Timestamp jumps counts the number of times the RTP timestamp makes an unexpected discontinuity — a sudden jump forward or backward that does not match the normal progression of media samples.

In normal operation, RTP timestamps increment at a predictable rate based on the codec's sampling frequency. For a G.711 audio stream at 8 kHz with 20ms packets, the timestamp advances by exactly 160 per packet. A timestamp jump occurs when this expected progression breaks — the next packet's timestamp is significantly different from what the codec clock rate predicts.

Think of it like a record skipping. The music was playing normally, then suddenly it jumps to a different part of the track. Each jump represents a moment where the media stream was disrupted.

Why It Matters

Timestamp jumps are diagnostic markers for stream-level events. They do not directly cause quality degradation (the media may resume perfectly after the jump), but they reveal what happened during the call:

• Call transfer (REFER) — When a call is transferred, the new media source has a different RTP timestamp base, causing a jump.
• Hold and resume — Putting a call on hold stops media, and resuming starts from a new timestamp position.
• Encoder restart — If the media encoder crashes and restarts, the timestamp resets.
• SRTP re-keying — Some SRTP implementations reset the RTP timestamp when rotating encryption keys.
• SSRC change — A new SSRC from the same endpoint implies a new timestamp epoch.

A call with zero timestamp jumps had an uninterrupted, stable media stream throughout. A call with multiple jumps experienced several stream disruptions that may or may not have been user-initiated.

How CallMeter Measures It

CallMeter monitors the RTP timestamp progression of incoming packets. When the actual timestamp differs from the expected timestamp by more than a codec-specific tolerance, it is counted as a jump. The counter increments throughout the call.

Thresholds

This metric does not have fixed thresholds because timestamp jumps are event-driven, not quality-driven. One jump during a call transfer is expected. Dozens of jumps with no corresponding user action may indicate a problem.

What Causes Timestamp Jumps

• Call transfer (REFER/INVITE) — Normal SIP operation that changes the media source.
• Hold and resume — Pressing hold stops media; resuming creates a timestamp discontinuity.
• Encoder crash or restart — Software or hardware encoder failure followed by recovery.
• SRTP re-keying — Periodic key rotation depending on the SRTP implementation.
• Gateway media switching — B2BUAs or media gateways that switch between media sources.
• SSRC collision handling — RFC 3550 requires SSRC changes on collision, which resets the timestamp epoch.

How to Fix It

Timestamp jumps are usually symptoms, not problems. To investigate:

1. Correlate with call events. Check the SIP signaling log for REFER, re-INVITE, or hold events that coincide with each jump.
2. Check encoder stability. If jumps occur without corresponding SIP events, the media encoder may be restarting unexpectedly.
3. Review SRTP configuration. Frequent re-keying intervals can cause unnecessary jumps. Evaluate if the re-keying frequency is appropriate.
4. Monitor SSRC changes. Use CallMeter's per-second timeline to see if jumps correlate with SSRC changes in the RTP stream.

Related Metrics

• Sequence Jumps — Similar discontinuities in the RTP sequence number space
• Sequence Resets — Full sequence counter restarts, often paired with timestamp jumps
• Clock Drift — Sudden clock corrections may appear as timestamp jumps
• Packets Lost — Brief loss events around timestamp jumps are normal during stream transitions