Stumbled on a weird bug today with our WebRTC softphone integration where agents lose connectivity exactly when traffic shifts to our secondary BYOC trunks in the Asia Pacific region. The initial WebSocket connection to the Genesys Cloud edge succeeds without issue, but the subsequent SDP negotiation fails silently after 45 seconds. This happens exclusively during peak hours when the primary carrier hits capacity and failover logic activates. The browser console shows a generic ‘Connection Lost’ event, but the server-side logs indicate a 408 Request Timeout on the media session establishment endpoint. We have verified that the SIP credentials and outbound routing policies are identical across all 15 trunks, yet the issue persists only on the backup paths.
The environment is running the latest Genesys Cloud release with custom Architect flows that handle dynamic routing based on carrier health metrics. We suspect there might be a mismatch in the codec negotiation or a timeout configuration issue specific to the failover state. Has anyone seen similar behavior where WebRTC sessions drop during trunk failover events? We are looking for any insights on whether this is a known limitation with the current softphone client or if there is a specific configuration tweak needed for BYOC trunk failover scenarios involving WebRTC endpoints.
This is caused by…
“The initial WebSocket connection to the Genesys Cloud edge succeeds without issue, but the subsequent SDP negotiation fails silently after 45 seconds. This happens exclusively during peak hours when the primary carrier hits capacity and failover logic activates.”
While my focus is typically on recording exports for legal discovery, this latency pattern mirrors issues we see with bulk job timeouts when network paths shift. In BYOC scenarios, the SDP failure usually indicates a NAT traversal issue or a firewall rule blocking the specific media ports required for the secondary trunk. The 45-second delay suggests the Genesys Cloud edge is waiting for an ICE candidate that never arrives due to asymmetric routing.
Check the iceTransportPolicy in your WebRTC configuration. If it is set to all, ensure your secondary carrier allows UDP traffic on the ephemeral port range. Also, verify that the STUN/TURN servers configured for that region are not overloaded during peak failover. A quick fix is to force relay mode in the SDP offer if your primary concern is connectivity stability over latency.
Check your Queue Performance dashboard for Abandoned Calls spikes coinciding with the trunk failover. If Service Level drops while Offered Conversations remain high, the issue is likely upstream capacity rather than a WebRTC handshake failure.