In our two previous tutorials on the Session Initiation Protocol (SIP), supported by the Internet Engineering Task Force (IETF), we looked at the history and architecture of SIP and the functional capabilities of the protocol. Here we extend the discussion to consider the message formats that are used for SIP communication.
As a brief review, recall that SIP, which is defined in RFC 3261, is an application protocol designed to establish communication sessions. SIP takes many of its protocol and message constructs from two other IETF protocols, the Simple Mail Transfer Protocol (SMTP), which is defined in RFC 2821, and specifies the format for electronic mail messages, and the Hypertext Transfer Protocol (HTTP), which is defined in RFC 2616, and specifies the format for web-based multimedia communication.
Most readers should be familiar with HTTP, and the processes that are undertaken by a web client to access resources, such as a document on a web server. Given that SIP was designed with a similar client/server architecture, we would expect the SIP messages to also be similar to the request/response message model that is used with HTTP. Thus, the SIP request message defines the operation requested by the client, while the SIP response message provides information from the server to the client indicating the status of that request.
But since the resources for a SIP session are communication resources (not file or web page resources, as in the case of HTTP), an identification or addressing scheme for those resources must be defined before the request/response message set can be implemented effectively. That identifier is known as a SIP Uniform Resource Indicator (SIP URI), which contains sufficient information to initiate and maintain a communication session. Examples (from RFC 3261) of resources that might need such an identification would include: a user of an online service, a mailbox on a messaging system, a logical group of users within an organization (such as the sales department), or a telephone number for a Public Switched Telephone Network (PSTN) destination, that needs to be conveyed to a gateway service. The SIP URI is similar to an email address (this time borrowing from SMTP), and typically contains two parts: a username and a hostname, such as sip:firstname.lastname@example.org. Other SIP URI forms are possible, which will be explored in future tutorials.
With the addressing scheme thus understood, there are six types of request messages defined, distinguished by what is called a method:
- REGISTER: Is used by a client to register an address with a SIP server.
- INVITE: Indicates that the user or service is being invited to participate in a session. The body of this message would include a description of the session to which the callee is being invited.
- ACK: Confirms that the client has received a final response to an INVITE request, and is only used with INVITE requests.
- CANCEL: Is used to cancel a pending request.
- BYE: Is sent by a User Agent Client to indicate to the server that it wishes to terminate the call.
- OPTIONS: Is used to query a server about its capabilities.
Other methods may be defined in the future and documented in subsequently published RFCs.
The response messages contain Status Codes and Reason Phrases that indicate the current condition of this request. The status code values are divided into six general categories:
- 1xx: Provisional: The request has been received and processing is continuing.
- 2xx: Success: An ACK, to indicate that the action was successfully received, understood, and accepted.
- 3xx: Redirection: Further action is required to process this request.
- 4xx: Client Error: The request contains bad syntax and cannot be fulfilled at this server.
- 5xx: Server Error: The server failed to fulfill an apparently valid request.
- 6xx: Global Failure: The request cannot be fulfilled at any server.
As before, specific details on the SIP message formats, status codes, and other parameters are specified in RFC 3261.
Recall from our earlier tutorials that the SIP session may include voice, video and/or data information, and therefore a standard method of describing the session that is being initiated (using the INVITE message noted above) is required. This part of the puzzle is solved by the use of the Session Description Protocol (SDP), defined in RFC 2327, which will be the topic of our next tutorial.
Copyright Acknowledgement: © 2005 DigiNet ® Corporation, All Rights Reserved
Mark A. Miller, P.E. is President of DigiNet ® Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.