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

Thu Feb 9 11:39:36 CST 2012

Thanks for the detailed followup.  Inbound reliability improvement is on
our 2012 goals.

When you place your outbound test call, are you mindful of the carrier it
goes on, do you vary them, etc?  In other words, do you do anything to be
sure that while carrier X can place a call to carrier Y, you might not be
able to get to Y if you use carrier Z?

On Thu, Feb 9, 2012 at 10:25 AM, Bryant Zimmerman <BryantZ at zktech.com>wrote:

>
> ------------------------------
> *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
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>

-- 
Carlos Alvarez
TelEvolve
602-889-3003
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120209/d0a86173/attachment.htm>