-
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 IP Telephony Protocols
Media Gateway Control Protocol (MGCP)
Skinny Client Control Protocol (SCCP)
Session Initiation Protocol (SIP)
Channel Associated Signaling (CAS)
T1 Primary Rate Interface (T1 PRI)
E1 Primary Rate Interface (E1 PRI)
Annex M.1 (Message Tunneling for QSIG)
Compatibility with Older Versions of QSIG Protocol (ECMA)
Facility Selection and Reservation
Message Waiting Indication (MWI) Service
QSIG Interface to Cisco CallManager
Where to Find More Information
Understanding IP Telephony Protocols
Understanding IP Telephony Protocols briefly describes some of the different protocols and their interaction with Cisco CallManager.
This section covers the following topics:
•
Where to Find More Information
IP Protocols
Cisco CallManager performs signaling and call control tasks such as digit analysis, routing, and circuit selection within the PSTN gateway infrastructure. To perform these functions, Cisco CallManager uses industry standard IP protocols including H.323, MGCP, SCCP, and SIP. Use of Cisco CallManager and these protocols gives service providers the capability to seamlessly route voice and data calls between the PSTN and packet networks.
Four IP protocols are discussing in this section:
•
•
•
H.323 Protocol
The International Telecommunications Union (ITU) developed the H.323 standard for multimedia communications over packet networks. As such, the H.323 protocol is a proven ITU standard and provides multivendor interoperability. The H.323 protocol specifies all aspects of multimedia application services, signaling, and session control over an underlying packet network. Audio is standard on H.323 networks, but networks can be scaled to include both video and data. The H.323 protocol can be implemented in large enterprise networks or can be deployed over an existing infrastructure, which makes H.323 an affordable solution.
The basic components of the H.323 protocol are terminals, gateways, and gatekeepers (which provide call control to H.323 endpoints). Similar to other protocols, H.323 applies to point-to-point or multipoint sessions. However, compared to MGCP, H.323 requires more configuration on the gateway.
For more information, refer to the following topics:
•
•
•
•
•
Media Gateway Control Protocol (MGCP)
MGCP provides Cisco CallManager a powerful, flexible and scalable resource for call control. Cisco CallManager uses MGCP to control media on the telephony interfaces of a remote gateway and also uses MGCP to deliver messages from a remote gateway to appropriate devices.
MGCP enables a call agent (media gateway controller) to remotely control and manage voice and data communication devices at the edge of multiservice IP packet networks. Because of its centralized architecture, MGCP simplifies the configuration and administration of voice gateways and supports multiple (redundant) call agents in a network. MGCP does not provide security mechanisms such as message encryption or authentication.
Using MGCP, Cisco CallManager controls call processing and routing and provides supplementary services to the gateway. The MGCP gateway provides call preservation (the gateway maintains calls during failover and fallback), redundancy, dial-plan simplification (the gateway requires no dial-peer configuration), hookflash transfer, and tone on hold. MGCP-controlled gateways do not require a media termination point (MTP) to enable supplementary services such as hold, transfer, call pickup, and call park. If the MGCP gateway loses contact with its Cisco Call Manager, it falls back to using H.323 control to support basic call handling of FXS, FXO, T1 CAS, and T1/E1 PRI interfaces.
For more information, refer to the "Adding a Cisco IOS MGCP Gateway" section in the Cisco CallManager Administration Guide.
Related Topics
•
•
Skinny Client Control Protocol (SCCP)
SCCP uses Cisco-proprietary messages to communicate between IP devices and Cisco CallManager. SCCP easily coexists in a multiple protocol environment. The Cisco IP Phone is an example of a device that registers and communicates with Cisco CallManager as an SCCP client. During registration, a Cisco IP phone receives its line and all other configurations from Cisco CallManager. Once it registers, it is notified of new incoming calls and can make outgoing calls. The SCCP protocol is used for VoIP call signaling and enhanced features such as Message Waiting Indication (MWI).
The Cisco VG248 gateway is another example of a device that registers and communicates with Cisco CallManager by using SCCP. For more information, on the Cisco VG248 gateway refer to the "Adding a Cisco VG248 Analog Phone Gateway"section in the Cisco CallManager Administration Guide.
Related Topics
•
•
Session Initiation Protocol (SIP)
The Internet Engineering Task Force (IETF) developed the SIP standard for multimedia calls over IP. ASCII-based SIP works in client/server relationships as well as in peer-to-peer relationships. SIP uses requests and responses to establish, maintain, and terminate calls (or sessions) between two or more end points. Refer to the Understanding Session Initiation Protocol (SIP) chapter for more information on SIP and the interaction between SIP and Cisco Call Manager.
Related Topics
•
•
Analog Telephony Protocols
Analog telephony signaling, the original signaling protocol, provides the method for connecting or disconnecting calls on analog trunks. By using direct current (DC) over two-wire or four-wire circuits to signal on-hook and off-hook conditions, each analog trunk connects analog endpoints or devices such as a PBX or analog phone.
To provide connections to legacy analog central offices and PBXs, Cisco CallManager uses analog signaling protocols over analog trunks that connect voice gateways to analog endpoints and devices . Cisco CallManager supports these types of analog trunk interfaces:
•
•
You can configure loop-start, ground-start, or E&M signaling protocols for FXO and FXS trunk interfaces depending on the gateway model that is selected. You must use the same type of signaling on both ends of the trunk interface to ensure that the calls properly connect. The following sections describe the types of analog signaling protocols that Cisco CallManager supports:
•
Loop-Start Signaling
Loop-start signaling sends an off-hook signal that starts a call and an on-hook signal that closes the loop and ends the call. Loop-start trunks lack positive disconnect supervision, and users can experience glare when two calls seize the trunk at the same time.
Related Topics
•
Ground-Start Signaling
Ground-start signaling provides current detection mechanisms at both ends of the trunk to detect off-hook signals. This mechanism permits endpoints to agree on which end is seizing the trunk before it is seized, and minimizes the chance of glare. Ground start provides positive recognition of connects and disconnects and is the preferred signaling method for PBX connections. Some PBXs do not support ground-start signaling, so then you must use loop-start signaling for the trunk interface.
Related Topics
•
E&M Signaling
E&M signaling uses direct current (DC) over two-wire or four-wire circuits to signal to the endpoint or CO switch when a call is in recEive or transMit (E&M) state. E&M signaling uses signals that indicate off-hook and on-hook conditions. When the connection is established, the audio transmission occurs. The E&M signaling type must be the same for both ends of the trunk interface for successful connections. Cisco CallManager supports these types of E&M signaling:
Wink-start signaling—The originating side sends an off-hook signal and waits to receive a wink pulse signal that indicates the receiving end is ready to receive the dialed digits for the call. Wink start is the preferred signaling method because it provides answer supervision. Not all COs and PBXs support wink-start signaling.
Delay-dial signaling—The originating side sends an off-hook signal, waits for a configurable time period, and then checks if the receiving end is on hook. The originating side sends dialed digits when the receiving side is on hook. The delay allows the receiving end to signal when it is ready to receive the call.
Immediate-start signaling—The originating side goes off hook, waits for a finite time period ( for example 200 ms), and then sends the dial digits without a ready signal from the receiving end.
Related Topics
•
Channel Associated Signaling (CAS)
Channel associated signaling (CAS) sends the on hook and off hook signals as bits within the frames on the same channel as the audio transmission. CAS is often referred to as robbed bit signaling because CAS takes bits from the voice channel for signaling. These signals can include supervision, addressing, and tones such as busy tone or dial tone.
You can use T1 CAS and E1 CAS digital trunk interfaces to connect a Cisco CallManager call to a CO, a PBX, or other analog device.
T1 CAS
The T1 CAS trunk interface uses in-band E&M signaling to carry up to 24 connections on a link. Both ends of the T1 link must specify T1 CAS signaling. Cisco CallManager provides the T1 CAS signaling option when you configure ports on some MGCP and H.323 voice gateways and network modules. For more information about supported gateways, see the "Voice Gateway Model Summary" section.
E1 CAS
Some Cisco gateways in H.323 mode can support the E1 CAS trunk interface that provides up to 32 connections on the link. You must configure the E1 CAS signaling interface on the gateway, not in Cisco CallManager Administration. Both ends of the E1 link must specify E1 CAS signaling. For a list of H.323 gateways that support E1 CAS, see the "Voice Gateway Model Summary" section. Refer to documentation for the specific gateway for configuration information.
Related Topics
Digital Telephony Protocols
Digital telephony protocols use common channel signaling (CCS), a dedicated channel that carries only signals. In a T1 link, one channel carries the signals while the other channels carry voice or data. The latest generation of CCS is known as Signaling System 7 (SS7) and provides supervision, addressing, tones, and a variety of services such as automatic number identification (ANI).
Integrated Services Digital Network (ISDN) is a set of international standards for user access to private or public network services. ISDN provides both circuit-based and packet-based communications to users.
Cisco CallManger can support these ISDN protocols:
•
•
Basic Rate Interface (BRI)
Basic rate interface (BRI) , which is used for small office and home communications links, provides two B-channels for voice and data and one D-channel for signaling.
Related Topics
•
•
T1 Primary Rate Interface (T1 PRI)
T1 Primary rate interface (PRI) is used for corporate communications links in North America and Japan. T1 PRI provides 23 B-channels for voice and data and one D-channel for common channel signaling. T1 PRI uses a communication rate of 1.544Mbps.
Related Topics
•
E1 Primary Rate Interface (E1 PRI)
E1 PRI Primary rate interface (PRI) is used for corporate communications in Europe. E1 PRI provides 30 B-channels for voice and data , one D-channel for common signaling, and one framing channel. E1 PRI uses a rate of 2.048 Mbps.
Related Topics
•
Q.Signaling (QSIG)
Because enterprises maintain existing telecommunication equipment from a variety of vendors, the protocol system, Q signaling (QSIG), provides interoperability and feature transparency between a variety of telecommunications equipment.
The QSIG protocol, a series of international standards, defines services and signaling protocols for Private Integrated Services Networks (PISNs). These standards use Integrated Services Digital Networks (ISDN) concepts and conform to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. The QSIG protocol acts as a variant of ISDN D-channel voice signaling. The ISDN Q.921 and Q.931 standards provides the basis for QSIG protocol, which sets worldwide standard for PBX interconnection.
The QSIG protocol enables Cisco voice switching services to connect to PBXs and key systems that communicate by using QSIG protocol. For QSIG basic call setup, Cisco devices can route incoming voice calls from a private integrated services network exchange (PINX) device across a WAN to a peer Cisco device that can transport the signaling and voice packets to another PINX device, which are PBXs, key systems, or Cisco CallManager servers that support QSIG protocol.
In a basic QSIG call, a user in a PINX can place a call to a user that is in a remote PINX. The called party receives the caller name or number as the call rings. The calling party receives the called name and number when the user phone rings in the remote PINX. All the features that are available as a PBX user operate transparently across the network. QSIG protocol provides supplementary and additional network features, as defined for PISNs, if the corresponding set of QSIG features are supported by both ends of the call.
To make supplementary features available to network users, ensure that all PBXs in the network support the same feature set.
Cisco tested Cisco CallManager QSIG feature functionality with the following PBX vendors: Lucent/Avaya Definity G3R using T1 or E1, Avaya MultiVantage and Communication Manager, Alcatel 4400 using E1 or T1, Ericsson MD110 using E1, Nortel Meridian using E1 or T1, Siemens Hicom 300 E CS using T1, Siemens Hicom 300 E using E1, and Siemens HiPath 4000.
Cisco CallManager supports the following QSIG features:
•
Tip
•
•
•
Annex M.1 (Message Tunneling for QSIG)
The Annex M.1 feature uses intercluster trunks and H.225 trunks to transport (tunnel) non-H.323 protocol information in H.323 signaling messages between Cisco CallManagers. Annex M.1 supports QSIG calls and QSIG call independent signaling connections. After you complete intercluster trunk configuration in Cisco CallManager Administration, QSIG tunneling supports the following features: Call Completion, Call Diversion, Call Transfer, Identification Services, Message Waiting Indication, and Path Replacement.
Note
Tip
For Cisco CallManager to support QSIG tunneling, you must choose the QSIG option in the Tunneled Protocol drop-down list box and check the Path Replacement Support check box in the Trunk Configuration window in Cisco CallManager Administration. By default, Cisco CallManager sets the option in the Tunneled Protocol drop-down list box to None; after you configure the QSIG Tunneled Protocol option, the Path Replacement Support check box automatically becomes checked. If you do not require path replacement over Annex M.1 or QSIG-tunneled trunks, you can uncheck the check box.
When you set the Tunneled Protocol field to None, Cisco CallManager automatically grays out the Path Replacement Support check box. When you set the Tunneled Protocol field to QSIG, you cannot configure the Redirecting Number IE Delivery (Inbound), Redirecting Number IE Delivery (Outbound), or Display IE Delivery options.
Tip
Basic Call for QSIG
QSIG basic call setup provides the dynamic establishment of voice connections from an originating PINX (PBX or Cisco CallManager) across a private network or virtual private network (VPN) to another PINX. You must use digital T1 or E1 primary rate interface (PRI) trunks to support QSIG protocol.
Call Completion
The following Call Completion services, which rely on the Facility Selection and Reservation feature, provide Cisco Call Back functionality over QSIG enabled trunks:
•
•
Cisco CallManager and the Call Completion services use the CallBack softkey on supported Cisco IP Phone models 7940, 7960, and 7970 in a Cisco CallManager cluster or over QSIG trunks. Likewise, the following devices support QSIG Call Completion services:
•
•
•
The Callback Calling Search Space service parameter, which works with the Cisco CallManager service, allows an originating PINX to route a call setup request to a CTI device that exists on the terminating PINX. This functionality supports CTI applications, such as Cisco CallManager Attendant Console, Cisco IP Manager Assistant (IPMA), and so on. For more information on this service parameter, click the i button that displays in the upper corner of the Service Parameter window.
•
In addition to configuring the Cisco Call Back feature in Cisco CallManager Administration, as described in the "Cisco Call Back" section on page 4-1, you may need to update the default settings for the Cisco Call Back service parameters; that is, if the Cisco Technical Assistance Center (TAC) directs you to do so. Cisco Call Back service parameters include Connection Proposal Type, Connection Response Type, Callback Request Protection Timer, Callback Recall Timer, and Callback Calling Search Space. For information on these parameters, click the i button that displays in the upper corner of the Service Parameter window.
For additional information on Cisco Call Back support, for example, how the feature works for QSIG-supported and Cisco CallManager intracluster calls, refer to the "Cisco Call Back" section on page 4-1.
Call Diversion
Cisco CallManager supports call diversion by rerouting and call diversion by forward switching. When call diversion by rerouting occurs, the originating PINX receives a request from the receiver of the call to divert the call to another user. The system creates a new call between the originator and the diverted-to user, and an additional CDR gets generated.
In Cisco CallManager Administration, the Cisco CallManager service uses the following parameters to perform call diversion by rerouting: Call Diversion by Reroute Enabled and Call Reroute T1 Timer. If you want to use call diversion by rerouting, you must set the service parameters to the values that are specified in the i-button help, which displays when you click the i button in the upper corner of the Service Parameter window. If you do not configure the service parameters, call diversion by forward switching automatically occurs.
Cisco CallManager cannot request that the originating PINX divert the call, but Cisco CallManager can validate the directory number to which the call is diverted by terminating restriction QSIG messages. Call diversion by rerouting does not support non-QSIG trunks. If you do not use a uniform dial plan for your network, use call diversion by forward switching and path replacement to optimize the path between the originating and terminating users.
If the receiver of the incoming call and the diverted-to user exist in the same PINX, Cisco CallManager uses call diversion by forward switching. If call diversion by rerouting is not successful for any reason, for example, the rerouting timer expires, forward switching occurs.
QSIG diversion supplementary services provide call-forwarding capabilities that are similar to familiar Cisco CallManager call-forwarding features, as indicated in the following list:
•
•
•
•
To provide feature transparency with other PBXs in the network, the system passes information about a forwarded call during the call setup and connection over QSIG trunks. Phone displays can present calling name/number, original called name/number, and last redirecting name/number information to show the destination of the forwarded call.Call identification restrictions can impact what displays on the phone. See the "Identification Services" section for more information.
QSIG supplementary services can provide the information to place the voice message from a diverted call into the originally called party voice mailbox. Be aware that voice-mail configuration may override call-forwarding configuration settings.
Cisco CallManager does not invoke call diversion by rerouting when the system forwards the call to the voice mailbox. If the connection to the voice mail server occurs over a Q.SIG trunk and you want to use call diversion by rerouting, you must enter the voice mail pilot number in the appropriate Coverage/Destination field instead of checking the Voice Mail check box in the Directory Number Configuration window.
Tip
Call Transfer
Cisco CallManager supports call transfer by join only.
When a user transfers a call to another user, the QSIG identification service changes the connected name and number that displays on the transferred party phone. Call identification restrictions can impact what displays on the phone.
The call transfer supplementary service interacts with the path replacement feature to optimize the trunk connections when a call transfers to a caller in another PINX. For more information about path replacement, see the "Path Replacement" section.
Compatibility with Older Versions of QSIG Protocol (ECMA)
To create CallManager compatibility with your version of the QSIG protocol, configure the ASN.1 Rose OID Encoding and QSIG Variant service parameters.
Tip
If you choose ECMA for the QSIG Variant parameter, you must choose the Use Global Value (ECMA) setting for the ASN.1 Rose OID Encoding service parameter. If you choose ISO for the QSIG Variant parameter, you normally choose the Use Local Value setting for the ASN.1 Rose OID Encoding service parameter. Other configurations may be needed in unusual situations.
If you configure the QSIG Variant service parameter, a warning message indicates that Cisco CallManager does not support ECMA with QSIG tunneling over intercluster trunks (Annex M.1). To use ECMA, verify that the None option displays for the Tunneled Protocol drop-down list box in the Trunk Configuration window.
Cisco Call Manager supports using Annex M.1 to tunnel QSIG over intercluster trunks. To configure Annex M.1, set the ASN.1 Rose OID Encoding to Use Global Valueless) and the QSIG Variant to ISO (Protocol Profile 0x9F).
Facility Selection and Reservation
The facility selection and reservation feature allows you to make calls by using mixed route lists, which contain route groups that use different protocols. This feature supports mixed route lists that include the following types of facilities:
•
•
•
•
•
Tip
When you configure the route list, configure the QSIG route groups as the first choice, followed by the non-QSIG route groups that serve as alternate connections to the PSTN. Make sure that you include additional route groups for QSIG calls in addition to the private network QSIG facilities. When no QSIG trunks are available for a call, you want to provide alternate routes over the PSTN for calls.If a call requires a QSIG facility, Cisco CallManager hunts through the route groups to reserve the first available QSIG facility. If a QSIG facility is unavailable, Cisco CallManager uses a non-QSIG facility to failover to the PSTN.
If a call does not require a QSIG facility, Cisco CallManager hunts through the route groups to find the first available facility.
The Path Replacement, Message Waiting Indication, and Call Completion supplementary services require a QSIG facility to meet QSIG signaling compliance requirements. If a QSIG facility is not available for one of the aforementioned services, the call does not meet QSIG signaling compliance requirements, and the feature fails.
Identification Services
When a call alerts and connects to a PINX, identification services can display the caller name/ID on a phone in the terminating PINX, and, likewise, the connected party name/ID on a phone in the originating PINX. QSIG identification restrictions allow you to control the presentation or display of this information between Cisco CallManager and the connected PINX.
Supported supplementary services apply on a per-call basis, and presentation settings for call identification information are set at both ends of the call. Cisco CallManager provides configuration settings to control the following caller identification number (CLID) and caller name (CNAM) information on phone displays:
•
•
•
•
Configuration settings for the outgoing call get sent to the terminating PINX, where the settings may get overwritten. The connected line and name configuration gets set on the terminating side of the call; after the originating PINX receives the configuration settings, the originating PINX may override the configuration.
Tip
You can allow or restrict display information for all calls by configuring fields in the Gateway Configuration window. Or, you can control display information on a call-by-call basis by using fields in the Route Patterns and Translation Patterns windows. The presentation setting for the gateway overrides the setting for the route pattern. Translation pattern presentation settings override route pattern presentation settings.
Cisco CallManager supports "Alerting on ring" only, and the QSIG Alerting Name that you configure allows you to send and receive call name information while the phone rings. In the Directory Number Configuration window in Cisco CallManager Administration, you configure the Alerting Name field for shared and nonshared directory numbers. When two phones ring for the shared directory number, the name that you entered in the Alerting Name field displays on the phone of the called party at the terminating PINX, unless translation pattern restrictions affect the information that displays. Route pattern restrictions may affect the information that displays on caller phone at the originating PINX.
Tip
If you do not configure an Alerting Name, only the directory number displays on the calling party phone when alerting occurs. If you configure a Display Name configured for the called party, the Display Name displays on the calling party phone when the call connects. If you do not enter a Display Name or an Alerting Name, no name displays on the calling party phone during the call. You cannot use Alerting Name with the following device types:
•
•
•
Message Waiting Indication (MWI) Service
In a QSIG network, when a PINX has a connected voice-messaging system that services users in another PINX, the message center PINX can send the following message waiting indication (MWI) signals to the other PINX:
•
•
Note
A PINX that is not a message center can receive MWI signals and perform the following tasks:
•
•
If the voice-messaging system connects to Cisco CallManager by using QSIG connections or by using the Cisco Messaging Interface (CMI), the message waiting indicators get set based on QSIG directives.
When a call is forwarded to a number and then diverted to a voice-messaging system, QSIG supplementary services can provide the information to place the voice message in the originally called party voice mailbox.
The Message Waiting Indication service, which uses the existing dial number for message waiting that is set up in Cisco CallManager Administration, does not require any additional configuration.
Path Replacement
In a QSIG network, after a call is transferred or forwarded to a phone in a third PINX, multiple connections through several PINX(s) can exist for the call. After the call connects, the path replacement feature drops the connection to the transit PINX(s) and creates a new call connection to the terminating PINX.
Note
Cisco CallManager does not support path retention.Cisco CallManager initiates path replacement for calls that are transferred by joining and for calls that are diverted by forward switching only. Calls that involve multiple trunks, for example, conference calls, do not use path replacement; however, if you choose the QSIG option for the Tunneled Protocol drop-down list box and check the Path Replacement Support check box for gatekeeper-controlled or non-gatekeeper-controlled intercluster trunks, path replacement occurs over the intercluster trunk and the other QSIG intercluster or PRI trunk that is used to transfer or divert the call.
When you use CTI applications with path replacement, the leg of the call that uses path replacement has a different Global Caller ID than the originating leg of the call. After a call is forwarded or transferred, if the remaining parties use the same Cisco CallManager, two Global Caller IDs exist, one for each party. The system deletes one of the Global Caller IDs, both parties in the call have the same Global Caller ID.
Tip
Because the QSIG protocol passes the extension number or directory number but does not pass translated or inserted numbers, use QSIG features, such as path replacement, in a network with a uniform dial plan. When a private network uses nonunique directory numbers in the dial plan, you must reroute calls through a PINX ID, which is a unique directory number for every PINX in the network. The path replacement feature uses the PINX ID, if configured, instead of the called or calling party number that the "Identification Services" section describes. To configure the PINX ID, perform the following tasks in Cisco CallManager Administration:
•
•
Tip
Cisco CallManager provides the Path Replacement Calling Search Space service parameter, so you can configure the calling search space that the responding Cisco CallManager will use to route the setup message to the requesting PINX. If you do not configure this parameter, the system uses the calling search space that the original connection used.
You configure Path Replacement settings in the Service Parameter window for the Cisco CallManager service. Path Replacement service parameters include Path Replacement Enable, Path Replacement on Tromboned Trunks, Start Path Replacement Minimum Delay Time, Start Path Replacement Maximum Delay Time, Path Replacement PINX ID, Path Replacement Timers, Path Replacement Calling Search Space, and so on. To obtain information about these parameters, click the i button that displays in the Service Parameter window.
Path replacement performance counters allow you to track when path replacement occurs. For information on performance counters, refer to the Cisco CallManager Serviceability System Guide.
For each call, the system generates more than one CDR for the path replacement feature. One CDR gets generated for the caller at the originating PINX; another CDR gets generated for the called party at the PINX where path replacement is initiated.
Note
QSIG Interface to Cisco CallManager
For Cisco CallManager to support QSIG functionality, QSIG must be back-hauled directly to Cisco CallManager. Cisco CallManager interconnects to a QSIG network by using an MGCP gateway and T1 or E1 PRI connections to the PISN. The MGCP gateway establishes the call connections. By using the PRI backhaul mechanism, the gateway passes the QSIG messages to Cisco CallManager to enable setting up QSIG calls and sending QSIG messages to control features.
When a PBX is connected to a gateway that is using QSIG via H.323, calls that are made between phones on the PBX and IP phones that are attached to the Cisco CallManager can have only basic PRI functionality. The gateway that terminates the QSIG protocol provides only the Calling Line Identification (CLID) and Direct Inward Dialed (DID) number rather than Cisco CallManager providing the information.
Related Topics
•
•
Where to Find More Information
Related Topics
•
•
•
•
Additional Cisco Documentation
•
•
•
