SIP ALG and WebRTC: Stop One-Way Audio for PBX Admins

SIP ALG is one of those “helpful” router features that quietly creates chaos in modern voice networks. It was designed for older SIP assumptions (simple NAT, predictable endpoints, SDP-directed media). In WebRTC-to-SIP environments, it often does the opposite of what you want: it rewrites signalling and SDP in ways that break ICE expectations, distort port mappings, and produce the classic “call connects but audio fails” outcome.

This guide is a practical field checklist for PBX admins. The goal is not to debate theory—it’s to give you a repeatable way to prove whether SIP ALG is involved, disable it safely, and confirm you’ve actually fixed the media path.

1) What SIP ALG actually does (and why it backfires)

A SIP ALG typically inspects SIP packets and attempts to “fix” NAT traversal by rewriting headers and SDP fields (IP addresses, ports, sometimes even payload-related details). That can be survivable in basic SIP-only estates.

In mixed WebRTC-to-SIP setups, the risk increases because:

• WebRTC endpoints are ICE-directed (candidate gathering + connectivity checks decide the media path).
• Many SIP environments are still SDP-directed (“send RTP to what’s in SDP”).
• ALG meddling can make the two models disagree about where media should go.

The result: signalling looks fine, but RTP/SRTP lands in a black hole.

2) The symptom pattern that screams “ALG”

Treat these as strong indicators—not proof on their own:

• Works on home Wi-Fi, fails on corporate Wi-Fi
  Corporate networks are where ALGs, firewalls, and “helpers” tend to be most aggressive.
• One-way audio that flips direction by network
  If direction changes depending on where the caller sits, you’re dealing with network traversal behaviour, not dialplan logic.
• Randomly “fixed” by rebooting the router
  That often points to state-table/NAT behaviour, not PBX configuration.

3) Prove it quickly with a controlled A/B test

Before changing any PBX settings, do a simple A/B:

1. Place a call from a network you control (where you can change router settings).
2. Capture a PCAP on the PBX/SBC side (or at least on the client LAN if that’s all you can access).
3. Disable SIP ALG on the router/firewall.
4. Place the same call again and compare.

For fast confirmation on the media side, Wireshark’s RTP tools are still one of the quickest “stop arguing, start proving” methods:
Wireshark RTP Player (Playing VoIP Calls)

If one-way audio disappears immediately after disabling ALG, you have your culprit—or at minimum, you’ve removed a major source of SDP/RTP distortion.

4) How to disable SIP ALG without guesswork

Different vendors call it different things: SIP ALG, SIP Helper, SIP Fixup, SIP Transformations, etc.

A common example (MikroTik) calls it SIP Helper and provides a clean disable path:
Mikrotik SIP ALG = SIP Helper (OnSIP)

Operational best practice:

• Disable ALG on the edge device actually doing NAT for the voice endpoints.
• If you have multiple layers (ISP router + firewall), disable it on both (or bridge the ISP router).

5) The “gotcha”: SIP ALG can mask deeper NAT problems

Sometimes the ALG “sort of” made things work by accident. Disabling it can expose underlying NAT issues you still need to address properly (and permanently), such as:

• Source-port rewriting that breaks RTP return paths
• UDP timeout values that are too aggressive for real-world VoIP
• Inconsistent NAT policies across interfaces/VLANs

If you run pfSense, Netgate’s VoIP NAT notes are worth bookmarking because they focus on the boring-but-decisive realities that often drive one-way audio:
Configuring NAT for VoIP Phones (Netgate/pfSense)

6) Post-fix verification checklist (don’t stop at “seems fine”)

After disabling SIP ALG, validate with evidence:

• SDP sanity: are the advertised IPs/ports believable for the call leg?
• RTP presence: do you see RTP/SRTP in both directions?
• Consistency: does it work across at least two networks (home + corporate/LTE)?
• Regression check: does audio remain stable across multiple calls (not just the first “lucky” one)?

If you want one repeatable habit: always confirm media direction with a capture before you change the next setting. It saves hours.

7) The deployment rule that prevents this class of pain

If you’re responsible for the overall design, the most stable approach is:

• Keep “helpers” off
• Make NAT behaviour explicit (port ranges, timeouts, static ports where justified)
• Anchor media consistently where the environment demands it
• Treat WebRTC traversal as a first-class requirement, not a best-effort feature

When you do that, SIP ALG stops being a mysterious gremlin and becomes what it should be: disabled by default.

For more articles like this, visit SoftpageCMS.