September 10, 2018 between 7:50AM and 9:59AM EDT, my FreePBX system running version FreePBX 13.0.194.10 lost connectivity with the VoIP service provider and with all the extensions.
These error, warning and notice start to show up in the asterisk log (/var/log/asterisk/full) at 7:50AM.
ERROR[2401] netsock2.c: getaddrinfo("VOIPTRUNKPROVIDER", "(null)", ...): Temporary failure in name resolution
WARNING[2401] acl.c: Unable to lookup 'VOIPTRUNKPROVIDER'
NOTICE[2401] chan_sip.c: Peer '254' is now UNREACHABLE! Last qualify: 325
These set of error, warning and notice keep repeating for 23 times and gone away completely at 9:59AM.
They come and go on their own.
No network connectivity issue was noticed any the time.
When the issue was happening, no incoming call nor outgoing call was successfully terminated.
Checked with the SIP trunk provider and they said they couldn’t find any fail registration at their end neither!
Does anyone have any idea of what this issue might be?
I am thinking could the lost of connectivity to the SIP trunk provider cause our server to also lose connection with the extensions.
If this was the case then I can just sign up for trunk service from another provider to use as fail over.
You say that your PBX lost registration with your sip provider too, but they didn’t see that happen? That’s a little weird. I don’t believe that losing connection with your sip provider would cause your pbx to also lose connection to your phones. And your server clearly did lose connection with the phones. Is your server local, or is it hosted?
If it’s hosted, I think it’s likely that you had some internet connectivity problems. We are dealing with a similar issue, and after tons of troubleshooting, it came down to unstable internet. If this issue keeps coming up, download ping plotter and see if the drops in service correlate to when your extensions go down.
But those other errors are interesting too. Maybe it’s a DNS problem. I don’t know much about that, so someone else may need to chime in.
My phones are all in-house. They are on the same network with the FreePBX server.
It’s unlikely the internet was the cause for the issue as we have SMNP monitor running inside to outside (via internet) and there was no indication of any packet/ping lost during the indicated time window.
The SIP trunk provider is VoIP.MS. Their answer to my question is unclear!
I asked them 2 time for the log of our server’s registration with theirs and they would just saying there is nothing!
You had a DNS issue. The PBX SIP stack could not resolve DNS for your provider which causes the SIP stack to lockup until it can resolve the DNS. This is a issue with chan_sip in asterisk but the issue does not exist with pjsip.
There has been another recurrent of the issue. The 1st sight of the issue started at 9:05AM EST Sept. 24, 2018 and the last sight at 9:15AM the same day. @tonyclewis , do you think the DNS issue would also lead to the issue with my desk phone losing connection with the FreePBX server (in parallel with the FreePBX server losing connection to the trunk provider)?
This is the Asterisk full log when the issue 1st happen this morning.
[2018-09-24 09:04:46] NOTICE[2401] chan_sip.c: Peer ‘’ is now UNREACHABLE! Last qualify: ___
[2018-09-24 09:04:46] VERBOSE[2369] chan_sip.c: Extension Changed [ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:05:57] ERROR[2401] netsock2.c: getaddrinfo(“chicago4.voip.ms”, “(null)”, …): Temporary failure in name resolution
[2018-09-24 09:05:57] WARNING[2401] acl.c: Unable to lookup ‘chicago4.voip.ms’
[2018-09-24 09:06:17] ERROR[2401] netsock2.c: getaddrinfo(“chicago4.voip.ms”, “(null)”, …): Temporary failure in name resolution
[2018-09-24 09:06:17] WARNING[2401] acl.c: Unable to lookup ‘chicago4.voip.ms’
[2018-09-24 09:06:17] NOTICE[2401] chan_sip.c: Peer '’ is now UNREACHABLE! Last qualify: 11
[2018-09-24 09:06:17] NOTICE[2401] chan_sip.c: Peer '’ is now UNREACHABLE! Last qualify: 10
[2018-09-24 09:06:17] NOTICE[2401] chan_sip.c: Peer ‘___’ is now UNREACHABLE! Last qualify: 10
[2018-09-24 09:06:17] VERBOSE[2369] chan_sip.c: Extension Changed ___[ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:06:17] VERBOSE[2369] chan_sip.c: Extension Changed [ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:06:17] VERBOSE[2369] chan_sip.c: Extension Changed [ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:06:17] VERBOSE[2369] chan_sip.c: Extension Changed [ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:06:17] VERBOSE[2369] chan_sip.c: Extension Changed [ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:06:17] VERBOSE[2369] chan_sip.c: Extension Changed [ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:06:37] ERROR[2401] netsock2.c: getaddrinfo(“chicago4.voip.ms”, “(null)”, …): Temporary failure in name resolution
[2018-09-24 09:06:37] WARNING[2401] acl.c: Unable to lookup ‘chicago4.voip.ms’
[2018-09-24 09:06:37] NOTICE[2401] chan_sip.c: – Registration for ‘[email protected]’ timed out, trying again (Attempt #3)
[2018-09-24 09:06:37] VERBOSE[2401] chan_sip.c: Registered SIP '’ at 10..8.144:5060
[2018-09-24 09:06:37] WARNING[2401] chan_sip.c: Retransmission timeout reached on transmission b50ecbd0ec4941d99f895ac26db38caf for seqno 103 (Critical Request) – See Home - Asterisk Documentation
Packet timed out after 20021ms with no response
[2018-09-24 09:06:37] WARNING[2401] chan_sip.c: Retransmission timeout reached on transmission a98797737ed64bcdbff3d69600d91f26 for seqno 103 (Critical Request) – See Home - Asterisk Documentation
Packet timed out after 20021ms with no response
[2018-09-24 09:06:37] WARNING[2401] chan_sip.c: Retransmission timeout reached on transmission 0fe8c36b2f884f6396dc98ef2b3685ea for seqno 103 (Critical Request) – See Home - Asterisk Documentation
Packet timed out after 20021ms with no response
[2018-09-24 09:06:37] WARNING[2401] chan_sip.c: Retransmission timeout reached on transmission 20afc84288654ff4b1a7c99cc714e348 for seqno 103 (Critical Request) – See Home - Asterisk Documentation
Packet timed out after 20021ms with no response
[2018-09-24 09:06:37] WARNING[2401] chan_sip.c: Retransmission timeout reached on transmission 5a20eb4013654aed94941eebf45ceb80 for seqno 103 (Critical Request) – See Home - Asterisk Documentation
Packet timed out after 20020ms with no response
[2018-09-24 09:06:37] WARNING[2401] chan_sip.c: Retransmission timeout reached on transmission b93706ec0093430da12cac5a94e3f4dc for seqno 103 (Critical Request) – See Home - Asterisk Documentation
Packet timed out after 20020ms with no response
[2018-09-24 09:06:37] VERBOSE[2369] chan_sip.c: Extension Changed [ext-local] new state Idle for Notify User ___ (queued)
[2018-09-24 09:06:37] NOTICE[2401] chan_sip.c: Peer '’ is now UNREACHABLE! Last qualify: 9
[2018-09-24 09:06:37] NOTICE[2401] chan_sip.c: Peer '’ is now UNREACHABLE! Last qualify: 11
[2018-09-24 09:06:37] NOTICE[2401] chan_sip.c: Peer '’ is now UNREACHABLE! Last qualify: 22
[2018-09-24 09:06:37] NOTICE[2401] chan_sip.c: Peer ‘VoIP-MS’ is now UNREACHABLE! Last qualify: 16
[2018-09-24 09:06:37] NOTICE[2401] chan_sip.c: Peer '’ is now UNREACHABLE! Last qualify: 11
[2018-09-24 09:06:37] VERBOSE[2369] chan_sip.c: Extension Changed ___[ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:06:37] VERBOSE[2369] chan_sip.c: Extension Changed ___[ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:06:37] VERBOSE[2369] chan_sip.c: Extension Changed [ext-local] new state Unavailable for Notify User ___
[2018-09-24 09:06:37] NOTICE[2401] chan_sip.c: Peer '’ is now Reachable. (10ms / 2000ms)
I am going to put in a DNS resolution monitoring and run it continuously until the next occurrence of the issue. This should rule-in OR rule-out the DNS lookup failure as the cause.
Yes.
It’s a known flaw in chansip, and when it happens the whole of the chansip driver locks up and all your extensions, including local, become unreachable.
You can move to pjsip and avoid the issue altogether.
As a workaround you can also, if possible, register your trunk to an IP address instead of a hostname.
