FreePBX Failover Trunk Setup for Outbound Call Centers

1. How FreePBX Trunk Failover Works

FreePBX evaluates trunks in the outbound route's trunk sequence list from position 0 downward. If a call attempt on position 0 fails with a qualifying SIP response, Asterisk retries on position 1, then position 2. The call either connects on a secondary trunk or exhausts the list and fails to the caller with a busy or congestion signal.

The definition of "failure" matters here. Asterisk treats the following as retriable:

• No SIP response (timeout)
• 503 Service Unavailable
• 502 Bad Gateway
• 403 Forbidden (in some configurations)

It does not retry by default on:

• 404 Not Found (number unroutable — retrying a secondary trunk usually produces the same result)
• 480 Temporarily Unavailable
• 486 Busy Here

For outbound call centers, the most operationally useful failover scenarios are 503 (carrier outage) and connection timeout (network path failure). Configure your secondary trunk to handle these cases.

2. Choosing a Secondary Trunk Architecture

There are three common failover architectures for outbound call centers:

Active-standby with a second SIP provider: A second SIP trunk account on a different carrier. Traffic normally flows 100% through the primary; the secondary activates only on primary failure. Appropriate when your primary provides flat-rate pricing and the secondary is a pay-per-minute backup — you accept higher per-minute costs on the secondary during outages.

Active-standby with a PSTN gateway: An on-premises VoIP gateway (e.g., Sangoma, AudioCodes) connected to POTS lines or a T1/PRI. Zero external dependency — works even if your internet connection fails for SIP but retains PSTN signaling via physical lines. Expensive per-minute and lower channel capacity, but maximally resilient.

Geographic redundancy via a second Asterisk server: A second FreePBX instance in a different datacenter, both registered to UnlimCall's network. If the primary server goes down, your dialer re-registers to the secondary. This handles compute failures rather than carrier failures — a different failure mode than trunk failover.

For most outbound call centers on a flat-rate primary trunk, active-standby with a second SIP provider is the lowest-complexity option with acceptable cost.

3. Configuring the Secondary Trunk

Add your secondary SIP trunk in FreePBX following the same PJSIP configuration steps as your primary. See FreePBX PJSIP trunk setup for the full procedure.

Key differences for the secondary trunk:

• Use a different SIP proxy hostname/IP — the secondary trunk must traverse a different network path than the primary, otherwise a network failure that takes down the primary also takes down the secondary
• If the secondary is a pay-per-minute carrier, confirm their rates and channel limits before enabling — a large outbound floor failing over unexpectedly to a per-minute carrier can generate significant cost in a short period
• Set Qualify Frequency on both trunks (60 seconds) so FreePBX detects availability continuously, not just at call time

4. Adding the Failover Trunk to an Outbound Route

In Connectivity > Outbound Routes, open your primary outbound route and scroll to the Trunk Sequence section.

• Position 0: unlimcall-primary (your flat-rate primary)
• Position 1: secondary-provider (your failover carrier)

Save and apply config.

To test failover without a real outage, temporarily disable the primary trunk:

`` asterisk -rx "pjsip show endpoint unlimcall-primary" ``

Then set the endpoint to offline state via a custom dialplan or temporarily remove the trunk IP from the allowlist on your UnlimCall account to generate 403 responses. Confirm calls route to the secondary trunk.

Restore the primary and verify automatic recovery — Asterisk should return to using position 0 on the next call attempt once the primary responds to OPTIONS again.

5. Monitoring Trunk Health Continuously

Asterisk's built-in OPTIONS-based qualification (qualify=yes) monitors trunk health every 60 seconds by default. This detection is reactive — you learn a trunk is down after a call fails, or when the next qualify cycle detects non-response.

For proactive monitoring, add an external check to your monitoring stack. The Asterisk Management Interface (AMI) exposes trunk state:

`` asterisk -rx "sip show peers" | grep unlimcall ``

Or for PJSIP:

`` asterisk -rx "pjsip show contacts" ``

Pipe this output to a monitoring script that alerts on Unreachable or Unknown status. Most outbound call center operations alert within 5 minutes of trunk failure — enough time to investigate without extended silence.

6. Failover Logging and Incident Review

After a failover event, extract the Asterisk log to understand the timeline:

`` grep "PJSIP\|SIP\|Dial" /var/log/asterisk/full | grep "$(date +%Y-%m-%d)" | head -200 ``

Look for the sequence: primary trunk 503 response → retry on secondary trunk → successful connection. Confirm the failover latency (time between first failure and secondary connection) — typically 5–15 seconds depending on SIP timeout settings.

Document each failover event with timestamp, duration, affected call volume, and root cause. Recurring failovers on the same trunk may indicate a peering or routing issue that the carrier can investigate.