Basic Calls Between Cisco CallManager and Cisco CME

Table of contents:

Even before the introduction of Cisco CME, Cisco CallManager used Cisco IOS voice routers to provide a Public Switched Telephone Network (PSTN) access gateway for Cisco CallManager's IP phones. Both the H.323 and Media Gateway Control Protocol (MGCP) VoIP protocols can support this function. The choice between these two is partly a historic issue and partly related to the type of PSTN interface used, but this topic is outside the scope of this book.

Direct MGCP integration between Cisco CME's IP phones and Cisco CallManager is not supported. Although this does not preclude the concurrent operation of MGCP (used for the PSTN gateway ports) and H.323-with-CME on the same Cisco IOS voice router, this configuration is not recommended. Using MGCP with Cisco CallManager to control the PSTN voice ports on a Cisco CME system would force PSTN traffic originated by the Cisco CME's IP phones to route through the Cisco CallManager to reach the PSTN. In most cases, this would be inefficient because it would result in the Cisco CME-to-PSTN voice traffic traversing the Cisco CME-to-Cisco CallManager WAN link twice.

Because Cisco CME is built on top of the Cisco IOS voice infrastructure software foundation also used by the Cisco IOS router-based PSTN gateways, Cisco CME inherits most of the H.323 gateway-to-CallManager interoperability. You should be aware of some minor differences, however.

In the simple PSTN gateway case, most of the call progress signaling for calls is performed as in-band audio tones. For example, when an IP phone (hosted by Cisco CallManager) places an outbound call to the PSTN, the ringing tone (also called the alerting or ringback tone) heard by the caller is usually generated as an audio signal that's passed through end-to-end from the PSTN trunk. This means that the audio path from the gateway to the IP phone is opened and active before the call is connected.

In the case where a call is placed from a Cisco CallManager IP phone to a Cisco CME IP phone, the ringing tone is provided as an out-of-band H.323 indication from Cisco CME (through H.323 control channel signaling). This means that the Cisco CME system signals to the Cisco CallManager, which in turn instructs the Cisco CallManager's IP phone to generate the ringing tone locally.

The reasons for this difference include the following:

  • It saves some bandwidth because the audio path is not opened until the call actually connects.
  • The Skinny Client Control Protocol (SCCP)-based IP phones attached to Cisco CME cannot generate in-band ringing tone.
  • It avoids issues with shared extension lines, where an inbound H.323 call to Cisco CME may ring multiple phones at the same time. This could create complexity in choosing which phone should physically be required to do the tone generation. Add to this the fact that any of the Cisco CME phones involved might also have calls already in progress, and it should become clear why out-of-band signaling of call progress tones is the preferred approach for Cisco CME.

This issue of ringing-tone signaling causes some specific changes in the H.323 protocol exchange that Cisco CME uses when talking to a Cisco CallManager, compared with H.323 signaling to another Cisco IOS PSTN gateway, for example.

To get Cisco CallManager to provide local ringing-tone generation for outbound calls from Cisco CallManager, the Cisco CME delays negotiation of the media path until the call connects. The Cisco CallManager 3.3 and 4.0 H.323 implementations assume that in-band ringing tone is provided (by the Cisco CME or another H.323 device) on all calls that negotiate the media path (using H.245) before the call is connected. This delayed negotiation can lead to a minor delay (typically about a quarter of a second) in establishing the audio path when the call actually connects. This delay is called the voice cut-through delay.

Cisco CME only uses this delayed H.245 media negotiation on calls that go to or from a Cisco CallManager. Cisco CME (3.1 and above) can explicitly identify Cisco CallManager calls based on special nonstandard H.323 information element (IE) messages that Cisco CallManager attaches to its H.323 call setup, proceeding, alerting, and connected messages. See Figure 8-1.

Figure 8-1. Cisco CallManager-to-Cisco CME 3.1 Basic Call

Call Transfer

Part I: Cisco IP Communications Express Overview

Introducing Cisco IPC Express

Building a Cisco IPC Express Network

Cisco IPC Express Architecture Overview

Part II: Feature Operation and Applications

Cisco IP Phone Options

Cisco CME Call Processing Features

Cisco CME PSTN Connectivity Options

Connecting Multiple Cisco CMEs with VoIP

Integrating Cisco CME with Cisco CallManager

Cisco IPC Express Automated Attendant Options

Cisco IPC Express Integrated Voice Mail

Cisco CME External Voice Mail Options

Additional External Applications with Cisco CME

Part III: Administration and Management

Cisco IPC Express General Administration and Initial System Setup

Configuring and Managing Cisco IPC Express Systems

Cisco IPC Express System Configuration Example

Part IV: Maintenance and Troubleshooting

Troubleshooting Basic Cisco IPC Express Features

Troubleshooting Advanced Cisco CME Features

Troubleshooting Cisco CME Network Integration

Troubleshooting Cisco UE System Features

Troubleshooting Cisco UE Automated Attendant

Troubleshooting Cisco UE Integrated Voice Mail Features

Part V: Appendixes

Appendix A. Cisco IPC Express Features, Releases, and Ordering Information

Appendix B. Sample Cisco UE AA Scripts

Appendix C. Cisco Unity Express Database Schema


Cisco IP Communications Express(c) CallManager Express with Cisco Unity Express
Cisco IP Communications Express: CallManager Express with Cisco Unity Express
ISBN: 158705180X
EAN: 2147483647
Year: 2006
Pages: 236 © 2008-2020.
If you may any questions please contact us: