SIP Trunk Failover: How to Build a Redundant Voice System

Why SIP Trunk Failover Matters

Voice communications are mission-critical for most businesses. Unlike email or chat, a phone call cannot be queued and retried later -- when a customer calls and nothing picks up, that opportunity is lost. For call centers, sales teams, and emergency services, even a few minutes of downtime can mean lost revenue, damaged reputation, and regulatory violations.

SIP trunk failover is the automatic process of rerouting voice traffic to a backup path when the primary trunk or path becomes unavailable. Combined with SIP trunk redundancy -- maintaining multiple independent paths for voice traffic -- it forms the foundation of PBX high availability.

Common causes of SIP trunk failures include:

• ISP outages -- your internet connection goes down, severing the SIP trunk
• Provider failures -- the SIP trunk provider's infrastructure has an issue
• PBX hardware failure -- your on-premise PBX server crashes or loses power
• Network congestion -- bandwidth exhaustion degrades call quality to unusable levels
• DDoS attacks -- volumetric attacks flood your SIP infrastructure

Types of SIP Trunk Failover

There are three fundamental layers where you can implement SIP trunk redundancy. A robust high-availability design addresses all three:

Asterisk PJSIP Failover Configuration

Asterisk offers two approaches to SIP trunk failover with PJSIP: multiple contacts on a single AOR (Address of Record), and dialplan-based failover between separate trunks. Both have valid use cases.

Approach 1: Multiple Contacts on a Single AOR

This method configures multiple SIP endpoints (e.g., East and West coast servers) as contacts within a single AOR. PJSIP will try the next contact if one is unavailable:

; === IPComms Trunk with Multi-Contact AOR ===

[ipcomms]
type=endpoint
transport=transport-udp
context=from-pstn
disallow=all
allow=ulaw
allow=alaw
outbound_auth=ipcomms-auth
aors=ipcomms

[ipcomms-auth]
type=auth
auth_type=userpass
username=your_username
password=your_password

[ipcomms]
type=aor
contact=sip:s1.ipcomms.net:5060
contact=sip:s2.ipcomms.net:5060
qualify_frequency=30
qualify_timeout=3

[ipcomms-identify]
type=identify
endpoint=ipcomms
match=34.23.59.14/32

Approach 2: Separate Trunks with Dialplan Failover

This method defines two separate trunk endpoints and uses the dialplan to fail over if the first trunk returns an error. This gives you more control over failover behavior:

; === Primary Trunk (East Coast) ===
[ipcomms-primary]
type=endpoint
transport=transport-udp
context=from-pstn
disallow=all
allow=ulaw
outbound_auth=ipcomms-primary-auth
aors=ipcomms-primary

[ipcomms-primary-auth]
type=auth
auth_type=userpass
username=your_username
password=your_password

[ipcomms-primary]
type=aor
contact=sip:s1.ipcomms.net:5060
qualify_frequency=30
qualify_timeout=3

; === Secondary Trunk (West Coast) ===
[ipcomms-secondary]
type=endpoint
transport=transport-udp
context=from-pstn
disallow=all
allow=ulaw
outbound_auth=ipcomms-secondary-auth
aors=ipcomms-secondary

[ipcomms-secondary-auth]
type=auth
auth_type=userpass
username=your_username
password=your_password

[ipcomms-secondary]
type=aor
contact=sip:s2.ipcomms.net:5060
qualify_frequency=30
qualify_timeout=3

Then in your dialplan, handle the failover logic (see the complete dialplan example below).

FreePBX Trunk Failover Settings

FreePBX provides a GUI-based approach to SIP trunk failover through its Outbound Routes module. Here is how to configure failover between two trunks:

DNS SRV Records for SIP Failover

DNS SRV (Service) records provide a standards-based mechanism for SIP failover that works at the protocol level. When your PBX resolves a SIP domain, the SRV records tell it which servers to contact, their priorities, and weights:

; _service._proto.name  TTL  class  type  priority  weight  port  target
_sip._udp.sip.ipcomms.net. 300 IN SRV 10 60 5060 east.ipcomms.net.
_sip._udp.sip.ipcomms.net. 300 IN SRV 10 40 5060 west.ipcomms.net.
_sip._udp.sip.ipcomms.net. 300 IN SRV 20 100 5060 backup.ipcomms.net.

How SRV-Based Failover Works

1. Priority (lower = preferred): The PBX first tries servers with the lowest priority value. In the example above, both East and West have priority 10, making them the primary tier. The backup server at priority 20 is only used if both primary servers fail.
2. Weight (load distribution): Among servers with the same priority, traffic is distributed proportionally by weight. East (weight 60) gets 60% of calls, West (weight 40) gets 40%.
3. Automatic failover: If a server at priority 10 is unreachable, the SIP stack automatically tries the next available server at the same priority, then moves to priority 20 if all primary servers fail.

[ipcomms-srv]
type=endpoint
transport=transport-udp
context=from-pstn
disallow=all
allow=ulaw
aors=ipcomms-srv

[ipcomms-srv]
type=aor
; Use domain name - PJSIP will resolve SRV records
contact=sip:sip.ipcomms.net
srv_lookups=yes
qualify_frequency=30

The advantage of DNS SRV is that failover happens transparently without any PBX configuration changes. The provider can add, remove, or reprioritize servers by updating DNS records.

IPComms Built-In Redundancy Features

IPComms is designed from the ground up for high availability. Our infrastructure provides multiple layers of redundancy so you can achieve carrier-grade uptime without complex PBX configurations:

Network Best Practices for Voice Redundancy

Even the most reliable SIP trunk is useless if your network goes down. These best practices ensure your voice traffic has a reliable path to the internet at all times:

Dual ISP Configuration

Maintain two independent internet connections from different providers, ideally using different last-mile technologies (e.g., fiber + cable, or fiber + fixed wireless):

Quality of Service (QoS)

QoS ensures voice traffic is prioritized over other data even during bandwidth contention:

• DSCP marking: Tag SIP signaling as CS3 (DSCP 24) and RTP media as EF (DSCP 46)
• Bandwidth reservation: Reserve 100 Kbps per concurrent call (G.711) plus 30% overhead for SIP signaling
• Traffic shaping: Cap non-voice traffic to prevent it from starving voice queues
• Jitter buffer: Target under 30ms jitter and under 150ms one-way latency

Firewall Considerations

Monitoring and Alerting for Trunk Failures

Proactive monitoring detects trunk failures before users notice. Here are the key methods for monitoring SIP trunk health:

SIP OPTIONS Ping (Qualify)

SIP OPTIONS is a lightweight request that checks if a remote endpoint is alive. Asterisk's "qualify" feature uses this to monitor trunk health:

[ipcomms-primary]
type=aor
contact=sip:s1.ipcomms.net:5060
; Send OPTIONS every 30 seconds
qualify_frequency=30
; Mark unavailable if no response in 3 seconds
qualify_timeout=3
; Authentication for qualify requests
authenticate_qualify=no

Asterisk CLI Monitoring Commands

# Check all PJSIP endpoint statuses
asterisk -rx "pjsip show endpoints"

# Check qualify status of a specific AOR
asterisk -rx "pjsip show aor ipcomms-primary"

# Show all contacts and their status (Reachable/Unreachable)
asterisk -rx "pjsip show contacts"

# Check registration status
asterisk -rx "pjsip show registrations"

External Monitoring Script

Use a cron-based script to check trunk status and send alerts when a trunk becomes unreachable:

#!/bin/bash
# Check SIP trunk health via Asterisk CLI
STATUS=$(asterisk -rx "pjsip show contacts" | grep "ipcomms-primary" | awk '{print $NF}')

if [ "$STATUS" != "Avail" ]; then
    echo "ALERT: Primary SIP trunk unavailable!" | \
    mail -s "SIP Trunk Failure Alert" admin@yourcompany.com

    # Optional: trigger failover script
    # /usr/local/bin/activate_backup_trunk.sh
fi

Key Metrics to Monitor

Complete Asterisk Dialplan with Failover

Here is a production-ready Asterisk dialplan that implements SIP trunk failover with logging. It attempts the primary trunk first, checks for failure conditions, and automatically fails over to the secondary trunk:

[outbound-calls]
; US/Canada calls with trunk failover
exten => _1NXXNXXXXXX,1,NoOp(Outbound call to ${EXTEN} via primary trunk)
 same => n,Set(TRUNK_PRIMARY=ipcomms-primary)
 same => n,Set(TRUNK_SECONDARY=ipcomms-secondary)
 same => n,Dial(PJSIP/${EXTEN}@${TRUNK_PRIMARY},30)
 same => n,NoOp(Primary trunk result: ${DIALSTATUS})
 same => n,GotoIf($["${DIALSTATUS}" = "CHANUNAVAIL"]?failover)
 same => n,GotoIf($["${DIALSTATUS}" = "CONGESTION"]?failover)
 same => n,Hangup()
 same => n(failover),NoOp(Failing over to secondary trunk)
 same => n,Dial(PJSIP/${EXTEN}@${TRUNK_SECONDARY},30)
 same => n,NoOp(Secondary trunk result: ${DIALSTATUS})
 same => n,Hangup()

; 10-digit dialing (prepend 1)
exten => _NXXNXXXXXX,1,Goto(outbound-calls,1${EXTEN},1)

; Emergency calls - try both trunks
exten => 911,1,Dial(PJSIP/911@${TRUNK_PRIMARY},10)
 same => n,Dial(PJSIP/911@${TRUNK_SECONDARY},10)
 same => n,Hangup()

; Toll-free numbers
exten => _1800NXXXXXX,1,Goto(outbound-calls,${EXTEN},1)
exten => _1888NXXXXXX,1,Goto(outbound-calls,${EXTEN},1)
exten => _1877NXXXXXX,1,Goto(outbound-calls,${EXTEN},1)
exten => _1866NXXXXXX,1,Goto(outbound-calls,${EXTEN},1)

How This Failover Works

1. Primary attempt: The call is first sent to ipcomms-primary with a 30-second timeout.
2. Status check: After the Dial() returns, the ${DIALSTATUS} variable is checked for failure conditions.
3. Failover triggers: CHANUNAVAIL means the trunk endpoint is unreachable. CONGESTION means the network returned a 503 or similar error. Both trigger failover.
4. Secondary attempt: The call is re-dialed through ipcomms-secondary with another 30-second timeout.
5. Graceful handling: If both trunks fail, the call hangs up (the caller hears a fast busy). You can add a Playback() before Hangup() to play a custom message.

Enhanced Failover with PJSIP Qualify

For even faster failover, combine the dialplan approach with PJSIP qualify. When qualify detects a trunk is unreachable, you can skip it entirely:

[outbound-calls-smart]
exten => _1NXXNXXXXXX,1,NoOp(Smart failover for ${EXTEN})
 ; Check if primary trunk is reachable via qualify status
 same => n,Set(PRIMARY_STATUS=${PJSIP_AOR(ipcomms-primary,contact_status)})
 same => n,GotoIf($["${PRIMARY_STATUS}" = "Reachable"]?primary:secondary)
 same => n(primary),Dial(PJSIP/${EXTEN}@ipcomms-primary,30)
 same => n,GotoIf($["${DIALSTATUS}" = "CHANUNAVAIL"]?secondary)
 same => n,Hangup()
 same => n(secondary),Dial(PJSIP/${EXTEN}@ipcomms-secondary,30)
 same => n,Hangup()