ccvp tuc quick reference sheets (digital short cut)

Introduction

IntroductionThe Cisco Unified Communications System consists of many different applications and products that must work togetheron top of an existing network infrastructure. This combination of systems on a network platform generally managed byan organization other than the one handling the telephones introduces an extremely complex environment that can makeit difficult to troubleshoot problems. Understanding the fundamental protocols and designs used in a UnifiedCommunications System, combined with a systematic troubleshooting process, will make resolving problems muchsimpler.

In this guide, you will be presented with the information needed to pass the 642-426 Troubleshooting UnifiedCommunications CCVP exam. The methods and practices discussed in this guide will help you solve problems on yourown without having to call the Cisco Technical Assistance Center (TAC). The methodologies presented here are used bythe Cisco TAC to solve hundreds of Unified Communications problems every day. If you follow this methodology andstill find yourself unable to solve a problem, you will be much further along in the process when you try to contact TAC,thus reducing your total time to resolution. The Cisco support website at http://www.cisco.com/support also contains awealth of information and tools to help you solve your problem. Most common issues and resolutions are documented onthe website, making this an essential part of your troubleshooting toolkit.

I hope to provide you with a deep level of understanding about how problems in Unified Communication Systems areidentified and resolved. This should help you in working on production systems and studying for future certificationssuch as the CCIE Voice.

[ 3 ]

© 2007 Cisco Systems, Inc. All rights reserved. This publication is protected by copyright. Please see page 78 for more details.

CCVP TUC Quick Reference Sheets by David McDaniel

CCVP TUC Quick Reference Sheets Page 4 Return to Table of Contents

CCVP TUC Quick Reference SheetsCCVP TUC Quick Reference Sheets By David McDaniel ISBN: 9781587053238 Publisher:Cisco Press

Prepared for Huy Cuong Le Trong, Safari ID: [email protected] by Huy Cuong Le Trong

Print Publication Date: 2007/07/02 User number: 1002807 Copyright 2007, Safari Books Online, LLC.This PDF is exclusively for your use in accordance with the Safari Terms of Service. No part of it may be reproduced or transmitted in any form by any means without the priorwritten permission for reprints and excerpts from the publisher. Redistribution or other use that violates the fair use priviledge under U.S. copyright laws (see 17 USC107) or thatotherwise violates the Safari Terms of Service is strictly prohibited.

CHAPTER 1

Methodology and Tools

Due to the complexity of Cisco Unified Communication Systems, it is necessary to have a solid understanding of thetelephony components and applications and the underlying network infrastructure. Being familiar with Cisco UnifiedCallManager, Cisco Unity, the network infrastructure, and the voice clients and how they interoperate is critical tosuccessful troubleshooting. When you are familiar with the components of the Unified Communication System, learningand using a systematic troubleshooting process will simplify problematic situations when they arise. Throughout thisShort Cut, Cisco Unified CallManager is referred to as Cisco Unified CallManager, or simply CallManager.

PreparationProper preparation will lead to a much faster recovery time in the event of a failure. Look over the following items todecide whether you are well prepared to solve problems in your system:

n Accurate physical and logical map of the internetwork

n Network protocols and addressing schemes used

n Configuration and routing of protocols at Layer 2 and Layer 3

n External network connections and routing protocols used at these entry points

n Documented normal network behavior and performance

Having accurate information readily available allows you to focus on identifying and solving the problem at hand.Countless hours can be spent trying to determine the structure of a network. This only detracts from addressing the coreissue.

Systematic Troubleshooting MethodologyA systematic troubleshooting model will allow you to methodically reduce a large set of possible causes of trouble to asmaller set of causes or a single cause. After you identify the cause, you can fix the problem and restore the Cisco

[ 4 ]







CHAPTER 1


Unified Communications system. When your issue is resolved, take the time to document the experience to assist withfuture problems and to share expertise within your organization.

Sample Troubleshooting Overview

Figure 1-1 shows an example of a systematic troubleshooting methodology.

Let us step through each of the items in this flowchart in greater detail.

[ 5 ]



FinishedStart Define Problem

Gather Facts

Consider Possibilities

Document Facts

Problem Resolved

Create Action Plan

Implement Action Plan

Observe Results

Utilize Process

Doproblem

symptomsstop?

Yes

No

FIGURE 1-1

SystematicTroubleshootingFlowchart





CHAPTER 1


Define the Problem

To define the problem, first identify the general symptoms. Next, determine what possible problems these symptomsmight indicate. In general, your definition of the problem should be similar to the problem report itself. When definingthe problem, start thinking about what some possible causes might be. This can help you get a start on possibly identify-ing a quick fix to the problem.

Gather Facts

When gathering facts about the problem, it is important to accurately interview end users to get all the pertinent detailsabout the problem. Asking the right questions can quickly reduce the time it takes to resolve a problem, so try to be verythorough. Here are some examples of questions to use when interviewing an end user:

n When did the problem first occur?

n Is the problem constant or intermittent? If intermittent, is there any pattern to the occurrence?

n Are any messages or tones played?

n Does the device display any messages?

n What digits are being dialed?

n What still works?

There are also many tools that can be used to gather information about the issue. Internal tools, such as show and debugcommands on routers and switches, and the device and search pages of the Cisco Unified CallManager server, along withexternal tools, such as packet sniffers, CallManager traces, and network management systems, are key when trouble-shooting complex issues.

[ 6 ]







CHAPTER 1


Consider Possibilities

After you have gathered all available facts, consider possible issues based on your information. This will help youremove irrelevant details and narrow the search to a certain class of problem. Brainstorm with the data you have andconsider what device is most likely the cause of the issue. For example, if you have determined that the problem occursonly on calls placed over the WAN, PSTN configuration probably is not a possibility.

Create an Action Plan

After you consider all possibilities and narrow your options down to the most likely cause, or ideally to the confirmedroot cause, the action plan should reflect a solution directly related to the problem. If the problem is very complex, youshould break the problem into small steps. At each step, determine whether the network is functioning properly—thisknowledge will allow you to focus on the telephony components of the system.

Implement the Action Plan

When implementing your action plan, be sure to keep track of exactly what you are testing. By using a systematicprocess and changing only one variable at a time, you can reduce the time required to resolve the problem. Here are someother tips to follow when implementing the action plan:

n Make sure your changes do not make the problem worse or cause additional problems.

n Limit your impact on other users. For example, do not restart the CallManager cluster unnecessarily.

n Minimize the extent and duration of potential security lapses.

n Maintain a current backup of the CallManager and Unity servers and the configurations of the routers and switchesin the network.

[ 7 ]



NOTE

The use of these tools arediscussed in depth furtherin this Short Cut. Externaltools generally are mostuseful when the inter-view process discussedearlier does not provide an obvious solution. Often, simply verifying the configuration afterasking questions willprovide enough informa-tion to solve the problem.





CHAPTER 1


Observe and Document Results

After making a change to find a solution, record the results and determine whether the problem still exists. If the problemis not resolved, restart the process from the possibilities based on the facts gathered. If the problem is resolved, make surethe changes are properly documented. The following are reasons for documenting:

n It maintains the steps taken to resolve an issue.

n It provides a back-out plan in case the fixes cause other problems.

n It can be used in the future if the problem occurs again.

Tools for Cisco Unified CallManagerTroubleshootingThere are many tools to assist in troubleshooting a Unified Communications System. The tools on the Cisco UnifiedCallManager server are accessible from the Serviceability page, the Real-time Monitoring Tool (RTMT), and theCommand Line Interface (CLI). Gateway show and debug commands, along with packet sniffers and network manage-ment software such as Cisco Works, are also very useful tools when troubleshooting. The Cisco.com website alsoprovides web-based tools to assist you, such as Tech Tips, TAC Case Collection, Output Interpreter, and the Cisco.comsearch engine. The Bug Toolkit on Cisco.com can also help you determine whether an issue you are experiencing is aknown defect. The diagram shown in Figure 1-2 displays an overview of the troubleshooting tools available.

[ 8 ]







CHAPTER 1


Cisco Unified CallManager Serviceability

Cisco Unified CallManager Serviceability is a web-based troubleshooting tool for Cisco Unified CallManager thatprovides many levels of functionality.

AlarmsAlarms are used to receive notification that an event has taken place. Alarms contain information such as an explanationof the event and recommended action, as well as details of which application and server caused the event. After youconfigure alarms on the CallManager Serviceability page, use the Cisco Unified CallManager RTMT to collect and viewthe alarms.

[ 9 ]



• Cisco Unified CallManager Troubleshooting Tools: – Cisco Unified CallManager Serviceability • Alarms • Setting Trace • CDR Analysis and Reporting (CAR) • Control Center – Real-Time Monitoring Tool • Alerts • Viewing Trace • Syslog Viewer • Performance Monitoring – CLI

• Gateway Troubleshooting Tools: – show Commands – debug Commands

• Other Troubleshooting Tools: – Packet Sniffer – Cisco.com Tools

FIGURE 1-2

Overview of CiscoUnified CallManagerTroubleshooting





CHAPTER 1


Follow these steps to configure alarms:

Step 1. From the Serviceability page, choose Alarm > Configuration.

Step 2. Choose the server and the service.

Step 3. Choose the alarm destination. All but Remote Syslog are collected and viewed via RTMT.

Step 4. Select the desired alarm event level for each destination. Emergency provides the least detail and Debugprovides the most.

CallManager also provides additional explanation or recommendations for an alarm through the Serviceability AlarmDefinitions. This is accessible through Alarms > Definitions from the Serviceability page.

TracesCallManager Serviceability provides tracing tools for services to assist in troubleshooting. There are two types of traces:

n System Diagnostic Interface (SDI): Every Cisco CallManager service includes a default trace log file. The systemtraces SDI information from the services and logs run-time events and traces to these log files.

n Signal Distribution Layer (SDL): The SDL trace log file contains call-processing information from services suchas Cisco Unified CallManager and Cisco CTI Manager. The system traces the SDL of the call and logs state transi-tions into a log file.

When configuring traces, the following settings are recommended:

n Do not use XML output files or Device Name Based Trace.

n Set the Debug Trace Level to Detailed. This will include keepalives and all available trace output.

[ 10 ]



NOTE

In most cases, you willgather SDL traces onlywhen the Cisco TechnicalAssistance Center (TAC)asks you to do so.

WARNING

Tracing can be resource-intensive, and you shoulduse it only as a tempo-rary troubleshooting tool.





CHAPTER 1


Dialed Number AnalyzerThis tool enables you to test dial-plan configurations before and after you deploy them. The tool works by taking dialeddigits and the time of day as input and running them through a selected calling search space from a given calling party.This can be useful when you are troubleshooting partitions with time schedules as well as basic call processing. You caneither view the results online or save the output in an XML file for later retrieval.

Controlling ServicesFrom the Control Center in Cisco Unified CallManager Serviceability, you can view the status of a service and start andstop one service at a time for a particular server in the cluster. Starting and stopping a Cisco CallManager service causesall Cisco Unified IP Phones and gateways that are currently registered to that Cisco Unified CallManager service to failover to their secondary Cisco CallManager service. This also causes other installed applications, such as CiscoCallManager Conference Bridge or Cisco Messaging Interface, to start and stop.

Cisco Unified CallManager Real-Time Monitoring Tool

RTMT run as a client-side application uses HTTPS and TCP to monitor device status, system performance, devicediscovery, and CTI applications in the Cisco Unified CallManager cluster.

Performance Monitor and Data LoggingYou enable performance counters in CallManager Administration under System > Service Parameters > Cisco RISData Collector. Once here, under Troubleshooting Perfmon Data Logging, set Enable Logging to true. Like other tracesettings, we recommend keeping this enabled only when you are actively troubleshooting a problem. When this setting isenabled, performance counters will be collected and can be retrieved using the RTMT.

[ 11 ]







CHAPTER 1


AlertsYou can configure RTMT to generate an alert on a given event. RTMT can then send e-mails to specified addresses whencertain parameters exceed a given threshold. This can be very useful for system administrators; it allows the administra-tors to be aware of problems immediately when they occur.

Trace & Log CentralRTMT Trace & Log Central enables you to collect, view, and zip various traces and log files, as seen in Figure 1-3. Thefollowing options are available under Trace & Log Central:

n Remote Browse: Browse trace and log files on a server remote from RTMT.

n Collect Files: Collect files for local viewing from a remote server.

n Query Wizard: Collect and download files that match the search criteria.

n Schedule Collection: Set a recurring trace collection.

n Local Browse: View trace and log files that have been downloaded locally.

n Real Time Trace: View trace and log output as it is generated.

n Collect Crash Dump: Collect a core dump of trace files.

This is the place you will visit to collect traces and logs you have configured in CallManager Serviceability.

[ 12 ]







CHAPTER 1


Understanding Trace OutputCisco Unified CallManager traces are some of the most valuable troubleshooting tools available to you. These tracesprovide many details that can be difficult to interpret. Here are a few examples of some trace output and what the varioussections mean.

SCCP Trace Output12/23/2006 09:37:31.240 CCM|StationInit: 00000076 OffHook.|

<CLID::StandAloneCluster><NID::10.30.0.41><CT::2,100,93,1.3644893>

<IP::10.17.20.40><DEV::SEP000F8F072AF6>

TABLE 1-1 SCCP Trace Description

Example Fields Description

12/23/2006 09:37:31.240 Date and time the event occurred

StationInit StationInit = SCCP Device → Cisco Unified CallManager

StationD = Cisco Unified CallManager → SCCP Device

00000076 Unique TCP handle for a device registered to a Cisco Unified CallManager

OffHook SCCP message and all data fields sent as part of that message

<XML Trace Data> Extra data used by some tools that you should ignore

[ 13 ]



FIGURE 1-3

RTMT Trace & LogCentral





CHAPTER 1


When reading SCCP traces, there are two types of communication. StationInit represents communication from theendpoint to the CallManager. StationD indicates communication from the CallManager to the Endpoint.

Digit Analysis Results

Some of the most useful information in the output of a Cisco Unified CallManager trace is the Digit Analysis informa-tion. This information shows the digit analysis logic that occurs in the Cisco Unified CallManager. Look for this informa-tion to see the matching route pattern and any digit manipulation that might occur.

[ 14 ]







CHAPTER 2

Cisco Unified CallManager Related Issues

Common Endpoint Registration IssuesEndpoint registration issues are some of the most common issues you will face when troubleshooting Cisco UnifiedCallManager. Many issues can prevent IP Phones from registering correctly, including network connectivity, IP Phonesettings, DHCP settings, and Cisco Unified CallManager configuration settings.

Network Connectivity

Phone Initialization ProcessWhen a phone initializes to a Cisco Unified CallManager server, it must go through many steps before it will actuallyregister. Figure 2-1 shows these steps.

Once a phone has power, either through Cisco Pre-Standard POE, 802.3af POE, or an AC power adapter plugged in tothe wall, it performs the following steps, as shown in Figure 2-1:

Step 1. The switch uses CDP to tell the phone the Voice VLAN it should use.

Step 2. If DHCP is enabled, the phone sends out a DHCPDISCOVER broadcast requesting an address in the voiceVLAN. Be aware that it is possible to hardcode the settings acquired by DHCP (IP address, subnet mask,default gateway, DNS, TFTP Server [Option 150]).

Step 3. The DHCP server sends a DHCPOFFER message with an address from the scope assigned to the VoiceVLAN.

Step 4. The phone receives the DHCPOFFER and applies the values.

Step 5. The phone contacts the TFTP server listed in the DHCP request through option 150 and attempts to down-load its configuration file. This file is formatted as SEP<mac address>.cnf.xml. If this file is not found, thephone requests the XMLDefault.cnf.xml file.

Step 6. The phone attempts to register with the highest priority CallManager server.

[ 15 ]



NOTE

The extension numbers,speed dials, and othersettings are assignedwhen the SCCP IP Phoneregisters. They are notcontained in the SEPXML file.





CHAPTER 2


If a phone is not registering, one of the first things to check is whether there is network connectivity between the phoneand the CallManager server. To verify connectivity, use the ping or traceroute utility. In Cisco Unified CallManager 5.xyou can ping from the Operating System Administration web pages and from the CLI. If the ping is unsuccessful, trypinging from another device in the path to isolate where the network connectivity issue is.

[ 16 ]



Modified FLP

Reflected FLP

Resistive Detection and Classification

Return Current

CDP (VLAN Number)

DHCPDISCOVER

DHCPOFFER (IP Add, Def-GW, TFTP, DNS*)

Cisco UnifiedCallManager

TFTPServer

DHCPServer

CatalystSwitch

Cisco Pre-Standard

802.3af

TFTP GET (SEP003094C3AD7E.cnf.xml)

TFTP Data (SEP003094C3AD7E.cnf.xml)

SCCP Registration with CallManager

*DNS Is Optional

CDP (I Need 6.3 W [for a 7960])

Inline Power

FIGURE 2-1

SCCP PhoneInitializationProcedure





CHAPTER 2


Endpoint Device Issues

Cisco IP Phones can display messages that can provide useful troubleshooting data. You can see these messages by press-ing the following button sequence: Settings > Status > Status Messages. Table 2-1 lists the possible messages on CiscoUnified IP Phones and provides a brief description of the meaning of each message.

TABLE 2-1 Status Messages on the Cisco Unified IP Phones

Message Description Message Description

BOOTP server used The phone obtained its IP address Load Auth failed A signed phone load file has beenfrom a Bootstrap Protocol (BOOTP) modified or renamed.server rather than a DHCP server.

CFG file not found The name-based and default Load ID incorrect Load ID of the software file is of theconfiguration file was not found wrong type.on the TFTP Server.

CFG TFTP size The configuration file is too large Load rejected HC The application that was downloaded iserror for the file system on the phone. not compatible with the phone hardware.

Checksum error Downloaded software file is corrupt. Load server is Indicates an invalid TFTP server IPinvalid address or name in the Load Server

option.

CTL installed A Certificate Trust List (CTL) file No CTL installed A CTL file is not installed in the phone.is installed in the phone.

CTL update failed The phone could not update its No default router DHCP or static configuration did notCTL file. specify a default router.

DHCP timeout DHCP server did not respond. No DNS server IP A name was specified but DHCP orstatic IP configuration did not specify a DNS

server address.

[ 17 ]



continues





CHAPTER 2


TABLE 2-1 Status Messages on the Cisco Unified IP Phones (continued)

Message Description Message Description

Dialplan parsing The phone could not parse the Programming error The phone failed during programming.error dial plan XML file properly.

DNS timeout DNS server did not respond. TFTP access error TFTP server is pointing to a directory that does not exist.

DNS unknown host DNS could not resolve the name TFTP error The phone does not recognize an errorof the TFTP server or Cisco code provided by the TFTP server.Unified CallManager.

Duplicate IP Another device is using the IP TFTP file not found The requested load file (.bin) was notaddress assigned to the phone. found in the TFTPPath directory.

Error update locale One or more localization files could TFTP server not The specified TFTP server could not benot be found in the TFTPPath authorized found in the CTL of the phone.directory or were not valid. The locale was not changed.

File auth error An error occurred when the phone TFTP timeout TFTP server did not respond.tried to validate the signature of a signed file. This message includes the name of the file that failed.

File not found The phone cannot locate on the Version error The name of the phone load file isTFTP server the phone load file incorrect.that is specified in the phone configuration file.

IP address released The phone has been configured to XmlDefault.cnf.xml, Name of the configuration file. release its IP address. or .cnf.xml

corresponding to the phone device name

[ 18 ]







CHAPTER 2


The other items to check on the Cisco IP Phone are the network settings at Settings > Network Configuration. Here youwill find information assigned by the DHCP server (for example, IP Address) as well as settings loaded from the TFTPserver (for example, CallManager IP Addresses).

CallManager Configuration Issues

It is possible that some configuration issues on the CallManager server are preventing the phone from registering. Ensurethat the TFTP server from which the phone is set to receive its configuration file is activated. From the Cisco UnifiedCallManager Serviceability interface, choose Tools > Control Center > Feature Services and verify that the CiscoUnified CallManager and Cisco TFTP services are started and activated.

If you are still having problems, it is possible that the configuration file is somehow corrupt. You might be able to resolvethe problem by re-creating the file. To re-create this file, simply delete and re-create the phone using the Cisco UnifiedCallManager Administration web interface as seen in Figure 2-2. After you have finished this, power cycle the phone.

Troubleshooting SIP Devices

SIP registration issues include many of the same possibilities as the SCCP phones. In addition, there are a few things tocheck for on the SIP IP Phones:

n The firmware version does not support SIP.

n Incorrect SIP configuration in Cisco Unified CallManager.

n SIP digest is incorrect or not configured on the endpoint.

n SIP digest authentication is not supported or is incorrect.

[ 19 ]



Delete Selected

FIGURE 2-2

Delete a Cisco IPPhone





CHAPTER 2


Cisco Unified CallManager Availability Issues

CallManager Stops Responding

The Cisco Unified CallManager system does not respond to keepalives from IP Phones and gateways, which causes themto lose registration with the CallManager. The following are possible causes of this problem:

n The CallManager server crashes, causing reboot.

n The CallManager service freezes.

n A process is consuming all the CPU cycles from the CallManager server.

n A process with a memory leak is causing the server to page.

Gather DataYou might want to view the status of, or restart, a Cisco Unified CallManager service that is having problems. To do this,use the Control Center available in Cisco Unified CallManager Serviceability at Tools > Control Center. There areseveral other items to check to determine why the server stopped responding. Gather facts from the following aspects ofthe server.

Check system log messages to see if anything unusual has been reported. It is useful to view log files when you are trou-bleshooting server crashes, hung services, and other errors. If server crashes are a recurring problem, turn up the level oftrace on these logs to provide more detail that can help TAC determine the source of the problem.

You can also use the RTMT to view CPU and memory use in real time. You can also use the following CLI commands onthe server:

n show stats io

n show perf query class Processor

[ 20 ]







CHAPTER 2


You can also view CPU utilization of specific processes using the following commands:

n show perf query counter Process “% CPU Time”

n show process load

Formulate an Action PlanIn many cases, server crashes and hung processes can be the result of a defect in the software. Collecting memory dumpsand system logs can greatly assist TAC in determining the root cause of your problem. If you determine that CPU utiliza-tion is the cause of the problem, you might want to consider redesigning the system with a potential hardware upgrade, orpossibly rebooting the server. If you have determined that the problem is a memory leak, one possible solution is toupgrade to the current version of CallManager. Consult the Cisco.com Bug Toolkit to determine whether the problem is aknown issue. If you already have the Cisco bug identification number, it will greatly reduce the amount of time TACneeds to diagnose your problem.

Cisco Unified CallManager Administration Does Not Display

When an administrator tries to connect to the web interface using the URL https://hostname/ccmadmin, the page does notdisplay. The following are possible causes for this problem:

n A service has failed to start or has stopped.

n Connectivity might not exist due to a misconfiguration or network issues.

n Name resolution might not be configured or is resolving to an incorrect address.

n Firewall or access lists might be blocking the HTTP traffic in one or both directions.

[ 21 ]







CHAPTER 2


To check the following items, use the following tools:

n Use ping to check network connectivity.

n Try using the IP address instead of the hostname.

n Verify firewall settings.

n Verify services have started using the utils service list command on the CLI.

Slow CallManager Server Response

A slow server response can have symptoms such as post-dial delay or an extremely slow response time when attemptingto use the web-based interface. The following are potential causes for this issue:

n Speed and duplex mismatches between the server and the switch

n High CPU utilization

n Denial of Service attacks

n Memory leaks

n Viruses or spyware running on the client

Verify network configuration settings and use the tools mentioned earlier to diagnose these types of problems. If yoususpect a virus or spyware issues, run virus scanning and spyware detection software on the client to ensure that themachine has not been compromised.

Troubleshooting Cisco Unified CallManagerSecurity IssuesImplementing security mechanisms in the Cisco Unified CallManager system prevents identity theft of the phone orCisco Unified CallManager server, data tampering, and call-signaling and media-stream tampering. These added

[ 22 ]







CHAPTER 2


measures also introduce additional sources of issues that can affect the Unified Communications system. Figure 2-3shows the security enhancements that can be configured.

[ 23 ]



PSTN

PSTN phone

CCM1-1 CCM2-1

HQ

BRANCH

T1/E1

FX0

IP WAN

PSTN phone

V

V

Gateway1. IPSec encryption of signaling2. sRTP to endpoints3. V3PN across WAN

Endpoint1. TLS for signaling2. SRTP for media3. Signed firmware

Cisco Unified CallManager1. Signaling encryption2. Signaling authentication3. TLS management4. Secure LDAP5. Manage certificates6. Device authentication7. Encrypted config files

FIGURE 2-3

UnifiedCommunicationsSecurityEnhancements





CHAPTER 2


Security Enhancements Overview

EndpointsBy default, devices boot up in nonsecure mode. To secure the endpoints, Cisco Unified CallManager creates a self-signedcertificate on the CallManager and TFTP servers. After the cluster is configured for authentication, this certificate is usedto authenticate the Cisco IP Phone. Authentication and encryption status is maintained on the device level. If all devicesinvolved in the communication channel have registered as secure, the call will register as secure. If one device in thechannel has registered as nonsecure, the call will register as nonsecure regardless of the rest of the components in thechain.

HTTPSSecure HTTP (HTTPS) secures communication between the browser client and the Tomcat server. HTTPS uses a certifi-cate and a public key to encrypt the data transferred over the network and ensures that the user login password transportssecurely via the Web.

Certificate Authority Proxy FunctionThe Certificate Authority Proxy Function (CAPF) performs the following functions related to security on IP Phones:

n Endpoint Authentication using an existing Manufacturing Installed Certificate (MIC), Locally Significant Certificate(LSC), randomly generated authentication string, or “null” authentication

n Issues LSC to Cisco IP Phones

n Upgrades existing LSCs

n Retrieves phone certificates

n Authenticates via the MIC

[ 24 ]







CHAPTER 2


Cisco IOS MGCP Gateway EncryptionCallManager supports gateways that use the MGCP Secure Real-Time Transport Protocol (SRTP) package allowing forsecure media streams between IP Phones and gateways. All devices need to support SRTP or the connection will fallbackto RTP. When an SRTP call is set up, the master encryption key is sent over the MGCP signaling path, which you shouldsecure with IPsec.

Cisco Unified CallManager does not recognize whether an IPsec connection exists before sending the encryption keys.Ensure that this is set up when deploying SRTP.

H.323 Gateway and H.323/H.225/H.245 Trunk EncryptionH.323 gateways and H.225 trunks that support security can authenticate to CallManager if an IPsec association is estab-lished. The H.323 devices generate the encryption keys that are sent to CallManager through the signaling path. In addi-tion to configuring an IPsec association, you must check the SRTP Allowed check box in the device configuration for thegateway or trunk. Once again, all devices in the call path must support SRTP for it to be used; otherwise, the system willfallback to RTP.

Phone Enrollment ProcessThe IP Phone uses either an MIC or LSC for security, which requires the phone to enroll with the CAPF service. Olderphones tend to need an LSC installed by the CAPF, while newer phones come with an MIC. For phones that require anLSC, the following steps are performed:

Step 1. The IP Phone generates a public/private key pair.

Step 2. A TLS session is established with the CAPF service, and the keys and identity are sent from the phone to theCAPF.

Step 3. The CAPF service creates and sends an LSC to the phone.

Step 4. The IP Phone installs the LSC.

[ 25 ]







CHAPTER 2


The CAPF service must be in the phone CTL file, which it downloads when the phone boots. The server also looks upthe phone in its local database to validate its identity.

Troubleshooting Issues with the CAPF Service

After configuring the CTL client and CAPF on the CallManager cluster, you might run into a problem wherein phonesdisplay the message “cannot authenticate the CTL file.” The following are some possible causes for this problem:

n Not all servers in the cluster are in the CTL file.

n The phone might have changed clusters and needs a new CTL file.

n A server was added to the cluster but the CTL file was not updated.

n A server in the CTL file had its IP address changed.

As you can see, the root cause of the problem is that the server and the CTL file the phone is trying to use are not insync. It is a good idea to first open the CTL client and verify that the CTL file is set up correctly for the servers in thecluster. Once this has been verified, perform a factory reset on the phone; this will direct the phone to download a newCTL file. If all this fails, delete the phone from the CallManager and add it back in selecting a nonsecure security profile.After the phone registers, install an LSC to reconfigure security.

Troubleshooting Authentication String Errors

When trying to enter an authentication string on a Cisco IP Phone, a failure message is displayed. The following arecauses of this problem:

n Incorrect authentication string

n Expired authentication string

n IP Phone is not registered to CallManager

[ 26 ]







CHAPTER 2


n IP Phone does not have authentication enabled

n The CAPF service is down or deactivated

n Incorrect IP Phone firmware

To begin narrowing down the cause of the problem, verify that an MIC, LSC, and CTL file are installed on the phone.Press the Settings > Security Configuration buttons on the phone and check the resulting screen for the files, as seen inFigure 2-4.

Use the CallManager Device administration screen to verify the authentication string being used. It is also a good idea tocheck the Control Center in CallManager Serviceability to verify that the CAPF service has started.

Troubleshooting LSC Validation

If LSC validation fails on an IP Phone that is set to use encryption, you might want to consider the following possiblecauses:

n Expired certificate

n The LSC installed in the IP Phone was issued by an untrusted source

n The CAPF certificate does not exist on all servers in the CallManager cluster

[ 27 ]



09:30a06/25/06

7960 Settings2Ring Type3Network Configuration4Model Information5Status6Security Configuration

Select Setting

1001

Select Save Exit more

09:30a06/25/06

Security Configuration3MIC Not Installed4LSC Not Installed5CTL File Not Installed

Select Setting

1001

Update Exit

FIGURE 2-4

Cisco IP PhoneSecurityConfiguration Screen





CHAPTER 2


Ensure that the certificate has not expired by choosing Security > Certificate Management > Display Certificate fromthe Operating System Administration web page. Verify the LSC using the procedure shown in Figure 2-4. Check the CTLfile and look for security alarms on the CallManager server. The SDL trace output may also provide some useful data fortroubleshooting LSC validation issues. If you are using security tokens, these might become locked after numerous loginattempts.

Troubleshooting Database Replication IssuesIn a Cisco Unified CallManager cluster, the publisher replicates a read-only copy of the Cisco Unified CallManagermaster database to all other servers in the cluster. During any period when the publisher is unreachable or offline, nochanges can be made to the configuration database. When problems exist with replication, the following symptoms canoccur:

n Changes made to the IP Phone configuration do not take effect.

n Dial plan changes are not available.

n Call Forward All cannot be set.

n Extension mobility does not work.

n Changes to speed dials do not take effect.

n MWI functions do not work.

n Resetting the IP Phone does not have any effect.

These features and functions require changes to be made in the master database. If a replication is broken, devices regis-tered to a subscriber will not be able to make such changes.

[ 28 ]







CHAPTER 2


Diagnosing Database Replication Issues

Cisco Unified CallManager 5.xThe RTMT is the primary tool you will use when troubleshooting database issues on CallManager 5.x. Under thePerformance tab, choose the Performance object, then choose the Number of Replications Created andReplication_State categories to open them. The different states indicated by the Replication_State counter are

n 0: Replication is not started.

n 1: Replication has been started but has not completed.

n 2: Replication setup has completed and is currently working.

n 3: Replication is broken and the Database Layer Monitor service on the subscriber has been started at least once.

You can also use the command utils dbreplication status from the CLI to view the database replication status. Thiscommand must be performed on the Publisher and will create a file on the server at a location printed to the screen. Usethe command file view activelog <location/filename.out> to view the file that was generated.

Cisco Unified CallManager 4.xThe MS SQL Enterprise Manager is the tool used for managing replication between the publisher and the subscribers.The Enterprise Manager provides a GUI management interface for the SQL servers, as seen in Figure 2-5. The first stepto determine whether replication issues exist is to go to the Replication Alerts in Enterprise Manager and see if any repli-cation errors appear.

Use the following procedure to determine whether the SQL subscription is working:

Step 1. Create a device on the publishing server that is easy to recognize.

Step 2. Click Insert. The device does not need to be functional.

[ 29 ]



NOTE

Cisco UnifiedCallManager 4.x usesMicrosoft SQL 2000 forthe database and CiscoUnified CallManager 5.xuses IBM Informix. As aresult, the troubleshoot-ing tools for these twoplatforms are very different.





CHAPTER 2


Step 3. Click Update, and then click Close.

Step 4. In Enterprise Manager, expand the SQL subscriber in question. Right-click the Devices table and chooseReturn all rows to see if the new device is present.

Re-creating the Subscription

Cisco Unified CallManager 5.xUse the command utils dbreplication repair all to re-create the first node to subsequent node database replication rela-tionships. This process can take longer than 30 minutes on a large deployment.

Cisco Unified CallManager 4.xThe DBHelper tool is the simplest and easiest way to determine the database status and fix any issues. This tool is avail-able from TAC and is the recommended tool to use when you are addressing DB replication issues. The tool has a simpleReinitialize button that will attempt to resolve the replication issues. There is also a manual process to re-create asubscription in CallManager 4.x. It is quite lengthy but is available on Cisco.com.

[ 30 ]



FIGURE 2-5

Replication Alerts inEnterprise Manager





CHAPTER 2


Troubleshooting LDAP Replication IssuesFailure to replicate the LDAP is one possible problem that can occur in the Cisco Unified Communications system.Knowing how to troubleshoot the LDAP integrations and replications will ensure a consistent directory. CallManagerinteracts differently with LDAP in CallManager Release 4.x than in CallManager Release 5.x.

Cisco Unified CallManager 4.x

By default, CallManager 4.x uses an embedded LDAP directory called DC-Directory to store user information. Thesystem also supports integration with a third-party LDAP service such as Microsoft Active Directory and NetscapeiPlanet. If a third-party integration is used, the system becomes dependent upon the remote directory server and canbehave abnormally if the connection is lost.

LDAP Synchronization Issues with DC-DirectoryA common symptom of failed LDAP synchronization is a CallManager subscriber taking a very long time to start onboot. Upon analysis of the event viewer you will see that DC-Directory replication has failed. The following are causesfor a failed DC-Directory replication:

n Lost network connectivity

n Password mismatch

n DNS resolution failing

n Repeated installs of a Cisco Customer Response Solutions (CRS) server

n Decommissioning of an existing CRS server

n Running the avid_scfg command on the subscriber more than once

[ 31 ]







CHAPTER 2


It is most likely that you will know whether CRS servers have been added or removed recently. If you think the passwordmight be the problem, try resetting the password using the CCMPWDChanger command on the publisher and thesubscriber. As always, perform basic network connectivity tests to ensure the problem is not within the underlying infra-structure. You also might want to reinitialize the LDAP directory if the system is not allowing you to add, delete, or viewusers in the database.

To reinitialize LDAP replication on CallManager 4.x, perform the following steps:

Step 1. Open the command prompt on the publisher by choosing Start > Run and entering cmd.

Step 2. Enter the command avvid_save password to back up the DC-Directory database.

Step 3. Ensure that the DC directory service has been stopped on the subscriber by entering the net stop dcdirectory command at the command prompt.

Step 4. Enter the command cleandsa to delete all data from the DC-Directory database on the publisher. Use deletedib if cleandsa is not supported.

Step 5. Enter the commands avvid_cfg password, then avvid_restore password to re-create the DC-Directory struc-ture and restore the data that was backed up in Step 2.

Now that the DC-Directory publisher is in a known good state, you must reinitialize LDAP replication on the subscribers.This is a very simple process that follows these steps:

Step 1. On the subscriber, enter the command cleandsa or deletedib from the command prompt like in Step 4 of theprevious process.

Step 2. Enter the command avvid_scfg publisher password on the subscriber.

Step 3. Repeat Steps 1 and 2 for each subscriber.

[ 32 ]







CHAPTER 2


Active Directory Integration IssuesIf you are experiencing authentication failure on a CallManager cluster integrated with Active Directory, you might wantto take the following actions:

n Verify that the Domain Controller is running and accessible.

n Ensure proper username and password usage and permissions.

n Reset the password of the Active Directory Administrator; do not use any special characters.

Cisco Unified CallManager 5.x

In Cisco Unified CallManager 5.x, directory information is stored directly in the Informix database. The system stillsupports third-party LDAP integrations with Microsoft Active Directory, Netscape Directory Server, iPlanet DirectoryServer, and Sun ONE Directory server. CallManager then uses the LDAPv3 standard to access this data.

Local Directory IssuesIf you are experiencing issues with Local Directory replication, you should attempt to repair the broken replication usingthe utils dbreplication repair all command at the CLI discussed earlier. Because the directory is located in the samedatabase used for CallManager configuration, the procedure is the same.

Active Directory Synchronization IssuesIf new users added in Windows Active Directory are not appearing in CallManager, you most likely have a synchroniza-tion issue. Here are some troubleshooting steps to assist resolution of this problem:

n Ensure network connectivity.

n Check the LDAP configuration on CallManager.

[ 33 ]







CHAPTER 2


n Ensure the credentials used for the LDAP connection are valid.

n Verify Active Directory service permissions for the account specified in the Distinguished Name field of LDAPdirectory on CallManager.

n Perform a manual synchronization if CallManager is configured as such.

Common MGCP Gateway Registration IssuesA number of tools can be used to troubleshoot MGCP gateways failing to register with Cisco Unified CallManager. Boththe CLI on the gateway and the web-based interface on the CallManager provide tools for troubleshooting. Figure 2-6illustrates the MGCP gateway registration process.

Here are the main characteristics of MGCP communications to consider when troubleshooting a problem:

n Each endpoint on the gateway registers with CallManager.

n Endpoints are under the control of the CallManager server to which they are registered.

n Some configuration must be performed on the gateway.

n Any SRST dial plan is not used when the gateway is registered to CallManager.

Basic Troubleshooting Tools

The CallManager web interface can show registration status similar to how status is displayed for IP Phones. TheCallManager RTMT also provides Event Log messages that can be useful when troubleshooting MGCP gateways.

[ 34 ]







CHAPTER 2


Here is an example of an error message that might be displayed when an unregistration event occurs:

%CCM_CALLMANAGER-CALLMANAGER-3-DeviceUnregistered: Device unregistered. Device name.AALN/S2/SU0/0@Pod1HQ Device IP address.10.1.1.101 Protocol.MGCP Device type.[Optional]120Device description [Optional].AALN/S2/SU0/0@Pod1HQ Reason Code [Optional]9 App IDCisco UnifiedCallManager Cluster IDStandAloneCluster Node ID CCM2-1

This error message occurred because a device unregistered with CallManager. You can also see that the Reason Code is 9,which indicates that CallManager sent a reset message that caused the device to unregister. Table 2-2 lists the MGCPunregister reason codes.

[ 35 ]



The gateway boots up

A TCP connection is opened

Restart in Progress (RSIP) informsCisco Unified CallManager that

gateway is being broughtin service

Acknowledgment (ACK)


A TCP connection is opened


Cisco Unified CallManagersends an Audit Endpoint

(AUEP) per endpoint

TCP TCP

RSIP

OK

AUEP

OK

Cisco Unified CallManagersends a Request Notify(RQNT) per endpoint

RQNT

OK

Endpoints are now registered inCisco Unified CallManager

FIGURE 2-6

MGCP GatewayRegistration Process





CHAPTER 2


TABLE 2-2 MGCP Unregister Error Reason Codes

Value Definition

1 Unknown

2 NoEntryInDatabase

3 DatabaseConfigurationError

4 DeviceNameUnresolveable

5 MaxDevRegExceeded

6 ConnectivityError

7 InitializationError

8 DeviceInitiatedReset

9 CallManagerReset

10 DeviceUnregistered

These reason codes can provide some insight into what might have caused the problem you are seeing. One of the bestways to verify that the MGCP gateway has registered to the CallManager is to use the show ccm-manager command.The following is an excerpt from the output from this command:

Pod1HQ#show ccm-manager

MGCP Domain Name: Pod1HQ

Priority Status Host

============================================================

Primary Registered 10.1.1.2

First Backup Backup Ready 10.1.1.1

Second Backup None

Current active Call Manager: 10.1.1.2

[ 36 ]







CHAPTER 2


The following are other commands that are useful when troubleshooting IOS MGCP gateways:

n show mgcp endpoint: Displays information for endpoints that are controlled using MGCP

n show mgcp connection: Displays information for active connections that are controlled using MGCP

n show mgcp statistics: Displays MGCP statistics about received and transmitted network messages

n show mgcp srtp {detail|summary}: Displays information for active SRTP connections controlled using MGCP

n debug mgcp: A full suite of debugging messages for MGCP errors, endpoints, events, and many others

Figure 2-7 shows a sample configuration of an MGCP gateway and some explanations for the commands used.

H.323 and SIP Gateway Troubleshooting

H.323 and SIP gateways require different troubleshooting techniques than those used by MGCP. Because these protocolsoperate in a peer-to-peer mode, they will never register to Cisco Unified CallManager. Their status will always show asunknown in the administration tool. They also require the dial plan to be configured on the gateway and on theCallManager. Troubleshooting dial plans are covered in the next section.

[ 37 ]







CHAPTER 2


[ 38 ]



Hostname of gateway

Enables MGCP for PRI

First choiceCisco Unified CM

Second choiceCisco Unified CM

TFTP server to getconfiguration from

Enables PRI backhaulingof the Q931 signaling

Enables MGCP forthe analog port

HQ–1 #show run | begin mgcp

mgcp

mgcp call-agent 10.1.1.2

mgcp dtmf-relay voip codec all mode out-of-band

mgcp rtp unreachable timeout 1000 action notify

mgcp modem passthrough voip mode cisco

mgcp package–capability rtp-package

mgcp package–capability sst-package

no mgcp timer receiver-rtcp

!

ccm-manager redundant-host 10.1.1.1

ccm-manager mgcp

ccm-manager config server 10.1.1.1

cmm-manager config

!

controller T1 0/1/0

framing esf

linecode b8zs

pri-group timeslots 1-24 service mgcp

!

interface Serial0/1/0:23

no ip address

isdn switch-type primary-ni

isdn incoming-voice voice

isdn T306 30000

isdn bind-13 ccm-manager

no cdp enable

!

dial–peer voice 999200 pots

service mgcpapp

port 2/0/0

FIGURE 2-7

IOS MGCP GatewayConfiguration





CHAPTER 3

Call Setup Issues

Call Setup Issues IntroductionMany types of problems can occur during call setup. The following are some examples of this class of problem:

n Fast-busy tone during or at the end of dialing

n Caller ID missing or incorrect

n No ringback

n Dead air

n One-way audio

n Inefficient call routing

n Secondary dial tone not functioning

The first step toward narrowing down potential problems is to decide whether the call is happening at a single site, isdestined off-site or over an intercluster trunk, or whether it is being routed through an H.323 gatekeeper. The followingparagraphs discuss each of these topologies in depth and present some of the associated issues and resolutions that canoccur.

On-Premise Single-Site Calling IssuesThe first area of discussion is for calls that originate and terminate within the same cluster at the same site. The two mostcommon causes of problems in this topology are Class of Service settings or translation patterns. Class of Service isimplemented in CallManager using partitions and Calling Search Space (CSS). It is important to understand howCallManager collects and analyzes digits before attempting to troubleshoot its operation. Here is the operation for digitcollection on Cisco Unified CallManager:

Step 1. Digits are analyzed one at a time as they are entered.

Step 2. If an explicit match is found and no other potential matches exist, the pattern is used.

[ 39 ]







CHAPTER 3

Call Setup Issues

Step 3. If an explicit match is found and other potential matches exist, the call must wait for the interdigit timeout toexpire before the call is extended.

Step 4. If no explicit matches exist, the pattern with the fewest number of potential matches globally will be used.

Step 5. If no potential matches exist, either a fast-busy or an Annunciator message will be played.

Class of Service Constructs

PartitionsA partition is a setting that can be applied to all things that can be called. Directory numbers, route patterns, and transla-tion patterns are all examples of objects that have a partition setting. If the partition is set to “null,” there will not be anyrestrictions on who can call the DN.

Calling Search SpaceA calling search space is a list of partitions that can be called by the object that has the CSS applied to it. A CSS isapplied to phones, endpoints, lines, and gateways. If the CSS setting is blank, the only partition it can reach is the “null”partition.

When a CSS is applied to a phone, you can apply it either to the device or to the line. If there is a setting at the line level,it will override the device-level setting. If there is no line setting, the device setting will be used.

On-Premise Call Setup Failure

There are relatively few common reasons for call setup failure in this topology. The main categories are as follows:

n Digit manipulation via a translation pattern is incorrect.

n The target is not known or not currently registered.

n The partition of the destination is not in the CSS of the calling phone.

[ 40 ]



NOTE

Cisco UnifiedCallManager looks atboth internal directorynumbers and externalroute patterns whenlooking for a match.Understanding theoverlap between thesetwo items in your dialplan is key.





CHAPTER 3

Call Setup Issues

Incorrect digit manipulation can either cause the call to fail by translation to an invalid number, or it can cause a loop. IfCisco Unified CallManager detects a loop that would infinitely change a number back and forth between two patterns, itplays a fast-busy tone after a short delay. If you are unsure what is happening to a digit string after dialing, the DialedNumber Analyzer tool provides a convenient way to test how a given digit string will be handled by a given callingsearch space.

Sample Problems

One-way CallingAnother common problem is when Phone A can call Phone B, but Phone B cannot call Phone A, as seen in Figure 3-1.This is usually seen when the CSS of Phone A includes the partition of Phone B’s line, but the CSS of Phone B does notinclude the partition of Phone A’s line.

Call Forwarding IssuesWhen you are seeing issues with call forwarding, check to make sure that the destination is valid and registered and thatit is contained in the CSS of the phone. If you are having issues when forwarding to voice mail, check the Call ForwardNo Answer (CFNA) settings and verify the correct partitions and CSS. It is also possible that the voice-mail server isdown or that all its ports are currently in use.

[ 41 ]



A

OK

B

XFIGURE 3-1

One-way Calling





CHAPTER 3

Call Setup Issues

Off-Site Call IssuesWhen calling off-site, the call must go through a gateway. There are three protocols that gateways use for call control:MGCP, H.323, and SIP. The Cisco IOS MGCP gateway registration issues have been covered already, so this sectionfocuses on call control troubleshooting. Understanding how your dial plan is configured will reduce the amount of timespent troubleshooting when you run into problems. The following are some common off-site calling issues are listed:

n Cisco Unified CallManager Issues

n Dial plan configuration errors

n Codec issues with the region settings

n Location settings configuration issues for CAC

n Gateway Issues

n MGCP, H.323, or SIP configuration errors

n Problems with QoS settings on WAN link

n All trunks in use or trunks down

Gateway Troubleshooting Checklists

Use the following guides when troubleshooting gateways for the three gateway protocols: MGCP, H.323, and SIP.

MGCPn Verify configuration on the IOS MGCP Gateway

n Verify mgcp commands

[ 42 ]







CHAPTER 3

Call Setup Issues

n Verify ccm-manager commands

n If a PRI is in use, verify Q.931 backhaul

n Verify gateway configuration in CallManager

n Verify the hostname is accurate

n Check endpoint configuration

n Registration verification commands

n show ccm-manager

n show mgcp endpoint

n show mgcp statistic

n Call setup verification commands

n show mgcp connection

n debug mgcp error

n debug mgcp packet

n debug mgcp state

H.323n Verify configuration on the IOS H.323 Gateway

n Verify dial peer commands

n Verify that the voice class H.225 timeout for TCP is set to 3 seconds or less

n Verify CallManager preference order

n Check H.323 binding

[ 43 ]







CHAPTER 3

Call Setup Issues


n Verify network settings on the gateway

n Check route pattern, lists, and groups

n Digit send/receive verification commands

n show dialplan number number

n debug vtsp session

n debug vpm signal

n debug mgcp state


n debug voice ccapi inout

n debug voip dialpeer inout

n debug cch323 h225

n debug h225 q931

SIPn Verify configuration on the SIP gateway

n Verify VoIP dial peers have SIP version 2 enabled and a valid session target

n Verify SIP UA retry settings

n Verify DTMF relay method


n Ensure that the SIP trunk is configured and an IP address is the destination

[ 44 ]







CHAPTER 3

Call Setup Issues


n show sip-ua status

n show sip status

n show sip statistics

n debug ccsip messages

Dial Peer Matching

For all calls going through a Cisco router, IOS associates one dial peer to each call leg. There are two types of dialpeers—POTS, for calls associated with TDM call legs, and VoIP dial peers for IP call legs.

Inbound Dial Peer MatchingTable 3-1 describes how dial peers match elements in the setup message with dial peer attributes. IOS performs tasks inthe order shown.

TABLE 3-1 Inbound Dial Peer Parameters

Setup Message Element Dial Peer Parameter Comments

Called number (DNIS) Incoming called-number A direct match is attempted between the number that was dialed and a configured called number

Calling number (ANI) Answer-address Useful when you want to match calls based on calling number

Calling number (ANI) Destination-pattern Calling number with destination-pattern is attempted

Voice Port Dial peer port A match between dial peer port and voice port is attempted last

[ 45 ]







CHAPTER 3

Call Setup Issues

If no match is made, IOS will use the default dial-peer 0.

The following is an example of an incoming POTS dial peer configured with Direct Inward Dial (DID):

dial-peer voice 1 pots

incoming called-number 81690

voice port 0:D

direct-inward-dial

Outbound Dial Peer MatchingOutbound dial peers match using the destination-pattern command. You also must specify a port for POTS dial peersand a session target command for VoIP dial peers. Wildcards can also be used to match ranges of numbers. Here is anexample of an outbound VoIP dial peer configuration:

dial-peer voice 4 voip

destination-pattern 81690

session target ipv4:172.22.10.1

The destination-pattern command functions differently for inbound and outbound dial peers. For inbound dial peers itmatches the calling number (ANI). For outbound dial peers it matches the called number (DNIS).

Route Plans

The components of a route plan in Cisco Unified CallManager have the following characteristics and have the relation-ships shown in Figure 3-2.

n Route Pattern: An E.164 address or range of addresses. The route pattern points to a route list or a device and canalso perform digit manipulation.

[ 46 ]







CHAPTER 3

Call Setup Issues

n Route List: Directs calls to one or more route groups.

n Route Group: Directs calls to one or more devices that allow call routing.

n Device: Typically a gateway, H.323 endpoint, or trunk.

When configuring the route plan, you must create it in reverse order so that the correct options will appear in the menus.CallManager processes calls in a top-down order, as shown in Figure 3-2.

[ 47 ]



User Dials Number

Route Pattern

Route List

Route Group

Device(Gateway/Trunk)


Route Group

1stChoice

2ndChoice

1stChoice

2ndChoice



1stChoice

2ndChoice

FIGURE 3-2

Route Plans in CiscoUnified CallManager





CHAPTER 3

Call Setup Issues

Common Problems

Caller ID IssuesCaller ID refers to a method that provides calling party information. Different methods are used for analog and digitalsignals; therefore, determining the point of failure is the first step to troubleshooting Caller ID issues. There are a fewthings to keep in mind when working with Caller ID:

n Caller ID is not supported on MGCP controlled FXS ports.

n Calling parties may block Caller ID.

n An H.323 gateway or CallManager ICT may be configured to block Caller ID.

n FXS ports have Caller ID disabled by default. Caller-id enable in the voice port config will enable it.

n Caller ID can be blocked using the caller-id block command in the voice port config.

No Ringback IssuesWhen an ISDN call is being established, the call might not go through due to some issue. When such a situation occursand ringback is not heard, a progress indicator is returned to the calling user. These ISDN progress indicators aredescribed in Table 3-2.

TABLE 3-2 ISDN Progress Indicators

PI Meaning Message Type

0 No progress indicator included Setup

1 Call not end-to-end ISDN; check in-band for more info Alert, setup, progress, connect

2 Destination address is non-ISDN Alert, progress, connect

3 Origination address is non-ISDN Setup

8 In-band information or appropriate pattern is available Alert, progress, connect

[ 48 ]







CHAPTER 3

Call Setup Issues

A common problem seen on gateways is when a Cisco IP Phone user makes an off-site call and does not hear a ringbacktone. The issue in this scenario is that CallManager automatically changes the audio of the phone to the H.323 gateway assoon as the channel signal is complete. The IP Phone did not hear the ringback tone because the PSTN did not provide aPI indicating that in-band information was available. Cisco Unified CallManager relies on in-band ringback when usingH.323 gateways.

The solution is to add the progress_ind alert enable 8 command in the POTS outbound dial peer. Per Table 3-2, this willchange the PI accordingly.

Dead Audio IssuesTwo-way dead audio describes the problem when a call is set up properly but neither party hears audio when the phone isanswered. This is generally the result of a codec mismatch or firewall settings. Ensure that the codecs match or thatproper transcoding resources are in place if different codecs are to be used. Verify that all firewalls in the media streampath are not filtering out RTP packets.

One-way audio is another possible problem you could encounter. This is generally the result of NAT issues but can alsobe the result of H.323 or MGCP binding, cRTP settings, or answer supervision settings.

Dropped CallsWhen a call is dropped in the middle of the call, there is always a definite reason for it. The following are some of thepossibilities:

n The remote user hung up or lost a signal on a cell phone.

n The network lost connectivity (sometimes due to a power outage or maintenance).

n A system error occurred.

[ 49 ]



NOTE

It is possible to setspecific progress indica-tors in ISDN messagesusing the progress_inddial-peer command.





CHAPTER 3

Call Setup Issues

The first place to look when diagnosing dropped call problems is the system logs. If an unregistration event occurred, thiswill appear in the CallManager system logs. Call Detail Records (CDR) can also be used to determine which side hungup. If you are able to reproduce the problem, you can also enable traces on the CallManager server.

Secondary Dial ToneWhen a user presses “9” for an outside line, it is customary to provide a different type of dial tone to inform the user thatthe call will be routed outside the local phone system. Sometimes you might find that when dialing “912065551212,” youdo not hear the secondary dial tone until the sixth digit is pressed. This occurs when there are overlapping dial plans,usually for route patterns such as 91XXX. The “Enable Secondary Dial Tone” box must be checked on all route patternsstarting with “9” to resolve the issue.

Troubleshooting Intercluster Dial Plan IssuesIn large voice networks, some designs employ multiple CallManager clusters. These designs generally use both WAN andPSTN links for routing calls between the clusters. There are some unique problems that can occur with a topology suchas this one.

Overlapping Dial Plan

Probably the most common configuration issue in a multicluster CallManager environment is an overlapping dial plan.This occurs when two or more patterns match a set of dialed digits. This causes CallManager to wait for additional digits15 seconds by default before completing the call. For example, if you have router patterns for both 911 and9.1XXXXXXXXXX, you will experience the delay mentioned. This can be resolved by changing the second routepattern to 9.1[2-9]XX[2-9]XXXXXX. Careful attention to the dial plan eliminates most, if not all, these types of problems.

Call Setup to Another Cluster

If calls over the ICT are not working properly, you could have one of the following causes:

[ 50 ]







CHAPTER 3

Call Setup Issues

n Partition or CSS configuration settings on either the originating or remote phone

n Digit discard, prefix, or transformation mask settings

n Dialed number is not valid

n ICT configuration settings

n Connectivity between the two clusters

If calls are being routed to the PSTN first instead of the WAN, it is most likely an ICT configuration issue. It is also agood idea to check the dial plan configuration on CallManager to ensure that it is sending the call the correct way.

Immediate Remote Call Drops

If a call to a phone at the remote site drops immediately after the remote user picks up the handset, the problem is notwith the dial plan. The most common problem with this symptom is a codec mismatch between the two endpoints.Invoking a transcoder resource will resolve the problem, as will switching the codecs to match on both ends.

Troubleshooting Gatekeeper IssuesA gatekeeper is an H.323 device on the network that provides services such as address translation and network accesscontrol for H.323 terminals and gateways. To troubleshoot a network that contains gatekeepers, you must understand thedifferent registration, admission, and status (RAS) messages they use. Once you have a firm understanding of how theyfunction, the common issues tend to fall into three categories:

n Discover and registration process

n Call admission

n Gatekeeper clustering and alternative gatekeeper issues

[ 51 ]







CHAPTER 3

Call Setup Issues

The following sections first review how gatekeepers are deployed and some of the RAS messages they use, and thenapproach some of the common problems.

Gatekeeper Processes

DiscoveryThere are two processes by which H.323 gatekeepers are discovered:

n Unicast Discovery: Endpoints are configured with the gatekeeper IP address and attempt to register immediately.UDP port 1718 is used and the gatekeeper replies with a Confirmation (GCF) or Rejection (GRJ) message.

n Multicast Discovery: Endpoints use UDP multicast address 224.0.1.41 to send a Request (GRQ) message. The gate-keeper replies with the same messages as it would in Unicast mode.

RegistrationRegistration is used after the discovery process by gateways to join a zone and inform the gatekeeper of their IP and aliasaddresses. Each gateway can register with only one gatekeeper, and there can be only one gatekeeper per zone. A gatewayregisters with an H.323 ID defined using the command h323-gateway voip id H323-ID ipaddr ip-address. A fewcommon registration issues are caused by unauthorized IP addresses, duplicate H.323 IDs, invalid security settings, ornonexistent zones.

AdmissionAdmission messages provide the basis for call authorizations and initial bandwidth control. A registered gateway sends anARQ message requesting call admission to a given endpoint. If bandwidth is available, an ACF message is sent back tothe initiating endpoint. The endpoint then attempts to set up a call directly with the destination endpoint. When the desti-nation receives the request, it checks with the gatekeeper to ensure bandwidth is available. The gatekeeper then returns an

[ 52 ]







CHAPTER 3

Call Setup Issues

ACF message and the call is set up. At any point in this flow, if bandwidth is not available, an ARJ message is sent withthe appropriate reason.

Bandwidth ControlBandwidth is initially requested through the Admission process defined earlier. If bandwidth needs to change during thecall, an endpoint can send a BRQ message to the gatekeeper. If bandwidth is available, the gatekeeper will respond with aBCF message. If bandwidth is not available, a BRJ message will result.

Location Request and RIPLocation Request (LRQ) messages are sent between gatekeepers to request a terminating endpoint. Figure 3-3 showslocation request usage between gatekeepers. You can also scale the network to larger sizes by using a directory gate-keeper, which has the ability to forward an LRQ message to a destination gatekeeper.

[ 53 ]



GK

V

GKGatekeeper A

1. ARQ3. RIP5. ACF 9. ACF

8. ARQ

Gatekeeper B

Endpoint B

Endpoint A

2. LRQ

4. LCF

6. Call Setup

7. Call Proceeding

10. Alerting

FIGURE 3-3

Location RequestUsage





CHAPTER 3

Call Setup Issues

DisengageA disengage request is used to inform a gatekeeper that a call has ended. Acceptance occurs with the DCF message, andrejection occurs with the DRJ message.

Troubleshooting show and debug Commands

show Commandsn show gatekeeper gw-type-prefix: Displays information about the configured prefix technology table

n show gatekeeper status: Displays overall gatekeeper status including zone status

n show gatekeeper zone prefix: Displays the zone prefix table

n show gatekeeper calls: Displays the status of each outgoing call the gatekeeper is aware of

n show gatekeeper endpoint: Displays the status of registered endpoints

n show gatekeeper zone cluster: Displays the members of the cluster and the current bandwidth utilization

debug Commandsn debug h225 asn1: Displays the actual contents of H.225 RAS messages

n debug ras: Displays the types and addressing of RAS messages sent and received

Common Problems

Gateway not Registering to GatekeeperAssuming you have proper network connectivity and can ping the gatekeeper from the gateway does not ensure thatmulticast routing is configured for discovery. Attempt unicast discovery if you suspect a multicast routing failure. Other

[ 54 ]



NOTE

The “bandwidth in use”displayed can be veryuseful when trouble-shooting call setups.





CHAPTER 3

Call Setup Issues

common registration problems are usually the result of a configuration error. Check the configuration settings for thefollowing:

n Duplicate H.323 IDs

n IP addresses not authorized to register

n Security settings mismatch

n Attempted registration with a nonconfigured zone

Here is a sample gatekeeper configuration:

gatekeeper

zone local HHQQ--11 cisco.com 1100..11..225500..110011 ***Verify zone name and IP address on the local gatekeeper.

zone remote DGK cisco.com 10.0.0.99 1719

no zone subnet HQ-1 ddeeffaauulltt enable

zone subnet HQ-1 1100..11..225500..00//2244 enable ***Verify the endpoint is allowed to register for the given zone.

zone prefix HQ-1 1...

zone prefix HQ-1 501*

zone prefix DGK *

gw-type-prefix 11##** default-technology ***Verify the technology prefix

bandwidth interzone default 256

bandwidth session default 256

bandwidth session zone HQ-1 256

nnoo sshhuuttddoowwnn ***Verify the gatekeeper is enabled.

Another important area to check is the Cisco Unified CallManager configuration for gateways and trunks. Ensuring thatthe correct gatekeeper, terminal type, technology prefix, and zone here matches the gatekeeper configuration can resolveconfiguration issues. If you are using a standalone gateway, verify that these items also match in the configuration of thegateway. Here is a sample configuration for a gateway:

[ 55 ]







CHAPTER 3

Call Setup Issues

interface Loopback 0

ip address 10.1.250.101 255.255.255.0

h323-gateway voip interface

h323-gateway voip id HQ-1 ipaddr 10.1.250.101 1718

h323-gateway voip h323-id HQGateway-1

h323-gateway voip tech-prefix 1#

h323-gateway voip bind srcaddr 10.1.250.101

!

dial-peer voice 1 voip

destination-pattern ....

session target ras

!

dial-peer voice 2 pots

destination-pattern 1611

port 1/1/1

no register e164

!

gateway

If verifying the configuration fails to resolve your problem, check gateway debugs or CallManager traces to determinethe point of failure in the process described above.

Call Admission IssuesIf you have verified that both endpoints are registered and calls are failing, you might have one of the following problems:

n Lack of bandwidth due to CAC configuration

n Connectivity issues between endpoints, but not to the gatekeeper

[ 56 ]







CHAPTER 3

Call Setup Issues

n Gatekeeper IP address misconfiguration

n Gateway dial peer misconfiguration

Applicable show commands, such as show gatekeeper zone status, show dial-peer voice summary, show gatekeeperzone status, and the debug commands described earlier, can help narrow the root cause of the problem.

Admission RejectionThe two most common reject reasons that you see in an ARJ message are calledPartyNotRegistered andrequestDenied. The first indicates that the gatekeeper has no information on where the called number endpoint islocated. Use the show gatekeeper zone status command to determine whether the endpoint is registered. The secondmessage, requestDenied, indicates that there is not sufficient bandwidth available to extend the call.

Gatekeeper Clustering Issues

When multiple gatekeepers are used together in a cluster, issues sometimes arise related to failover. Most often theseissues are due to a loss of network connectivity or a configuration error. If you have used ping to determine propernetwork connectivity across the cluster, try the following show and debug commands:

n show gatekeeper zone cluster: Displays the status of all local clusters, including the Alternate Gatekeeper function.

n debug gatekeeper gup: Displays packets for the Gatekeeper Update Protocol and can easily indicate a mis-configuration.

[ 57 ]







CHAPTER 4

Voice and Video Quality Issues

Defining Common Voice and Video Quality IssuesWhen voice, video, and data are converged onto the same network infrastructure, it becomes important to ensure properquality of service. Voice and video are both sensitive to latency and packet drops, and require guaranteed bandwidth endto end across the network. It is important to remember that communication will operate only as fast as the slowestcommunication link the traffic must pass. We will now address the various types of problems that voice and video trafficencounter in a network

Delay

End-to-End DelayThe total delay across the network is the sum of the following factors:

n Propagation delay across the transmission media (~40ms coast to coast in the USA)

n Serialization delay to clock all the bits onto the wire

n Processing and queuing delays within a router

JitterJitter is the variation in the delay of received packets. This can be caused by network congestion, poor queuing, orconfiguration errors. Ensure that you have a QoS-capable WAN link with jitter guarantees and that you have your linksettings set appropriately. Implementing fragmentation and interleaving as well as proper queuing will generally reduce oreliminate jitter.

[ 58 ]







CHAPTER 4


Packet Loss

Packets are usually lost when routers run out of buffer space on a given interface. Other reasons include CRC errors,High CPU issues, or WAN link errors. Use the following methods to prevent packet drops:

n Increase link capacity to reduce congestion.

n Drop packets of less critical applications.

n Verify QoS settings on WAN links and switches.

n On Frame Relay links, use shaping to minimize loss.

n Configure policing to prevent certain types of traffic from dominating an interface.

QoS Requirements

Consult Table 4-1 for details on QoS requirements for voice and video. Note that voice has very small packets and a lowamount of required bandwidth, while video has much larger packets and higher overall bandwidth requirements. Data isless critical but still dependent on the application using it. Different types of data can be assigned different priority levelsacross the network. Ensuring that proper measures have been taken to set up LAN QoS is also important to reduce buffercongestion issues.

TABLE 4-1 Voice and Video Quality of Service Requirements

Voice Video

Latency < 150ms < 150ms

Jitter < 30ms < 30ms

Loss < 1% < 1%

Minimum Priority Bandwidth (One-Way) 17–106 kbps Video Stream + 20%

[ 59 ]







CHAPTER 4


VoIP Quality ProblemsVerifying that voice quality is good across the network will ensure the success of the Unified Communication System.Troubleshooting voice quality problems can be difficult. They can be intermittent, and perceived quality can be verysubjective. Here are some good questions to ask when you begin troubleshooting voice quality problems:

n Has it ever worked?

n Were there any error messages displayed or heard?

n When did it happen?

n Did something change recently?

n Can you localize the problem to a device, calling direction, or subnet?

After you have answered these questions, look at a network diagram or make a call flow diagram to understand all thedevices in use. This can prevent unnecessary work by eliminating devices not involved.

Layer 2 Voice Quality Problems

Buffers, not bandwidth, tend to create the main problem on switched Layer 2 networks. These buffers can fill instantlyduring times of traffic congestion. Switches use weighted random early detection (WRED) to drop lower-priority traffic,letting high-priority traffic such as voice or video pass into the queue. The command auto qos voip cisco-phone appliedto an interface will set up the switch to give priority to traffic tagged out of an IP Phone.

When troubleshooting QoS on a Cisco Catalyst switch, the command show mls qos interface interface-type interface-number queueing will display the queues that have been set up along with any marking that is being performed. Tomonitor packets that arrive with a particular DSCP value, use the command mls qos monitor dscp dscp-value on theinterface desired, followed by the show mls qos interface interface-type interface-number statistics to view how manydrops have occurred on the interface.

[ 60 ]



NOTE

Success in troubleshoot-ing voice quality prob-lems is largely dependentupon asking the rightquestions. Try to get asmuch detail as you canfrom the users beforelooking at configurationsand debugs.





CHAPTER 4


Gateway Voice Quality Problems

Here are some common issues that appear on gateways:

n Duplex and speed mismatches

n Bandwidth across slow WAN links

n Link Fragmentation and Interleaving (LFI): Generally used on circuits with speeds slower than 768 kbps due tolarge packets causing excessive latency

n Low latency queuing (LLQ) bandwidth settings

n WAN interface configuration

n Service provider SLA

Multilink PPP Interface ConfigurationOn slower PPP serial interfaces, use the command ppp multilink fragment delay delay-in-ms to set the maximum serial-ization delay to 10 ms via automatic fragmentation. The command ppp multilink interleave will allow high-prioritypackets to be sent between two fragments to minimize delay and jitter. It is also important to add the service-policyoutput policy_name command for a given QoS policy map.

Verify the configuration using the following commands:

n show interfaces multilink interface-number

n debug ppp multilink fragments

[ 61 ]



NOTE

Gateways are often avery likely cause ofquality issues becausethey aggregate differentmedia types for voicetraffic.





CHAPTER 4


Frame Relay Configuration RecommendationsThe following are some recommended settings for Frame Relay PVCs:

n Minimum CIR should be equal to the CIR of the link

n Committed burst (Bc) is 1/100 of CIR

n Excess Burst (Be) is set to zero

n Interleave voice packets with fragmented data packets

n Apply LLQ to the interfaces

Here is a sample Frame Relay configuration:frame-relay cir 512000

frame-relay bc 5120 *** Committed burst is set to 1/100 of CIR

frame-relay be 0

frame-relay mincir 512000

frame-relay fragment 80

service-policy output DFW-to-SJC

class-map match-all VOICE-CTRL-OUT

match ip dscp cs3

class-map match-all VOICE-OUT

match ip dscp ef

class-map match-all VOICE-CTRL

match access-group name VOICE-CTRL

policy-map DFW-to-SJC

class VOICE-OUT

priority 128

class VOICE-CTRL

bandwidth percent 5

class class-default

fair-queue

[ 62 ]







CHAPTER 4


Use the following commands to verify and troubleshoot your Frame Relay QoS configuration:

n show frame-relay fragment [interface interface [DLCI]]: Displays FR fragmentation statistics.

n show frame-relay pvc [interface interface] [DLCI]: Displays statistics for PVCs on Frame Relay interfaces.

Phone Tools

The Quality Report Tool (QRT) enables users to report problems to administrators as they happen. When a user is experi-encing a problem, he simply presses the QRT button on his IP Phone and selects the type of problem he is having. Toconfigure this, the softkey template must be changed on the phone, and the reports must be able to be viewed in RTMT.This allows users to easily provide administrators with the problem they are having along with an exact timestamp.Pressing the “i” or “?” button twice on Cisco IP Phones will display some voice quality troubleshooting data such aspacket counts, codec, jitter, and dropped and discarded packets. These statistics can also be logged in the Call DetailRecord database by enabling Call Diagnostics in System > Service Parameters from the web-based administrator toolon Cisco Unified CallManager.

Voice Activity Detection

When sending calls over a WAN, you generally want to use as little bandwidth as possible while still maintainingadequate voice quality. Voice Activity Detection (VAD) can maximize bandwidth by not sending any packets that containsilence across the network. VAD can save substantial bandwidth, but it can also cause problems. Sometimes VAD takes amoment to detect the beginning of speech and results in the first part of a word being cut off. This can be irritating tosome people and might not be acceptable for your network.

[ 63 ]







CHAPTER 4


Troubleshooting EchoTalker echo is the sound of your own voice in the telephone receiver while you are talking. When this echo exceedsapproximately 25 ms, it can be distracting to users. Listener echo can also occur, which occurs when the remote partyhears your voice twice when you speak. Most echo problems can be solved at the gateway. Both H.323 and MGCP gate-ways have options to assist in reducing echo. Here are some questions to ask when you begin troubleshooting echo:

n Does the echo occur between IP Phones?

n Are speakerphones involved?

n Who is hearing the echo?

n Is there any pattern to when the echo is heard (outside calls, one number, all the time, and so on)?

n What types of gateways and protocols are being used?

Sources and Types of Echo

Talker EchoTalker echo occurs when the speech of a person talking is coupled with the receiving path at the far end, resulting in thetalker hearing their own voice delayed by the path time. If this signal has large enough amplitude and delay, it can bequite annoying. This type of echo is usually the result of impedance mismatch in a two-wire to four-wire conversiontaking place through hybrid transformers.

Receiver EchoWith receiver echo, the voice of the talker is echoed by the far end hybrid transformer. Then, when the echo is returning,it is echoed back to the listener. This results in the person listening hearing both the person talking and their echo.

[ 64 ]







CHAPTER 4


Echo Cancellation

Echo cancellers come standard on IOS Release 12.3(4)XD and later on all but the AS5300 series gateways. They faceinto the PSTN side on a gateway and capture, as well as store, the outgoing signals heading toward the hybrid trans-former. The echo canceller then looks at the Rx side for echo. When echo is detected, an inverse waveform (that is, awaveform 180 degrees out of phase from the echo waveform) is superimposed on the Rx path to cancel out the echowaveform. When one side is silent, the residual echo is replaced with comfort noise based on the actual noise on the line.Echo cancellation is implemented in DSP firmware for analog lines and is built in to the codecs for packet-basednetworks.

The echo canceller is enabled by default and provides a couple of commands to tweak its operation. The voice portcommands are

n echo-cancel coverage {8 | 16 | 24 | 32 | 48 | 64}: Adjusts the size of the echo canceller buffer

n echo-cancel erl worst-case {0 | 3 | 6}: Determines what amount of echo activates the echo canceller in dB (default 6)

Measuring and Adjusting for Echo

There are various methods for measuring echo in a Unified Communications System. The IP Phone can be configured togenerate a test tone; signal levels can then be compared on the gateways to set the ERL levels properly. Using the showcall active voice command on the gateway will show input and output signal levels. If these are not equal, you can adjustthe input and output attenuation levels such that the echo canceller performs properly.

On the Cisco Catalyst 6608 Voice Gateway, this process is a little different. Using the show port voice [mod/port]command will allow you to view the statistics needed to make proper attenuation adjustments based on the test tone.Keep in mind that adjusting attenuation levels can have an effect on the voice-mail system.

[ 65 ]







CHAPTER 4


Quality Problems with Cisco Unified VideoAdvantageCisco Unified Video Advantage (UVA) has quite a few requirements to bring instant video telephony to the desktopcomputer. Some of the most common problems and their solutions are listed next.

Verify Hardware and Software

The computer running UVA must be at least 1 GHz and have 256 MB of RAM. If the computer does not meet theserequirements, the software will not install. The system also requires that the desktop computer be plugged in to the switchport on the back of a 7940/41/60/61/70/71 phone, have a Cisco UVA camera plugged in to a USB port, and be runningthe UVA software. The final requirement is that Cisco Unified CallManager be properly configured. CallManager musthave video capabilities enabled for the IP Phone device and is disabled by default. If all these requirements are not met,video calls will not be made.

CPU throttling software can also cause the computer to run at a clock speed slower than it is capable of running to savepower. This will also cause the installation to abort.

Setting Up a PC to Capture a System Crash

A system crash can occur when using or installing the Cisco Unified Video Advantage software. Installing Microsoft’sdebugging tool WinDbg can help diagnose problems with the software. The following drivers are used in UVA, andseeing these in the crash can help you isolate the problem:

n Cpmt.sys: Cisco Media Termination Driver

n CamDrC21.sys: USB camera driver for Windows XP

[ 66 ]







CHAPTER 4


n CamDRC20.sys and CamUSC20.sys: USB camera driver for Windows 2000

n CdpPacketWdmCvl.sys: Cisco Discovery Protocol packet driver

USB Out of Bandwidth

If Windows is giving error messages indicating that there are too many USB devices attached to a single port, the USBport might be out of bandwidth. If you do not have any spare USB ports, you will need to add a new host controller viaPCI or PCMCIA. The other solution is always to remove other USB devices.

Cisco Audio Session Tunnel (CAST) Traces

By opening Cisco Unified Video Advantage Diagnostics, you can open the CAST viewer, which provides a wealth ofinformation on the interactions occurring with UVA. You will be able to see whether the remote end is not video-enabled,if codecs were mismatched, or if conference resources were not available for the call. This tool is very valuable in deter-mining the cause of problems.

[ 67 ]







CHAPTER 5

Application Integration and Media Resources Issues

Common Cisco Unity Integration IssuesVoice mail is a very important tool used by businesses today. Issues you might run into on Unity integrated with CiscoUnified CallManager include Message Waiting Indicators (MWI) not working, call transfer issues, or auto-attendantmalfunctions.

Message Waiting Indicators

Common IssuesTwo events cause MWIs to toggle on or off. When a message is left for a subscriber, the MWI is triggered to turn on.After a subscriber is finished listening to the new messages, Unity deactivates the MWI. If there are new messages in thesubscriber’s inbox, the MWI should be activated; if there are no new messages it should be deactivated. It is important tonote that MWIs only activate for new voice messages. E-mail and fax messages do not cause MWI triggers. Some of thepossible causes for MWI issues are described in the following list:

n An inbox rule in Unity is moving voice messages to another folder upon arrival. Remove the rule so that the newvoice-mail messages stay in the inbox.

n CallManager Configuration Issues

n The voice-mail port CSS must include the partitions assigned to the MWI On and MWI Off directory numbers

n The MWI DNs CSS must also include the partition of the phones

n The MWI On and MWI Off fields are swapped or not configured to be the same extensions as those configuredin Cisco Unity

n Dial plan overlap with MWI DNs

[ 68 ]







CHAPTER 5


n Unity Configuration Issues

n Wrong phone system assignment for a subscriber

n MWIs are not enabled

n The wrong extension is entered in the subscriber’s configuration

n No voice-mail ports are configured for Dialout MWI

n Lack of available voice-mail ports

n Microsoft Exchange is offline

A useful tool for troubleshooting MWI issues on Cisco Unity is the Port Status Monitor. This is available in the ToolsDepot on the Unity server and will show real-time status of the voice-mail ports. The macro trace tool for MWI problemswill show when MWI ON and MWI OFF messages are being sent. This can indicate a problem with either the Unityconfiguration or the CallManager configuration, depending on what trace messages you see.

MWI ArchitectureThe four Cisco Unity Components shown in rectangles in Figure 5-1 work together to control MWIs. Here are the basicsteps taken by the system:

Step 1. Exchange Monitor receives a notification from the Exchange server when a change occurs in the Inbox of asubscriber when new voice messages arrive. Exchange monitor then sends an MWI activation message to theNotifier queue.

Step 2. The Notifier adds the MWI activation message as a request to the phone system.

Step 3. The Notifier queries the DOH to determine the status of the phone. If the MWI is already turned on, theNotifier discards the message.

[ 69 ]







CHAPTER 5


Step 4. The MIU receives the request and sends the message to the phone system. The phone system then respondswith the new MWI status to the Notifier.

This process is similar for the deactivation process. Understanding this architecture can assist you in turning on thecorrect traces when troubleshooting problems. Each component has its own set of traces for use when troubleshooting.

Exchange Server Unavailable IssuesIf the Exchange server is down, the Unity server will use the Unity Message Repository (UMR) to temporarily storemessages until it comes back online. If callers attempt to check voice mail while the server is down, they will only beable to hear messages stored in the UMR. When the server comes back online, Cisco Unity moves messages from theUMR to the Exchange server. All messages will appear as new and MWIs will be triggered. MWIs also might not func-tion when Unity is using UMR. To verify that the Exchange server is down, choose Start > All Programs >Administrative Tools > Services applet.

Delayed MWIThe primary causes for delayed MWI issues are the following:

n The Exchange server is unavailable (as discussed in the preceding section).

n No ports are currently available to send the MWI messages.

[ 70 ]



ExchangeMonitor

NotifierQueue

Notifier MIU

Exchange DOH

FIGURE 5-1

Cisco Unity Message-Waiting IndicatorsArchitecture





CHAPTER 5


n CallManager is sending callers to ports dedicated for MWI, tying them up.

n AppleTalk protocol was uninstalled from the Exchange server.

Call Transfer Issues

Callers may report not hearing a configured Auto Attendant or hearing the opening greeting instead of their voicemailbox when checking their messages. These problems are due to an incorrect call-routing configuration on either CiscoUnity or Cisco Unified CallManager. Here are some of the potential causes:

n A call-routing rule is overriding the system default rule.

n If multiple Unity installations are in use, the wrong voice-mail profile might be configured to a phone inCallManager.

n The user has set different call-forward settings.

n The subscriber has an invalid extension assigned.

Verifying the CallManager and Unity configurations for both the phone and the subscriber can generally resolve thesetypes of call-routing issues. The Port Status Tool mentioned earlier can also be very useful in troubleshooting these problems.

Computer Telephony Interface (CTI) IssuesWhen integrating Cisco Unified CallManager with applications such as Cisco Unity, Cisco Unified Contact CenterExpress, Cisco Unified IP-IVR, or Cisco Unified Customer Voice Portal (CVP), use virtual endpoints to provide theconnection to these applications. These endpoints are referred to as CTI ports in CallManager and can be grouped into aline group and numbered by using a CTI route point.

[ 71 ]







CHAPTER 5


CTI Manager

The CallManager CTI Manager is a program that allows applications to interface with the CTI components ofCallManager without having to be aware of the structure of the CallManager cluster. There can be multiple CTIManagers in a cluster, but only one CTI Manager per server. An application can also have connections to multiple CTIManagers, but only one can be used at a time to open a device with media termination. CTI Managers can also failover toone another in the event of a server outage.

CTI Quick Buffer Encoding (CTIQBE)

CallManager JTAPI and TSP both communicate with CTI Manager over CTIQBE. See Figure 5-2 for a diagram of theserelationships. When troubleshooting, remember that this protocol handles the communication between CallManager andCTI Manager.

[ 72 ]



Cisco UnifiedCallManager

Cisco Unified CallManagerCTI Manager Service

CTIQBEover

TCP/IP

CTI

Application

Application Provider

API (JTAPI)

Application TAPISVR

Application Provider

API (TAPI) TSP

FIGURE 5-2

CTI Manager CTIQBERelationships withApplications





CHAPTER 5


CTI Route Points and CTI Ports

The following devices can be controlled by CTI:

n Cisco SCCP and SIP IP Phones

n CTI Ports

n CTI Route Points

CTI Route points can answer, make, receive, redirect, hold, unhold, and drop calls and are considered the pilot points forCTI ports. You can also use JTAPI or TSP to control CTI route points, which can be configured with an infinite queuedepth to avoid busy signals.

CTI ports must exist in CallManager for call control with CTI. Each port can have only one active audio stream; this issimilar to how voice-mail ports work. If the port is in use, users attempting to use it will receive a busy tone.

Example Call Flow for a Basic IP IVR Application

Figure 5-3 shows a sample call flow for a basic IP IVR application. The following steps explain the process:

Step 1. The user dials the CTI route point directory number.

Step 2. Cisco Unified CallManager signals the IVR Auto Attendant via JTAPI that a call has arrived for the CTIroute point DN.

Step 3. The IVR application checks to see how many sessions and CTI ports are available. Because this is not acommunication flow, it is not represented in the figure.

Step 4. The IVR application associates the call with a CTI port and instructs CallManager to send the call to the CTIport.

[ 73 ]







CHAPTER 5


Step 5. The call arrives at the CTI port and the IVR accepts the call.

Step 6. The IVR application creates a task to handle processing the call. Like Step 3, this is also not a communica-tion flow and is therefore not represented in the figure.

Step 7. The Auto Attendant script answers the call using the “accept” step.

Step 8. A media stream is set up between the IP Phone and the Auto Attendant.

Step 9. The IVR server plays prompts, accepts user input digits, and directs the call.

Troubleshooting Tips

CTI ManagerWhen troubleshooting CTI Manager, ensure that the JTAPI version and/or TSP version match, both on the client and on CallManager. Ensure that proper IP connectivity is in place and that the CTI Manager service has been started andactivated.

[ 74 ]



IP IVR

2

4

5

7

1 8 9

Cisco UnifiedCallManager IVR

FIGURE 5-3

Example Call Flow forIP IVR





CHAPTER 5


CTI Ports and Route Points not RegisteredThe following are some of the possible causes for these ports not registering:

n Network connectivity or name resolution issues

n Incorrect credentials

n Incorrect device association

n JTAPI version mismatch, or incompatible CRS version

For CRS problems, a good place to start is the Subsystem Manager in Cisco CRS. This will allow you to verify that theengine subsystems are currently in service. The JTAPI configuration in CRS is also a good place to look in case settingsare not matched with settings in CallManager. If the correct devices are not associated with the JTAPI user, the systemwill also fail. Verify these settings in the Application User Information screen in CallManager.

If all else fails, try resynchronizing the integration in CRS by choosing Subsystems > JTAPI > Resynchronize. If youare still having problems at this point, it is probably a good idea to gather some traces on the CRS server. Viewing thisoutput can tell you how the CRS server is attempting to communicate with CallManager.

Troubleshooting Media ResourcesMedia resources on Cisco Unified CallManager can be either software-based running on the CallManager server, or hardware-based running on a gateway. These resources provide services such as annunciator, transcoding, conferencing,media termination (MTP), and music on hold (MOH). Transcoding can only be done in hardware, and annunciator andMOH can only be done in software. CallManager manages media resources using a model shown in Figure 5-4.

[ 75 ]







CHAPTER 5


Hardware-Based Media Resources

The follow are reasons why hardware-based media resources might have trouble registering with Cisco UnifiedCallManager:

n Network connectivity between the router and CCM

n Incorrect gateway or CallManager configuration

n DSP hardware failure

Generally, CallManager traces can be used to determine how interactions with the media resources are being handled.The IOS command debug dspfarm all can also provide information specific to the router. The RTMT is also a very

[ 76 ]



User NeedsMedia ResourceMedia

ResourceManager

MediaResourceGroup List

MediaResource

Group

MediaResource

Group

Assigned to Device

Media Resource3

Media Resource4

1stChoice

2ndChoice

Media Resource1

Media Resource2

FIGURE 5-4

CallManager MediaResourcesManagement





CHAPTER 5


useful tool when troubleshooting these types of registration issues. If you suspect DSP hardware failure, try using thecommand test voice driver and test dsp device to test and reset the hardware.

Software-Based Media Resources

If software-based media resources are having trouble registering, ensure that media resource is enabled using the systemparameter settings in CallManager. Also, check the control center on the Serviceability web interface to ensure that theCisco IP Voice Media Streaming App is started. If software resources seem hung, a reset of this service will generally getthings going again. The RTMT and CallManager traces can also be used to troubleshoot these types of problems.

[ 77 ]







ccvp tuc quick reference sheets (digital short cut)

Documents

usb camera driver

outbound dial peers

voip dial peers

media resources issuesn

unified communications system

multiple cti managers

microsoft active directory

media resources issues