[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Fax: +61 2 8304 0001www.websitemanagers.com.au
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
