Troubleshooting SRTP Key Negotiation Failures Causing Silent Calls

How-To-Articles
1

Troubleshooting SRTP Key Negotiation Failures Causing Silent Calls

Executive Summary & Architectural Context

One of the most elusive and frustrating issues in a secure voice environment is the “Silent Call.” The symptoms are always the same: an agent answers a call, they say “Hello?”, but there is no sound. The caller is also saying “Hello?”, but they hear only dead air. Both sides stare at their timers for ten seconds, waiting for a connection that never arrives, before hanging up in frustration. The network team looks at their monitors and says, “The UDP packets are moving between the Edge and the SBC; the network is fine.” The voice team looks at the SIP logs and says, “The call was answered with a 200 OK; the telephony is fine.”

A Principal Architect knows that if packets are moving but there is no audio, you are likely facing an SRTP (Secure Real-time Transport Protocol) Key Negotiation Failure. In a secure trunk, the audio isn’t just “sent”; it is “locked” with a cryptographic key. That key is exchanged during the SIP handshake. If the two sides don’t agree on the “Crypto Suite” (the lock type) or if the “Key Material” is corrupted in flight, the receiver will have the packets but won’t be able to “Unlock” them. The result is a stream of encrypted noise that the platform’s audio engine treats as total silence.

This masterclass details how to diagnose SRTP negotiation failures, interpret cryptographic mismatches in SIP logs, and resolve the “Silent Call” epidemic in your secure contact center.

Prerequisites, Roles & Licensing

Licensing & Permissions

  • Licensing Tier: Genesys Cloud CX 1, 2, or 3 with SRTP enabled.
  • Granular Permissions:
    • Telephony > Trunk > View, Edit
    • Telephony > Edge > Logs
  • Dependencies:
    • Packet Capture Tool: Wireshark or the Genesys Cloud Edge log viewer.
    • SBC Access: Ability to view the SIP and Media profiles on your carrier gateway.

The Implementation Deep-Dive

1. The Anatomy of the Key Exchange (SDES)

In most Genesys Cloud environments, SRTP keys are exchanged using SDES (Session Description Protocol Security Descriptions). The key is sent in plain text (protected by TLS) inside the SIP message.

The “a=crypto” Line:
Inside the INVITE, you will see a line like this:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WfJra093cm9tS21zZStSOTY3d2NxS0p0eS9Sdz0K

  • 1: The tag (priority).
  • AES_CM_128_HMAC_SHA1_80: The Crypto Suite (the “Lock Type”).
  • inline:WfJra...: The actual base64-encoded Master Key.

2. Identifying the “Crypto Suite” Mismatch

The #1 cause of SRTP silence is a mismatch in the Authentication Tag Length.

The Trap: The 32 vs 80 Conflict

The standard for secure voice is HMAC_SHA1_80 (an 80-bit tag). However, some older SBCs or regional carriers default to HMAC_SHA1_32.

  • The Failure: If the Genesys Edge sends an INVITE offering only “80,” and the SBC responds with only “32,” the negotiation fails.
  • The Result: The SIP call might still connect (because some platforms treat SRTP as “Optional”), but the audio engine won’t be able to decrypt the packets because it’s using the wrong tag length to verify the packets. It sees the audio as “Corrupt” and drops it-leaving the agent in silence.

The Solution: The “Offer Both” Strategy

  1. In the Genesys Cloud SIP Trunk settings, navigate to Media Encryption.
  2. Ensure that you have enabled both AES_CM_128_HMAC_SHA1_80 and AES_CM_128_HMAC_SHA1_32 in the “Allowed Suites” list.
  3. This allows the Edge to negotiate the highest common denominator, ensuring a successful “Lock” on every call.

“The Trap”: NAT-Induced Key Corruption

The Scenario: You have verified that both sides agree on the Crypto Suite. Calls are still silent. You take a PCAP and notice that the a=crypto line in the 200 OK from the SBC is slightly different than what the SBC thinks it sent.

The Catastrophe: A “SIP-Aware” Firewall or NAT device in the middle is attempting to “Fix” the SIP packet.

The root cause: Some firewalls have a feature called SIP ALG (Application Level Gateway). When it sees an IP address inside the SIP packet, it tries to change it to match the NAT’s public IP. In doing so, it occasionally miscalculates the “Content-Length” of the packet or accidentally mangles the base64-encoded SRTP key. If even one character of the inline: key is changed, the “Key” is broken, and the audio cannot be decrypted.

The Principal Architect’s Solution: The “TLS-Only” Defense

  1. Encrypt the Control Path: Switch your SIP trunking from UDP to TLS.
  2. Why? Firewalls cannot “Inspect” or “Modify” TLS-encrypted SIP packets. By hiding the a=crypto line inside a TLS tunnel, you prevent the firewall from “Helping” (and ultimately breaking) your key negotiation. This is the only guaranteed way to ensure the key material arrives at the Edge exactly as the SBC sent it.

Advanced: Troubleshooting “Mid-Call” Key Changes

The failure condition: The call starts perfectly. 30 seconds in, when the agent puts the customer on hold and then resumes, the audio disappears.

Implementation Detail:
When a call is put on hold, the system often sends a re-INVITE. In a secure environment, this re-INVITE might contain a New SRTP Key.

  1. If your SBC is not configured to handle “Late Media” or “Key Refresh,” it might ignore the new key and keep trying to use the old one.
  2. The Fix: Ensure the “Unsecured to Secured” and “Key Update” settings are enabled in your Trunk’s “Media Security” section. This allows the system to smoothly transition to new keys during mid-call events like transfers or music-on-hold.

Validation, Edge Cases & Troubleshooting

Edge Case 1: One-Way Silence

The failure condition: The agent can hear the customer, but the customer cannot hear the agent.
The root cause: Asymmetric negotiation. The SBC accepted the Edge’s key (Inbound), but the Edge rejected the SBC’s key (Outbound) because the SBC offered a suite that wasn’t in the Edge’s “Allowed” list.
The solution: Check the SIP 488 Not Acceptable Here response code in your logs. If you see this after an INVITE, it means the security suites were incompatible.

Edge Case 2: RTCP Encryption Mismatch

The failure condition: The audio is fine, but the platform’s “Real-Time Health” metrics (Jitter/Packet Loss) are showing 0% or N/A.
The root cause: SRTP also encrypts the RTCP (Control Protocol) packets. If the “Encrypted RTCP” flag is set on one side but not the other, the health data cannot be read.
The solution: Ensure the “SRTCP” (Secure RTCP) toggle matches on both the SBC and the Genesys Trunk configuration.

Reporting & ROI Analysis

Silent calls are the “Silent Killer” of customer satisfaction scores.

Metrics to Monitor:

  • Zero-Audio Interaction Rate: Percentage of calls where the RTP_Packets_Received > 0 but the RTP_Volume_Level remains at a baseline.
  • SIP 488 Error Rate: Frequency of security negotiation failures.
  • AHT (Short Calls): Percentage of calls ending in < 15 seconds (a classic indicator of “Silent Call” hang-ups).

Target ROI: By eliminating SRTP negotiation failures, you reduce your Silent Call Rate to < 0.1%, instantly improving your Net Promoter Score (NPS) and ensuring that every answered call results in a meaningful interaction.

Official References