FreePBX 14.0.13.4
Current Asterisk Version: 13.27.1
Hosting this FreePBX server in the cloud, phones are remotely connecting to this server over the internet. It seems like the phones are overlapping somewhere, as they seem to unregister and register back after several minutes. They have 10 phones, two different models and it seems to happen to all of the extensions. Here is the entries in the /var/log/asterisk/full log:
[2019-09-11 10:01:27] VERBOSE[11892] res_pjsip_registrar.c: Added contact 'sip:[email protected]:21845' to AOR '2001' with expiration of 120 seconds
[2019-09-11 10:01:27] VERBOSE[11892] res_pjsip/pjsip_configuration.c: Endpoint 2001 is now Reachable
[2019-09-11 10:01:27] VERBOSE[11892] res_pjsip/pjsip_options.c: Contact 2001/sip:[email protected]:21845 is now Reachable. RTT: 34.260 msec
[2019-09-11 10:01:28] VERBOSE[11892] res_pjsip_registrar.c: Added contact 'sip:[email protected]:21846' to AOR '2006' with expiration of 120 seconds
[2019-09-11 10:01:28] VERBOSE[11892] res_pjsip/pjsip_configuration.c: Endpoint 2006 is now Reachable
[2019-09-11 10:01:28] VERBOSE[11892] res_pjsip/pjsip_options.c: Contact 2006/sip:[email protected]:21846 is now Reachable. RTT: 36.851 msec
[2019-09-11 10:02:31] VERBOSE[11893] res_pjsip/pjsip_options.c: Contact 2008/sip:[email protected]:21836 has been deleted
[2019-09-11 10:02:31] VERBOSE[11893] res_pjsip/pjsip_options.c: Contact 2001/sip:[email protected]:21837 has been deleted
[2019-09-11 10:02:31] VERBOSE[11893] res_pjsip/pjsip_options.c: Contact 2007/sip:[email protected]:21831 has been deleted
[2019-09-11 10:02:31] VERBOSE[11893] res_pjsip/pjsip_options.c: Contact 2006/sip:[email protected]:21830 has been deleted
[2019-09-11 10:02:31] VERBOSE[11893] res_pjsip/pjsip_options.c: Contact 2009/sip:[email protected]:21834 has been deleted
[2019-09-11 10:03:12] VERBOSE[11892] res_pjsip/pjsip_configuration.c: Endpoint 2007 is now Unreachable
[2019-09-11 10:03:12] VERBOSE[11892] res_pjsip/pjsip_options.c: Contact 2007/sip:[email protected]:21842 is now Unreachable. RTT: 0.000 msec
[2019-09-11 10:03:13] VERBOSE[11892] res_pjsip/pjsip_configuration.c: Endpoint 2008 is now Unreachable
[2019-09-11 10:03:13] VERBOSE[11892] res_pjsip/pjsip_options.c: Contact 2008/sip:[email protected]:21843 is now Unreachable. RTT: 0.000 msec
[2019-09-11 10:03:15] VERBOSE[11892] res_pjsip/pjsip_configuration.c: Endpoint 2001 is now Unreachable
[2019-09-11 10:03:15] VERBOSE[11892] res_pjsip/pjsip_options.c: Contact 2001/sip:[email protected]:21845 is now Unreachable. RTT: 0.000 msec
[2019-09-11 10:03:25] VERBOSE[11892] res_pjsip/pjsip_configuration.c: Endpoint 2007 is now Reachable
[2019-09-11 10:03:25] VERBOSE[11892] res_pjsip/pjsip_options.c: Contact 2007/sip:[email protected]:21842 is now Reachable. RTT: 24.395 msec
[2019-09-11 10:03:27] VERBOSE[11892] res_pjsip/pjsip_configuration.c: Endpoint 2001 is now Reachable
[2019-09-11 10:03:27] VERBOSE[11892] res_pjsip/pjsip_options.c: Contact 2001/sip:[email protected]:21845 is now Reachable. RTT: 23.588 msec
[2019-09-11 10:03:30] VERBOSE[11892] res_pjsip/pjsip_configuration.c: Endpoint 2002 is now Unreachable
[2019-09-11 10:03:30] VERBOSE[11892] res_pjsip/pjsip_options.c: Contact 2002/sip:[email protected]:21840 is now Unreachable. RTT: 0.000 msec
[2019-09-11 10:03:57] VERBOSE[11892] res_pjsip_registrar.c: Added contact 'sip:[email protected]:21847' to AOR '2008' with expiration of 120 seconds
[2019-09-11 10:03:57] VERBOSE[11892] res_pjsip/pjsip_configuration.c: Endpoint 2008 is now Reachable
[2019-09-11 10:03:57] VERBOSE[11892] res_pjsip/pjsip_options.c: Contact 2008/sip:[email protected]:21847 is now Reachable. RTT: 35.802 msec
Hopefully I got all the information needed, if not, please let me know. Any suggestions here? I have tried to lower the requalify period from 60 seconds to 15, but it looks like there is no change there.
This looks like a router is losing the NAT session somewhere. Do the phones stay up when in use?
There are a few questions that might help narrow the scope of your search:
Are you using a 1:1 NAT anywhere, even though it’s not recommended?
If so, do you believe that 1:1 NAT is or is not actually NAT?
Are you using NAT on all of the interfaces between the phones and the server?
Do you have all of your extensions and servers set up to use NAT?
Are you using any kind of firewall rules on the server end?
Are you using the Integrated Firewall? If not, do you believe it’s because you’re too smart to use a proven tool to help you keep your system safe?
How is your RTP structure set up? (Generally, we don’t need a poster-sized drawing, as nice as that could be).
Is your RTP “NAT aware”?
Have you turned off SIP-ALG and other SIP “Helpers” (these are like having a three-year-old “Helper”)
What kind of firewall/routers are you using? Some work easier than others.
So, as you can see from this half-hostile, half-kidding line of questioning, you probably need to look at your network structure and NAT setup to make sure everything is working? If you have questions, pop back in and ask before you waste a lot of time.
I was on the same page as far as it being a NAT related issue. I’m more suspect on the network where the phones are than the setup of the FreePBX server side. I am most certainly using the built in firewall, intrusion detection, all that jazz is turned on. As far as I know, the phone side of the network is behind a Zyxel USG firewall and as far as I’m aware, all SIP related settings are disabled. It does only seem to affect registrations bouncing. No dropped calls or issues with active calls, those appear to work just fine. I will continue to investigate on that network with the phones, I just wanted to make sure there wasn’t anything configuration-wise on the FreePBX side I needed to look at or change. I think to try to rule it out, I will build another user/phone that I can have behind a totally different network and internet source and see if it bounces the same way.
That statement really drives home the NAT session losing it’s place. I have some Xyzel routers in the warehouse, but I’ve never used one between a NATted server and NATted phones.
You do need to make sure the server side is using all of the right NAT settings. You can set them in your trunks (you may need to for your ITSP) and you can set them “per channel driver” in the Advanced Tab. Make sure you are setting the “local networks” correctly too. Without that, the “server side” firewall could block your return message traffic.
Be sure the phones are advertising their “external” address correctly. I think a SIP DEBUG (DEBUG PJSIP ? - I can never remember - I just use command completion) and a chance to watch the traffic will give you a heads up on which part of the “keep-alive” conversation is failing. If one side is sending keep-alive packets to a non-routable address (through the Internet), then you’ll have found your culprit.
Thanks for the clarification on this issue. I agree this is definitely a NAT related issue and I think it stems from that side with the phones. The test phone I built hasn’t bounced a single time and registration sticks. So I really don’t think its a configuration on the server side, definitely a problem NAT related on the internet side where the phones are coming from. Since the phones are all connecting remotely, the global settings for them are to use the external address and ‘none’ on the internal address. This is a hosted VPS so there shouldn’t be any internal/local network traffic.
