ferent SIP entities and what their message formats are. We'll also examine multi- ple examples of how SIP works. These examples will usually consist of message flow that gives a global picture of SIP operation. However, I have also included one example where the reader can see all the messages in detail, including message headers, parameters, and session descriptions. Although it is not the purpose of this book to analyze all the protocol details, it is instructive to see, at least once, what SIP messages look like. Client/Server Transactions SIP is based on the Web protocol Hypertext Transfer Protocol (HTTP) and like HTTP, SIP is a request/response protocol. To understand the request/response mechanism used in SIP, we'll have to examine the follow- ing definitions of client and server. A client is a SIP entity that generates requests. A server is a SIP entity that receives requests and returns responses. This terminology is inherited from HTTP, wherein a Web browser contains an HTTP client. When I type an address in my Web browser, such as http://www.accessmhtelecom.com, I am sending a request to a particular Web server. The Web server sends back a response with the information requested-namely, the Web page of McGraw-Hill's telecom publishing group. SIP conforms to the same procedures. Following the same terminology, when two user agents exchange SIP messages, the User Agent (UA) sending requests is the User Agent Client (UAC) and the UA returning responses is the User Agent Server (UAS). A SIP request, together with the responses it triggers, is referred to as a SIP transaction. SIP Responses Upon reception of a request, a server issues one or several responses. Every response has a code that indicates the status of the transaction. Status codes are integers ranging from 100 to 699 and are grouped into classes, as shown in Table 5-1. SIP: Protocol Operation Range Response Class Table 5-1 100-199 Informational SIP Response Classes. 200-299 Success 300-399 Redirection 400-499 Client error 500-599 Server error 60