We are observing intermittent SIP 408 Request Timeout errors specifically when our outbound campaigns trigger the secondary failover trunk in the Singapore region. Our primary BYOC trunk handles about 60% of the load, but once it hits its concurrency limit, traffic shifts to the secondary provider. This is where the failures occur.
The primary trunk registers cleanly and maintains stable RTP streams. However, the secondary trunk, while showing a registered status in the Genesys Cloud administration console, begins dropping calls with a 408 timeout precisely at the INVITE stage. The logs indicate that the Genesys edge is sending the INVITE, but the carrier gateway is not responding within the 32-second window defined in our SIP profile.
We have already verified that the SIP credentials are correct and that the secondary carrier is not blocking our outbound IPs. We also increased the “Initial invite timeout” to 60 seconds in the trunk configuration, but the issue persists. Interestingly, this only happens during peak hours (14:00 - 16:00 SGT), suggesting a potential race condition or resource contention on the Genesys edge node rather than a pure carrier-side issue.
Has anyone experienced similar latency spikes on secondary BYOC trunks during high-concurrency failover events? We are considering adjusting the “Max retry” settings or implementing a more aggressive health check interval, but we want to avoid destabilizing the primary trunk. Any insights into how the Genesys edge handles SIP transaction timers during failover would be appreciated.