- Just noticed that the WebRTC softphone registration is failing intermittently for agents located in the Singapore data center, specifically when they are attempting to connect via the 15 configured BYOC trunks.
- The issue manifests as a persistent ‘ICE Gathering Timeout’ error in the browser console, accompanied by a 408 Request Timeout response from the /api/v2/platform/user/me endpoint during the initial WebSocket handshake phase.
- This behavior is isolated to the Asia/Singapore region and does not replicate in the US East or EU West environments, suggesting a potential latency or firewall restriction issue specific to the local carrier interconnects.
- The SIP registration logs show that the initial INVITE message is successfully sent to the carrier, but the subsequent ACK is delayed by approximately 4-5 seconds, causing the Genesys Cloud platform to drop the session before the media path is established.
- We have verified that the SIP credentials are correct and that the outbound routing rules in Architect are properly configured to prioritize the primary trunk for Singapore-based agents.
- The carrier-specific quirks for the local providers include a strict requirement for SDP offer/answer negotiation within a 2-second window, which seems to be exceeded during peak traffic hours between 10:00 AM and 2:00 PM SGT.
- The WebRTC SDK version currently in use is 1.2.4, and we have confirmed that the latest patches have been applied to all agent workstations.
- The failover logic is enabled, but the secondary trunks are not being utilized because the primary trunk is not explicitly marking itself as down; instead, it is simply failing to complete the handshake in time.
- We are seeking advice on whether there are any specific configuration changes required in the Architect flow to extend the timeout period for ICE candidate gathering or if this is a known limitation with the current BYOC implementation in the APAC region.
- Any insights into how other administrators have handled similar latency issues with carrier-specific SDP negotiation timeouts would be greatly appreciated.
{
"keepAliveInterval": 15000
}
If I remember correctly, adjusting this value in the Web SDK configuration often resolves the 408 timeouts during the handshake phase. The platform documentation suggests increasing the interval to prevent premature connection drops.