SRTP Decryption Failures — VoIP Security Metric
Detect SRTP decryption failures per endpoint per second. Identifies encryption key mismatches, cipher suite incompatibilities, and security configuration errors in SIP infrastructure.
SRTP Decryption Failures
| Property | Value |
|---|---|
| Key | srtp_decrypt_failures |
| Unit | Count |
| Type | Cumulative counter |
| Direction | Receive |
| RFC | RFC 3711 (SRTP) |
What It Measures
SRTP Decryption Failures counts the number of received RTP packets that failed SRTP decryption. Each failure means a media packet arrived but could not be decrypted — the audio or video data is unrecoverable for that packet.
This metric is only active when SRTP encryption is enabled (SDES-SRTP or DTLS-SRTP mode). In unencrypted calls, the value is always zero.
Why It Matters
SRTP decryption failures are a definitive indicator of encryption misconfiguration. Unlike packet loss (which has many causes), decryption failures have a narrow set of causes — all related to key management or cipher suite negotiation. A single decryption failure means the security handshake succeeded (keys were exchanged) but something went wrong during media decryption.
For carriers testing encrypted trunk deployments and enterprises validating SIP-over-TLS infrastructure, this metric is the fastest path to identifying security layer issues that would otherwise manifest as silent audio or one-way media.
Thresholds
| Level | Value | Meaning |
|---|---|---|
| Good | 0 | Encryption is working correctly |
| Warning | 1 - 5 | Intermittent decryption issues — investigate key rollover or SSRC changes |
| Critical | Above 5 | Sustained decryption failures — media quality severely impacted |
What Causes SRTP Decryption Failures
- SSRC change without re-keying. When the SSRC changes mid-call (hold/resume, re-INVITE), the SRTP context may need to be re-established. If the new SSRC uses the old key context, decryption fails.
- Cipher suite mismatch. Both sides negotiated SRTP, but one side is using a different cipher suite than the other expects.
- Key lifetime exhaustion. SRTP keys have a maximum lifetime (defined by the MKI in SDES or the DTLS session). If the key expires mid-call without renegotiation, subsequent packets fail.
- SBC key stripping. Some SBCs terminate and re-originate SRTP. If the re-origination introduces a key mismatch, decryption fails on the far side.
How to Fix It
- Check SSRC consistency. Compare with SSRC Switches — if both spike simultaneously, the SSRC change is disrupting the SRTP context.
- Verify cipher suite negotiation. Inspect the SDP for
cryptoattributes (SDES) or DTLS fingerprint (DTLS-SRTP). Both sides must agree. - Test with SDES vs DTLS separately. Run the same test with each mode to isolate which encryption method is failing.
- Check SBC SRTP passthrough. If an SBC sits between endpoints, verify it either passes SRTP through transparently or correctly re-encrypts.
Related Metrics
- DTLS Rehandshakes — DTLS session renegotiation events
- SSRC Switches — Stream identifier changes that may disrupt SRTP context
- Packet Loss Rate — Decryption failures compound with network loss
- MOS Score — Decryption failures directly degrade perceived quality