# Our backup internet kicks in fine, so why does the call still drop?

We have a secondary ISP circuit set up for failover, and when I check the logs, it does switch over correctly when the primary goes down. But our team still loses VoIP calls and video conferences every single time. It's confusing because on paper, failover is "working." Is this just a fact of life with backup circuits, or is there SD-WAN/networking tech out there that actually keeps sessions alive through a failover event instead of just switching the connection? Trying to figure out if this is a config issue on our end or a fundamental limitation of how failover works.

##### Post Metadata
- Posted at: 21 days ago
- Net upvotes: 1


## Comments
### Comment 1

Not a config issue on your end — this is a structural limitation of how standard failover works, not something you&#39;ve set up wrong.

Here&#39;s what&#39;s actually happening: your failover is doing exactly what it&#39;s designed to do — detecting the primary circuit is down and switching traffic to the backup. That part works. The problem is that most failover setups (dual-WAN routers, ISP-provided failover, firewall-based failover) assign a separate public IP to each circuit. The moment traffic moves to the backup circuit, it&#39;s moving to a new IP address — and any application that had an active session tied to the original IP treats that as the session ending, not continuing. Your VoIP call and video conference don&#39;t know &quot;failover succeeded,&quot; they just see the connection disappear and have to start over. That&#39;s why you can watch the logs confirm the switch happened correctly and still lose the call — those are two different layers of the problem, and fixing the first one (getting traffic flowing again) doesn&#39;t touch the second one (keeping the session&#39;s identity intact through the switch).

To your actual question — is this just a fact of life, or is there tech that avoids it — there is, and it comes down to where the public IP is issued from. If the IP is tied to the ISP circuit, it will always change on failover, full stop, regardless of how well-configured the router is. The way around it is decoupling the IP from the circuit entirely: instead of each ISP handing out its own IP, a dedicated IP block gets issued from separate infrastructure that all your traffic tunnels through first. That&#39;s the mechanism Bigleaf&#39;s same-IP failover uses — because the IP isn&#39;t tied to any one circuit, switching circuits underneath the tunnel doesn&#39;t touch it, and the call or video session just keeps running like nothing happened.

One thing worth knowing since you mentioned video specifically: this hits video conferencing especially hard because those platforms use real-time media protocols that are bound to the session&#39;s IP — the instant it changes, the session is over from the platform&#39;s perspective, not just degraded. So the pattern you&#39;re describing (log shows clean failover, call drops anyway) is exactly what you&#39;d expect any IP-based failover setup to do, not a symptom of something misconfigured.

Resources on this specifically:

Same-IP Address Failover — the mechanism in full detail. 
https://www.bigleaf.net/same-ip-address-failover/

Bigleaf vs. Failover — goes deeper into why &quot;the failover worked&quot; and &quot;the call survived&quot; are two separate claims with standard setups.
https://www.bigleaf.net/blog/bigleaf-vs-failover/

Why Are Calls Garbled? — relevant if you&#39;re also seeing quality issues outside of failover events specifically, since that&#39;s usually a related but distinct circuit-quality problem.
https://www.bigleaf.net/blog/why-are-calls-garbled/

##### Comment Metadata
- Posted at: 20 days ago
- Author title: Digital Marketing Manager




## Related Product
[Bigleaf Networks](https://www.g2.com/products/bigleaf-networks/reviews)

## Related Category
[SD-WAN](https://www.g2.com/categories/sd-wan)

## Related discussions
- [How well does Trello scale into a larger team?](https://www.g2.com/discussions/1-how-well-does-trello-scale-into-a-larger-team)
  - Posted at: over 13 years ago
  - Comments: 6
- [Can we please add a new section](https://www.g2.com/discussions/2-can-we-please-add-a-new-section)
  - Posted at: over 13 years ago
  - Comments: 0
- [Quantifiable benefits from implementing your CRM](https://www.g2.com/discussions/quantifiable-benefits-from-implementing-your-crm)
  - Posted at: over 13 years ago
  - Comments: 4


