Telecom Protocols

Internal Use Only

Session Initiation Protocol (SIP)

Introduction:
The Session Initiation Protocol (SIP) is a signaling communications protocol, widely used for controlling multimedia communication sessions such as voice and video calls over Internet Protocol (IP) networks. The protocol defines the messages that are sent between peers which govern establishment, termination and other essential elements of a call. SIP can be used for creating, modifying and terminating sessions consisting of one or several media streams. SIP can be used for two-party (unicast) or multiparty (multicast) sessions. Other SIP applications include video conferencing, streaming multimedia distribution, instant, presence information, file transfer, fax over IP and online games. It is an application layer protocol designed to be independent of the underlying transport layer; it can run on Transmission Control Protocol (TCP), User Datagram Protocol (UDP) or Stream Control Transmission Protocol (SCTP). It is a text-based protocol, incorporating many elements of the Hypertext (HTTP) and the Simple Mail Transfer Protocol (SMTP). SIP works in conjunction with several other application layer protocols that identify and carry the session media. Media identification and negotiation is achieved with the Session Description Protocol (SDP). For the transmission of media streams (voice, video) SIP typically employs the Real-time Transport Protocol (RTP) or Secure Real-time Transport Protocol (SRTP). For secure transmissions of SIP messages, the protocol may be encrypted with Transport Layer Security (TLS).

Protocol Design:
SIP employs design elements similar to the HTTP request/response transaction model. Each transaction consists of a client request that invokes a particular method or function on the server and at least one response. SIP reuses most of the header fields, encoding rules and status codes of HTTP, providing a readable text-based format. Each resource of a SIP network, such as a user agent or a voicemail box, is identified by a uniform resource identifier (URI), based on the general standard syntax also used in Web services and e-mail. The URI scheme used for SIP is sip: and a typical SIP URI is of the form: sip:username:password@host:port. If secure transmission is required, the scheme sips: is used and mandates that each hop over which the request is forwarded up to the target domain must be secured with Transport Layer Security (TLS). The last hop from the proxy of the target domain to the user agent has to be secured according to local policies. TLS protects against attackers which try to listen on the signaling link but it does not provide real end-to-end security to prevent espionage and law enforcement interception, as the encryption is only hop-byhop and every single intermediate proxy has to be trusted. SIP works in concert with several other protocols and is only involved in the signaling portion of a communication session. SIP clients typically use TCP or UDP on port numbers 5060 and/or 5061 to connect to SIP servers and other SIP endpoints. Port 5060 is commonly used for nonencrypted signaling traffic whereas port 5061 is typically used for traffic encrypted with Transport Layer Security (TLS). SIP is primarily used in setting up and tearing down voice or video calls. It also allows modification of existing calls. The modification can involve changing addresses or ports, inviting more participants, and adding or deleting media streams. SIP has also found applications in messaging applications, such as instant messaging, and event subscription and notification. A suite of SIP-related Internet Engineering Task Force (IETF) rules define behavior for such applications. The voice and video stream communications in SIP applications are carried over another application protocol, the Realtime Transport Protocol (RTP). Parameters (port numbers, protocols, codecs) for these media streams are defined and negotiated using the Session Description Protocol (SDP) which is transported in the SIP packet body. A motivating goal for SIP was to provide a signaling and call setup protocol for IP-based communications that can support a superset of the call processing functions and features present in the public switched telephone network (PSTN). SIP by itself does not define these features; rather, its focus is call-setup and signaling. The features that permit familiar telephone-like operations: dialing a number, causing a phone to ring, hearing ring back tones or a busy signal - are performed by proxy servers and user agents. Implementation and terminology are different in the SIP world but to the end-user, the behavior is similar. SIP-enabled telephony networks can also implement many of the more advanced call processing features present in Signaling System 7 (SS7), though the two protocols themselves are very different. SS7 is a centralized protocol, characterized by complex central network architecture and dumb endpoints (traditional telephone handsets). SIP is a peer-to-peer protocol, thus it requires only a simple (and thus scalable) core
[5]

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

network with intelligence distributed to the network edge, embedded in endpoints (terminating devices built in either hardware or software). SIP features are implemented in the communicating endpoints (i.e. at the edge of the network) contrary to traditional SS7 features, which are implemented in the network.

SIP Network elements:

SIP also defines server network elements. Although two SIP endpoints can communicate without any intervening SIP infrastructure, which is why the protocol is described as peer-to-peer, this approach is often impractical for a public service.

User Agent
A SIP user agent (UA) is a logical network end-point used to create or receive SIP messages and thereby manage a SIP session. A SIP UA can perform the role of a User Agent Client (UAC), which sends SIP requests, and the User Agent Server (UAS), which receives the requests and returns a SIP response. These roles of UAC and UAS only last for the duration of a SIP transaction. A SIP phone is a SIP user agent that provides the traditional call functions of a telephone, such as dial, answer, reject, hold / un-hold, and call transfer. SIP phones may be implemented as a hardware device or as a soft phone. As vendors increasingly implement SIP as a standard telephony platform, often driven by 4G efforts, the distinction between hardware-based and software-based SIP phones is being blurred and SIP elements are implemented in the basic firmware functions of many IP-capable devices. Examples are devices from Nokia and BlackBerry. In SIP, as in HTTP, the user agent may identify itself using a message header field 'User-Agent', containing a text description of the software/hardware/product involved. The User-Agent field is sent in request messages, which means that the receiving SIP server can see this information. SIP network elements sometimes store this information, and it can be useful in diagnosing SIP compatibility problems.

Proxy server
An intermediary entity that acts as both a server (UAS) and a client (UAC) for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it.

Registrar
A registrar is a SIP endpoint that accepts REGISTER requests and places the information it receives in those requests into a location service for the domain it handles. The location service links one or more IP addresses to the SIP URI of the registering agent. The URI uses the sip: scheme, although other protocol schemes are possible, such as tel: More than one agent can register at the same URI, with the result that all registered user agents receive the calls to the URI. SIP registrars are logical elements, and are commonly co-located with SIP proxies. But it is also possible and often good for network scalability to place this location service with a redirect server.

Redirect server
A user agent server that generates 3xx (Redirection) responses to requests it receives, directing the client to contact an alternate set of URIs. The redirect server allows proxy servers to direct SIP session invitations to external domains.

Session border controller

Session border controllers Serve as middle boxes between UA and SIP servers for various types of functions, including network topology hiding, and assistance in NAT traversal.

Gateway
Gateways can be used to interface a SIP network to other networks, such as the public switched telephone network, which use different protocols or technologies.

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

SIP Message:
SIP is a text-based protocol with syntax similar to that of HTTP. There are two different types of SIP messages: requests and responses. The first line of a request has a method, defining the nature of the request, and a Request-URI, indicating where the request should be sent. The first line of a response has a response code. For SIP requests, RFC 3261 defines the following methods: Main article: List of SIP request methods REGISTER: Used by a UA to indicate its current IP address and the URLs for which it would like to receive calls. INVITE: Used to establish a media session between user agents. ACK: Confirms reliable message exchanges. CANCEL: Terminates a pending request. BYE: Terminates a session between two users in a conference. OPTIONS: Requests information about the capabilities of a caller, without setting up a call. A new method has been introduced in SIP in RFC 3262: PRACK (Provisional Response Acknowledgement): PRACK improves network reliability by adding an acknowledgement system to the provisional Responses (1xx). PRACK is sent in response to provisional response (1xx). The SIP response types defined in RFC 3261 fall in one of the following categories: Main article: List of SIP response codes Provisional (1xx): Request received and being processed. Success (2xx): The action was successfully received, understood, and accepted. Redirection (3xx): Further action needs to be taken (typically by sender) to complete the request. Client Error (4xx): The request contains bad syntax or cannot be fulfilled at the server. Server Error (5xx): The server failed to fulfill an apparently valid request. Global Failure (6xx): The request cannot be fulfilled at any server.

Transaction:
SIP makes use of transactions to control the exchanges between participants and deliver messages reliably. The transactions maintain an internal state and make use of timers. Client Transactions send requests and Server Transactions respond to those requests with one-or-more responses. The responses may include zero-or-more Provisional (1xx) responses and one-or-more final (2xx-6xx) responses. Transactions are further categorized as either Invite or Non-Invite. Invite transactions differ in that they can establish a long-running conversation, referred to as a Dialog in SIP, and so include an acknowledgment (ACK) of any non-failing final response (e.g. 200 OK). Because of these transactional mechanisms, SIP can make use of un-reliable transports such as User Datagram Protocol (UDP).

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

If we take the above example, User1s UAC uses an Invite Client Transaction to send the initial INVITE (1) message. If no response is received after a timer controlled wait period the UAC may have chosen to terminate the transaction or retransmit the INVITE. However, once a response was received, User1 was confident the INVITE was delivered reliably. User1s UAC then must acknowledge the response. On delivery of the ACK (2) both sides of the transaction are complete. And in this case, a Dialog may have been established.

Instant Messaging and Presence:

The Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) is the SIP-based suite of standards for instant messaging and presence information. MSRP (Message Session Relay Protocol) allows instant message sessions and file transfer.

Conformance testing:
TTCN-3 test specification language is used for the purposes of specifying conformance tests for SIP implementations. SIP test suite is developed by a Specialist Task Force at ETSI (STF 196).
[17]

The SIP developer community meets regularly at the SIP Forum SIP it events to test

interoperability and test implementations of new RFCs.

Applications:
The market for consumer SIP devices continues to expand; there are many devices such as SIP Terminal Adapters, SIP Gateways, and SIP Trunking services providing replacements for ISDN telephone lines. Many VoIP phone companies allow customers to use their own SIP devices, such as SIP-capable telephone sets, or softphones. SIP-enabled video surveillance cameras can make calls to alert the owner or operator that an event has occurred; for example, to notify that motion has been detected out-of-hours in a protected area. SIP is used in audio over IP for broadcasting applications where it provides an interoperable means for audio interfaces from different manufacturers to make connections with one another.
[18]

SIP-ISUP interworking:

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

SIP-I, or the Session Initiation Protocol with encapsulated ISUP, is a protocol used to create, modify, and terminate communication sessions based on ISUP using SIP and IP networks. Services using SIP-I include voice, video telephony, fax and data. SIP-I and SIP-T
[19]

are two protocols

with similar features, notably to allow ISUP messages to be transported over SIP networks. This preserves all of the detail available in the ISUP header, which is important as there are many country-specific variants of ISUP that have been implemented over the last 30 years, and it is not always possible to express all of the same detail using a native SIP message. SIP-I was defined by the ITU-T, where SIP-T was defined via the IETF RFC route.
[20]

A Session Initiation Protocol (SIP) connection is a Voice over Internet Protocol (VoIP) service offered by many Internet

telephony service providers (ITSPs) that connects a company's private branch exchange (PBX) telephone system to the public switched telephone network (PSTN) via the Internet. Using a SIP connection may simplify administration for the organization as the SIP connection typically uses the same Internet access that is used for data. This often removes the need to install Basic Rate Interface (BRI) or Primary Rate Interface (PRI) telephone circuits.

Deployment issues:
If the call traffic runs on the same connection with other traffic, such as email or Web browsing, voice and even signaling packets may be dropped and the voice stream may be interrupted. To mitigate this, many companies split voice and data between two separate internet connections. Alternately, some networks use the TOS precedence or DiffServ fields in the header of IPV4 packets to mark the relative time-sensitivity of SIP and RTP as compared to web, email, video and other types of IP traffic. This precedence marking method requires that all routers in the SIP and RTP paths support separate queues for different traffic types. Other options to control delay and loss include incorporating multiple VLANs (virtual local area networks), traffic shaping to avoid this resource conflict, but the efficacy of this solution is dependent on the number of packets dropped between the Internet and the PBX. Registration is required if the end user has a dynamic IP address, if the provider does not support static hostnames, or if NAT is used. In order to share several DID numbers on the same registration, the IETF has defined additional headers (for example "P-PreferredIdentity", see RFC 3325). This avoids multiple registrations from one PBX to the same provider. Using this method the PBX can indicate what identity should be presented to the Called party and what identity should be used for authenticating the call. This feature is also useful when the PBX redirects an incoming call to a PSTN number, for example a cell phone, to preserve the original Caller ID. Users should also be aware that a SIP connection can be used as a channel for attacking the company's internal networks, similar to Web and Email attacks. Users should consider installing appropriate security mechanisms to prevent malicious attacks.

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:

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols
sip:1112223344@mycompany.com sip:1112223344@10.1.1.1

Internal Use Only

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 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, is 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 Meeting Place, Call Manager, and Call Manager 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 serversthis 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 serverUAs 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 serverUAs 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 Call Manager 5.x can act as SIP registrar servers. Location serverthis 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 Call Manager 5.x can function as a SIP B2BUA. Presence serverthis 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 Call Manager.

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

A Cisco SIP gateway that is using Survivable Remote Site Telephony (SRST) can provide registration and redirection services to SIP phones when Call Manager 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. REGISTERA UA client sends this message to inform a SIP server of its location. INVITEA 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. ACKA SIP UA can receive several responses to an INVITE. This method acknowledges the final response to the INVITE. CANCELthis message ends a call that has not yet been fully established. OPTIONSthis message queries the capabilities of a server. Cisco gateways receive these methods only. BYEthis 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. INFOthis message is used when data is carried within the message body. PRACKthis message acknowledges receipt of a provisional, or informational, response to a request. REFERthis message points to another address to initiate a transfer. SUBSCRIBEthis message lets the server know that you want to be notified if a specific event happens. NOTIFYthis message lets the subscriber know that a specified event has occurred. It can also transmit dual tone multi frequency (DTMF) tones. UPDATEA 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

Class Response

of

Status Code

Explanation

Informational/provi sional

100

Trying

Success

200

OK

180 181

Ringing Call Is Being Forwarded

Client-error

400 401

Bad Request Unauthorized

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols
182 183 Redirection 300 301 302 305 380 Server-error 500 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 505 513 Global failure 600 603 Decline Server Timeout SIP Version Not Supported Message Too Large Busy Everywhere Queued Session Progress Multiple Choices Moved Permanently Moved Temporarily Use Proxy Alternative Service Internal Server Error

Internal Use Only

402 403 404 405 406 407 408 410 413 Payment Required Forbidden Not found Method Not allowed Not Acceptable Proxy Authentication Required Request Timeout Gone Request Entity Too Large

414

Requested URL Too Large

415

Unsupported Media Type

416 420 421 423 480

Unsupported URI Scheme Bad Extension Extension Required Interval Too Brief Temporarily Not Available

604

Does Not Exist Anywhere

481

Call Leg or Transaction Does Not Exist

606

Not Acceptable

482 483 484 485 486 487 488

Loop Detected Too Many Hops Address Incomplete Ambiguous Busy Here Request Terminated Not Acceptable Here

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

491 493 Request Pending Undecipherable

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 Call Manager network. Neither phone is a SIP endpointthe IP addresses listed are for the gateway and Call Manager. A SIP trunk exists between Call Manager 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

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

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

Internal Use Only

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: vTells the SDP version oLists the organization of the calling party sDescribes the SDP message cLists the IP address of the originator tTells the timer value mDescribes the media that the originator expects aGives 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.

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

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

Internal Use Only

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols 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

Internal Use Only

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:

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols
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

Internal Use Only

SIP Call Flow

Basic SIP session setup involves a SIP UA client sending a request to the SIP URL of the called endpoint (UAS), inviting it to a session. If the UAC knows the IP address of the UAS, it can send the request. Otherwise, the UAC sends the request to a proxy or redirect server to locate the user. That server might forward the request to other servers until the user is located. After the SIP address is resolved to an IP address, the request is sent to the UAS. If the user takes the call, capabilities are negotiated and the call commences. If the user does not take the call, it can be forwarded to voice mail or another number. The following sections outline various scenarios in more detail.

Call Flow Between Two SIP Gateways

Cisco routers, including CME routers, can act as SIP gateways for calls that originate from non-SIP phones. The gateways function as SIP UAs and set up a SIP session between them for each call. Figure 4-1 shows two routers handling analog phones, using SIP between them. In this example, SIP GW-A originates the calls and acts as a UAC, and SIP GW-B acts as a UAS. The signaling from the PBX to the gateway is just normal analog call signaling. Only the two gateways exchange SIP messages.

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

Figure 4-1 Call Flow Between Two SIP Gateways In Figure 4-1, the analog phone on the left initiates a call to the analog phone on the right. After the first phone initiates the call, the call flow proceeds as follows: 1. 2. 3. 4. 5. 6. 7. 8. 9. The PBX sends a call setup signal to GW-A, which then sends a SIP INVITE message to GW-B. This INVITE contains SDP information for capabilities negotiation. GW-A also sends a Call Proceeding message to the PBX. GW-B exchanges call setup message with its PBX and sends SIP responses 100 (Trying) and 180 (Ringing) to GW-A. GW-A translates these messages into analog signaling messages for its PBX. When the user on the right picks up the call, his PBX sends a Connect message to GW-B, which then forwards a SIP 200 (OK) response to GW-A. This OK response contains SDP information with the capabilities that both devices support. GW-A delivers a Connect message to its PBX. When the PBX acknowledges that with a Connect ACK, it sends a SIP ACK message to GW-B. GW-B sends a Connect acknowledgement to its PBX, and the call is active. At this point, normal voice steams exist between the two phones and the gateways, and RTP voice streams exist between the two gateways. The user on the left hangs up the phone. His PBX sends a Call Disconnect message to GW-A. GW-A then sends a SIP BYE message to GW-B and a Release message to the PBX. The PBX responds with a Release Complete message. GW-B sends a Call Disconnect message to its PBX, which responds with a Release message. GW-B forwards a SIP 200 (OK) response to GW-A and a Release Complete message to its PBX. The call is now completely terminated.

Call Flow Using a Proxy Server

SIP UAs register with a proxy server or a registrar. Proxy servers then act as an intermediary for SIP calls. Cisco routers that are acting as SIP gateways can use the services of a SIP proxy server, either contacting the server or receiving requests from it. They can additionally register E.164 numbers with a proxy server or a registrar. Proxy servers can either leave the signaling path when the call is connected or can enable "Record-route" to stay in the signaling path. If Record-route is disabled, the proxy server does not know of any changes to the call or when the call is disconnected. Figure 4-2 shows call flow when Record-route is disabled.

Figure 4-2 SIP Call Flow Using a Proxy Server In Figure 4-2, a SIP endpoint places a call using a proxy server. The figure shows several types of endpoints: Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols
A PC and a PDA running a SIP application A SIP phone A cell phone that uses SIP

Internal Use Only

In Figure 4-2, one of these endpoints places a call to an analog phone behind SIP gateway GW-B. The call flow proceeds as follows: 1. 2. 3. 4. 5. The UAC sends an INVITE to its proxy server. In this INVITE, the Request-URI field contains the address of the called phone number as part of the SIP address. SDP information is included with this INVITE. The proxy server creates a new INVITE, copying the information from the old INVITE, but replacing the Request-URI with the address of GW-Bthe UAS. When GW-B receives the INVITE, it initiates a call setup with the PBX. It sends a SIP response 100 (Trying) to the proxy server which, in this example, sends a 100 response to the SIP UAC. The proxy server is not required to send this response. The PBX sets up an analog call with the end user and sends call progress messages to GW-B. When GW-B receives the Alerting message, it sends a SIP 180 (Ringing) message to the proxy server. The proxy server sends the same message to the UAC. When the end user picks up the phone, the PBX sends a Connect message to GW-B. GW-B then sends a SIP 200 (OK) response to the proxy server, which sends it to the UAC. SDP information for the remote end is included in this OK response. The proxy server is not configured to be statefulthat is, Record Route is disabled. Therefore, the proxy server leaves the signaling path, and all further SIP signaling is directly between the UAC and GW-B. The SIP UAC acknowledges the OK response, and a two-way RTP stream is established between the UAC and GW-B, the UAS. A twoway voice stream is established between GW-B and the PBX. When the UAC hangs up, it exchanges SIP BYE and OK signals with GW-B. GW-B terminates the call with the PBX.

6. 7.

Call Flow Using Multiple Servers

SIP UAs and SIP proxy servers can contact a redirect server to determine where to send an INVITE. They typically do this when the called number is outside the local domain. The redirect server returns the most detailed information it haseither endpoint location(s) or the location of the next-hop server. Then it relies on the proxy server or UAC to route its INVITE appropriately. Figure 4-3 shows the call flow in a more complex network with registrar, redirect, and proxy servers. (Recall that these are functional units and can all reside in the same device.) The figure shows the messages that are necessary to route the initial INVITE method to the UAS. After GWB, the UAS, receives the INVITE, call flow is similar to the previous examples. Figure 4-3 SIP Call Flow with Multiple Servers

In Figure 4-3, one of the SIP endpoints in Network A calls an analog phone behind gateway GW-B in Network B. The following steps take place: 1. 2. 3. 4. 5. 6. 7. 8. The gateway, GW-B, registers the E.164 phone numbers of its analog phones with the registrar server. The registrar server replies with a 200 (OK) response. The UAC sends an INVITE method to its proxy server, Proxy-A. The proxy server recognizes that the destination number is outside its domain. It sends the INVITE to the redirect server. The redirect server replies with a 300-series message listing the SIP address of the next-hop proxy server, Proxy-B. Proxy-A sends an INVITE message to Proxy-B. Proxy-B requests the location of the called number from its registrar server. The registrar server responds with the SIP address of GW-B. Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols
9. Proxy-B sends an INVITE to GW-B.

Internal Use Only

Following these steps, GW-B sets up the call with the PBX. It sends responses to Proxy-B, which forwards them through Proxy-A to the calling endpoint. If Record-route is enabled, all further signaling goes through the proxies. If not, call signaling proceeds as shown in Figure 4-2. Call Flow Using Cisco CallManager 5.x CallManager 5.x supports SIP phones and is an integral part of a SIP network. It can play different roles, such as registrar server and B2BUA. Figure 4-4 illustrates a call flow scenario with CallManager acting as a B2BUA.

Figure 4-4 Call Flow with CallManager 5.x In Figure 4-4, a SIP phone is registered to a CallManager. The SIP phone places a call to an analog phone off a PBX behind the router/gateway GW-B. A SIP trunk exists between CallManager and the gateway. CallManager acts as a B2BUAit terminates each leg of the call during the signaling phases, yet it allows the RTP stream to go directly between the two endpoints. This is accomplished by the way SDP information is sent. 1. 2. 3. A SIP phone that is registered to CallManager calls the analog phone. It sends an INVITE containing standard SDP information to CallManager. CallManager responds with a 100 Trying message. In this step, CallManager is acting as a UAS. CallManager sends an INVITE over its SIP trunk to the remote SIP gateway, GW-B. This INVITE has a different Call-ID number than the one from the phone. In addition, this INVITE does not contain SDP fields. CallManager acts as a UAC in this step. GW-B answers with a 100 Trying message and initiates a call to the PBX. (That signaling is not shown.) GW-B sends its SDP parameters in a 183 Session Progress message to CallManager. Included in this are the session parameters that the gateway supports. CallManager sends a 183 Session Progress message to the SIP phone. This message contains an SDP portion with the capabilities that both endpoints support. For instance, suppose that the original SDP message of the phone indicated that it supported G.711 and G.729 codecs, but the gateway SDP message said that it supported only G.729. In that case, the 183 message from CallManager to the phone would list only G.729. It would also list the IP address of GW-B as the originator address in SDP field 'c.' When the analog phone picks up, GW-B sends a 200 OK message containing its SDP information. CallManager acknowledges it with an ACK that contains the SDP information that both endpoints support. The IP address of the SIP phone is also included as the originator address in the SDP field 'c.' CallManager sends a 200 OK message with SDP information to the phone. The phone acknowledges that message. Now that each endpoint has the IP address of the other, the two can establish an RTP stream between them for the duration of the call. In Figure 4-4, the analog phone hangs up, so GW-B sends a SIP BYE method to CallManager. CallManager replies with a 200 OK response and then sends a BYE to the SIP phone. The phone responds with a 200 OK message. Madhunath Yadav
BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

4.

5.

6. 7. 8.

Telecom Protocols

Internal Use Only

SIP Pros and Cons

People have high expectations for SIP. They hope it will enable advanced, anywhere, anytime multimedia communication. However, SIP is basically just another call control protocol, with its pros and cons. The following sections list a few of each.

Pros
SIP works independently of the type of session, or the media used, giving it flexibility. It is an open standard, allowing multivendor support and integration. Applications can be written to customize SIP uses. SIP messages are clear text, making troubleshooting easier. SIP can accommodate multiple users with differing capabilities. For instance, in a conference that has some users with video capability and some only with audio capability, the video users can see each other. They do not have to drop down to audio only, as with other protocols.

Cons
Processing text messages puts a higher load on gateways. The router must translate that text into a language that the router can understand. Code for this must be in the Cisco IOS. SIP is a fairly new protocol, so fewer people understand it than the older protocols. Be sure you have trained support personnel if you intend to implement SIP within your network. When you are using both SIP and SCCP phones on the same network, you must convert between in-band and out-of-band DTMF tones. SIP features are still being developed, and many vendors have proprietary implementations of the protocol.

When to Use SIP

SIP is the protocol of choice when you want to integrate multiple types of media. For example, perhaps you get an instant message on your phone screen that you want to respond to verbally. You start to press the button to call the IM sender, but you see that the sender has set his status to "Don't call me," so you refrain. Later, you would like to have a videoconference with three other people, but you notice that one of them has his phone off-hook. The other two join you, one as video and the other as audio only. You send a text message to the IP phone of the third person, asking him to join when he can. This might sound like the office of the future, but it is becoming reality. You can use SIP trunks even without native SIP phones. You might choose them because of the simple session setup mechanism for SIP. For instance, you can use a SIP trunk between gateways with toll bypass. When you use SIP with Call Manager or CME, you are not limited to Cisco-brand IP phones. You can also use other commercially available, and perhaps lower-priced, SIP phones. Be aware that Call Manager might not be able to provide all the features for these phones that it can for a Cisco-brand SIP phone. Before you implement a SIP network, plan its integration into your existing network. Determine exactly what you want to accomplish and how you will accomplish it. Remember also that you need to either find people who are knowledgeable about SIP or train your staff.

Dial Plan Considerations

SIP dial plan considerations are similar to those for an H.323 gateway, because dial peers control gateway call routing. You must configure dial peers to forward calls out of the gateway. You can forward calls to Call Manager using a Voice over Internet Protocol (VoIP) dial peer, to the PSTN as a plain old telephone service (POTS) dial peer, to another gateway using a VoIP dial peer, or to directly connected voice ports as POTS dial peers. In a voice network that has Call Manager and SIP gateways, it is important to understand the interaction between the two, because different versions of Call Manager have different SIP capabilities. Call Manager versions before 5.x can only have a SIP trunk to a gateway or other servers. Call Manager 5.x and above also acts as a SIP B2BUA and allows SIP phones to register to it. It also can do domain routing for SIP calls. A new menu, SIP Route Pattern, allows you to configure SIP URI dialing. Therefore, your dial plan must take into account the Call Manager version. No matter which version of Call Manager you use, you configure a dial plan to send calls to the SIP trunk when needed. Call Manager appears to the SIP gateway as a SIP-enabled VoIP dial peer. Another consideration in SIP networks is where the dial plan will reside. The default behavior of SIP is to push down the dial plan to each endpoint. When a user dials digits on the phone, the phone compares those numbers against its internal dial plan. If the phone finds a match, Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

it sends an INVITE. Otherwise, it must wait for the inter digit timer to expire before playing a reorder tone. The alternative is to use the Key Press Markup Language (KPML). When you use KPML, the SIP phone sends each digit to Call Manager, similar to the way SCCP phones behave. Call Manager can instruct the phone to play a reorder tone immediately if an incorrect number is dialed, or it can route the call as soon as enough digits are dialed. If you do not use KPML, you must configure SIP dial rules. In your dial planning, consider the need to configure the gateway for such options as number translations or other digit manipulations, or call restrictions. If you are using SRST, be sure that the dial plan will work both with and without Call Manager and, if possible, any SIP servers in the network. You need at least one dial peer with a destination pattern for routing outgoing calls. Default incoming POTS and VoIP dial peers are available, but you should specifically configure dial peers for incoming calls if you need a non default configuration. As with H.323, SIP gateway configuration can become complex in a large network. You must configure each gateway with the information you need to route calls. Proxy, registrar, redirect, and DNS servers can help the network scale by providing dial plan resolution. This simplifies the gateway configuration.

Implementing SIP Gateways

Configuring a SIP gateway can be as simple as configuring SIP VoIP dial peers or as complex as tweaking SIP settings and timers. Gateway SIP configuration is done in three basic places: on dial peers, under SIP UA configuration mode, and under voice service VoIP configuration mode. The following sections discuss the types of configuration you can accomplish in each mode.

SIP Dial Peer Configuration

A basic SIP gateway configuration consists of simply adding one line under a VoIP dial peer configuration: session protocol sipv2. You can use additional dial peer settings; the exact options and commands vary by Cisco IOS version. For instance, to allow SIP calls to be hairpinned from one VoIP dial peer to the other, use the redirect ip2ipcommand. SIP supports both consultative and blind call transfers from Cisco gateways. It also supports call forwarding from IP phones that are registered with the gateway as e-phones. This capability is enabled per dial peer with the application session command in dial-peer configuration mode. To change the transport protocol (UDP is the default), use the session transport [udp |tcp] command. SIP can switch from using UDP to TCP when a voice packet gets within 200 bytes of the maximum transmission unit (MTU) to avoid UDP fragmentation. To configure this for a specific dial peer, use the voice-class sip transport switch udp tcpcommand. You can also configure this globally under voice service configuration mode. Example 4-7 shows the configuration of two SIP dial peers. On the first dial peer, the transport protocol is changed from the default UDP to TCP (an optional step). On the second dial peer, the configuration shows enabling switching from UDP to TCP for large packets. Example 4-7. Configuring a SIP Dial Peer
SIP-GW(config)#dial-peer voice 3401 voip SIP-GW(config-dial-peer)#session target ipv4:10.6.2.1 SIP-GW(config-dial-peer)#session protocol sipv2 SIP-GW(config-dial-peer)#session transport tcp ! SIP-GW(config)#dial-peer voice 4404 voip SIP-GW(config-dial-peer)#session target ipv4:10.7.1.1 SIP-GW(config-dial-peer)#session protocol sipv2 SIP-GW(config-dial-peer)#voice-class sip transport switch udp tcp SIP-GW(config-dial-peer)#destination-pattern 4404...

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

SIP UA Configuration
The SIP UA does not require configuration to function, but you might want to make some adjustments. Enter UA configuration mode by issuing the sip-ua command. As with dial peers, the options vary by Cisco IOS and device. Table 4-2 shows some common UA commands. Table 4-2. SIP UA Commands
Command calling-info max-forwards number nat retry Description Controls the calling ID treatment for calls to and from the PSTN. Configures the maximum hops for SIP methods. Values are 170; default is 70. Configures NAT traversal settings. Controls the number of times that a SIP message will be sent. Options include the following: byeDefault is 10. cancelDefault is 10. cometDefault is 10. inviteDefault is 6. notifyDefault is 10. prackDefault is 10. referDefault is 10. registerDefault is 10. rel1xxDefault is 6. responseDefault is 6. subscribeDefault is 10.

registrar {dns: address |ipv4: destinationaddress}[expires seconds][tcp][secondary] sip-server {dns:[host-name] |ipv4: ip-addr[:port-num]}

Allows a gateway to register the E.164 numbers of non-SIP phones with a registrar or proxy server. Specifies the name or IP address of a SIP server, usually a proxy server. When you use this, you can configure the dial-peer session target as session target sipserver. Changes SIP signaling timers. Options include the following: connectTime to wait for a 200 response to an ACK. Default is 500 ms. disconnectTime to wait for a 200 response to a BYE. Default is 500 ms. expiresValid time for an INVITE. Default is 180,000 ms. registerTime that UA waits before sending REGISTER message. Default is 500 ms. tryingTime to wait for a 100 response to an INVITE. Default is 500 ms.

timers

[no] transport {udp | tcp}

Configures the SIP UA to listen for messages on port 5060 of either UDP or TCP. Both are enabled by default.

Example 4-8 shows a SIP UA configuration. The gateway is configured to register its analog phones with redundant servers, the IP address of the proxy server is specified, the maximum number of hops for SIP methods is reduced to 10, and the gateway is limited to listening for TCP SIP messages. The configuration is partially verified by using the show sip-ua status command. The configured E.164 phone number registration is verified with the show sip-ua register status command. Example 4-8. SIP UA Configuration SIP-GW(config)#sip-ua SIP-GW(config-sip-ua)#registrar ipv4:10.30.25.250 tcp SIP-GW(config-sip-ua)#registrar ipv4:10.30.25.251 tcp secondary SIP-GW(config-sip-ua)#sip-server ipv4:10.30.25.252 SIP-GW(config-sip-ua)#max-forwards 10

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols
SIP-GW(config-sip-ua)#no transport udp ! SIP-GW#show sip-ua status SIP User Agent Status SIP User Agent for UDP : DISABLED SIP User Agent for TCP : ENABLED SIP User Agent bind status(signaling): DISABLED SIP User Agent bind status(media): DISABLED SIP early-media for 180 responses with SDP: ENABLED SIP max-forwards : 10 SIP DNS SRV version: 2 (rfc 2782) NAT Settings for the SIP-UA Role in SDP: NONE Check media source packets: DISABLED Maximum duration for a telephone-event in NOTIFYs: 1000 ms SIP support for ISDN SUSPEND/RESUME: ENABLED Redirection (3xx) message handling: ENABLED Reason Header will override Response/Request Codes: DISABLED

Internal Use Only

SDP application configuration: Version line (v=) required Owner line (o=) required Timespec line (t=) required Media supported: audio image Network types supported: IN Address types supported: IP4 Transport types supported: RTP/AVP udptl ! SIP-GW#show sip-ua register status Line peer expires(sec) registered ============ ============= ============ =========== 4101 20001 118 yes 4102 20003 118 yes

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols
4103 20005 118 yes 4104 20007 118 yes

Internal Use Only

SIP Voice Service Configuration

The voice service configuration mode is used for voice-related commands that affect the entire gateway. Enter this mode by issuing the voice service voip command. In this mode, you can allow hairpinned calls for all dial peers with the redirect ip2ip command. (You can also issue this command under dial-peer configuration mode. Then it affects only those dial peers.) You can enter the SIP submode with the sip command from voice service mode. You can do several SIP-specific configurations from this mode. Table 4-3 lists some of these; specific options vary by Cisco IOS version and device. Table 4-3. SIP Voice Service Configuration Commands Command bind {all |control |media}source-interfaceinterface-id call service stop [forced] min-seseconds redirect contact order [best-match |longest-match] Description Sets the source IP address for control signaling or media, or both. Stops the SIP service. Active calls are not affected unless the forcedoption is used. Changes the SIP session expiration timer. Default (and recommended) value is 1800 sec. In the event of a timer mismatch, the higher value is used. Sends a SIP 300 Redirect message listing all the routes in the Contact header when the gateway knows of multiple routes to a destination. This command controls the order in which the routes are listed. Longest-match is default; it puts routes in order of number of digits matched in its destination patterns. Best-match uses the current system configuration. Configures the gateway to act as a registrar server; used when SRST is active. Globally configures either TCP or UDP as the transport protocol. Controls the maximum number of subscriptions accepted or originated by the gateway. Default is twice the number of dial peers configured on the gateway. Enables the router to use TCP instead of UDP when a SIP message exceeds the MTU size.

registrar server[expires[maxseconds] [minseconds]] session transport{tcp | udp} subscription maximum{accept |originate}number transport switch udp tcp

Example 4-9 shows a gateway that has been configured to hair-pin calls for all dial peers. The source IP address for all SIP signaling traffic has been set to Loopback 0, and this gateway has been configured to act as a registrar server. You can verify the interface binding with the show sip-ua status command. Example 4-9. SIP Voice Service Configuration SIP-GW(config)#voice service voip SIP-GW(conf-voi-serv)#redirect ip2ip SIP-GW(conf-voi-serv)#sip SIP-GW(conf-serv-sip)#bind control source-interface lo0 SIP-GW(conf-serv-sip)#registrar server expires max 1500 min 500

Toll Bypass
You use toll bypass to send calls between different sites over a packet network rather than over the PSTN. Because this bypasses the PSTN, it also bypasses any long-distance toll charges. Cisco routers, functioning as edge gateways, can use SIP to pass voice traffic between them. This traffic is typically from analog phones, such as those connected to a PBX, but it can be from IP or SIP phones. Figure 4-1 shows this type of setup. Configuring the routers for toll bypass involves two components. First, you must configure connection(s) to the internal voice network. This might be a PRI to a PBX, for instance. You must configure both the physical links and the appropriate dial peers. Second, you must configure

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

the connection to the other router. This involves configuring the physical link and at least one SIP VoIP dial peer pointing to the remote SIP router. You configure the dial peers and gateways as detailed in the previous sections of this chapter.

Registering with CallManager

CallManager versions 4.x can register a SIP trunk connecting to a remote gateway, a proxy server, or CallManager Express. The trunk is referred to as a signaling interface. CallManager 5.x can register SIP phones, in addition to SIP trunks. Trunks can point to other Cisco CallManager clusters, also.

Securing SIP Gateways

Your SIP gateway, as part of your IP network, should conform to your company security policy. Deployment of basic items, such as user control and authentication, access-control lists, and physical security, should be standard. The SIP network, like most of your user devices, should be on a LAN using private IP addresses, with strong perimeter security. Because SIP messages contain IP addresses in several different locations, it is important to use a firewall that supports SIP. Cisco IOS firewalls, PIX firewalls, and Adaptive Security Appliance (ASA) devices are all able to inspect the SIP application data and maintain call flow information. SIP supports some authentication, authorization, and accounting (AAA) mechanisms to help authenticate communications between UAs, servers, and gateways. You can use RADIUS to preauthenticate calls. The gateway forwards incoming call information to a RADIUS server, which must authenticate it before connecting the call. To enable AAA for SIP calls, you must use the normal AAA configuration on the gateway and the RADIUS server. In addition, at global configuration mode, issue the aaa preauth command to enter AAA preauthentication configuration mode. Specify the RADIUS server with the command group {radius | groupname}. You can also use HTTP Authentication Digest. UAs, proxy servers, and redirect servers can request authentication before they process a SIP message. Gateways can respond to authentication challenges and can respond on behalf of non-SIP phones that they have registered to a SIP server. SIP defines authentication and authorization fields that can be present in the message header. A server that receives a messagesuch as an INVITEwithout authentication credentials issues a challenge. The response includes an authorization field with an MD5 hash and other credentials. To configure a gateway to use HTTP Authentication Digest, give the following command in each dial peer or SIP-UA configuration mode: authentication username username password password [realmrealm]. Username is the name of the user that will be authenticating, password is the shared password, and realm is an optional entry that lets you configure multiple username/password combinations. The realm is included in the challenge, so the response will include credentials for that specific realm. To provide a more secure, encrypted transport mechanism for SIP messages, Cisco IPT devices have added support for the TLS protocol. Allowing H.323 to SIP Connections SIP and H.323 dial peers can be configured on the same gateway, but call routing between the two types of dial peers is disabled by default. To enable this routing, enter voice service configuration mode and issue the command allow-connections from-typeto to-type. Options for both the from-type and the to-type are h323 and sip. Example 4-11 shows a router that is configured to allow multiple types of VoIP connections. Example 4-11. Configuring H.323 to SIP Connections H323-SIP-GW(config)#voice service voip H323-SIP-GW (conf-voi-serv)# allow-connections h323 to h323 H323-SIP-GW (conf-voi-serv)# allow-connections h323 to sip H323-SIP-GW (conf-voi-serv)# allow-connections sip to h323 H323-SIP-GW (conf-voi-serv)# allow-connections sip to sip

Troubleshooting Tools
If calls cannot be made between SIP gateways or over SIP trunks, dial peer configuration is one of the first places to check. Make sure that the dial peer is configured to use SIP and that both devices are using the same transport protocol and DTMF relay method. Make sure that destination patterns and session targets are correct, also.

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

Several show commands can troubleshoot and monitor the SIP UA function of the gateway. Example 4-12 lists them; options can vary by Cisco IOS and device. Example 4-12. show sip-ua Command Options SIP-GW#show sip-ua ? calls Display Active SIP Calls connections Display SIP Connections map Display SIP status code to PSTN cause mapping table & vice versa min-se Display Min-SE value mwi Display SIP MWI server info register Display SIP Register status retry Display SIP Protocol Retry Counts service Display SIP submode Shutdown status statistics Display SIP UA Statistics status Display SIP UA Listener Status timers Display SIP Protocol Timers The show sip-ua connections {udp|tcp} command gives you information on active connections, including those with errors. To stop a problem connection, use the clear sip-ua {udp | tcp} [connection id number] [target ipv4: ip-address] command. To ensure that the SIP is enabled on the gateway, use the show sip-ua servicecommand. You should get the following result: SIP-GW#show sip-ua service SIP Service is up The show sip-ua statistics command provides statistics on each type of method and response, errors, and total SIP traffic information. You can reset these counters with theclear sip-ua statistics command. The show sip-ua status command can be useful in troubleshooting, also. Output from this command was shown previously in Example 4-13. To debug SIP messages, use the debug ccsip command. This command has several options, as Example 4-13 shows. Use messages to see the SIP method and response messages, as shown previously in Example 4-1. The media option shows RTP information. Your options might vary by Cisco IOS and device. Example 4-13. debug ccsip Command Options SIP-GW#debug ccsip ? all Enable all SIP debugging traces calls Enable CCSIP SPI calls debugging trace error Enable SIP error debugging trace events Enable SIP events debugging trace info Enable SIP info debugging trace media Enable SIP media debugging trace

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols
messages Enable CCSIP SPI messages debugging trace preauth Enable SIP preauth debugging traces states Enable CCSIP SPI states debugging trace transport Enable SIP transport debugging traces

Internal Use Only

Case Study: Configuring SIP Between a Gateway and CallManager 5.x

In this case study, SIP is being introduced into the New York and Shanghai networks. The locations will use both SIP and SCCP phones, and a SIP trunk will be configured between the New York CallManager cluster and the Shanghai gateway, shown in Figure 4-12. CallManager 5.x is used to register the SIP phones. The preferred DTMF relay method will be SIP-NOTIFY, but RTP-NTE will be accepted as a second choice.

Figure 4-12 SIP Case Study Network Diagram For redundancy, the Shanghai gateway has dial peers to two of the CallManager servers. One CallManager IP address is configured under the UA, to demonstrate that command. The gateway will register its network analog phones with registrar servers at 10.10.10.19 and 10.10.10.20. HTTP digest authentication is configured. All SIP traffic will use interface Fa0/0 as its source IP address. Large packets will switch from UDP to TCP as their transport protocol to avoid UDP fragmentation. Example 4-14 shows the configuration of SIP and the SIP trunk on the Shanghai gateway. POTS dial peers to connect to the PBX are not shown in this example. CallManager configuration is outside the scope of this case study. Example 4-14. SIP Case Study Shanghai-GW(config)#sip-ua Shanghai-GW(config-sip-ua)#sip-server ipv4:10.10.10.11 Shanghai-GW(config-sip-ua)#registrar ipv4:10.10.10.19 Shanghai-GW(config-sip-ua)#registrar ipv4:10.10.10.20 secondary Shanghai-GW(config-sip-ua)#authentication username NYCServ1 password Madhunath Yadav
BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols
C1sc0 realm NYC-SIP ! Shanghai-GW(config)#voice service voip Shanghai-GW(conf-voi-serv)#sip Shanghai-GW(conf-serv-sip)#bind all source-interface fa0/0 Shanghai-GW(conf-serv-sip)#transport switch udp tcp ! Shanghai-GW(config)#dial-peer voice 2121 voip Shanghai-GW(config-dial-peer)#destination-pattern 21255521.. Shanghai-GW(config-dial-peer)#session target sip-server Shanghai-GW(config-dial-peer)#session protocol sipv2 Shanghai-GW(config-dial-peer)#dtmf-relay sip-notify rtp-nte Shanghai-GW(config-dial-peer)#preference 1 ! Shanghai-GW(config)#dial-peer voice 2122 voip Shanghai-GW(config-dial-peer)#destination-pattern 21255521.. Shanghai-GW(config-dial-peer)#session target 10.10.10.12 Shanghai-GW(config-dial-peer)#session protocol sipv2 Shanghai-GW(config-dial-peer)#dtmf-relay sip-notify rtp-nte Shanghai-GW(config-dial-peer)#preference 2

Internal Use Only

Global Title vs. Point Code

Global Title vs. Point Code

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

A Global Title (GT) is an address used in the SCCP protocol for routing signaling messages on telecommunications networks. In theory, a global title is a unique address which refers to only one destination, though in practice destinations can change over time. The Global Title is similar in purpose on the PSTN to the host name on the internet. In design, however, global titles are quite different. The structure is usually hierarchical, the value can be of variable length, and is not necessarily a wholly numeric valuethough it often is for issues of backwards compatibility and association with regular telephone numbers. An SS7 point code is similar to an IP address in an IP network. It is a unique address for a node (Signaling Point, or SP), used in MTP layer 3 to identify the destination of a message signal unit (MSU). In such a message you will find an OPC (Originating Point Code) and a DPC (Destination Point Code); sometimes documents also refer to it as a signaling point code. Depending on the network, a point code can be 24 bits (North America, China), 16 bits (Japan), or 14 bits (ITU standard, International SS7 network and most countries) in length. For example Global titles belong to your mobile network looks like your mobile number: +xx248283828 where xx is your country code

Pont code looks like: 8578, 600 etc. ----------------------------------------------------------BRA or BRI and PRA PRI: BRA (Basic Rate Access): Basic Rate Access is one of two ISDN services. The other is Primary Rate Access (PRA) BRA Provides an ISDN user with simultaneous access to two 64kbps data channel using the existing pair copper telephone cable. Each Data channel is referred to as Bchannel and can carry voice or data and another channel is the D channel operates at 16 kbps and used for signaling to the ISDN. The total data rate of BRA is therefore 144 kbps. The two B-channel and one signaling channel gives rise to the term 2B+D. Basic Rate ISDN is indicated for low capacity uses such as that required PRA (Primary Rate Access) The user interface to an integrated services digital network (ISDN) intended for large business applications in European countries and elsewhere outside of North America and Japan. Also known as 30B+D, PRA offers 30 bearer (B) channels for user payload, plus one data (D) channel for signaling and control, and is backward-compatible with E-1 transmission. Primary rate interface (PRI), the North American version, offers 23 bearer (B) channels, plus one data (D) channel, and is backward-compatible with T1 and J-1 transmission systems. PRI and PRA both provide a full-duplex (FDX) point-to-point connection through an NT2-type intelligent CPE switching device, such as a PBX or router, for interfacing with the central office (CO) switch.The B and D channels are clear channels of 64 kbps, as signaling and control are out-of-band.The B channels can be used individually to connect on demand to any other ISDN device, or multiple B channels can be bonded and treated as a single fast connection for bandwidth-intensive applications such as data file transfers, videoconferencing, and any multimedia combination. Although the D channel is reserved exclusively for signaling and control, those functions are fairly light. ISDN standards, therefore, provide for non-facility associated signaling (NFAS), which allows a D channel to support up to five PRA/PRI circuits.

Integrated Service Digital Network:

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

Integrated Services for Digital Network (ISDN) is a set of communication standards for simultaneous digital transmission of voice, video, data, and other network services over the traditional circuits of the public switched telephone network. Prior to ISDN, the telephone system was viewed as a way to transport voice, with some special services available for data. The key feature of ISDN is that it integrates speech and data on the same lines, adding features that were not available in the classic telephone system. There are several kinds of access interfaces to ISDN defined as Basic Rate Interface (BRI), Primary Rate Interface (PRI), Narrowband ISDN (N-ISDN), and Broadband ISDN (B-ISDN). ISDN is a circuit-switched telephone network system, which also provides access to packet switched networks, designed to allow digital transmission of voice and data over ordinary telephone copper wires, resulting in potentially better voice quality than an analog phone can provide. It offers circuit-switched connections (for either voice or data), and packet-switched connections (for data), in increments of 64 kilobit/s. A major market application for ISDN in some countries is Internet access, where ISDN typically provides a maximum of 128 kbit/s in both upstream and downstream directions. Channel bonding can achieve a greater data rate; typically the ISDN B-channels of three or four BRIs (six to eight 64 kbit/s channels) are bonded. ISDN is employed as the network, data-link and physical layers in the context of the OSI model. ISDN is designed to provide access to voice and data services simultaneously. In a videoconference, ISDN provides simultaneous voice, video, and text transmission between individual desktop videoconferencing systems and group (room) videoconferencing systems.

ISDN Elements:
An integrated service refers to ISDN's ability to deliver at minimum two simultaneous connections, in any combination of data, voice, video, and fax, over a single line. Multiple devices can be attached to the line, and used as needed. That means an ISDN line can take care of most people's complete communications needs (apart from broadband Internet access and entertainment television) at a much higher transmission rate, without forcing the purchase of multiple analog phone lines. It also refers to integrated switching and transmission in that telephone switching and carrier wave transmission are integrated rather than separate as in earlier technology.

Basic Rate Interface:

The entry level interface to ISDN is the Basic(s) Rate Interface (BRI), a 128 kbit/s service delivered over a pair of standard telephone copper wires. The 144 kbit/s payload rate is broken down into two 64 kbit/s bearer channels ('B' channels) and one 16 kbit/s signaling channel ('D' channel or data channel). This is sometimes referred to as 2B+D. The interface specifies the following network interfaces:

The U interface is a two-wire interface between the exchange and a network terminating unit, which is usually the demarcation point in non-North American networks. The T interface is a serial interface between a computing device and a terminal adapter, which is the digital equivalent of a modem. The S interface is a four-wire bus that ISDN consumer devices plug into; the S & T reference points are commonly implemented as a single interface labeled 'S/T' on an Network termination 1 (NT1).

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

The R interface defines the point between a non-ISDN device and a terminal adapter (TA) which provides translation to and from such a device. BRI-ISDN is very popular in Europe but is much less common in North America. It is also common in Japan where it is known as INS64.

Primary Rate Interface:

The other ISDN access available is the Primary Rate Interface (PRI), which is carried over an E1 (2048 kbit/s) in most parts of the world. An E1 is 30 'B' channels of 64 kbit/s, one 'D' channel of 64 kbit/s and a timing and alarm channel of 64 kbit/s. In North America PRI service is delivered on one or more T1 carriers (often referred to as 23B+D) of 1544 kbit/s (24 channels). A PRI has 23 'B' channels and 1 'D' channel for signalling (Japan uses a circuit called a J1, which is similar to a T1). Inter-changeably but incorrectly, a PRI is referred to as T1 because it uses the T1 carrier format. A true T1 (commonly called "Analog T1" to avoid confusion) uses 24 channels of 64 kbit/s of in-band signaling. Each channel uses 56 kb for data and voice and 8 kb for signaling and messaging. PRI uses out of band signaling which provides the 23 B channels with clear 64 kb for voice and data and one 64 kb 'D' channel for signaling and messaging. In North America, Non-Facility Associated Signalling allows two or more PRIs to be controlled by a single D channel, and is sometimes called "23B+D + n*24B". D-channel backup allows for a second D channel in case the primary fails. NFAS is commonly used on a T3. PRI-ISDN is popular throughout the world, especially for connecting PBXs to PSTN. While the North American PSTN can use PRI or Analog T1 format from PBX to PBX, the POTS or BRI can be delivered to a business or residence. North American PSTN can connect from PBX to PBX via Analog T1, T3, PRI, OC3, etc... Even though many network professionals use the term "ISDN" to refer to the lower-bandwidth BRI circuit, in North America BRI is relatively uncommon whilst PRI circuits serving PBXs are commonplace.

Barer Channels:
The bearer channel (B) is a standard 64 kbit/s voice channel of 8 bits sampled at 8 kHz with G.711 encoding. B-Channels can also be used to carry data, since they are nothing more than digital channels. Each one of these channels is known as a DS0. Most B channels can carry a 64 kbit/s signal, but some were limited to 56K because they traveled over RBS lines. This was commonplace in the 20th century, but has since become less so.

signaling channel
The signaling channel (D) uses Q.931 for signaling with the other side of the link.

X.25
X.25 can be carried over the B or D channels of a BRI line, and over the B channels of a PRI line. X.25 over the D channel is used at many pointof-sale (credit card) terminals because it eliminates the modem setup, and because it connects to the central system over a B channel, thereby eliminating the need for modems and making much better use of the central system's telephone lines. X.25 was also part of an ISDN protocol called "Always On/Dynamic ISDN", or AO/DI. This allowed a user to have a constant multi-link PPP connection to the internet over X.25 on the D channel, and brought up one or two B channels as needed.

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,

Telecom Protocols

Internal Use Only

Frame Relay
In theory, Frame Relay can operate over the D channel of BRIs and PRIs, but it is seldom, if ever, used.

Consumer and industry perspectives:

There are two points of view into the ISDN world. The most common is that of the end-user, who wants a digital connection into the telephone network from home, whose performance would be better than a 20th-century analog 56K modem connection. Discussion on the merits of various ISDN modems, carriers' offerings and tariffs (features, pricing) are from this perspective. Since the principal consumer application is for Internet access, ISDN was mostly superseded by DSL in the early 21st century. Inexpensive ADSL service offers speeds up to 5 Mbit/s, while more expensive versions are improving in speed all the time. By 2010, ADSL speeds of several millions of bits per second had become commonplace, thus making ISDN obsolete before it fairly started. There is a second viewpoint: that of the telephone industry, where ISDN is a core technology. A telephone network can be thought of as a collection of wires strung between switching systems. The common electrical specification for the signals on these wires is T1 or E1. Between telephone company switches, the signaling is performed via SS7. Normally, a PBX is connected via a T1 with robbed bit signaling to indicate on-hook or off-hook conditions and MF and DTMF tones to encode the destination number. ISDN is much better because messages can be sent much more quickly than by trying to encode numbers as long (100 ms per digit) tone sequences. This results in faster call setup times. Also, a greater number of features are available and fraud is reduced. ISDN is also used as a smart-network technology intended to add new services to the public switched telephone network (PSTN) by giving users direct access to end-to-end circuit-switched digital services and as a backup or failsafe circuit solution for critical use data circuits.

ISDN and broadcast industry

ISDN is used heavily by the broadcast industry as a reliable way of switching low latency, high quality, long distance audio circuits. In conjunction with an appropriate codec using MPEG or various manufacturers proprietary algorithms, an ISDN BRI can be used to send stereo bi-directional audio coded at 128 kbit/s with 20 Hz 20 kHz audio bandwidth, although commonly theG.722 algorithm is used with a single 64 kbit/s B channel to send much lower latency mono audio at the expense of audio quality. Where very high quality audio is required multiple ISDN BRIs can be used in parallel to provide a higher bandwidth circuit switched connection. BBC Radio 3 commonly makes use of three ISDN BRIs to carry 320 kbit/s audio stream for live outside broadcasts. ISDN BRI services are used to link remote studios, sports grounds and outside broadcasts into the main broadcast studio. ISDN via satellite is used by field reporters around the world. It's also common to use ISDN for the return audio links to remote satellite broadcast vehicles. In many countries, such as the UK and Australia, ISDN has displaced the older technology of equalised analogue landlines, with these circuits being phased out by telecommunications providers. IP based streaming codecs are starting to gain a foothold in the broadcast sector, using broadband internet to connect remote studios. However reliability and latency is crucially important for broadcasters and the quality of service offered by ISDN has not yet been matched by packet switched alternatives. and is today limited to niche business applications with point-to-point requirements.

Madhunath Yadav

BSS Engineer, EDR ZTE NEPAL Pvt. Ltd,