Voice Health Monitor User Guide, 1.1
Voice Network Troubleshooting

Table Of Contents

Voice Network Troubleshooting

Cannot Make a Call

All IP Phones in an Area Are Nonfunctional

Cannot Call Other IP Phones

Cannot Access Workflow Applications

Phone Access Switch is Out of Power

Cannot Access Conferencing Service


Voice Network Troubleshooting


These topics present some typical scenario-based voice troubleshooting procedures. These scenarios describe problems that VoIP network users may encounter, and shows how to use VHM to analyze such problems:

Cannot Make a Call

All IP Phones in an Area Are Nonfunctional

Cannot Call Other IP Phones

Cannot Access Workflow Applications

Phone Access Switch is Out of Power

Cannot Access Conferencing Service

Cannot Make a Call

An IP phone user reports that she cannot access the phone service.

To troubleshoot this problem:


Step 1 Get the Cisco CallManager IP address to which the IP phone connects from the IP Phone configuration.

Step 2 Identify which voice cluster the Cisco CallManager belongs to.

Step 3 In VHM, open the Status View for the voice cluster identified in Step 2. (For details, see the "Using the Status View" section.)

Step 4 Find the Cisco Call Managers that are down.

Step 5 Check to see whether the IP address from Step 1 matches the Cisco CallManager that is down.

Step 6 Use the Device Detail View window of the Real-Time Dashboard to find out more about the faults. (For details see the "Using the Device Detail View" section.)

For example:

If you have configured synthetic transactions for the Cisco CallManager, you can view the results of the test in VHMs Device Detail View window:

a. In the Real-Time Dashboard—Status View, open the Device Detail View for the Cisco CallManager.

b. Click the Application tab.

c. Under the Attribute column, look for the Synthetic Phone Registration test.

d. Look under the Status column to see if the test failed.

Step 7 Alternatively, use the Monitoring Console's alarm log to determine whether there are other alarms related to problems associated with the Cisco CallManager.


All IP Phones in an Area Are Nonfunctional

A group of users report that IP phones in an area are nonfunctional.

To troubleshoot this problem:


Step 1 If you have configured TFTP Receive synthetic transactions, check to determine whether the ST Server is running. Select Server Configuration > Administration > Process Management > Process Status.

Step 2 If the ST Server is not running, ask a user who can log on to CiscoWorks2000 in the System Admin role to start the ST Server. Select Server Configuration > Administration > Process Management > Start Process.

Step 3 If the ST Server is running, verify that TFTP Receive synthetic transactions are configured. Select Voice Health Monitor > Administration > Synthetic Transaction > Transaction Configuration.

Step 4 Start the Real-Time Dashboard. Select Voice Health Monitor > Real-Time Dashboard. The Real-Time Dashboard-Summary View window is displayed.

a. Examine the voice device groups, looking for a voice cluster with Critical faults. Double-click any such voice cluster to open a Real-Time Dashboard-Status View.

b. Examine the devices on the Status View, looking for CallManagers that have an Applications status of Critical. Double-click the Critical status to open a Device Detail view.

c. In the Device Detail View, click the Application tab. .

d. Under the Attribute column, look for the TFTP Receive test.

e. Look under the Status column to see if the test failed.


Cannot Call Other IP Phones

To troubleshoot this problem:


Step 1 If you have configured End to End Call synthetic transactions, check to determine whether the ST Server is running. Select Server Configuration > Administration > Process Management > Process Status.

Step 2 If the ST Server is not running, ask a user who can log on to CiscoWorks2000 in the System Admin role to start the ST Server. Select Server Configuration > Administration > Process Management > Start Process.

Step 3 If the ST Server is running, verify that End to End Call synthetic transactions are configured. Select Voice Health Monitor > Administration > Synthetic Transaction > Transaction Configuration.

Step 4 Start the Real-Time Dashboard. Select Voice Health Monitor > Real-Time Dashboard. The Real-Time Dashboard-Summary View window is displayed.

a. Examine the voice device groups, looking for a voice cluster with Critical faults. Double-click any such voice cluster to open a Real-Time Dashboard-Status View.

b. Examine the devices on the Status View, looking for CallManagers that have an Applications status of Critical. Double-click the Critical status to open a Device Detail view.

c. In the Device Detail View, click the Application tab.

d. Under the Attribute column, look for the End to End Call test.

e. Look under the Status column to see if the test failed.


Cannot Access Workflow Applications

A user reports that he cannot access the Auto Attendant or other Workflow Application.

To troubleshoot this problem:


Step 1 Obtain the numbers the user dialed; from them, identify which Workflow Application Server is serving the user call.

Step 2 From the Real-Time Dashboard-Summary View window, click the VoiceServices device group to launch the Status View window.

Step 3 From the Status View window, identify the workflow applications that are down.

Step 4 Check to determine whether the workflow application server identified in Step 1 is down.

Step 5 If the workflow application server is down:

Go to the Workflow Application Admin page through the Real-Time Dashboard-Device Detail View and check for any fault conditions.

Check the Monitoring Console's Alarm Log for alarms related to the Workflow Application.


Phone Access Switch is Out of Power

A user reports that the IP phone that uses the Phone Access Switch is out of power.

To troubleshoot this problem:


Step 1 From the phone extension and username, identify the switch that the phone is connected to. If the user is running Campus Manager, the User Tracking application provides this information.

Step 2 From the Real-Time Dashboard-Summary View window, click the Phone Access Switch device group to launch the Status View window.

Step 3 Check to determine whether the switch identified in Step 1 is down.

Step 4 Open the detailed device view window for that Phone Access Switch and get more information; for example, IP address and location.

Step 5 Check to determine whether the reachability and interfaces categories show up as Critical.

Step 6 If the reachability, system, and environment status on the switch are OK, check to determine whether the cards on the switch are operating normally. To do so, check the Monitoring Console for any card level faults on the switch. If the card feeding power to the phone is down, that is the root cause of the problem.

Step 7 An alternative is to check the Monitoring Console's alarm log for other alarms that may be related to the down status of the Phone Access Switch.


Cannot Access Conferencing Service

An IP phone user calls and reports that she cannot access the conferencing service.

To troubleshoot this problem:


Step 1 Identify where the conference bridging services are down.

Step 2 If the conference bridging services are running on a PC:

a. Check to determine whether the PC is running normally by looking for faults on the Monitoring Console.

b. If there are any faults related to the PC, check the PC condition by logging in to the PC.

Step 3 If the conference service is running on a Catalyst switch:

a. Check the Monitoring Console to find out whether there are alarms relating to the Voice T1 interfaces of the Catalyst switches.

b. Open the Device Detail View window for the Catalyst Switch for which the alarm was generated.

To find information about an interface, select the InterfaceStatus tab.

To find system information such as IP addresses, locations, and system contacts, select the DeviceInformation tab.

If you have configured synthetic transactions for Cisco CallManager, select the Applications tab. Look for the Synthetic Phone to Conference Bridge test results. Then look for a Synthetic Phone to Conference Bridge Failed event.