Cisco CallManager System Guide, Release 4.1(2)
Understanding IP Telephony Protocols

Table Of Contents

Understanding IP Telephony Protocols

IP Protocols

H.323 Protocol

Media Gateway Control Protocol (MGCP)

Skinny Client Control Protocol (SCCP)

Session Initiation Protocol (SIP)

Analog Telephony Protocols

Loop-Start Signaling

Ground-Start Signaling

E&M Signaling

Channel Associated Signaling (CAS)

T1 CAS

E1 CAS

Digital Telephony Protocols

Basic Rate Interface (BRI)

T1 Primary Rate Interface (T1 PRI)

E1 Primary Rate Interface (E1 PRI)

Q.Signaling (QSIG)

Annex M.1 (Message Tunneling for QSIG)

Basic Call for QSIG

Call Completion

Call Diversion

Call Transfer

Compatibility with Older Versions of QSIG Protocol (ECMA)

Facility Selection and Reservation

Identification Services

Message Waiting Indication (MWI) Service

Path Replacement

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:

IP Protocols

Analog Telephony Protocols

Digital Telephony Protocols

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

Media Gateway Control Protocol (MGCP)

Skinny Client Control Protocol (SCCP)

Session Initiation Protocol (SIP)

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:

"Adding a Cisco IOS H.323 Gateway" section in the Cisco CallManager Administration Guide

Gatekeeper Configuration chapter in the Cisco CallManager Administration Guide,

Understanding Cisco CallManager Trunk Types chapter in the Cisco CallManager System Guide,

Understanding Cisco CallManager Voice Gateways chapter in the Cisco CallManager System Guide, and the

Trunk Configuration chapter in the Cisco CallManager Administration Guide

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

H.323 Protocol

Skinny Client Control Protocol (SCCP)

Session Initiation Protocol (SIP)

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

H.323 Protocol

Media Gateway Control Protocol (MGCP)

Session Initiation Protocol (SIP)

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

H.323 Protocol

Media Gateway Control Protocol (MGCP)

Skinny Client Control Protocol (SCCP)

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:

Foreign Exchange Office (FXO)—Analog trunks that connect a gateway to a central office (CO) or private branch exchange (PBX).

Foreign Exchange Station (FXS)—Analog trunks that connect a gateway to plain old telephone service (POTS) device such as analog phones, fax machines, and legacy voice-mail systems.

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

Ground-Start Signaling

E&M Signaling

Channel Associated Signaling (CAS)

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

E&M Signaling

Channel Associated Signaling (CAS)

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

Loop-Start Signaling

E&M Signaling

Channel Associated Signaling (CAS)

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

Loop-Start Signaling

Ground-Start Signaling

Channel Associated Signaling (CAS)

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 on page 36-13.

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 on page 36-13. Refer to documentation for the specific gateway for configuration information.

Related Topics

Loop-Start Signaling

Ground-Start Signaling

E&M Signaling

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)

T1 Primary Rate Interface (T1 PRI)

E1 Primary Rate Interface (E1 PRI)

Q.Signaling (QSIG)

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)

E1 Primary Rate Interface (E1 PRI)

Q.Signaling (QSIG)

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

Basic Rate Interface (BRI)

E1 Primary Rate Interface (E1 PRI)

Q.Signaling (QSIG)

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

Basic Rate Interface (BRI)

T1 Primary Rate Interface (T1 PRI)

Q.Signaling (QSIG)

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:

Annex M.1 (Message Tunneling for QSIG)


Tip Annex M.1 provides support only for Cisco CallManager clusters that use intercluster trunks. Cisco CallManager does not support Annex M.1 with PBXs.


Basic Call for QSIG

Call Completion

Call Diversion

Call Transfer

Compatibility with Older Versions of QSIG Protocol (ECMA)

Facility Selection and Reservation

Identification Services

Message Waiting Indication (MWI) Service

Path Replacement

Annex M.1 (Message Tunneling for QSIG)

The Annex M.1 feature uses intercluster 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.


Tip If you use a gatekeeper, you must configure every gateway in the network for QSIG tunneling. If any gateway in the network does not support QSIG tunneling, calls drop at the intercluster trunk that is configured for QSIG tunneling.


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 Cisco CallManager does not support protocol profile 0x91 ROSE encoding with Annex M.1.


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:

Completion of Calls to Busy Subscribers (CCBS)—When a calling party receives a busy tone, the caller can request that the call complete when the busy destination hangs up the phone and becomes available.

Completion of Calls on No Reply (CCNR)—When a calling party receives no answer at the destination, the calling party can request that the call complete after the activity occurs on the phone of the called party.

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:

Cisco IP Phone Models 7905, 7910, 7912, 7940, 7960, 7970

Cisco VGC Phone, Cisco IP Communicator, and Cisco SCCP Phone

CTI route point that forwards calls to supported devices

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.

QSIG trunks

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:

Call Forward All (CFA) configuration supports Call Forwarding Unconditional (SS-CFU).

Call Forward Busy (CFB) configuration supports Call Forwarding Busy (SS-CFB).

Call Forward No Answer (CFNA) configuration supports Call Forwarding No Reply (SS-CFNR).

Cisco CallManager does not support Call Deflection (SS-CD).

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 When calls are forwarded among multiple PINXs, a forwarding loop can result. To avoid calls being caught in a looping condition, or entering a long forwarding chain, configure the Forward Maximum Hop Count service parameter for the Cisco CallManager service. Setting this service parameter above 15 makes your QSIG configuration noncompliant with international standards.


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 For more information on these parameters, click the i button that displays in the upper corner of the Service Parameter window.


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:

E1 or T1 PRI trunks that use the QSIG protocol

E1 or T1 PRI trunks that use a protocol other than QSIG

T1-CAS gateways

FXO ports

Intercluster trunks


Tip You cannot add route groups with H.323 gateways to a route list that includes QSIG route groups.

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:

Calling Line Identification Presentation/Restriction—Displays the calling number (CLIP) or restricts the display of the calling number (CLIR).

Calling Name Identification Presentation/Restriction—Displays the calling name (CNIP) or restricts the display of the calling name (CNIR).

Connected Line Identification Presentation/Restriction—Displays the number of the connected line (COLP) or restricts the display of the connected line (COLR).

Connected Name Identification Presentation/Restriction—Displays the name of the connected party (CONP) or restricts the display of the connected name (CONR).

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 When you restrict a name, the display shows "Private," and the display remains blank for a restricted calling line number.


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 You configure Alerting Name identification restrictions by setting the Connected Name configuration parameters.


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:

PRI trunks

FXS/FXO ports for MGCP gateways

MGCP T1-CAS gateways

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:

MWI Activate—Send a signal to another PINX to activate MWI on the served user's phone after the voice-messaging system receives a message for that phone.

MWI De-activate—Send a signal to deactivate the MWI after the user listens to messages in the associated voice-messaging system.


Note Cisco CallManager does not support the MWI interrogation service.


A PINX that is not a message center can receive MWI signals and perform the following tasks:

MWI Activate—Receive a signal from another PINX to activate MWI on the served user's phone.

MWI De-activate—Receive a signal to deactivate the MWI on the served user phone.

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 provides "requesting" and "cooperating" PINX messages only. If configured for QSIG, Cisco CallManager responds to third-party vendor PINX "inviting" messages, although Cisco CallManager will not originate "inviting" messages.

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 This section provides information on a few path replacement service parameters. For a complete list of service parameters and for detailed information on the parameters, click the i button that displays in the upper corner of the Service Parameter window.


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:

Configure the PINX ID service parameter(s) for the Path Replacement feature. (The Path Replacement feature uses the Cisco CallManager service.)

Create a call pickup group that includes only the PINX ID.


Tip Reserve the PINX ID call pickup group for PINX ID usage. Do not add other directory numbers to this call pickup group.


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 When a Cisco SoftPhone user chooses to perform a consultive transfer to move a call to another PINX, path replacement can occur; if the user performs a direct (blind) transfer, path replacement cannot occur. For more information about Cisco SoftPhone, refer to the Cisco SoftPhone documentation that supports your version of the application.


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

Basic Rate Interface (BRI)

E1 Primary Rate Interface (E1 PRI)

T1 Primary Rate Interface (T1 PRI)

Where to Find More Information

Related Topics

Understanding Session Initiation Protocol (SIP), page 38-1

Gateway Configuration

Gatekeeper Configuration

Understanding Cisco CallManager Voice Gateways, page 36-1

Gateway Configuration Checklist, page 36-25

Trunk Configuration Checklist, page 39-9

Trunk Configuration

Additional Cisco Documentation

Cisco  IP Telephony Solution Reference Network Design

Cisco ICS 7750 System Description

Configuring Cisco IP Telephony Voice Gateways