We have an ongoing and intermittent issue with our FreePBX, it will occasionally stop receiving calls and stop allowing outgoing calls. This is easily fixed by restarting the router that the FreePBX is connecting through but is a concern as it may take some time before we are aware of the issue, during which time customers are unable to phone us.
Is there a way we can monitor for the connection dropping out? (note that the Internet connection doesn’t drop out, just the FreePBX stops working)
I have checked the logs on the FreePBX and when we make an outgoing call during a failure it produces the following:
[2014-05-30 10:03:03] VERBOSE[C-00040129] chan_sip.c: – Got SIP response 480 “Temporarily Unavailable” back from 22.214.171.124:5060
[2014-05-30 10:03:03] VERBOSE[C-00040129] app_dial.c: – SIP/MNF-SIP-OUT-1-000402ef is circuit-busy
[2014-05-30 10:03:03] VERBOSE[C-00040129] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)
However, this is only produced when we make a call, nothing seems to be logged when the connection initially stops working.
I’m hoping there is some kind of tool (preferably Windows-based) that we can run from another PC on our LAN that will periodically check for a connection to 126.96.36.199:5060 and will produce a warning to a log file, event log or send an email when the connection stops working.
Any ideas greatly appreciated!
Ideally you want to do a protocol test to make sure SIP is open on that IP, not just a ping. That is what the qualify frequency does in the trunk. If you put in 20 seconds every 20 seconds it will test the trunk. You will see messages in the log if the trunk gets lagged or is unavailable.
I would add an entry in the logger for a syslog source and run some type of syslog server like kiwi that can look for different events and alert you. If you happen to be running an NMS such as What’s UP Gold, Paessler or Solar Winds Orion they all have this ability to. You could also write a script that would parse the Asterisk log and then mail you if you are handy in Perl, Python, BASH or some other scripting language. Personally as a non-programmer I find Python as easy to deal with as BASIC if you ever took a computer class that made you learn that language.
Thanks for the reply, SkykingOH. A test of protocol access is what I am hoping for, ping tests always work even when the PBX isn’t working correctly and, as I understand it, a test using Telnet doesn’t work either.
I have a syslog server on a NAS that I can use to capture the data from the FreePBX (provided I can figure out how to get the FreePBX server to log to the syslog server!)
At present our trunks have qualify=6000 in them, which is what the provider recommends. Doing some digging I have found suggestions that qualify should be removed from the trunks as they can be marked as being unavailable and the PBX stops trying to reconnect. Do you think it could be worth a go removing the qualify line?
I haven’t seen anywhere in the Asterisk logfiles a message that the trunk has gone offline as a result of the qualify test failing, do you happen to know what text gets logged so I can search for it?
I’m afraid I’m a newbie when it comes to FreePBX and linux in general so I apologize if my questions sound stupid, I have been Googling all day but seem to be getting nowhere!
You can’t “telnet” a UDP port, if you use UDP5060 or UDP4569. As suggested, you can script something to run every n times and you can use nmap, e.g.
nmap -sU -p5060 and if the output is good, do something, if not, do something else, like throw it into syslog, email…
Alternatively, instead of running nmap, you could “ask” asterisk the status of the port everyone once in a while, e.g.
asterisk -rx "sip show peer " | grep Status
That should show something like this below;
Status : OK (6 ms)
Example bash script:- quick and dirty one
/usr/sbin/asterisk -rx "sip show peer $peername" | grep Status | grep OK
if [[ “$?” -ne “0” ]]; then
echo "Not good, do something"
echo "Good, do nothing"
Hope this helps
it sure sounds like the router is slamming port 5060 shut - neither your provider nor the pbx are aware of this until one end or the other tries to make a call. drop the qualify time on the trunk to 25 seconds (as skykingoh mentioned) and see if the problem goes away. many routers use 30 seconds as the default udp timeout and your current 6000 (6 minute) qualify time doesn’t keep the port open.
Perhaps sipsak could help here, you can check for an open SIP register, both yours and your providers, kinda of like a directed udp telnet/netcat test with useful results and a whole lot more . . . (That’s the SAK in the name )