We are looking for a solution … In brief, SIP phones register properly but outbound calls are always cut-off after about 30 seconds. Inbound calls are usually OK.
Imagine one Yealink SIP phone at two locations, each behind a Peplink Balance router (B210 at one location and B310x at another) running FW 8.1.3. Each of the SIP phones registers successfully to two different providers (voip.ms and callcentric.com. Port 5080 is in use with VOIP.MS and 5060 with Callcentric. VOIP.MS tech support advised to use TCP; UDP is used with Callcentric. TLS/encryption is not employed.
Interestingly, the “cut off behavior” is the same with both providers, with UDP and TCP, with ports 5060 and 5080, with two different SIP providers, and with two different ISPs (Spectrum & Comcast). The use of SFC does not seem to make a difference. Here’s the present setting for SIP at both locations:
TU very much @astryukov . We’ll give this a try. We didn’t think this should be necessary but as we look further at the description of this variable on page 222 of the FW manual it’s not clear what, precisely, this variable “does” – particularly in a single WAN or SFC environment. Can someone from Peplink provide some details?
In both modes the router aims to keep VoIP traffic on the same WAN the SIP session gets initiated on.
In standard mode the SIP headers get rewritten when sent over NAT WANs. In compatibility mode the headers are not rewritten.
Old VoIP systems weren’t designed for NAT situations and needed a SIP ALG to rewrite the headers.
Modern VoIP systems expect NAT, but they all have different techniques for crossing NAT routers.
Personally I nearly always find myself turning off SIP ALG (so setting to compatibility mode) when troubleshooting VoIP.
That’s helpful. Thank you. I’m curious why that would be necessary in a single WAN situation or when all SIP traffic is being directed to SFC. I also don’t understand why outbound calls would be cut off in a half or a minute or a bit more.
But … meanwhile … “compatibility mode” seems to have solved the problem. :<)
I have spent far too many hours staring at SIP network captures to remember exactly why, but SIP has a 32 sec time out for ACK messages after a SIP Invite. So typically what we’re fault finding is the return ACK path and why - for whatever reason, it doesn’t get through / back.
In standard mode, with SIP IP headers being rewritten, there is a lot of opportunity for misaddressed SIP messages, and since Peplink firewalls are all stateful (allowing return traffic on ports that have been opened outbound by LAN based services), that rewrite isn’t needed.
Network captures are the only way to work out for sure what was going on if you have the enthusiasm…
We continued the testing this morning. Outbound calls are terminated in 32 seconds after changing to “compatibility mode.” Must be something else. Hugely frustrating. Oh well …
We found the culprit. During troubleshooting VOIP.MS had directed that the protocol be changed from UDP to TCP. In the interim, we changed from the default “Standard Mode” to “Compatibility Mode.” The “winning combination” was UDP and "Compatibility Mode. Thanks to all for your comments. Problem solved.
@TK_Liew : I’m wondering why the default is not “Compatibility Mode” when that’s the setting that appears to be best under most circumstances.
We need to cater to the old VoIP system. Like @MartinLangmaid said, old VoIP system is not designed for NAT situations and needed a SIP ALG while most of the modern VOIP systems do have intelligent to handle the NAT situation. So, the default setting will be Standard mode.
