Thanks for the detailed followup. Inbound reliability improvement is on our 2012 goals.<div><br></div><div>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?</div>
<div><br><br><div class="gmail_quote">On Thu, Feb 9, 2012 at 10:25 AM, Bryant Zimmerman <span dir="ltr"><<a href="mailto:BryantZ@zktech.com">BryantZ@zktech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span style="font-family:Arial,Helvetica,sans-serif;font-size:10pt"><br>
<span style="font-family:tahoma,arial,sans-serif;font-size:10pt"><hr width="100%" size="2" align="center">
<b>From</b>: "Carlos Alvarez" <<a href="mailto:carlos@televolve.com" target="_blank">carlos@televolve.com</a>><br>
<b>Sent</b>: Thursday, February 09, 2012 11:25 AM<br>
<b>To</b>: "Asterisk Users Mailing List - Non-Commercial Discussion" <<a href="mailto:asterisk-users@lists.digium.com" target="_blank">asterisk-users@lists.digium.com</a>><br>
<b>Subject</b>: Re: [asterisk-users] checking if a phone number is UP</span><div class="im"><br>
<br>
A very interesting solution. Is there any code you'd share for this?
<div><br>
</div>
<div>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.</div>
</div><div><br>
<br>
<div class="gmail_quote"><div class="im">On Thu, Feb 9, 2012 at 7:59 AM, Bryant Zimmerman <span dir="ltr"><<a href="mailto:BryantZ@zktech.com" target="_blank">BryantZ@zktech.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;padding-left:1ex"><span style="font-family:arial,helvetica,sans-serif;font-size:10pt"><div class="im">We designed our solution the following way.<br>
<br>
We have several land line numbers hooked to an asterisk testing server.<br>
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. <br>
<br>
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. <br>
<div>Bryant</div>
<br>
<br>
</div><span style="font-family:tahoma,arial,sans-serif;font-size:10pt"><div class="im"><hr width="100%" size="2" align="center">
<b>From</b>: "Aurimas Skirgaila" <<a href="mailto:a.skirgaila@gmail.com" target="_blank">a.skirgaila@gmail.com</a>><br>
</div><b>Sent</b>: Thursday, February 09, 2012 9:34 AM<br>
<b>To</b>: "Asterisk Users Mailing List - Non-Commercial Discussion" <<a href="mailto:asterisk-users@lists.digium.com" target="_blank">asterisk-users@lists.digium.com</a>>
<div><br>
<b>Subject</b>: [asterisk-users] checking if a phone number is UP</div>
</span><div class="im">
<div><br>
<br>
hi,<br>
<div class="gmail_quote">
<div><br>
</div>
<div>We have a phone number from third party provider which is used for inbound calls. How could I monitor if this <span style="text-decoration:underline">phone number</span> is reachable?</div>
<div><br>
</div>
<div>the initial idea doesn't sound elegant: </div>
<div>- on my SIP server I set couple seconds of ringing before Answer().</div>
<div>- the monitoring server calls to that phone number for few seconds, checks if it "hears" the ringing and hangs up the call.<br>
<div><br>
</div>
<div>**</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Thank you,</div>
<div>Aurimas</div>
</div>
</div>
</div>
</div></span></blockquote></div>
<div><br>
</div>
-- <br>
<div>Carlos Alvarez</div>
<div>TelEvolve</div>
<div><a href="tel:602-889-3003" value="+16028893003" target="_blank">602-889-3003</a></div>
<div><br>
-------------------<br>
Carlos<br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
Thanks<br><font color="#888888">
Bryant</font></div>
<br>
</div>
<br></span>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Carlos Alvarez</div>
<div>TelEvolve</div><div>602-889-3003</div><div><br></div><br>
</div>