In the first part of this tip, I discussed why you would want to use Wireshark to capture Voice-over-Internet-Protocol...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
packets and how to get a Wireshark VoIP packet capture. In this part, I explain how to filter your Wireshark packet capture for VoIP-related traffic only.
Filtering VoIP packet captures from Wireshark
After the Wireshark packet capture has been completed, you must filter the traffic so that you see only the packets that pertain to the VoIP call. A good grasp of Boolean logic is helpful at this point (as I describe below).
For the purpose of an example, let's say that the IP addressing scheme inside the LAN is 192.168.1.0/24. Let us further say that the IP addresses for the two end devices creating VoIP traffic are 192.168.1.10 and 192.168.1.11. The initial filter of the packet capture could then look something like this:
ip.addr==192.168.1.10 || ip.addr==192.168.1.11
The double pipe (||) between the two IP address filters denotes a logical OR, and the entire statement represents a filter that will display all packets that have either one of the above two IP addresses listed in them.
When analyzing this traffic, what will become immediately apparent is that other non-VoIP traffic will still be displayed inside Wireshark even after the initial filtering. This is likely due to the fact that other non-VoIP traffic, such as Address Resolution Protocol requests and Domain Name System (DNS) traffic, is constantly being communicated by the two end devices over the User Datagram Protocol (UDP). So, in order to filter the capture down even further, the statement may look something like this:
(ip.addr==192.168.1.10 || ip.addr==192.168.1.11) && !arp && !dns
Now the scope of the packet capture should be narrowed rather drastically from its beginnings, and the majority of the remaining packets displayed should be of the Session Initiation Protocol (SIP) and Real-Time Transport Protocol (RTP) variety. However, any further filtering deemed necessary by the network administrator will vary from network to network.
Further Wireshark packet capture filtering
More on Wireshark packet capture
View this Wireshark tutorial
At this point, you may be ready to conduct a Wireshark packet analysis for your VoIP traffic by delving into each packet individually and examining header values and other such information. However, you may wonder why we didn't just filter for RTP and SIP from the very beginning? It is best not to use this as the initial filter until you are absolutely certain that no other accompanying TCP or UDP packets that may be helpful in the analysis of the traffic are necessary to examine. For example, in many network configurations, the Asterisk server receives connection requests from other nodes for management purposes, and if an audit is being conducted, filtering strictly RTP and SIP traffic may distort the results of the audit. Also, if network intrusion is suspected, simply filtering for RTP and SIP may not be sufficient to locate malicious traffic. Furthermore, the example detailed above consisted of merely two end devices, whereas in enterprise environments, hundreds of VoIP phone calls may be traversing the network simultaneously, and may therefore render a simple SIP and RTP filtering useless.
Throughout the course of VoIP traffic analysis, various nuances may present themselves that may initially perplex the network analyst. In order to more quickly move beyond this initial confusion, a thorough knowledge of the network architecture, a firm grasp of Wireshark filters and a high degree of persistence are all key to the overall success of the VoIP traffic analysis.