DTLS Rehandshakes — VoIP Encryption Stability Metric
Monitor DTLS-SRTP rehandshake events per call. Frequent rehandshakes indicate certificate issues, network instability, or security layer problems in encrypted VoIP deployments.
DTLS Rehandshakes
| Property | Value |
|---|---|
| Key | dtls_rehandshakes |
| Unit | Count |
| Type | Cumulative counter |
| Direction | Both |
| RFC | RFC 5764 (DTLS-SRTP), RFC 6347 (DTLS 1.2) |
What It Measures
DTLS Rehandshakes counts the number of times the DTLS session was renegotiated during a call. The initial DTLS handshake at call setup is not counted — only subsequent rehandshakes that occur during the active media session.
In a healthy encrypted call, DTLS rehandshakes should be zero. The initial handshake establishes the SRTP keys, and those keys are used for the entire call duration.
Why It Matters
DTLS rehandshakes interrupt media flow. During a rehandshake, both sides must exchange certificates, verify fingerprints, and derive new SRTP keys — a process that takes tens to hundreds of milliseconds. During this window, media packets may be queued, delayed, or dropped.
For carriers deploying DTLS-SRTP at scale, unexpected rehandshakes are a leading cause of intermittent audio drops that are extremely difficult to diagnose without this metric. The drops are brief (100-500ms), do not register as packet loss (the packets are delayed, not lost), and correlate with no visible network event.
Thresholds
| Level | Value | Meaning |
|---|---|---|
| Good | 0 | DTLS session stable throughout the call |
| Warning | 1 | Single rehandshake — investigate cause |
| Critical | 2+ | Multiple rehandshakes — security layer unstable |
What Causes DTLS Rehandshakes
- Certificate expiration during call. If the DTLS certificate expires mid-call, the remote side may trigger a rehandshake.
- NAT rebinding. When the NAT mapping changes (timeout, rebind), the DTLS session may be invalidated, forcing a new handshake.
- SBC failover. If traffic fails over to a backup SBC, the new path requires a fresh DTLS handshake.
- ICE restart. ICE connectivity checks that select a new candidate pair require DTLS renegotiation on the new path.
- MTU issues. DTLS handshake messages are larger than typical RTP packets. If they exceed the path MTU and fragment, the handshake may fail and retry.
How to Fix It
- Check NAT keepalive intervals. Ensure STUN keepalives prevent NAT mapping timeouts during the call.
- Use long-lived certificates. Short-lived or auto-generated certificates that expire during test runs cause unnecessary rehandshakes.
- Monitor ICE restarts. Compare with ICE Restarts — if both correlate, the rehandshake is triggered by ICE, not DTLS itself.
- Verify path MTU. Ensure the network path supports DTLS handshake messages without fragmentation.
Related Metrics
- SRTP Decryption Failures — Failures that may follow a botched rehandshake
- ICE Restarts — Connectivity changes that trigger DTLS renegotiation
- SSRC Switches — Stream changes during rehandshake
- Round Trip Time — Rehandshakes are impacted by RTT