Two links do not create call continuity
A second WAN can restore reachability when the first fails. It does not by itself preserve the public address, NAT mapping, SIP dialog or media path of a call already in progress. A carrier may also authorize a trunk by source IP, making an otherwise healthy backup link unusable until it is explicitly supported.
Load balancing and failover solve different problems. Distributing new flows can increase aggregate use of links; moving a failed flow can change the endpoint identity seen by the peer. Design signaling and media policy together rather than treating each UDP packet as an interchangeable load-balancing unit.
Define the SD-WAN service being purchased
Ask whether the design preserves an overlay endpoint, anchors media, duplicates packets or merely selects a better underlay. These have different bandwidth and recovery implications. Define the measurements that trigger a path change, such as sustained loss or delay, and the return-to-primary policy. Avoid oscillation between two marginal links.
Check physical independence: two services sharing a duct, building power or upstream carrier can fail together. Include DNS, tunnel endpoints and provider ingress addresses in the dependency inventory.
Run three separate acceptance tests
First, disconnect the primary path while no calls are active and measure when new inbound and outbound calls recover. Second, change paths during an established two-way call and record any lost media or disconnect. Third, restore the primary path and check whether recovery itself disrupts calls.
Repeat under realistic upload load. Record which capabilities were observed and which depend on the provider or overlay. A claim of seamless voice failover requires evidence from that architecture; the presence of two green WAN indicators is insufficient.
Do not infer trunk readiness from SD-WAN state
The Windstream diagnostic aligns the selected access path with SIP, SDP, packets and calls.
Prove the selected Granite access path
The Granite diagnostic aligns the actual route with SIP, SDP, packets and calls.
Prove the ordered FirstLight access design
The FirstLight diagnostic distinguishes geo-diverse redundant loops from an unverified alternate route.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Netgate: gateway groups ↗
- IETF RFC 3261 ↗
- IETF RFC 3550 ↗
- Windstream Enterprise — SIP Trunking with Dynamic IP ↗
- Windstream Enterprise — Voice & Communications ↗
- Windstream Enterprise — Direct Trunk Overflow fact sheet ↗
- Windstream — Standard Agreement for Service Terms and Conditions ↗
- Windstream Enterprise — Dynamic IP Standard Terms and Conditions ↗
- Windstream Enterprise — Customer Responsibilities Guide ↗
- Windstream Enterprise — Data Products SLA and QoS classes ↗
- Windstream Enterprise / Uniti Solutions — U Connect portal and support ↗
- Granite — VoIP & Cloud Phone Systems ↗
- Granite — SIP Trunking brief (legacy, date-scoped) ↗
- Granite — Legal & Policy ↗
- Granite — General Terms of Service (May 2026) ↗
- Granite — VoIP Services Additional Terms and Conditions of Service ↗
- Granite — VoIP Services Service Level Agreement ↗
- Granite — Canadian VoIP 911 English ↗
- Granite — Resources and customer portals ↗
- FirstLight — Voice and SIP Trunking ↗
- FirstLight — SIP Trunk info sheet ↗
- FirstLight — Service Schedule A, Voice Services, version 4 (August 21, 2026) ↗
- FirstLight — Standard Terms and Conditions, version 5 (June 16, 2025) ↗
- FirstLight — E911 Acknowledgement, version January 14, 2019 ↗
- FirstLight — Legal, Regulatory, Terms and Conditions ↗
- FirstLight — Customer Support ↗
- FirstLight — Prevent Long Distance Fraud and PBX Hacking ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.