VoIP.info Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Reviewed 2026-10-30Foundational

Define the failure you intend to survive

A provider outage, local internet failure, PBX failure and a single unreachable destination need different responses. A second trunk on the same PBX and internet circuit does not remove those shared dependencies.

Redundancy needs separate failure paths
A PBX uses a primary provider path and an alternate provider path. Shared PBX, power and internet dependencies remain unless the design also separates them.

New-call recovery and active-call survival are different tests. Inbound number failover needs a provider-side routing plan.

Design outbound behavior

Specify which failures should trigger an alternate route. An authorization denial or invalid destination may require correction rather than another attempt. Limit retries and verify number formatting, caller identity and permissions on each trunk. Prevent loops between alternate paths.

Design inbound behavior separately

Inbound failover depends on control of the called number and the provider's routing options. Ask where calls go when the primary PBX cannot be reached and whether that behavior uses a timeout or a health signal. A second outbound account alone does not redirect inbound calls to your number.

DIDWW documents DNS SRV for a customer trunk host and trunk groups with selected rerouting disconnect codes, priority and weight. Flowroute documents per-number primary and failover destinations. Neither pattern implies that every SIP error or an already established call will move. Record the triggering response and every attempted destination when you test.

SIP.US documents primary and secondary trunk assignments plus PSTN Backup and Forward options. These have different triggers and channel use; see the SIP.US record rather than treating them as one universal failover mode.

Voxtelesys portal route profiles can prioritize registered-PBX, customer-IP and external-transfer destinations. Review the provider record and validate the actual advance trigger, cost and shared dependencies.

Amazon Chime SDK Voice Connector uses priority and weight for customer SIP hosts, while connector groups can span AWS Regions. Review the provider record and keep provider-region fallback distinct from the customer PBX, access network and active-call state.

Test recovery as well as failure

Use an agreed maintenance exercise. Confirm new calls on the backup path, expected handling of active calls and return to the primary route. Check capacity, billing assumptions and emergency-calling arrangements for the backup. Record the observed recovery time instead of describing the design as seamless without evidence.

Where the provider exposes a separate CDR for each delivery attempt, reconcile attempts by call identifier and time. DIDWW describes that behavior for SRV and trunk-group failover. A single successful final leg can hide a repeatedly failing primary leg.

Model every BYOC-P failure domain

Zoom Phone BYOC-P can use regional trunks, alternate Zoom data-center routing, multiple customer SBCs and Internet or private connectivity. Those controls do not establish one universal route order, timer, access diversity, carrier recovery or established-call behavior; test each accepted boundary separately.

Keep Genesys provider requirements separate from the deployed sequence

For Genesys Cloud BYOC, the provider record distinguishes OPTIONS, 503 and sequential-failover requirements from the selected carrier's actual target order, timers, capacity, restoration and established-call behavior.

Bind ACS Direct Routing failover to route priority and response code

For Azure Communication Services Direct Routing, the provider record preserves regular-expression match, route priority, equal-priority random SBC selection, OPTIONS health and Microsoft's documented 408, 503 and 504 next-SBC failover boundary.

Keep the CCAI Platform BYOC failover owner explicit

Google assigns customers responsibility for high availability and call routing from carrier services to the CCAI Platform media edge. The BYOC record preserves multiple inbound carriers, the single outbound-carrier boundary and requested Google-telephony fallback as different designs.

Trace a peoplefone offline-forwarding path

The peoplefone fallback diagnostic follows registration expiry, provider line state, the offline role, number filtering, alternate delivery and return to primary without representing forwarding as active-call survival.

Keep redundant targets distinguishable from stale branches

The A&A duplicate-ringing diagnostic inventories registration, direct server and Also Ring branches before deciding whether an alternate path is intended resilience or a retired target.

Apply SureVoIP’s timeout-only destination policy

For SureVoIP inbound delivery, use the provider-specific destination diagnostic to preserve the ordered routes and distinguish a timeout from Busy, Unavailable or later PBX failure.

Distinguish Magrathea health probes from call delivery

Use the Magrathea SIP Resilience diagnostic to correlate nominated addresses, provider probes, pool membership, new-call selection and later PBX routing.

Distinguish NFON multi-PBX modes from PSTN backup

Use the NFON backup-PBX diagnostic to correlate the selected mode, endpoint readiness, provider branch, PBX route and restoration.

Prove SIP DNS selection before expecting another target

Use the Voip Unlimited DNS failover diagnostic to trace NAPTR, SRV, address records, cache state, a qualifying failure and the new transaction.

Resolve Broadvoice failover mechanics for the ordered route

Broadvoice publishes built-in redundancy and failover without one public timer or route contract. The Broadvoice provider record keeps targets, health checks, failure responses, detection, restoration, new-call recovery and established-call behavior as separate acceptance evidence.

Qualify SIPcity’s optional peering failover address

SIPcity permits a primary and optional failover IP for peering, but does not publish one trigger or timer contract. The SIPcity provider record requires an approved new-call exercise and keeps active-call survival and restoration as separate evidence.

Separate Toku platform redundancy from customer-trunk failover

Toku describes redundant infrastructure, but the reviewed material does not define one customer trunk trigger, retry path or restoration timer. The Toku provider record requires the selected design and an approved new-call failure and recovery exercise.

Separate LoopUp endpoint distribution from DNS and WAN failover

LoopUp offers round-robin or ordered failover across customer endpoints and separately publishes regional platform FQDNs. The provider record requires each new-call choice and recovery path to be proved.

Separate SIPTRUNK gateway redundancy from call treatment

SIPTRUNK documents multiple gateway registration or SRV behavior separately from PSTN Backup, hard forwarding and voicemail. The mode-mismatch diagnostic keeps provider reachability, inbound destination, treatment trigger and restoration as different observations.

Do not combine SIP.US gateway failover with secondary routing

SIP.US documents provider-gateway redundancy, secondary-trunk DID routing and PSTN Backup as separate mechanisms. Use the SIP.US failover diagnostic to capture the qualifying failure, next attempted path, caller result and restoration.

Keep Flowroute provider-edge selection and number-route failover separate

Flowroute documents current PoP selection separately from per-number primary and failover route relationships. Use the Flowroute diagnostic to record the first delivery result, any second attempt and return to primary without assuming which responses advance.

Keep DIDWW trunk-group and DNS SRV attempts separate

DIDWW can create a new CDR for each trunk-group or DNS SRV attempt. The provider-specific diagnostic binds every attempt to the layer, configured trigger and destination that owned it.

Use every available Twilio edge address without losing trunk identity

Twilio recommends avoiding a single termination IP and preserving the personal trunk domain while edge routing changes. The termination diagnostic separates DNS or address failover from ACL and credential acceptance.

Preserve SIPStation failover precedence

Sangoma documents different behavior when no failover is configured and when account-level or per-DID failover exists. The SIPStation diagnostic records the first server, configured override, next attempt and final route.

Keep IP Telecom access diversity separate from SIP failover

IP Telecom recommends resilient connectivity such as backup broadband or 4G/5G. The provider record keeps access failover, provider SIP routing, alternate inbound delivery, PBX redundancy and established-call survival as separate evidence.

Treat Clearfly forwarding and virtual attendant as routing controls

Clearfly describes personalized forwarding and a virtual attendant for weather or phone-system outages. The provider record keeps those controls separate from SIP target health, access diversity, PBX resilience and established-call survival.

Bind Redcentric failover to the ordered access design

A legacy Redcentric description tied standard failover to provider-supplied circuits and treated third-party access as designed work. The provider record uses that only as a present-day acceptance question for circuits, targets, triggers, recovery and support.

Translate CommPeak redundancy claims into a tested route map

CommPeak publishes geo-redundant routing and failover language. The provider record still requires selected targets, DNS behavior, triggers, established-dialog limits, alternate inbound handling, recovery and rollback evidence.

Require an explicit Voximplant alternate-path design

The reviewed Voximplant pages do not define one universal customer failover sequence. Use the provider record to record targets, DNS dependency, triggers, retry behavior, established-dialog limits, recovery and rollback.

Separate Voip Unlimited DNS routing from portal diversion

The provider profile distinguishes NAPTR or SRV target selection, registered Contact, customer-system diversion and non-registration alerts.

Keep SignalWire resource assignment separate from failover

The reviewed SignalWire material documents number and Resource SIP Address routing but does not establish a redundant PBX retry policy. The provider profile keeps that gap explicit.

Interpret Telnyx failover from the recorded first result

Telnyx documents response-specific advancement for IP and FQDN routes and a separate registered-instance path for credential Connections. Use the Telnyx diagnostic to retain each attempt, response and next destination.

Do not invent Bandwidth failover triggers

Bandwidth Build documents prioritized routes and later failover routes but the reviewed public page does not publish a complete response-code or timer contract. The Bandwidth diagnostic preserves the observed attempt, result and any next route.

Classify Voipfone diverts before calling them failover

Voipfone publishes Always, closed, busy, no-answer and PSTN-failover controls. The Voipfone diagnostic records which rule was enabled, what triggered and which attempt occurred.

Classify the VoIP.ms failover state first

VoIP.ms separates Busy, Unreachable, No Answer and Max Capacity. The VoIP.ms diagnostic records the trigger evidence and alternate attempt for each.

Read the Twilio stopping response before expecting another URI

Twilio publishes response classes that stop Origination URL advancement and a four-second no-response boundary. The Twilio diagnostic preserves each attempt.

Test Plivo fallback only at its documented boundary

The Plivo inbound diagnostic distinguishes an unresponsive primary from a reachable destination that returns a final SIP response.

Test Vonage priority and timeout at their documented boundary

The Vonage inbound diagnostic distinguishes an unreachable URI from a reachable target that returns a final SIP response.

Preserve Voxtelesys destination priority and transfer ownership

Voxtelesys supports prioritized route destinations and a later Transfer using an outbound trunk group. The diagnostic retains the actual attempt and avoids inventing a universal response matrix.

Separate Amazon Chime group fallback from origination routing

Voice Connector group priority and origination-host priority are different selection layers. The Amazon Chime diagnostic traces each without claiming active-call survival.

Test Callcentric Network Down Forward below DID Forward

A direct DID Forward has higher priority than Call Treatments, including a network-down treatment. The Callcentric diagnostic tests precedence, the separate forwarded leg and return to primary.

Scope Anveo Direct failover to the DID add-on

The Failover Add-on can send an inbound DID to a backup SIP URI, while outbound LCR has different controls. The diagnostic records the actual attempts without inventing a trigger matrix.

CarrierX soft failure is not dead-trunk state

CarrierX separates one-call soft failure from thresholded hard-failure state and SIP OPTIONS monitoring. The diagnostic retains each transition and next attempt.

AVOXI terminal codes are explicit stop controls

An AVOXI URI can list 400–699 responses that terminate a call. The diagnostic does not infer universal retry or alternate-target behavior for other outcomes.

Separate Easybell address order from Offline forwarding

A later Trusted IP and an Offline forward to a telephone number are different mechanisms. The diagnostic requires observed attempts instead of an invented universal trigger.

SIP.US Forward, Backup and secondary trunks have different precedence

PSTN Forward bypasses the PBX and prevents conditional Backup from engaging; a secondary trunk is a separate SIP route. The diagnostic requires observed attempts.

Separate Flowroute edge recovery from number-route failover

A preferred PoP can change the Flowroute source edge while the number remains on the same customer route. The Flowroute failover diagnostic records both layers.

ClearlyIP number-level failover has separate precedence

The ClearlyIP workflow keeps per-number rules, Location rules, Smart Routing and observed recovery as different evidence.

Keep Simwood routing controls and observed recovery separate

The Simwood workflow records time-of-day routing, forwarding, failover and the provider attempt as different evidence.

Do not pin one Sinch regional edge

The Sinch diagnostic preserves the regional FQDN, DNS answers, selected address and observed result.

Do not flatten Commio responses into generic failover

The Commio route diagnostic preserves silence, 486, 503 or busy and elapsed time before deciding whether advancement was expected.

Test each Nextiva failover boundary

The Nextiva provider guide keeps portal forwarding, redundant provider servers and a second customer path as different controls.

Treat Intermedia failover as a per-number new-call route

The Intermedia diagnostic correlates the monitored location, configured ten-digit alternate, selected destination and restoration without inventing a trigger matrix.

Explain each Infobip route advance

The Infobip route diagnostic distinguishes priority, weight, time-window eligibility, administrative state, OPTIONS status, connection timing and answer timeout.

Distinguish IntelePeer redundant trunks from number failover

The IntelePeer route diagnostic separates bundle redundancy, usage-profile selection and switched-number Forward or Failover records.

Separate BCM One proxy redundancy from per-number recovery

The BCM One provider guide keeps provider-side proxy behavior distinct from ordered Disaster-Recovery Routing targets.

Keep Cox continuity controls independently observable

The Cox Business provider guide separates always-forward, not-reachable, route-exhaustion, backup-PBX and provider-core layers.

Name the Comcast continuity control precisely

The Comcast provider guide separates Failover/Overflow, Load Balancing, Bursting, Unreachable Destination and Call Forward Not Reachable.

Name the Lumen hunt and failure evidence precisely

The Lumen provider guide distinguishes sequential and percentage allocation from generic failover claims and undocumented timers.

Name the AT&T algorithm and forwarding control

The AT&T provider guide keeps Linear, Round Robin, % Allocation and Most Idle separate from Unreachable Destination and Forward Always.

Name the Verizon continuity mechanism

The Verizon guide separates optional VARRS SBC capacity from PBX Group Unreachable and Call Forward Unreachable redirection.

Name the exact Bell continuity control

The Bell guide separates dual virtual connections, automatic overflow and per-number Remote Call Forwarding modes.

Name the exact Rogers continuity control

The Rogers guide keeps peer failover, active load balancing, capacity overflow and as-needed emergency redirect distinct.

Name the ThinkTel recovery mechanism

The ThinkTel diagnostic keeps secondary-binding selection, response-code-triggered SureCall and all-down forwarding distinct.

Name the Iristel failover layer

The Iristel diagnostic distinguishes provider redundancy, customer access, SIP delivery and backup-line redirection.

Name the TELUS resiliency purpose

The TELUS diagnostic distinguishes provider SBC redundancy, trunk-group selection, customer access, edge receipt and PBX routing.

Do not merge SaskTel overflow with emergency redirection

The SaskTel diagnostic separates RTM overflow, requested emergency redirection, customer access, PBX forwarding and restoration.

Trace Cogeco provider selection before customer changes

The Cogeco diagnostic separates provider geo-redundancy, customer access, eSBC receipt, PBX routing and restoration.

Do not merge Flowroute Edge Strategy with DID failover

The Flowroute diagnostic traces provider PoP attempts separately from the number's primary and failover route relationships.

Version and order AireSpring routing controls

The AireSpring guide preserves dated portal and DTO material without turning it into one universal trigger or restoration sequence.

Keep OnSIP ring-time failover separate from PBX forwarding

The OnSIP guide compares the saved provider timer and external destination with local inbound rules and observed attempts.

Treat DIDforSale gateway diversity as ingress scope, not observed failover

The DIDforSale guide preserves every current provider source, packet receipt and customer route without inventing universal timers or retry order.

Do not convert multiple Zadarma source addresses into inbound failover claims

The Zadarma guide treats confirmed customer egress addresses separately from number-level inbound routing and active-call survival.

Do not turn Voxbeam network redundancy into endpoint-failover rules

The Voxbeam guide leaves destination order, triggers, restoration and active-call behavior open until the account policy proves them.

Keep GoTrunk POP selection separate from customer failover

The GoTrunk guide does not turn provider locations into undocumented destination order, trigger or active-call guarantees.

Distinguish DIDWW DNS SRV from Trunk Group attempts

The DIDWW guide keeps transparent SRV targets in one CDR and member rerouting as separate attempt records.

Treat Exotel proxy retry and destination order as new-call behavior

The Exotel guide does not turn multiple addresses or destinations into proof of health-aware routing or established-call survival.

Do not infer Voximplant recovery from one registration transition

The Voximplant diagnostic retains registration state, callback or status evidence and call outcome separately.

Compare Colt failure detection with recovery

The Colt failover diagnostic distinguishes first-call detection, blacklist state, timer or OPTIONS recovery and later selection.

Separate Gamma trunk rerouting from cloud call control

The Gamma continuity diagnostic distinguishes trunk, Call Manager and Inbound triggers.

Separate Bandwidth route priority from Final Destination URI

The Bandwidth provider record keeps route groups, endpoint weights and number-level failover controls distinct.

Separate Commio destination advancement from DNS and PBX recovery

The Commio provider record preserves ordered attempts, responses, timeouts and later recovery evidence.

Separate LES.NET forwarding from failure-triggered failover

The LES.NET provider record keeps a selected DID destination, telephone forwarding, provider attempt and recovery evidence distinct.

Require the applied Wavix destination policy

The Wavix diagnostic does not convert multiple saved destinations or product language into a universal failover sequence.

Separate Allstream forwarding, overflow, failover and pooling

The Allstream diagnostic distinguishes portal Unavailable forwarding, trunk overflow, multi-endpoint failover, two-endpoint pooling, WAN state and PBX routes.

Keep Cloudli Service Continuity separate from PBX failover

The Cloudli diagnostic preserves the affected number, backup destination, provider attempt, PBX reachability and restoration state.

Use Orange project response policy, not generic SIP assumptions

The Orange Business Talk guide treats guide-specific probing and rerouting rules as project evidence and requires primary restoration proof.

Make Vodafone endpoint diversity and restoration observable

The Vodafone Evolved Voice diagnostic records eligible endpoints, trigger, alternate selection, call result and return to primary.

Distinguish Swisscom continuity options

The Swisscom Enterprise SIP diagnostic keeps core forwarding, Multi SAP, Multi PBX, Multi Server and trunk failover independently observable.

Make Sunrise backup and restoration observable

The Sunrise Business Voice SIP diagnostic records trigger, selected alternate, new-call result and return to primary.

Identify the selected Proximus redundancy mode

The Proximus Business Trunking diagnostic keeps Basic-Single, Single, Basic-Multi and Secure-Multi evidence distinct.

Verify Crazytel continuity at each boundary

The Crazytel SIP trunk diagnostic keeps Divert on Down, network failover, alternate call and primary restoration separate.

Verify MaxoTel Offline diversion as a call path

The MaxoTel SIP Trunking guide keeps configured destination, offline trigger, alternate completion and restoration separate.

Do not infer voice continuity from broadband options

The Aussie Broadband SIP Trunks guide keeps Internet access, alternate routing, restored service and completed calls independently observable.

Prove selected Symbio dual-network routing

The Symbio Enterprise SIP trunk diagnostic verifies entitlement, policy, trigger, selected path, call result and restoration independently.

Name the exact Telstra continuity mechanism

The Telstra SIP Connect diagnostic keeps Shared Capacity, access redundancy, PBX failover, number diversion and BRS+ distinct.

Name the exact Optus continuity feature

The Optus Evolve Voice diagnostic keeps Emergency Diversion, Dual Voice Trunk and Dual Exchange Homing distinct.

Name the One NZ continuity option

The One NZ SIP diagnostic distinguishes Multi-Site diversity, Dual Circuit, dual Diversity and Smart SIP 4G failover Access.

Prove the 2degrees continuity design

The 2degrees SIP diagnostic distinguishes provider rerouting, alternate data paths and PBX mobile redirection.

Prove the Vocus continuity design

The Vocus SIP Voice diagnostic distinguishes whole-trunk diversion, alternate access and PBX routing.

Prove Superloop continuity at each boundary

The Superloop diagnostic distinguishes outage posts, alternate access, provider routing, PBX policy and completed calls.

Prove Enreach continuity rather than assuming it

The Enreach diagnostic checks entitlement, trigger, target, provider action, call result and restoration.

Treat MetTel redundancy as bounded product evidence

The MetTel SIP Trunking guide does not convert a multi-datacenter claim into tested account failover, route diversity or completed calls.

Bound NUSOflex to the eligible inbound path

The NUSO guide does not turn inbound PSTN-impairment claims into universal outbound, access or established-call continuity.

Separate Always, Unreachable and Enterprise Trunking

The Telesystem guide keeps saved forwarding, trigger, delay, alternate route, trunk group and completed call distinct.

Separate TPx forwarding, DTO and SD-WAN continuity

The TPx guide keeps CFNR, Trunk Group Call Forwarding, Standard DTO, Enhanced DTO and active/active access evidence distinct.

Bound Lingo redundancy and automatic-failover claims

The Lingo guide preserves feature, trigger, alternate target, new attempt, answer and restoration as separate evidence.

Do not infer Voyant restoration from redundancy language

The Voyant guide preserves access state, new attempts, status components and verified ordinary-call restoration separately.

Name the exact Windstream DTO option

The Windstream guide distinguishes Trunk to Trunk and Trunk to Number Redirect from access survival and established-call continuity.

Bound Granite DTFO to the ordered design

The Granite guide separates trigger, alternate target and observed delivery from access survival and established-call continuity.

Bind FirstLight redundancy to the accepted order

The FirstLight guide separates redundant access loops, alternate-path evidence and observed calls from established-call continuity.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.