I have a strange issue I was hoping to get some suggestions on. I have 5 Cisco 7940G extensions at my beach house that are connected via VPN to a FreePBX system at the main site. There are also 2 Polycom extensions at the remote site. (VVX 201 and a VVX 311) The main site is my city house which has a FreePBX server version FreePBX 13.0.197.28 running Asterisk Version: 13.29.2
I set this up to experiment with a couple years ago. At that time I used 2 routers running an older OpenVPN version to setup the VPN. TCP-based application traffic over the VPN has never been a problem, ever. However, getting the phones to register and stay registered was always a challenge but since it was experimental I didn’t spend a whole lot of time on it. I did run across the configuration info in the Can not get Cisco Phones to Register thread and implemented that. (turn nat enable on, and add the directive into the pjsip config file) However the phones would on occasion lose registration.
Anyway OpenVPN released a new version 2.5.2 which fixes a bunch of security holes and I upgraded the routers I used running dd-wrt with it, then ALL the phones stopped registering completely. After a lot of investigation and experimentation I determined that there’s a bug in newer OpenVPN to where it uses the wrong MTU on ARM architecture creating black holes in the routing path for certain sizes of packets. It’s possible to fix that via configuration directive which then got the phones to start registering but still the phone registration was iffy and the extensions would lose registration. After replacing one of the Polycoms (a VVX 400) and doing some more work I finally figured out that what was going on was during periods of high UDP packet loss on the path over the Internet was when the failing to stay registered problems were the worst. I switched the OpenVPN vpn over to using TCP transport and now the Polycom’s get and stay registered even when the Net is busy, but the 7940s refused to do it. All phones are running the latest firmware from their respective manufacturers.
I finally tried turning off the nat hack in the 7940 config file and then the phones started attempting to register into FreePBX but show as status Unavailable. Turning the nat hack back on and rebooting a phone and now there are no log entries at all in the log on the FreePBX server showing any connection attempts. Switching the driver over from chan_pjsip to chan_sip and turning off the nat hack allows the phones to register in just fine.
And the TCP transport on the VPN SEEMS to help as well in keeping the phones registered all of the time. Perhaps the TCP/IP stacks in the VPN routers are superior to whatever passes for a TCP/IP stack in the 7940s.
So my question to anyone who uses the 7940’s (or HAS used them) it seems as though there is some sort of timing issue or some such interaction would you agree with this or is there some other Gotcha in those phones I need to look at?
Pings through the VPN show a RTT of 45ms on average, pings outside of the VPN are similar. I already use chan_sip for my POTS-to-SIP gateway hardware (no I do not run sip trunks) and I have tried getting chan_pjsip to work with that hardware with no luck - and little interest from any developer into looking into any bugs in chan_pjsip - so clearly as long as I have this hardware I’ll be using chan_sip. The only part of the phone network that touches the Internet is the OpenVPN gateways, I don’t port-forward 5060 from the outside to the inside, etc. so there is little security risk that acts as an incentive to upgrade FreePBX. I am much more interested in this from a networking standpoint.