[asterisk-users] Service Level Compliance

[Adam Goryachev]

lists at infoway.net wrote:
> The issues we would like to resolve are the following:
>
> 1) We can ping our originating SIP providers. However, that doesn't guaratee us that we can receive calls from them. In several occasions, some of our SIP providers have had routing (SIP) problems and when we dial any of the DIDs, they would not even hit our box. The call would simply die somewhere in their network or their providers' networks. How can we proactively confirm that they are actually routing calls to us? We thought we could probably dial out through any of our other providers so the call comes in via a different provider and maybe hit an AGI script. This script could update a MySQL table with a timestamp of the last successful "test". We could then take the data from that table and bring it to Nagios and/or Cacti. Is there a better approach?
>
> 2) We can test Asterisk responsiveness by doing something like 'asterisk -rx "show uptime"' and parse the results. We can also connect to MySQL and execute a test query. However, how can we verify that Asterisk is actually talking to MySQL and that it's connection hasn't died?
>
> 3) As stated above, we can test the responsiveness of asterisk. However, we have noticed in, at least, one occasion, that even though asterisk seems to be responsive, it would not accept or place any calls. Somehow it's "call" engine was locked and we had to restart asterisk. How can we verify that asterisk is actually capable of receiving and placing calls?
>   
Solve all of 1 - 3 with a couple of scripts plus AGI. You have a test 
asterisk server using either voip or a local pstn line (or bri/pri) 
which calls the customers number. I'd try to use a PSTN line since this 
is the method most of your customers' customers will use to call. When 
the call arrives to your asterisk box A, write the date/time or 
something, to a text file (which is read and reported to your monitoring 
server), then pass the call into an AGI which does some mysql lookups 
(similar to a normal call would), and write the result of these lookups 
into another text file (which again is read and compared to the result 
you should get, and reported back to the monitoring system - assuming 
some sort of static result can be obtained). Finally, pass the call to 
Asterisk B, which places the call into the queue. Finally, when the 
agent answers the call, they hear a recording from your original test 
box (ie, the originator of the call) which simply loops with "Please 
press 1 to acknowledge, or 0 if you can't understand/hear this 
properly", the originator is simply waiting for the dtmf (with some 
configurable timeout), if you get answered and get a 1 or 0, then return 
that to your monitoring server, either via text file or directly.  If 
you timeout, also report that as needed (possible queue problem, or 
perhaps the agent took too long to answer, you decide on the timeout 
value and the alerting to send back).

> 4) We have no Digium boards and all kernels are 2.6 or above, so we end us using ztdummy, if needed. The client's agents are in a different country and the average lantency is around 250ms. Most of the time, call quality is good. However, there are a few situations where people complaint about echo. Is there a way to measure or "improve" this? I know it has been a topic discussed at lenght and if we could probably script a way to measure some sort of a MOS value, that would be great. Any ideas?
>   
If you have no PSTN interfaces, ie, everything is voip, then you can't 
be responsible for echo (neither introducing it, nor removing it). If 
you are responsible for the echo that your voip provider is leaving in 
the call, then you are pretty much stuffed. You can't really measure it 
(AFAIK), but you could perhaps ask your provider for an SLA on echo, and 
see what they have to say about it. Then just copy what they say into 
your own....
> 5) Anything else that you could think of we could measure to make sure all components are working?
>   
The best method to ensure that the whole end-to-end system is working, 
is by testing the entire end-to-end system.
> You input is greatly appreciated it. I promise that whatever solution is best recommended and scriptable, we will post our development and working solutions for the community to benefit from.
>   
While this would be nice, and could probably be used as a guideline for 
other people, it should be mostly useless to anyone else, since their 
end-to-end system will be very different (assuming you really are 
testing your system properly).

Just my 0.02c worth.

Regards,
Adam

-- 
Adam Goryachev
Website Managers
Ph: +61 2 8304 0000                            adam at websitemanagers.com.au
Fax: +61 2 8304 0001                            www.websitemanagers.com.au