It is important to ensure that all the people in the organization who are responsible for managing the IPT network are notified of new software releases related to voice products as and when they become available. You can sign up for the Cisco Voice Technology Group subscription tool, available at the following URL, to receive notifications on the new OS service releases, CallManager, and other applications availability:

http://www.cisco.com/cgi-bin/Software/Newsbuilder/Builder/VOICE.cgi

You also should sign up to receive security field notices from Cisco. For procedures on subscribing, refer to the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html#SecurityInfo

Before you perform software upgrades on CallManager servers or any other Cisco AVVID application servers, such as Cisco Unity or CRA, stop the antivirus software scanners and third-party monitoring tools and disable Cisco Security Agent (CSA) if it is running.

Use the following steps to disable CSA:

To disable McAfee VirusScan:

Cisco recommends that you not perform upgrades via Microsoft Terminal Services Client. Instead, perform upgrades via Virtual Network Computing (VNC) or directly from the console. VNC software is bundled along with CallManager. It is available under the C:UtilsVNC directory on the CallManager servers. For security reasons, you should disable VNC during normal operations. When you need to perform upgrades, use Windows Terminal Services to enable VNC and then disable it after the upgrade is complete. For upgrades, or whenever a reboot is required, always make sure to have a local resource around to work directly on the server console, if required.

In most cases, software upgrades to servers require a reboot. This causes some interruptions to the call processing. Therefore, make sure to do the following:

The server reboots during upgrades cause devices such as IP phones, gateways, and media resource devices to unregister and reregister with the servers. Therefore, before you begin the upgrade, make a note of the number of devices registered to each CallManager server by monitoring the following performance counters, the names of which are self-explanatory:

You can use either the Performance Monitor application that comes with Windows 2000/2003 or the Real-Time Monitoring Tool (RTMT; refer to the “Real-Time Monitoring Tool” section, later in this chapter) to collect this information. The registered device counts taken after the upgrade should closely match the counts taken before the upgrade.

To run Performance Monitor on CallManager servers, select Start > Programs > Administrative Tools > Performance. After the application opens, as shown in Figure 9-1, you can add the counters in the preceding list and any other counters by selecting the appropriate performance object. After you add all the desired counters to monitor, you can save the view as a Microsoft Management Console (MMC) file by selecting Save from the Console menu. Running this saved MMC file before you perform an upgrade opens the Performance Monitor screen with all the configured counters.

Figure 9-1. Monitoring Performance Counters

Before you decide to upgrade the CallManager software version, ask yourself the following questions:

If no critical defects are affecting your existing deployment and product support is continued for your deployment, you do not need to rush for the upgrade. You also need to consider the amount of time and resources required to complete the upgrade before you make a decision.

As mentioned earlier, if you do decide to upgrade, you should perform the upgrade in the lab network before you apply it in the production cluster. You should develop a test plan to test the features and full functionality that deployed in your production environment. Document any changes that end users will notice because of the upgrade, and communicate this information to them ahead of time. If necessary, develop a plan to educate or train the users on new features that you want them to know about.

All software upgrades require that you reboot the servers at the end of the process. This causes some interruptions to call processing. However, you can minimize these interruptions by following this failover procedure:

You should perform the upgrades sequentially, one at a time in the cluster. In a Cisco CallManager cluster, you must upgrade all the servers in the cluster to ensure that all of them run the same CallManager version, OS version, and SQL version. Ensure that you reboot the server after the upgrade.

You should plan for the restoration of the system to its original state in case you encounter any problems during the upgrades. The following are the three methods to speed up the recovery:

The following sections describe these recovery procedures.

Because OS installation steps are the same for the majority of the Cisco AVVID applications and CallManager, the best practices recommended performing OS upgrades for CallManager that also apply to the application servers.

However, the process of upgrading software versions for each application varies from one product to another. Refer to the specific product documentation and release notes before the upgrade.

The list that follows includes a few commonly omitted tasks after a CallManager upgrade affects the functioning of the application servers:

You might need to upgrade the firmware on some Cisco IP Phones or Gateways to test the functionality and features in the new firmware versions before rolling out the changes to all the Cisco IP Phones and Gateways in the production network. The best practice when upgrading the firmware is to load it on a few devices and run it for a few days. If the results are good, you should proceed with upgrading the firmware on all devices.

You can specify the device firmware loads in two places in CallManager. One is on the Device Defaults page. To access this page from the Cisco CallManager Administration page, select System > Device Defaults. Before performing the upgrade, make a note of the device load versions specified in this page. The second place is at the individual IP phone or the gateway level. The device firmware specified at the individual device level takes precedence over the specified firmware on the device defaults page.

To perform a selective upgrade of firmware on devices, download the latest firmware and copy the binary files onto the TFTP server. The default path is C:Program FilesCiscoTFTPPath. If you are downloading an executable wrapper that contains the loads, the wrapper automatically copies the files to the TFTP server and updates the Device Defaults page with the latest load information. To perform the selective upgrade, you need to update the Device Defaults page configuration that points back to old load IDs.

To upgrade the load on a Cisco IP phone, from the Cisco CallManager Administration page, search for the IP phone for which you want to perform the upgrade and, in the phone device configuration, specify the IP phone Load ID, as shown in Figure 9-2, and reset the phone. After the Cisco IP Phone reboots, verify that the Cisco IP Phone has the latest phone load. On 7960/7940 Cisco IP Phone models, to verify the load, press the Settings button on the Cisco IP Phone and then choose Status > Firmware Versions menu options to verify that the App Load ID displayed matches the configured Load ID on the Cisco IP Phone device page, as shown in Figure 9-2. After the Cisco IP Phone registers with CallManager, make a note of the IP address from the CallManager Administration page and browse to the phone to check the software version when you are not local to the IP phone.

Figure 9-2. Selective Upgrade of Firmware on Cisco IP Phones and Gateways

To upgrade the load on a few gateways, configure the load on the gateway configuration page and reset the gateways. Figure 9-2 shows the specific load ID being configured for a WS-6608 MGCP T1 PRI gateway. To verify the load ID on the Catalyst 6608 gateway port, use the show version command on the switch, as shown in Example 9-1. Looking at the highlighted portion of the example, port 4/1 has a different load (D00404000008) than the rest of the gateway ports (D00404000007). Ports 4/4 to 4/7 are configured as conference bridges in CallManager and have a different load ID, C00103010014.

cat6k-voice> (enable) show version
WS-C6509 Software, Version NmpSW: 8.1(3)
Copyright © 1995-2003 by Cisco Systems
NMP S/W compiled on Oct 10 2003, 12:38:01

System Bootstrap Version: 5.3(1)
System Boot Image File is 'bootflash:cat6000-supk8.8-1-3.bin'
System Configuration register is 0x2

Hardware Version: 2.0  Model: WS-C6509   Serial #: SCA0443045D

PS1  Module: WS-CAC-1300W   Serial #:  SON04472655

Mod Port Model              Serial #     Versions
--- ---- ------------------- ----------- ------------------------------------
1   2    WS-X6K-SUP1A-2GE    SAD04480PZW Hw : 7.0
                                         Fw : 5.3(1)
                                         Fw1: 5.4(2)
                                         Sw : 8.1(3)
                                         Sw1: 8.1(3)
         WS-X6K-SUP1A-2GE    SAD04480PZW Hw : 7.0
                                         Sw :
3   48   WS-X6348-RJ-45      SAL05031N6H Hw : 1.4
                                         Fw : 5.4(2)
                                         Sw : 8.1(3)
4   8    WS-X6608-T1         SAD04320KZA Hw : 1.1
                                         Fw : 5.4(2)
                                         Sw : 8.1(3)
                                      HP1: D00404000008; DSP1: D0054133 (4.1.33)
                                      HP2: D00404000007; DSP2: D0054133 (4.1.33)
                                      HP3: D00404000007; DSP3: D0054133 (4.1.33)
                                      HP4: C00103010014; DSP4: C002E031 (3.3.2)
                                      HP5: C00103010014; DSP5: C002E031 (3.6.15)
                                      HP6: C00103010014; DSP6: C002E031 (3.6.15)
                                      HP7: C00103010014; DSP7: C002E031 (3.6.33)
                                      HP8: D00404000007; DSP8: D0054133 (3.6.33)
6   5    WS-SVC-CMM          SAD075303F1 Hw : 2.2
                                         Fw : 12.2(13)ZP2,
                                         Sw : 12.2(13)ZP2,
7   5    WS-SVC-CMM          SAD0640008A Hw : 2.1
                                         Fw : 12.2(13)ZP,
                                         Sw : 12.2(13)ZP,
15  1    WS-F6K-MSFC         SAD04480KXC Hw : 1.4
                                         Fw : 12.1(1)E,
                                         Sw : 12.1(1)E,

       DRAM                    FLASH                   NVRAM
Module Total   Used    Free    Total   Used    Free    Total  Used  Free
------ ------- ------- ------- ------- ------- ------- ----- ----- -----
1       65408K  48723K  16685K  16384K  11459K  4925K   512K  280K  232K

Uptime is 88 days, 0 hour, 22 minutes
cat6k-voice> (enable)

After you have successfully tested the new loads on a few devices and are ready to upgrade the firmware for the entire cluster, follow these steps:

You can always revert to the old device loads if you have to do so. The old firmware images still exist in the TFTP server. Hence, all you need to do is update the Device Defaults page to point back to the old firmware load ID and reset the phones and gateways based on the device pool.

QRT Viewer enables administrators to view the problems that are reported by the IP phone users through the QRT feature. Administrators should run these reports at least twice a week and take proactive measures to reduce the problems before they get out of control.

To access the report in CallManager 4.0, from the CallManager Serviceability page, select Tools > QRT Viewer. (In CallManager 3.3.3, select Tools > Phone Problem Reports Viewer.)

QRT Viewer provides many filters to pick the records for report generation and provides a variety of fields to include in the generated report. Figure 9-4 shows a sample report generated with QRT Viewer.

Figure 9-4. Sample QRT Viewer Report

Summary view displays information about CPU usage, memory usage, the number of registered phones, the number of calls in progress, and the number of active gateway ports/channels. This is useful information to monitor on a daily basis. A sudden decrease in the number of registered phones, for example, could indicate a problem with the server or with the switch/module on a particular segment. You should note the statistics on this page before performing an upgrade and run RTMT to ensure that the same numbers of IP phones and gateway ports are available after the upgrade.

During a busy period, monitor the CPU and memory usage. A value above 80 percent is not a good indication. Possible reasons for higher usage are that the server is overloaded with too many devices or a service is malfunctioning because of a memory leak. You should examine the reason for this high usage and act appropriately to reduce the usage values. High CPU usage could introduce call-processing delays.

Server view displays information about CPU, memory, and disk usage and the status of critical services.

The CPU and Memory page displays in graphical format the various processes that are currently running on the system and their corresponding memory and CPU usage. Whenever you notice higher CPU or memory usage, you can see which service is taking up maximum resources. This information will help you to troubleshoot issues such as a slow dial tone, CallManager not responding, and so on. You also can view the memory and CPU usage of another server in the cluster.

Enabling detailed tracing levels for the signal distribution layer (SDL) and system diagnostic interface (SDI) traces is often required during troubleshooting. Detailed tracing occupies a lot of disk space. If the level of trace remains at Detailed, you might run out of disk space. The information gathered from disk usage will help to prevent such scenarios.

The Critical Services page lists all the CallManager-related services, including the status and uptime of the service.

CallProcess view displays information about call activity, gateway activity, trunk activity, and SDL queues. The information displayed under Gateway Activity assists you in evaluating the capacity of the PRI usage and assists you in troubleshooting issues with PRI when the channel is activated but not operating.

Selecting SDL Queue from the CallProcess view displays the number of signals and requests in various SDL queues and the number of processed requests. To understand the importance of the SDL queue parameters, you need to know about the call-throttling feature in CallManager. Call-throttling protects CallManager from high CPU usage caused either by a burst of call attempts that exceeds the threshold that the CallManager can support or by a call routing loop. In addition, a faulty hardware or faulty firmware could send too many events to CallManager, forcing CallManager to process all the faulty requests, thereby reducing the CPU cycles available for other devices.

To protect from such events, CallManager places the incoming messages and signals into four different SDL priority queues:

CallManager processes messages in the high-priority queue before messages in the normal-priority queue, processes messages in the normal-priority queue before messages in the low-priority queue, and so forth. The types of messages that go into the normal-priority queue are the initial call setup messages. Whenever CallManager receives a new message request, it calculates the expected delay to complete the request. The expected delay depends on the number of messages in the queue and the number of messages processed.

The higher the number of signals waiting in the queue, the higher the delay is. If the delay is more than the configured threshold values (configured via the Cisco CallManager (CCM) Call Throttling service parameters), the call-throttling feature denies the incoming requests.

Figure 9-5 shows the CCM Call Throttling service parameters for the CallManager service.

Figure 9-5. CallManager Service Parameters—CCM Call Throttling

Do not change the default values of the parameters shown in Figure 9-5 unless directed to do by Cisco support personnel.

In Figure 9-5, entering 0 for System Throttle Sample Size disables the call-throttling feature. The call-throttling mechanism applies to incoming calls from phones, Cisco IOS gateways, MGCP gateways, and MGCP back-haul PRI gateways. Whenever the call-throttling feature is called for, the IP phone devices making calls display the message “Too Much Traffic Try Again Later.”

Service view displays information about the Cisco TFTP service, directory server, and Heartbeat for critical services.

The information gathered for the TFTP service includes total TFTP requests, total TFTP requests not found, and total TFTP requests aborted. This information helps you to troubleshoot TFTP-related issues during the initial phone registrations with CallManager. A higher number for TFTP requests not found indicates that many devices are attempting to download the configuration file or firmware from the TFTP server but are unable to find the specified file. This clearly indicates that you must have specified a device load in the Device Defaults page that does not exist in the TFTP server.

The Directory Server window displays information about the status of the replication; this helps you to troubleshoot issues related to directory replication.

The HeartBeat window shows the HeartBeat count for CallManager service, Cisco TFTP service, and Cisco Telephony Call Dispatcher (TCD) services. The HeartBeat is an incremental count that indicates which service is alive and running. If the count for a service does not increment, you can consider the service dead, and you should take immediate action to analyze the reason for the failure of the service.

Device view displays information about the number of registered phones, registered gateways, and registered media resource groups. The information gathered in the Device Summary view assists you during a CallManager upgrade, where the number of devices registered before the upgrade must be equal to the number of devices registered after the upgrade. It also gives you the data required to calculate the device weights or dial plan weights for the CallManager cluster.

The Device Search view lets you search for devices, such as IP Phones and gateways, in the cluster. An important feature of the Device Search view is that it enables you to search for devices based on their status, such as registered, unregistered, or registration rejected, as shown in Figure 9-6. RTMT and the IP Phone Information Facility option in the IP Telephony Monitor (part of ITEM) are the only Cisco tools that allow you to query the devices based on the real-time status. You can use this search filter to determine the number of phones that are in the unregistered status before or after an upgrade or during the deployment of IP Phones in the network.

Figure 9-6. RTMT Device Search Filter—Registration Status

The filter in the Device Search that is of most interest in day-to-day operations is the search based on the IP address or IP subnet, as shown in Figure 9-7. You might want to search using these filter options if multiple users report problems with their IP phones. If you can narrow down the problems to a group of users based on an IP subnet, you can focus on troubleshooting only within that network segment or device pool.

Figure 9-7. RTMT Device Search Filter—Cisco IP Phone Characteristics

The Computer Telephony Integration (CTI) view provides the status of the registered CTI applications and their connection status.

Perfmon view displays all the counters available in Windows Perfmon. To meet your requirements, you can select a particular counter that is not available in default monitoring and add it. You can also set alerts for the new counter, as discussed in the next section.

There are two kinds of RTMT alerts. The first set is preconfigured, and the second set is user defined. You can customize both of them. The main difference is that you cannot delete preconfigured alerts, whereas you can add and delete user-defined alerts. However, you can disable both preconfigured and user-defined alerts. To view the preconfigured alerts, from the RTMT client application, select the Alert > Alert Central menu option.

The preconfigured alerts are enabled by default. In most cases, you do not have to change the default threshold settings configured for the preconfigured alerts. However, you have an option to change the threshold settings to meet your requirements. The notification can be an e-mail or a pager. To set up e-mail notification, you should specify the SMTP server name and port number. You can do this in the RTMT client application by selecting the Alert > Configure E-Mail Server menu option.

To set a new alert, select the Perfmon Monitoring in PerfMon view, select any performance counter that you want to monitor, and right-click the graph to configure the alert settings, as shown in Figure 9-8.

Figure 9-8. Defining New Alerts in RTMT

Example 9-2 shows a few sample alert messages sent by RTMT via e-mail.

From: [email protected]
Sent: Friday, February 27, 2004 1:47 AM
To: [email protected]
Subject: [RTMT-ALERT] CallProcessingNodeCpuPegging

At 01:46:03 on 02/27/2004 on cluster StandAloneCluster.
Number of registered phones in the cluster drops 10 Percent.
Current monitored precanned object has decreased by 100 percent.

This is alert from CallManager 4.0 server At 01:46:33 on
    02/27/2004 on node 10.1.3.1. Processor load over 90 Percent.
    Ccm (91 percent) uses most of the CPU.

At 21:01:03 on 02/27/2004 on node 10.1.3.1.
Directory connection failed .
Monitored precanned object has value of 0.

At 18:12:27 on 02/26/2004 on cluster StandAloneCluster.
Number of registered gateways increased.
Current monitored precanned object has increased by 1.

RTMT reporting functionality provides predefined reports that include the information collected during the monitoring process. To access the RTMT reports, from the CallManager Serviceability page, select Tools > Serviceability Report Archive. There are five predefined reports:

The service parameter RTMT Report Deletion Age for the Cisco Serviceability Reporter service defines the age of the report. This parameter specifies the number of days that must elapse before reports are deleted. For example, if this parameter is set to 7 (default value), reports that were generated 7 days ago are deleted on the eighth day. A value of 0 disables report generation, and any existing reports are deleted.

These reports aid you in analyzing the capacity of the system and troubleshooting problems. More importantly, careful interpretation of the reports will help you to identify the problems in advance and take appropriate measures to prevent them from happening again.

The service that is responsible for generating the reports is Cisco Serviceability Reporter service. Set the service parameter RTMT Report Deletion Age for this service to 30 and keep the reports for 30 days. At the end of 30 days, copy the reports onto the network share server so that the trending analysis covers a longer period, resulting in meaningful data.

To configure the level of tracing for the available services, select Trace > Configuration on the CallManager Serviceability page. The default tracing level for all the services is Error. Enabling the Detailed tracing level for any of the services logs huge amounts of data in the log files.

The Troubleshooting Trace Settings page provides a one-stop shop for enabling the traces required to troubleshoot a problem. This page offers you the option of selecting the service on a particular CallManager or on the entire cluster. This page has predefined trace levels to capture sufficient information needed by Cisco TAC and engineering teams to investigate deep into the problems. To access the Troubleshooting Trace Settings page from the CallManager Serviceability page, go to Trace > Troubleshooting Trace Settings.

The client portion of this tool, CallManager Trace Collection Tool, sits on a desktop running Windows XP or Windows 2000. With this tool, you can connect to any CallManager from your desktop or laptop and collect all the required traces. The client version of this tool is available as a plug-in on the CallManager Administration page. To access the tool after the installation from your workstation, select the Trace Collection Tool menu option from Start > Programs > Cisco CallManager Serviceability > Trace Collection Tool.

This tool gathers log files that are associated with various CallManager services, CallManager applications, system traces. System traces include Event Viewer logs, Dr. Watson logs, Microsoft IIS logs, SQL logs, Directory logs, System Performance logs, and Prog logs.

Refer to the following URL for more information on the Trace Collection Tool and Troubleshooting Trace Settings page:

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_configuration_example09186a00801f3b4d.shtml

The Bulk Trace Analysis Tool assists you in troubleshooting a problem that requires you to analyze logs collected over a period of time. Enabling the Detailed level traces on CallManager uses a lot of CPU and memory resources. Furthermore, analyzing such a large amount of data on CallManager requires more resources. By using the Bulk Trace Analysis Tool, you can analyze the trace files from a standalone workstation. This tool reads the SDI and SDL trace files stored in XML format. By default, all CallManager traces are stored in plain text files. To generate SDI and SDL trace files in XML format, you should enable XML tracing from the Trace Configuration page for the services. The limitation of logging traces in XML format is that it reduces the number of lines stored per log file and increases the amount of processing power required to analyze and display the contents. Hence, avoid using XML logging whenever possible.

You can install the Bulk Trace Analysis Tool on your workstation by downloading the Bulk Trace Analysis Tool plug-in from the CallManager Plug-ins page. Do not install the tool on the CallManager Publisher or Subscriber servers because analyzing a large number of trace files consumes CPU and memory resources. You can copy the XML trace files that you need to analyze from the CallManager server to your workstation and open them in the Bulk Trace Analysis Tool.

Figure 9-9 shows the sample output of an analysis of XML trace files by using the Bulk Trace Analysis Tool.

Figure 9-9. Bulk Trace Analysis Tool Output

User reports can provide billing information about an individual user or a whole department. You can determine who the top users are based on several categories, including usage duration, number of calls, and amount of charges. This information helps you to identify users in the cluster who have a heavy call volume.

The CDRs do not contain cost information, by default. However, in the CAR application, you can select Rating Engine from the Report Config menu to configure the costs associated with calls and define the cost factors based on time of day. After you configure these values, the reports you generate through CAR will have cost information.

When you log in to the CAR application, if your user ID is assigned as a manager for some users in the CallManager user pages, you can generate a report for all the users who are reporting to you.

The system reports provide information about QoS, traffic, and malicious calls, and provide a system overview. The QoS reports help you to troubleshoot voice-quality issues; they contain information about jitter and packet loss. The Call Management Record database stores the information about QoS parameters.

The traffic report identifies traffic patterns, provides information about the call activities during the day, and identifies the peak time and lean time. This report helps in capacity planning of the gateways and circuits.

The device reports help in capacity planning of gateways, Conference Bridge resources, and voice mail. The route plan report provides information about the use of the route pattern, route list, and route group. The route plan report helps you to optimize the dial plan.

The CDR search tool helps you to pull a CDR for a particular call that experiences problems; the details in the record help you to troubleshoot issues with one-way audio, duplex mismatch, and so on.

Starting with CallManager 3.3(2), Cisco has modified the way passwords are used for various services in the CallManager cluster to increase the security for the Windows Services that comprise the system. Many of the services that were running as Local System in prior releases have been changed to run as Local Windows user accounts and services. The services that use these accounts are listed in Table 9-3.

During installation, by default, the accounts shown in Table 9-3 are created (without Log on Locally access) and the local Windows password is generated by an algorithm based on the NetBIOS name of the CallManager Publisher server as the seed for each account within the Cisco CallManager cluster. After entering the private password phrase during the Publisher installation, the passwords for the service accounts are regenerated and modified. When you are installing the Subscriber servers, you should enter the same password phrase that you used when building the Publisher.

Because all the servers in the cluster must be able to communicate with Publisher to keep the database up to date, it is critical that the passwords for the service accounts shown in Table 9-3 are identical among all the servers in the cluster. If you decide to change passwords for any of these service accounts, you should use the Cisco-provided Admin Utility. The Admin Utility program is in the C:Program FilesCiscoBin directory on the CallManager servers. You should run this utility on the CallManager publisher server only. Refer to the AdminUtility-Readme.html file located in the C:Program FilesCiscoBin directory on the CallManager servers before running this utility.

As with any installation or upgrade, Cisco recommends that you execute this utility during off-peak hours. This utility will change the affected local Windows account, services, and virtual directories.

If you choose to change all accounts on all systems within the cluster, all call processing will be terminated until the entire cluster is updated. Depending on the number of servers within the cluster and the call volume at the time this utility is executed, the upgrade process could take several minutes per server.

The steps to run the Admin Utility to set a new password are as follows:

Cisco CallManager Password Changer

You can use CCM Password Changer to change the password of special CCM users, such as the following:

• Directory Manager (user account for DC Directory)

• CCMSysUser (account used for CTI applications, such as QRT, CRA, and Callback)

• CCMAdministrator (account used by MLA)

• IPMASysUser (account used by IPMA)

CCM Password Changer works with all supported directory servers, which include DC Directory, Active Directory, and Netscape directory. This utility updates the passwords on all the CallManager servers in the cluster and in the registry. You have to reboot the CallManager servers any time you change the passwords.

To launch CCM Password Changer, using Windows Explorer, browse to C:Program FilesCiscoBin and launch ccmpwdchanger.exe. Figure 9-12 shows the CCM Password Changer interface. Use the local Administrator password to log in to the CCM Password Changer.

Figure 9-12. CCM Password Changer Interface

When implementing the dial plan, you can use explicit route patterns such as 9.[2-9]XX[2-9]XXXXXX or route patterns with the @ wildcard character along with route filters. Recall from Chapter 6, “Design of Call-Processing Infrastructure and Applications,” that the @ wildcard character is a macro that comprises many route patterns, depending on the dial plan loaded in CallManager. By default, CallManager understands only the North American Numbering Plan (NANP). Beginning with CallManager 3.3.4, support for international dial plans has been added. Refer to the following document on Cisco.com for more information on supported international dial plans:

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/prod_configuration_guide09186a0080292f3d.html

If you are deploying CallManager in a country outside North America, you can download the country-specific International Dial Plan file from the following URL and install it on all the servers in the cluster:

http://www.cisco.com/cgi-bin/tablebuild.pl/IDP

The dial plan definition files are stored on the CallManager servers under the C:Program FilesCiscoDialPlan directory. By default, the NANP file contains the various route patterns that comprise NANP. For example, if you install an Australian Numbering Plan on the CallManager servers, you see an additional file called AUNP under the same directory. After you install the international dial plan, when defining the route patterns, you can choose which numbering plan the route pattern should use, as shown in Figure 9-15.

Figure 9-15. Choosing Numbering Plan for Route Pattern

For inexperienced users, designing the dial plan using explicit route patterns without the use of route filters is easy and simple to understand. However, there are some instances in which using route filters can be beneficial, particularly when a single route pattern with the @ macro can replace multiple route patterns.

To emphasize this point, consider the example of defining the toll-free numbers in the United States. Calling toll-free numbers commonly is allowed from lobby phones and common areas. The toll-free numbers are part of the long-distance dial pattern of 1 + ten digits. They should be defined in the dial plan and assigned to a class of service. The five area codes for toll-free numbers are 800, 855, 866, 877, and 888. Instead of defining five route patterns, you can use a 9.@ route pattern with the following route filter to group all five area codes. The following is the definition of the route filter:

(LONG-DISTANCE-DIRECT-DIAL EXISTS AND

AREA-CODE == 800 AND

TRANSIT-NETWORK DOES-NOT-EXIST)

OR

(LONG-DISTANCE-DIRECT-DIAL EXISTS AND

AREA-CODE == 855 AND

TRANSIT-NETWORK DOES-NOT-EXIST)

OR

(LONG-DISTANCE-DIRECT-DIAL EXISTS AND

AREA-CODE == 866 AND

TRANSIT-NETWORK DOES-NOT-EXIST)

OR

(LONG-DISTANCE-DIRECT-DIAL EXISTS AND

AREA-CODE == 877 AND

TRANSIT-NETWORK DOES-NOT-EXIST)

OR

(LONG-DISTANCE-DIRECT-DIAL EXISTS AND

AREA-CODE == 888 AND

TRANSIT-NETWORK DOES-NOT-EXIST)

In the preceding example, the LONG-DISTANCE-DIRECT-DIAL clause is included to force the use of 1. Also, we have to exclude the TRANSIT-NETWORK to prevent the user from dialing the transit network escape code of 1010XXX.

When you create a directory number, route pattern, translation pattern, CTI port, or CTI route points, CallManager puts them in a <none> partition. It is a good practice to place all of them in their own partition. Leaving them in a <none> partition leaves room for toll fraud. Assume that you have a route pattern of 9.1[2-9]XX[2-9]XXXXXX in a null partition. All the IP phones, including lobby phones, have access to this route pattern and thus can make long-distance calls. This breaks your Class of Restriction policies. It also allows users to set Call Forward All to long-distance numbers and thus misuse the telephony network.

Minimize the number of partitions and the length of the partitions as much as possible, because the number of characters allowed in the calling search space (CSS) is limited to 512 characters. As you know, the CSS is a list of partitions. Hence, lengthy partition names or a large number of partitions limits the number of partitions that you can have in the CSS. Also, shorter partition names improve performance because of faster string matches.

In a multisite centralized CallManager deployment model, you can use the alternate Calling Search Space Design described in Chapter 6, “Design of Call-Processing Infrastructure and Applications.” This uses the CSS on the line level and the device level to determine the effective calling restrictions on the IPT devices.

When an IP phone user receives an incoming call from the PSTN, the phone displays the digits sent by the PSTN in the missed and received calls options. This number does not include the access code (for example, 9 or 0) that is required if the user dials the external number. You can prefix the access codes and the long-distance access codes easily by using the following new advanced service parameters (under Clusterwide Parameters [Device - PRI and MGCP Gateway] section) for CallManager service, introduced in CallManager 3.3.3:

CallManager adds the prefix values defined in the service parameters to numbers in the missed and received calls directories based on the inbound Q.931 call type value.

For example, in North America, for international numbers, you can prefix 9011 by configuring “9011” in the International Number Prefix parameter, and for national numbers, you can prefix 91 by configuring “91” in the National Number Prefix parameter. You likely want to keep the prefix for subscriber and unknown numbers blank. One limiting factor is that (at least in North America) Q.931 call types do not distinguish between local and long-distance numbers, so ten-digit local numbers will be dialed with a 91 long-distance prefix. Again, this is normally a nonissue because if you want to avoid the long-distance rates for the local calls, you can create an outbound translation pattern for the area codes that do not require you to dial 1 and remove 91 before sending the call to the PSTN.

Apply the operating system service packs and critical hot fixes regularly to prevent security attacks and thus harden the operating system. Upgrade the antivirus software on the servers as and when new versions are available.

Cisco bundled a security script CCM-OS-OptionalSecurity.cmd beginning with CallManager operating system release version 2.6. The script is available in the C:UtilsSecurityTemplates directory on the CallManager servers. You can optionally run this script only on the CallManager servers to harden the operating system.

CSA is a distributed security software solution that helps prevent malicious behavior on CallManager and other application servers. The CSA solution is composed of several elements:

You should install the CSA Software Agent on all CallManager servers as well as other application servers such as Unity, IPCC Express and so forth. You can download the CSA Software Agent for CallManager at no charge from the following URL:

Similarly you can download the CSA Software Agent for Unity from the following URL:

Remember that each Cisco IPT application has it’s own version of CSA Software Agent. Hence, make sure that you download and install the version that is specific to your product.

If you remove a subscriber server from a cluster, also remove the server name from the CallManager Server page. Do not just power off the server. If you leave the removed server name on the CallManager Server page, the Publisher server still views the server as part of the cluster even though you powered off the server. Hence, the Publisher server tries to contact the server in the back end, which is a waste of CPU resources.

Auto-registration in CallManager enables the phone to register automatically and get a directory number. This feature is helpful during the implementation phase when used along with BAT and TAPS, as discussed in Chapter 8, However, you should either turn off this feature after you complete the implementation or use the following method to forward all the calls from auto-registered phones to a security operator number as soon as they go off-hook. That way, even if someone successfully registers the “rogue phone” to the cluster, the call will always reach the security operator.

The preceding configuration forwards the calls to the security operator as soon as an auto-registered phone goes off-hook and thus allows you to prevent the misuse of the IPT network by auto-registered phones, as shown in Figure 9-17.

Figure 9-17. Call Flow for an Auto-Registered Phone Forwarding to Security Operator

The session timeout for CCMAdmin and CCMService pages is set to 20 minutes by default. The steps to increase or decrease this setting are as follows:

The Alerts and Activities option displays the list of alerts generated by the devices that are currently monitored by ITM, as shown in Figure 9-20. This feature is similar to the Alert Central window in RTMT (as discussed earlier in the “RTMT Alerts” section). The alerts are summarized by device. Click on any alert to see a complete list of events associated with that alert.

Figure 9-20. ITM - Alerts and Activities

ITM allows you to group devices into multiple partitions. If you have numerous devices in your IPT network, you will likely want to use this feature. For example, if you have two CallManager clusters managed by two different groups of users, you might want to create two partitions and place the devices in different partitions according their cluster association. You can then set up user groups and give permissions in such a way that each group can control its own cluster.

Device Management allows you to add, delete, and modify all devices that ITM monitors. It also allows you to view the device state and provides an interface to change the credentials such as SNMP community string, username, and password for the servers. You can add a single device or import devices by using a comma separated value (CSV) file. You can enter two types of devices in the ITM. One is a Network Device and the other is a Media Server. The Network device consists of all routers and switches, and the Media server consists of CallManager, Unity, Personal Assistant, CER, and CCC servers. After you add all the network devices that need to be monitored by ITM, you can use View Discovery Status to find the state of the device.

The Alerts and Activities option contains information on alerts that are generated because of an event. You can forward such alert information to other systems and users. There are two types of notifications:

In configuring either notification type, you need to select the list of devices for which you want to enable the notification. As shown in Figure 9-21, you can select individual devices or a group of servers (for example, All Cisco Gateways). You can also choose to send the alert only if a critical alarm is generated from the selected device or group of devices.

Figure 9-21. ITM - Notification Services

By choosing different combination of these parameters, you can control the information that is sent to the individuals who are responsible for different components of the network. In other words, you can filter the information based on the job function of each recipient.

When configuring SNMP trap notification, you need to enter the SNMP trap recipient, which is the DNS name or IP address of the server that receives the trap notification. In case of E-Mail notification, the recipient information is the e-mail addresses of the intended persons to send the alert notification. You also need to specify the SMTP server information to communicate with the E-Mail server.

Fault History allows you to view the alerts and events generated by devices that are monitored by ITM for the past 30 days. Based on the fault history, you can tell if the event or the alert is recurring or not. If you see a recurring event in the fault history, you need to analyze the reason for that event and take the appropriate steps to resolve the issue.

Configuration allows you to configure the thresholds for various events, polling intervals, and other configuration parameters that apply to ITM. Within the Configuration display, one useful option is Confidence Testing, which is discussed in the following section.

In a complex network involving several switches, keeping track of the switch port to which the IP phone connects becomes hard. IPIF helps ITM to monitor, track, and maintain the phone information in the network. This utility provides information about the phone extension, IP address of the phone, MAC address of the phone, status of the phone, type of phone, protocol, SRST mode, CallManager address, switch address, switch port, switch port status, VLAN name, VLAN ID, and SRST router information. This utility helps in troubleshooting issues with phone registration when the phone moves. The switch details are populated for those switches that are managed by ITM.

Using IPIF, you can find IP Phones in the network, view details of IP Phones, schedule phone discovery, and view the status of phone discovery. You can generate individual reports of all phones in the network, unregistered suspect phones, duplicate MAC/IP address IP Phones, phone audit, phone move, and IPT applications. The IPT Applications display provides information for all IPT applications that are registered with CallManager.

As discussed in Chapter 1, “Survivable Remote Site Telephony (SRST)” section, the SRST feature provides backup call processing for the IPT endpoints in the branch sites in case of connectivity failure with the CallManager at the central site.

The SRST Monitoring Management in ITM monitors the WAN link between the central site router and the branch site router configured for SRST. When the WAN link goes down, ITM sends an alert informing that IPT endpoints such as Cisco IP Phones in the branch site are in SRST mode. By viewing this alert, you can check the status of the remote WAN link and resolve the issue to restore the WAN link.

This testing assists you in proactively monitoring the status of the IP phones. It also provides information about the availability of the intermediate network among the IP Phone, ITM, and SAA (Service Assurance Agent) router. This testing requires a router to run SAA. The SAA router sends SAA-based pings to all key phones; you can optionally configure the ITM server to send an ITM ping in addition to the SAA ping. You can use the Phone Reachability Testing Manager page to add, configure, delete, and view reachability tests.

IPT Security Displays provides the following views:

The information collected from IPT Security Displays assists in the inventory of all phones, troubleshooting issues with call routing, and the identification of phone theft. The report contains attributes such as the phone extension, IP address of the phone, MAC address of the phone, switch address, switch port details, and the CallManager address.

The combination of IPHDU and IPIF constitutes a great tool for help desk personnel to troubleshoot problems with a phone. IPHDU allows help desk personnel to access IPIF without requiring them to have complete access to ITEM. IPHDU is an optional component that you can install IPHDU on any Windows platform. The help desk personnel can obtain information about the phone by using the phone extension, IP address of the phone, or MAC address of the phone. IPHDU provides the following information:

GSU assists in collecting performance and capacity statistics from CallManagers and gateways. GSU is an optional web-based plug-in that can be installed on top of ITEM.

GSU communicates with CallManager and collects information about registered MGCP gateways. You can use GSU to schedule a study, which is a task to collect device statistics of MGCP gateways from CallManager. A study can be scheduled to run once or over a period of time; you can perform trending analyses based on the data collected over the time period.

GSU polls the Performance Monitor counters and provides the following performance statistics: