Вы находитесь на странице: 1из 32

July 2018

Introduction to Wireshark for


Voice Engineers
and Professionals
Introduction to Wireshark for Voice
Engineers and Professionals
Contents
1 Introduction ..................................................................................................................................... 4
2 How to Use the Guide ...................................................................................................................... 4
3 Brief Overview of the OSI Model ..................................................................................................... 4
3.1 The OSI Layers ............................................................................................................................... 4
3.2 Encapsulation ................................................................................................................................ 5
4 Network Preparation ....................................................................................................................... 6
4.1 Capturing Packets on the Wireshark Computer ........................................................................... 6
4.2 Capturing Packets on Other Devices Using Promiscuous Mode ................................................... 6
4.3 Capturing Packets on Other Devices Using Port Mirroring ........................................................... 7
5 Introduction to Wireshark ............................................................................................................... 8
5.1 First-Time Operation of Wireshark ............................................................................................... 8
5.2 The Three Panes............................................................................................................................ 9
5.2.1 Pane 1 – A List of Packets...................................................................................................... 9
5.2.2 Pane 2 – Layered Information ............................................................................................. 10
5.2.3 Pane 3– Going Deep ............................................................................................................ 12
5.3 Filtering Results ........................................................................................................................... 13
5.4 Managing .pcap Files................................................................................................................... 14
5.5 Wireshark Capture Instruction Review ....................................................................................... 15
6 Real-World Voice Application Examples ........................................................................................ 16
6.1 Scenario Details........................................................................................................................... 16
6.2 Sample Capture Characteristics .................................................................................................. 16
6.3 Packet Viewing Exercises ............................................................................................................ 17
6.3.1 Filtering the SIP Control Packets ......................................................................................... 17
6.3.2 Analyzing the List of Packets ............................................................................................... 18
6.3.3 Examining the Contents of SIP Packets ............................................................................... 19
6.3.4 Filtering RTP Packets ........................................................................................................... 22
7 Using Wireshark’s Telephony-Specific Features ............................................................................ 24
7.1 VoIP Calls ..................................................................................................................................... 24
7.1.1 Flow Sequence Tool ............................................................................................................ 25
7.1.2 Play Streams Tool ................................................................................................................ 26
7.2 RTP .............................................................................................................................................. 27
7.2.1 SIP Flows ............................................................................................................................. 28
8 Appearance of Typical Voice Issues in Wireshark.......................................................................... 29

© 2018 TeleDynamics │ page 1


8.1 One-Way Voice ........................................................................................................................... 29
8.2 No-Way Voice ............................................................................................................................. 29
8.3 Registration Failure ..................................................................................................................... 29
8.4 Server Not Found ........................................................................................................................ 30
8.5 Know the Codes .......................................................................................................................... 30
9 Useful Links .................................................................................................................................... 30
10 Support .......................................................................................................................................... 31
11 Partnering with TeleDynamics ....................................................................................................... 31

Figures
Figure 1. OSI Layers ....................................................................................................................................... 5
Figure 2. Voice Packet Encapsulation ........................................................................................................... 5
Figure 3. Packet Capture on Wireshark ........................................................................................................ 6
Figure 4. Capture Options Menu .................................................................................................................. 7
Figure 5. Wireshark Welcome Screen ........................................................................................................... 8
Figure 6. Capture Results .............................................................................................................................. 9
Figure 7. Enlarged view of Figure 6, Pane 2 ................................................................................................ 10
Figure 8. Expanded Ethernet II Entry .......................................................................................................... 10
Figure 9. Expanded Internet Protocol Version 4 ......................................................................................... 11
Figure 10. Expanded Transmission Control Protocol .................................................................................. 12
Figure 11. Hex Dump................................................................................................................................... 12
Figure 12. Filter Parameters........................................................................................................................ 13
Figure 13. Sort Results for tcp.port==443 ................................................................................................... 13
Figure 14. Invalid Field Entry ....................................................................................................................... 14
Figure 15. Filter Syntax Using the AND Operator ....................................................................................... 14
Figure 16. Saving Packets ............................................................................................................................ 15
Figure 17. File Capture Size ......................................................................................................................... 15
Figure 18. Scenario Exercise ....................................................................................................................... 16
Figure 19. Search Results – SIP Protocol and IP Address 192.168.1.61 and X.Y.Z.23 ................................. 17
Figure 20. Call Termination ......................................................................................................................... 19
Figure 21. Selection of Packet #6 ................................................................................................................ 20
Figure 22. Packet #6 Details ........................................................................................................................ 20
Figure 23. SIP Section of Packet 2 ............................................................................................................... 21
Figure 24. Details Given in Message Body .................................................................................................. 21
Figure 25. Search Results – RTP with an IP address of 192.168.1.61 ......................................................... 22

© 2018 TeleDynamics │ page 2


Figure 26.RTP Protocol Details .................................................................................................................... 23
Figure 27. Telephony Menu ........................................................................................................................ 24
Figure 28. VoIP Call Capture ....................................................................................................................... 25
Figure 29. Additional Monitoring Functions ............................................................................................... 25
Figure 30. Flow Sequence Window ............................................................................................................. 26
Figure 31. RTP Player .................................................................................................................................. 27
Figure 32. RTP Streams Window ................................................................................................................. 27
Figure 33. RTP Steam Analysis .................................................................................................................... 28
Figure 34. SIP Flows Window ...................................................................................................................... 29

Tables
Table 1. Steps Taken by SIP for Call Initiation ............................................................................................. 18
Table 2. X-Lite Client and SIP Exchange at 49 Seconds ............................................................................... 19

Notice
The information contained in this document represents the current view of TeleDynamics on the topics
discussed on the date of publication. While TeleDynamics endeavored to include the most up-to-date
information available at the time of publication, its accuracy cannot be guaranteed.
This document is for informational purposes only. TeleDynamics makes no warranties, express or
implied, as to the information in this document.
Complying with all applicable copyright laws is the responsibility of the user. The furnishing of this
document does not grant any license to patents, trademarks, copyrights, or other intellectual property
held by TeleDynamics.

© 2018 TeleDynamics │ page 3


1 Introduction
This guide was created to serve as an introduction to Wireshark, to assist telecommunications
professionals administrating Voice over Internet Protocol (VoIP) systems and to troubleshoot common
issues and problems. It is not an all-encompassing examination of this powerful tool, but it will provide a
solid starting point for using Wireshark and troubleshooting modern voice applications. A multitude of
information is available online for specific faults and failures that can be used to continue research and
enrich the user’s skillset (see the ‘Useful Links’ in section 9).

2 How to Use the Guide


This guide will cover the following topics:
• Brief overview of the OSI model
• Network preparation
• Introduction to Wireshark
• Real-world voice application examples
• Wireshark’s telephony-specific features
• Examining how specific voice malfunctions appear in Wireshark
• Useful links for further reading
The first section covering the OSI model is a primer for network administrators. First-time Wireshark
users should experiment with the software to become familiar with its capabilities and functionality. In
the ‘Introduction to Wireshark’ section, you can attempt to replicate the steps outlined to examine
normal traffic to and from your computer without actually troubleshooting specific issues. This
experience will be invaluable when you are called upon to troubleshoot real-world scenarios.

3 Brief Overview of the OSI Model


The Open Systems Interconnection (OSI) model is a conceptual model that standardizes communication
operations in a telecom system. Since the network structure and its operation are based on this model,
Wireshark will display and organize the captured data packets within this framework.
3.1 The OSI Layers
The OSI model is composed of seven layers, with each layer being responsible for a variety of
communication functions (see Figure 1). Although full comprehension of how the OSI model applies to
networking is not required, knowing what information is found within each layer will be advantageous
to the administrator. The layers that Wireshark primarily deals with are the Data Link, Network and
Transport layers – layers two through four.
• Transport Layer is where the Transmission Control Protocol (TCP) and User Datagram Protocol
(UDP) port numbers are found, as well as information about the Session Initiation Protocol (SIP)
and the Real-Time Transport Protocol (RTP).
• Network Layer is where the internet protocol (IP) resides. Source and destination IP addresses,
as well as information concerning quality of service, are found in this layer.
• Data Link Layer contains information pertaining to the Ethernet, including the media access
control (MAC) source and destination addresses.

© 2018 TeleDynamics │ page 4


Figure 1. OSI Layers

3.2 Encapsulation
In the OSI model, each layer is encapsulated by the layer below it. All information transmitted on a
network, including voice, is broken down into smaller parts (called packets) before being sent over the
network infrastructure. Encapsulation is the process by which control information is attached to each
piece of data for the purpose of successfully reaching its proper destination in an appropriate amount of
time. Each layer of the OSI model attaches a different piece of information so the functionality of that
layer can be successfully performed. In the information technology (IT) world, attaching information to
the beginning of data is referred to as prepending.
A voice conversation is broken down into voice samples that are encapsulated using the Real-Time
Transport Protocol (RTP), where an RTP header is prepended to the sample. This is then further
encapsulated into a Transport Layer segment, which adds a Transport Layer header to the voice sample
using the User Datagram Protocol (UDP), which includes information such as port numbers. This is then
encapsulated into a packet at the Network Layer, where the IP header contains information such as
source and destination IP addresses. Finally, the packet is encapsulated into a frame at the Data Link
Layer, and is prepended with a frame header with source and destination MAC addresses, among other
things. See Figure 2.

Figure 2. Voice Packet Encapsulation

© 2018 TeleDynamics │ page 5


4 Network Preparation
To successfully capture packets, preliminary preparation must be conducted on the network. What must
be done depends on the source and destination of the traffic you need to capture, as well as the
network infrastructure on which you will be performing the capture.
4.1 Capturing Packets on the Wireshark Computer
Wireshark captures packets traversing the network card of the computer on which it is installed. This is
an ideal situation if the network traffic to be captured is destined for, or generated by, the same
computer. However, if you need to examine traffic that is being exchanged between other devices on
the network, you must prepare the network accordingly.

IP Phone

Port 3
IP Phone

Port 4
Port 1

Wireshark Port 2
Computer

IP PBX
(SIP Server)
Figure 3. Packet Capture on Wireshark

In the scenario shown in Figure 3, none of the traffic we want to examine, as portrayed by the red
dotted lines, is traversing the network card of the Wireshark computer, so none of the packets can be
captured. To capture this traffic, we can use one of two techniques: promiscuous mode or port
mirroring.
4.2 Capturing Packets on Other Devices Using Promiscuous Mode
Ethernet, by its nature, is a shared medium, so a computer connected to the network may receive data
that is not destined for itself. When this occurs, a device will read the destination MAC address in the
Ethernet header and check to see if it matches its own. If it doesn’t, it discards the frame.
Wireshark takes advantage of this and can read and capture packets that are not destined for itself.
However, to do this, Wireshark must be configured to detect and include such packets in the capture
instead of discarding them. The configuration parameter that does this is called promiscuous mode. This

© 2018 TeleDynamics │ page 6


mode reads and records all packets that arrive on the interface, regardless of the actual intended
recipient of that data. The only prerequisite is that the monitoring computer must be on the same
network segment or virtual local area network (VLAN) as the devices generating the traffic to be
analyzed.
Wireshark functions in promiscuous mode by default; however, to ensure it is enabled, go to the
Capture → Options… menu item before you begin to capture. The window shown in Figure 4 will
display. You can then enable or disable promiscuous mode for any individual interface, or you can
enable it on all interfaces using the checkbox highlighted in the lower left of the menu.

Figure 4. Capture Options Menu

NOTE: Promiscuous mode will not always capture data that is destined for another device. Modern
network switches are designed to minimize the number of packets arriving at network devices that are
not their intended recipients. This increases network efficiency, but hinders the packet capturing
process. For this reason, a second method, port mirroring, may be used to capture the required packets.
4.3 Capturing Packets on Other Devices Using Port Mirroring
Port mirroring is a feature available on many managed switches that allows packets on a network to be
exchanged on a specific port of that switch. When enabled, port mirroring sends a copy of all of the
packets that are seen on one switch port to a network monitoring connection on another port of the
same switch.
Using the scenario depicted in Figure 3 as an example, Port 1 can be configured as the mirrored, or
monitoring, port. This is the port where a computer running Wireshark would be connected. Ports 2, 3
and 4 are then configured as source ports for the port mirroring; they are designated as ports whose
traffic is copied to the mirrored port. The end result is that all traffic on Ports 2, 3 and 4, whether
incoming or outgoing, is replicated and sent to Port 1. The packets will traverse the computer’s network
card, allowing it to capture and store them for analysis.
There may be cases where you would be required to perform port mirroring with a single source port
mapped to a single destination port. There are also cases where multiple source ports can be mapped to
a single monitoring port. These include the use of VoIP monitoring devices that track SIP sessions and

© 2018 TeleDynamics │ page 7


VoIP statistics. Such applications are more commonly found on the telco side than the enterprise
network. Depending on your device requirements and capabilities, you can choose the appropriate
configuration to suit your needs.
Switch vendors use a variety of terms to refer to port mirroring. For example, Netgear refers to the
feature as Port Mirroring, Cisco identifies it as Switch Port Analyzer (SPAN), and 3Com calls it Roving
Analysis Port (RAP). There are many options and several limitations to each configuration; additional
details can be found in each vendor’s device documentation.

5 Introduction to Wireshark
Wireshark is software that you can download and install for free on your computer. Although it is
available for Mac and some Linux-based systems, the Windows version will be detailed in this guide.
Wireshark version 2.6.1 is the latest version available at the time of publication and is referenced here.
The generic packet capture examples that do not necessarily relate to VoIP will be examined in this
section in order to gain a basic understanding of Wireshark and how it works. In subsequent sections,
real packet capture scenarios involving voice applications will be described and detailed.
5.1 First-Time Operation of Wireshark
When running Wireshark for the first time, the image shown in Figure 5 will be displayed after
installation. All of the available interfaces on the computer including wired, wireless and Bluetooth are
displayed, and the traffic detected on each is shown in a small graph. This indicates that the application
is ready to begin capturing packets. The filter field permits the user to enter various parameters that will
cause Wireshark to capture only specific packets. Although this can be done now, the same filters can be
applied after the capture to display only the desired packets.

Figure 5. Wireshark Welcome Screen

© 2018 TeleDynamics │ page 8


To begin packet capture, click the interface of choice and then click the Start Capture button, which
looks like a shark’s fin ( ) on the left side of the toolbar. Make sure you select the appropriate interface
(wired or wireless in the case of a laptop) to capture the packets you require.
Once the Start Capture button ( ) has been clicked, the window will change to a three-paned format
(see Figure 6). Pane 1 displays the packets being captured. The packets are displayed in a tabular format
as rows of digits and text, and will increase in number as traffic continues to traverse the network card.
The number of network applications being run will affect the table population rate. The Stop Capture
button ( ) can be used to either end or interrupt the capture process.
5.2 The Three Panes
Once the capture is complete, the panes shown in Figure 6 will be displayed within the Wireshark
window.

Figure 6. Capture Results

5.2.1 Pane 1 – A List of Packets


The first pane is the packet list pane and contains a list of packets in table format. Each column indicates
a packet parameter. The columns displayed are:
• No. – The number assigned to the packet. Upon arrival, each packet is assigned a sequential
number, beginning with one, for the specific capture. Pane 1 of Figure 6 shows that over 6,600
packets have been captured.
• Time – The number of seconds that have elapsed between the beginning of the capture and the
receipt of that particular packet.
• Source and Destination – These columns indicate the source and destination IP addresses found
in the header of each IP packet. This information comes from Layer 3 (Network Layer) of the OSI
model.

© 2018 TeleDynamics │ page 9


• Protocol – This column indicates the Transport Layer protocol being used. The Application Layer
protocol in use may be indicated, depending on the specific protocols in question. In Figure 6,
packets using TCP and UDP are shown, as well as the Internet Mail Access Protocol (IMAP), an
Application Layer protocol used for email.
• Length – This indicates the size of the specific packet in bytes.
• Info – This field contains specific information about the packet. Its contents depend on the
protocol being used and will vary accordingly.
The columns provide this information so that individual conversations with particular parameters can be
identified and isolated. Once the parameters have been determined, each packet can be closely
examined in the second pane.
5.2.2 Pane 2 – Layered Information
After reviewing the information given in Pane 1, identify the packet you want to examine and click on it
to reveal additional information. The second pane or ‘packet details pane’ then displays information
about the selected packet (see Figure 7).

Figure 7. Enlarged view of Figure 6, Pane 2

In Pane 2, four entries can be seen. Each of these entries is preceded by a greater-than symbol (>),
which if clicked upon, will expand the entry, showing additional information. Some entries have
subentries that can be further expanded.
The first entry for Frame 6653 includes generic information about the specific packet: when it arrived,
its size and which interface it was captured on. The next three entries correspond to Layers 2, 3 and 4 of
the OSI model.
The Ethernet II entry includes information shown in the expanded view in Figure 8. This information is
found within the header of the Data Link Layer (Layer 2). Both the source and destination MAC
addresses can be seen (highlighted in yellow), as well as the value of the Type field, which in this case is
IPv4 (highlighted in yellow).

Figure 8. Expanded Ethernet II Entry

© 2018 TeleDynamics │ page 10


The expanded Internet Protocol Version 4 entry (Figure 9) shows the source and destination IP
addresses at the end, in addition to useful information such as the Differentiated Services, where
Quality of Service mechanisms are implemented, as well as flagged items dealing with IP packet
fragmentation. This information is found within the IP header which operates at Layer 3 (Network Layer)
of the OSI model.

Figure 9. Expanded Internet Protocol Version 4

The Transmission Control Protocol displays information found within the Transport Layer header.
Depending on the protocol being used at this layer, the resulting information can vary widely. In this
case, the TCP protocol is being used, so we are viewing the information found within the header of the
TCP segment (see Figure 10). This information includes source and destination ports used by specific
applications on the device, sequence and acknowledgement numbers used to employ reliability
mechanisms, flags used to initiate and tear down sessions, and window size, which regulates flow
control.
From this information, the destination port (143) can be determined. This packet is a part of a session
retrieving an email message – Port 143 is used by IMAP, a protocol used to retrieve email and to
synchronize folders between an email server and clients.
Additional Entries – Occasionally, Wireshark may display an additional entry below the Transport Layer
in Pane 2, indicating a protocol that is running on top of the Transport Layer protocol in question. An
example of such a case is with voice, where control packets using the SIP protocol will have an additional
entry for SIP parameters, and where packets carrying the actual voice have an entry for RTP, the
protocol used to transport the actual voice. Both of these cases will be examined in depth later in this
guide.

© 2018 TeleDynamics │ page 11


Figure 10. Expanded Transmission Control Protocol

While fully understanding all of the information displayed for each layer explained in this section is not
necessary, it gives an understanding of the level of detail Wireshark will go into when capturing packets.
And keep in mind that what we have seen so far is a vast amount of information for just one packet;
Wireshark captures and saves such information for each and every packet.
5.2.3 Pane 3– Going Deep
Pane 3 is the packet bytes pane. It is not used for troubleshooting for voice due to the limited
information given, but is included here for completeness. This pane displays the full contents of the
selected packet including all headers in a standard format or hex dump. A hex dump uses hexadecimal
values to display the contents. By clicking on the various entries in Pane 2, you can see which parts of
the hex dump correspond to each entry. As shown in Figure 11, the source port value of the TCP entry is
selected in Pane 2 and the corresponding hex digits for that value are highlighted in Pane 3.

Figure 11. Hex Dump

As an aside, this makes a strong case for enabling encryption of any communication session, voice or
otherwise. If this had been a session where passwords were exchanged, those passwords could be
reconstructed from the data found in the hex dumps unless adequately encrypted.

© 2018 TeleDynamics │ page 12


The selected packet is small – only 54 bytes, so its full contents can easily fit within Pane 3. Typically,
packets can be up to 1500 bytes or longer, depending on the network configuration. In such cases, you
can scroll down to see the full contents of the packet. VoIP packets – both control packets as well as
those carrying the voice samples – are typically smaller.
5.3 Filtering Results
As is evident from the screenshots, a file capture – even one that only lasts a few seconds – can result in
hundreds or thousands of captured packets. The most difficult part of packet analysis can be sorting
through all of the available data to find the relevant information for troubleshooting.
Wireshark has powerful filtering mechanisms that can filter based on a multitude of parameters.
Wireshark’s display filter reference page includes thousands of parameters you can use to winnow the
results down to the specific packets you’re looking for.
Once the capture is complete, you can enter the filter parameters in the field labeled Apply a display
filter… As shown in Figure 12, upon entering a filter parameter, a window appears containing syntax
suggestions and options to complete the filter. As an example, to show only the packets that have a
destination port number of 443, we can use the tcp.port == 443 filter parameter. When this is done,
only the packets destined for this port are displayed in the packet list (see Figure 13). Port 443 is used by
the HTTPS protocol for secure web communication.

Figure 12. Filter Parameters

Figure 13. Sort Results for tcp.port==443

© 2018 TeleDynamics │ page 13


Notice that as you type in the filter field, whenever the text you type is valid, the field will turn green.
This means that you can safely press Enter and the results will be filtered accordingly. If it turns pink, the
text as it is typed will not bring about a valid result (see Figure 14).

Figure 14. Invalid Field Entry

It is possible to combine multiple statements using logical operators, where each statement is separated
by AND or OR operators. Figure 15 displays a result where all of the packets in the packet capture are
filtered to display only those that have a TCP port of 443 and a source IP address of 192.168.0.17. Out of
the thousands of packets captured, only nine packets satisfy both criteria. With the appropriate
parameters, it is possible to fine-tune a search to the few packets you are interested in viewing.
You can string together as many statements as you like with the AND and OR terms. Alternatively, you
can use the && and || symbols, respectively.
To further research Wireshark’s filtering mechanisms, see the list of useful links in section 9.

Figure 15. Filter Syntax Using the AND Operator

5.4 Managing .pcap Files


Once the capture is complete, you can save the information into a .pcap file. If you attempt to close
Wireshark or to begin a new capture, you will be prompted to save the file or discard the captured
packets (see Figure 16). Once saved, the file can be shared. To give an idea of how large .pcap files can
become, the file created in this example has a capture duration of just over 10 seconds and contains
7284 packets, with a size of 7.45 MB (see Figure 17).

© 2018 TeleDynamics │ page 14


Figure 16. Saving Packets

Figure 17. File Capture Size

The actual size of the file is dependent upon the number of packets and the type of traffic captured. This
specific capture had a YouTube video playing in the background, so there were a lot of packets captured
in a small amount of time. The size of most of the packets was close to the maximum of 1500 bytes.
Other traffic captures, such as voice, may be substantially smaller since the size of each packet for such
applications is typically much smaller, on the order of tens to a couple hundred bytes.
Security Notice: Be careful when sharing .pcap files as they may contain sensitive
information including registration passwords, server IP addresses and user names, if not
encrypted. The files may also contain personal information which, if proliferated, can
result in serious legal repercussions. Voice conversations can even be reconstructed and
listened to using Wireshark itself.
When sending such files to technical and helpdesk staff, it is always a good idea to zip them and secure
the compressed file with a password. When sending the file over email, share the password of the
compressed file with the recipient through other means, such as IM or text message.
5.5 Wireshark Capture Instruction Review
Before staring a Wireshark capture session, prepare the network and devices from which you desire to
capture packets. Once the network and devices are prepared:
1) Open the Wireshark application.
2) Select the interface from which you want to capture packets.
3) Click the Start Capture button ( ) on the left side of the toolbar.
4) Begin generating the traffic that you want to capture. In the case of capturing voice, initiate a
phone call on the device in question. You should begin to see packets populating Pane 1.
5) Perform any related activities on the devices to capture all of the relevant packets. For example,
initiate a phone call and ensure some voice is sent by speaking into the receiver, perform any
pertinent actions such as call hold, call transfer or anything else you’d like to test, and then hang
up the phone to capture the exchange of packets that tear down of the call.
6) Once all of the actions have been performed, press the Stop Capture button ( ) to end the
capture process.
7) Review the list of captured packets in Pane 1. Go through each of the timestamps and verify that
the duration of the capture matches the amount of time between the start/stop of the capture.

© 2018 TeleDynamics │ page 15


8) To save the capture in a .pcap file, click File → Save As… and save it to the location of your
choice.
9) The file can be shared just like any other file on the computer.

6 Real-World Voice Application Examples


In this section we look at some actual voice packet captures. We’ll use Wireshark’s filtering mechanism
to focus our view of packets and we’ll also examine the parameters of voice packets.
6.1 Scenario Details
The scenario being examined is one where there is an X-Lite SIP client configured on a computer with an
extension of 3XX and an IP address of 192.168.1.61. The device registers with a SIP server on the
internet with an IP address of X.Y.Z.23.1 There is a second phone that also registers on the same SIP
server that has an extension of 4XX and an IP address of X.Y.X.183.1 Details of the intervening network
infrastructure are not included here, such as the network address translation (NAT) router behind which
the X-Lite client is operating, as these are irrelevant to the exercise. Figure 18 depicts the scenario.

Extension 4XX
IP: X.Y.X.183

Network

Extension 3XX
IP: 192.168.1.61
SIP Server
IP: X.Y.Z.23
Figure 18. Scenario Exercise

6.2 Sample Capture Characteristics


The sample .pcap file used for this example has the following characteristics:
• Number of captured packets: 10993
• Capture duration in seconds: 115
• File size in MB: 2.56
The capture was performed on the computer running the X-Lite device.

1
These addresses are taken from the Wireshark capture used in this section. For privacy reasons, the first three
octets of the IP addresses have been obscured in the screenshots and will be referred to as X.Y.Z.23 and X.Y.X.183
in the text. The 192.168.1.61 address has not been obscured since it is a private IP address and cannot be reached
from the internet. The extension numbers have been similarly obscured.

© 2018 TeleDynamics │ page 16


The “interesting” traffic in this capture is a telephone call made from extension 3XX to extension 4XX.
However, during the time period of the capture, additional traffic was recorded that we don’t need to
view including some ICMP, ARP and TLS packets, each of which corresponds to various other
applications and utilities. So, we need to filter out the unneeded packets to view only the packets
pertaining to the call in question.
6.3 Packet Viewing Exercises
In order to view portions of the captured traffic, we’ll look at various filtering commands that we can
apply to isolate the packets we want. We will also look into specific types of packets to glean important
information from each.
6.3.1 Filtering the SIP Control Packets
In this exercise, we will explain how to isolate the SIP control packets of the conversation. In the display
filter field, use the SIP keyword in conjunction with the IP addresses of the X-Lite computer and the SIP
server involved in the conversation. These addresses are 192.168.1.61 and X.Y.Z.23, respectively. The
filter used is:
sip && ip.addr == 192.168.1.61 && ip.addr X.Y.Z.23

This filter shows all the packets that use the SIP protocol and have a source or destination IP address of
192.168.1.61 and X.Y.Z.23 (Figure 19).

Figure 19. Search Results – SIP Protocol and IP Address 192.168.1.61 and X.Y.Z.23

Notice the following from Figure 19:


• Of over 10,000 packets captured, only 20 packets match our criteria. This is typical, as the vast
majority of exchanged packets are those whose payload is the voice itself, so they use Real-Time
Transfer Protocol (RTP). SIP does not carry voice, but carries only the control information to set
up, control and tear down calls.
• The yellow highlighted area shows that the first packet is a SIP INVITE packet, which initiates the
phone call. The invite indicates the number that was called. In this case it is extension 4XX.
• The yellow highlighted area also indicates the port being used (the number inside the red box
after the colon “:”). In the interest of privacy, the port number here is blurred, and it is not the

© 2018 TeleDynamics │ page 17


default SIP port (5060). Changing the default port is good practice to avoid attacks targeting
default port values for SIP.
• Some packets are designated Requests and others are designated Status, as indicated in the
Info column. The Requests are SIP messages initiating a specific functionality, while Status
messages (or Responses) are messages responding to Requests and indicate the status of those
requests. Typical Requests include INVITE, ACK, NOTIFY, and BYE. Typical Responses include
Trying, Ringing, OK, and Bad Request.
• All Responses display a protocol of SIP, while Requests have a protocol of SIP/SDP in the
Protocol column. Session Description Protocol (SDP) is a companion protocol of SIP used for
describing multimedia communication sessions for the purposes of session announcement,
session invitation, and parameter negotiation.
• The SIP messages that have been filtered here are exchanged exclusively between the X-Lite
client and the SIP server. SIP messages may also be sent between the VoIP end devices involved
in the communication.
6.3.2 Analyzing the List of Packets
From the output shown in Figure 19, follow the SIP procedures taking place in initiating the call. Table 1
lists the steps taken by SIP to initiate the call. All of the information in Table 1 has been obtained from
the above packet capture. Note that all of these messages are sent within three seconds. Notice also
that the call was answered within two seconds of ringing.

Table 1. Steps Taken by SIP for Call Initiation


Pkt. No. Time(s) Type Command Description
2 1.75 Request INVITE The initiating of the call that is made from 3XX to 4XX
3 1.80 Status Trying The SIP server responds stating that it is attempting the
connection
4 1.80 Status Proxy The SIP server responds and states it requires authentication
Authentication
Required
5 1.80 Request ACK The initiator responds acknowledging the requirement of
authentication
6 1.81 Request INVITE The initiator of the call resends an INVITE with authentication
information
11 1.84 Status Trying The SIP server responds stating that it is attempting the
connection
13 2.00 Status Ringing The remote device is ringing
22 4.15 Status OK The SIP server sends a message stating that the call has been
answered

From Figure 19 we can also see that twice during the duration of the call (once at around 49 seconds
and once at about 94 seconds), there were additional exchanges between the X-Lite client and the SIP
server. Table 2 explains the first of these exchanges.

© 2018 TeleDynamics │ page 18


Table 2. X-Lite Client and SIP Exchange at 49 Seconds
Pkt. No. Time(s) Type Command Description
4687 49.14 Request INVITE Initiation of a new event sent from SIP server to extension 3XX
4695 49.23 Status Trying Acknowledgement from extension 3XX that the command has
been received
4696 49.24 Status OK Response from extension 3XX stating event was successfully
completed
4698 49.27 Request ACK Response from SIP server acknowledging the response

INVITE commands sent within a call that is already in progress, like the one above, indicate that changes
to the call are being made. This could include call hold, call transfer, call park, or other telephony
functions. Finally, the call ends with the SIP server sending a BYE request to tear down the call. The X-
Lite client responds with an OK confirmation. This can be seen in the yellow highlighted area in Figure
20.

Figure 20. Call Termination

6.3.3 Examining the Contents of SIP Packets


In this exercise, a single packet from the screenshots in Figures 19 and 20 will be examined. Specifically,
we’ll look at packet number 6. The response of the X-Lite SIP client after the server requested Proxy
Authentication is shown in Figure 21. The following screenshot shows this packet selected and displays
the contents of the packet in the Figure 22. Notice that Pane 2 in Figure 22 has five entries; the last is
Session Initiation Protocol or SIP. By expanding this entry and various subentries, additional details
about the packet can be viewed.
When expanding the Session Initiation Protocol item in Figure 22, there are several sections. The
highlighted areas are:
• Via SIP/2.0/UDP – This indicates the version of the SIP protocol that is being used, namely 2.0,
and underlying Transport Layer protocol that is carrying the SIP packet, which in this case is
UDP.

© 2018 TeleDynamics │ page 19


• To and From – These sections detail the information of the caller and the called parties,
including extension numbers, IP addresses, Transport Layer port numbers, and caller ID
information, which includes the name of the caller. The name can be seen in the line that begins
with SIP Display Info but is blurred in the screenshot.

Figure 21. Selection of Packet #6

Figure 22. Packet #6 Details

• Proxy-Authorization – This section is included in this SIP control packet because the original
INVITE sent to the SIP server (packet number 2) got a response of Proxy Authentication
Required (packet 4). This section includes the username, which is the extension number, and
three parameters that are involved in the authentication process: Nonce Value, Digest
Authentication Response and the MD5 Algorithm. The original INVITE (packet 2) did not
contain any proxy authorization information. This can be confirmed by comparing Figure 22 to
Figure 23, which is a screenshot of the SIP section of packet 2. Notice the Proxy Authorization
section is missing.
• User-Agent includes specifics of the device initiating the INVITE request. In this example, the
device is an X-Lite client version 5.0.1.

© 2018 TeleDynamics │ page 20


• Message Body only exists in SIP packets that are also using SDP. Information about the
communication session being established in this example is included and are shown in Figure 24.

Figure 23. SIP Section of Packet 2

Figure 24. Details Given in Message Body

Note the following information can be found within the Message Body entry:
• The creator of the session is indicated, including the IP address, as well as the name of the
session. In this case, the name of the session adopts the name of the actual client.

© 2018 TeleDynamics │ page 21


• The Media Description subentry shows the following details:
o The type of media (audio).
o The port being used for the media stream. This is not the same as the port used by the
SIP control protocol, but rather that used by the RTP stream carrying the voice packets.
o The Media Protocol being used to carry the actual voice packets. In this case it is RTP
using Audio Video Profile (AVP).
o The Media Format, indicating the codec that will be used by the communication. There
are several formats listed in order of priority. During negotiation with the remote
endpoint, the first commonly supported codec is used.
You can do further research using your favorite search engine as well as the ‘Useful Links’ in section 9 of
this document.
6.3.4 Filtering RTP Packets
RTP is the protocol used to transport the actual voice packets between devices. In this exercise, we look
at how to isolate these RTP packets. The RTP packets are exchanged between the two endpoints directly
and do not traverse the SIP server. For this reason, we use the following filter:
rtp && ip.addr == 192.168.1.61

The results show all of the packets that use the RTP protocol and have a source or destination IP address
of 192.168.1.61. In other words, it shows all RTP packets sent and received by the X-Lite client (see
Figure 25).

Figure 25. Search Results – RTP with an IP address of 192.168.1.61

© 2018 TeleDynamics │ page 22


Notice the following from Figure 25:
• The number of packets resulting from this filter is in the thousands. This is to be expected since
a voice conversation is composed of tens or even hundreds of packets per second.
• The first stream of packets is flowing from the source (192.168.1.61) to the destination
(X.Y.X.183). Halfway through the list, some packets begin to move in the opposite direction,
from X.Y.X.183 to 192.168.1.61. This is the point where the person on the remote device is
speaking and voice packets are consequently sent in the other direction. By scrolling through the
list, it can be determined when each caller was speaking by the number of voice packets sent in
a specific direction for certain segments of the call.
• Each packet has some extra information in the Info column that indicates the codec being used
(in this case, G.711).
• The size of each individual voice packet is 214 bytes. This uniformity is to be expected since
voice requires a steady stream of information, unlike the more bursty behavior of data
transmissions. The uniformity in size promotes a more timely delivery of the packets, resulting in
a better quality of voice service.
• The size of the packets is much smaller than the maximum allowable size of 1500 bytes. This is
typical of voice packets and is used to maintain a steady flow of data.
By clicking on a specific packet (here we click on packet 157), more details about the RTP protocol can
be viewed (Figure 26).

Figure 26.RTP Protocol Details

Note the following from Figure 26:


• The Real-Time Transport Protocol entry is an additional entry running on top of the UDP
Transport protocol.
• In the RTP entry, some of the information that can be obtained includes:
o Version of the RTP protocol being used
o The Payload Type, which includes the codec used

© 2018 TeleDynamics │ page 23


o The Sequence Number, which aids in the reconstruction of the voice once the packets
are received
o A Timestamp is used to indicate the instant of sampling of the specific piece of the voice
contained within the packet

7 Using Wireshark’s Telephony-Specific Features


To this point, we have seen how Wireshark can be used to filter out specific packets based on the
protocols being used, as well as the source and destination IP addresses. Wireshark has additional built-
in intelligence that can analyze whole packet flows and select specific information pertinent to voice
applications, while displaying it in a meaningful, informative manner. These features can be found under
the Telephony menu item (see Figure 27). In this section, we’ll examine the same flow of voice packets
used in previous examples, as well as the available options in the Telephony menu that can be useful
while inspecting these conversations. The menu items are:
• VoIP Calls
• RTP
• SIP Flows
• SIP Statistics
Once a packet capture has been made that contains SIP and RTP packets, any of these tools can be
selected to analyze and display data about the capture. The selected tool will be applied to the specific
packet capture that is open at the time.

Figure 27. Telephony Menu

7.1 VoIP Calls


The VoIP Calls menu item analyzes the packet capture and displays a list of calls made during the
capture. Multiple calls may be captured and displayed in a list. Figure 28 displays output from the VoIP
Calls tool on the packet capture.

© 2018 TeleDynamics │ page 24


Figure 28. VoIP Call Capture

Each voice call is listed as an entry in a table. In Figure 28, only one conversation takes place throughout
the capture process. Information found in this entry includes:
• Start and stop times relative to the beginning of the capture
• The IP address of the initial speaker; that is, the device that initiated the call
• From and To information, including the call display name, extension number and IP address of
the initiating device, and the SIP server of the destination device
• The protocol being used
• The duration of the call
• The number of packets exchanged – this is the number of SIP packets, not voice packets since
voice packets use the RTP protocol
• The state of the call, which indicates if the call was successfully completed during the capture or
not. In this case, the call was successfully completed during the duration of the capture.
• Comments, including some of the SIP events that took place during the call. These include SIP
requests as well as response codes.
There are several additional monitoring activities that can be performed from this window, which can be
found at the bottom of the window (see Figure 29). By selecting a voice conversation, these buttons
become active. Two functions that we review here are the Flow Sequence and Play Streams tools.

Figure 29. Additional Monitoring Functions

7.1.1 Flow Sequence Tool


Flow Sequence will provide a view of the exchange of SIP packets and RTP packets between the
initiating device, the SIP server, and the remote telephony device. Figure 30 is an example of the Flow
Sequence window. By viewing requests and the corresponding responses, it is possible to determine
where along the process of exchanging SIP messages any potential problem exists. Comments are
provided for each transaction, including the SIP request and response types. The number of RTP packets
sent or received is also included.

© 2018 TeleDynamics │ page 25


Figure 30. Flow Sequence Window

7.1.2 Play Streams Tool


This tool provides a view of the entire exchange of RTP packets associated with a specific conversation.
The tool opens a sub-application called the RTP Player that allows you to analyze the voice streams in
detail and even to play back the voice conversation.
The RTP Player window includes two RTP streams, one for each direction. These are displayed as two
separate waveforms where various events are indicated, including out-of-sequence packets, jitter drops,
incorrect timestamps and inserted silence (see Figure 31). The pane below the player provides
information about each RTP stream, including source and destination IP addresses and ports, the
number of packets, and the sample rate and codecs being used. The play button (lower left) can be used
to play back the audio of the conversation.

© 2018 TeleDynamics │ page 26


Figure 31. RTP Player

7.2 RTP
The RTP menu provides a list of all the individual RTP streams detected within the packet capture. Each
voice conversation is composed of two RTP streams, one in each direction. Figure 32 shows the RTP
Streams window after selecting RTP menu.

Figure 32. RTP Streams Window

As expected, two RTP streams for the single voice conversation are found within the capture and include
the following information: source and destination IP addresses, type of codec used, and information
concerning jitter. Additional tools that can be used in the RTP Streams window appear as buttons along
the bottom of the window. By selecting a specific stream and clicking the Analyze button, a new window
appears as in Figure 33.

© 2018 TeleDynamics │ page 27


Figure 33. RTP Steam Analysis

This window displays a list of all of the RTP packets sent in this stream and includes specific information
about each one, including sequence numbers, jitter, bandwidth and other important information
pertinent to VoIP audio.
7.2.1 SIP Flows
The SIP Flows menu item appears to be similar to the VoIP Calls menu item, but additional details
beyond those found in the VoIP Calls tool are displayed.
Unlike the VoIP Calls window, which includes a single entry for the entire voice call, the SIP Flows
window lists multiple SIP events that may occur during a single conversation. SIP information is
exchanged between devices whenever call control events occur within the duration of the call. These
events can include call hold, call transfer, call conferencing and other telephony features. When these
features are used, SIP packets are exchanged. It is these SIP packet exchanges that are detected in the
captured packets and displayed as individual flows in the SIP Flows window (see Figure 34).

© 2018 TeleDynamics │ page 28


Figure 34. SIP Flows Window

The first entry is similar to the VoIP Calls window, except for the additional details within the Comments
column, which shows all of the SIP requests and responses included in the exchange. A second flow
display shows a SIP event occurring approximately 23 seconds into the packet capture. The SIP Flows
window indicates that this is a CALL SETUP event with a REGISTER SIP request. SIP registrations are
time-based and will eventually expire, so this REGISTER event is simply a refresh of the original.
Subsequent REGISTER messages must contain the same parameters as the original registration. Calls
that include additional telephony events can be much more interesting to view in the SIP Flows tool. It
can be useful to itemize and analyze phone calls by their specific constituent events.

8 Appearance of Typical Voice Issues in Wireshark


This section briefly describes how common SIP and VoIP problems appear in Wireshark in order to more
readily identify them.
8.1 One-Way Voice
One-way voice is a common SIP issue characterized by a successfully completed call, where one caller
can hear the other, but not vice versa. This is usually caused by a NAT router or firewall between the
communicating devices that blocks one of the two RTP streams.
In Wireshark, such a situation would have the following characteristics:
• SIP packets would be successfully exchanged between the two end points in both directions.
• Calls would be successfully initiated, any SIP events during the conversation would appear
normal, and the call would be ended with the appropriate requests and responses.
• Observed RTP streams flow in only one direction. The number of RTP packets in one direction
increases over time, while the amount of RTP packets flowing in the other direction remains at
zero for the duration of the call.
8.2 No-Way Voice
This is similar to the one-way voice scenario. A call is successfully initiated, but neither caller can hear
the other. Callers know that the session has been successfully initiated because they see the call timer
showing the duration of the call on the IP telephone or SIP client.
In this case, the Wireshark indications will be the same as the one-way voice scenario, except that no
RTP packets will be exchanged between the end devices. The number of RTP packets in the RTP Streams
window will remain at zero for both streams.
8.3 Registration Failure
Another problem that may arise is registration failure, which may be due to an incorrect username,
password or an incorrect SIP server address. Such a scenario would display the following characteristics
in Wireshark:

© 2018 TeleDynamics │ page 29


• A SIP registration request would be sent by the initiating device.
• Normally, the SIP server would respond with a 200 response code (OK). But in the case of a
registration failure, the response would be 4XX. The 400 series of response codes indicates
some sort of failure, with the specific codes specifying the particular reason. For example: 400 –
Bad Request; 401 – Unauthorized; 408 –Request Timed Out.
A complete list of all available codes can be found among the ‘Useful Links’ provided in section 9
of this guide.
• Registration failure would best be seen in the SIP Flows window, which displays the failed
exchange of SIP packets along with the accompanying reasons.
8.4 Server Not Found
In the event that the SIP server cannot be found, and therefore no IP communication can be successfully
made with it, then the attempted call will obviously fail. The resulting behavior observed in Wireshark
would be SIP messages sent from the initiator that will not receive a response from the server. When
viewing the packets captured in Pane 1, you would see SIP requests with no counterpart responses.
8.5 Know the Codes
Many of the problems that arise when dealing with SIP and VoIP can be intuitively understood by
examining the request events and response codes. Using Wireshark’s telephony tools and gaining a
fundamental understanding of the codes and their meaning will go a long way towards understanding
the problem and why it occurs.

9 Useful Links
www.wireshark.org Download Wireshark
www.wireshark.org/doc/ Wireshark Documentation
www.wireshark.org/docs/dfref/ Wireshark display filter reference
www.wireshark.org/docs/wsug_html_chunked/ChWorkB Building display filter expressions
uildDisplayFilterSection.html
en.wikipedia.org/wiki/Session_Initiation_Protocol Information about SIP
en.wikipedia.org/wiki/Session_Description_Protocol Information about SDP
en.wikipedia.org/wiki/List_of_SIP_request_methods A list of SIP requests
en.wikipedia.org/wiki/List_of_SIP_response_codes A list of SIP response codes
en.wikipedia.org/wiki/RTP_audio_video_profile A description of the RTP Audio video profile
en.wikipedia.org/wiki/List_of_codecs#Voice A list of ITU-T voice codecs
tools.ietf.org/html/rfc1889 Information about RTP
www.counterpath.com/x-lite/ X-Lite free SIP client
https://www.voipmechanic.com/glossary.htm A glossary of VoIP related terms

© 2018 TeleDynamics │ page 30


10 Support
The TeleDynamics VoIP and networking support team is available to help you at
IPTechSupport@TeleDynamics.com. For questions or comments regarding this guide, or general
questions about TeleDynamics, email info@teledynamics.com or call (800) 847 5629 (U.S. and Canada)
or +1 512 928 1533 (international).

11 Partnering with TeleDynamics


At TeleDynamics, we consider our dealers a part of our family and we enjoy developing long-term
relationships with all our customers. By becoming a dealer, you will receive our twice-yearly full line
color catalog, along with seasonal mailers and email updates. Upon approval, you will be provided with
a User ID and Password for access to special pricing and offers on our website. TeleDynamics dealers
also benefit from a number of top-shelf services such as drop-shipping, same-day shipping, provisioning,
leasing programs, and expert technical support, in addition to great customer care. For more
information and to apply, visit www.teledynamics.com.

© 2018 TeleDynamics │ page 31

Вам также может понравиться