On Monday 31 October 2005 16:35, Simon P. Ditner wrote: > I'm load testing an asterisk application, and I'd like to determine > the audio quality automatically. I'm already doing DTMF tests, but I'm > looking for something a little fuzzier I think.
There are several things I've been thinking about to do this over the past year. The main idea involves executing a Monitor()-like application that simply monitors the audio in both directions and runs VERY quick/light calculations based on what I'd call "inverse" denoise/depop/declick filters. Hell you could also try to detect echo. You want to detect these things but not do anything about 'em. The app would know where each leg of the call is going and could easily, easily stuff this into a DB to obtain per-call, per-provider and per-user stats. It's then a simple matter of data-mining to get stats on time of day, call route, total calls active, codec, whatever. Alternatively or in addition to above: periodically call a remote echo() extension and feed it a known audio waveform, maybe even the 1004Hz miliwatt tone, since it's designed not to "fit" nicely into TDM. Run similar tests to those mentioned above. This has the added bonus of giving you jitter, delay and more specific audio quality stats since you KNOW what the waveform coming back is supposed to be like. This is all technology independent. IAX2 has call/jb stats (which you could cross-correlate with what you've found to try and kill bugs) but nothing this advanced. Then there's the very very very primitive but what I'd think would be highly effective method of simply detecting a short answered call to a number followed by another call to the same number within 2 minutes of the first call. This would indicate that there was a high chance of a poor quality call, and you could use this metric to temporarily turn off service to a provider. Ideally you would call out through another provider on the 2nd call. While really really cheap in terms of processor time and implementation complexity, it is also the least likely to be correct. Many people call poor cell phones (nothing you can do to fix poor call quality there), and many people also call, hear an answering machine, and call back right away to try and "get through". You could reduce the false positives by looking for this short answered call/call to same number when you see it happen to two different phone numbers in a short period of time, but again this added delay just adds to the frustration level of overall poor call quality. I have had many, many people interested in these ideas (including myself) but I've just not had the time to put finger to keyboard and bash something out. -A.
