Stuck on a persistent WebRTC signaling timeout that only manifests when traffic is routed through our secondary BYOC trunks in the Singapore region. We are managing fifteen BYOC trunks across APAC and EMEA, and while the primary trunks handle the load without issue, the failover logic triggers a 504 Gateway Timeout on the WebRTC session establishment when the primary carrier experiences high latency.
The environment is running Genesys Cloud Platform version 2023.11.0. The softphone is the standard Genesys WebRTC client, but we are using a custom integration for call recording metadata injection via the Architect flow. The specific error observed in the browser console is:
{"code": "SIGNALING_TIMEOUT", "message": "ICE gathering failed within 5s", "details": "candidate: 192.168.1.100 5060 UDP"}
We have verified that the SIP credentials are valid and the trunk registration status is green in the Admin console. The issue seems to be tied to the carrier-specific quirks of our secondary provider, which has a stricter NAT traversal policy. We attempted to adjust the STUN/TURN server configuration in the WebRTC settings, but the timeout persists.
“WebRTC connections require stable UDP ports. Ensure your firewall allows outbound traffic on ports 5000-5500 for media streams.”
This documentation snippet suggests a firewall issue, but our network team confirmed that the ports are open. The problem appears to be in the signaling phase, not the media path. We are using the latest version of the Genesys Cloud JavaScript SDK (v5.2.1) for our custom integration.
Has anyone encountered similar issues with BYOC trunk failover affecting WebRTC signaling? We are looking for best practices to optimize the ICE gathering timeout or adjust the carrier failover logic to prevent this 504 error. Any insights into carrier-specific configurations that might help resolve this would be greatly appreciated.