Media Encryption Issues

This page covers common issues when using encrypted SIP signaling (TLS) and encrypted media (SDES-SRTP, DTLS-SRTP). Each section includes the symptom, likely causes, and resolution steps.

TLS Handshake Failures

Certificate Expired

Symptom: Endpoint fails with "TLS handshake failure: certificate has expired" before any SIP message is sent.

Cause: The server's TLS certificate (or your uploaded client certificate) has passed its validity period.

Resolution:

1. Check the certificate expiration date in the registrar's TLS configuration
2. Renew the expired certificate and re-upload to CallMeter
3. If the server cert is expired, contact the SIP server administrator

Untrusted Certificate Authority

Symptom: "TLS handshake failure: certificate signed by unknown authority"

Cause: The SIP server uses a self-signed certificate or an internal CA that is not in the system trust store.

Resolution:

1. Obtain the CA certificate that signed the server's certificate
2. Upload it as the CA Certificate in the registrar's TLS configuration
3. Set the TLS verification mode to Custom

Hostname Mismatch

Symptom: "TLS handshake failure: certificate is valid for X, not Y"

Cause: The registrar domain does not match the Common Name (CN) or Subject Alternative Names (SAN) in the server's certificate.

Resolution:

1. Verify the registrar URI matches one of the names in the server certificate
2. If the server uses an IP address but the cert has a hostname (or vice versa), update the registrar URI to match the certificate
3. As a last resort, set TLS verification mode to Skip (not recommended for production testing)

mTLS Rejection

Symptom: Connection closes immediately after TLS handshake or server returns "bad certificate"

Cause: The server requires client authentication (mutual TLS) but the client certificate is missing, expired, or not trusted by the server.

Resolution:

1. Upload a valid client certificate and private key in the registrar's TLS configuration
2. Ensure the server's trust store includes the CA that signed the client certificate
3. Verify the client certificate has not expired

SDES-SRTP Issues

No Matching Cipher Suite

Symptom: Call fails with 488 Not Acceptable Here after SDP exchange.

Cause: None of the cipher suites offered in a=crypto lines match what the remote endpoint supports.

Resolution:

1. Check which cipher suites the remote endpoint supports (consult its documentation)
2. Ensure CallMeter is offering compatible suites (default: all three are offered)
3. If the remote only supports a specific suite, verify it is among the offered options

Unencrypted Fallback When Required

Symptom: Call connects but media is unencrypted despite SRTP policy being set to "Required."

Cause: The remote endpoint answered without a=crypto lines and the SRTP policy was set to "Offered" (not "Required").

Resolution: Change the SRTP policy from Offered to Required. With Required policy, the call will fail (rather than fall back to unencrypted) if the remote does not support SRTP.

DTLS-SRTP Issues

DTLS Handshake Timeout

Symptom: Call is established (SIP 200 OK received) but media never flows. Endpoint shows DTLS timeout error.

Cause: The DTLS handshake packets are blocked by a firewall or NAT device. DTLS uses the same UDP port as RTP, but the initial handshake packets look different from RTP and may be filtered.

Resolution:

1. Verify the firewall allows all UDP traffic on the media port range (not just RTP-shaped packets)
2. Check if a NAT device is timing out the UDP binding before the DTLS handshake completes
3. Enable RTCP-MUX to reduce the number of ports involved
4. If testing through an SBC, verify the SBC supports DTLS passthrough

Fingerprint Mismatch

Symptom: DTLS handshake fails with "remote certificate does not match fingerprint"

Cause: The certificate received during the DTLS handshake does not match the a=fingerprint attribute in the SDP. This can happen if an intermediary (SBC, B2BUA) modifies the SDP but does not update the fingerprint.

Resolution:

1. Check if an SBC or B2BUA sits between the endpoints and is modifying SDP
2. If using an SBC, configure it to either pass DTLS through transparently or terminate and re-originate DTLS with its own certificates
3. Inspect the SDP answer for matching fingerprint values

SRTP Authentication Failure

Symptom: Media packets are received but decoded as silence or noise. Quality metrics show 100% packet loss despite packets arriving.

Cause: SRTP keys were derived incorrectly, or one side is sending unencrypted RTP while the other expects SRTP.

Resolution:

1. Verify both endpoints agreed on the same encryption method (check SDP for consistent a=crypto or a=fingerprint)
2. If using dual offer (method 3), confirm the answerer's response uses the same method as the caller expects
3. Ensure no intermediary is stripping encryption attributes from the SDP

Diagnostic Checklist

Related Pages

• Media Security Overview — Compare encryption modes
• SDES-SRTP — SDES configuration guide
• DTLS-SRTP — DTLS configuration guide
• TLS Certificates — Certificate management