VoIPowering Your Office: Debugging SIP Sessions Without Excessive Hair Loss

By Carla Schroder | Jul 16, 2007 | Print this Page
http://www.enterprisenetworkingplanet.com/unified_communications/VoIPowering-Your-Office-Debugging-SIP-Sessions-Without-Excessive-Hair-Loss-3688936.htm

No matter how much of a wizard you are with the usual network analysis and troubleshooting tools, such as ping, tcpdump, mtr, ntop, Wireshark, Nmap, Nessus, and so forth, using them to debug SIP sessions can be a fast track to madness and despair. SIP is complicated and many-tentacled. SIP is highly distributed, with Cancels and Invites and parallel forking and seemingly random routing, so we really need something that can follow all of this energetic tangle and make sense out of it.

tcpdump and Wireshark are still the most useful of packet sniffers; they will help you even with SIP problems, though they have their limitations with regards to SIP. You can use tcpdump to follow a single call to try to figure out where it's going wrong:

# tcpdump -pi eth0 -s0 host 192.168.1.142 and udp port 5060
This tells tcpdump to not put the network interface into promiscuous mode, listen to eth0, capture the entire data payload on host 192.168.1.142, UDP port 5060 datagrams only, because that is what the SIP protocol uses. Make a call, and you'll see output like this:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65335 bytes
10:41:19.454886 IP 192.168.1.10.5073 > 127.0.0.1.5060: SIP, length: 1022
        0x0000:  4500 041a 6c7d 0000 4011 c8a9 c0a8 0203  E...l}..@.......
        0x0010:  7f00 0001 13d1 13c4 0406 6ef8 494e 5649  ..........n.INVI
        0x0020:  5445 2073 6970 3a35 3030 4065 6b69 6761  TE.sip:250@foo
        0x0030:  2e6e 6574 2053 4950 2f32 2e30 0d0a 526f  .net.SIP/2.0..Ro
        0x0040:  7574 653a 203c 7369 703a 3132 372e 302e  ute:.
If all you want to see is header information, which shows IP addresses and connection information without the data payload, omit the -s0 switch. This example shows a live capture; you could also save it to a file with the -w [filename] switch:
# tcpdump -c 200 -pi eth0 -s0 -w sipdump host 192.168.1.142 and udp port 5060
Then open the file in Wireshark for easier slicing and dicing of the captured output. -c 200 limits it to a count of 200 runs. If you don't set a count limit, stop it with Ctrl+C.

Using promiscuous mode is pretty much a waste of time on switched networks, and you want a targeted capture anyway.

Asterisk's built-in SIP debugger
Asterisk comes with the sip debug command, which you run on the Asterisk console:

asterisk1*CLI> sip debug
SIP Debugging enabled
When there is call activity you'll see output like this on the console:

---
[July 7 16:46:41] DEBUG[25349]: chan_sip.c:1977 __sip_reliable_xmit: *** SIP TIMER: Initalizing retransmit timer on packet: Id #8
[July 7 16:46:42]
<--- SIP read from 11.22.33.44:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 11.22.33.44:5060;branch=z9^26tcpdump27^1b090600;rport
From: "asterisk" ;tag=as74294d92
To: ;tag=C6905CEB-8E04615C
CSeq: 102 OPTIONS
Call-ID: 77b1a966680935ce45c5be5b089c31f4@11.22.33.55
Contact:
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER
User-Agent: PolycomSoundPointIP-SPIP_601-UA/2.0.3.0127
Content-Length: 0

You can turn on debugging for a single host with the sip debug ip [host:port] command, and troubleshoot a problem peer with sip debug peer [peername]. (Peers are configured in /etc/asterisk/sip.conf, in case you forgot.) Turn it off with sip no debug.

SipSpy
SipSpy is a distributed SIP monitor designed to see all, know all, and report all. You install a monitoring agent, which is called spyAgent, on your hosts that process SIP messages, such as your Asterisk, Trixbox, PBXtra, SipX, or SIPxchange server, plus any inbound or outbound proxies. The spyAgents all report to a central Java-based manager called SipSpy. SipSpy then sorts out the different call streams by CallID, so a simple mouse click shows you the individual call sessions. Easy peasey. You can filter traffic using the usual BPF (Berkely Packet Filter) expressions just like in tcpdump and Wireshark, and other standard packet sniffers.

Agents must authenticate to the spymaster, and you can save sessions for later analysis. These are stored in plain text XML files. Currently it only runs on Linux and other Unix-type systems, but the authors are working on supporting Windows. SipSpy is a free program licensed under the GPL, so don't be shy about pitching in and helping.

ngrep—Network Grep
ngrep is a great little tool that is like tcpdump plus the grep command. ngrep captures network traffic just like tcpdump, while using a grep-like search on your capture. The great thing about using ngrep is it searches on text strings instead of protocols, which a lot easier for us ordinary mortals. So you can easily search by username, extension numbers, hostnames or addresses—anything at all. For example, you might want to see only INVITES and what they are doing:

# ngrep -W byline -d eth0 INVITES
The -W byline switch preserves ngrep's natural line breaks for better readability.

Endpoint and peer registrations are common sources of trouble:

# ngrep  -W byline -d eth0 REGISTRATION
If you don't want to bother with getting the cases correct, use the -i switch for a case-insensitive search. You may monitor any host remotely:
# ngrep -W byline -d eth0 host 192.168.1.10 
-O [filename] dumps the result into a file.

Analyzing all that output
Now that you know how to watch SIP in action, what do you with all of that output? First of all, just read it line by line. You'll quickly get the hang of following the flow and recognizing trouble spots. If you're still stumped, you'll have the information you need to post on a mailing list, user forum, or to show your tech support.

Resources
tcpdump
Wireshark
SipSpy