Panoramisk

Annonce

On peut être passionné par la téléphonie et prendre soin de soi : "Faites du sport, faites du vélo" est la devise du site d'e-commerce lancé par l'un des auteurs de Panoramisk : bikeo. Si vous faites du vélo, que ce soit en ville, sur la route ou sur les chemins plus accidentés, n'hésitez pas à aller faire un petit tour sur www.bikeo.fr pour vos prochains achats verts.
En plus leur plate-forme de téléphonie utilise Asterisk, comme quoi on peut la convergence est une réalité.

Testing the VoIP network against quality

Transporting voice over a packet network is not an easy task and requires controlled quality with regards to bandwidth first but also with delay, jitter and frame loss ratio. We can encounter a very bad voice quality during network congestion, which is not good for a professional network. In order to test our network in advance or during production there are tools and techniques that can be easily used. This article shows how to simply test an IP network for voice transport with off the shelf tools.

The tests proposed here are based on the pjsip¹ library suite which allows to build test tools around the SIP² protocol. The library is really rich and complete, allowing one to imagine any kind of testing tools, from a simple call engine to a compete IP phone simulator.

In order not loosing you in some specific code, we will use for the tests in this article the available siprtp tool included in the package. This tool allows setting one or multiple SIP sessions including signaling and voice transport parts and provides us with statistical results. Running this tools in a back to back scenario will allow to analyze results on call establishment time, packet loss or jitter which is exactly what we are looking for, on a real network and with automation if necessary.

siprtp can be used as a client (UAC³ in the SIP terminology) or a server (UAS⁴). We can therefore initiate or receive calls on a SIP environment, for our back to back automated test we will use both components which is easier than having somebody placing calls hundred time with a phone.

At the end of each test call siprtp is providing statistics that allow to know exactly what happens during this call. As an example, here below is the result of a test call between our Polycom IP301 phone and the siprtp test tool, simply started as a server. The call was 23 minutes long, started in 1ms and our local network is of average quality (no packet loss but and average jitter around 30ms).

Call #0: CONFIRMED [duration: 00:23:52.945]
   To: ;tag=as72661943
   Signaling quality: got 1st response in 1 ms, connected after: 1 ms
   Stream #0: audio PCMA@8000Hz, 20ms/frame, 8.00KB/s (9.06KB/s +IP hdr)
              RX stat last update: 00h:00m:05.382s ago
                 total 71.06K packets 11.46MB received (13.75MB +IP hdr)
                 pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
                       (msec)    min     avg     max     last
                 loss period:   0.000   0.000   0.000   0.000
                 jitter     :   0.000   1.343 268.625   0.125
              TX stat last update: 00h:00m:02.720s ago
                 total 71.06K packets 11.46MB sent (13.75MB +IP hdr)
                 pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
                       (msec)    min     avg     max     last
                 loss period:   0.000   0.000   0.000   0.000
                 jitter     :   0.750  29.558  62.125  43.000
             RTT delay      :   0.427 548.994 1052.000 1001.000

The test environment we used is built with an Asterisk server, configured as standard back-to-back UA (no re-invite) and no codec adaptation on the call (which lower performance). The network is a switched one, standard product from the SOHO market. The Asterisk server was a 1.4 standard release, compiled from sources and running in a Debian VMWare virtual machine⁵.

The sip.conf configuration file specifies an entry for each test client:

[pjsip-uac]
type=friend
context=perftest
fromdomain=192.168.16.185
insecure=very
qualify=no

[pjsip-uas]
type=peer
allow=all
host=192.168.16.186
qualify=no

In the dial plan (extensions.conf) we have specified how extensions are reachable one from the other using a simple Dial.

[perftest]
exten => 1111,1,Dial(SIP/ua@pjsip-uas,20,t)

The pjsip was the 0.5.10.3, compiled on a Mac OS X (10.3) with some code patches in order to force communication with Asterisk with the G.711 A law by default.

If compiling this tool (preferred option for us), you will find some older packages pre-compiled on the web site, a Windows version is available, as well as a Linux RedHat one.

We can easily use this tool set in order to validate a long distance network that will more easily drop packets or have congestion, on a local network it makes lower sense.

Using standard protocols for telephony over IP, like SIP and RTP allows building and using very efficient tools in order to validate the network and gather rich metrics. We can use these tools to validate a network prior ToIP installation but also in a regular basis for quality enhancement.
If you think about a high quality controlled ToIP network, put these ideas in your list, we stay at your disposal for any specific development on top of it, if required.