We have been troubleshooting an intermittent one-way audio issue on inbound calls for the past two weeks and I think we have finally narrowed it down to an SRTP negotiation problem on our BYOC Cloud trunk, but I need help understanding what exactly is going wrong.
The symptom: approximately 8% of inbound calls have audio flowing only from the agent to the caller. The caller can hear the agent perfectly, but the agent hears complete silence. The issue is not queue-specific or agent-specific - it happens randomly across all queues.
We captured a SIP trace on our SBC (AudioCodes Mediant 800B running 7.40A) and found something interesting. During the SDP offer/answer exchange, our SBC is offering:
m=audio 10000 RTP/SAVP 0 8 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:base64keyhere
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:base64keyhere
Genesys Cloud responds with:
m=audio 20000 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:differentkeyhere
Both sides agree on the cipher suite, but the one-way audio calls consistently show an SRTP authentication failure on the inbound RTP stream in the AudioCodes debug logs. The calls where audio works fine show no such errors.
Our SBC firmware is current. The trunk is configured for “Secure” media transport in GC. We are on US-West-2 (Oregon). Has anyone seen intermittent SRTP auth failures on BYOC Cloud trunks with AudioCodes SBCs?
We had almost the exact same issue with our AudioCodes setup about six months ago. The 8% failure rate was the clue that led us to the root cause.
The problem is related to SRTP key lifetime and re-keying. When your SBC offers two crypto suites (SHA1_80 and SHA1_32), Genesys Cloud always selects the first one (SHA1_80). But on approximately 1 in 12 calls, the AudioCodes Mediant has a known bug in firmware versions prior to 7.40A.258 where it initializes the SRTP session using the key material from crypto line 2 (SHA1_32) even though crypto line 1 was selected in the answer.
The fix is to remove the second crypto line entirely from the SBC configuration. In the AudioCodes admin:
- Go to Setup > Signaling & Media > Media Security
- Under SRTP Settings, change “Offered Crypto Suites” from “All” to “AES_CM_128_HMAC_SHA1_80 Only”
- Save and reset the trunk group
By offering only one crypto suite, you eliminate the possibility of the SBC selecting the wrong key material. Our failure rate dropped from roughly 8% to zero immediately after making this change.
Alternatively, if you need to keep both suites for other trunk connections, upgrade to firmware 7.40A.258.003 or later, which includes the SRTP key index selection fix.
The single crypto suite fix is correct. Just want to add a diagnostic shortcut for anyone else debugging SRTP issues on BYOC trunks.
Instead of pulling full SIP traces from the SBC, you can get the SRTP negotiation details directly from the Genesys Cloud conversation API:
GET /api/v2/conversations/calls/{conversationId}
In the response, look at participants[].sessions[].segments[].properties. The srtp.cipherSuite and srtp.status fields will tell you exactly what cipher was negotiated and whether the SRTP session was established successfully. A status of SRTP_AUTH_FAIL on the inbound leg confirms the key mismatch.
You can also build a real-time WebSocket monitor that subscribes to v2.conversations.calls.{id} and alerts on any conversation where the SRTP status is not ESTABLISHED. We built one that pings our Slack channel within seconds of a failed SRTP negotiation so we can proactively call the customer back instead of waiting for a complaint.