[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