So, I've been tasked with deploying SIP/VoIP to a small number of offices and it's been working out fairly well except that if you install several devices in my case Gigaset C610IP devices and/or Snom 821 they have been issues answering calls from time to time. I've been troubleshooting this for some time now as it only happens what seems randomly even though they get calls all day long. Interestingly enough making calls have been working fine. There are lots of reports and what seems to be random suggestions on how to fix these issues some which are totally wrong. Thankfully I've seen to nailed it down so I'm going to cover the common misinformation about this.
- SIP/VoIP ALG is bad do NOT use
- Proxies are not your solution 2015, they will usually make things worse
- NAT keep-alive only helps if you have one device in total
- QoS will not help if you're maxing out your download capacity
- Keep your device(s) up to date (install firmware updates!), this will help tremendously
- STUN doesn't really work reliably for VoIP/SIP and only seems to be a way for the device to figure out its external IP (which it will anyway unless its really old and buggy)
- Changing codecs will not fix anything else than audio quality (unless you're enforcing unsupported ones)
- PC clients (Mitel) seems to work with NAT much better without pretty much any interraction despite what the Internet says
More detailed information on why -insert bullet point- is bad
While Linux does have a SIP/VoIP connection tracker it modifies packets in a way that isn't RFC-compliant meaning that any model that's ~5 years old and newer will work properly with these enabled. Some router distributions ships these enabled by default (OpenWRT doesn't for instance) so make sure these are not loaded as it's the only way to disable these functions. Your device will figure out by itself if it's behind NAT or not due to how the SIP protocol works, try not to outsmart it.
These can be good in various situations but SIP/VoIP is usually not one of them, in all honestly I never god one to work properly with these phones at all.
Interestingly enough this seems to work on netfilter if you have one device but if you have several which all try to use port 5060 by default this makes things unreliably, that said it worked a lot better using netfilter than pf. Without going into deep packet inspection due to how UDP works in general it makes it hard for the connection tracker figuring out where packets should go and SIP/VoIP devices aren't forgiving at all.
QoS only controls egress traffic, at best your could start dropping packet that already hit your connection but that would be inefficient and doesn't make any sence. QoS is however highly recommended to deploy especially if you're on a cable or DSL connection.
While most vendors actually have some kind of auto update functionality it doesn't seem be triggered automatically in general, just make sure you're running the latest release/stable firmware available which will usually save you from unnecessary odd bugs.
For whatever reason STUN doesn't work as intended on neither of my firewalls. It wont help your data (RTP) connections either so I'm not sure what the intention were adding the functionality in the first place.
Mitel software clients (usually rebranded) seems to work just fine, I have no idea why but say they say... Don't try to fix what aint broken.
Getting your devices to work properly
- Assign static IPs (otherwise you'll have fun issues and portforward will stop working), locked by MAC address if you're using DHCP as the rest of us 2015.
- Forward 2 ports per device for SIP protocol control traffic (SIP secure uses +1), common practices are 5060+1 (device 1), 5062+1 (device 2) 5063+1 and so on.
- RTP needs 2 ports per call, however 19 ports seems to be the unwritten standard and works well. Usually you start at 10000-10018 (UDP) and work your way up.
- Enable NAT keep alive and make your your timeouts are longer than the actual NAT keep alive timer. In my case our service provider use 90 secs, OpenWRT uses 60 as default so that wont work. Running Linux this goes into /etc/sysctl.conf:
That seems to good enough in most cases, be aware that this may cause issues if you're using DHT protocols which usually are deployed by P2P applications.
- G.711 is unfortunately standard
- G.729(ab) is nicer on paper but it's covered with patents so it's a cost issue.
- G.722 however isn't and would provide a much nicer audio quality over G.711 however very few providers support this codec. This is the one you usually see mentioned/branded as "HD Audio" in VoIP/SIP documentation.
As a sidenote, there are multiple SIP attackers out there so it's wise to only allow your providers netblock on the data connections (5060, 5062 etc).