Most VoIP problems we troubleshoot aren't VoIP problems — they're internet problems. A flaky cable line, a noisy upstream, an ISP doing maintenance at 2 AM. If your business runs on phones, a single internet connection is a single point of failure. Dual-WAN or multi-WAN routers fix that. Here's when you need one, what to buy, how to configure it for our phone service, and the honest tradeoffs of each option.
When dual-WAN is worth it
Not every customer needs it. Use this rough cut:
- Under 5 phones, low call volume — a single solid fiber or cable line is usually fine. Keep an LTE backup in your back pocket or use the cell-phone simultaneous-ring fallback as your business-continuity plan.
- 5–20 phones, customer-facing — dual-WAN with automatic failover pays for itself the first outage. Mix two carriers if you can.
- 20+ phones, contact center, multi-location — dual-WAN minimum, often with a third LTE/5G WAN for true diversity. This is non-negotiable for our multi-location deployments and our sales team customers who can't afford a missed lead call.
The classic mistake is buying two connections from the same cable provider. If the cable plant goes down, both your WANs go with it. Use two different physical paths — fiber + cable, cable + fiber, or terrestrial + LTE. Even better, two carriers using two different physical routes into the building.
How to actually verify path diversity
Ask each ISP for the demarc location and the upstream path. If both lines enter the building through the same conduit, you don't have diversity — a backhoe takes them both out. Telecom rooms in shared buildings frequently have all carriers landing in one room; if your reliability target is high, you may need to run a second conduit or use an LTE/5G WAN that doesn't share copper or fiber with anyone.
Cost of an hour of phones-down
Before you spec the router, do this math. Pick the worst week in your year (peak season, end-of-month billing, hurricane prep). Estimate revenue per hour of inbound calls in that window. If a 4-hour outage during that week costs $10,000 in lost calls and customer trust, a $1,000 router and a $100/mo LTE plan is a no-brainer. If the same outage costs $200, maybe a single line plus cell-phone fallback is enough. The right answer depends on the business, not on the brochure.
Routers we deploy
We're brand-agnostic, but these are the units we install most often. Specs as of 2026:
- Peplink Balance 20X — single WAN with embedded LTE. Around $500. Good for small offices that want simple failover.
- Peplink Balance Two — 2 WAN + embedded LTE, SpeedFusion for hot failover (no dropped calls on WAN switch). Around $1,000. Our default for 10–30 user offices.
- Peplink Balance 380 — 3 WAN, higher throughput, suitable for larger sites and small contact centers.
- Ubiquiti UniFi Dream Machine Pro — 2 WAN, much cheaper (~$400), works well if you already run UniFi. Failover is functional but not hot — expect a few seconds of call drop on switchover.
- Cradlepoint or Cisco IR series — when LTE/5G is the primary or secondary WAN and you need carrier-grade management.
Peplink's SpeedFusion bonding is the only commodity feature we know of that holds an active SIP call across a WAN failure. If your business literally cannot drop a call mid-conversation, that's the product. Everyone else can tolerate a 10–30 second blip on failover, which means a cheaper router works.
What about a regular router with two ISPs?
Some folks ask if they can just plug two ISPs into a regular consumer router with WAN failover. Some routers (Asus, Synology RT2600) support this. It works for HTTP traffic. It does not work well for VoIP because failover detection is slow and SIP re-registration can take a minute or more. If phones are important, get a real dual-WAN router.
5G as a primary WAN
For some sites — rural offices, construction trailers, pop-up retail — 5G has become a real primary WAN option, not just a backup. T-Mobile, Verizon, and AT&T all sell business 5G plans with usable upload speeds and stable enough latency for VoIP. The catch: signal varies by location, congestion varies by time, and not every plan supports the static IP or QoS markings VoIP wants. Test before committing.
Configuration that actually matters
QoS
VoIP traffic must be prioritized. Tag SIP and RTP with DSCP EF (46) on the LAN side and make sure your router honors it. Without QoS, a single big upload (Dropbox sync, video upload, a backup running) will tank call quality even on a fast connection. We've watched call MOS scores drop from 4.3 to 1.8 because somebody started a cloud backup; QoS pinned them back to 4.3 immediately.
Failover thresholds
Default "ping the gateway" health checks are too coarse — your gateway can be up while the upstream is broken. Set health checks against external targets (8.8.8.8, 1.1.1.1) and require 2–3 missed checks before failover to avoid flapping.
SIP ALG off
Disable SIP ALG on every router we deploy. It mangles SIP headers more often than it helps. Our SBC handles NAT traversal. SIP ALG is the source of about a third of the weird one-way-audio tickets we troubleshoot at customer sites that didn't follow this rule. If you've inherited a router and audio is one-way, check SIP ALG first.
Same public IP problem
When you fail over, your public IP changes. Existing calls usually drop unless the router does SpeedFusion-style bonding. New calls re-register within 30–60 seconds. Set caller expectations or buy the bonding.
Load balancing vs. failover
Two modes worth distinguishing. Failover keeps WAN1 primary and only uses WAN2 when WAN1 dies. Load balancing splits traffic across both WANs all the time. For VoIP, failover is simpler and more reliable. Load balancing can put RTP packets on different WANs, which creates jitter. If you load-balance, pin SIP and RTP to a single WAN with policy-based routing.
VLANs
Put voice on its own VLAN. It isolates broadcast traffic, makes QoS easier to enforce, and means a busy desktop video upload doesn't slosh into the phone subnet. Most managed switches support this; we configure it as part of deployment.
What this looks like on the bill
For a 15-user office on All-Inclusive ($32/user/mo = $480/mo phone service), a Peplink Balance Two is a one-time ~$1,000 plus a $50–$100/mo LTE failover SIM. One four-hour ISP outage that takes your phones down probably costs more than that in lost calls. We've watched it happen.
For SIP trunking customers ($15/channel + $0.015 out, $0.005 in on our SIP trunking), the same router applies — the trunk re-registers from the new WAN after failover.
For multi-site deployments, the router-per-site cost adds up but each site is independently resilient. We've also done hub-and-spoke topologies where a primary site has dual-WAN and remote sites tunnel back through it, which can simplify the math but creates a hub-failure single point. Spec carefully based on what your business actually needs to keep running.
Real-world failover story
One of our property management customers in central Florida lost their primary fiber for 6 hours during a storm. Peplink Balance Two failed over to LTE inside 4 seconds. Phones stayed up. Maintenance dispatch kept running. The portfolio manager didn't know there was an outage until he saw the cellular data usage on the next bill. Total LTE overage that month: $43. Cost of 6 hours of phones-down during a storm: more than $43, by a lot.
Common mistakes
- Buying two cable lines from the same provider. Same plant, same outage. Use carrier diversity.
- Leaving SIP ALG enabled. Disable it.
- No UPS on the router and switch. Dual-WAN doesn't help when the power blinks. Budget $150–$300 for a UPS that gives you 30+ minutes.
- Forgetting to test failover. Pull WAN1's cable on a Saturday. Make sure phones still ring. Most outages are the first time anyone realizes failover doesn't actually work.
- Ignoring LTE data caps. If your failover is on a 15 GB/mo cellular plan and your primary goes down for a day, you'll blow the cap. Size the LTE plan for your worst expected outage.
- Skipping the bandwidth math. Each concurrent call is about 100 kbps. 50 calls is 5 Mbps minimum, with headroom for jitter and packet retransmission, plus everything else on the network.
- Putting voice and data on the same VLAN. A noisy printer or a misconfigured IP camera can ruin every call.
What to ask a network provider
- What's the actual physical path of each WAN? Where do they enter the building?
- What's the failover detection time and the SIP re-registration time?
- Can the router prioritize VoIP traffic with DSCP, and does the ISP honor those markings on the upstream?
- What's the SLA on each connection, and what's the credit if it's missed?
- If you have to fail over for 24 hours, what's the cellular data cap and the overage cost?
- Can the LTE module be repositioned for better signal, or does it have an external antenna option?
What we don't do
We don't sell internet service — you get that from your local ISPs. We don't manage your LAN switches by default; we'll spec what's needed and point you at integrators if you don't have one. We don't guarantee call quality on internet connections we haven't seen. And we don't believe in a magic single-vendor box that solves WAN diversity through software alone — physical diversity matters, and software can't fix a cut cable.
Monitoring and proactive alerting
A dual-WAN router that fails over silently is great — until you realize you've been on the backup for a week and don't know it because nobody's watching. Set up SNMP or syslog alerts so the IT contact gets a notification when WAN1 goes down and another when it comes back. Peplink's InControl 2 portal does this well; UniFi's controller does it adequately. Without alerting, you'll discover you're on LTE when the data overage bill arrives.
What to alert on
- WAN1 down / restored.
- WAN2 down / restored.
- LTE data usage crossing 50%, 75%, 90% of plan.
- SIP registration failures.
- Call quality (MOS score) dropping below 3.5.
For customers on our managed network add-on, we monitor these from Ocoee and call before you notice. For everyone else, set the alerts to go to whoever owns the network — usually the IT manager or the office manager.
Multi-site networking
If you have more than two locations, the network design gets bigger than just "dual-WAN at each site." Three common topologies:
- Independent sites. Each location has its own dual-WAN, its own internet, its own phone registrations. Simplest, no inter-site dependencies, scales fine for chains where each location is operationally independent.
- Hub-and-spoke. A primary site has dual-WAN; remote sites tunnel through it. Cheaper for small remote offices that only need basic phone, but the hub becomes a single point of failure.
- Full mesh with SD-WAN. Every site talks to every other site over a managed overlay. Most flexible, most complex. Worth it for 10+ sites with significant inter-site call volume.
For multi-location customers, we usually start with independent sites and only step up to SD-WAN when there's a real reason. Most retail and service chains run fine on independent dual-WAN.
Disaster preparation in Florida and elsewhere
We're in Ocoee, Florida. Hurricanes happen. We've watched customer phone systems stay up through Helene, Milton, and Ian because the dual-WAN was real (fiber + LTE) and the UPS lasted long enough for cellular battery to handle the rest. We've also watched customer phone systems die in storms because the "dual-WAN" was two cable lines from the same provider, sharing the same downed pole. If you operate in a region with seasonal disaster risk, the diversity question is not academic. It's the difference between "we kept dispatching during the storm" and "we missed half our calls and a third of our customers gave up."
Where to start
Tell us your site count, user count, and current ISPs and we'll spec the router. We sell and pre-configure the hardware listed above — see hardware — or you can buy your own and we'll send config. Contact us if you want a network review before you commit, or get started if you're ready to move forward. For larger deployments, we'll do a free 30-minute network call where we look at your current setup and give you a no-pressure recommendation.