Stuck on a persistent issue where WebRTC audio streams fail to initialize for specific outbound campaigns routed through our Singapore BYOC trunks. The problem is isolated to the Genesys Cloud WebRTC softphone client (v24.3.0) and does not affect PSTN calls or SIP trunked audio via traditional agents.
We have 15 BYOC trunks configured in the APAC region. While standard SIP registrations and inbound calls function without interruption, the WebRTC handshake consistently drops during the initial media negotiation phase. The Architect flow successfully routes the call, and the carrier acknowledges the session with a 200 OK. However, the client-side JavaScript console logs a fatal error before the audio channel opens.
The error manifests as follows:
WebRTC connection failed: ICE candidate gathering timeout.
Error Code: 503 Service Unavailable
Stack Trace: at WebSocketClient.send (genesys-webrtc-sdk.min.js:42:105)
We have verified that the firewall rules allow UDP traffic on ports 3478-3481 and that STUN/TURN servers are correctly configured in the Genesys Cloud administration console. The issue appears to correlate with the carrier-specific codec negotiation. Our carriers prefer G.729, but the WebRTC client attempts to negotiate Opus or PCMU. When we force PCMU via the outbound route settings, the handshake succeeds intermittently, but audio quality degrades significantly during peak APAC hours (0900-1200 SGT).
Has anyone encountered similar ICE candidate gathering timeouts when using BYOC trunks with WebRTC? We are considering implementing a custom TURN server, but we want to rule out configuration errors in the Genesys Cloud WebRTC settings first. Any insights on how to debug the SDP exchange between the Genesys Cloud edge and the BYOC carrier for WebRTC sessions would be appreciated. We are currently logging raw SDP offers/answers via the /api/v2/analytics/conversations/summary endpoint, but the data lacks the granular media negotiation details needed to pinpoint the mismatch.