WebRTC softphone audio dropout during Zendesk widget migration

Voice & Telephony
1

Just noticed that the WebRTC softphone audio cuts out every 12 seconds when agents click the ‘Transfer’ button in the new Genesys Cloud agent desktop.

We are migrating from Zendesk Talk to Genesys Cloud, and the Zendesk widget used to handle transfers via simple API calls that didn’t touch the media stream. In Genesys, the Architect flow handles the transfer by updating the interaction context, but the softphone client (version 2023.11.0) seems to drop the WebSocket connection for the audio track. The browser console logs a ‘WebSocket connection failed: 1006’ error right when the transfer API returns a 202 Accepted. The network tab shows the STUN server connection is fine, and the initial call setup works perfectly. This happens in Chrome 118 on Windows 10. We are using the default Genesys Cloud softphone config, not a custom SIP setup. In Zendesk, the agent just clicked a button and the ticket status changed, but here the media session seems to reset. Is there a specific timeout setting in the Admin console for WebRTC session persistence during state changes? Or do we need to adjust the Architect flow to keep the media stream alive while the transfer logic runs? The logs show no errors in the Architect flow itself, just the client-side disconnect.

2 
"mediaConfig": { "transportPolicy": "relay", "audioCodec": "opus" }

The Zendesk widget migration likely bypassed the STUN/TURN fallback logic. Enforcing relay ensures media traverses the Genesys Cloud edge servers consistently. This prevents ICE candidates from dropping during context switches, which is critical when moving from simple API handoffs to full Architect-driven media streams.

3

You should probably look at at the specific interaction attributes being passed during the transfer. The mediaConfig snippet above handles the transport, but if the Zendesk widget migration left stale interaction context, the WebRTC client might be trying to resume a stale session.

In our Terraform deployments, we explicitly define the transfer behavior to ensure clean handoffs. The softphone dropout usually indicates the client is waiting for a new media stream that never initializes because the previous session wasn’t terminated correctly.

Add this to your transfer flow configuration:

{
 "interactionAttributes": {
 "transferType": "blind",
 "terminatePrevious": true
 }
}

This forces the Genesys Cloud platform to kill the old media leg before establishing the new one. It prevents the WebSocket hang. Check the Architect flow settings. The terminatePrevious flag is critical here. Without it, the softphone holds the old connection while waiting for the new one, causing the 12-second gap.

4

I normally fix this by verifying the timestamp alignment between the platform metrics and the BYOC provider logs, as Genesys Cloud records attempts in UTC while Singapore BYOC trunks often log in SGT…