- +877 776 0673
- [email protected]
- Mon - Fri: 9:00 - 18:00 EST
Sometimes, when things are going crazy in a business VoIP network, it’s tough to trace the problem’s root cause. Voice quality issues are among the most important issues in VoIP, which are very hard to locate. Packet analysis tools are a great source to identify such issues. Going deeper inside network communication at the packet level will reveal the cause of many problems. Many important packet analysis tools are used by Network and VoIP Engineers to rectify VoIP QoS issues. Some of the most common problems that can be easily resolved by using a packet sniffer or packet analysis tool are:
Some of the most widely used Packet sniffing and analysis tools are Wireshark, OmniPeek, Snort, tcpdump, and snoop. Tcpdump and snoop are command-line packets sniffing tools on Unix/Linux machines, widely used in the pre-GUI era. tethereal and tshark are command-line versions of Wireshark, available in many Unix/Linux machines. We will be using Wireshark and using it to identify and resolve issues occurring on our PBX or VoIP Softswitch platform.
Wireshark is an open-source network analysis and packet sniffing software created by a collaboration of a very vast community of developers. Some estimates have 2.4 million lines of total codes, which makes it worth $ 94 million! Wireshark can be used for various purposes, not limited to capture of packets on all physical and virtual interfaces of a system, analysis of UDP, TCP, and SSL streams capture of FTP, HTTP, HTTPS traffic and its analysis.
From the OSI layers perspective, we can easily get hold of packet-level details for the following layers:
All of the widely used protocols in VoIP telephony can be analyzed with the help of Wireshark, like:
We can also use Wireshark to plot many interesting VoIP call flows, IO graphs to better represent and visualize the communication between different nodes. These call flows are helpful to find out the problematic network nodes, IP subnets, and codecs. A sample VoIP call flow looks like this:
Most of the VoIP companies have direct access to their core servers, where they can take packet traces, mostly called SIP traces, in case of any issue which is not traceable from simply tweaking the configurations on the GUI of the Pbx/Softswitch. Some of the companies use hosted PBX solutions. In that case, they can ask their service provider for the SIP traces, which their Engineering staff can utilize to analyze and trace the problem. Also, most of the companies during their VoIP Network deployment install dedicated servers to capture signalling logs. These records are beneficial for network audits, security and identification of different QoS problems.
I will end part one of this series with some great words of Chris Sanders, one of the leading information Security Expert from Mandiant:
All network problems stem from the packet level, where even the prettiest looking applications can reveal their horrible implementations, and seemingly trustworthy protocols can prove malicious. To better understand network problems, we go to the packet level. Here, nothing is hidden from us—nothing is obscured by misleading menu structures, eye-catching graphics, or untrustworthy employees. At this level, there are no true secrets (only encrypted ones). The more we can do at the packet level, the more we can control our network and solve problems. This is the world of packet analysis.
As we are working in VoIP, we do need to know about the protocols that make this communication possible.
SIP is one of the fundamental building blocks of today’s modern VoIP communication, not only for voice communications but also for multimedia session establishment, instant messaging or some gaming session. Suppose we have two SIP devices, Alice and Bob. When Alice initiates a SIP call, an INVITE packet is sent to Bob, in return Bob reply with 100 Trying or 180 Ringing message back to Alice. The numbers (100, 180, etc.) that you are seeing are known as SIP methods. These SIP methods are used to convey different informational messages about the status of a particular call. After sending 1xx informational messages, Bob will send a 200 Ok message, which marks the establishment of a call, and the RTP stream is established after that instant. A particular SIP call is ended by sending a Bye message by either party. Once a Bye message is sent, the call will get stopped, and the RTP session dropped.
We have put together an easy to follow 4-page step-by-step PDF on Exploring the SIP building blocks.
As we are working in VoIP, we do need to know about the protocols that make this communication possible.
SIP is one of the fundamental building blocks of today’s modern VoIP communication, not only for voice communications but also for multimedia session establishment, instant messaging, or some gaming session. Suppose we have two SIP devices, Alice and Bob. When Alice initiates a SIP call, an INVITE packet is sent to Bob, in return Bob reply with 100 Trying or 180 Ringing message back to Alice. The numbers (100, 180 etc.) that you are seeing are known as SIP methods. These SIP methods are used to convey different informational messages about the status of a particular call. After sending 1xx informational messages, Bob will send a 200 Ok message, which marks the establishment of a call, and the RTP stream is established after that instant. A particular SIP call is ended by sending a Bye message by either party. Once a Bye message is sent, the request will get stopped, and the RTP session dropped.
Now let’s open Wireshark. You can download the latest version from http://www.wireshark.org/download.html. I am using the 64-bit version. Once you open it for the first time, you will see the following screen:
Now let’s open a SIP trace in the Wireshark: this is a simple VoIP call between two extensions configured on two local Asterisk PBXs:
Here you will see all the basic SIP signalling parameters which we discussed above. We need to understand two types of packets to get a proper understanding of a VoIP communication scenario:
As you can see, I have filtered SIP packets from a treasure of different packets flowing through my network. Now, as I have filtered these packets, let’s save these packets only: Click on File, and then click on Export Specified Packets:
Now, as we have filtered out our SIP call packets, let’s open our new file to which we exported the packets (I named the file Test-Call-SIP):
In Wireshark, All of the major Telephony analysis options can be found at the top under Telephony:
To view an INVITE packet detail, double click an INVITE packet, and you will see a new window pop up with all the different network layers detail:
To check the SDP (Session Description Protocol) details, expand the SDP box, which is visible in INVITE detail:
An SDP is always a focal point to check media-related issues in VoIP.
As VoIP professionals, we should also know about different RFCs in use in our domain. RFC stands for Request for Comments; IETF (Internet Engineering Task Force) documents, which details the underlying architecture and working of a specific protocol. Each RFC has a specific number. Some of the famous RFCs are:
As you now have enough background in Wireshark and VoIP, in the 3rd part of this article series, we will look at different issues that arise in VoIP and how we can identify its symptoms and causes using Wireshark.
Want to learn more? Read these related articles:
Please click Like if you found value in this article. Click Share to spread the love, thank you!
