Your Internet Is Fine. Your Router Is the Problem.

When VoIP calls sound bad, everyone blames the internet. The real culprit is almost always the router in the closet — and the fix is usually simple.

The Conversation We Have Every Week

Someone calls us. Their VoIP phones are acting up. Choppy audio. One-way sound. Calls dropping after 30 seconds. Phones that stop ringing for incoming calls. The diagnosis they’ve already arrived at: “Our internet must not be good enough.”

Their internet is almost always fine. We run a test and their connection is solid — plenty of bandwidth, reasonable latency, minimal packet loss. The problem is sitting in the networking closet (or under the front desk, or balanced on top of a bookshelf). It’s the router.

This isn’t an edge case. A 2025 industry report found that misconfigured routers account for nearly 40% of initial VoIP call setup failures and over 25% of one-way audio incidents in small business environments. The router is the number one cause of VoIP issues, and it’s the last thing most people think to check.

SIP ALG: The Feature That Breaks Everything

Somewhere, years ago, a networking engineer had a reasonable idea: since SIP traffic has trouble traversing NAT (the technology that lets multiple devices share one public IP address), why not build a feature into routers that inspects SIP packets and rewrites the IP addresses to help them find their way?

This feature is called SIP ALG — Application Layer Gateway. In theory, it helps. In practice, it’s responsible for more VoIP problems than any other single cause.

Here’s what goes wrong. Modern VoIP systems already handle NAT traversal on the server side — techniques like STUN, TURN, and symmetric RTP solve the problem cleanly. But SIP ALG doesn’t know that. It intercepts your SIP packets and “helpfully” rewrites them anyway. It replaces IP addresses that don’t need replacing. It corrupts headers. It introduces invalid port numbers. It breaks encrypted signaling entirely (because it can’t read encrypted packets and corrupts the parts it can).

The symptoms are maddening because they’re inconsistent. Calls that connect but have no audio. Calls that work one way but not the other. Phones that randomly stop receiving incoming calls. Call transfers that fail. Issues that come and go without any apparent pattern. You’ll swear your internet is flaky, but the internet is fine — the router is mangling your voice traffic.

The fix is almost always simple: turn off SIP ALG. Here’s where to find it on common routers:

  • Netgear: Advanced > Setup > WAN Setup > uncheck “SIP ALG”
  • ASUS: Advanced Settings > WAN > NAT Passthrough > disable “SIP Passthrough”
  • TP-Link Omada: Advanced > NAT Forwarding > ALG > disable SIP ALG
  • Ubiquiti UniFi: Settings > Routing > NAT > Firewall Connection Tracking > toggle SIP off
  • SonicWall: Network > VoIP > Settings > uncheck “Enable SIP Transformations”
  • Fortinet FortiGate: Requires CLI access to disable the SIP ALG and remove the SIP session-helper

The bad news: Some routers — particularly ISP-provided modem/router combos — have SIP ALG enabled with no way to turn it off. The AVM Fritz!Box, Virgin SuperHub, BT HomeHub v1/v2, Sagecom F@st, and many 2Wire/Pace gateways (common with AT&T U-verse) all fall into this category. If you have one of these and you’re having VoIP problems, the answer is usually to put it in bridge mode and use your own router, or replace it entirely.

The 30-Second Call Drop

Here’s a troubleshooting scenario that’s almost diagnostic: calls connect, audio works fine, then the call drops at exactly 30 seconds. Or 60 seconds. Always the same duration.

This is a NAT timeout problem. Your router creates a temporary entry in its NAT table when your phone sends a SIP packet. That entry maps your phone’s internal IP address to the router’s public IP, so return traffic knows where to go. But the router expects to see traffic flowing through that entry regularly. If there’s a pause — even a brief silence in the conversation — the router decides the “session” is over and closes the entry. Your phone is now invisible to the outside world. The call dies.

Consumer routers typically set this timeout at 30 to 60 seconds. Business routers let you configure it to 120 seconds or more. VoIP phones can also be configured to send tiny “keepalive” packets every 20-25 seconds to keep the NAT entry alive — but your phone has to be configured to do this, and many aren’t by default.

If your calls are dying at a consistent interval, check your router’s UDP timeout setting and increase it. Or configure your phones to send NAT keepalives. This is one of those fixes that takes two minutes and solves a problem that’s been driving you crazy for months.

Double NAT: The Problem You Don’t Know You Have

Double NAT happens when you have two devices performing NAT between your phone and the internet. The most common scenario: your ISP gave you a modem/router combo (a “gateway”), and you plugged your own router into it. Both devices are doing NAT. Two layers of address translation.

SIP hates this. Your phone’s SIP messages contain its own internal IP address, which is only valid inside your local network. With one layer of NAT, the router (or the VoIP server) can translate that address correctly. With two layers, neither device has the full picture. The result: your phone can make outbound calls (the NAT pinholes get punched from inside out), but incoming calls fail or produce one-way audio. You can hear the caller, but they hear silence.

The fix: Put the ISP gateway into bridge mode so it acts as a pure modem. Your router handles all NAT. Alternatively, enable IP passthrough or DMZ on the ISP gateway to direct all traffic to your router’s WAN IP. The goal is to have exactly one device doing NAT, not two.

How do you know if you have double NAT? Check your router’s WAN IP address. If it starts with 10.x.x.x, 172.16-31.x.x, or 192.168.x.x, your router is getting a private IP from the ISP gateway, which means both devices are doing NAT.

ISP-Provided Gateways: A Field Guide to Frustration

The modem/router combos that ISPs hand out are, almost without exception, terrible for VoIP. It’s not that they’re bad hardware per se — they’re fine for web browsing and email. But they’re optimized for simplicity and remote management, not for the specific requirements of real-time voice.

Common problems with ISP gateways:

  • SIP ALG that can’t be disabled. We covered this above, but it bears repeating. If you can’t turn it off and it’s breaking your calls, bridge mode or replacement is your only option.
  • Locked-down settings. DNS servers you can’t change (causing phone registration failures when phones can’t resolve SIP hostnames). UDP timeouts you can’t adjust. QoS settings that don’t exist.
  • DHCP instability. Some gateways (the Arris TG1682G, popular with Comcast, is a known offender) have DHCP bugs that cause devices to lose and reacquire IP addresses. When a VoIP phone gets a new IP, it loses its SIP registration and drops any active call.
  • Firmware updates that reset your settings. ISPs push firmware updates to gateways remotely, often at night. Sometimes those updates reset configuration changes you made. You come in Monday morning and your phones don’t work because the bridge mode you configured got undone over the weekend.
  • Underpowered hardware. The gateway is doing routing, NAT, firewalling, WiFi, and sometimes the ISP’s own VoIP service simultaneously. Under load, it runs out of CPU or memory and starts dropping packets. Your voice traffic is the first to suffer because it’s the least tolerant of delays.

The moose-t straightforward fix: put the ISP gateway in bridge mode and use a dedicated business-grade router. If your ISP offers a standalone modem (no routing), even better.

QoS: The Real Fix for “My Calls Get Choppy When Someone Downloads a File”

Quality of Service is the one router feature that genuinely matters for VoIP — and it’s the one feature that consumer routers almost universally get wrong.

Here’s the scenario: your office has a 50 Mbps upload connection. That’s plenty for voice — a single call uses about 85 kbps. But when someone starts uploading a large file, syncing to the cloud, or backing up to an off-site server, that upload pipe fills up. Voice packets get stuck behind data packets in the outbound queue. You hear choppy audio, garbled words, or silence.

QoS fixes this by putting voice packets at the front of the line. When the upload pipe is congested, voice traffic goes first and data traffic waits. The voice call sounds perfect; the file upload takes a little longer. Everyone wins.

But QoS only works if the router can identify voice traffic and actually prioritize it. VoIP phones mark their packets with a special DSCP tag (Expedited Forwarding, DSCP 46) that says “I’m real-time audio, prioritize me.” A business router sees that tag and acts on it. A consumer router either ignores it or strips it entirely.

Consumer routers offer “device priority” (give this device high priority) or “gaming mode” or “media priority” — marketing names for features that don’t actually implement real traffic management. They can’t reserve bandwidth for voice. They can’t separate voice and data onto different logical networks (VLANs). They can’t ensure that voice packets get priority regardless of how congested the network is.

If your calls get choppy when someone uses the internet heavily, the fix isn’t “get faster internet” — it’s “get a router that does real QoS.” A TP-Link ER605 does this for about $60. It’s one of the best investments a small office can make for phone quality. (For more on what actually affects voice quality, see our call quality guide.)

The Quick Checklist

If you’re having VoIP issues and you’ve already confirmed your internet speed is adequate, work through this list:

  1. Disable SIP ALG. This fixes a surprising percentage of problems instantly. If your router doesn’t let you disable it, that’s your first problem.
  2. Check for double NAT. Look at your router’s WAN IP. If it’s a private address, you have double NAT. Fix it with bridge mode on the ISP gateway.
  3. Increase UDP timeout. Set it to 120 seconds or higher. If your router doesn’t have this setting, configure NAT keepalives on your phones (20-25 second interval).
  4. Enable QoS. Prioritize DSCP 46 traffic. Set your upload bandwidth cap at 90% of your actual upload speed — this forces the router to manage the queue instead of the ISP’s equipment managing it for you (badly).
  5. Use wired connections. Plug your desk phones into Ethernet, not WiFi. WiFi adds jitter that Ethernet doesn’t. If you must use WiFi, at least put the phone on the 5 GHz band.
  6. Consider replacing the ISP gateway. If you’re fighting with an ISP-provided modem/router combo, bridge mode or replacement is often the fastest path to a working system.

When to Call Your Provider

If you’ve worked through the checklist and things still aren’t right, call your provider. A good provider will be able to look at SIP traces and RTP quality metrics from their end and tell you exactly what’s going wrong — whether it’s a network issue, a phone configuration issue, or something on their infrastructure.

If your provider can’t do that — if they just tell you to “check your internet” and wish you luck — that tells you something about the kind of provider you’re working with.

Having call quality issues you can’t figure out? Drop us a line. We manage our customers’ phone systems end to end, which means we troubleshoot this stuff routinely. We’ll look at the problem from our side and yours, and we’ll tell you honestly whether the fix is your router, your internet, or something on our end. No pressure, no 47-slide deck.