Welcome back.
In this module,
we are going to get our hands dirty with some live hands‑on demos.
Have you ever been on a call and heard choppy audios,
long pauses or other strange sounds, or maybe a call that never connects.
I've been in such situations many times before,
and trust me, the users are usually pretty annoyed with such calls.
You may be involved in high pressure calls if the calls
are impacting high‑profile end users.
Expect escalations and long calls with other data network
engineers or network security engineers.
You will be trying to prove that it's due to a packet drop from
some network devices and not your VoIP servers,
and that's a tough situation to be in.
Well,
that's where tools like Wireshark and other monitoring and
troubleshooting tools come in handy.
Many free and open‑source protocol analyzers like
Wireshark allow you to capture network traffic from the
end‑user computers or network devices, view them,
analyze them, and define a problem out of them.
Like in the previous example, we saw the SIP‑protocol‑related traffic.
Here is another example of a call I captured from my computer.
It's a SIP call initiated by my Cisco Jabber, and it failed.
Let's analyze the packets we captured.
Let me filter it with a keyword, s‑i‑p, sip here,
and now it reflects all the SIP‑protocol‑related packets.
Let's again go to Telephony, and then click on VoIP Calls.
Here is the call I initiated from my Cisco Jabber.
Now you can see the Start Time and Stop Time,
which is very critical piece of information; the endpoint extension
from which the call was initiated; to the endpoint it was sent to;
the protocol used; the duration of the call; and If you take a look
at the state, it was rejected.
Let's click on the Flow Sequence button here to find
out what all events took place.
So we see the initial INVITE that was sent with an SDP message
which has the supported list of codecs like opus,
variants of G.722 Codecs, and G.711 u‑law codec.
So we now know it was an Early‑Offer call,
as the supported codecs are offered within the INVITE message.
We also see that we are getting 183 Session Progress with the SDP message,
which is usually an announcement from the other end
informing us that something is wrong with this call. And
the next message is 404 Not Found.
Let's close it, and now let's take a look at the RTP headers to see
if there are any lost or out‑of‑sequence packets.
We see all the RTP packets related to the calls here.
We see the individual packet details like the time,
the source, or the destination.
We also see the codec negotiated is a variant of G.711,
which is G.711 u‑law. Let's see how these RTP packets form
an audio call all together.
Let's go to the Telephony tab, and then go to the RTP option.
Now let's select the RTP Streams from here. Here is our call listed
with details such as Source and Destination Address, Start and End
Time, Jitter or packet loss. Let's open the audio stream by clicking
the Play Streams button here. Here's the actual audio combined with all
the audio packets together.
Now I can play it here,
and it is the announcement that says the call cannot be completed as dialed.
Please check the number and dial again.
Let's go ahead and find out more details with the button Analyze
here. This is going to give us more details of each packet with
sequence, timestamp, jitter of each packet, skew, and
bandwidth‑related information.
You can also see the maximum jitter, minimum jitter or average jitter values.
Less than 30‑ms jitter is quite acceptable, but
with more than 30‑ms jitter value,
you will not be able to understand the other party clearly. You can capture
these packets from the end user's computer involved in the problematic call or
any intermediate network devices such as routers,
switches,
and even firewalls, to see where exactly the call is getting worse with
more jitter or packet drops. Once you know which device is dropping the
packet or delaying the packet transfer, you can narrow down the issue and dig deeper to troubleshoot it further.