VoIP Infrastructure Guide
SIP Trunk Failover Configuration
8 min read · Updated April 2026
A single SIP trunk outage can take down all outbound calling. SIP trunk failover ensures calls route to a secondary provider automatically when the primary fails. Here's how to configure it correctly.
1. Why SIP trunk failover matters
SIP trunk failures happen more often than most engineers expect — provider outages, BGP routing issues, certificate expiry, authentication failures, or capacity exhaustion. Without failover, every outbound call fails until the issue is resolved.
With proper failover configured, calls automatically route to a secondary provider within seconds of detecting a failure. Users may experience a brief pause but calls complete successfully.
Failover typically requires accounts with two different SIP trunk providers — not just two connections to the same provider, which shares the same failure modes. Geographic diversity (different data centers, different carriers) provides the strongest protection.
2. DNS SRV-based failover
Many SIP trunk providers publish DNS SRV records that enable automatic failover without any dialplan configuration:
; Query SIP SRV records for a provider
dig SRV _sip._udp.provider.com
; Example response:
; _sip._udp.provider.com. 300 IN SRV 10 50 5060 sip1.provider.com.
; _sip._udp.provider.com. 300 IN SRV 10 50 5060 sip2.provider.com.
; _sip._udp.provider.com. 300 IN SRV 20 100 5060 sip-backup.provider.com.
; Priority 10 servers are tried first (lower = higher priority)
; Weight 50 = 50% of traffic between equal-priority servers
; Priority 20 server (backup) only used if all priority 10 fail
When your PBX resolves the provider hostname via SRV, it automatically tries servers in priority order. If the primary fails (no response, 503), it moves to the next SRV record. This is transparent to your dialplan — you just point to the provider hostname and DNS handles failover.
Check that your PBX supports SRV lookups: Asterisk PJSIP does by default. Kamailio uses DNS module. FreeSWITCH Sofia supports SRV. chan_sip in Asterisk has limited SRV support.
3. Asterisk failover configuration
PJSIP with multiple trunks
; pjsip.conf — two trunk endpoints
[primary-trunk]
type=endpoint
...
aors=primary-trunk
[backup-trunk]
type=endpoint
...
aors=backup-trunk
; extensions.conf — failover dialplan
exten => _1NXXNXXXXXX,1,Dial(PJSIP/${EXTEN}@primary-trunk,,b(pre-bridge^s^1))
same => n,GotoIf($["${DIALSTATUS}" = "ANSWER"]?done)
same => n,GotoIf($["${DIALSTATUS}" = "BUSY"]?busy)
; Primary failed — try backup
same => n,NoOp(Primary trunk failed: ${DIALSTATUS}, trying backup)
same => n,Dial(PJSIP/${EXTEN}@backup-trunk)
same => n(busy),Busy(20)
same => n(done),Hangup()
; Handle specific failure codes
exten => h,1,NoOp(Call ended with DIALSTATUS: ${DIALSTATUS})
; For 503 responses from primary, failover immediately
same => n,GotoIf($["${HANGUPCAUSE}" = "38"]?failover) ; 38 = network out of order
Using PJSIP contact groups for round-robin/failover
; Define multiple contacts in a single AOR
[primary-trunk]
type=aor
contact=sip:sip1.provider.com
contact=sip:sip2.provider.com
qualify_frequency=30 ; OPTIONS ping every 30s
qualify_timeout=3 ; Mark unreachable after 3s no response
4. FreeSWITCH failover configuration
<!-- Sofia gateway with failover -->
<gateway name="primary-trunk">
<param name="realm" value="sip1.provider.com"/>
<param name="username" value="myuser"/>
<param name="password" value="mypass"/>
<param name="ping" value="30"/> <!-- OPTIONS ping -->
<param name="ping-max" value="3"/> <!-- Fail after 3 missed -->
</gateway>
<gateway name="backup-trunk">
<param name="realm" value="sip1.backup-provider.com"/>
<param name="username" value="backupuser"/>
<param name="password" value="backuppass"/>
</gateway>
<!-- Dialplan failover in FreeSWITCH -->
<extension name="outbound-with-failover">
<condition field="destination_number" expression="^(1\d{10})$">
<action application="bridge" data="sofia/gateway/primary-trunk/$1"/>
<action application="bridge" data="sofia/gateway/backup-trunk/$1"/>
</condition>
</extension>
5. SBC failover
SBCs typically have more sophisticated failover capabilities than PBX platforms:
- Active/Standby: Primary SBC handles all traffic; standby monitors via heartbeat and takes over on failure. Stateful failover preserves active calls on some platforms.
- Active/Active: Both SBCs handle traffic simultaneously. DNS or load balancer distributes calls. If one fails, all calls go to the remaining SBC.
- Trunk priority groups: Configure primary and backup trunks with priority — SBC automatically fails over to lower-priority trunk when primary is unreachable.
Most enterprise SBCs (AudioCodes, Ribbon, Oracle) have built-in health monitoring that pings trunk providers via OPTIONS every 15-30 seconds and automatically fails over when the primary stops responding.
6. Monitoring and alerting for trunk failover
; Asterisk — monitor trunk registration status
asterisk -r
pjsip show registrations ; PJSIP outbound registrations
sip show registry ; chan_sip registrations
; Alert when trunk goes down — Asterisk AGI/AMI
; Use AMI RegistryEntry events for real-time status changes
; Check trunk health with OPTIONS ping
sipsak -s sip:sip.provider.com -v
Set up alerting for:
- Trunk registration state changes (registered → not registered)
- Consecutive call failures to a trunk (3+ failures in 60 seconds)
- Failover events — when backup trunk is being used
- Return to primary — when primary trunk recovers
Log all failover events with timestamps in your CDRs so you can correlate trunk failures with call quality issues in post-incident analysis.
Frequently asked questions
How do I configure SIP trunk failover in Asterisk?
In Asterisk PJSIP, configure two trunk endpoints then use dialplan to try the primary first and fall through to the backup on failure: Dial primary trunk, check DIALSTATUS, if not ANSWER or BUSY dial the backup trunk. For automatic failover, configure qualify_frequency and qualify_timeout in the AOR to mark unreachable contacts and skip them automatically.
What is DNS SRV failover for SIP?
DNS SRV records define multiple SIP servers with priorities and weights. Lower priority value means higher preference. Your PBX resolves the provider hostname via SRV and tries servers in priority order. If the primary server fails or returns 503, it automatically tries the next SRV record. This requires no dialplan changes — configure your provider hostname and DNS handles failover transparently.
How quickly does SIP trunk failover happen?
SIP trunk failover speed depends on the detection method. DNS SRV failover after a call failure: nearly instant (seconds). OPTIONS ping-based detection: depends on ping interval (typically 15-60 seconds) plus failover delay. For fastest failover, use both: DNS SRV for immediate call-level failover and OPTIONS pings for pre-emptive trunk health monitoring.
Having SIP trunk reliability issues?
Paste your SIP trace into SIPSymposium. The analyzer identifies trunk registration failures, 503 responses that should trigger failover, and routing issues between primary and backup trunks.