Post
How to prove whether SIP ALG is modifying your calls
The reliable way to detect SIP ALG is to compare the same SIP message before and after it crosses the firewall. If the SIP payload changes—rather than only the packet’s outer IP address and port—something in the path is inspecting and rewriting the application data.
That proves modification. It does not, by itself, prove the modification caused the fault.
This distinction matters. “SIP ALG detected” is often treated as a diagnosis, but it is only an observation until the changed field can be connected to a failed registration, missing response, incorrect route or broken media path.
What SIP ALG actually changes
SIP is unusual because network addresses can appear in two places at once: in the IP packet carrying the message and inside the SIP or Session Description Protocol (SDP) text. Ordinary network address translation changes packet headers. A SIP application-level gateway can inspect the message body, rewrite embedded addresses and ports, and open temporary paths for signalling or media.
| Location | Typical information | Why a gateway may inspect it |
|---|---|---|
| IP and UDP/TCP headers | Packet source and destination | Normal routing, firewalling and NAT |
| Via | Where SIP responses should travel | Response routing through NAT |
| Contact | Where later SIP requests may be sent | Reachability of the phone or PBX |
SDP c= line |
Media connection address | Where the far end sends RTP |
SDP m= line |
Media port and formats | Opening or translating a media path |
Products use “SIP ALG”, “SIP inspection”, “VoIP helper” and “SIP session helper” for overlapping features. Do not rely on the label alone. Fortinet, for example, documents both a SIP ALG and a separate SIP session helper, with both capable of performing NAT on addresses inside SIP messages.
Capture the same call at two points
The cleanest test uses simultaneous packet captures immediately inside and outside the firewall.
phone or PBX → inside capture → firewall/NAT → outside capture → carrier
Use a test call with a precise timestamp and a destination you control. Synchronise the capture devices’ clocks first. If the PBX generates the SIP traffic, capture near the PBX; capturing only at an unrelated phone may show a different call leg.
In Wireshark, start with the sip display filter. Select the test call, note its Call-ID and then filter on that value so retransmissions and responses remain together. Do not assume all SIP uses UDP port 5060. The signalling may use another port, TCP or TLS.
Keep the unmodified captures private. SIP messages can expose telephone numbers, usernames, public addresses, authentication material and call-routing details. Work from sanitised extracts when sharing evidence.
A small before-and-after example
Suppose the inside capture contains this abbreviated offer:
Contact: <sip:[email protected]:5060>
c=IN IP4 10.20.30.40
m=audio 12000 RTP/AVP 0 8 101
The corresponding message outside the firewall contains:
Contact: <sip:[email protected]:5060>
c=IN IP4 203.0.113.20
m=audio 41024 RTP/AVP 0 8 101
| Difference | What it proves | What it does not prove |
|---|---|---|
| Contact host changed | A device rewrote SIP header content. | That the new Contact is unusable. |
| SDP connection address changed | A device rewrote the advertised media address. | That RTP fails to reach it. |
| SDP media port changed | A device translated or substituted the advertised RTP port. | That the matching pinhole is absent. |
The example addresses are reserved for documentation. In a real capture, compare the complete messages and confirm they have the same Call-ID, CSeq and branch context before treating them as the same request.
Changes worth investigating
Concentrate on differences that alter where a later packet will be sent:
- a Contact address that points to the wrong public interface;
- a Via rewrite inconsistent with the packet’s observed source;
- an SDP address belonging to another WAN or an unreachable private network;
- an advertised media port with no matching firewall or NAT state;
- removed Route or Record-Route information;
- rewriting on one request but not its retransmission; or
- a malformed message after the payload length changes.
The rport mechanism defined by RFC 3581 deserves special care. It lets a SIP client request that the response return to the source address and port observed by the server. Seeing received and rport values in a response can therefore be correct standards-based behaviour, not evidence that a firewall has corrupted the message.
Run a controlled A/B test
Once the captures prove that a gateway changes SIP, test whether those changes matter.
- Save the failing capture and the firewall configuration state.
- Choose one repeatable call path and record its expected result.
- Change only the relevant SIP inspection setting.
- Clear or allow old sessions to expire using the vendor’s documented procedure.
- Repeat the same call and capture it at the same two points.
- Compare signalling, SDP and RTP—not just whether the handset rang.
Do not change SIP inspection during active business calls merely to test a theory. Treat it as a controlled network change with a rollback plan. Some platforms apply ALG behaviour through a security profile, a session helper or both, and an existing session may retain the old behaviour.
When paired captures are not available
A single capture can still raise a strong suspicion, especially when the PBX generated a private address but the wire capture shows a public one. It cannot prove which device made the change if several routers, managed firewalls or carrier NAT layers sit between the capture point and the destination.
Ask the carrier for a sanitised copy of the corresponding request or the values it received. Match the Call-ID and timestamp. A provider-side trace paired with a PBX-side trace can serve the same purpose as capturing both firewall interfaces.
If SIP uses TLS end to end, an intermediate firewall normally cannot read and rewrite the encrypted SIP payload. In that case, confirm where TLS terminates and compare traces at those endpoints. Do not weaken signalling security simply to make an ALG test easier.
The result should name the field
A useful conclusion is specific: “The firewall changed the SDP connection address from the PBX’s public voice address to the wrong WAN address, and RTP was then sent to that interface.”
“SIP ALG broke it” is not yet a useful conclusion. Name the message, field, before-and-after values, resulting packet path and A/B result. That turns a familiar suspicion into evidence someone else can verify.
For the broader diagnostic sequence, see NAT and firewall troubleshooting, packet captures for VoIP troubleshooting, and SIP headers explained.
Technical references
- RFC 3261: the SIP specification
- RFC 3581: symmetric SIP response routing and rport
- Fortinet: SIP ALG and SIP session helper
Published 17 August 2026. Test firewall changes in a controlled window and follow the documentation for the exact platform and software release.