| Asterisk Call Analyzer for IAX2 |
An add-on tool for complete IAX2 (Asterisk Protocol) call analysis Click for Whitepaper "IAX2 Call Analyzer for Unsniff" (900 kb) Are you one of the growing number of people deploying the Asterisk VoIP platform ? We present a add-on tool that performs complete VoIP Call Analysis for the Inter Asterisk Exchange (IAX2) protocol. Measure and plot call bandwidth, interarrival delay, jitter, packet loss, and IAX2 events for each direction of call. This tool like others in this series (such as TCP/IP analysis) is written in the excellent Ruby scripting language using the Fox-Ruby toolkit. Full source code of the tool is provided for you to tweak it to your liking. If you are working with Asterisk in any capacity, this is a "must have" tool on your workbench. IAX2 Call AnalyzerCalculate and plot bandwidth, delay, jitterAsterisk (the open source PBX server) is rapidly gaining in popularity as a powerful alternative to expensive PBX systems. The IAX2 (Inter Asterisk Exchange ver 2) protocol is the native language of Asterisk. The main strength of IAX2 when compared to competing protocols such as RTP/SIP/H.323 is its friendliness to NAT (Network Address Translation) and firewalls. IAX2 uses only a single UDP port 4569 to carry both media and control messages. How to download and run this tool  IAX2 is a relatively new protocol and there is a lack of tools available that can perform quality analysis of IAX calls. Ethereal (the excellent open source protocol analyzer) contains IAX2 protocol dissection but lacks aggregate call analysis features. The features of the IAX call analyzer are:
The tool is written in Ruby using the powerful Unsniff Scripting API. The tool uses the Fox-Ruby and the UnleashCharts charting library to build its user interface.The tool comes with full source code. You can modify / adapt / extend it any way you wish. Please let us know of any bugs in the tool or improvements you would like to see. Extract calls from an capture fileIf Unsniff sees a NEW IAX control message and a corresponding ACCEPT message, it assumes a call has been set up and creates a new call. The data associated with each call is extracted from these two messages and shown in a table. You can then double click any call in the table to analyze that call. For each call the following data is shown.
Call Bandwidth ChartOne of the most important factors that needs to be considered while deploying a VoIP system is the bandwidth requirements. The bandwidth at your disposal will help you plan tradeoffs on voice quality by selecting the right codec. Each codec has a specific voice stream bandwidth. For example G.711 generates a packetized voice stream of 64kbps bandwidth. However, the actual bandwidth required is larger due to the IP/UDP/IAX2 headers. The call bandwidth chart plots the actual bandwidth usage of the selected call.The methodology used by the bandwidth analyzer is: Use entire packet size including Ethernet/IP/UDP/IAX2 headers The entire packet size is used to calculate the bandwidth requirements. As an example, if we are analyzing a call which uses the GSM codec, the total payload is calculated as: Total payload = 33 (GSM) + 4 (IAX2) + 8 (UDP) + 20 (IP) + 14 (Ethernet) = 79 bytes You can compare your bandwidth utilization with the specifications different codecs at http://www.openh323.org/docs/bandwidth.html Sample used bandwidth every 200 ms We use a 200ms sample rate of used bandwidth to plot. If you wish to use a more granular sample, then you can change the line @sliceus = 200000 line in the iax2ana.rb script. In the picture below we can see that the call uses the iLBC codec and the used bandwidth is around 35kbps in each direction. You can play with this tool for other codecs such as G.711, GSM, Speex and verify for yourself the bandwidth usage claims of each of these codecs.  One-way delay (Latency)When you talk into a microphone,the first thing that happens is the sampling of your voice (often at 8000 times per second). The one-way delay is the time between the sampling of a voice signal and the playout of the sample at the other end. This includes codec delays, network buffering, transmission delays, and playout buffering. While all these factors are important to determining the overall voice quality, the transmission delay is the largest and most unpredictable component. Even casual users of voice over IP services would have noticed that as latency gets longer, it becomes much harder to carry out a meaningful conversation. The well accepted benchmark for maximum one-way delay is 150ms. Unfortunately, measuring one-way delay is not easy. We need timestamp synchronization between the two endpoints and a way to carry this information in each packet. This is too much to ask in a loosely controlled network such as the internet. So what we are really saying is, Unsniff cannot calculate the one-way delay for given these requirements. Luckily it turns out the inter-arrival delay (next section) is a pretty good indicator as well of voice quality. Unsniff can calculate the inter-arrival delay and plot them on a chart for the duration of the call. So lets accept that one-way delay calculation will remain an elusive goal for us and move on to the next section !Interarrival DelayIn the previous section, we saw that measuring one-way delay is not possible given our constraints. Let us now focus on the next best thing, the inter-arrival delay.What is Interarrival delay ? Assume a VoIP transmitter is sending voice packets exactly 20ms apart, so they keep coming at 0ms, 20ms, 40ms, tick,tick,tick,tick, . In an ideal situation the receiver must also receive these packets exactly 20ms apart (at t+0ms, t+20ms, t+40ms) and so forth. Actually this is what happens in traditional phone systems. Unfortunately in an IP network, this not the case. While we can easily arrange the sender to transmit packets at exactly 20ms intervals, we cant "arrange" for them to be received at exactly the same rate. This is due to the routers and the packet switched network in between. So we may have a case where the receiver gets the packets at (t+0, t+23, t+45, t+61, etc). This means that instead of arriving nicely at 20ms intervals, we get packets at 23ms, 22ms, and 16ms intervals. Since the actual numbers (23ms,22ms,16ms above) are dependent on the transmit rate (20ms), we define interarrival delay as the difference between the two. In this case we have interarrival delays of 3ms for the 1st packet, 2ms for the 2nd packet, -4ms for the 3rd packet. So we have delays of 3ms, 2ms, 4ms in the above example. This is how interarrival delay is calculated. This is also sometimes misleadingly referred to as simply “delay”. Calculating interarrival delay for IAX2  The two measurement points required to calculate delay are the received time and the transmit time. Received Time The received time is when the packet was captured by Unsniff. Getting this is not a problem because Unsniff gets a microsecond resolution timestamp for each captured packet from its provider (Winpcap or Windows Raw Sockets). The only tricky part it to position Unsniff close to the receiver if we want a reasonably accurate measurement. Ok next.. Transmit Time This is when a packet was transmitted. Unsniff does not have access to this information because it is only running near the receiver. You could probably run another instance of Unsniff near the sender and correlate two packets by writing simple scripts. This is not feasible in a number of situations. The IAX2 timestamp comes to our rescue. The timestamp in the IAX2 mini frame is the number of milliseconds since the call began. We can use this timestamp because we are only interested in the time difference not the actual time. All we have to do is convert the microsecond resolution timer at the receive side to milliseconds and we have our measurements. Jitter (statistical variation of Interarrival Delay)Within bounds Interarrival delay can be easily controlled by adding a buffer. Sometimes interarrival delays are not problem at all because they are uniform. Let us consider an example : If at a receiver packets arrive at (t+0, t+22, t+40, t+62, t+80), we can see that the delays are +2ms, -2ms, +2ms, -2ms and so on. So you can just add a buffer for a single packet and still play it out with no problems, except that you introduce some additional delay due to the buffer. The real problem happens when these interarrival delays vary. This interarrival delay variation is known as the jitter (a term borrowed from electronics).The jitter is quite a good indicator of voice quality. However, it does not mean much at a single point of time. So, if someone walks up to you and says “My call experienced a jitter of 8.3ms at 10:42:22 AM”. You will not know what to say about the voice quality at that instant. You can use jitter to compare different calls or compare time periods of the same call. If the same person walks up to you and says, “My call experienced high jitter (between 7ms and 8ms) for a few minutes at 10:42:22AM compared to the beginning of the call (between 0ms and 2ms)”. You can conclude that the voice quality during the phase of high jitter was lower than during the period of low jitter. Calculating jitter for IAX2  The IAX2 informational draft does not include a formula for calculating jitter from interarrival delay samples. So we stole one from RFC3550 (RTP - A transport protocol for real time applications) - the predominant VoIP protocol. We think that the formula is valid for both RTP and IAX2. The formula is : IAX2 EventsWe have looked at call bandwidth, interarrival delay, and jitter charts for voice over the IAX2 protocol. While all these give you an idea of the quality of the call. You still want to see how the IAX2 protocol itself works over the timeperiod of a single call:
Let us take a look at a sample call.  The notation used in the IAX Events chart is shown in the table below
How to Download and run this toolPre-requisites1. You need to have Unsniff Network Analyzer installed on your system (download a trial version from here)2. You need to have Ruby installed on your system (click here to download a one-click installer for Windows) Download the IAX2 Call Analyzer script1. Download iax2ana.rb (the IAX2 Call Analyzer Ruby Script) to a folder on your PC2. Download UnleashCharts.rb (the Unleash Charting Library) to the same folder How to run ?
Usage:iax2ana <capture-file-name> capture-file-name : Capture file in Unsniff (*.usnf) format Example:c:\RubyTest> iax2ana.rb BuggyAsteriskCapture.usnf |