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:

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 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.

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.

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

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.

Example 4-1. SIP INVITE Message

 

[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:

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: ;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.

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: ;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.

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: ;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.

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: ;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  

Категории