[asterisk-users] checking if a phone number is UP

Bryant Zimmerman BryantZ at zktech.com
Thu Feb 9 11:25:10 CST 2012



----------------------------------------
 From: "Carlos Alvarez" <carlos at televolve.com>
Sent: Thursday, February 09, 2012 11:25 AM
To: "Asterisk Users Mailing List - Non-Commercial Discussion" 
<asterisk-users at lists.digium.com>
Subject: Re: [asterisk-users] checking if a phone number is UP

A very interesting solution.  Is there any code you'd share for this? 
 We don't have inbound issues all that often (as far as we know), so I'm 
curious whether you had a lot of reliability issues before this, or 
possibly we have more problems than we believe. 

On Thu, Feb 9, 2012 at 7:59 AM, Bryant Zimmerman <BryantZ at zktech.com> 
wrote:
We designed our solution the following way.

We have several land line numbers hooked to an asterisk testing server.
The testing server places one call every X seconds per line to a number we 
want to test . We cycle through each number in our testing pool. Each  
number on average is tested once every 30 min this can be adjusted by the 
dial rate and the number of test lines in the outbound calling pool.  When 
a call comes from one of our test numbers our inbound dial plans log the 
call and busy's out. So the test call is not answered and no call charge is 
assessed per carrier.  To verify that a test succeeded the testing server 
checks the database after it gets a busy.  By design if a call comes in it 
is checked before any line counts are tested so this method never effects 
the customers line counts.   We also have a full audio/dtmf test that is 
run once a day per number. This means that the first test call of the day 
is actually answered and a DTMF and audio hand shake is done.  Both ends 
log the result in a database. 

We catch vendor issues with these methods and it allows us to open tickets 
and resolve issues before a customer knows there might be an issue. Our 
vendors hate the system as we tend to catch any hiccup they may be having 
as well. Several of them are mistified how we can open tickets on issues 
consistently before they know they have an issue. 
Bryant 

----------------------------------------
 From: "Aurimas Skirgaila" <a.skirgaila at gmail.com>
Sent: Thursday, February 09, 2012 9:34 AM
To: "Asterisk Users Mailing List - Non-Commercial Discussion" 
<asterisk-users at lists.digium.com> 
Subject: [asterisk-users] checking if a phone number is UP  

hi,

 We have a phone number from third party provider which is used for inbound 
calls. How could I monitor if this phone number is reachable? 
 the initial idea doesn't sound elegant:  - on my SIP server I set couple 
seconds of ringing before Answer(). - the monitoring server calls to that 
phone number for few seconds, checks if it "hears" the ringing and hangs up 
the call.

 ** I use Nagios to check if my services are UP using check_sip, but it 
this situation I'm more concerned about my DID provider than my server. 
It's just like pinging a phone number. 

 Thank you, Aurimas     
 -- 
Carlos Alvarez TelEvolve 602-889-3003 
-------------------
Carlos

As to code that I can share on this one at present it is a closed solution 
as we are working on a carrier level testing and monitoring solution for 
the wholesale markets. The implementation is closed but the concept is 
straight forward. 

Our real issue with the carriers that we found is you don't know you have 
an issue on inbound until you can test.  We were getting 1 to 2 reports a 
week of issues out of thousands of calls a day so we thought we were good. 
Then we had a large customer that after one four day window. They called us 
upset because they were starting to receive e-mails and cell phone calls 
from customers telling them that they had had issues getting through. Now 
they were getting some calls but a high number were failing during of all 
things peek times.  We had delivered every call our carrier had sent us and 
they checked and they had delivered every call they had gotten. But 
remember in the LNP world your phone number has to be routed by a CLEC that 
has that number in their switch in a region that controls that number.  It 
turned out that AT&T had a switch that was failing to route correctly under 
load due to a bad firmware update. and our customers numbers just happened 
to live on that switch.   So how do you know there is an issue in this 
case. Only by testing. Now this issue was effecting all customers on the 
AT&T switch and they had not caught the issue in 4 days so this would have 
gone on for days had my customer not complained. We now catch carrier 
issues like this several times a month.  

We designed our testing system to solve for these kind of issues.  We went 
from 1 to 2 issues a week to finding about 40 a week.  60% of the time the 
issue falls on the party controlling the number at the base level the rest 
of the time it is a carrier in the middle not having capacity or some kind 
of technical issue.  This has allowed us to weed out the crappy carriers 
where possible and settle for the once that can step up. Once we pounded on 
the carriers and cut off the bad ones we reduced our issues back down to an 
average of 3-5 per week and our customers have taken notice. 

Thanks
Bryant 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120209/fbbf0180/attachment.htm>


More information about the asterisk-users mailing list