Quick question about a specific SIP signaling failure we are encountering on our Singapore (SG1) BYOC trunk infrastructure.
We manage 15 distinct BYOC trunks across APAC regions, and while most are stable, the primary outbound trunk for our Singapore data center is throwing intermittent “408 Request Timeout” errors during peak campaign hours. This is not a general connectivity issue, as inbound calls and other outbound trunks in the same region function normally. The issue appears strictly tied to outbound leg establishment when the concurrency exceeds 400 simultaneous sessions.
The SIP trace shows the INVITE message leaving our carrier gateway correctly, but the Genesys Cloud edge node does not respond with a 100 Trying or 180 Ringing within the 3-second window expected by our carrier’s Session Border Controller (SBC). Subsequently, the carrier retries twice before failing the call with a 408. We have verified that the SIP credentials are valid and the registration state is active (200 OK) throughout the test window.
We are running Genesys Cloud version 2024-11. We have already adjusted the “Max Concurrent Calls” setting on the trunk configuration to match the carrier’s guaranteed bandwidth, and we ensured that the outbound routing rules prioritize this BYOC trunk without any failover logic interfering during the initial attempt. The carrier has confirmed they see the INVITEs arriving at the Genesys edge IP but claim no response is sent back from the platform.
Could there be a known limitation with the SIP stack on the SG1 edge nodes regarding high-velocity outbound INVITE processing? We are considering implementing a retry mechanism on our carrier side, but that introduces latency. Has anyone else seen this specific 408 behavior on SG1 BYOC trunks under heavy load, and what configuration tweaks resolved it?