Context:
We are managing 15 BYOC trunks across the Asia Pacific region, with a primary focus on the Singapore (SG) edge. Our outbound routing logic relies heavily on weighted failover to distribute load between carriers. Recently, during a scheduled maintenance window on our primary carrier, we observed significant latency spikes when the Architect flow attempted to route calls through the secondary carrier. The SIP registration status remained ‘Healthy’ in the admin console, but the actual call setup time increased from ~200ms to over 3 seconds. This is causing our IVR scripts to timeout before the carrier handshake completes. We are using the latest Genesys Cloud API SDK for monitoring, and the SIP traces show a 408 Request Timeout from the secondary carrier’s edge before the retry logic kicks in. The failover weight is set to 80/20, but the system seems to be waiting for a full timeout on the primary trunk before switching, rather than using the predictive failover logic we configured.
Question:
Is there a specific setting in the BYOC trunk configuration or the Architect outbound routing block that controls the aggressive failover threshold? We want to ensure that if the primary carrier’s latency exceeds 500ms, the flow immediately attempts the secondary trunk without waiting for a hard timeout. Any insights on tuning the SIP retransmission timers or the failover detection logic for multi-trunk setups would be appreciated.