SSRC Switches — RTP Stream Stability Metric
Track SSRC (Synchronization Source) changes during a call. SSRC switches indicate stream restarts from hold/resume, re-INVITE, codec changes, or failover events.
SSRC Switches
| Property | Value |
|---|---|
| Key | ssrc_switches |
| Unit | Count |
| Type | Cumulative counter |
| Direction | Receive |
| RFC | RFC 3550 Section 8.2 |
What It Measures
SSRC Switches counts the number of times the SSRC (Synchronization Source identifier) changed on a received RTP stream during a call. The SSRC is a 32-bit random identifier that uniquely identifies an RTP stream. When it changes, it means the sender restarted its RTP session — all sequence numbers and timestamps reset.
Why It Matters
SSRC changes are expected during certain SIP operations: hold/resume (re-INVITE), codec renegotiation, and call transfer. But unexpected SSRC changes indicate problems — stream restarts due to crashes, failovers, or misconfigured SBCs that re-originate media.
Each SSRC change disrupts the receiver's jitter buffer, resets sequence number tracking, and may invalidate the SRTP encryption context. The result is a brief quality disruption (50-200ms of silence or artifacts) that is invisible to network-level monitoring but audible to users.
For teams testing hold/resume, codec change, and re-INVITE scenarios, this metric validates that the SIP infrastructure handles mid-call changes cleanly — with exactly the expected number of SSRC transitions and no extras.
Thresholds
| Level | Value | Meaning |
|---|---|---|
| Good | 0 (or matches expected scenario transitions) | Stream is stable |
| Warning | 1 unexpected switch | Investigate — may indicate an SBC re-origination |
| Critical | 2+ unexpected switches | Stream instability — likely failover, crash recovery, or misconfiguration |
How to Fix It
- Compare with your scenario. If your test includes hold/resume or codec change actions, expect one SSRC switch per action. Match the count against Scenario Actions Executed.
- Check SBC behavior. SBCs that anchor media may re-originate the RTP stream with a new SSRC. This is normal for B2BUA SBCs but indicates a restart if unexpected.
- Check for SRTP failures. If SSRC switches correlate with SRTP Decryption Failures, the encryption context is not surviving the SSRC transition.
- Monitor jitter buffer impact. After an SSRC switch, the jitter buffer resets. Check Jitter Buffer Current Delay for spikes following the switch.
Related Metrics
- SRTP Decryption Failures — SSRC changes may invalidate SRTP context
- DTLS Rehandshakes — DTLS may renegotiate after SSRC change
- Jitter — Spikes after SSRC switch as jitter buffer resets
- Hold Count — Expected SSRC changes from hold/resume