Hello,
Every time my internet goes down or do something on my router and when the internet is back all trunks cannot reconnect and say request sent and only option is to reboot entire FreePBX in order to be able to make calls. Any solution to somehow reboot server after request sent is detected or anything else? I’m out of ideas 
Thanks!
Please confirm that this is trunk registration related (after the internet is working again, you can make calls between extensions, access voicemail from an extension, etc.)
After causing the issue, see whether running
fwconsole restart
from a root shell prompt restores connectivity. If so and a monitoring script proves necessary, it could restart Asterisk instead of rebooting the whole server.
If REGISTER requests are really being repeatedly issued with no reply, the problem is likely a ‘poisoned’ NAT association in your router that is being kept alive by the continual retries.
Or, Asterisk may have considered the error to be ‘fatal’ and given up.
At the Asterisk console, type
pjsip set logger on
(for pjsip trunks) and/or
sip set debug on
(for chan_sip trunks).
See whether registration requests are going out and what replies, if any are being received.
If there is no reply to repeated requests, it’s probably a router NAT issue. If your router allows separate configuration of ‘unreplied’ and ‘assured’ timeouts, try setting unreplied down to e.g. 10 seconds. Otherwise, try having Asterisk wait longer between retries: set General Retry Interval (pjsip) or registertimeout (chan_sip) to e.g. 600 (10 minutes) and also set the qualify frequency to 600.
If you still have trouble, post router make/model. If the router doesn’t get a public IP on its WAN interface, post details (modem is configured as router, ISP does NAT, etc.)
If you have a static IP and your provider supports it, using IP authentication may avoid the need for registration altogether.
If you have trunks used only for outbound, most providers will accept calls without registration (though they still need to be authenticated).
If your provider can route calls to a SIP URI and you have dynamic DNS set up, you may be able to receive calls without registration, even with a dynamic IP address (you’ll also have to permit incoming INVITEs from the provider’s IP addresses through your firewall).
Thanks for the reply and sorry for a late reply!
In the mean time I got a really good deal on a small SSD so I replaced very old HD that was in my pfSense (router) and obviously I had to do a fresh install.
Now when I simulate internet outage ie. I unplug modem ethernet cable or reboot modem I still get all trunks to re-register. While the internet is out I can call between extensions and access FreePBX voicemail which means it has definitely something to do with trunk registration.
Below is the log what happens when I unplug the modem. As I configure pfSense more like it was before I’m hoping I won’t break anything because right is working just as it should.
freepbx*CLI> sip show registry
Host dnsmgr Username Refresh State Reg.Time
localphone.com:5060 Y 9440XXX 105 Registered Sun, 07 Apr 2019 12:45:28
sipgate.de:5060 Y 502XXXX 105 Registered Sun, 07 Apr 2019 12:45:31
seattle.voip.ms:5060 Y 101XXX 105 Registered Sun, 07 Apr 2019 12:45:28
3 SIP registrations.
[2019-04-07 12:48:43] NOTICE[2262]: chan_sip.c:30136 sip_poke_noanswer: Peer 'SipGate' is now UNREACHABLE! Last qualify: 182
freepbx*CLI> sip show registry
Host dnsmgr Username Refresh State Reg.Time
localphone.com:5060 Y 9440XXX 105 Request Sent Sun, 07 Apr 2019 12:47:14
sipgate.de:5060 Y 502XXXX 105 Request Sent Sun, 07 Apr 2019 12:47:17
seattle.voip.ms:5060 Y 101XXX 105 Request Sent Sun, 07 Apr 2019 12:47:13
3 SIP registrations.
[2019-04-07 12:49:18] NOTICE[2262]: chan_sip.c:15869 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #2)
[2019-04-07 12:49:19] NOTICE[2262]: chan_sip.c:15869 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #2)
[2019-04-07 12:49:22] NOTICE[2262]: chan_sip.c:15869 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #2)
[2019-04-07 12:49:58] ERROR[2262]: netsock2.c:305 ast_sockaddr_resolve: getaddrinfo("seattle.voip.ms", "(null)", ...): Name or service not known
[2019-04-07 12:49:58] WARNING[2262]: acl.c:835 resolve_first: Unable to lookup 'seattle.voip.ms'
[2019-04-07 12:49:58] NOTICE[2262]: chan_sip.c:15869 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #3)
[2019-04-07 12:49:58] WARNING[2262]: chan_sip.c:4065 retrans_pkt: Retransmission timeout reached on transmission 11a8deab37103e9973870dc96ed5d207@[::1] for seqno 1132 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 39212ms with no response
[2019-04-07 12:49:58] NOTICE[2262]: chan_sip.c:30136 sip_poke_noanswer: Peer 'voip_ms' is now UNREACHABLE! Last qualify: 45
[2019-04-07 12:50:18] ERROR[2262]: netsock2.c:305 ast_sockaddr_resolve: getaddrinfo("localphone.com", "(null)", ...): Name or service not known
[2019-04-07 12:50:18] WARNING[2262]: acl.c:835 resolve_first: Unable to lookup 'localphone.com'
[2019-04-07 12:50:18] NOTICE[2262]: chan_sip.c:15869 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #3)
[2019-04-07 12:50:18] WARNING[2262]: chan_sip.c:4065 retrans_pkt: Retransmission timeout reached on transmission 7a5a5110088cd8461fd3e2cc7685ddec@[::1] for seqno 1130 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 56227ms with no response
[2019-04-07 12:50:18] WARNING[2262]: chan_sip.c:4065 retrans_pkt: Retransmission timeout reached on transmission 00d7ce5a2703939a1a648fd67e4e7ac1@[::1] for seqno 1647 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 60029ms with no response
[2019-04-07 12:50:24] ERROR[2262]: netsock2.c:305 ast_sockaddr_resolve: getaddrinfo("sipgate.de", "(null)", ...): Name or service not known
[2019-04-07 12:50:24] WARNING[2262]: acl.c:835 resolve_first: Unable to lookup 'sipgate.de'
[2019-04-07 12:50:24] NOTICE[2262]: chan_sip.c:15869 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #3)
[2019-04-07 12:50:30] WARNING[2262]: chan_sip.c:4065 retrans_pkt: Retransmission timeout reached on transmission 00d7ce5a2703939a1a648fd67e4e7ac1@[::1] for seqno 1648 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
[2019-04-07 12:50:38] NOTICE[2262]: chan_sip.c:24599 handle_response_peerpoke: Peer 'voip_ms' is now Reachable. (46ms / 2000ms)
[2019-04-07 12:50:40] NOTICE[2262]: chan_sip.c:24599 handle_response_peerpoke: Peer 'SipGate' is now Reachable. (183ms / 2000ms)
[2019-04-07 12:50:45] NOTICE[2262]: chan_sip.c:15869 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #4)
freepbx*CLI> sip show registry
Host dnsmgr Username Refresh State Reg.Time
localphone.com:5060 Y 9440XXX 105 Registered Sun, 07 Apr 2019 12:50:31
sipgate.de:5060 Y 502XXXX 105 Registered Sun, 07 Apr 2019 12:50:32
seattle.voip.ms:5060 Y 101XXX 105 Registered Sun, 07 Apr 2019 12:50:45
3 SIP registrations.If the error messages stopped after the modem was back on line and then you did the last show registry, all is well now and and you’ll probably have to wait for the problem to recur (if it does) to find out what is wrong.
The issue is most likely the state’s table in pfSense retaining the old states which are no longer accurate when your ISP connectivity changes. I suspect the problem is more on the router (ie pfSense) than in FreePBX. Did you have firewall states previously set to Conservative and now in the default Normal mode?
Yes, so far all is well as it should be but with my old pfSense setup after internet was out I had to reboot FreePBX in order to re-register all trunks. Obviosly at the time I did not knew about fwconsole restart so can’t tell if that would work or not.
I never came across above modes in pfSense. And yes, this issue is definitely has to do with pfSense.
Thanks! I do not recall ever seeing or changing this, but will keep in my if things start go wrong after internet outage.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.