VoIP Protocols: SIP Messages

Vladimír Toncar

SIP Message Format

As mentioned before, SIP is a text-based protocol. The formatting of SIP messages is based on the syntax of HTTP version 1.1. There are two types of messages: requests and responses.

The format of a request is as follows:

<request start line>
<request headers> (several lines)
<blank line>
<message body> (carries the Session Description Protocol message)

In the message, end of line is always denoted with the two octets <CR><LF>.

The format of the response is very similar to what we have just shown. The only difference is in the first line. The response format is as follows:

<response status line>
<request headers> (several lines)
<blank line>
<message body>

An Example Message

Let's have a look at an actual SIP message:

INVITE sip:13@10.10.1.13 SIP/2.0
Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK343bf628;rport
From: "Test 15" <sip:15@10.10.1.99>tag=as58f4201b
To: <sip:13@10.10.1.13>
Contact: <sip:15@10.10.1.99>
Call-ID: 326371826c80e17e6cf6c29861eb2933@10.10.1.99
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Wed, 06 Dec 2009 14:12:45 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 258

v=0
o=root 1821 1821 IN IP4 10.10.1.99
s=session
c=IN IP4 10.10.1.99
t=0 0
m=audio 11424 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

This example shows an INVITE message. This is the message that a SIP endpoint needs to send in order to establish a call. The message was sent by an Asterisk PBX running at the IP address 10.10.1.99. It starts a call from extension number 15 to extension number 13 at the IP address 10.10.1.13.

Message headers

Let's describe the most important message headers in the example above.

The request start line: The string "INVITE sip:13@10.10.1.13 SIP/2.0" tells that this is an invitation to a call. It also gives the SIP address of the receiving endpoint (sip:13@10.10.1.13) and identifies the version of the protocol (SIP/2.0).

Call-ID: This is a unique identifier of the given SIP session. It usually consists of a random string and the IP address of the sender.
CSeq: This is an ID that identifies the particular SIP transaction. As mentioned in the previous section, the same CSeq: is always shared by a request and its related response or responses. The CSeq: identifier is composed of a sequence number (incremented for each new request) and the name of the particular request.
From: This field ('From: "Test 15" <sip:15@10.10.1.99>;tag=as58f4201b' in our example message) contains the address of the caller with an optional display name and with optional tags. From: is a mandatory field in all SIP requests and responses. In SIP responses, From: is always a copy of the From: field in the related request message. Note that in our example, 10.10.1.99 is the IP address of the Asterisk PBX which plays the role of a SIP proxy. The actual caller (phone number 15) might be located elsewhere but the proxy will not show the actual IP address in message headers.
To: This field contains the address of the called party. To: is a mandatory field. The To: fields in responses are copied from the related request message.
Via: The Via: headers are used to record the route of the request. Each proxy server on the path of the message will add one Via: entry. Thanks to this, the replies can be routed back along the same path.
Content-type: This field describes the media type of the message body. The type is usually "application/sdp", denoting the Session Description Protocol (we will look at SDP later). The message body can be sometimes empty (e.g. the REGISTER message) and then the Content-type: header is not present.
Content-length: This is the length of the message body in octets. This header is always present but can be 0 (denoting there is no message body).

The message body carries a message of the Session Description Protocol. This message contains a description of the audio (and possibly video) channel that the calling endpoint wants to establish. We will look at the Session Description protocol later in a greater detail.

SIP Requests

SIP originally only had 6 requests (also called methods). These requests have been a part of the standard since SIP 1.0. Lets describe the individual methods:

INVITE — This is a request to establish a call (a session). We have seen an example of the message above.
CANCEL — This method is used to stop an INVITE that is in progress (that is, the call has not been established yet).
ACK — The ACK request is used to confirm that the endpoint has received a final response in a transaction. Typically, after the called party accepts a call, the caller confirms the receipt of the accepting response (200 OK) with the ACK method.
BYE — The BYE method is used to end an established call (compare with CANCEL that is used to stop the session before it has been established).
REGISTER — The REGISTER method is used to register the SIP endpoint at the registrar server. This method does in fact the same as the Registration Request (RRQ) in H.323.
OPTIONS — This request is used to ask the other party for the list of SIP methods it supports. The response may also contain the set of capabilities (i.e. audio/video codecs) of the responding party.

In addition to these six requests, several other SIP methods have been added, either in SIP 2.0 or in other individual RFCs. For example, the INFO method was defined in RFC2976. It can be used to carry application-level information that are relevant to the session, for example participant images or account balance information. The INFO method can also be used to carry DTMF digits.

The three methods SUBSCRIBE, NOTIFY, and MESSAGE extend SIP with instant messaging features. If you send the SUBSCRIBE method, you are asking the other party to send you notifications about status changes ("available", "busy", "away", etc.). The status change notifications are then sent in the NOTIFY messages. Last, the method MESSAGE is used to send instant messages. The text of the instant message is simply transported in the body of the method (Content-Type: is usually text/plain).

SIP Responses

Like many other IETF protocols, SIP uses 3-digit response codes. The responses fall into 6 categories.

Informational responses are mainly used to inform about the progress of a session (e.g. "180 Ringing"). There is only one response in the Success group and you will not be surprised that it is "200 OK". The Redirection group contains responses that a User Agent or a proxy server can use to redirect the caller to another destination. The last three groups of responses report about failures and the severity of the failure increases with each group, from Request Failure, to Server Failure, to Global Failure.

Let's list the most important responses:

Informational	Success
100 Trying 180 Ringing 181 Call forwarded 182 Queued 183 Session Progress	200 OK

Redirection	Request Failure
300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 380 Alternative Service	400 Bad Request 401 Unauthorised 403 Forbidden 404 Not Found 405 Method Not Allowed 415 Unsupported Media Type 420 Bad Extensions 486 Busy Here

Server Failure	Global Failure
500 Server Error 501 Not Implemented 503 Service Unavailable 504 Timeout 505 SIP Version Not Supported	600 Busy Everwhere 603 Decline 604 Doesn’t Exist 606 Not Acceptable

The meaning of the individual response codes is quite clear so we will not explain them in detail here. Examples of response messages and the usage of responses in a SIP call will be shown in the next section.

Next section: SIP Call Flow