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:[e-mail]

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 informationwhether a phone is on- or off- hookwhen 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 applicationsyou 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 platformincluding instant messaging, voice, video, and application-sharingis 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

Class of Response	Status Code	Explanation
Informational/provisional	100	Trying
	180	Ringing
	181	Call Is Being Forwarded
	182	Queued
	183	Session Progress
Success	200	OK
Redirection	300	Multiple Choices
	301	Moved Permanently
	302	Moved Temporarily
	305	Use Proxy
	380	Alternative Service
Client-error	400	Bad Request
	401	Unauthorized
	402	Payment Required
	403	Forbidden
	404	Not Found
	405	Method Not Allowed
	406	Not Acceptable
	407	Proxy Authentication Required
	408	Request Timeout
	410	Gone
	413	Request Entity Too Large
	414	Requested URL Too Large
	415	Unsupported Media Type
	416	Unsupported URI[1] Scheme
	420	Bad Extension
	421	Extension Required
	423	Interval Too Brief
	480	Temporarily Not Available
	481	Call Leg or Transaction Does Not Exist
	482	Loop Detected
	483	Too Many Hops
	484	Address Incomplete
	485	Ambiguous
	486	Busy Here
	487	Request Terminated
	488	Not Acceptable Here
	491	Request Pending
	493	Undecipherable
Server-error	500	Internal Server Error
	501	Not Implemented
	502	Bad Gateway
	503	Service Unavailable
	504	Server Timeout
	505	SIP Version Not Supported
	513	Message Too Large
Global failure	600	Busy Everywhere
	603	Decline
	604	Does Not Exist Anywhere
	606	Not Acceptable

[1] URI = uniform resource identifier

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 endpointthe IP addresses listed are for the gateway and CallManager. A SIP trunk exists between CallManager and the gateway/CME.

[View full width]

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: ;tag=105741C-1D5E !The called party To: 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 refreshes 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: .1>;party=calling;screen=no;privacy=off Timestamp: 1014960901 !Identifies the user agent client, for return messages Contact: 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

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.

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: ;tag=105741C-1D5E
!A tag is added by the UAS to identify this series of messages
To: ;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.

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: ;tag=105741C-1D5E
To: ;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: ;party=called;screen=no;privacy=off
Contact: 
Content-Length: 0

 

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

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: ;tag=105741C-1D5E
To: ;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: ;party=called;screen=yes;privacy=off
Contact: 
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.

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: ;tag=105741C-1D5E
T0o: ;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