Hello, I have been looking at how to test if our phone lines are up or down. We’ve thought about using a third-party service such as Twillio to create a script and call a DID to test the line every thirty minutes. Another option we’d like to see if it is possible, can FreePBX generate an outbound external call to call itself and test for dial tone? Any help or info would be greatly appreciated, thank you in advance.
This idea cries out for us to ask, “why?” because it sounds like there is an underlying problem to be solved.
Yes you can script calls on timers and such but I wouldn’t do it unless you have a really good reason.
2 Likes
Well, we’ve had instances in which our phone lines were down and no one knew about it until it was mentioned that no phone calls had come through. That’s when we realized that we need some form of test to dial out and then back to ensure that lines aren’t down without us knowing. I don’t know what the best way to go about this, and hoping that there are others that could provide input as to what worked for them.
What are your phone lines (POTS, PRI, VoIP from ISP, VoIP over public internet)? If POTS, how connected (copper pairs from central office, cable MTA, fiber ONT, etc.)?
When your lines went down, did they come back by themselves? If not, what did you do to get them fixed? How long was a typical outage? How often did they occur?
Hi Stewart, the phone line is a VoIP from an ISP and when the lines went down, it was that the provider’s telephony router was powered off. The lines outage lasted for several hours and at that time we had no alarm to notify us that calls weren’t coming through. It wasn’t until someone had to physically go to the server room and do a physical inspection. Lastly, I mentioned testing every three minutes, I meant to say every thirty minutes. We would even be ok with an every hour call for a script to run if that is the solution that has worked best. Otherwise, any feedback would be great to have. Thank you all in advance.
If there’s a router that needs monitoring is rather setup a ping monitor.
Assuming default settings (including qualify on the trunk), the system should have reported it as ‘unreachable’. If the last failure was less than a week ago, you should be able to see the unreachable message in /var/log/asterisk/full*.
If your previous failures also resulted in loss of communication with the server, a simple script that follows the log file (or polls it periodically) could check for unreachable and send you an alert.
The last failure was past that, unfortunately. However, I have been looking at to see if contexts can be used as a part of the script so that FreePBX can make an external outbound call and call itself. Is this in the realm of possibility? I haven’t been able to find something like what I am describing.
Sorry for joining in so late, but there’s an underlying issue that you might want to explain to us so we can actually help you.
The system knows if a phone is unreachable or not - you can get that information from the asteriskinfo report.
The problem (to my way of thinking) is that there are seven layers of connectivity, and each of them has a different way of messing you up.
With trunks, on the other hand, you may or may not find out about a trunk being down until you try to send a call. There is a “script on trunk fail” option on the trunks, so you could use that.
Hi Dave, our provider’s modem was powered off but our freepbx server was up. It wasn’t until we realized that calls weren’t coming through that we had a problem.
Does your provider’s modem have an IP address?
If so, that would be the most reliable way of checking. If not, you need to explain more about how the system is connected.
There are lots of tools that test for the presence of a device on a specific network. At the “when you have a really big hammer…” end is Nagios (which is a lot of daemon to watch this problem) which can use a host of different tests and go crazy when something goes wrong, and at the “here’s your stick - you figure it out” end would be something like a crontab based ‘ping’ script that sends an email when the other end goes down. In between are a myriad of solutions that might scale to what your needs might be.
Nagios will scale well, but it’s a LOT of solution for a little problem. The ping script doesn’t scale as well, but it would be quick and easy.
Yes they do have an IP address. How we’re connected: Provider has a router that connects to our FreePBX server with a digium card. We have Zabbix monitoring the FreePBX server but not for dial tone. We realized that if the provider’s router is powered but phone lines are down, we would have no way to know, at least not in a prompt manner. I hope this explains our setup if, I do appreciate your time. If there are any other details, please clarify.
Is this an FXO/FXS setup or are they delivering a PRI/T1?
You will never monitor for “dial tone”. If you are on a single-line setup, you’re going to be getting B+ from the “wall end” of the connection. This is almost impossible to check for (in my experience) but DAHDI might have an arcane way to monitor B+ from the interface. The Asterisk guys (like @jcolp and the venerable crew at Asterisk) might have some ideas on that.
If you’re on a PRI, the DAHDI interface will tell you when the PRI/T1 loses clock and the interface will go RED. There are ways to monitor that.
If the provider’s modem has an IP address and it’s powered off, it shouldn’t respond to the ICMP message, so that should be a valid test.
So, as I mentioned before, check for what you want to check for is not an approach that it likely to yield a good result. You need to expand your scope and look for things that will actually give you a feel for what’s working and what’s not.
As I ruminate more on this - one thing you can try is setting up a job that calls your number from a “well known but completely bogus” Caller ID (assuming you can do that) and watch for incoming calls on your PBX from that CID. If you don’t see one after a few minutes, ring an alarm. The call would be terminated immediately by the PBX (based on the inbound route killing the call instantly) but it would also fail if you called it while someone else was actually on the line (assuming it’s an FXS/FXO connection).
We’re on a PRI/T1 connection, and because of the last outage we also setup monitoring on the provider’s modem. The thing is that our provider is not the best at communicating, so we want to be ready if outage goes unnoticed by us. Hence we want to prevent a scenario in which our PBX is up and the modem is up giving us a false positive of Green on the DAHDI interface. What we thought of doing is seeing if freepbx can originate an outbound call to itself and look at logs for that call. If no call then we get a notification. I’m not sure if this is possible, but I hope it is or something along those lines can be done.
It doesn’t have to be FreePBX, but that would work.
Ok, that’s good to know that it is possible. We have Twillio in which we can use to make the calls, but we want to avoid the costs that would be associated with it. If it can be done through FreePBX, can it be done by creating a SIP extension and using one of our DIDs to call out and call another DID in the PBX? That’s the part where I am a little confused.
Bare bones possible solution,
Ssetup up a call-file dated a long time in the future that notifies as necessary.
Set up an inbound route DID/CID specific and send it to a custom context that ‘touches’ the call file n+1 MIN in the future and then hangs up the call .
Do that every n minutes.
The call wouldn’t ever have to ‘complete’ to do what you’re trying to do. The fact that the call rang from the DID/CID combo and was immediately rejected should be enough to satisfy the check.
On the Inbound Route, set the destination to “Terminate - SIT Tones” and the call will never complete (according to Twilio). Also, unless Twilio is actually charging for every second, the entire check would take less than a second, and most providers bill in 6-second increments.
@dicko @cynjut That is some great intel, thank you for that. I think a good path forward would be to use Twilio, I’ll have to see if they charge by the second or not.
hangup before answer results in 0 x $n = always $0
1 Like