Switching to VoIP

11.3. SIP Packet Inspection

If you enjoy sifting through megs and megs of captured packets, you're either a nefarious cracker searching for an elusive password, you're a network QA analyst who gets paid by the byte, or you have a sick sense of pleasure . Sifting through mounds of packets that have been captured from the network isn't entertainment, after all.

Even among network administrators, the use of packet-sniffing tools is often a last resort. When logfiles, packet loggers, and other analysis tools fail, the ol' packet sniffer gets the dust blown off, and the administrator has to refamiliarize himself with it in order to figure out exactly what's wrong on his network.

But, since you're serious about VoIP, you should cozy up to that sniffer. In packet telephony applications, capture tools aren't just the last resortthey're a primary troubleshooting tool. Using a sniffer (or protocol analyzer ), like the ubiquitous Ethereal or Network General's aptly named Sniffer, you can capture and dissect call setups, teardowns, and other signals. You can zero in on capabilities negotiationsay, to figure out why two particular phones can't call each other while the rest of the network functions fine.

11.3.1. Project 11.1. Inspect SIP Traffic with Ethereal

11.3.1.1 What you need for this project:

• SIP registrar such as Asterisk

• Xten Network's X-Lite SIP softphone

• Ethereal software running on Linux, Windows, or Macintosh

Ethereal is a packet analysis tool that you can use to inspect network traffic, from the Ethernet layer all the way up to the application layer. Packets are captured in a buffer and displayed on the screen. Filters can be applied to restrict the capture to packets matching a certain source, destination, size , protocol, or service.

To obtain Ethereal, download it from http://www.ethereal.com and install it on your Windows, Mac, or Linux box. The screenshots and examples here assume the Windows version. You'll also need a SIP softphone such as X-Ten Network's X-Lite or X-Pro. This project assumes X-Lite. Both X-Lite and Ethereal will need to be running on the same machine, because switched networks permit you to sniff only packets that are being sent to or from your own host. (If you're using a non-switched network, like a hub, Ethereal can observe packets not bound for or originated from your PC.)

To demonstrate SIP packet observation with Ethereal, we'll set up a filter that allows us to capture SIP registration signals in two scenariosone for a successful SIP registration, another for a failed SIP registration. As in the other projects, the SIP server with registrar is 10.1.1.10. In this instance, Asterisk is used as the SIP server.

11.3.1.2 Configure the SIP softphone

If you're setting up X-Lite for the first time, you'll need to click the configuration button, right of the center, next to the Clear button (see Figure 11-1). Once you click this button, you'll see the configuration menu appear.

In the configuration menu, double-click Menu, then System Settings, then SIP Proxy, then [Default]. This will take you to the SIP client configuration, as in Figure 11-2.

Here, you can configure the softphone to register using a number and/or password to match what you've established in the dial-plan configuration on the SIP server.

Once configured as in Figure 11-2, the SIP softphone will automatically register with the SIP registrar as soon as you close the configuration menu. If registration was successful, you'll see Logged In in the UI display, as in Figure 11-1. If not, make sure the SIP proxy profile called [Default] is enabled and configured to match a SIP peer on the server.

11.3.1.3 Configure Ethereal

Once Ethereal is installed, launch it. Next, begin a capture by clicking the Capture menu and the Start menu item. This will show you the Ethereal: Capture Options dialog, as in Figure 11-3. In order to limit the kind of traffic that Ethereal will capture, you'll need to use a filter string. Ethereal has a rather sophisticated syntax for this string, which instructs Ethereal what to capture and what to ignore.

In this case, our SIP server is 10.1.1.10, and the standard port for SIP traffic is UDP 5060. We want to capture traffic in both directionsthat is, to the SIP server and to the softphone running on the same host as Ethereal. The string that achieves this is:

host 10.1.1.10 and udp port 5060

Check the "Update packets in real time" and "Automatic scrolling in live capture" options in order to see the packet capture log occur immediately rather than waiting

until the capture session is complete. Then, click OK and the main capture window will appear.

11.3.1.4 Observe SIP registration

Now, restart X-Lite. It will attempt to register automatically with the SIP server upon startup. By the time X-Lite says you're Logged In, you can stop the packet capture by clicking Ethereal's Capture menu and Stop menu item. The main capture window should be filled up with a number of packets, as in Figure 11-4.

In this instance, Ethereal shows the first packet, packet number 1, as a SIP REGISTER method. Newer versions of Ethereal, such as the 0.10.7 used here, can parse SIP packets and tell you which methods and responses they contain. Packet 4 is a second registration request (the first one failed because X-Lite tries anonymous registration first).

Packet 5 is the 100 Trying SIP response sent from the SIP server back to the softphone. Packet 6 is the 200 OK SIP response sent from the SIP server back to the softphone, indicating the registration was successful. Packet 7 is a SIP NOTIFY method asking for username 204 at the SIP registrar. Packet 8 is the 200 OK response. At this point, registration is complete. The additional packets (9 and 10) are keep- alive packets that X-Lite sends to its SIP registrar. Not all SIP phones do this.

The bottom pane of the main capture window shows the actual hex-encoded content of the packet and the ASCII-encoded content of the packet that corresponds to

it. The hex is on the left, and the ASCII on the right. This is where you can usually pick out problems: an incorrect password or a botched username would be easy to spot this way.

11.3.1.5 Observe registration failure

Outside the test lab, you probably won't have occasion to capture SIP packets unless something is working incorrectly. But then, why else would you need a packet sniffer? Simulating a registration failure is very easy. Just alter the registration username of the SIP proxy profile in X-Lite to one that doesn't match a SIP peer on the SIP server. (Be sure that your softPBX requires SIP clients to use a username and password; Asterisk can be configured to allow anonymous registration!) Then, start the Ethereal capture with the filter string used earlier, restart X-Lite, and watch the registration crash and burn (see Figure 11-5).

Packets 1, 2, and 3 in Figure 11-5 are a result of the de facto anonymous registration attempt and can be ignored. Packet 4 is the SIP REGISTER method using the incorrect username. Packet 5 is the customary 100 Trying response. Then, packet 6 contains the 403 Forbidden response, which indicates service is unavailable for this username. (An incorrect password should result in a 401 Unauthorized.)

To spot the incorrect username, highlight packet 4 and scroll down the bottom pane until you see the SIP User header in the ASCII-encoded column of the packet contents on the right side.

Similar capture and analysis techniques can be used to troubleshoot access control and dial-plan configuration problems on the SIP server, or misconfigurations on SIP phones. If you're daring enough to decode ASN.1, you can even use this technique to troubleshoot H.323 signaling.

11.3.2. Project 11.2. Inspect SDP Capabilities Negotiation

11.3.2.1 What you need for this project:

• A SIP-compatible softPBX such as Asterisk

• A SIP phone such as X-Lite

• Ethereal software

• LAN

The Session Description Protocol is an essential part of SIP call signaling. Its elements are text tokens sent in SIP packets with the SDP content-type header. These tokens advertise the capabilities and requirements of each endpoint according to the parameters of the application, be it a telephone call, instant message, or something else.

During call setup, specifically during the SIP INVITE method, the SDP payload is sent from one endpoint to the other. A SIP 200 OK response indicates agreement with the SDP parameters, while a 4xx response indicates disagreement or incapability. If you need a refresher on SIP signaling, refer back to Chapter 7.

11.3.2.2 Inspect successful capabilities negotiation

Using Ethereal configured with the same filter string from Project 11.1, you can capture a successful capabilities negotiation. In its default configuration, Asterisk supports G.711 so that just about any IP phone, X-Lite included, can place calls to it. In this case, X-Lite will be used to call Asterisk extension 201, and the SDP exchange for this call will be captured.

If you don't have such an extension on your dial-plan, then you can call Asterisk's default autoattendant demo at extension 500 instead. (If you've removed this extension in your hacking of Asterisk, just run a make sample from your Asterisk source directory in order to get the default config back again.)

When you place the call on X-Lite, use Ethereal to capture the SIP packets and zero in on the SDP content carried in the INVITE methods and 200 OK responses. In Figure 11-6, you can see that the call setup was successful.

Packet 5 is the authenticated INVITE method. The user in this example is calling SIP user 201. Included in packet 5 is an SDP payload. Ethereal indicates this in its Protocol column in the top packets pane of the main capture window, shown in Figure 11-6. Packet 6 is the 100 Trying response. Packet 7 is the 200 OK response, which also includes an SDP payload. If there's a codec match in the media attributes list of the SIP INVITE and the 200 OK response (shown in the bottom pane), then all that's needed is a SIP ACK method sent by the caller to confirm agreement on the first matching attribute. That's what packet 8 is.

11.3.2.3 Inspect failed capabilities negotiation

If there were no capabilities match, call setup would fail. This scenario can be produced easily by temporarily crippling the capabilities of the Asterisk server. To make it impossible for the X-Lite softphone to negotiate an audio stream with the Asterisk server, you can disallow all codecs supported by X-Lite and permit only GSM codec, which X-Lite doesn't support. This snippet of /etc/asterisk/sip.conf does just that:

[general] port = 5060 ; Port to bind to (SIP is 5060) bindaddr = 0.0.0.0 ; Address to bind to (all addresses on machine) disallow=all #allow=ulaw #allow=alaw #allow=gsm

The G.711 and GSM codecs have been commented out. This will simulate a codec capabilities mismatch, so the SIP client won't be able to pass the SDP negotiation, and call setups will fail. (Don't forget to issue a reload command at the Asterisk command line.) Now, we can run the capture again while X-Lite tries to call extension 500, as before. Only this time, the call will fail because there's no suitable codec common to both the caller (X-Lite) and the receiver (Asterisk).

Packet 7 is shown in Figure 11-7. It's a SIP INVITE carrying SDP content that includes a list of a tokens.

These represent media attributes, or capabilities. Ethereal presents the SDP content in a parsed, hierarchical fashion. But the raw ASCII SDP payload of this SIP packet, which can be seen in X-Lite's diagnostic log, actually looks like this:

... Content-Type: application/sdp User-Agent: X-Lite release 1103m Content-Length: 290 v=0 o=203 146336832 146337009 IN IP4 10.1.1.201 s=X-Lite c=IN IP4 10.1.1.201 t=0 0 m=audio 8000 RTP/AVP 0 8 3 98 97 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15

The capabilities are listed with a reference number following the rtpmap keyword. 0 pcmu/8000 indicates that 0 is the reference number that RTCP will later use to refer to this G.711 m law at 8000 Hz capability. The other capabilities are advertised with other numbers. (These numbers are reserved like commonly used port numbers in TCP/IP, and they can be overridden.)

In Figure 11-8, you can see that the 200 OK response sent by the receiver to the sender has an SDP payload that presents no audio codecs at all in its media attributes. This is because they have been purposefully disabled, of course. Packet 10 is the customary SIP ACK method acknowledging receipt of the 200 OK and giving the go-ahead for RTP to begin. But without any matching SDP media attributes to establish the RTP media channel, the receiver selects attribute reference number 101 using SDP's M token. 101 means there's no valid capabilities match. RTCP will report to the calling endpoint a few seconds later that no media channel exists, and the receiver " hangs up" with a SIP BYE method in packet 12.

Call-signaling issues can be frustrating, especially when using a mixed bag of SIP products from different vendors and vintages. Just as you can reveal SDP failures as in Project 11.2 and authentication problems as in Project 11.1, packet capture is the best tool for exposing any and all signaling problems.