If you’ve worked on implementing a sufficiently complex VoIP system, you know that sometimes things can get a little weird. Calls that will drop after a few seconds or one way audio when calling certain numbers. Troubleshooting these issues can be maddening at times; your config files all look spot on, but for some reason things just aren’t working like they should. This article goes over one tool that needs to be in your arsenal to get to the bottom of these bugs and keep your calls flowing free.
Nearly every system has logging available, configurable to varying degrees of verbosity. These are a good resource for troubleshooting information and seeing what is going on behind the scenes in your system, but at times can be confusing or misleading. For example, what if the logs are just not showing any call data at all? What if the logs show some call data, but you’re connecting to an error recording you’ve never heard before? This is when you need to deploy the one tool in your VoIP bug-busting arsenal that can show you what is really going on, the Packet Capture.
Packet captures do just that, they capture the raw packets that are sent to and from your system. Everything sent over the internet is packets, little bite-sized chunks of data which are flung around the globe to be processed and stitched back together once arriving at their ultimate destination. Your VoIP calls are controlled by tiny SIP packets communicating between end points, setting up the parameters of the call and defining the media stream which will contain the audio of your phone conversation. By capturing these packets you can see behind the behind the scenes, and see how the metaphorical VoIP sausage is made.
Now first off, how to get those packets.
Any VoIP system worth its salt is going to have some form of packet capture available, although it may vary between system type. On systems running on top of Linux (FreePBX, Asterisk, FreeSWITCH, etc.), the simplest method is using the tcpdump command line utility. So to use this, you will first and foremost need direct command line access to your phone system, either via SSH or a keyboard and monitor plugged right in there. Once in, you can run the following command to start the capture running:
tcpdump -s 3000 -w ~/capture-file.pcap port 5060 or portrange 10000-35000
screenshot of console output:
If your system complains about permissions, add “sudo” on the front to run the command with root permissions. Running this will grab packets on the default SIP signaling port 5060, as well as from the common media ports in the specified port range and write the resulting file to your current user’s home directory (~/). After starting this capture, place a call.
At this point, you won’t see anything, but tcpdump is there, quietly listening to those packets and writing them to the specified file. After your call is done, you can close the capture with Control-C.
Now equipped with this capture, you can dive into the nittiest of gritties of the raw SIP signaling and RTP data for your call. There are a few different options out there for reading packet capture files, but the grand daddy of them all is Wireshark. A wireshark tutorial would be a whole other ball game, and will probably come in a future post. But if you want to view your call in Wireshark, the best place to start is opening the Telephony menu, and select VoIP Calls. Then you can select your call in the VoIP Call menu and click the Flow button. This will give you an overview of the call flow, showing SIP signaling between User Agents.
Wireshark screenshot:
Captures matter, because they are the actual SIP packets. This is the universal language of SIP. While individual systems will have their own particular log output, the SIP always tells the true tale. As support engineers, we breathe SIP, and while I may not know the ins-and-outs of the SmallComp SIP Gulper 2600, if I see that system giving a 404 response to an inbound call, I’ve got a pretty good hunch that the Gulper is not provisioned with the number being requested.
If you can learn to read captures, you will have a huge advantage when tackling new problems related to your VoIP. Sometimes phone issues can be transient and hard to duplicate, getting a capture of that occasional issue can allow you to dive deep into the possible causes and root out the source of the issue much easier.
