Session Initiation Protocol Application Layer Gateway (SIP ALG) is the most common hidden cause of VoIP call quality problems in business networks.
SIP ALG is a router feature that inspects and rewrites voice traffic as it passes through your firewall. It ships enabled by default on most commercial routers.
It’s designed to help VoIP calls traverse NAT. In practice, it corrupts the very packets it tries to fix, leading to dropped calls, failed registrations, and audio that only works in one direction.
Most VoIP providers recommend turning it off. For organizations running Microsoft Teams, cloud voice platforms, or SIP trunking environments, disabling SIP ALG is one of the first steps to stable call quality.
Fixing SIP ALG issues starts with understanding what it does, how to spot it behind VoIP problems, where to disable it on common routers, and why Teams deployments are especially sensitive to it.
What is SIP ALG?
SIP ALG combines two technologies: the Session Initiation Protocol (SIP) that manages voice sessions, and an Application Layer Gateway (ALG) that rewrites data packets as they cross your network boundary.
SIP is the signaling standard behind most modern voice platforms. It handles three core functions in any SIP-based call:
- Device registration: Connecting phones, softphones, and session border controllers (SBCs) to the voice platform.
- Call setup and teardown: Initiating, routing, and ending voice sessions between endpoints.
- Media negotiation: Determining which audio codecs and ports to use for the actual voice stream.
The ALG component sits inside your router’s firewall. Its job is to inspect SIP packets and rewrite IP addresses and port numbers as they pass through network address translation (NAT). NAT translates private internal IPs to public ones, and SIP ALG was originally designed to make sure the SIP signaling data stayed consistent through that translation.
The problem is that SIP ALG implementations vary widely across router manufacturers, and most are poorly executed. Instead of helping, the ALG modifies SIP headers and SDP body content in ways that break call setup, corrupt media negotiation, and cause endpoints to lose registration. Modern VoIP platforms use their own NAT traversal methods (STUN, TURN, ICE) that handle this without interference from the router.
How SIP ALG causes VoIP problems
When SIP ALG rewrites SIP packets, it changes destination addresses, port numbers, and contact headers inside the signaling data. If those changes don’t match what the VoIP platform or SBC expects, the call fails or degrades. The ALG operates silently, so the root cause isn’t always obvious from the user’s perspective.
The symptoms of SIP ALG interference follow a consistent pattern across environments:
- One-way audio: You can hear the other party, but they cannot hear you (or the reverse). This happens when the ALG rewrites the media port information incorrectly, so the audio stream only flows in one direction.
- Dropped calls: Calls connect but disconnect after a set interval, typically 30 to 60 seconds. This often occurs when the router’s firewall closes the UDP pinhole that the ALG opened, killing the media stream mid-call.
- Failed registrations: Phones intermittently lose their connection to the voice platform. The ALG modifies the REGISTER request in a way that prevents the server from detecting NAT, so keepalive messages never get sent.
- No incoming calls: Outbound calls work, but inbound calls go straight to voicemail or fail silently. This is a registration issue caused by the ALG rewriting contact headers.
- Degraded audio quality: Static, echo, choppy audio, or delays during conversation. Packet modification introduces jitter and latency that wouldn’t exist if the SIP traffic passed through unaltered.
Most routers ship with SIP ALG enabled by default. Many IT teams don’t realize it’s active until they start troubleshooting persistent call quality issues that don’t respond to standard network fixes.
Why SIP ALG matters in Microsoft Teams environments
SIP ALG is especially problematic in organizations running Microsoft Teams Direct Routing or SBC-based calling configurations. In these deployments, SIP signaling flows between the on-premises SBC and Microsoft’s SIP proxy in the cloud. The SIP proxy expects unmodified headers. When a router’s ALG rewrites those headers mid-transit, the Teams platform rejects the signaling or fails to establish the media path.
Microsoft’s own troubleshooting documentation for Teams calling issues identifies SIP ALG as an interference source and recommends disabling it on all edge routers and firewalls.
The issue is compounded by encryption. Teams Phone environments use TLS for SIP signaling and SRTP for media. SIP ALG cannot properly inspect or rewrite encrypted SIP messages. When it tries, the result is corrupted signaling that the Teams SIP proxy cannot parse. This makes SIP ALG interference even more likely in modern Teams deployments than in legacy unencrypted VoIP setups.
For any organization using Teams for external calling, disabling SIP ALG on every device between the SBC and the internet should be a baseline configuration step.
How to disable SIP ALG
The general process to disable SIP ALG is the same across most router platforms:
- Log into your router’s admin interface (typically via a browser at 192.168.0.1 or 192.168.1.1).
- Navigate to the firewall, NAT, or security settings section.
- Locate the SIP ALG toggle. It may be labeled SIP ALG, SIP passthrough, SIP Transformations, or SIP Helper depending on the manufacturer.
- Disable the setting and save.
- Reboot the router. Changes to ALG settings typically require a full restart to take effect.
After rebooting, place several test calls to confirm that registration holds and audio flows in both directions.
Router-specific guidance
Every SIP ALG router implementation is slightly different. Menu paths and terminology vary by brand, model, and firmware version. Below is a summary of where the setting typically lives for the most common enterprise and mid-market platforms, along with links to each vendor’s official documentation for current instructions.
Fortinet FortiGate
FortiGate firewalls process SIP traffic through either the SIP ALG (proxy-based) or a legacy SIP session helper (kernel-helper-based). On FortiOS 6.2.2 and later, both are disabled via the CLI. You also need to remove the SIP entry from the session helper list. Fortinet’s administration guide covers the full process, including how to verify that SIP ALG is no longer handling traffic after the change.
See Fortinet’s SIP ALG and SIP session helper documentation.
Cisco Meraki
Meraki MX security appliances do not implement SIP ALG. There is no setting to disable because the feature does not exist on the platform. If you are experiencing VoIP issues behind a Meraki MX, the cause is elsewhere (port forwarding, NAT configuration, or an upstream device).
See Cisco Meraki’s VoIP FAQ and troubleshooting guide for more information.
Ubiquiti UniFi
UniFi gateways (USG, UDM, UDM Pro) include a SIP ALG toggle in the gateway settings under the firewall or security section. The exact menu path depends on whether you are using the classic controller interface or the newer UniFi OS.
See Ubiquiti’s community documentation on SIP ALG for your specific hardware and firmware version.
SonicWall
SonicWall firewalls label the setting as “SIP Transformations” under the VoIP settings section. Disable SIP Transformations and increase the UDP connection timeout to 300 seconds under Firewall Settings to prevent the firewall from closing voice sessions prematurely.
See SonicWall’s VoIP optimization guide to learn more about both settings.
Netgear
On most Netgear routers, the SIP ALG toggle is found under WAN Setup or Security/Firewall in the advanced settings. Netgear ProSafe and Nighthawk models have different interfaces, so the exact path varies.
See Netgear’s support documentation for your specific model.
TP-Link
On newer TP-Link firmware (including Omada series), ALG settings are located under NAT Forwarding. Uncheck SIP ALG along with any other ALG options you are not actively using (RTSP, H.323).
See TP-Link’s ALG configuration guidance for model-specific instructions.
When to keep SIP ALG enabled
Disabling SIP ALG is the right call in most environments. But there are a few scenarios where it may need to stay on:
- Legacy VoIP systems: Older PBX platforms built before STUN, TURN, and ICE became standard may rely on ALG to traverse NAT correctly. Disabling it on these systems can cause connectivity issues. If you are running a legacy system and unsure, test in a controlled environment before making the change in production.
- Complex multi-NAT environments: Networks with multiple layers of NAT, firewalls, and routers may require ALG to keep SIP traffic routed correctly between segments. This is increasingly rare as NAT traversal techniques improve, but it still exists in some older network architectures.
- Specific provider requirements: Some VoIP providers require SIP ALG to be enabled for compatibility with their infrastructure. Always check with your provider before disabling. If your provider explicitly requires it, follow their guidance.
What to do after disabling SIP ALG
Turning off SIP ALG removes the most common source of interference, but a few additional settings help ensure consistent voice quality across your network:
- Enable QoS: Configure Quality of Service rules to prioritize voice traffic over other data. Tag VoIP packets with DSCP EF (46) so your network equipment handles them with the lowest latency and jitter.
- Set up port forwarding: If you are running an on-premises PBX or SBC, forward the SIP signaling port (typically UDP 5060) and the RTP media port range (typically UDP 10000–20000) to the correct internal device.
- Assign static IPs to voice devices: Phones and SBCs should use static IP addresses so the voice platform can always reach them. Dynamic IP changes can cause intermittent registration failures.
- Keep firmware current: Router manufacturers occasionally patch ALG-related bugs and improve NAT handling. Check for firmware updates after disabling SIP ALG to make sure you are running the most stable version available.
For cloud voice and hosted PBX environments, most of the NAT traversal complexity is handled by the provider. Disabling SIP ALG and enabling QoS are often the only two steps needed on the local network.
Eliminate common VoIP problems by changing one router setting
Most persistent VoIP call quality issues trace back to SIP ALG interference. Disabling it is the single most effective first step toward stable voice performance. Pair that with proper QoS configuration and current firmware, and the majority of dropped calls, one-way audio, and registration failures disappear.
For organizations running Microsoft Teams, cloud voice, or SIP trunking across multiple locations, getting the network foundation right is not optional. Momentum manages voice, network, and collaboration environments for 36,000+ enterprise locations, from architecture design through ongoing support.
Talk to a Momentum VoIP expert about optimizing your voice and network environment.
FAQs
What is SIP ALG?
SIP ALG stands for Session Initiation Protocol Application Layer Gateway. It is a feature built into most commercial routers that inspects and rewrites SIP packets as they pass through NAT. It was designed to help legacy VoIP systems maintain connectivity through firewalls, but poor implementations on most routers cause it to break SIP signaling instead.
Does disabling SIP ALG affect other network functions?
No. SIP ALG only targets SIP traffic. Disabling it has no impact on web browsing, email, file transfers, or any other network service. Other ALG functions (FTP, PPTP) operate independently and are not affected.
How do I know if SIP ALG is causing my VoIP problems?
The most common symptoms are one-way audio, dropped calls after a consistent interval (30–60 seconds), phones that lose registration intermittently, and incoming calls that fail or go straight to voicemail. If these issues resolve after you disable SIP ALG and reboot the router, it was the cause.
Is SIP ALG a problem for Microsoft Teams calling?
Yes. SIP ALG can interfere with Teams Direct Routing and SBC-based deployments by rewriting SIP headers that the Teams SIP proxy does not tolerate. Microsoft recommends disabling SIP ALG on all edge devices in Teams Phone environments. The issue is worse in Teams because signaling is encrypted with TLS, and SIP ALG cannot properly parse encrypted packets.
