Links

Sniffin’ the VOIP traffic

This time we will install a network protocol analyzer to watch the traffic on our LAN from initiating and connecting a SIP call.

The Wireshark open source project was formerly known as Ethereal. I used to work for a great company called Cybera as a programmer, and I was always fascinated by networking. I’d bug the network engineers for any information I could, and play around with Ethereal to try to understand what they were talking about.

If you’re working under windows, download the installer. For our Ubuntu or Debian friends, it’s available under the standard free apt archives.

There’s one little trick you need to be aware of during the install.

Make sure you select WinPCAP as part of the installed goods.Complete the install and start the program. Minimize it for the time being.

Run over to another box on your LAN and make sure you can ping this address, as detailed in my last post.

If you don’t see ‘Logged In’ in the faux LCD window, most likely you’ll need to update the IP address that the phone needs for Asterisk.

Click the little Menu button juuuust to the left of the green phone button. Select System Settings->Sip Proxy->Default.

Make sure that the IP address for Domain/Realm, SIP Proxy, and Outbound proxy are all set to the IP address of the Asterisk Trixbox server you just started via VMWare.

Remeber, Nerd Vittles set us up with 500 and 501 as 2 extensions to use with these phones. Dial 501 from the 500 phone or vice versa. I launched mine just now and I can hear the kids, dog, and my wife doing fun stuff. Frankly at this point I have to sit back and marvel at the processes running to make this possible. It just blows my mind.
Now comes the hackin’ part. As the SIP call is in progress, flip back to Wireshark.

From the main window, select Capture->Interfaces.

I can see one of the listed network interfaces dealing with a lot of traffic. Choose that one and press the capture button.

Let wireshark capture at least 5 or so seconds of traffic. So far, on mine, the vast majority of this VOIP traffic is of the UDP variety. Click Stop and wireshark will dump it all into its analysis window.

Every line that says OICQ Protocol represents one UDP (User Datagram Protocol) VOIP packet traversing the network. As a side note, it appears that Wireshark has made the assumption for us that these packets are really part of a chat protocol popular in China, which, of course, is not correct.

Right click on one, and select ‘Open in new window’. Go down to the bottom and look at the ‘data’ section of the packet. This data section represents the actual digitized voice of the VOIP call. It’s interesting to me that the protocol used is UDP, which is one of the two major types of IP packets, the other being TCP. UDP is a connectionless protocol, which means that the client generating the traffic simply puts the packet on the wire without regard to checking to see if the recipient actually received it. This also implies that the recipient has to collect the correct UDP packets and reorder them to form a meaningful conversation. I wonder what role the SIP ‘stack’ in asterisk plays in this function. I suppose we’ll find out here at Asteriskblog!

Well, I hope you’ve found that illuminating, and I’m sure we’ll be referring to this tool to diagnose our further work in Asterisk. Please contact me if you have any questions.

5 Responses to “Sniffin’ the VOIP traffic”

VoIP calls (similarly to POTS calls) basically break down into two parts: the signalling (SIP) and the actual transport (RTP). SIP/RTP is not the one and only protocol for this, there are other protocols for signalling and transporting, Asterisk’s IAX for exampe does both.

SIP: Session Initiation Protocol
RTP: Realtime Transport Protocol
SIP is used only for signaling, RTP is used for transport. SIP itself doesn’t provide any means of transporting the actual voice data.
The SIP protocol can run over TCP or UDP connections. Asterisk (1.2) only supports SIP on UDP. After two endpoints negotiated a session using the SIP protocol they start exchanging voice data which is transported by RTP.
SIP as well as RTP are by default unencrypted, that’s why you can even playback phone calls in realtime. There are “secure” versions of SIP and RTP called SIPS and SRTP that provide authentication and data encryption.

Regarding reording:
SIP messages are quite small and compact, resembling e-mail headers in structure, and they won’t exceed the 64kByte limit for UDP packet size so there is no need for any reordering.
RTP (which uses UDP) defines its own additional header with sequence number and timestamp.

If Wireshark catches the SIP transaction, it will identify the stream as RTP and can dig into the details. You can also force Wireshark to crack into the udp packets to see if they’re RTP from the protocol options.

Once the packet is identified as RTP, you can run analysis on it to find out of order packets, jitter, and latency. You can also display the SIP call setup in graph form.

Sorry but I do not think there is any news in this article. Ethereal can sniff and decode most of the VoIP protocol for ages.

Moreover Intel has published (in 2004) a paper named “Using Ethereal to Debug SIP and RTP on Voice over IP (VoIP) Products from Intel”. The Intel publication is not restricted to Intel products and gives a lot of tips and hints to debug SIP/RTP calls in details.