Hack 82. Dig into SDP
No SIP-based telephone call happens without Session Description Protocol, and there's an SDP message inside every SIP Invite.
Knowing what SDP messages look like will help you identify the cause of failed calls that are rooted in incompatible phones. That's right; if the phones (or softphones) calling each other with SIP don't have (or aren't configured to use) the same media codecs, they won't be able to talk to each other! Of course, the phone isn't going to say, "Hey dude, I don't have the right codec!" It's more than likely just going to give you a busy signal. So you'll need to dig into SDP to find out if a mismatch of media capabilities is to blame.
SDP 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, and a 4xx response indicates disagreement or incapability. For a much deeper discussion on SIP, have a peek inside my book, Switching to VoIP (O'Reilly).
6.12.1. Inspect Successful Capabilities Negotiation
Using Ethereal configured with the same filter string from "Peek Inside of SIP Packets" [Hack #81], you can capture a successful capabilities negotiation. In its default configuration, Asterisk supports G.711 so that just about any IP phone, including X-Lite, 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, you can call Asterisk's default auto-attendant demo at extension 500 instead. (If you've removed this extension in your hacking of Asterisk, just run a make samples from your Asterisk source directory [Hack #41] 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 6-9, you can see that the call setup was successful.
Figure 6-9. Ethereal can parse SDP content so that it's easier for you to troubleshoot call setup problems
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 6-9. Packet 6 is the 100 TRying response. Packet 7 is the 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), 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.
6.12.2. Inspect Failed Capabilities Negotiation
If there was 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 Global System for Mobile (GSM) codecs, which X-Lite doesn't support. Take a look at this snippet of /etc/asterisk/sip.conf, which 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 simulates 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. (In Ethereal, select Capture Start.) Only this time, the call will fail because theres no suitable codec common to both the caller (X-Lite) and the receiver (Asterisk).
Packet 7 is shown in Figure 6-10. 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.
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
Figure 6-10. The bottom pane of the capture window shows the media attribute list: the SDP text payload that advertises the capabilities of the calling endpoint
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 uLaw at 8000Hz 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 6-11, 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 that 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.
Figure 6-11. The bottom pane of the capture window shows the media attribute list: SDP's listing that advertises the capabilities of the receiving endpoint, in this case Asterisk
Call-signaling issues can be frustrating, especially when using a mixed bag of SIP products from different vendors and vintages. Just like for revealing SDP failures and authentication problems, packet capture is the best tool for exposing any and all signaling problems.