Overview
This covers how to configure and validate resiliency for a Voice AI trunk deployment — i.e. a customer's PBX/SBC failing over between a primary and a secondary/resilient path to Talkative. This is closely related to SIP OPTIONS/keepalive behaviour: see Mitel - Trunk Option Request Information for why the Talkative trunk itself doesn't reliably respond to OPTIONS, and why keepalive should be configured between the PBX and its own SBC rather than toward Talkative directly.
How failover detection works
The PBX detects a primary path outage via OPTIONS/keepalive (or an equivalent heartbeat) against its own SBC/edge device — not against the Talkative trunk directly (see the Trunk Option doc linked above). When that heartbeat fails, the PBX marks the primary path down and reroutes to the secondary/resilient path.
Failover test procedure
The mechanics below are generic — exact device names and menus differ by PBX/SBC vendor:
- Confirm there are no active/live calls before taking anything down for testing.
- Simulate an outage on the primary SBC/edge path (e.g. power off the primary appliance/VM, or otherwise take the primary path offline in a controlled way).
- Place a test call and confirm the PBX/SBC detects the primary path is unavailable, raises an alarm, and reroutes via the secondary/resilient path.
- Run an end-to-end test call through the full flow (IVR bot → queue/routing → agent pickup) to confirm the resilient path isn't just "up" but actually functional for real traffic.
- Restore the primary path and confirm calls route back through it as expected (failback).
If the deployment has two edge devices behind different public IPs (a primary and a resilient/secondary), double-check as part of this test that each internal device's NAT is translating to the correct, intended public IP — a mismatch here (traffic leaving from the wrong public IP) is a common and easy-to-miss cause of "the resilient path doesn't actually work."
Firewall considerations
Ensure the relevant firewall rules are in place for all servers involved in the deployment — the primary path and any resiliency/secondary path(s) alike. It's easy for a rule to be correctly configured for the primary server but missed or misconfigured for the resilient one, which will only surface once a failover actually happens.
Detailed firewall configuration and troubleshooting is covered separately in an upcoming troubleshooting document — this doc just flags it as a required check as part of resiliency setup and testing.
Debugging checklist
- One-way or no audio: run simultaneous packet captures at both ends of the leg in question to help identify where the audio is being lost, and confirm firewall rules exist equally for both the primary and resilient paths (see above).
- Issue reproduces intermittently or self-resolves before you can capture it: consider forcing a controlled failover (take the primary path down deliberately) to try to reproduce it in a state where you're already capturing traces on both sides.
- Trunk reports "down" but calls are still working: this is very often an OPTIONS/keepalive false alarm rather than a real path failure — see the Trunk Option doc linked above before assuming a network fault.