Session Initiation Protocol

The Session Initiation Protocol (SIP) is an Internet Engineering Task Force (IETF) standard call control protocol, based on research at Columbia University by Henning Schulzrinne and his team. The first SIP RFC, number 2543, was published in 1999. Since then, much work has been done, and numerous RFCs have been published to solidify and extend SIP capabilities.

SIP is designed to provide signaling and session management for voice and multimedia connections over packet-based networks. It is a peer-to-peer protocol with intelligent endpoints and distributed call control, such as H.323. Gateways that use SIP do not depend on a call agent, although the protocol does define several functional entities that help SIP endpoints locate each other and establish a session.

In this chapter you will learn

• How SIP works
• SIP call flow
• SIP pros and cons
• Dial plan considerations
• How to implement SIP gateways
• Some ways to secure SIP gateways
• Allowing H.323 to SIP connections
• Troubleshooting tools

Description of SIP

SIP was designed as one module in an IP communications solution. This modular design allows it to integrate with and use the services of other existing protocols, such as Session Description Protocol (SDP), Real-Time Transport Protocol (RTP), Resource Reservation Protocol (RSVP), RADIUS, and Lightweight Directory Access Protocol (LDAP). SIP usually uses User Datagram Protocol (UDP) as its transport protocol, but it can also use TCP. The default SIP port for either TCP or UDP is 5060. To provide additional security, Transport Layer Security (TLS) support is included beginning with Cisco IOS Software Release 12.3(14)T. SIP specifications do not cover all the possible aspects of a call, as does H.323. Instead, its job is to create, modify, and terminate sessions between applications, regardless of the media type or application function. The session can range from just a two-party phone call to a multiuser, multimedia conference or an interactive gaming session. SIP does not define the type of session, only its management. To do this, SIP performs four basic tasks:

• Locating users, resolving their SIP address to an IP address
• Negotiating capabilities and features among all the session participants
• Changing the session parameters during the call
• Managing the setup and teardown of calls for all users in the session

SIP is built on a client-server model, using requests and responses that are similar to Internet applications. It uses the same address format as e-mail, with a unique user identifier (such as telephone number) and a domain identifier. A typical SIP address looks like one of the following:

• sip:1112223344@mycompany.com
• sip:1112223344@10.1.1.1

This allows Domain Name System (DNS) to be used to locate users, and it also allows SIP to integrate easily with e-mail. SIP uses Multipurpose Internet Mail Extension (MIME) to describe the contents of its messages. Thus, SIP messages can contain information other than audio, such as graphics, billing data, authentication tokens, or video. Session Description Protocol (SDP) is used to exchange session capabilities and features.

One of the most unique parts of SIP is the concept of presence. The public switched telephone network (PSTN) can provide basic presence information—whether a phone is on- or off- hook—when a call is initiated. However, SIP takes that further. It can provide information on the willingness of the other party to receive calls, not just the ability, before the call is attempted. This is similar in concept to instant messaging applications—you can choose which users appear on your list, and they can choose to display different status types, such as offline, busy, and so on. Users who subscribe to that instant messaging service know the availability of those on their list before they try to contact them. With SIP, you can gather presence information from many devices, such as cell phones, SIP phones, personal digital assistants (PDA), and applications. A SIP Watcher subscribes to receive presence information about a SIP Presentity. SIP presence information is available only to subscribers.

SIP is already influencing the marketplace. A growing number of IP Telephony Service Providers (ITSP), such as Vonage, are already using it. Traditional telephony providers, such as AT&T, have created SIP-aware networks for both internal and customer use. Cellular phone providers use SIP to offer additional services in their 3G networks. The Microsoft real-time communications platform—including instant messaging, voice, video, and application-sharing—is based on SIP. Cisco applications such as MeetingPlace, CallManager, and CallManager Express (CME) support SIP. Some hospitals are implementing SIP to allow heart monitors and other devices to send an instant message to nurses. You can expect to see its use increase as more applications and extensions are created for SIP.

SIP Functional Components

SIP endpoints are called user agents (UA) and can be various devices, including IP phones, cell phones, PDAs, Cisco routers, or computers running a SIP-based application. UAs can act as either clients or servers. The user agent client (UAC) is the device that is initiating a call, and the user agent server (UAS) is the device that is receiving the call. The SIP protocol defines several other functional components. These functional entities can be implemented as separate devices, or the same device can perform multiple functions.

• Proxy server—This server can perform call routing, authentication, authorization, address resolution, and loop detection. A UA sends its call setup messages through a proxy server. The proxy server can forward the messages if it knows where the called party is located, or it can query other servers to find that information. It then forwards the request to the next hop. When it receives a response to the request, it forwards that to the client UA. After the call is set up, the proxy server can elect to stay in the signaling path so that it also sees call change or termination messages, or it can withdraw from the path and let the UAs communicate directly. Cisco has a SIP proxy server product.
• Redirect server—UAs and proxy servers can contact a redirect server to find the location of an endpoint. This is particularly useful in a network that has mobile users whose location changes. The redirect server can let its clients know that a user has moved either temporarily or permanently. It can also return multiple possible addresses for the user, if necessary. When a UA has multiple addresses, the proxy server can fork the call, sending it to each address either simultaneously or sequentially. This allows "Find Me/Follow Me" type services. Cisco routers can act as SIP redirect servers.
• Registrar server—UAs register their location with a registrar server, which places that information into a location database. A registrar server responds to location requests from other servers. The server can maintain the location database locally, or it can employ a separate location server. Cisco routers and CallManager 5.x can act as SIP registrar servers.
• Location server—This server maintains the location database for registered UAs.
• Back-to-back user agent (B2BUA)—This server acts as a UA server and client at the same time. It terminates the signaling from the calling UA and then initiates signaling to the called UA. B2BUAs are allowed to change the content of requests, giving them more control over the call parameters. Cisco CallManager 5.x can function as a SIP B2BUA.
• Presence server—This server gathers presence information from Presentities and subscription information from Watchers, and sends status notifications.

All these functions work together to accomplish the goal of establishing and managing a session between two UAs. SIP servers can also interact with other application servers to provide services, such as authentication or billing.

You can configure Cisco routers as SIP gateways. As such, they can act as a SIP UAC or UAS, they can register E.164 numbers with a SIP registrar, and they can act as SIP registrar and redirect servers. In addition, they can set up SIP trunks to another SIP gateway or to CallManager.

A Cisco SIP gateway that is using Survivable Remote Site Telephony (SRST) can provide registration and redirection services to SIP phones when CallManager and proxy servers are unavailable. SRST is not on by default; you must configure it. Both SIP and SCCP phones can fail over to a router that is running SIP SRST. Cisco CME and SRST also support B2BUA functionality beginning in Cisco IOS 12.(4)T. SIP SRST is described in Chapter 13, "SRST and MGCP Gateway Fallback."

SIP Messages

SIP uses plain-text messages, following the format of standard Internet text messages. This helps in troubleshooting, because it is easy to read SIP messages. However, you must understand the types of messages and their formats to successfully troubleshoot them. This section helps you with that understanding.

SIP messages are either requests or responses to a request; the function that the request invokes on a server is called a method. Several types of SIP methods exist. The original SIP specification included the following six methods. Cisco gateways can both send and receive these methods, except where noted.

• REGISTER—A UA client sends this message to inform a SIP server of its location.
• INVITE—A caller sends this message to request that another endpoint join a SIP session, such as a conference or a call. This message can also be sent during a call to change session parameters.
• ACK—A SIP UA can receive several responses to an INVITE. This method acknowledges the final response to the INVITE.
• CANCEL—This message ends a call that has not yet been fully established.
• OPTIONS—This message queries the capabilities of a server. Cisco gateways receive these methods only.
• BYE—This message ends a session or declines to take a call.

Cisco gateways also support the following additional methods, but they only respond to them. They do not generate them.

• INFO—This message is used when data is carried within the message body.
• PRACK—This message acknowledges receipt of a provisional, or informational, response to a request.
• REFER—This message points to another address to initiate a transfer.
• SUBSCRIBE—This message lets the server know that you want to be notified if a specific event happens.
• NOTIFY—This message lets the subscriber know that a specified event has occurred. It can also transmit dual tone multifrequency (DTMF) tones.
• UPDATE—A UAC uses this to change the session parameters, such as codec used or quality of service (QoS) settings, before answering the initial INVITE.

SIP entities can send additional messages in response to a method; these responses are listed in Table 4-1. Responses to SIP methods fall into six categories. The 100 Series designates informational or provisional responses, such as 100 for Trying, and 180 for Alerting. A 200 Series response means that the request was successful; it includes 200 for OK, and 202 for Accepted. The 300 Series redirects the user to a different location for the called endpoint. Examples include 301 for Moved Permanently and 302 for Moved Temporarily. The 400 Series of responses indicate a request failure, such as 404 User Not Found and 480 Temporarily Unavailable. A 500 Series response is received due to a server failure, such as 500 for Server Internal Error or 503 for Service Unavailable. The 600 Series is used for a global failure, including 603 when the call is declined.

Table 4-1. SIP Response Table

Example 4-1 shows a SIP INVITE message and explains the different fields. This call is from an IP phone in a CME network to an IP phone in a CallManager network. Neither phone is a SIP endpoint—the IP addresses listed are for the gateway and CallManager. A SIP trunk exists between CallManager and the gateway/CME.

Example 4-1. SIP INVITE Message

SIP-GW#debug ccsip messages
Sent:!Request-URI (Uniform Resource Identifier) field

!This is the SIP address, or SIP URL, that the INVITE is sent to

INVITE sip:3401@10.6.2.10:5060 SIP/2.0!Each device that handles the packet adds its IP address to the VIA 
field
Via: SIP/2.0/UDP  10.6.3.1:5060;branch=z9hG4bKA1798!The calling party. A tag identifies this series of messages

From: <sip:4105553501@10.6.3.1>;tag=105741C-1D5E!The called party

To: <sip:3401@10.6.2.10>
Date: Fri, 06 Jan 2006 05:35:01 GMT!Unique identifier for this call

Call-ID: E937365B-2C0C11D6-802FA93D-4772A3BB@10.6.3.1!Extensions supported include reliable provisional responses and timer
 refreshers
Supported: 100rel, timer!Minimum value for session interval

Min-SE:  1800
Cisco-Guid: 3892269682-738988502-2150410557-1198695355!Identifies the device that originated the INVITE

User-Agent: Cisco-SIPGateway/IOS-12.x!List of methods that are supported

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY,
INFO, UPDATE, REGISTER!Identifies call sequence number and method for this call

CSeq: 101 INVITE!Max number of proxies or gateways that can forward this message

Max-Forwards: 70
Remote-Party-ID: <sip:4105553501@10.6.3.1>;party=calling;screen=no;privacy=off
Timestamp: 1014960901!Identifies the user agent client, for return messages

Contact: <sip:4105553501@10.6.3.1:5060>
Expires: 180
Allow-Events: telephone-event!This INVITE carries an SDP message

Content-Type: application/sdp
Content-Length: 202

SIP uses SDP to exchange information about endpoint capabilities and negotiate call features. This sample INVITE contains SDP information. The SDP part of a SIP message has standard fields, as shown in Example 4-2. This is the continuation of the INVITE message in Example 4-1. The SDP fields have the following meanings:

• v—Tells the SDP version
• o—Lists the organization of the calling party
• s—Describes the SDP message
• c—Lists the IP address of the originator
• t—Tells the timer value
• m—Describes the media that the originator expects
• a—Gives the media attributes

Example 4-2. SIP SDP Message Contents

v=0
o=CiscoSystemsSIP-GW-UserAgent 7181 811 IN IP4 10.6.3.1
s=SIP Call
c=IN IP4 10.6.3.1
t=0 0
m=audio 18990 RT
SIP-CME#P/AVP 0 19
c=IN IP4 10.6.3.1
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20

Continuing the call, the called side (the UAS) returns a provisional response 100 Trying, shown in Example 4-3. Note that the call sequence number, 101, and the method type it is responding to, INVITE, are sent in each message.

Example 4-3. SIP "Trying" Response

Received:
!"Trying" indicates that the gateway has received the INVITE
SIP/2.0 100 Trying
Via: SIP/2.0/UDP  10.6.3.1:5060;branch=z9hG4bKA1798
From: <sip:4105553501@10.6.3.1>;tag=105741C-1D5E
!A tag is added by the UAS to identify this series of messages
To: <sip:3401@10.6.2.10>;tag=16777231
Date: Fri, 06 Jan 2006 5:35:10 GMT
Call-ID: E937365B-2C0C11D6-802FA93D-4772A3BB@10.6.3.1
Timestamp: 1014960901
CSeq: 101 INVITE
Allow-Events: telephone-event
Content-Length: 0

In Example 4-4, the UAS sends a 180 Ringing response to indicate that the remote phone is ringing.

Example 4-4. SIP Ringing Response

Received:
! Ringing indicates that the called phone is being alerted
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP  10.6.3.1:5060;branch=z9hG4bKA1798
From: <sip:4105553501@10.6.3.1>;tag=105741C-1D5E
To: <sip:3401@10.6.2.10>;tag=16777231
Date: Fri, 06 Jan 2006 5:35:10 GMT
Call-ID: E937365B-2C0C11D6-802FA93D-4772A3BB@10.6.3.1
Timestamp: 1014960901
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK
Allow-Events: telephone-event
Remote-Party-ID: <sip:3401@10.6.2.10>;party=called;screen=no;privacy=off
Contact: <sip:3401@10.6.2.10:5060>
Content-Length: 0

The remote phone has picked up the call, so a 200 OK response is sent, as shown in Example 4-5.

Example 4-5. SIP OK Response

Received:
! OK indicates that the called phone has answered
SIP/2.0 200 OK
Via: SIP/2.0/UDP  10.6.3.1:5060;branch=z9hG4bKA1798
From: <sip:4105553501@10.6.3.1>;tag=105741C-1D5E
To: <sip:3401@10.6.2.10>;tag=16777231
Date: Fri, 06 Jan 2006 5:35:12 GMT
Call-ID: E937365B-2C0C11D6-802FA93D-4772A3BB@10.6.3.1
0Timestamp: 1014960901
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK
Allow-Events: telephone-event
Remote-Party-ID: <sip:3401@10.6.2.10>;party=called;screen=yes;privacy=off
Contact: <sip:3401@10.6.2.10:5060>
Content-Type: application/sdp
Content-Length: 221

v=0
o=CiscoSystemsCCM-SIP 2000 1000 IN IP4 10.6.2.10
s=SIP Call
c=IN IP4 10.6.2.10
t=0 0
m=audio 24580 RTP/AVP 0 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

The UAC responds to the OK message with an ACK method, shown in Example 4-6. Now the call is established.

Example 4-6. SIP ACK Message

Sent:
ACK sip:3401@10.6.2.10:5060 SIP/2.0
Via: SIP/2.0/UDP  10.6.3.1:5060;branch=z9hG4bKB1C57
From: <sip:4105553501@10.6.3.1>;tag=105741C-1D5E
T0o: <sip:3401@10.6.2.10>;tag=16777231
Date: Fri, 06 Jan 2006 5:35:13 GMT
Call-ID: E937365B-2C0C11D6-802FA93D-4772A3BB@10.6.3.1
Max-Forwards: 70
CSeq: 101 ACK
Content-Length: 0