My current config is completely failing… specifically regarding the automatic failover logic for our APAC BYOC trunks when initiated via the Conversational API. We have a multi-region setup with 15 trunks, and the primary carrier in Singapore is currently experiencing intermittent latency spikes. The failover rule is configured to trigger after a 3-second timeout, but instead of switching to the secondary carrier in Tokyo, the call state hangs in ‘connecting’ for approximately 45 seconds before returning a generic ‘Call Failed’ status in the analytics dashboard. The SIP trace shows an initial 100 Trying, followed by silence, and eventually a 408 Request Timeout from the primary carrier’s proxy, yet the platform does not seem to register this as a hard failure worthy of immediate failover. This delay is unacceptable for our high-volume outbound campaigns. I have verified that the secondary trunk is registered and healthy by making manual test calls, which connect instantly. The issue appears isolated to API-initiated flows where the transferTo parameter is used with a specific number pattern. The Architect flow itself is simple: Get Input → Make Outbound Call → Disconnect. No complex logic is interfering with the routing decision. I suspect the timeout threshold defined in the trunk configuration is not being respected by the underlying SIP stack when the call origin is programmatic rather than user-initiated via the softphone.
- Adjusted the failover timeout value in the trunk settings from 3000ms to 1500ms, but the platform still waits the full 45-second default circuit break period before failing the call entirely.
- Captured the raw SIP INVITE and ACK messages using the diagnostic logs endpoint; the primary carrier responds with 100 Trying but no 180 Ringing, which should theoretically trigger the failover logic immediately according to the documentation.