Overview of SIP
Session Initiation Protocol (SIP) forms the backbone of modern real-time communication networks. Over the years, SIP has been enhanced a great deal to include several use cases that make it a very robust multipurpose communication protocol. The following sections provide a brief overview of SIP.
Brief Introduction to and History of SIP
The SIP communications protocol is used for session setup, modification, and teardown. It is an application layer protocol that incorporates many elements of Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP). SIP is modular in design and can work in concert with many other protocols that are required to set up and support communication sessions, including the following:
■ Real-Time Transport Protocol (RTP)
■ Session Description Protocol (SDP)
■ Resource Reservation Protocol (RSVP)
SIP was originally designed by Mark Handley, Henning Schulzrinne, Eve Schooler, and Jonathan Rosenberg in 1996, and it was standardized in 1999 as RFC 2543. The version of SIP standardized in RFC 2543 was 1.0. At the time of this writing, the current SIP version is 2.0, standardized as RFC 3261.
SIP Operation
SIP works on the request/response framework and mirrors a model similar to HTTP, where there is a client/server exchange. A node that generates the request is called a user agent client (UAC), and a node that processes the request and sends out at least one response is called a user agent server (UAS). The concepts of a SIP transaction and a SIP dialog characterize the interaction between the UACs and UASs. A SIP transaction consists of a single request and all responses to that request, which may include zero or more provisional responses (1XX) and one or more final responses (2XX, 3XX, 4XX, 5XX, 6XX). A SIP dialog is a peer-to-peer relationship between user agents that exists for some time.
A single SIP dialog can include multiple SIP transactions. A transaction consists of a single request and the response(s) to that request. Figure 2-1 shows a few of these messages and an example of the SIP dialog with multiple transactions. The first transaction in this figure, known as the INVITE transaction, forms the SIP three-way handshake observed in many SIP dialogs.
)
The following events occur in Transaction 1 in this example:
The UAC sends an INVITE message to the UAS in an attempt to establish a session.
The UAS sends a 200 OK response, which accepts the INVITE message for the session.
The UAC needs to acknowledge the 200 OK message for the INVITE transaction, which is done via an ACK request message. (Note that this message is only observed during the INVITE transaction.)
At this point, the session is established, and it continues until one participant decides to end the session. When that occurs, a second transaction is created, consisting of the following events:
Session teardown occurs, with a BYE message sent by one participant (in this case, the originating UAC).
The UAS accepts the BYE for session teardown and replies by sending a 200 OK.
SIP commonly uses TCP or UDP as the transport protocol. For devices such as call agents, voice gateways, SIP proxies, and session border controllers (SBCs) that typically handle several SIP sessions simultaneously, the transport layer protocol is usually UDP. Establishing and maintaining a connection involves significantly more overhead with TCP than with UDP. However, when SIP sessions need to traverse communication links that are prone to errors, such as packet drops, it is better to use TCP as the transport layer protocol. Port number 5060 is typically used for SIP over UDP or TCP.
SIP messages exchanged between UACs and UASs carry a lot of information that could be misused if it fell into the hands of an attacker. For example, a SIP INVITE carries information that could reveal details of the network topology, the nature of the device originating or servicing the request, and details of the media stream(s), such as the IP addresses and port numbers. This is especially problematic when communication sessions span open networks. To prevent such attacks, it is possible to secure SIP signaling by using Transport Layer Security (TLS). The port number used for SIP over TLS is 5061.
Resources on a SIP network are identified by a uniform resource identifier (URI), which takes the following generic format:
sip:username:password@host:port
If the port is not specified, it defaults to 5060. For secure SIP transmission over TLS, an s may be added to the end of sip to make it sips:
sips:username:password@host:port
Note that the sips URI is not required when using TLS, and many implementations use SIP over TLS with the sip URI. As with a non-secure sip URI, if the port is not specified, a default port is used. In this case, however, the default port is 5061 instead of 5060.
SIP devices are referred to as user agents and can be devices such as IP phones, call servers, fax servers, gateways, and SBCs. The originator of a SIP request is called a UAC, and a device that processes the request is called a UAS. SIP includes several functional components, and interactions between user agents in real-world scenarios are in most cases more complex than generic client/server transactions. In order to understand the core tenets of SIP operation, you need to understand the following functional components of SIP:
■ SIP proxy: A SIP proxy is a device that is capable of performing call routing, authentication, authorization, address resolution, loop detection, and load balancing. A SIP proxy can be stateless or stateful; the fundamental difference between the two is whether they are aware of SIP transactions. A SIP transaction consists of a single request and all responses to that request, which may include zero or more provisional responses (1XX) and one or more final responses.
A stateful proxy becomes aware of the state of a SIP transaction by creating a server transaction, a client transaction, and a response context. By being transaction aware, the proxy is capable of forking requests, retransmitting requests, and generating messages by itself. For example, a stateful SIP proxy can generate a SIP CANCEL message to all entities still processing a forked request after a final response has already been received.
Stateless proxies, on the other hand, do not maintain transaction state; they transparently forward requests from the client to the server, and they send responses in the reverse direction. Once a request or a response is forwarded to the intended recipient, all details or transaction context of the message is purged. Consequently, stateless proxies cannot fork requests, retransmit requests, or generate messages on their own.
Proxies do not manipulate SIP message headers such as To, From, Call-ID, and so on. They do, however, include a Via header and a Record-Route header, and they decrement the Max-Forwards header value by one.
■ Redirect server: A redirect server is a server that provides location services to user agents or proxies by replying to requests with the location or route to the host that ultimately services the request. This is desirable in situations where there is a need to build highly scalable servers that do not participate in a SIP transaction but simply help the proxy or user agent reach the host by sending a single message. Redirect servers reply to requests with a 3XX response in which the Contact header contains the URI of the location to the host.
■ Registrar server: A registrar server is a server that accepts registration requests from user agents and creates a mapping between their address of record (AOR)—the public identifier of the user agent—and the user agent’s location. Subsequently, this mapping between the user agent AOR and location is indexed and stored in a location server. Cisco Unified Communications Manager (Unified CM) and Cisco Unified Communications Manager Express (Cisco Unified CME) act as registrar servers for Cisco IP phones and other enterprise endpoints. Similarly, Cisco Unified Border Element (CUBE) may be required to register with a service provider. While Unified CM is not covered as a registrar server in this book, the topic of configuring Cisco Unified CME as a registrar server for SIP endpoints is covered in Chapter 10, “Unified CME and SRST.” Registrar server interactions for a SIP trunk solution with CUBE are covered in Chapter 9, “CUBE Interworking Features.”
■ Location server: A location server contains a mapping between a user agent’s AOR and location; it does not need to be by a separate physical server and can be physically and logically colocated with the registrar server.
■ B2BUA: Back-to-back user agents (B2BUAs) are devices that have both UAC and UAS functionality and are capable of forwarding requests and processing them. SBCs, such as CUBE, are examples of B2BUAs. Unified CM may also act as a B2BUA. SIP trunking with Unified CM is covered in Chapter 5, “Unified CM SIP Trunk Configuration,” and B2BUA operations with CUBE are covered in Chapter 9.
SIP Methods
SIP messages are transmitted in plaintext. SIP messages can be requests or responses to requests. Table 2-2 lists SIP requests and describes the purpose of each one.
Table 2-2 SIP Requests
SIP Request |
Description |
|---|---|
INVITE |
A caller sends out this message to request another entity to establish a SIP session. |
ACK |
This indicates that the client has received a final response to an INVITE request. |
OPTIONS |
This request queries the server for its capabilities. |
BYE |
This is used by the UAC to indicate to the server that it wishes to terminate the established SIP session. (Note that this request can be issued by the caller or the callee.) |
CANCEL |
This is used to cancel a pending request and can be sent only if the server has not replied with a final response. |
REGISTER |
A client uses this message to register the address listed in the To header field with a SIP registrar server. |
PRACK |
This provisional acknowledgment is used to ensure that provisional responses are received reliably. (For more details on this message, see Chapter 9.) |
SUBSCRIBE |
This creates a subscription for important event notification. (For more details about this message, see Chapter 3, “VoIP Protocols: RTP, RTCP, and DTMF Relay.”) |
NOTIFY |
This notifies the subscriber of the occurrence of an event. (For more details about this method, see Chapter 3.) |
INFO |
This allows the exchange of application-level information among communicating entities. Information is exchanged without affecting the state of the SIP transaction or dialog. |
PUBLISH |
This publishes an event to the server. |
REFER |
This instructs the recipient to contact another entity, using the information specified in this request. (For more details about this message, see Chapter 9.) |
UPDATE |
This modifies the state of the session without changing the state of the dialog. (For more details about this message, see Chapter 9.) |
MESSAGE |
This transports instant messages using SIP. |
Every SIP transaction begins with a request from a UAC to a UAS. The UAS begins processing the request as soon as it is received. The result of this processing depends on the nature of the request, the formatting of the request, the state of the server at the time the request was being serviced, and the general configuration and policies local to the server. In the case of devices such as SIP proxies, B2BUAs, and voice gateways, the result of processing a request could depend on downstream devices.
SIP servers are always required to respond with the results of request processing. SIP responses use the following formatting convention:
■ The SIP version number (2.0 is the current SIP version number)
■ A three-digit status code (for example, 404)
■ A textual description (for example, Not Found)
The three-digit status code is an integer that communicates the outcome of request processing and is used for machine interpretation. The textual description, on the other hand, is for human observers and is useful in call failure debugging and call record interpretation. The first digit of the status code indicates the SIP response class; there are six classes in all (see Table 2-3).
Table 2-3 SIP Response Classes
Class of Response |
Meaning |
Type of Response |
|---|---|---|
1XX |
Informational: The request has been received and is being processed. |
Provisional |
2XX |
Success: The request has been received, understood, and accepted. |
Final |
3XX |
Redirection: Further action needs to be taken to complete the request. For example, the UAC needs to contact another server to process the request. |
Final |
4XX |
Client error: The request contains bad syntax (such as malformed headers) or could not be fulfilled at the server (for example, if the server could not find the number referenced in the requested URI). |
Final |
5XX |
Server error: A server failed to fulfill a valid request. |
Final |
6XX |
Global failure: The request could not be fulfilled at any server. |
Final |
Breaking Down a SIP Call
Before diving into the details of how a communication session over SIP is established, it is important to get a sense of how the initiator of a request—the UAC—forms the request and how the UAS ultimately processes the request. The following subsections take a detailed look at how SIP requests and responses are created.
Forming a Request
Standards-based SIP requires that a request contain at least the following header fields:
■ Request-URI
■ Via
■ From
■ To
■ Call-ID
■ Max-Forwards
■ CSeq
Subsequent sections discuss these header fields in more detail, and subsequent chapters introduce several other header fields used for specific applications. The header fields that appear in a request can vary depending on the type of request (refer to Table 2-4). For example, a SIP INVITE request would require additional header fields in comparison to a SIP REGISTER request.
Example 2-1 illustrates all of the items discussed in this section. This example shows a SIP INVITE sourced from a Cisco 8865 SIP IP phone acting as a UAC. This INVITE is sent to Unified CM as the UAS for the call. Here you can see the mandatory SIP header fields, such Request-URI, along with Via, From, To, Call-ID, Max-Forwards, and CSeq. This example also shows the required SIP INVITE fields, such as Contact, Allow, Supported, and Accept. Finally, it shows the optional headers, such as User-Agent, Session-ID, Expires, and Remote-Party-ID. These headers and their usage are covered after Example 2-1.
Example 2-1 Sample SIP INVITE from a Cisco 8865 SIP IP Phone
Several mandatory SIP headers appear in all requests:
■ Request-URI: In general, each resource within a SIP network is identified by a URI, which is expressed either as a SIP URI or a SIPS URI (SIP Secure URI). Specifically, within the scope of a SIP request, the Request URI header identifies the resource that processes the request.
■ Via: This header field indicates the transport layer protocol used for exchanging SIP messages and the location to which responses must be sent. For example, the following Via header field specifies UDP as the transport layer protocol and 10.1.1.1:5060 as the address/port pair for responses:
Via: SIP/2.0/UDP 10.1.1.1:5060;branch=z9hG4bK2D1F9D1C08
Also included in the Via header field is the branch parameter, which serves as an identifier for the SIP transaction created by any request and remains the same from the perspective of the UAC and the UAS. The branch parameter, which is unique across space and time, is valid until the termination of a SIP transaction. Subsequent requests that create new transactions must ensure that they generate new and unique values for this parameter. When a SIP proxy handles a request, such as a SIP INVITE, it inserts a Via header field before forwarding the request to the next hop. The next hop could be another proxy server or the final destination that processes the request. A request traversing proxies has more than one Via header field value.
■ From: This header field indicates the logical identity of the user agent that initiates the request. The From header field carries the identity of the initiator of the request in the form of a URI. Optionally, this header field can also include the display name of the initiator. For media sessions established over SIP, the display name in the From header field serves as a caller ID assertion. Intermediary devices such as SBCs usually transform the contents of the From header field. This might be required for a myriad of reasons, such as to enable interoperability across different SIP networks, provide topology abstraction, or make identity assertions. The From header field must carry a tag parameter. (The significance of the tag parameter is explained shortly.)
■ To: This header field usually identifies the logical entity that is supposed to process the request and is populated using a sip URI/SIPS URI or a tel URI. The logical entity identified in the To header field may or may not be the actual UAS that processes the request. In fact, the entity identified in the To header field usually isn’t the one to process the request when the request traverses several hops. Dialog-creating requests (such as SIP INVITE) must never carry a tag parameter in the To header field. Instead, the tag parameter is populated by the user agent that processes the request.
■ Call-ID: This header field uniquely identifies all messages that belong to a SIP dialog; the SIP dialog in turn is uniquely identified by the combination of the Call-ID header, the From tag, and the To tag. A SIP dialog may contain several SIP transactions. The Call-ID header field value is created by the UAC and retained in messages sent by the UAS. The Call-ID must be unique. User agents must ensure that this header field is generated in such a way to ensure that there isn’t any overlap with the Call-ID field of another SIP dialog. The Call-ID header field can sometimes carry the IP addressing information or domain name details of the initiating user agent, which might be undesirable in terms of topology abstraction. SBCs overcome this problem by overwriting the Call-ID header field value and preventing any internal network topology information from crossing network boundaries.
■ Max-Forwards: This header field value limits the number of hops a request can traverse before it reaches its final destination. Every node that receives a request either partially or completely processes a SIP request. Partial processing could include running syntactical checks, adding header fields, or occasionally modifying a request before it is passed on to the next hop. Complete processing of the request, on the other hand, involves sending one or more of the six response classes listed in Table 2-3 after processing the request. Every node that partially processes the request decrements the Max-Forwards header field value by one before sending the request to the next hop. If a request is received at a user agent or a proxy that is not the final destination of the request, an explicit check is run on the value of the Max-Forwards header field. If it is 0, the request is rejected with a 483 Too Many Hops response. If it is a nonzero value, it is forwarded to the next hop.
■ CSeq: This header field is used to order transactions within a dialog. It is formatted as follows:
CSeq: <Sequence-Number> <Method>
where <Method> is a SIP request (refer to Table 2-2).
The header fields listed here are required for every type of SIP request. However, additional header fields might also be required, depending on the type of the SIP method (request). For example, a SIP INVITE requires additional header fields accompanying the mandatory header fields to be efficiently processed by the UAS. For SIP INVITE, the following additional header fields are required:
■ Contact: This header field provides a SIP or SIPS URI at which the user agent can be contacted for subsequent requests. For example, consider an audio call that is already established between a UAC and a UAS. Due to negotiated session policy or application interactions, the UAS might need to send a midsession request to the UAC. To do so, it uses the SIP or SIPS URI indicated in the Contact header field. Note that the usage of the Contact header field is not restricted to INVITE requests only. This header field is also present in responses to the SIP INVITE and other SIP methods, when applicable.
■ Allow: It is recommended that the Allow header field be present within a SIP INVITE. This header field advertises the different SIP methods that can be invoked on the UAC within the scope of the dialog initiated by the SIP INVITE request. Parsing the Allow header field allows a UAS to understand the types of requests that can be sent to the UAC during the SIP dialog. For example, if the UAS wants to transmit dual-tone multifrequency (DTMF) information using the SIP INFO message, it can do so only if the UAC-advertised support for the SIP INFO message is in the Allow header field of the INVITE. The following is an example of the Allow header field:
Allow:INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE, NOTIFY,PRACK,UPDATE,OPTIONS
Although it is recommended for UACs to include the Allow header field in INVITE requests, there might be instances when this header field isn’t included. In such cases, the UAS must not assume that the UAC does not support any method; rather, it must be interpreted as the unwillingness of the UAC to advertise what methods it supports. The UAS can go ahead and send requests that are required to further advance the communication session; however, if the method is unsupported by the UAC, these requests are rejected by using the 405 Method Not Allowed response.
■ Supported: A UAC might use this header field to enumerate the various extensions to baseline SIP that it supports. A UAS might apply these extensions to baseline SIP when responding to the request. For example, if the UAC includes the timer extension in the Supported header field, it advertises support for SIP session refresh. The UAS might apply this extension to ensure session liveliness, as per the guidelines of RFC 4028. Session timers and session refresh operations are covered in Chapter 9.
■ Accept: The UAC might include the Accept header field to indicate content types that are acceptable to it in responses to requests or in new requests within the dialog. This header field allows user agents to advertise support for various session description formats.
Although some of the header fields listed here are optional, they are nonetheless universally supported across device types and vendors for initiating communication sessions over SIP. The following header fields might be added in SIP INVITE requests (although their exclusion does not deter the SIP session from proceeding smoothly):
■ Require: When included in the SIP INVITE, this header field enumerates extensions to baseline SIP using option tags. Each option tag represents a SIP extension that the server must support in order to process the request. If the server cannot support a specific extension, the request is rejected with a 420 Bad Extension response.
■ Expires: This header field might be added by a UAC to limit the validity of an invitation. Once a communication session is established, this header field value has no bearing on the amount of time for which the session can last. The usage of the Expires header field is method dependent. (As described in Chapters 9 and 10, this header field has a different purpose for the SIP REGISTER method.)
■ Diversion: This header field is used when a call is diverted from the original called endpoint to another endpoint. You will observe a Diversion header when a call is forwarded in Unified CM by either the Call Forward No Answer, Call Forward Busy, or Call Forward All setting for a line. This header is covered in both Chapters 5 and 8, “CUBE Call Routing and Digit Manipulation.”
■ Remote-Party-ID (RPID): This header field is primarily used for caller identification. The data from this header field often supersedes caller identification information in other headers, such as the Contact header or From header, and Cisco IP phones use this information to display caller ID information, if present. Another header field that effectively achieves the same thing is the P-Asserted-Identity (PAI) field. For more information about how to configure Unified CM to add these header fields, see Chapter 5.
Table 2-4 summarizes the mandatory, method-dependent, and optional headers for a SIP INVITE message. As mentioned previously, different SIP methods have different method-dependent and optional headers.
Table 2-4 Classification of Headers in SIP INVITE Messages
Header Fields |
Requirement |
|---|---|
Request-URI, Via, From, To, Call-ID, Max-Forwards, CSeq |
Mandatory for all SIP messages |
Contact, Allow, Supported, Accept |
Required for INVITE messages and optional for other methods |
Require, Expires, Diversion, Remote-Party-ID, P-Asserted-Identity |
Optional for SIP INVITE messages |
It is also possible for vendors to include proprietary header fields in SIP INVITE requests. If such a request happens to be processed by a device from the same vendor, any proprietary header field is interpreted to enable additional functionality. For example, Cisco devices such as Unified CM, voice gateways, and CUBE use the Call-Info header field in SIP INVITE messages (and corresponding responses) to advertise support for Cisco’s proprietary method of DTMF relay or SIP unsolicited notify. (For more on this, see Chapter 3.) If a nonmandatory proprietary header cannot be understood by a UAS, it is dropped, and processing of the request continues according to RFC 3261.
Forming a Response
On receiving a SIP request, a UAS performs a sequence of checks to determine how to respond to the request. Figure 2-2 illustrates the logic executed on the server to process a request.
)
The first check executed at the UAS involves whether the SIP method is supported. SIP methods are nothing but requests that require a specific action to be executed at the server. The SIP requests listed in Table 2-2 are all examples of SIP methods. All SIP user agents that initiate and support calls support the SIP INVITE method; however, it is possible for a UAS to not extend support to all the methods listed in Table 2-2. If a UAS does not support a given SIP method, it responds to the corresponding request with a 405 Method Not Allowed response.
After inspecting whether the method is supported, the SIP UAS proceeds to check various header fields in the request. The first header fields to be checked are the To and Request URI header fields. These header fields are checked for correct formatting and whether the UAS is indeed the node that is supposed to process the request. If either check fails, the request is rejected via the relevant 4XX class of responses.
The next check that is run is to verify whether the request has been looped—basically, whether the UAS has already processed exactly this request. Looping of requests is quite common in SIP networks, especially when nodes have improperly configured call routing. Call loops result in the UAS rejecting the request with a 482 Loop Detected response.
If a request is determined to be new, the UAS checks whether the client has requested special processing of the request by using the Require header field. This field specifies extensions to baseline SIP that facilitate specific application usage paradigms. These extensions are specified in the form of option tags in the Require header field. For example, the UAC might include the 100rel option tag in an INVITE request to ensure that the server sends provisional responses (101 to 199 responses) reliably. If a UAS does not support an option tag specified by the client, it rejects the request with a 420 Bad Extension response. (For more details on the 100rel option tag, see Chapter 9.)
After the UAS verifies that it supports the extensions required by the client, the next check performed is to determine whether it understands the message body within the request. A request can carry a message body (typically utilizing SDP) that provides additional details about the request. If the UAS cannot interpret a message body within a request, it is rejected.
Finally, in certain cases, a UAS might require the client to support certain extensions to baseline SIP for the request to be successfully processed. For example, if the server requires that provisional responses be sent reliably when a SIP session is being set up, and the UAC does not include the 100rel option tag in the Supported header field, it can reject an INVITE request with a 421 Extension Required response. A UAS should not use the 421 Extension Required response unless it truly cannot process the request using the constructs of baseline SIP.
Once all the checks are executed at the UAS, further processing of the request is strictly method dependent. For example, the same set of rules cannot be used to process an INVITE request and a REGISTER request. While processing a SIP INVITE, the following logic is applied:
■ If the INVITE contains an Expires header field, the UAS must send a final response before the expiration interval. If it fails to do so, the request is rejected with a 487 Request Terminated response.
■ The received INVITE might be a mid-dialog request (a Re-INVITE). Unless the server undergoes an unexpected restart, it maintains state information for all established dialogs. Mid-dialog requests are usually sent to modify session characteristics or ensure session freshness. For such requests, the processing rules of Section 12.2.2 of RFC 3261 are followed.
■ A mid-dialog INVITE request received at the UAS might not match an existing dialog. This could be because of an unexpected server restart, where all dialog contexts are purged, or it might be a result of incorrect request routing by downstream devices. Whatever the underlying cause, the guidelines of Section 12.2.2 of RFC 3261 are followed to handle such a situation.
If the SIP INVITE is not a mid-dialog request but rather is a dialog-creating request, the UAS is being invited to a communication session. When processing such a request, the UAS can either indicate progress, failure, or success of the request. Alternatively, the request could be redirected:
■ Progress: If the UAS cannot immediately send a final response to the SIP INVITE message, it can indicate some kind of progress to the request by sending a provisional response between 101 and 199. Commonly used progress indications include the SIP 180 Ringing and 183 Session Progress provisional responses. Provisional responses are classified as early dialog responses and require the UAS to populate the tag parameter of the To header field in the response. A provisional response is usually followed by a 200 OK final response or, in rare cases, a failure response.
■ Failure: If the UAS is unable to accept the session invitation, a failure response is sent to the client. Processing of the request at the server may fail for a number of reasons. The server could be overloaded, in which case it sends a 503 Service Unavailable response, or it might be that the server could not locate the device specified in the Request URI, in which case it responds with a 404 Not Found response. Whatever the reason, the server responds to the request with an error code that reflects the outcome of processing. The failure response might occasionally carry supplementary information to provide more granular details of the failure and to allow the client to augment the request, if applicable.
As an example, if the server sends a 503 Service Unavailable response, it can also choose to include a Retry-After header field that provides the client a time after which the request may be retried. If the overloaded condition at the server clears after the specified time interval, the server might respond with a success response.
■ Success: The session invitation being accepted at the UAS generates a 200 OK response. It is recommended that the 200 response include the Allow, Supported, and Accept header fields. Inclusion of these header fields ensures that the server can advertise any extensions to baseline SIP that it supports without having to be explicitly probed, perhaps via a SIP OPTIONS message.
Even if the SIP INVITE did not carry a SDP body, the server must include an SDP offer in the 200 OK response. If the INVITE carried an SDP offer, the UAS must include an SDP answer in the 200 OK response.
200 OK responses to the SIP INVITE must be followed by a SIP ACK method. This ensures that the 200 OK response was delivered reliably.
■ Redirect: A UAS can respond to INVITE requests with a redirect response (3XX). On receiving a redirect response, the client is required to execute an additional set of actions to complete the request. This usually entails the client parsing the Contact header field of the redirect response and sending the INVITE message to one or more URIs included in the Contact header field.
When multimedia communication networks peer over SIP, more often than not, 3XX redirect responses are viewed as attempts at toll fraud attacks. Consequently, on receiving a 3XX response, a user agent may terminate the request completely instead of try to further process the request.
Continuing with the transaction started in Example 2-1, Example 2-2 shows the subsequent 200 OK response to that INVITE message. Many of the same header fields observed in the original INVITE are present in this message. The To and From header fields remain unchanged except for a tag that is postfixed on the To header field. This tag is used to identify the specific UAS in the SIP dialog. All future requests and responses between these two UAs should include this To header tag. The Remote-Party-ID and Contact headers will be updated to reflect the appropriate information of the called endpoint or UA handling the request on behalf of the remote endpoint. The Call-ID header will remain the same as seen in the INVITE message, and the CSeq header for this message will reference the same CSeq header of the INVITE request since this is a response to that specific request. The Allow header and Supported header are included to inform the UAC of the allowed request methods and the supported SIP extensions.
Example 2-2 200 OK Response from Unified CM to INVITE Sent by the IP Phone
Analyzing a Basic SIP Call
A SIP call begins when a UAC invites a UAS to a communication session. In real-world implementations, the two user agents might be separated over several hops. However, for the sake of simplicity, let’s assume that the two user agents communicate directly with one another.
When inviting another user agent to a communication session, the UAC might be preconfigured with the exact location of the UAS. If not, its request might be ferried by a SIP proxy server to the intended UAS. When the request is received at the UAS, the UAS allocates the necessary resources to process the request. As the request is being processed, the UAS might be required to send provisional responses. It must send a final response once the request is fully processed to alert the UAC of the outcome.
Based on the results of request processing, the server responds with any one of the six classes of response codes listed in Table 2-3. Depending on the request, the UAS may respond with a provisional response class (1XX) followed by a final response class, or it may respond directly with a final response class. For example, when processing a SIP INVITE, the UAS typically sends a 100 Trying provisional response, followed by a final response. The provisional 100 Trying response alerts the UAC that the request is currently being processed, and a final response is expected shortly. It also serves as a mechanism to deter the UAC from sending subsequent copies of the same SIP INVITE.
Figure 2-3 demonstrates a SIP message exchange for establishing an audio call between Phone A and Phone B. A call agent, like Cisco’s Unified Communication Manager (commonly known as Unified CM), is in the middle of the signaling for both phones and aids in the establishment of the communication session.
)
The SIP call in Figure 2-3 involves the following steps:
Step 1. Phone A initiates a communication session with Phone B by sending a SIP INVITE message to Unified CM. In this scenario, Unified CM functions as both the registrar server for the phones and their UAS for all outbound requests.
Step 2. Included in the SIP INVITE are several pieces of information that enable the transaction/dialog to progress smoothly. These pieces of information include several header field values in the SIP message. The SIP INVITE can be sent in one of two ways:
■ With an SDP body
■ Without an SDP body
If the SIP INVITE carries an SDP body, the call is classified as an “early offer” call. If an SDP body is not advertised in the SIP INVITE, the call is classified as a “delayed offer” call. As discussed shortly, SDP is used to encode the characteristics of a media session, such as the type of media stream(s) supported (for example, audio, video), the IP addresses and port numbers for the media stream(s), and the set of supported codecs for different media stream types.
Sending an early offer INVITE allows the UAC to enforce characteristics of the session up front by including its supported media stream types, the relevant media formats per media stream, and any SDP-based extensions. With delayed offer INVITE messages, the UAC has to tailor its session characteristics in accordance with the SDP body advertised by the UAS. The example shown in Figure 2-3 illustrates an early offer call.
Step 3. On receiving the SIP INVITE message, Unified CM sends a 100 Trying response to Phone A. The 100 Trying response serves to inform Phone A that the INVITE has been received, and processing is under way. After sending the 100 Trying response, Unified CM examines the Request URI in the received INVITE message and does a database lookup. The database lookup is done to determine the location information (IP address and port) of Phone B. The location information for Phone B is present in Unified CM because it also functions as a registrar server.
Step 4. On obtaining the location information of Phone B, Unified CM operates as a SIP B2BUA, and a SIP INVITE is sent from Unified CM to Phone B. Phone B sends a 100 Trying response to Unified CM.
Step 5. After the request is completely processed at Phone B and it begins ringing, a 180 Ringing message is sent to Unified CM. The 180 Ringing message is then relayed from Unified CM to Phone A. At this stage, an audible ringback tone must be generated at Phone A. The ringback tone might be generated locally on the phone or might be generated by Unified CM. Alternatively, if Phone B wants to stream a custom ringback tone or pre-connect announcement, it sends a 183 Session Progress message with an SDP body. This scenario, defined as “early media,” allows Phone A to listen to media packets encapsulating custom ringback tones or pre-connect announcements even before Phone B goes off-hook. For more information about early media and ringback, see Chapter 9.
Step 6. Once Phone B is taken off-hook, a 200 OK response is sent to Unified CM, indicating that the call has been answered. Included in the 200 OK is an SDP body indicating the chosen media stream(s) and media codecs. The 200 OK response is then sent to Phone A. At this stage, the phones can begin to exchange media packets with one another. The 200 OK response must be followed by a SIP ACK sent end-to-end to indicate that the 200 OK response was reliably received.
At this stage, the SIP dialog is considered complete. You should note that Unified CM is only responsible for setting up the communication session but for most scenarios does not place itself in the path of the media packets.
Step 7. The SIP call terminates when one of the phones transmits a SIP BYE message.