The above quote is incorrect, and it is the reason why you don’t understand why your setup works. You need not explicitly open up a port to allow incoming traffic to traverse your router and end up at your PBX or another device on your network. If that were the case, your computer could never receive a response when you reached out to a web-site, your Fire TV could never receive a response from Netflix when you pushed “play” on a movie, and your PBX could never receive a call.
Most modern routers use Linux at their core. Linux typically uses iptables to manage its NAT and Firewall. Iptables has a firewall rule entitled “allow related” and “allow established.” Those two rules are the magic that allows your PBX to work.
A register packet is how your PBX tells a remote system what your IP address is and the port to route calls to on your IP address. Register packets are not necessary for SIP to work, but you’d have to provide the remote system with your IP address and port number in some other manner (via a web interface, for example) if you didn’t do so with a registration packet.
A qualify (options) packet is how your PBX asks the remote system to verify that it is functioning and what functions it supports. Generally, if you configure Asterisk to send a qualify packet, and it doesn’t receive a response within 2000ms (2 seconds), Asterisk will assume that the trunk is down and will not send calls out on that trunk until it comes back up. Options packets are typically sent every 60 seconds, but again you can change that by changing the qualifyfreq= settings in the PEER details.
When your PBX sends out a register packet or a qualify (options) packet to a remote host from port 5060 (or to port 5060), iptables recognizes that the remote host is likely to respond at some point in the near future. Your router forwards the register or options packet out on a defined port from your public IP address (usually it starts with the port your PBX is using (i.e., 5060) unless some other device on your network got to it first, in which case it will pick some other random port), and then it will keep that port open for replies for a certain period of time.
If your PBX continues to send periodic traffic to that destination from the same source port to the same destination, your router will hold that port open for replies essentially forever. If your PBX doesn’t keep sending traffic, eventually, your router will expire the relationship and stop forwarding replies to that port back to your PBX.
A good router (most routers) will only keep the port open for replies from the destination IP address you reached out to. A crummy router will open the port to the entire world (i.e., any packet from any IP address to that port will get forwarded to the device on your network). I’ve seen consumer grade routers that appeared to do that, i.e., opening port 5060 to the world and thus allowing SIP scanning tools to attempt to hack the device.
“Allow related” and “allow established” are not the same as SIP ALG, but they could be confused with SIP ALG. “Allow related” means that IPtables looks at your traffic, attempts to determine what it is, and then allows packets that seem related to those packets back to the same device, sometimes on related ports. For example, if your router sees traffic relating to ports 5060, it might allow packets in ports 10,000 to 20,000 through, thus allowing RTP traffic through that are related to your 5060 traffic.
SIP ALG is different than allow related/established. Instead of simply allowing in traffic that would otherwise be discarded, SIP ALG changes the contents of the SIP Headers, in recognition of the fact that when SIP is configured strictly, SIP devices will ignore the UDP headers and instead respond to the addresses contained in the SIP headers.
If you’re behind a firewall and you aren’t configured correctly, the SIP headers could have internal IP addresses (192.168.1.xx) instead of external IP addresses. If your remote system is configured strictly, it will attempt to reply to those internal IP addresses, and you’ll never get the response. And, as noted above, even if you send out requests from Port 5060, your router might have to change the source port on the UDP headers if another device on your network is already using port 5060. Again, if the remote system attempts to respond to the port in the SIP headers (5060), the traffic may go to a port that your router may not be expecting, and the traffic may be dropped.
SIP ALG is almost never necessary because (1) most people do configure their SIP headers correctly (to show their public IP address instead of their internal private IP address) and (2) most SIP providers configure their systems to use the UDP headers rather than the SIP headers (NAT=Yes) because of the port altering that can occur when the source port is already being used by another device behind your router.
SIP ALG is also the cause of problems because, more often than not, SIP ALG rewrites the SIP headers incorrectly, i.e. by re-writing the wrong packets or writing with the wrong information. Added to the fact that its never necessary (see above) and SIP ALG is one of the most common causes of VOIP issues.
I’ve greatly oversimplified this post in order to answer your questions, and I’m confident that someone will reply to point out that I’ve gotten something wrong. But, basically, this is why your system works even though you haven’t explicitly forwarded a port. If you want to read more about it, I suggest that you google “iptables” and “allow related”.
