Current Location ：
NAT and Firewall Traversal for SIP: What Breaks and How to Fix It
Ask any voice engineer what causes the most avoidable tickets and the answer is rarely the PBX. It is the path between the PBX and the outside world. SIP was designed by people who assumed every endpoint had a real address, and network address translation was invented by people who assumed protocols would carry their own addresses through. Both assumptions are wrong in opposite directions, and the gap between them is where calls go silent in one direction while the phone still rings. This article explains what actually happens to a SIP conversation behind a firewall, which fixes genuinely work, and which ones only appear to.
Why SIP and NAT Disagree
SIP separates signalling from media. The signalling carries addresses in its headers and body; the media flows on separate ports chosen during the conversation. NAT rewrites addresses in the IP header, but it cannot rewrite the addresses written inside the SIP payload unless something reads the protocol. So the firewall happily forwards a message that claims the caller is at a private address, and the far end sends audio to an address that does not exist on its network. The phone rings, the caller hears nothing, and every log on the system looks normal.
| Symptom | Likely cause | Where to look first |
|---|---|---|
| Registration succeeds, calls have no audio one way | Private address advertised in SDP | SDP body in the INVITE and 200 OK |
| Calls drop after 30 seconds | Session timers not relayed, ACK lost | SIP ALG behaviour, timer headers |
| Registration flaps every few minutes | Contact address rewritten or expires mishandled | REGISTER contact and Expires values |
| Works internally, fails from outside | Two different egress paths with different addresses | Routing table and outbound interface selection |
| Intermittent failures on one carrier only | Carrier expects a specific source port or range | Carrier requirement sheet versus actual ports |
What SIP ALG Actually Does
Many consumer and small business firewalls ship with a SIP application layer gateway enabled. The idea is reasonable: inspect SIP, rewrite the addresses, keep the media flowing. In practice, ALGs are written against a narrow reading of the standard, and they break encrypted signalling, mis-handle multi-line INVITEs, and rewrite fields the PBX relies on. When a deployment behaves differently depending on which firewall sits in front of it, the ALG is usually the reason. Turning it off is often the single highest-value change, provided the signalling path is handled deliberately instead.
- Disable SIP ALG before troubleshooting anything else, then retest from a clean state
- Keep signalling and media on predictable ports so firewall rules can be explicit
- Do not rely on the firewall to fix addresses the platform should be advertising correctly
- Document every port and range in use, and give that document to whoever manages the firewall
- Test from outside the network, not only between two internal extensions
The Options That Hold Up
There are three durable answers. The first is a session border controller at the edge, which owns the public address, normalises SIP, and relays media, so internal endpoints never need to be reachable. The second is configuring the platform with an explicit external address and a defined media range, then opening exactly those ports. The third is a VPN or private circuit, which removes the problem by removing the boundary. Each has a cost: an SBC adds a component to operate, static configuration needs discipline when the network changes, and private circuits constrain where endpoints can be.
Choosing Between Them
A single site with a stable public address and a cooperative carrier can live with static configuration for years. Multi-site estates, remote workers, and carriers that change media addresses mid-conversation are better served by an edge device that terminates the boundary in one place. The wrong answer is the one that appears to work in testing because the test happened to run from inside the network.
Redstone Approach
Redstone deploys IP-PBX platforms and gateways with documented port and address requirements, and supports session border controller placement at the network edge where the topology calls for it. We provide the firewall requirements in writing before cutover, and test signalling and media separately so that a partial success is never mistaken for a working deployment. No specification is assumed: the port plan is agreed against your actual network.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
