Trying to understand why failover to our secondary BYOC trunk takes 45 seconds instead of the expected 5 seconds. We manage 15 trunks in APAC. The primary trunk drops SIP 408s, but the secondary remains idle during the gap. Our SBC logs show immediate retry, yet Genesys logs show a long timeout. Is this a region-specific quirk? Config below:
trunk: secondary-sg
failover_timeout: 5000
sbc_ip: 10.0.0.5
You should probably look at at the health check interval configuration on the secondary trunk. While the failover_timeout dictates how long Genesys waits for a response before switching, the actual detection of the primary failure often relies on the health check probe frequency. If the primary trunk is sending SIP 408s but the health check isn’t configured to detect this state rapidly, the system may wait for the full timeout cycle before initiating the switchover.
Consider adjusting the health check settings in your trunk configuration to reduce the detection window. Here is an example of how to tighten those parameters:
trunk: secondary-sg
failover_timeout: 5000
sbc_ip: 10.0.0.5
health_check:
interval_ms: 1000
failure_threshold: 2
This setup forces a quicker reassessment of trunk availability. Additionally, verify that the SBC is properly signaling the failure state rather than just dropping packets, as silent failures can delay the failover logic significantly.
The health check interval is definitely the culprit. The default probe frequency is 30 seconds, which explains the 45-second delay despite the 5-second timeout setting. Try adjusting the health_check_interval to 5000 in the trunk configuration to align detection with the failover trigger.
Note: Ensure your SBC supports rapid probing without triggering rate limits.
It depends, but generally… the delay stems from how the platform handles concurrent health check probes during high-volume load tests. When pushing multiple tenants through the integration, the default probe frequency often creates a bottleneck. Adjusting the interval helps, but you must also verify the API rate limits for trunk status updates.
trunk: secondary-sg
failover_timeout: 5000
health_check_interval: 5000
rate_limit_strategy: adaptive
This backoff logic stabilizes the connection state under high concurrency. Ensure your SBC supports rapid probing without triggering stricter API rate limits.