Asterisk Tutorial 38 — Introducing Wireshark

Introducing Asterisk & Going Deep With Wireshark

Welcome to Introducing and Going Deep with Wireshark. In today’s episode, we have somewhat changed our plans. Originally, we planned to introduce Wireshark as an application and what it can do. But then something in our last episode caught our eye — the second pcap trace packet size was surprisingly small and we wondered why.

What that means is, we have our first look at Wireshark as well as getting up close with Wireshark’s analysis tools as we try to uncover what the cause could be.

What is Wireshark

Wireshark is an open source tool that is available to download fromwww.wireshark.org. As an open source tool, there are distribution options for most mainstream operating systems. While Wireshark is particularly useful in debugging SIP, that is not its sole function. In actual fact, it is actually a complete network protocol analyzer that comes complete with a vast range of telephony analysis tools.

As a network analysis tool, Wireshark can also perform live captures. However, as mentioned last week, our telephony traffic goes over our Asterisk server and not our local machine which is why we did the tcpdump. If like use you are using Wireshark version 1.10.7, the start screen when opening will look similar to below:

Newer versions look a bit different, but the overall menu structure and workflows are pretty much the same, so you will not have to reacquaint yourself with the application:

Using Wireshark

In order to use Wireshark to analyse the trace that we performed in our last episode, you will need to copy the file from your Asterisk server to your local machine. In our example, we used the scp command as shown below to copy the file from our Asterisk server onto our studio machine:

scp pcadmin@192.168.100.55:/home/pcadmin/test.pcap

Just remember that you will need to logged into the local machine and not the Asterisk server. Once the file is saved on your local machine, you will be able to open it in Wireshark after which a screen similar to the one shown below will appear:

The screen above shows all the traffic that was captured whilst performing our tcpdump last time around. This information could well be useful, but for now we are only interested in the telephony traffic. Therefore, click on theTelephony menu tab and then select VoIP Calls from the drop down list. Doing so will bring up a new window in which all the detect VoIP calls are listed:

If you watched last weeks tutorial but haven’t watch this week yet, you may well be thinking: “hang on, they only made one call so why are there two calls listed?” It’s a good question with a simple answer. Remember back in our SIP in Detail tutorial, we outlined the “SIP Handshake” and talked about the two call legs. Meaning, the two VoIP calls listed above represent the two call legs which it why it looks like two calls when in fact there was only one (see the previous tutorial).

Now select either one of the calls as it doesn’t really matter which one and click on “Flow”. This will then open a new window showing the call’s SIP architecture which includes both call legs, hence why it doesn’t really matter which one you click on. By clicking on the individual aspects within the graph (green area), Wireshark will jump to the relevant packet listed in the main screen, meaning you can also view the details of the selected packet.

This is particularly helpful if you have multiple calls contained within you capture. By using the Wireshark VoIP Calls and then Flow method you can open individual calls and then select protocol aspects and instantly see which packet relates to the “INVITE” for example.

Live Debugging

Through following the above process and simultaneously explaining every step, we then came to point half way down the green graph above and quickly realised why our packet size was smaller than we thought it would be. Ordinarily, after the call had been established (2nd “ACK”) we would have expected that we would start seeing the RTP elements of the call. But in stead of seeing the payload, we found another invite (or more accurately a re-invite).

As you will recall, when a re-invite is sent and acknowledged all the RTP packets contained within payload will be transmitted directly between the two IP endpoints, thus bypassing the server completely. As we captured the traffic passing through the server, it is now clear why our packet size was not what we expected as all the RTP packets were transmitted directly — all expect for one packet which should not be there. And the answer to why it is will be coming next week!

More Info

At pascom, we are the developers of the mobydick phone system. Being based on Asterisk, mobydick provides businesses with an easy to install, manage and use Open Standards phone system.

Why not take mobydick for a test spin with our free community download. Need more info about mobydick or would like a personalised demo? Give us a call +44 203 1379 964 or drop us a line via our website.

Until next time — Happy VoIPing!

Originally posted on blog.pascom.net