Hey everyone,
I’m currently navigating a Zendesk Talk to Genesys Cloud softphone widget migration and running into a persistent issue with the agent desktop handoff. Call recording completes without issue, but the WebRTC session drops the exact moment the Architect flow executes the external CRM write.
This is a stark contrast to our legacy setup. Zendesk Talk kept the audio bridge stable regardless of background queue jobs, whereas the GC softphone appears to stall the WebSocket keep-alive once the main thread blocks on the webhook handshake. It feels like the signaling thread is getting choked by the integration payload.
We’re on release 2023-06-01, running softphone widget v4.2.1 in Chrome 118 on Windows 11. The console immediately throws WebRTC: ICE connection state changed to failed, followed by a 429 Too Many Requests when the flow hits the “Push to Zendesk” node.
I scrolled through a community post from March about TURN relay exhaustion causing similar drops, so I checked our metrics. Our dashboard shows relay capacity sitting at 14%, so that’s not the bottleneck. Bumping the STUN timeout in the org settings is doing jack all. The routing profile matches the destination skill, and the agent is fully provisioned.
For anyone else in the migration trenches, here’s the temporary workaround I’ve implemented: inserting a 1500ms pause in Architect right before the Zendesk integration node fires. That keeps the signaling alive long enough for the payload to transmit. It works for UAT, but it’s a fragile patch for a live contact center, so I’m hoping for a cleaner fix.
The softphone relies on continuous bidirectional signaling, whereas the legacy Zendesk setup offloaded API calls to a separate worker process. Flow ID is flow-88a2c91e-4f3b-4d1a-9c21-77f0e4a1b2c4. The genesys-softphone.log shows the disconnect happening at timestamp 1698241200.
Has anyone else encountered this during a Zendesk-to-GC cutover? Any practical advice on decoupling the signaling from the webhook execution?