The SIP protocol is commonly used for IP telephone communications. Unfortunately it’s notorious for having issues with NAT traversal. Even some major vendors can’t seem to get it right. [Stephen] had this problem with his Cisco WRVS4400N router. After a bit of troubleshooting, he was able to come up with a workaround that others may find useful.
The router had built in SIP ALG functionality, but it just didn’t work. [Stephen] was trying to route SIP traffic from a phone to an Asterisk PBX system behind the router. The router just couldn’t properly handle these packets regardless of whether SIP ALG was enabled or disabled.
[Stephen] first tried to change the SIP port on the external VOIP phone from the default of 5060 to something else. Then he setup port forwarding on the router to the Asterisk box to forward the traffic to the Asterisk system on the original port. This sort of worked. The calls would go through but they would eventually drop after about 20 seconds.
The only thing that [Stephen] could get to work completely was to change the SIP port in Asterisk’s sip.conf file using the “bindport” directive. He changed it to some random unused high port number. Then he setup port forwarding on the router to forward incoming UDP packets on that port to the Asterisk system. This worked fine, but now all of the original phones behind the router stopped working because they were configured to use the default port of 5060.
Rather than re-configure all of the phones in the organization, [Stephen] made one change on the Asterisk system. He setup an iptables rule to forward all incoming traffic on UDP port 5060 to the new SIP port. Now all of the phones are working with minimal changes across the organization. It’s a lot of hassle to go through just because the router couldn’t handle SIP correctly, but it gets the job done.
I might have been tempted to set the port forwading rule to send the inbound high port to 5060 and leave all of the local stuff as is.. or did I misunderstand the issue.
That’s the easy way…. or better yet, replace the router with pfsense. For a lot of phones, one can use a cheap outdated redundant dual-nic server (tons on ebay for < $200) and pfsense. These will easily handle a sizable call center and have a lot of nice features like working qos, url blocking (YouTube, etc), and load balancing multiple Internet connections.
psfense, ipcop, endian.. the list is of firewall distros is extensive, but the idea is the same…. old server… a bunch of NICs, firewall distro… careful setup… sleep easier at night.
Hi, OP here. That doesn’t work because if the server thinks its local port is 5060, it’ll communicate that port back to the endpoint and the endpoint will try to use 5060, which doesn’t work. SIP is an ugly mess.
Working as a network tech that does a lot of VoIP deployements, I get this type of problem on a daily basis, its extremly frustrating and every single router/firewall has some implementation of SIP ALG that breaks sip in one way or another. There is a post on voipinfo that outlines what each router is doing and how its breaking the traffic.
Our go to method is a pfsense alix 2d3 device which is predictable and reliable.
UDP VOIP NAT IP SIP WTF !
Oh Easy!
>Universal Datagram Protocol
>Voice Over Internet Protocol
>Network Address Translation
>Internet Protocol
>Session Initiation Protocol
>Why The Face!
Agreed very easy so why not put them in the blog in the first place ? . I forgot ALG? FFS
https://www.youtube.com/watch?v=wXlvy3sTTBk
That is all.
Another way is to enable encryption for SIP (supported by asterisk and most phones),
stupid routers can’t fuck with your data if they can’t parse it – and it’s a very good idea to enable some security for external phones anyway.
OP here. Agreed – but the endpoint and/or the PBX (I don’t recall which now) did not support TLS. real world problems.
Has it ever occur to you guys that it is the fault of SIP that it is embedding IP addresses in its protocol that is causing all the trouble?
I mean when SIP is invented, NAT is roaming the earth already. Why on earth was SIP not made itself compatible with NAT? By compatible, I mean without the need of any ALG. There are plenty of ways out there to obtain a your external IP and there are also plenty of ways to keep the session alive with NAT and get voice call initiated successfully without ALG involved.
That’s exactly the problem – pretty sure I covered that in the write-up. In any case, I didn’t develop the protocol – just the workaround ;-)
You can configure Asterisk to bind to multiple ports, the iptables rule isn’t needed.
Just add a second Transport entry to pjsip.conf with a bind on that different port.
OP here. I don’t recall which version of Asterisk this was – probably 2.2 or 2.8, I think. In any case, that feature was not available on the customer’s production PBX and I wasn’t at liberty to upgrade. Real world problems.