Does anyone know why WebRTC signaling sessions initiated by agents using the softphone client are timing out specifically when the active BYOC trunk in our Singapore region triggers a failover to the secondary carrier? We have a setup with 15 BYOC trunks distributed across APAC, and while PSTN routing remains stable, the WebRTC media path seems to lose its binding during the SIP re-registration window.
The issue manifests as a 504 Gateway Timeout on the /api/v2/telephony/providers/edges/{edgeId}/sessions endpoint when the agent attempts to establish a new call immediately after the primary trunk health check fails. The Architect flow logs show the call leg is created, but the WebRTC offer/answer exchange never completes. The client logs indicate a “WebSocket connection reset” error, yet the underlying SIP INVITEs are successfully routed to the secondary carrier according to the trunk analytics.
We are using the Genesys Cloud Web SDK version 2.14.0. The failover logic is configured with a 10-second detection threshold, which should be sufficient for SIP re-registration, but the WebRTC signaling state appears to desynchronize from the underlying SIP dialog state. This results in agents hearing silence or a busy tone, while the system still marks the interaction as “in progress” in the analytics dashboard.
Has anyone encountered similar desynchronization issues between the WebRTC signaling layer and the BYOC trunk failover mechanism? We have verified that the STUN/TURN servers are reachable and that the carrier-specific codecs (G.711, Opus) are correctly prioritized in the trunk configuration. The problem is isolated to the WebRTC softphone users; desktop softphone users on the same edge do not experience this timeout, suggesting a protocol-specific handling issue rather than a general network connectivity problem.