SIP 101

The majority of techniques covered in this chapter, and in the rest of this book, assume a basic understanding of the Session Initiation Protocol (SIP ) (http://www.cs. columbia .edu/sip/). While it goes beyond the scope of this book to delve thoroughly into the complete workings of SIP, it will be helpful to review some of the basics.

Simply put, SIP allows two speaking parties to set up, modify, and terminate a phone call between the two of them. SIP is a text-based protocol and is most similar, at first glance, to the HTTP protocol. SIP messages are composed of specific requests and responses that are detailed here.

SIP URIs

A SIP Uniform Resource Indicator (URI) is how users are addressed in the SIP world (RFC 3261). The general format of a SIP URI is

 sip:user:password@host:port;uri-parameters?headers 

Some example SIP URIs taken directly from the RFC are

 sip:[e-mail]    sip:[e-mail]    sip:alice:[e-mail];transport=tcp    sip:[phone]:[e-mail];user=phone    sip:alice@192.0.2.4:5060    sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com    sip:alice;day=[e-mail] 

SIP Architecture Elements

There are five logical core components in SIP architecture. Many of the server functions detailed here are often consolidated into one or two server applications.

• User agents (UA)    Any client application or device that initiates a SIP connection, such as an IP phone, PC softphone, PC instant messaging client, or mobile device. The user agent can also be a gateway that interacts with the PSTN.

• Proxy server    A proxy server is a server that receives SIP requests from various user agents and routes them to the appropriate next hop. A typical call traverses at least two proxies before reaching the intended callee.

• Redirect server    Sometimes it is better to offload the processing load on proxy servers by introducing a redirect server. A redirect server directs incoming requests from other clients to contact an alternate set of URIs.

• Registrar server    A server that processes REGISTER requests. The registrar processes REGISTER requests from users and maps their SIP URI to their current location (IP address, username, port, and so on). For instance, sip:[e-mail] might be mapped to something like sip: dave@192.168.1.100:5060, which is the softphone from which I just registered.

• Location server    The location server is used by a redirect server or a proxy server to find the callee's possible location. This function is most often performed by the registrar server.

A typical SIP-based call flow is best represented by the illustration in the section, "Typical Call Flow," later in this chapter.

SIP Requests

SIP requests can be used in a standalone sense or in a dialog with other SIP requests and responses. The following is a brief overview of the most common requests used in call initiation and teardown :

SIP Request	Purpose	RFC Reference
INVITE	Initiates a conversation.	RFC 3261
BYE	Terminates an existing connection between two users in a session.	RFC 3261
OPTIONS	Determines the SIP messages and codecs that the UA or server understands.	RFC 3261
REGISTER	Registers a location from a SIP user.	RFC 3261
ACK	Acknowledges a response from an INVITE request.	RFC 3261
CANCEL	Cancels a pending INVITE request, but does not affect a completed request (for instance, stops the call setup if the phone is still ringing).	RFC 3261
REFER	Transfers calls and contacts external resources.	RFC 3515
SUBSCRIBE	Indicates the desire for future NOTIFY requests.	RFC 3265
NOTIFY	Provides information about a state change that is not related to a specific session. (For example, Windows Messenger uses a SUBSCRIBE method to get contacts, groups, and allow and block lists from the server. Microsoft Live Communications Server 2003 uses a NOTIFY to transfer this information.)	RFC 3265

SIP Responses

SIP responses (RFC 2543) are three-digit codes much like HTTP (for example, 200 OK, 404 Not Found, and so on). The first digit indicates the category of the response. The entire range of possible responses to a SIP request is as follows :

Response	Category	Codes
1 xx responses	Information responses	100 Trying 180 Ringing 181 Call Is Being Forwarded 182 Queued 183 Session Progress
2 xx responses	Successful responses	200 OK
3 xx responses	Redirection responses	300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 303 See Other 305 Use Proxy 380 Alternative Service
4 xx responses	Request failure responses	400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 409 Confl ict 410 Gone 411 Length Required 413 Request Entity Too Large 414 Request URI Too Large 415 Unsupported Media Type 420 Bad Extension 480 Temporarily Not Available 481 Call Leg/Transaction Does Not Exist 482 Loop Detected 483 Too Many Hops 484 Address Incomplete 485 Ambiguous 486 Busy Here
5 xx responses	Server failure responses	500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Time-out 505 SIP Version Not Supported
6 xx responses	Global failure responses	600 Busy Everywhere 603 Decline 604 Does Not Exist Anywhere 606 Not Acceptable

Typical Call Flow

Now to see the SIP requests and responses in action, let's look at a fairly standard call setup between two users. The actual example is shown using a Vonage softphone client as User agent A (7035551212) calling User agent B (5125551212).

The Vonage user sends an INVITE to User B to initiate a phone call. The Session Description Protocol (SDP RFC 2327) is used to describe all media codecs supported by the Vonage user.	INVITE sip:[e-mail] SIP/2.0 INVITE sip:[e-mail] SIP/2.012D61E45C460BA4624A77E6E51AA1 From: Vonage User sip:[e-mail]>;tag=3010128031 To: <sip:[e-mail]> Contact: <sip:17035551212@12.39.18.123:5060> Call-ID: 805C3881-E9F6-402E-BBD8-181A2B9C2AC6@12.39.18.123 CSeq: 10814 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-PRO Vonage release 1105x Content-Length: 244 v=0 o=17035551212 44428031 44428065 IN IP4 12.39.18.123 s=X-PRO Vonage c=IN IP4 12.39.18.123 t=0 0 m=audio 8000 RTP/AVP 0 18 101 a=rtpmap:0 pcmu/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv
User B receives the request (his phones rings).	SIP/2.0 100 Trying Via: SIP/2.0/UDP 12.39.18.123:5060;rport;branch=z9hG4bKA53 5C55954034DE8980460B33AC67DDD From: Vonage User <sip:[e-mail]. net>;tag=3010128031 To: <sip:[e-mail]> Call-ID: 805C3881-E9F6-402E-BBD8-181A2B9C2AC6@12.39.18.123 CSeq: 10815 INVITE Max-Forwards: 15 Content-Length: 0<F255D>
While User Bs phone is ringing, he sends updates (TRYING, SESSION PROGRESS, and so on).	SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 12.39.18.123:5060;rport;branch=z9hG4bKA53 5C55954034DE8980460B33AC67DDD From: Vonage User <sip:[e-mail]. net>;tag=3010128031 To: <sip:[e-mail]. net>;tag=gK0ea08a79 Call-ID: 805C3881-E9F6-402E-BBD8-181A2B9C2AC6@12.39.18.123 CSeq: 10815 INVITE Contact: <sip:15125551212@216.115.20.41:5061> Max-Forwards: 15 Content-Type: application/sdp Content-Length:<F255D> 238 v=0 o=Sonus_UAC 14354 30407 IN IP4 69.59.245.131 s=SIP Media Capabilities c=IN IP4 69.59.245.132 t=0 0 m=audio 21214 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=maxptime:20
User B picks up the phone and sends an OK response to the caller.	Via: SIP/2.0/UDP 12.39.18.123:5060;rport;branch=z9hG4bK493 C01C844624AAE8C1A8CE04A4237E3 From: Vonage User <sip:[e-mail]. net>;tag=1667903552 To: Vonage User <sip:[e-mail]> Call-ID: [e-mail]. vonage.net CSeq: 1410 REGISTER Contact: "Vonage User" <sip:17035551212@12.39.18.123:5060> ; expires =20 Content-Length: 0<F255D>
The Vonage user responds with an ACK acknowledgment.	ACK sip:15125551212@216.115.20.41:5061 SIP/2.0 Via: SIP/2.0/UDP 12.39.18.123:5060;rport;branch=z9hG4bK6B5 3C0C1ECFD4B7DB26C6CC5F224B292 From: Vonage User <sip:[e-mail]. net>;tag=3010128031 To: <sip:[e-mail]. net>;tag=1091505090 Contact: <sip:17035551212@12.39.18.123:5060> Call-ID: 805C3881-E9F6-402E-BBD8-181A2B9C2AC6@12.39.18.123 CSeq: 10815 ACK Max-Forwards: 70 Content-Length: 0<F255D>
The conversation is established directly between the two parties.	RTP packets are exchanged in both directions carrying the conversation.
User B hangs up and sends a BYE message.	BYE sip:17035551212@12.39.18.123:5060 SIP/2.0 Via: SIP/2.0/UDP 216.115.20.41:5061 Via: SIP/2.0/UDP 69.59.240.166;branch=z9hG4bK07e88f99 Via: SIP/2.0/UDP 69.59.240.166;branch=z9hG4bK07e88f99 net>;tag=1091505090 To: Vonage User <sip:[e-mail]. net>;tag=3010128031 Call-ID: 805C3881-E9F6-402E-BBD8-181A2B9C2AC6@12.39.18.123 CSeq: 10816 BYE Max-Forwards: 15 Content-Length: 0<F255D>
The Vonage user accepts the BYE message, and sends an OK as an acknowledgment.	SIP/2.0 200 OK Via: SIP/2.0/UDP 12.39.18.123:5060;rport;branch=z9hG4bKE31 C9EC9A1764679A417E3B5FBBF425A From: <sip:[e-mail]>;tag=2209518249 To: <sip:15125551212@206.132.91.13>;tag=448318763 Call-ID: E630553E-E44911DA-BC08C530-3979085C@206.132.91.13 CSeq: 10816 BYE Max-Forwards: 14 Content-Length: 0<F255D>

Further Reading

This brief summary of SIP is meant only as a refresher and companion to many of the SIP-based attacks discussed throughout the book. For a more thorough reference guide on SIP, we highly recommend reading SIP Beyond VoIP by Henry Sinnreich, Alan B. Johnson, and Robert J. Sparks (VON Publishing, 2005).