How to Debug SIP

When I was younger I had two careers in mind – a college professor or a radio disc jockey.   For better or worse, I ended up being a software developer at a telecommunications company.  I can’t complain too much, though.  I worked on a number of really cool projects.  I’ve traveled all around the world on the company dime.  My name sits in the U.S. patent office along with Thomas Edison and the inventor of the Whoopee Cushion.  Still, while I’ve lost interest in being a DJ, I continue to feel the call to teach.

Thankfully, I do have an opportunity to periodically stand in front of a bunch of students and play professor.  While it’s not the same as tenure at an Ivy League university, I am able to develop curriculum and impart  knowledge to willing pupils.

I am talking about the SIP class that I teach every few months.  It’s only a two and a half day course, but it’s a very intense two and a half days.  We start with the basics of SIP before going through every message type, all the important responses, call flows, media, security, and even touch on cloud communications.  My students learn as much as anyone could be expected to learn about SIP in such a short period of time.

One of the reasons why they leave class with more than just a “book learning” is that we put SIP to work.  They install a SIP soft phone to make calls, change their presence status, send instant messages, and invoke call features such as conference, transfer, and hold.  While seeing those things from a user’s standpoint is important, I get them down and dirty with the protocol itself.  They make those calls and then wade through SIP messages to understand exactly what happened behind the curtain.

My tool of choice for dissecting call flows is Wireshark.  Wireshark is a free packet tracing tool that captures, formats, and displays IP packets.  Do you want to know how Address Resolution Protocol works?  Use Wireshark to capture and display ARP messages.  Do you want to know what happens when you surf the web?  Use Wireshark to capture and display HTTP and HTML messages.  Do you want to know what happens when you transfer a SIP call?  You guessed it.  Wireshark will capture and display SIP messages.

Using Wireshark for SIP is pretty simple.  There are a number of great tutorials on the Internet to help you understand the fundamentals of how to capture IP packets so I won’t attempt to repeat those instructions in any detail.  Essentially, you begin by telling Wireshark to capture the packets on a particular interface (e.g. your LAN card).  Press “go” and Wireshark will then record every IP packet that comes to or from your PC.   Press “stop” when you think you’ve captured what you want.

To capture SIP messages you want to do something SIP-wise between “go” and “stop.”  The first lab lesson in my class is to make a two-party call.  Thad calls Andrew.  Andrew answers the call.  Thad hangs up the call.  This will cause Thad’s SIP phone to send INVITE, ACK, and BYE requests.   Andrew’s SIP phone will send 100 Trying, 180 Ringing, and 200 OK response messages.

After capturing packets you will, of course, want to look at them.  You may be surprised at how many messages your PC sends and receives even when you think it’s doing absolutely nothing.  However, don’t let the abundance of these background packets scare you away.  There are ways to hide them.


The easiest way to tell Wireshark to only show you SIP messages and disregard everything else is with the “VoIP Calls” command.  This can be invoked as follows.


On my test lab PC, I made all kinds of SIP calls while Wireshark was running in capture mode.  Each session will have its own entry.


The first in the list is Thad calling Andrew.  Select it and click on the “Flow” button to see the following.


Wireshark displays the call flow in an easy-to-understand ladder graph.  To get inside one of these message simply click on it.  For example, if I click on the INVITE, I see the following.


Do you see that little plus sign (“+”) next to the words “Session Description Protocol”?  Click on it and the actual INVITE message will open up.


At this point you can examine the SIP URI, headers, and even the message body.  Since SIP is fairly easy to read and understand, it doesn’t take much to figure out what is happening with each message in a call flow.  That’s assuming, of course, that you’ve been reading my many blog articles on SIP messages and responses.

You can save these traces, too.  Wireshark saves traces in pcap (packet capture) files.  It’s not uncommon for me to debug problems on systems I’ve never seen by loading up pcap files from those systems.

The last thing I want to show you today is how to get to the actual media.  As you may recall, media is sent in RTP packets and since RTP is just another kind of IP packet, Wireshark captures those, too.  Go back to the list of SIP calls, select one, and press “Player” to see the following.


This allows you to “Decode” and “Play” the audio spoken between Andrew and Thad.  You can play one channel (e.g. Thad) or both channels (e.g. Andrew and Thad’s two-way conversation).

This only scratches the surface of what Wireshark can do for you, but it’s more than enough to make you dangerous.   If you are curious to learn more, download Wireshark from, find yourself a SIP soft phone, and go to town.  It’s the absolute best way to learn this stuff.


  1. Hi Andrew,
    I would recommend Cain&Able for demonstration of a call hijack in the security discussions in your course and sipsak for session hijacking.

    I’ve also got Asterisk and SIP Express Router (what ever flavour you prefer) and a sprinkling DNS (bind) for NAPTR and SRV records, running on VMs.I also have Open IMS core for my telco students. Makes for nice compact lab. You can also throw in a couple of hardware phones if you have a nifty little use powered switch like picked up from Blackbox here in the UK.


    1. Good stuff, Neill. Given the resources I have to work with and the fact that I only teach this class every few months, I have relied on a bare-bones lab setup. I also take it on the road so I try not to do more than I can accomplish with a few notebook PCs. Still, I like the idea about Cain&Able and will see if I can somehow work that in.

  2. […] Source: […]

  3. Hi Andrew, Good trainings. Thank you. Since the INVITE has a configured timeout, I question the usefulness of the Trying response. It seems like an overburden on the sip server.

    1. Tom, the 100 Trying is necessary to stop the retransmission of the INVITE message. It tells the sender that the INVITE has been received and is being processed. For a deeper dive into the subject, please see my blog on SIP timers.

  4. Hi Andrew! Greetings from Madrid, Spain! I have been working with SIP for about three weeks now and I’m finding your blog very useful, practical and interesting. SIP is my breakfast, lunch and dinner right now and Wireshark is the best way to digest it!

    1. Thank you! I am glad you enjoy this little hobby of mine. 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: