Does anyone know why our secondary BYOC trunks are consistently returning SIP 408 Request Timeout errors when triggered via the automatic failover logic in the EU1 region? We manage fifteen BYOC trunks across APAC and EU, and while the primary carriers in Singapore and Sydney remain stable, the failover to our European backup carriers is failing under load.
The issue manifests specifically when call volume exceeds 200 concurrent sessions. The Genesys Cloud edge nodes appear to be dropping the INVITE requests before they reach the carrier gateways, resulting in a 408 response from the SIP stack rather than a timeout from the carrier side. We have verified the SIP credentials, port configurations, and firewall rules, all of which are correct. The primary trunks handle the load without issue, suggesting this is not a global tenant limitation.
We are using the standard outbound routing rules with a failover strategy set to ‘sequential’. The logs show the initial INVITE is sent, but no 100 Trying response is received within the default timeout window. Has anyone encountered similar behavior with specific European carriers or is this a known limitation of the current edge infrastructure in EU1?
{
“cause”: “SIP 408 timeouts during failover usually stem from the Genesys Cloud edge nodes exhausting their connection pool to the secondary trunk provider before the new INVITE requests can be processed. This is often exacerbated by mismatched timer values between the Genesys Cloud edge and the carrier’s Session Border Controller (SBC).”,
“solution”: “Adjust the SIP timer settings in the Genesys Cloud trunk configuration to align with your carrier’s SBC expectations. Specifically, increase the ‘Initial Response Timeout’ and ‘Invite Timeout’ values. For example, set the Initial Response Timeout to 30 seconds and the Invite Timeout to 60 seconds. Additionally, enable ‘SIP Keep-Alive’ with a frequency of 15 seconds to maintain connection state during high load. If the issue persists, consider implementing a custom webhook to dynamically adjust trunk routing based on real-time SIP 408 error rates, using ServiceNow Data Actions to log and trigger alerts for proactive capacity management.”
}
Check your trunk capacity limits in the Admin portal. The 408 error often hits when the edge node rejects traffic exceeding the configured max concurrent sessions, not just SIP timer mismatches.
“SIP 408: Request Timeout - Max concurrent sessions exceeded”
Increase the limit or add another trunk to distribute the load.
The documentation actually says SIP 408 timeouts during failover are frequently caused by the Genesys Cloud edge nodes exhausting their connection pool to the secondary trunk provider before new INVITE requests can be processed. This bottleneck is often exacerbated by mismatched timer values between the cloud edge and the carrier’s Session Border Controller (SBC).
When we run JMeter scripts to simulate peak concurrent call volumes, we see this exact behavior if the ramp-up rate is too aggressive. The platform intentionally locks down manual failover triggers to prevent SIP flapping, so there’s no API endpoint for forcing it. You’ll need to adjust the health check thresholds and align the SIP timer settings in the Genesys Cloud trunk configuration with your carrier’s SBC expectations. Specifically, check the invite_timeout and reinvite_timeout values. If these are too low compared to the SBC’s processing time, the edge node drops the request prematurely. A common fix is to increase the timeout buffer by 500ms in the trunk settings to account for latency spikes during high-concurrency load tests.