Hack73.Inspect the SIP Message Structure
Hack 73. Inspect the SIP Message Structure
SIP is the predominant signaling standard among VoIP carriers and VoIP enabled PBX systems, so it might be a good idea to know something about it, beyond what the acronym stands for. SIP is a conversational, connectionless signaling protocol. In English, that means that SIP uses a two-way data conversation, generally using a UDP socket. Its message structure is similar to that of Simple Mail Transfer Protocol (SMTP) or HTTP messages, which also contain headers and a payload. SIP serves many purposes in a telephony environment, including setting up and tearing down VoIP phone calls. Poking around the VoIP network with Perl is a great way to learn about SIP's message structure. Besides monitoring the availability of hosts, you can use the script from "Monitor VoIP Devices" [Hack #72] as an investigation tool for understanding how the SIP protocol works. Using the -v switch, you can see the full output of a SIP interaction: # ./sip_ping.pl v 192.168.0.123 The preceding command sends the following SIP message to the specified host: OPTIONS sip:192.168.0.123 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:6655;branch=z9hG4bK1116720069 From: <sip:ping@127.0.0.1> To: <sip:192.168.0.123> Contact: <sip:ping@127.0.0.1> Call-ID: 0436a2258bedd74d8618e587446810c9@127.0.0.1 CSeq: 102 OPTIONS User-Agent: sip_ping.pl Date: Sat, 21 May 2005 05:01:09 PDT Allow: ACK Content-Length: 0 The response from the remote host is as follows: SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.0.1:6655;branch=z9hG4bK1116720069;received=192.168.0.52 From: <sip:ping@127.0.0.1> To: <sip:192.168.0.123> Call-ID: 0436a2258bedd74d8618e587446810c9@127.0.0.1 CSeq: 102 OPTIONS Contact: <sip:102@192.168.0.123:5060;line=j522azny> User-Agent: snom200-3.56m Accept-Language: en Accept: application/sdp Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO Allow-Events: talk, hold, refer Supported: timer, 100rel, replaces Content-Length: 0 Notice the plain-text structure of a SIP message packet. Both the request and the response contain very human-readable headers. This is no accident. The body responsible for SIP, the IETF, has a history of advocating human-readable protocols. As a result, SIP avoids machine-friendly ASN.1 encodings such as those used by SIP's predecessors. The response captured here is from a Snom 200 SIP hardphone. The User-Agent field indicates that it's running version 3.56m of Snom's firmware. Note the Allow, Allow-Events, and Supported headers showing all of the different SIP functionality that this host supports. This is the intended purpose of the OPTIONS request in SIP: to determine the functionality of a remote SIP service. OPTIONS is just one of several methods (by the way, methods is SIP's word for requests) that SIP implements. The INVITE method is used to establish calls, and the SUBSCRIBE method is used with presence capabilities like user availability and location. These methods are akin to GET and POST in HTTP. And like HTTP, the host receiving the methods has a variety of numeric responses. In this case, 200 represents that the method was successful, and the response message contains the desired information. Like HTTP, the response for "resource not found" is 404. So, if a SIP INVITE was sent for a user that didn't exist on a particular SIP device, the response would be a 404. If you point this script at other SIP hosts, you'll see a large variety of responses due to the variation in behavior of different SIP implementations on the Internet and due to the variations in available functionality from one SIP host to the next. A SIP video-conferencing device might not support the same methods (as listed on the Allow line) as a SIP phone, for example. 6.3.1. See Also
Brian Degenhardt |
EAN: 2147483647
Pages: 156