VoIP Protocols: SIP Messages
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)
<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)
An Example Message
Let's have a look at an actual SIP message:
INVITE sip:firstname.lastname@example.org SIP/2.0
Via: SIP/2.0/UDP 10.10.1.99:5060;branch=z9hG4bK343bf628;rport
From: "Test 15" <sip:email@example.com>tag=as58f4201b
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Wed, 06 Dec 2009 14:12:45 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
o=root 1821 1821 IN IP4 10.10.1.99
c=IN IP4 10.10.1.99
m=audio 11424 RTP/AVP 0 8 101
a=silenceSupp:off - - - -
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.
Let's describe the most important message headers in the example above.
The request start line: The string "INVITE sip:firstname.lastname@example.org SIP/2.0" tells that this is an invitation to a call. It also gives the SIP address of the receiving endpoint (sip:email@example.com) 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:firstname.lastname@example.org>;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 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).
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:
181 Call forwarded
183 Session Progress
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
380 Alternative Service
400 Bad Request
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
505 SIP Version Not Supported
600 Busy Everwhere
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
Comments on this piece, or the VoIP Overview as a whole, are welcome on Vladimir's blog.