The New Kid on the Block: SIP

Session initiation protocol (SIP) recently threw its hat into the ring to be a contender for the gateway protocol of choice. SIP designers envision the promise of vendor interoperability, the flexibility of network designers to select VoIP products from different vendors and have those products communicate via SIP. Cisco recently introduced a CallManager feature (that is, a SIP trunk) that permits a CCM environment to communicate with an SIP environment.

SIP uses the concept of inviting participants into sessions, and those sessions can be advertised by the Session Announcement Protocol (SAP). Like H.323, SIP distributes call-forwarding intelligence in devices throughout the network. These devices are called user agents (UAs). Two types of UAs exist:

• User agent clients (UACs) initiate the connection by sending an INVITE message

• User agent servers (UASs) reply to INVITE messages

UAs include components such as IP phones. If the IP phone originates the call, the IP phone represents a UAC. However, when the IP phone receives a call, the IP phone acts as a UAS. Cisco provides SIP firmware, allowing an administrator to convert a Cisco 7960G IP Phone from a Skinny Client Control Protocol (SCCP) phone to an SIP phone.

A SIP network leverages various types of SIP servers:

• Proxy Server Performs forwarding for a UAC

• Registrar Server Registers the location of current clients

• Redirect Server Informs the UA of the next server to contact

• Location Server Performs address resolution for SIP proxy and redirect servers

SIP uses clear text for sending messages, which helps administrators troubleshoot network issues. The two types of SIP messages include

• Request A message from a client to a server

• Response A message from a server to a client

A request includes messages such as an INVITE (which requests a participant to join the session) or a BYE (which disconnects the current call). Conversely, a response message uses HTTP status messages. For example, have you ever attempted to connect to a website and received a "404 error" or a "500 error" message? Those HTTP responses are also used in the SIP environment.

For a SIP client to get the IP address of a SIP server, it has to resolve (that is, look up) a SIP address. These SIP addresses are actually URLs, which happen to begin with sip:, as opposed to http:. SIP addresses can include a variety of information such as username, password, hostname, IP address, and phone number information. Consider the following example of a SIP address:

sip:[e-mail];user=phone

In this example, the user=phone argument specifies that the user portion of the URL (that is, 18595551212) represents a phone number and not a user ID.

SIP devices can dynamically make their addresses known by registering with a SIP registrar server. Once SIP devices have their addresses registered, a SIP client might have the ability to resolve a SIP address by itself, perhaps via DNS or through a local host table. However, a SIP client might use a SIP proxy server to query a SIP location database to resolve the SIP IP address. Consider a basic SIP call, where one SIP gateway communicates directly with another SIP gateway, without the use of proxy or redirect servers, as shown in Figure 5-7.

Figure 5-7. Basic SIP Call Setup

A basic SIP call setup begins when a SIP client sends an INVITE message to a SIP server (noting a SIP IP phone can act as either a UAC or a UAS, depending on whether it is originating or terminating the call). The destination server (that is, a UAS) responds if it is willing to join the session to which it has been invited. The originating client (that is, a UAC) sends an acknowledgement (that is, an ACK message) to the destination server. At this point, the RTP streams flow directly between the SIP gateways.

If you introduce a SIP proxy server into your topology, the call setup procedure is similar to that just discussed. However, the INVITE message goes to the proxy server rather than the destination UAS. The proxy server might consult a location server to learn the IP address of the final endpoint. The destination exchanges call parameters with the proxy server, which responds to the originating UAC. The UAC then forwards an ACK, via the proxy server, to the destination UAS, after which the RTP stream begins. Using a proxy server offers you the benefits of centralized call control and call setup management.

When a redirect server is used, the originating UAC sends an INVITE message to a redirect server, which might consult a location server to determine the path to the destination. The registrar server responds to the UAC with a "moved message," telling the UAC the IP address of the destination UAS. This operation is much like when you connect to a website, and you receive a message saying that the page you are looking for has moved to a new URL, and you are automatically redirected. Once the UAC learns the location of the destination UAS, a direct connection can be set up between the UAC and UAS. Therefore, the main purpose of a redirect server is to off-load the IP resolution process from the UAC.

If one of your SIP servers goes down, the voice network could be rendered unavailable. One way to provide redundancy is to have multiple instances of proxy and redirect servers. Therefore, the UAs can contain multiple server entries, and if the first server fails, the second server takes over.