slingshot.tel Open in urlscan Pro
2606:4700:3036::ac43:c6ea  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Skip to content
 * +877 776 0673
 * info@slingshot.tel
 * Mon - Fri: 9:00 - 18:00 EST

Customer Login
 * +877 776 0673
 * info@slingshot.tel
 * Mon - Fri: 9:00 - 18:00 EST

Customer Login
 * Business Phones
 * Plans & Pricing
 * Blog

Menu
 * Business Phones
 * Plans & Pricing
 * Blog

Book A Demo


USING PACKET ANALYSIS TO SOLVE VOIP ISSUES

BY EDWIN J. FRONDOZO, CO-FOUNDER


Instantly download a printable cheatsheet on spotting an email phishing attempt

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:

 * Voice quality issues
 * FAS, early media-related issues
 * Intermittent call failures
 * VoIP interconnection issue
 * Protocol, codec mismatch issues
 * Identification of malicious network activity
 * Identification of bandwidth utilization

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:

 * Application HTTP, SMTP, FTP, Telnet
 * Presentation ASCII, MPEG, JPEG, MIDI
 * Session NetBIOS, SIP, SDP, NWLink
 * Transport TCP, UDP, SPX

All of the widely used protocols in VoIP telephony can be analyzed with the help
of Wireshark, like:

 * GSM ,H.255,IAX2,SIP, LTE, RTP, SRTP,SCTP, H.323

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:




EXPLORING THE SIP BUILDING BLOCKS:

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:

 * SIP Packets – to understand the cell signalling mechanism
 * RTP Packets – to understand voice quality issues because RTP carries the
   voice packets

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.

 * It contains the media IP that is used to established media connection;
 * It shows the user agent information. It shows the SIP version that has been
   used to negotiate the call.
 * It shows the codec information, which the calling party has offered to the
   called party side.
 * It shows the DTMF digits information, whether it’s shared in the form of the
   telephony-event parameter or not.

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:

 * The IETF defines RTP in RFC 3550
 * The payload format for several CODECs are defined in RFC 3551
 * RTCP is defined in RFC 3550 used to address delay and jitter issues
 * Secure RTP is defined in RFC 3711
 * SIP is defined in detail under RFC 3261

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.

Instantly download a printable cheatsheet on spotting an email phishing attempt

Want to learn more?  Read these related articles:

 * FIND OUT THE MOST IMPERSONATED BRANDS IN 2021

 * WHAT IS PHISHING AND WHY IS IT IMPORTANT?
   
    



Please click Like if you found value in this article.  Click Share to spread the
love, thank you!




PRODUCTS

 * Business Phone Plans
 * Business Phones
 * BRIA Enterprise Softphone
 * BRIA Softphone – Quick Start

Menu
 * Business Phone Plans
 * Business Phones
 * BRIA Enterprise Softphone
 * BRIA Softphone – Quick Start


SERVICE

 * Virtual PBX system
 * Get started in 5 minutes
 * Cloud Phone Network
 * Hybrid Workforce
 * Business Phone System Course

Menu
 * Virtual PBX system
 * Get started in 5 minutes
 * Cloud Phone Network
 * Hybrid Workforce
 * Business Phone System Course


COMPANY

 * About Us
 * Our Team
 * Refer A Friend
 * Contact Us
 * Support Desk
 * Read our Blog

Menu
 * About Us
 * Our Team
 * Refer A Friend
 * Contact Us
 * Support Desk
 * Read our Blog


© 2006 – 2024 dgNetrix Communications, Inc.