SIP ALG: Diagnose One-Way Audio Before You Disable It

SIP ALG: Diagnose One-Way Audio Before You Disable It

A call rings, connects and stays up, yet only one person can hear. A Session Initiation Protocol (SIP) Application Layer Gateway (ALG), usually shortened to SIP ALG, is often blamed immediately. Sometimes that diagnosis is right. Sometimes the real fault is a firewall rule, an incorrect media address, double Network Address Translation, a Virtual Private Network route or an endpoint using the wrong interface.

The safer response is not to toggle a production router setting and hope. It is to trace one failed call, capture a baseline and test one reversible change. This guide explains what SIP ALG does, what evidence points towards it and how to decide whether it should be on or off in your environment.

The call connects, but only one person can hear

Voice over Internet Protocol (VoIP) calls use more than one conversation between devices. Session Initiation Protocol (SIP) handles registration and call setup. The actual audio normally travels separately as Real-time Transport Protocol (RTP) streams.

That separation explains an important clue: a successful SIP response does not prove that audio can travel in both directions. A phone can receive a `200 OK`, show an active call and still advertise an unreachable address for one RTP stream. The other party hears silence because its media packets are going to the wrong place or being blocked on the way.

Before changing anything, write the symptom precisely:

• Which party cannot hear: the internal user, the external caller or both?
• Does it affect inbound calls, outbound calls or both?
• Does the failure begin immediately or after hold, transfer or several minutes?
• Is it limited to one site, one router, one handset type or one network such as office Wi-Fi?
• Does the same user work correctly on mobile data or another internet connection?

“One-way audio” is a symptom class, not a root cause. Direction and scope turn it into usable evidence.

What SIP ALG changes while a call crosses the edge

Most business endpoints use private Internet Protocol (IP) addresses that are not reachable directly from the public internet. Network Address Translation (NAT) lets many internal devices share a public address. Ordinary NAT can rewrite IP and port information in packet headers, but SIP may also carry addresses and ports inside its message body.

An ALG tries to understand that application data. A SIP ALG may inspect SIP messages, rewrite addresses or ports, track a call state and open temporary media paths through a firewall. Depending on the product, related functions may be labelled SIP helper, SIP inspection, SIP transformation or SIP passthrough.

The intention is reasonable. Problems arise when the intermediary’s assumptions do not match the endpoints, provider, NAT traversal method or call path. It may rewrite a value that an endpoint has already made reachable, maintain an incomplete state, mishandle unusual formatting or interfere with a session border controller (SBC) that is already controlling signalling and media.

The signalling fields worth comparing

A packet capture or provider trace may show whether values change between the local and wide-area sides of the firewall. Inspect fields such as:

• `Via`, which identifies where SIP responses should be sent through the transaction path.
• `Contact`, which tells another SIP element how to reach the user agent for later requests.
• `Record-Route` and `Route`, where proxies intentionally keep themselves in the signalling path.
• The connection and media lines in Session Description Protocol (SDP), which advertise where RTP should be sent.

A changed value is not automatically corruption. NAT-aware devices and SBCs legitimately alter call information. The question is whether the stored or transmitted value matches the supported design and leads to a reachable destination.

Why encrypted signalling changes the investigation

SIP over Transport Layer Security (TLS) encrypts signalling between the two TLS peers. An intermediary that is not terminating that encrypted session generally cannot inspect and rewrite the protected SIP and SDP content in the same way it handles unencrypted SIP. Product behaviour varies, so verify the configured inspection path and the firewall vendor’s documentation rather than assuming the setting is irrelevant or harmless.

Read the symptom without jumping to the cause

The pattern around a failure helps determine where to look first.

Registration expires or incoming calls stop ringing

If endpoints repeatedly lose registration, compare registration intervals, NAT binding timeouts and keep-alive behaviour. Look for inconsistent `Contact` values or responses returning to an old port. SIP ALG may be involved, but an overly short firewall timeout, duplicate credentials or an endpoint sleeping without push support can look similar.

Calls establish but audio travels in one direction

This pattern increases the value of inspecting SDP and RTP. Check whether either side advertises a private, stale or wrong-interface address. Then confirm whether packets are transmitted towards that address and whether return packets cross the firewall. A media pinhole that opens in one direction only can implicate edge handling, but provider media anchoring and local host firewalls must also be checked.

Calls fail only after hold or transfer

Hold, resume and transfer can create new SIP transactions and updated SDP offers. A device that handles the original `INVITE` but mishandles a re-`INVITE` or `UPDATE` may break audio only after the call state changes. Capture the complete journey, not just the first ten seconds.

One model fails while every other endpoint works

This narrows the investigation towards endpoint configuration, firmware, codec negotiation or its NAT traversal method. Do not make a site-wide firewall change solely because one handset behaves differently. Reproduce the fault with a second unit and compare its messages with a working endpoint.

Follow one failed call from REGISTER to RTP

A structured trace is more useful than a generic online SIP ALG detector because it shows what happened on your actual route. Capture only with proper authorisation and protect call metadata as operationally sensitive information.

Use this sequence:

1. Identify one reproducible journey. Record the calling number or test identity, destination, time, endpoint, connection type and expected result.
2. Confirm registration. Note the registrar, transport, source address and port, expiry interval and whether registration remains stable long enough to test.
3. Follow the initial `INVITE`. Check the responses in order. A completed setup commonly progresses through provisional responses to a successful final response and acknowledgement.
4. Compare SDP offers and answers. Record the advertised media addresses, RTP ports and negotiated codecs. Flag private addresses offered to a remote party unless a documented media relay makes that design valid.
5. Observe RTP in each direction. Count or graph the two streams. Determine whether the silent side sends no packets, sends them to the wrong destination or sends them correctly but receives none.
6. Check teardown and state changes. Include hold, resume, transfer and hang-up if the incident appears after one of those actions.

Capture at both sides of the edge device when possible. If the LAN-side message contains the intended address but the WAN-side message contains a different unusable value, the change happened at or near the edge. If both sides already contain the wrong value, investigate endpoint or SBC configuration first.

Build a baseline that can survive scrutiny

A useful before-and-after test must be repeatable. “It seemed better after the reboot” is not enough for a permanent network decision.

Create a compact baseline with:

• router or firewall model, firmware and active configuration version;
• WAN type, public address behaviour and every NAT boundary in the route;
• SIP transport: User Datagram Protocol (UDP), Transmission Control Protocol (TCP) or TLS;
• endpoint type and version for a desk phone, desktop softphone and mobile softphone where used;
• current SIP ALG or helper state, including policy-specific inspection profiles;
• provider or PBX address, media ranges and supported NAT traversal approach;
• results for registration, inbound call, outbound call, two-way audio, hold, resume, attended transfer and unattended transfer;
• timestamps and trace references for each failure.

Repeat each important call more than once. Intermittent NAT or timing faults can make a single success misleading. Run tests long enough to cross the interval at which the real failure normally appears.

The controlled SIP ALG change drill

Changing an edge security device can affect every voice endpoint at a site. Treat the test as a small maintenance change rather than an informal toggle.

1. Get authority and choose a window. Confirm the person responsible for the network approves the change. Avoid peak call periods and tell affected users what is being tested.
2. Save a restorable configuration. Export or checkpoint the current configuration. Record the exact SIP inspection, helper or policy setting rather than relying on a screenshot with no context.
3. Set acceptance criteria. Define what must pass: stable registration plus successful inbound, outbound, two-way audio, hold and transfer tests on representative endpoints.
4. Set the rollback trigger. Examples include loss of registration across the site, emergency-call policy risk, failure of previously working endpoints or any change that cannot be explained during the window.
5. Change one variable. Disable, bypass or adjust only the authorised SIP ALG function. Do not simultaneously replace DNS, alter codecs, update firmware and change firewall rules.
6. Clear stale state carefully. Existing NAT and SIP sessions may preserve the previous behaviour. Follow the vendor-supported method for clearing relevant sessions or restarting affected endpoints; do not reboot unrelated infrastructure without need.
7. Repeat the identical test set. Use the same accounts, destinations, endpoint types and directions captured in the baseline.
8. Compare the traces. Confirm not only that audio is audible but also that signalling values and RTP destinations now follow the expected path.
9. Keep or roll back on evidence. Retain the change only if the defined tests pass and no regression appears. Otherwise restore the saved state and continue investigating.

This is the practical answer to “Should SIP ALG be on or off?”: use the state supported by your provider, firewall and call architecture, then prove it with representative traffic. There is no responsible universal setting for every network.

Prove the fix across every endpoint journey

A desk phone working after the change does not prove that every user journey is healthy. Edge behaviour can vary by transport, device and network path.

Desk phones on the office LAN

Test multiple extensions if they traverse different switches, virtual LANs or policies. Include a call held beyond the usual failure interval. Confirm that power-saving, registration refresh and transfer behaviour remain stable.

Desktop softphones

Repeat calls on the normal wired or Wi-Fi connection and through the company Virtual Private Network (VPN) if that is a supported working mode. A split-tunnel route may send signalling and media through different edges, so note the actual path rather than assuming it.

Mobile softphones

Test office Wi-Fi, another trusted Wi-Fi network and mobile data. Confirm inbound ringing after the app has been backgrounded as well as when it is open. Mobile push notification delivery and SIP registration lifecycle are related to reachability but are not the same as an ALG test.

Call features that renegotiate media

Exercise hold, resume, blind transfer, attended transfer and any supported call recording or conferencing path. These functions can produce new offers, answers or media destinations that a basic two-minute call never reaches.

Record a pass or fail for each journey, plus the evidence reference. This prevents an early success on one phone from becoming an untested site-wide conclusion.

Cases where the ALG is not the whole story

If disabling or bypassing SIP ALG changes nothing, the baseline still has value. It lets you move to the next likely cause without guessing.

Double NAT and carrier-grade NAT

A second router, cellular gateway or upstream carrier NAT can introduce another state boundary. Draw the path from endpoint to provider and identify every translated address. Changing the office firewall cannot correct an unreachable address introduced elsewhere.

Media rules and asymmetric routing

SIP signalling may use a small known set of destinations while RTP uses a broader negotiated port range. Confirm rules in both directions and make sure return traffic follows the same stateful edge where required. Multi-WAN failover can produce an unexpected public address or asymmetric path.

Wrong local interface or VPN route

An endpoint with Ethernet, Wi-Fi and VPN interfaces may advertise the wrong address. Compare its SDP with the operating system’s current routes and the application’s network-selection settings.

Codec or early-media confusion

A failed codec negotiation more often causes a rejected setup or no usable media than a simple ALG signature, but traces should still confirm the offered and selected codec. Also distinguish ringback or announcements before answer from RTP after the final response.

SBC and managed-firewall policy

An SBC may intentionally anchor signalling and media, normalise SIP and control topology exposure. A managed firewall may use a supported SIP inspection profile as part of the provider’s design. Coordinate changes with the party that owns that architecture. Bypassing a component without understanding its role can remove a working control rather than fix a fault.

Turn the result into a supportable network decision

Close the incident with more than “ALG disabled”. Record:

• the original symptom and affected scope;
• the before-and-after traces or call identifiers;
• the exact configuration object changed;
• acceptance tests performed and endpoint versions;
• the result, including any remaining failure;
• the configuration backup and rollback method;
• the owner and review date, especially before a firmware, provider or network change.

If the ALG was the cause, this record helps prevent it being re-enabled accidentally during a router replacement. If it was not, the evidence keeps support teams from repeating the same speculative change.

Diagnose first, then decide

SIP ALG can cause genuine registration, call-setup and one-way-audio faults, but the symptom alone does not prove it. Separate signalling from media, inspect the addresses each side advertises, establish a repeatable baseline and alter one authorised variable with a rollback path. The result should be a traceable network decision, not folklore.

If you want a contained endpoint test after an edge change, use a small SessionCloud trial group to repeat registration, inbound, outbound, hold, transfer and mobile-push journeys across managed desktop and mobile softphones. That gives your team a defined acceptance set before a wider rollout.