-
Cisco Unified CallManager System Guide, Release 4.2(1)
-
Index
-
Preface
-
Introduction
-
Cisco IP Telephony Overview
-
System Configuration Overview
-
Multilevel Administration
-
System-Level Configuration Settings
-
Clustering
-
Redundancy
-
Call Admission Control
-
Cisco TFTP
-
Device Support
-
Services
-
Auto-Registration
-
Partitions and Calling Search Spaces
-
Time-of-Day Routing
-
Understanding Route Plans
-
Application Dial Rules Overview
-
Understanding the Directory
-
Managing User Directory Information
-
Media Resource Management
-
Annunciator
-
Conference Bridges
-
Transcoders
-
Music On Hold
-
Media Termination Points
-
Cisco DSP Resources for Transcoding, Conferencing, and MTP
-
Voice Mail Connectivity to Cisco CallManager
-
SMDI Voice Mail Integration
-
Cisco Unity Messaging Integration
-
Cisco DPA Integration
-
Call Park and Directed Call Park
-
Call Pickup
-
Cisco IP Phone Services
-
Cisco CallManager Extension Mobility and Phone Login Features
-
Cisco CallManager Attendant Console
-
Cisco IP Manager Assistant
-
Understanding Cisco CallManager Voice Gateways
-
Understanding IP Telephony Protocols
-
Understanding Session Initiation Protocol (SIP)
-
Understanding Cisco CallManager Trunk Types
-
Cisco IP Phones
-
Understanding Video Telephony
-
Computer Telephony Integration (Revised 01/08/2007)
-
Cisco ATA 186 and Cisco ATA 188
-
Administrative Tools Overview
-
Administrative Accounts and Passwords
-
Feedback
Table Of Contents
Understanding Session Initiation Protocol (SIP)
Media Termination Point (MTP) Devices
SIP Functions Supported in Cisco CallManager
Basic Calls Between SIP Endpoints and Cisco CallManager
DTMF Relay Calls Between SIP Endpoints and Cisco CallManager
Forwarding DTMF Digits from SIP Devices to Gateways or Interactive Voice Response (IVR) Systems
Supplementary Services Initiated by SCCP Endpoint
Ringback Tone During Blind Transfer
Supplementary Services Initiated by SIP Endpoint
Enhanced Call Identification Services
Calling Line and Name Identification Presentation
Calling Line and Name Identification Restriction
Connected Line and Name Identification Presentation
Connected Line and Name Identification Restriction
Redirecting Dial Number Identification Service (RDNIS)
SIP Signaling/Trunk Interface Configuration Checklist
Where to Find More Information
Understanding Session Initiation Protocol (SIP)
Understanding Session Initiation Protocol (SIP) describes SIP and the interaction between SIP and Cisco CallManager.
This section covers the following topics:
•
SIP Functions Supported in Cisco CallManager
•
•
SIP Networks
A SIP network uses the following components:
•
•
•
•
SIP uses a request/response method to establish communications between various components in the network and to ultimately establish a call or session between two or more endpoints. A single session may involve several clients and servers.
Identification of users in a SIP network works through
•
•
Related Topics
•
•
SIP and Cisco CallManager
All protocols require that either a signaling interface (trunk) or a gateway be created to accept and originate calls. For SIP, the user must create a signaling interface. For more information, refer to the Trunk Configuration section in the Cisco CallManager Administration Guide.
SIP signaling interfaces connect Cisco CallManager networks and SIP networks that are served by a SIP proxy server. As with other protocols, SIP components fit under the device layer of Cisco CallManager architecture. As is true for the H.323 protocol, multiple logical SIP signaling interfaces can be configured in the Cisco CallManager database and associated with route groups, route lists, and route patterns. To provide redundancy, in the event of failure of one logical SIP interface, other logical SIP interfaces provide services in the same route group list. Redundancy can also be achieved by assigning multiple Cisco CallManager modes under SIP signaling interface device pools.
SIP signaling interfaces use port-based routing, with one SIP signaling interface connecting to a SIP network. Cisco CallManager accepts calls from any SIP device as long as the SIP messages arrive on the configured incoming port. When configuring multiple signaling interfaces, configure a unique incoming port for each SIP interface. Use of the same port as an incoming port for multiple signaling interfaces causes an alarm.
Figure 38-1 SIP and Cisco CallManager Interaction
Related Topics
•
Media Termination Point (MTP) Devices
Cisco CallManager requires an RFC 2833 dual tone multifrequency (DTMF) compliant MTP device to make SIP calls. The current standard for SIP uses in-band Real-Time Transport Protocol (RTP) payload types to indicate DTMF tones. Cisco components such as SCCP IP phones, support only out-of-band DTMF payload types. Thus, an RFC 2833 compliant MTP device acts as a translator between inband and out-of-band DTMF.
Related Topics
•
SIP Functions Supported in Cisco CallManager
Cisco CallManager supports the following functions and features for SIP calls:
•
•
•
•
•
•
Basic Calls Between SIP Endpoints and Cisco CallManager
This section includes three basic calling scenarios. Two describe incoming and outgoing calls, while the other one describes the use of early media - a media connection prior to the connection or answer of a call.
Basic Outgoing Call
You can initiate outgoing calls to a SIP device from any Cisco CallManager device. A Cisco CallManager device includes SCCP IP Phones or fax devices that are connected to Foreign Exchange Station (FXS) gateways. For example, an SCCP IP Phone can place a call to a SIP endpoint. The SIP device answering the call triggers media establishment.
Basic Incoming Call
Any device on the SIP network, including SIP IP Phones or fax devices that are connected to FXS gateways can initiate incoming calls. For example, a SIP endpoint can initiate a call to an SCCP IP Phone. The SCCP IP Phone answering the call triggers media establishment.
Use of Early Media
While the PSTN provides inband progress information to signal early media (such as a ring tone or a busy signal), the same does not hold true for SIP. The originating party includes Session Description Protocol (SDP) information, such as codec usage, IP address, and port number, in the outgoing INVITE message. In response, the terminating party sends its codec, IP address, and port number in a 183 Session Progress message to indicate possible early media.
The 183 Session Progress response indicates that the message body contains information about the media session. Both 180 Alerting and 183 Session Progress messages may contain SDP, which allows an early media session to be established prior to the call being answered.
When early media needs to be delivered to SIP endpoints prior to connection, Cisco CallManager always sends a 183 Session Progress message with SDP. While Cisco CallManager does not generate a 180 Alerting message with SDP, it does support the 180 Alerting message with SDP when it receives one.
Related Topics
•
DTMF Relay Calls Between SIP Endpoints and Cisco CallManager
Based on RFC 2833, the current standard for SIP uses in-band payload types to indicate DTMF tones. Cisco components such as SCCP IP phones do not support in-band payload types. An RFC 2833 compliant MTP device monitors for payload type and translates between inband and out-of-band payload types.
The following call flows show how Cisco CallManager processes DTMF digits:
•
Forwarding DTMF Digits from SIP Devices to Gateways or Interactive Voice Response (IVR) Systems
The following example shows the MTP software device processing inband DTMF digits from the SIP Phone to communicate with the Primary Rate Interface (PRI) gateway. The RTP stream carries RFC 2833 DTMF, as indicated by a dynamic payload type.
Figure 38-2 Forwarding DTMF Digits
Figure 38-2 begins with media streaming, and the MTP device has been informed of the DTMF dynamic payload type.
1.
2.
3.
Generating DTMF Digits
As discussed in DTMF Relay Calls Between SIP Endpoints and Cisco CallManager, SIP sends DTMF in-band digits, while Cisco CallManager only supports out-of-band digits. The software MTP device receives the DTMF out-of-band tones and generates DTMF inband tones to the SIP client.
Figure 38-3 Generating DTMF Digits
Figure 38-3 begins with media streaming, and the MTP device has been informed of the dynamic DTMF payload type.
1.
2.
3.
Related Topics
•
Supplementary Services Initiated by SCCP Endpoint
All supplementary services initiated by an SCCP endpoint during a SIP call are supported. SCCP endpoints are internally managed by Cisco CallManager without affecting the connecting SIP device. Any changes to the original connecting information are updated with re-INVITE messages that use the Remote-Party-ID header. Refer to SIP Extensions for Caller Identity and Privacy for more information on the Remote-Party-ID header.
The following section, Ringback Tone During Blind Transfer, describes a blind transfer, which is unique as a supplementary service because it requires Cisco CallManager to provide a media announcement.
Ringback Tone During Blind Transfer
For SCCP-initiated blind transfers, Cisco CallManager needs to generate tones or ringback after a call has already connected. In other words, Cisco CallManager provides a media announcement for blind transfers.
A blind transfer works when the transferring phone connects the caller to a destination line before the target of the transfer enters the call. A blind transfer differs from a consultative, or attended, transfer in which one transferring party either connects the caller to a ringing phone (ringback received) or speaks with the third party before connecting the caller to the third party
Blind transfers that are initiated from an SCCP IP Phone allow ringback to the original, connected SIP device user. To accomplish ringback, Cisco CallManager uses an annunciator software device that is often located with an MTP device.
With an annunciator, Cisco CallManager can play predefined tones and announcements to SCCP IP Phones, gateways, and other IP telephony devices. These predefined tones and announcements provide users with specific information on the status of the call.
Related Topics
•
Supplementary Services Initiated by SIP Endpoint
The following sections describe supplementary services initiated by a SIP endpoint.
SIP-Initiated Call Transfer
Cisco CallManager does not support SIP-initiated call transfer and does not accept receiving REFER requests or INVITE messages that include a Replaces header. When Cisco CallManager receives a REFER request, it returns a 501 Not Implemented message. When Cisco CallManager receives an INVITE message with a Replaces header, it processes the call and ignores the Replaces header.
Call Hold
Cisco CallManager supports call hold and retrieve that a SIP device initiates or that a Cisco CallManager device initiates. For example, when a SCCP IP Phone user retrieves a call that was placed on hold by another user, Cisco CallManager sends a re-INVITE message to the SIP proxy. The re-INVITE message contains updated Remote-Party-ID information to reflect the current connected party. If Cisco CallManager originally initiated the call, the Party field in the Remote-Party-ID header gets set to calling; otherwise, it gets set to called. For more information on the Party field parameter, refer to Enhanced Call Identification Services.
Call Forward
Cisco CallManager supports call forward that a SIP device initiates or that a Cisco CallManager device initiates. With call forwarding redirection requests from SIP devices, Cisco CallManager processes the requests. For call forwarding initiated by Cisco CallManager, no SIP redirection messages are used. Cisco CallManager handles redirection internally then conveys the connected party information to the originating SIP endpoint through the Remote-Party-Id header.
Related Topics
•
Enhanced Call Identification Services
This section describes the following SIP identification services in Cisco CallManager and how Cisco CallManager conveys these identification services in the SIP:
•
–
–
•
–
–
Cisco CallManager provides flexible configuration options to provide these identification services either on a call-by-call basis or statically preconfigured for each SIP signaling interface.
Calling Line and Name Identification Presentation
Cisco CallManager includes the calling line (or number) and name presentation information in the From and Remote-Party-ID headers of the initial INVITE message from Cisco CallManager. The From header field indicates the initiator of the request. Cisco CallManager uses Remote-Party-ID headers in 18x, 200 and re-INVITE messages to convey connected name and identification information. The Remote-Party-ID header also gives detailed descriptions of caller identity and privacy. Cisco CallManager sets the Party field of the Remote-Party-ID header to calling for calling ID services.
Note
Example:
Bob Jones (with external phone number=8005550100) dials out to a SIP signaling interface; the From and Remote-Party-ID headers contain
From: "Bob Jones" <sip:8005550100@localhost>Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=calling;screen=no;privacy=offCalling Line and Name Identification Restriction
Calling line (or number) and name restrictions configuration occurs on the SIP signaling interface level or on a call-by-call basis. The SIP trunk level configuration takes precedence over the call-by-call configuration. To configure on a call-by-call basis, refer to the Route Group Configuration in the Cisco CallManager Administration Guide.
Calling line and name restrictions configuration also occurs independently of each other. For example, you may choose to restrict only numbers and allow names to be presented.
Example 1
With a restricted calling name, Cisco CallManager sets the calling name in the From header to a configurable string. Cisco CallManager sets the display field in the Remote-Party-ID header to include the actual name but sets the Privacy field to name:
From: "Anonymous" <sip:8005550100@localhost>Remote-Party-ID: "Bob Jones"<9728135001@localhost; user=phone>; party=calling;screen=no;privacy=nameExample 2
With a restricted calling number, Cisco CallManager leaves out the calling line in the From header; however, Cisco CallManager still includes the calling line in the Remote-Party-ID header but sets the Privacy field to privacy=uri:
From: "Bob Jones" <sip:@localhost>Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=calling;screen=no;privacy=uriExample 3
With a restricted calling name and number, Cisco CallManager sets the Privacy field to privacy=full in the Remote-Party-ID header:
From: "Anonymous" <sip:localhost>Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=calling;screen=no;privacy=fullConnected Line and Name Identification Presentation
Cisco CallManager uses connected line and name identification as a supplementary service to provide the calling party with the connected party's number and name. The From header field indicates the initiator of the request. Cisco CallManager uses Remote-Party-ID headers in 18x, 200 and re-INVITE messages to convey connected information. Cisco CallManager sets the Party field of Remote-Party-ID header to called.
Example 1
Cisco CallManager receives an INVITE message with a destination address of 800555. Cisco CallManager includes the connected party name in 18x and 200 messages as follows:
Remote-Party-ID: "Bob Jones"<98005550100@localhost; user=phone>; party=called;screen=no;privacy=offConnected Line and Name Identification Restriction
You can configure connected line (or number) and name restrictions on the SIP trunk level or on a call-by-call basis. The SIP trunk level configuration takes precedence over the call-by-call configuration. To configure on a call-by-call basis, refer to the Route Group Configuration in the Cisco CallManager Administration Guide.
Similar to Calling ID services, users can restrict connected number and name independently of each other.
Example 1
Cisco CallManager sets the display field in the Remote-Party-ID header to include the actual name, but sets the Privacy field to privacy=name:
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=called;screen=no;privacy=nameExample 2
With a restricted connected number, Cisco CallManager still includes the connected number in the Remote-Party-ID header but sets the Privacy field to privacy=uri:
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=called;screen=no;privacy=uriExample 3
With a restricted connected name and number, Cisco CallManager sets the Privacy field to privacy=full in the Remote-Party-ID header:
Remote-Party-ID: "Bob Jones"<8005550100@localhost; user=phone>; party=called;screen=no;privacy=fullRelated Topics
•
Redirecting Dial Number Identification Service (RDNIS)
Cisco CallManager uses the SIP Diversion header in the initial INVITE message to carry available RDNIS information.
Related Topics
•
SIP Service Parameters
SIP timers and counters can be individually configured for functionality on different servers. Refer to the Service Parameter Configuration chapter in the Cisco CallManager Administration Guide for full information on how to configure service parameters.
SIP Timers and Counters
SIP timers and counters are configurable service parameters. The following tables describe the various SIP timers and counters and give their default values and range values:
Note
Related Topics
•
SIP Signaling/Trunk Interface Configuration Checklist
Table 38-3 provides an overview of the steps that are required to configure SIP signaling/trunk interfaces in Cisco CallManager, along with references to related procedures and topics.
Table 38-3 Trunk Configuration Checklist
Step 1
Create a SIP trunk.
For outgoing calls, configure the destination address (the address of the SIP Proxy Server).
Configure the destination port.
Configure a unique incoming port for each SIP interface.
Adding a Trunk, Cisco CallManager Administration Guide
Trunk Configuration Settings, Cisco CallManager Administration Guide
Step 2
Verify the RFC 2833 compliant MTP device is configured.
Trunk Configuration Settings, Cisco CallManager Administration Guide
In the trunk configuration, the MTP field is always checked. SIP requires an RFC 2833 compliant MTP device. For more information on MTP, see Media Termination Point Configuration, Cisco CallManager Administration Guide.
Step 3
Assign to a Route Pattern, Route Group, or Route List, if needed.
Route Pattern Configuration,Cisco CallManager Administration Guide
Route Group Configuration, Cisco CallManager Administration Guide
Route List Configuration, Cisco CallManager Administration Guide
Step 4
Configure SIP timers, counters, and service parameters, if necessary.
Service Parameters Configuration, Cisco CallManager Administration Guide.
For specific configurable values, see SIP Service Parameters.
Step 5
Verify the Annunciator is active, if necessary.
Annunciator Configuration, Cisco CallManager Administration Guide.
Step 6
If a SIP Proxy server is used as the destination address, configure static routes to point to all IP addresses or domain names of the SIP interface Call Manager Group.
Trunk Configuration Settings, Cisco CallManager Administration Guide
The device pool field can be an IP address, fully-qualified domain name (FQDN), or DNS SRV name.
Related Topics
•
•
Where to Find More Information
Related Topics
•
•
•
•
Additional Cisco Documentation
•
