Академический Документы
Профессиональный Документы
Культура Документы
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
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.
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.
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
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
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.
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).
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.
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.
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.
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.
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.
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
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.
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
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.
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.
• 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.
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.
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).
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.
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.
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.
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).
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.
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