Cisco IP Telephony: Planning, Design, Implementation, Operation, and Optimization [Electronic resources] نسخه متنی

Figure 9-14. RTMT Top 10 Alerts from Alert Report

Chapter 1, "Cisco IP Telephony Solution Overview," for information on dial plan weights and device weights.

Duplex and Speed Settings

When deploying Cisco IP Phones, use the Auto setting to negotiate the duplex and speed with the connected switches. By default, the switch port and the PC port on the IP phone are set to do auto-negotiation to configure the speed and duplex. Hence, no manual configuration on the IP phones is required.

You should configure the Ethernet port on the closet switch and the NIC setting on the PC to do auto-negotiation. This configuration approach avoids negotiating mismatched speed and duplex settings and prevents voice-quality problems caused by interface buffer overflows and device connection timeouts with CallManager. Hard-code the NIC setting on the servers and on switch ports that connect the servers to 100/FULL. After you perform any upgrades on the servers, ensure that the configuration settings of the NIC on the servers are not changed.

Dial Plan Optimization

When you are designing the dial plan, keep it as simple as possible by following the tips recommended next to optimize the performance of CallManager.

Route Pattern Design

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_guide09186a0080292f3133

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 Files\Cisco\DialPlan 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.

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.

Partition Rules

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.

Calling Search Space Rules

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.

Prefixing the Digits in Missed and Received Calls

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:

National Number Prefix

International Number Prefix

Unknown Number Prefix

Subscriber Number Prefix

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.

Securing the Servers

It is critical to secure the call-processing servers and other application servers from viruses, worms, and denial of service (DoS) attacks. Chapter 6. discusses the best security practices. This section gives operational best practices to keep the servers up to date to prevent them from becoming potential targets for security attacks.

Operating System Hardening

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:\Utils\SecurityTemplates directory on the CallManager servers. You can optionally run this script only on the CallManager servers to harden the operating system.

Caution

Be aware that running this script on the CallManager servers that are integrated with other applications, such as Cisco IP-IVR and Cisco IPCC Express, is not supported. Refer to the Readme file in the C:\Utils\SecurityTemplates directory before making a decision to run this optional security script.

Cisco Security Agent

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:

CSA Software Agent Core endpoint technology that resides on servers and autonomously enforces local policies that prevent attacks

CSA Management Console Core management application that provides a central means of defining and distributing policies, providing software updates, and maintaining communications to the agents

CSA Profiler Plug-in management application that provides the capability to build custom policies to protect new applications and tune and modify existing policies in live environments

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:

http://www.cisco.com/cgi-bin/tablebuild.pl/cmva-3des

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

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

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.

Service and Enterprise Parameter Fine-Tuning

Sometimes you have to fine-tune the CallManager service and Enterprise parameters, based on the size of your network and your requirements. The service parameters are stored in the SQL database and are replicated between the CallManager servers in the cluster. The default values are stored in the ProcessConfigDefault table, and running values are stored in the ProcessConfig table in the SQL database. However, some parameters are specific to a given CallManager server, and others are cluster-wide parameters. Changing a cluster-wide parameter affects the whole cluster operation. Previous chapters and this chapter discussed some of these service parameters in detail. Table 9-4 lists the other commonly changed service parameters. To access the service parameters, from the CallManager Administration page, go to

Service > Service Parameters , and then select the desired service to display the associated service parameters.
Some of the services have advanced service parameters that are not displayed by default. To view them, click the Advanced button on the Service Parameters page.

As the name implies, the service parameters are associated with a service, and changing the values affects the behavior of the corresponding service. In addition to the service parameters, CallManager provides another set of parameters called enterprise parameters. Changing the values of enterprise parameters affects all the devices and services within the CallManager cluster. To access the enterprise parameters, from the CallManager Administration screen, select

System > Enterprise Parameters . In most cases, you do not have to change any of these values. Table 9-5 lists some commonly changed Enterprise Parameters and their effects on the cluster operation.

Deployments Involving Shared Lines

Deploying an IPT network with shared lines increases the dial plan weight on the CallManager servers. Hence, you must carefully size the servers and memory requirements in shared-line deployments. If you are using shared lines on many IP phones, a single directory number can appear on 300 devices. Therefore, if you have two different directory numbers, you can share them on two different sets of 300 phones, with shared line 1 on the first 300 phones and shared line 2 on the other 300 phones, for a total of 600 devices with shared lines. In practical deployments, no one requires such a large number.

Call Detail Records

If you have enabled CDRs, the call activities are stored in the CallManager CDR database in the SQL server. If you leave the CDR database untouched, over a period, the number of records stored in the database becomes substantial and occupies a lot of hard disk space. Having a large CDR database increases the amount of time to complete the backup and restore process and results in high usage of memory and CPU by SQL service whenever you run queries or generate reports through CAR. To avoid these issues, you should routinely purge the CDR database.

You can use the CAR tool to schedule the purge of CDRs periodically. To configure automatic purge of the CDR and CMR records from the CAR application, select

System > Database > Configure Automatic Purge .

If you do not want to install CAR, you can manually purge the CDR data by using the procedure described in the following document:

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

CallManager Traces

Leave the CallManager trace level to its default and enable detailed tracing only when troubleshooting. Configure the trace settings back to their default values after you complete the troubleshooting. Enabling detailed tracing involves a lot of disk writing cycles and occupies hard disk space.

Another approach is to enable detailed tracing only for CallManager Service, Cisco Database Layer Monitor Service, and Cisco RIS Data Collector Service and leave the trace settings on other services to Error level. When you enable detailed tracing, you can limit the number of files and the size of each trace file to the minimum required. CallManager overwrites the trace information, beginning with the first file, when the file limit is reached, and moves to the next file when the number of lines in the current file reaches the specified threshold.

Firmware Loads

Always use the same phone loads or gateway loads throughout the cluster. This ensures that whenever you upgrade the CallManager, all the devices get a new load. Otherwise, over a period of time, you will have a few phones and gateways that are left with old device loads in the network. Use BAT to query for the phones and gateways that have different loads and remove the device-specific load information from the configuration pages.

Cluster Guidelines

This section discusses some operational best practices in configuring and managing the CallManager cluster.

Removing a Subscriber

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

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.

Installing Third-Party Software Applications

Do not install unsupported third-party applications on any of the IPT application servers, to avoid issues such as memory leaks in those applications that affect the CPU and the availability of memory resources on the servers.

Changing Session Timeout for CallManager

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:

Cisco Unity Operations

As discussed in Chapter 7, "Voice-Mail System Design," Cisco Unity uses an underlying messaging network for proper functioning. The messaging store could be either Microsoft Exchange or IBM Lotus Domino. If you are following Microsoft's or IBM's best practices for monitoring and maintaining Exchange, Windows, or Domino, it is unlikely that you will encounter issues regarding these messaging products. Using Exchange or Domino to store and retrieve voice messages, break down distribution lists to addresses, and then route SMTP messages is basic mail technology that Exchange and Domino have a solid track record of handling. If you maintain the message store servers properly, the weakest point between Unity and the message stores will be the network connection between them. If there are network latency issues between the Unity and message store servers, it can manifest itself as telephone user interface (TUI) delays in the Unity conversation that the end user will hear.

Refer to the Cisco Unity Maintenance Guide on