Could someone explain why our Architect flow drops calls when the primary APAC BYOC trunk is down? The flow uses a Queue node set to ‘Return to IVR’ on no-answer, but it loops infinitely instead of hitting the secondary carrier. We see 408 Request Timeout errors in the call logs. The failover policy is set to ‘Immediate’, yet the secondary SIP trunk never receives the INVITE. Is there a specific timeout setting in the Queue node that overrides the trunk failover logic?
It depends, but generally… the Queue node logic operates independently of the underlying SIP trunk failover mechanisms. When a call enters the queue and hits the timeout threshold, the platform attempts to execute the “Return to IVR” path. If the primary trunk is already down, the system may not immediately re-evaluate the Carrier Selection policy for the subsequent leg. This creates a loop where the IVR tries to place the call back into the queue or a similar routing block, perpetuating the 408 Request Timeout because the downstream carrier remains unreachable. The failover policy applies to the initial INVITE, not necessarily to re-routes triggered by queue timeouts.
To resolve this, insert a Get Queue Stats or a Conditional Split before the return path. Check the status of the primary carrier or the queue wait time explicitly. If the primary trunk is marked as Unavailable, route directly to the secondary carrier node instead of returning to the IVR. This bypasses the loop and forces a fresh carrier selection based on current availability. Ensure your Data Actions are not interfering with this flow, as webhook delays can also cause session timeouts. Review the SIP Trunk configuration to confirm the secondary trunk is correctly prioritized in the Failover Group.