Your Router Is Doing More Than You Think

Your Office Network: Part 8 of 10

Most people think of their router as the box that connects the office to the internet. That is accurate, as far as it goes. But the router is also the device making decisions about address translation, firewall rules, DNS resolution, DHCP leases, and in many cases, inspecting and modifying the actual content of your VoIP traffic. Some of those decisions are essential. Some of them are actively causing your phone problems.

This post covers what your router is doing, why it matters for VoIP, and which settings to check when phones are misbehaving. If you have already read our post on NAT traversal, some of this will be familiar. The difference here is the practical focus: not the theory of why NAT and SIP conflict, but the specific router settings that cause problems in real offices and what to do about them.

NAT: the fundamental conflict

Network Address Translation is how your router lets dozens of devices share a single public IP address. Every device in your office has a private address (something in the 10.x.x.x or 192.168.x.x range), and when any of them sends traffic to the internet, the router rewrites the source address to the router's single public IP. When responses come back, the router translates them back and forwards them to the correct internal device.

For web browsing, email, file transfers, and most internet activity, NAT is completely transparent. The applications never know it is happening.

SIP is different, and the reason matters.

When your VoIP phone places a call, it sends SIP signaling messages that contain IP addresses embedded in the message body. Specifically, the phone puts its own IP address into the SDP section of the SIP message, telling the other end "send audio to this address." The problem is that the phone only knows its private address. So the SIP message says "send audio to 192.168.1.50." The router rewrites the source address in the IP packet header to the public address, but it does not touch the SIP message content. The SIP message arrives at the far end with a private, unreachable address inside it.

The result is the most common VoIP symptom in the world: one-way audio. The call connects. Signaling works fine. But audio only flows in one direction, or does not flow at all, because one or both ends are trying to send audio to an address that does not exist on the public internet.

This is covered in much more detail in the NAT traversal post. For this discussion, the key point is that NAT is a function of your router, and how your router handles it directly determines whether your phones work correctly.

What helps: the phone's own workarounds

Most modern VoIP phones and hosted phone systems have built-in mechanisms to work around NAT. They use STUN to discover their public address, or they rely on the VoIP provider's infrastructure to handle the translation. These workarounds usually work well, as long as the router does not interfere with them.

The phrase "as long as the router does not interfere" is doing a lot of work in that sentence.

SIP ALG: the feature that breaks VoIP

SIP ALG stands for SIP Application Layer Gateway. It is a feature built into many routers, especially consumer and small-business models, that attempts to solve the NAT problem described above. The idea is straightforward: the router inspects SIP messages as they pass through, finds the embedded private IP addresses, and rewrites them to the router's public IP address. In theory, this fixes the one-way audio problem without the phone needing to do anything.

In practice, SIP ALG is one of the most common causes of VoIP problems. The implementations in the vast majority of consumer and small-business routers are buggy, incomplete, or both. Here is what goes wrong.

Double-rewriting. If the phone is already using STUN to insert its public address into SIP messages, and the router's SIP ALG also rewrites those addresses, the result is a doubly-translated address that is incorrect. The phone did the right thing. The router "fixed" it into the wrong thing.

Corrupted messages. SIP ALG rewrites IP addresses inside the message body but does not always update the Content-Length header. The receiving end sees a message whose declared length does not match its actual length and rejects it. Calls fail to connect, or registration fails intermittently.

Mangled encryption. If your VoIP provider uses TLS encryption for SIP signaling (which is increasingly common and is best practice), the router cannot read the encrypted message body. Some SIP ALG implementations attempt to process these encrypted messages anyway, corrupting them in the process.

Inconsistent behavior. SIP ALG on many routers does not handle every SIP message type correctly. It might rewrite INVITE messages properly but mangle REGISTER messages, or handle initial requests but break re-INVITEs (which are used for call transfers and hold/resume). The result is phones that can make calls but cannot transfer them, or calls that connect but fail when put on hold.

The fix: turn SIP ALG off

The near-universal advice from VoIP providers is to disable SIP ALG on your router. This is not controversial advice. It is standard practice. The workarounds built into phones and VoIP platforms handle NAT traversal more reliably than SIP ALG does.

The challenge is finding the setting. Different router manufacturers label it differently:

• "SIP ALG" (the most common label)
• "SIP Helper"
• "SIP Transformations"
• "Application Layer Gateway" (with SIP as one of several protocols)
• "SIP Passthrough"
• "ALG" in the firewall or NAT settings section

Some routers have SIP ALG enabled by default with no user interface option to disable it. In those cases, the solution is either a firmware update that adds the option, a command-line configuration change (if the router supports it), or replacing the router.

If you are experiencing any combination of one-way audio, registration failures, dropped calls after a fixed time, calls that fail on transfer, or intermittent call setup failures, check whether SIP ALG is enabled. Disabling it resolves the problem in a surprising number of cases.

Firewall rules for VoIP

Your router's firewall controls which traffic is allowed to pass between your internal network and the internet. For outbound traffic (devices inside your network reaching out to the internet), most firewalls are permissive by default and allow everything. For inbound traffic (the internet trying to reach devices inside your network), most firewalls block everything by default.

VoIP requires traffic to flow in both directions, and the firewall needs to allow it.

SIP signaling

SIP signaling typically uses UDP port 5060 or TCP port 5061 (for TLS-encrypted SIP). Your phones initiate outbound connections to your VoIP provider's servers on these ports. The provider sends responses back, and these responses need to be allowed through the firewall.

Most firewalls handle this automatically through stateful inspection: because the phone initiated the outbound connection, the firewall creates a temporary rule to allow the provider's responses back in. You generally do not need to create explicit inbound firewall rules for SIP signaling as long as your phones are initiating the connections.

RTP media (the actual audio)

RTP, the protocol that carries the actual voice audio, uses a range of UDP ports, typically somewhere in the range of 10000 to 65535, depending on the phone's configuration and the VoIP provider's requirements. Like SIP, the phone initiates the outbound RTP stream, and the firewall should allow the return traffic through stateful inspection.

Where this breaks down is when the firewall's state table is not maintained correctly, or when the firewall's UDP timeout is too aggressive (more on this below). If the firewall closes its state entry for the RTP stream, return audio stops flowing and you get one-way audio.

What to check

If you suspect firewall issues, verify that:

1. Outbound UDP traffic to your VoIP provider's SIP server (port 5060 or 5061) is not blocked
2. The firewall is using stateful inspection and is maintaining state for UDP connections
3. The UDP state timeout is long enough to keep connections alive during normal call activity (at least 60 seconds, preferably 120)
4. No overly aggressive intrusion prevention system (IPS) is flagging SIP traffic as suspicious and dropping it

UDP timeout: the invisible call killer

This one is subtle and catches a lot of people. Your router's NAT table and firewall state table maintain entries for active connections. For TCP, these entries persist as long as the TCP connection is open, because TCP has explicit connection setup and teardown messages that tell the router when the connection starts and ends.

UDP has no such messages. UDP is connectionless. The router has no way of knowing when a UDP "conversation" is over, so it uses a timer. If no traffic flows through a particular NAT mapping for a set period, the router assumes the conversation is done and removes the entry.

The default UDP timeout varies by router. Some set it at 30 seconds. Some at 60. Some at 120. Enterprise-grade routers often allow you to configure it.

Here is how this causes problems. Your phone registers with the VoIP provider, creating a NAT mapping. The provider records the phone's public address (the router's address and the port NAT assigned). Between registration refreshes, if no calls are in progress, there may be no SIP traffic flowing for a while. If the NAT timeout is shorter than the interval between registration refreshes or keep-alive messages, the NAT mapping expires.

Now the phone thinks it is registered, but the NAT mapping that allowed the provider to reach it is gone. Inbound calls fail because the provider sends the INVITE to the old NAT mapping, which no longer exists. The phone eventually re-registers, the mapping is recreated, and things work again, until the next quiet period when the mapping expires again.

The symptom is phones that randomly become unreachable for inbound calls, usually when they have been idle for a while. Outbound calls work because making a call creates a new NAT mapping. But inbound calls fail until the phone re-registers.

The fix

There are two approaches, and you should ideally do both.

First, reduce the phone's re-registration interval or enable SIP keep-alive messages (OPTIONS pings or CRLF keep-alives) at an interval shorter than the router's NAT timeout. If the router times out NAT entries after 60 seconds, configure the phone to send a keep-alive every 30 seconds. This keeps the NAT mapping alive.

Second, if your router allows it, increase the UDP timeout for SIP traffic. Many business-class routers let you set application-specific timeouts. Setting the SIP UDP timeout to 300 or 600 seconds gives much more margin.

DNS: the overlooked bottleneck

Your router typically acts as the DNS server for devices on your network. When a phone needs to resolve your VoIP provider's server address, it asks the router, and the router either responds from its cache or queries an upstream DNS server.

If DNS resolution is slow, it directly affects VoIP in two ways.

Registration delays. When a phone boots up, it needs to resolve the address of the SIP registrar before it can register. Slow DNS adds seconds to the boot process. If DNS is unreliable, registration can fail entirely, and the phone sits there unable to make or receive calls until the DNS issue resolves.

Call setup delays. Each outbound call requires the phone to resolve the address of the SIP proxy (unless it caches the result). Slow DNS adds delay to call setup. If you notice a consistent lag between dialing and hearing ringback, slow DNS is a possible cause.

What to check

Log into your router and see which upstream DNS servers it is configured to use. If it is using your ISP's DNS servers, those are usually adequate but can occasionally be slow or unreliable. Consider adding a well-known public DNS service (like 1.1.1.1 or 8.8.8.8) as a secondary.

If you have separate VLANs for voice and data, make sure the DNS server configuration in the DHCP scope for the voice VLAN is correct. A phone that gets the wrong DNS server, or no DNS server at all, in its DHCP lease will have registration and call setup problems.

DHCP: different settings for different VLANs

DHCP is how devices on your network automatically receive their IP address, subnet mask, default gateway, and DNS server settings. Your router typically runs the DHCP server, although in some environments, a separate server handles it.

If you have set up VLANs to separate voice and data traffic (which, as we covered in that post, is highly recommended), your router needs to serve different DHCP configurations for each VLAN. The voice VLAN gets one IP address range, one set of DNS servers, and potentially one set of VLAN-specific options. The data VLAN gets different settings.

Many VoIP phones also use DHCP options to discover their provisioning server, the server that provides the phone's configuration, firmware updates, and phone directory. The most common are DHCP option 66 (TFTP server address) and option 150 (also TFTP server, Cisco-specific). If these options are not configured in the DHCP scope for the voice VLAN, phones may boot but fail to pick up their configuration, resulting in phones that register but have missing features, wrong extensions, or outdated firmware.

Common DHCP problems

IP address exhaustion. If the DHCP pool is too small and all addresses are leased, new devices cannot get an address. The phone plugs in and cannot connect to the network. This is more common than you might think in growing offices.

Long lease times. A DHCP lease of 24 hours means a device that was temporarily on the network holds an address for a full day after it disconnects. In environments with visitors or devices that connect intermittently, long lease times can contribute to address exhaustion. For voice VLANs, a lease time of 4 to 8 hours is usually appropriate.

Wrong gateway or DNS. If the DHCP configuration for the voice VLAN points to the wrong default gateway, voice traffic will not route correctly. If it points to the wrong DNS server (or no DNS server), phones will fail to resolve server addresses.

When to upgrade your router

The router is often the oldest and most neglected piece of networking equipment in an office. It was set up when the internet connection was installed, possibly years ago, and it has been running untouched ever since. Here are the signs that your router is a bottleneck.

You cannot disable SIP ALG. If SIP ALG is causing problems and your router does not offer a way to disable it, the router is working against you. A router that cannot be configured to stop breaking your VoIP traffic needs to be replaced.

No Quality of Service support. If your router has no QoS features, voice traffic competes equally with everything else for your internet bandwidth. During busy periods, large downloads or cloud backups will degrade call quality. A router with QoS lets you prioritize voice traffic on the WAN link, which is where congestion is most likely to occur.

CPU is maxed out. If you can check your router's CPU utilization (many have a web interface that shows this), and it is regularly above 80 or 90 percent during business hours, the router is struggling to process traffic quickly enough. High CPU on the router adds latency to every packet passing through it, voice included.

Old firmware with no update path. Router firmware vulnerabilities are common and serious. If your router's manufacturer has stopped releasing firmware updates, you are running known-vulnerable software on the device that sits between your network and the internet. Security aside, old firmware also means bugs that cause VoIP problems (like SIP ALG issues) will never be fixed.

Throughput mismatch with your ISP. If you have upgraded your internet connection but your router cannot handle the new speed, the router becomes the bottleneck. A router rated for 100 megabits of throughput (with firewall and NAT active) will limit a 500 megabit internet connection to 100 megabits. Our Bandwidth Calculator can help you figure out how much throughput your office actually needs so you can size a replacement correctly. This is more common than you would think, because router throughput ratings are often listed under ideal conditions that do not reflect real-world traffic with firewall inspection, NAT, and QoS all active.

Cannot handle VLAN routing. If you have implemented VLANs on your switches but your router cannot route between them (inter-VLAN routing), you need either a router that supports this or a layer-3 switch. Without inter-VLAN routing, devices on different VLANs cannot communicate, which limits the usefulness of your VLAN deployment.

What to look for in a replacement

If you determine that your router needs to be upgraded, here is what matters for a VoIP-friendly environment.

SIP ALG that can be disabled (or better yet, a router from a vendor that does not include SIP ALG at all).

QoS with support for DSCP marking and priority queuing on the WAN interface. The router should be able to read DSCP values on packets from your VoIP phones and prioritize them.

Adequate throughput with all features enabled. Check the rated throughput with firewall, NAT, QoS, and VPN (if you use one) all active. That number, not the headline "up to" throughput, is what your network will actually get.

VLAN support and inter-VLAN routing capability, if you are running or planning to run VLANs.

Configurable UDP timeouts for NAT and firewall state tables.

Reliable DHCP server with support for multiple scopes (one per VLAN) and DHCP options for phone provisioning.

Current firmware from a vendor with a track record of regular updates.

Business-class routers from vendors like Ubiquiti, MikroTik, Fortinet, Cisco, and others meet these requirements. The specific choice depends on your budget, your technical comfort level, and whether you have someone to manage it. But any of them will be a significant improvement over the ISP-provided residential router that many small offices are running.

The router in context

Your router sits at a critical junction. On one side, your local network with its switches, VLANs, and cabling. On the other side, the internet path to your VoIP provider. Every voice packet crosses the router twice: once on the way out, once on the way back. If the router adds latency, drops packets, corrupts SIP messages, or lets firewall rules and NAT timeouts interfere with call flow, every call on your network is affected.

The good news is that router problems, once identified, are fixable. Disable SIP ALG. Configure QoS. Adjust UDP timeouts. Set up proper DHCP scopes. Run a VoIP quality test after each change to confirm it actually improved things. And if the router cannot do what you need it to do, replace it. The investment in a proper business-class router is modest compared to the ongoing cost of unreliable phone service.

This is Part 8 of the Your Office Network series. Next up: WiFi for Everything Else, covering access points, channels, interference, and how to make wireless work well for everything that is not a desk phone.