At the end of every call, most endpoints have the ability to report a "score" of the call quality (uses RTCP) which theoretically you could use to track call quality on an ongoing basis. Unfortunately, endpoints seem to vary a lot in the way of reporting this information and as a result, there are no tools to track and report on this data. If there was, this would be far and away the best way to track call quality (see below about wireshark).
Setting up a test call between two asterisk servers, recording it at one end then analyzing the audio isn't the best way to accomplish what you want for a few reasons. - Analyzing audio is relatively "hard", especially if the source is music. Asterisk's built in milliwatt test tone would be a better choice but still... - You only get results in one direction. To get a meaningful analysis of call quality, you need to capture it at both ends. - And in any case, the audio quality in a voip call is just a function of the network (assuming your end points are not faulty) so you really want to analyze the network performance which is much easier than analyzing audio. If you insist on doing it with a packet capture, then I'd recommend using tcpdump to capture the call, then use wireshark to analyze the call quality. It has built in tools for exactly that purpose including the above mentioned RTCP and it's the tool of choice for this kind of thing. However, analyzing a 24 hour call would not be practical. You need to split it into a series of smaller calls. I can give you some tips on how to make this work but there is a much better and easier solution. Let me cut to the chase; "mtr" is the tool you want. http://www.bitwizard.nl/mtr/ (available as a package for most distros). This one-liner will run the test repeatedly sending 500 packets at a time in 2ms intervals and capturing the results in a file with a time stamp. # while true; do { date ; mtr -i 0.2 -c 1000 -r -o LDRSNBAWVGJMXI 192.168.1.1; echo ; } | tee -a testresult.txt ; done This will give you almost everything you need to know about audio quality including: - The amount of packet loss and jitter. - When the loss/jitter happened. - Was the loss/jitter significant in any particular time period (i.e 1000 lost packets over 24 hours has no effect on voice quality but 1000 lost packets in 5 minutes is serious, that's why we break up the tests). - Where on the network the loss happened. This is the easiest way to find a problem. However it's not perfect. It's biggest weakness is with regard to jitter. Just because there was jitter doesn't mean it ultimately had an effect on the call quality. Endpoints have built in dynamic jitter buffers that compensate for the network and you have absolutely no way of knowing how big the jitter buffer was at the time of the jitter and therefore you don't know if an audio packet was dropped or not. On the other hand, it has an advantage over a simple capture at the endpoint since it can shed light on where in the network the loss is happening. One last note; with mtr you will often see high packet loss at some mid-point on the trace. This is not significant unless the loss is as high or higher from that point forward. Often routers will drop a percentage of ping packets targeted directly at them to save CPU so loss at a single hop doesn't mean anything unless the hops past that one also have high loss. John --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
