SRTP negotiation failure with Ribbon SBC — cipher suite mismatch

Our Bold360 knowledge base articles aren’t being matched against the SRTP error keywords.

When agents search for ‘cipher suite mismatch’ in the knowledge panel, Bold360 returns zero results even though we have a detailed troubleshooting article. The knowledge base search engine doesn’t index technical terms containing special characters like hyphens.

In CIC, we used to resolve SRTP issues by editing the SIP trunk XML configuration directly on the IC server.

In Genesys Cloud, the SRTP cipher suite is configured in the trunk’s TLS/SRTP profile. But the UI only shows a dropdown with limited options. If your SBC requires a non-standard cipher, you may need Genesys Support to configure it via their backend console.

Across CCaaS vendors, SRTP cipher negotiation is handled differently:

• GC: Requires AES_CM_128_HMAC_SHA1_80 by default
• CXone: Supports both SHA1_80 and SHA1_32
• Five9: Uses carrier-managed SRTP, no customer configuration
• Talkdesk: Supports custom cipher profiles via support ticket

GC’s rigid default is the most secure but the least flexible.

SRTP Cipher Mismatch Troubleshooting

FWIW, here’s the step-by-step:

1. Capture a SIP INVITE from the Edge using the trunk diagnostics
2. Look at the SDP a=crypto line
3. Compare the offered cipher against your SBC’s supported list
4. If they don’t match, update the SBC profile

YMMV, but Ribbon SBCs often default to SHA1_32 which GC rejects.

If you use a low-code iPaaS, you can automate SRTP monitoring.

Our Workato recipe polls the trunk metrics API every 5 minutes. If the cryptoErrors counter increases, the recipe sends a Slack alert with the trunk name and the last 3 SIP traces. No coding required.

When SRTP fails, check if Chrome’s TLS settings are interfering.

I’ve seen cases where chrome://flags/#enable-tls13-early-data causes WebRTC DTLS negotiation issues that look like SRTP failures in the trunk logs. The symptoms are similar but the root cause is browser-side, not SBC-side.

The speech analytics engine can actually detect SRTP failures indirectly.

When SRTP negotiation fails, the call either drops or falls back to unencrypted RTP. If it falls back, the audio quality degrades and our keyword detection precision drops from 87% to 52%. A sudden drop in speech analytics accuracy across a specific trunk is a strong signal of SRTP issues.

My agents say their calls keep dropping when they try to transfer to an external number. Is the ‘SRTP’ thing the reason? I don’t understand any of the technical stuff above.

Under MiFID II, unencrypted RTP fallback is a violation. All financial advisory calls must be encrypted end-to-end.

If your trunk silently falls back from SRTP to RTP during a cipher mismatch, you are transmitting unencrypted financial conversations. Configure the trunk to REJECT the call rather than fall back. A dropped call is better than a compliance violation.

We A/B tested two trunk configurations: strict SRTP (reject on mismatch) vs permissive (fallback to RTP).

The 5% call failure rate on strict mode is acceptable because 100% encryption compliance is mandatory.