TIPS Troubleshooting VoIP Call Quality Issues

[VoicePulse]

Troubleshooting VoIP Call Quality Issues

Assuming you have a Windows PC and a PBX running Linux, there are two useful tools for troubleshooting call quality issues on VoIP -- Wireshark and Ping Plotter Freeware. Sending the results from these programs to your provider will help them diagnose the problem faster, but it doesn't guarantee the issue is something they can fix!

Wireshark captures and analyzes network traffic. It has compatible Linux and Windows versions, which makes it easy to capture the traffic on your Linux PBX, copy it over to Windows and view the results. This capture file can be used to identify almost any SIP problem, so being able to do these steps is very helpful! To do the copy, you will also need to install a program called pscp on your Windows PC.

Run the following to install Wireshark on your PBX (assuming it's running CentOS):

yum install wireshark

Run the following commands on your PBX to capture all traffic, SIP (signaling) and RTP (audio), between the PBX and your provider's server into file /root/my.cap. Based on the options used below, this file can get very large very fast if you have lots of simultaneous calls! Type Ctrl-C after making a phone call to stop the capture.

tshark host server.provider.com -w /root/my.cap

Run the following command to compress your capture file my.cap into a compressed my.cap.gz file:

gzip /root/my.cap

From your Windows PC, run the following to copy that capture file from your PBX's IP address to your Windows PC's C: drive. You will be prompted for the PBX's root password.

pscp [email protected]:/root/my.cap.gz C:\

Then you can open C:\my.cap.gz using the Windows version of Wireshark. The Statistics > VoIP Calls menu will let you see all of the calls and let you graph the SIP dialog (to diagnose problems registering or incoming calls that don't ring) or playback the call (to find the one with audio quality problems). The Statistics > RTP menu will let you see all of the RTP streams (audio) and the packet loss, jitter, etc associated with each one. If you see packet loss or high jitter during the calls you experienced call quality issues with, that might explain the problem!

Next, if you want to track down where the packet loss is occurring, you can install Ping Plotter Freeware on your Windows PC and run a continuous ping to a server on your provider's network. You might want to ask them which server to use, because the SIP proxy or website may not be ideal.

The Ping Plotter trace will help you identify if there was packet loss during the times you experienced call quality issues. You can also save the Ping Plotter capture and send that to your provider.

Remember, if the packet loss is at some router on the Internet between you and your provider, you might both be helpless in fixing the situation! Occasionally, your provider might be able to recommend a different server to connect to that is on a network that will bypass that troublesome router.

I hope this helps you get started in troubleshooting your VoIP call quality issues. Resolving the issue will require a similar effort from your provider and their willingness to examine the useful data you've collected on the problem. The most important thing is to actually capture the problem occurring in a Wireshark capture, because the entire phone call can then be analyzed.

Good luck!

Copyright (c) VoicePulse 2008

 

[wardmundy]

Great tip! Thanks.

 

[jroper]

The mtr command is also a useful one for checking the state of a network.

It's kind of ping and traceroute's love-child.

Joe

 

[VoicePulse]

Joe,

Yes, mtr is useful too if you're working in a Linux-only environment. I don't think it outputs a file that can be used to store or replay what it captured, but it's still useful in seeing where the problem is while it's occurring.

 

[jroper]

Hi

yes agreed, if I heard quality issues occuring, my first port of call would be to run mtr to the provider. If that threw up issues, then then I would follow your very good and precise advice.

I just wish you had not copyrighted it, so we could thow it into some documentation. ;-)


Joe

 

[mtennant]

http://winmtr.sourceforge.net/

is also available for the Windows OS.

Works great. Thanks for the tip.

 

[grumpy]

Thank you for the tutorial, I have already used pingplotter. And it's results scare me, I'm trying to get wife approval but the quality is not there yet! I think Bell's shaping is having an effect and packet lost at some routers. My connection according to speed test is not as good as it was two weeks ago and the feel of surfing is not the same. But I have no other choice for hi speed.

Here is a graphic from ping plotter. in zip as I could not upload png.

 

[mtennant]

71ms roundtrip is around 35ms one way. That isn't bad at all, in my experience.

 

[grumpy]

Thanks for the reply mtennant, I had been comparing numbers to the 71ms not halfing it. But what about the packet loss on one of the routers, and as I retest that router improves by 5% but another drops 7%. Is the packet loss actually more important to voip then ping time? I have to admit I've been doing computers for over 20 years but never got involved in big lans or wan much. Most of it goes beyond me, like wireshark cool info but no idea what it means.

 

[mtennant]

Packet loss is not good. You want zero. A little is not the end of the world, but not on a consistent basis. If you are compressing your voice, it becomes a much bigger issue.

Packet loss tells me your upstream providers are trying to push too much thru too little.

I'd complain.

 

[VoicePulse]

If you're definitely experiencing packet loss, you may want to try a different codec. Based on your provider or your local equipment, a different codec might perform better at packet loss concealment.

 

[grumpy]

I use ulaw, (no compression better right!)
Before I send email of to my provider I would like to get a better understanding. If I have packet loss in the middle (#7 hop) no big deal, but if I get packet loss at the start and end then it is a big deal, right. I'm currently running ping plotter with udp 56bytes, as in my mind this is the closest to VOIP. (I did read in your FAQ 1000 bytes, but I did not feel that represented the actual traffic I use)
Are these statements anywhere near the right direction, or should I be looking at it from a different angle? (I definitely have packet loss and voice quality issues) Also in earlier test I never saw packet loss at my linksys router with DD-WRT before but I'm seeing it today could that be caused by the return trip with loss at the end point?
(up to 30% Packet loss on end point)

 

[VoicePulse]

If you're seeing packet loss right in the beginning (your own network) or at the very end (your provider's network), then there's probably something that can be done to fix it. On your end, it could be your router, cablemodem, or ISP's first hop somewhere in the ground near your house. Any one of those can be fixed yourself or by calling your ISP. If it's close enough to the provider's end, they can call their ISP or check their own routers.

G.711 does no compression, but we've seen in practice that sometimes it actually sounds worse than something like G.726-32 when there's packet loss. Depending on the implementation, G.711 may pass though the drops in audio caused by dropped packets, while another codec will conceal those drops by filling in audio from the packet before. You should experiment with different codecs because in a real-world scenario you can't assume that G.711 will always sound better.

 

[Tekmon]

Great write! Thanks.