SIP 408 Timeout on BYOC Trunk Failover during High Concurrency

Can anyone clarify the expected behavior of the Genesys Cloud BYOC failover mechanism when the primary carrier experiences intermittent SIP 408 Request Timeout errors under high load? We are managing 15 BYOC trunks in the AP-Southeast-1 region, primarily handling inbound voice traffic for a large-scale contact center operation. Recently, we have observed that during peak hours, when the primary carrier’s latency exceeds 200ms, the platform attempts to route calls to the secondary carrier. However, the failover logic seems to introduce a significant delay, resulting in dropped calls before the secondary registration is fully established.

The specific issue manifests as a SIP 408 timeout on the initial INVITE to the primary trunk, followed by a 3-5 second gap before the system attempts the secondary route. During this gap, the caller hears silence or a fast busy signal. Our SIP registration status remains stable, and credentials are correct. The outbound routing configuration is set to ‘Least Cost’ with ‘Failover’ enabled for secondary trunks.

Below is a simplified representation of our trunk configuration:

trunk_configuration:
 name: "AP-SE-1-Primary-ByOC"
 region: "ap-southeast-1"
 sip_settings:
 registrar: "sip.provider-a.com"
 outbound_proxy: "proxy.provider-a.com"
 timeout_ms: 1500
 failover:
 enabled: true
 secondary_trunk_id: "trunk_id_secondary_123"
 detection_method: "sip_timeout"

We have verified that the secondary trunk is registered and active. The Analytics API v2 shows a spike in call_setup_time during these periods, correlating with the 408 errors. Is there a specific setting in the Genesys Cloud admin portal or a SIP header manipulation required to accelerate the failover process? We need to ensure that the transition between carriers is seamless for the end user, minimizing any perceived latency or call drops. Any insights into optimizing the SIP timeout values or adjusting the failover detection logic would be greatly appreciated. We are currently running Architect flow v14.2.1 and have not made any recent changes to the trunk configuration.