Filter
Top Products
Cisco IP Telephony Troubleshooting Guide for Cisco CallManager Release 3.0(1)
© 2000 Cisco Systems, Inc. 4
Purpose
This troubleshooting guide provides descriptions of the tools and utilities used to configure,
monitor, and troubleshoot Cisco CallManager Release 3.0(1), Cisco IOS Gateways and
Gatekeeper. Appendices provide detailed examples of three different call flows. In the first case
study, a Cisco IP Phone calls another Cisco IP Phone within a cluster, which is called an intra-
cluster call. In the second case study, a Cisco IP Phone calls through a Cisco IOS Gateway to a
phone hanging off of a local PBX or somewhere on the PSTN. In the third case study, a
Cisco IP Phone calls another Cisco IP Phone in a different cluster, which is called an inter-
cluster call. Once you understand the call flow and debug traces, it will be easier to isolate a
problem and determine which component is causing the problem. This document helps you
understand the tools available to troubleshoot potential problems and to understand the call flows
and series of events through the call traces and debug outputs.
In the event that you must contact the Cisco Technical Assistance Center (TAC), many of the
tools explained here are instrumental in gathering the data required by TAC. Having this
information before calling TAC assists with faster problem resolution.
Version
All discussions in this document are written for Cisco CallManager Release 3.0(1), unless
otherwise stated.
Topology
It is very important to have an accurate topology of the network that contains the ports to which
various components are connected, such as VLANs, routers, switches, gateways, and so on.
Having a well-documented topology will assist you in troubleshooting problems with the system.
You need to ensure that you have an accurate topology, access to all the network devices, and
terminal services for management of the Cisco CallManager.
Adding IP telephony to a new or existing network requires significant planning to ensure
success. Since real-time traffic has different requirements than data traffic, the network must be
designed with low latency and quality-of-service (QoS) in mind. As with any network that
carries mission-critical traffic, it is imperative that the network administrator maintains accurate,
detailed diagrams of the network topology. In a crisis situation it is important to know not just
the broad overview of the network, but also which ports are connected to network components,
such as routers, switches, Cisco CallManager servers, gateways, and other critical devices. It is
important to plan the network with redundancy and scalability in mind.
Caution: Cisco does not support using hubs for shared connectivity to the switches as they can
interfere with correct operation of the IP telephony system.
When working with switched networks, knowing the state of the spanning-tree for redundancy is
critical. The state of the network should be documented before any failure occurs.