WebRTC Softphone Fails on Legacy Browsers During Migration

Hey everyone, I’ve run into a really strange issue with the WebRTC softphone during our Zendesk-to-GC migration. Agents using older Chrome versions cannot establish calls, unlike the reliable Zendesk Voice widget.

Environment:

• Genesys Cloud Edge (eu-west-1)
• WebRTC Client SDK v2.8
• Chrome 92 (Legacy requirement)

The connection drops immediately with a DTLS handshake failed error. Is this a known compatibility issue with older browser stacks compared to Zendesk’s fallbacks?

You might want to check at the WebRTC configuration settings in your Genesys Cloud environment, specifically the media transport parameters. The DTLS handshake failed error on Chrome 92 is a known issue related to deprecated cipher suites that were removed in later browser versions but are still required for compatibility with older stacks during migration periods.

Here is a checklist to resolve this without forcing an immediate browser upgrade for all agents:

• Update the WebRTC Client SDK: Ensure you are using the latest patch of v2.8 or consider v2.9 if available. The SDK includes fallback mechanisms for older DTLS implementations. Check the release notes for “legacy browser support” patches.
• Adjust Edge Settings: In the Genesys Cloud Admin portal, navigate to Admin > Communications > WebRTC. Look for the “Media Transport” settings. Ensure that “Legacy DTLS Support” is enabled if your organization uses a custom Edge deployment. This allows the edge to negotiate with older cipher suites like TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
• Force Specific Cipher Suites: If you are using a custom configuration or Terraform, explicitly define the allowed cipher suites to include those supported by Chrome 92. For example:

{
"dtls": {
"cipherSuites": [
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
]
}
}

• Audit Trail Impact: Remember that changing media transport settings can affect the metadata recorded in bulk export jobs. Verify that the chain of custody for legal discovery requests remains intact by testing the export of a test call after the change. The recording_id and session_id must still map correctly to the agent’s interaction history.

Testing this in a non-production environment first is crucial to avoid disrupting live operations. The migration from Zendesk often exposes these legacy dependency issues, so documenting the fix in your audit trail is essential for compliance.

The easiest fix here is this is to verify if the load balancer is terminating DTLS before it reaches the Genesys Cloud edge, as Chrome 92 might be hitting a rate limit during the handshake retry loop.

“The connection drops immediately with a DTLS handshake failed error.”

Check the /api/v2/platform/webhooks for any spikes in connection attempts; sometimes the issue isn’t the browser but the throughput limits on the WebSocket channel getting saturated by failed handshakes.

If I remember correctly, Chrome 92 dropped support for certain DTLS cipher suites used by older WebRTC stacks. This usually breaks the handshake before media flows. Try forcing TLS 1.2 via policy or updating the SDK to v2.9, which handles legacy cipher negotiation better.