The actual process of replacing or migrating from a legacy telephony system to a new-world Cisco IP Telephony (IPT) system can be a challenging task if you do not have the proper tasks, tools, and processes in place.
Whereas the previous chapters provided the design and configuration parameters required for actual implementation of the Cisco IPT solution, this chapter helps you to smoothly and successfully complete the IPT implementation phase by discussing in detail implementation tasks, tools, processes, common problems, and possible causes and resolutions of those problems. CallManager provides various tools that assist you in the implementation and in day-to-day operations. Identify which tools you need to use and learn how and when to use them during the implementation. This chapter discusses some of these tools that are applicable in the implementation phase of IPT. Some tools discussed in this chapter can be used in both the implementation phase and the operations and optimization phase. Chapter 9, “Operations and Optimization,” discusses the tools that are not covered in this chapter.
A detailed implementation plan will help you to deploy the IPT solution within the estimated time and without facing major hurdles. The following are the major tasks involved in the implementation of IPT networks:
Develop IPT acceptance tests.
Complete postimplementation documentation.
Develop a support strategy.
Develop a training plan for end users and network administrators.
In large IPT deployments, it is common to subcontract the actual deployment of IP Phones to a partner. In this case, you should review the implementation plan with the partner’s IPT deployment team to make sure that all the preceding tasks are covered in detail. This ensures successful deployment of an IPT network that conforms to the proposed design.
The preimplementation tasks include the following subtasks. Appendix H, “IPT Implementation Checklist,” includes tables that assist you in collecting the information required to complete the following tasks:
Develop a project plan.
Collect site information.
Build an implementation team.
A project plan itemizes the sequence of steps involved in the IPT solution implementation. Good project management smoothens the implementation process by keeping track of all the tasks and making sure they are being performed in a timely fashion by all parties involved.
For a large-scale deployment, you should have a project manager who can be a single point of contact for the entire IPT implementation project and who has all the current information about the implementation phase. The responsibilities of the project manager should include the following:
Plan the implementation task schedule, including the resource allocation, and build the implementation team.
Coordinate with IPT network design engineers, facilities engineers, integration consultants, and other specialists.
Coordinate the arrival of deliverables from multiple locations with engineers and installers and oversee communication among all parties.
Interact with external vendors such as telephone companies, to place the order for the voice trunks, and Internet service providers, to order additional bandwidth on WAN links.
The second major task in implementation is to perform readiness analysis, which includes the following checks:
Site readiness
Voice network readiness
Data network readiness
IPT readiness
Appendix H contains the checklists of the steps that the deployment team needs to perform to complete the implementation readiness analysis.
The site readiness checklist included in Appendix H covers the following tasks:
Determine IPT/network component placement.
Evaluate rack space and cabling requirements.
Evaluate power and HVAC requirements.
The deployment team needs to review each of these readiness checklists and tighten up the loose ends where needed. You might have covered some of these tasks in the planning phase of the IPT network. The checks are included here to ensure that the steps recommended in the planning phase have been implemented and the basic infrastructure is ready to employ IP Telephony.
You should check the power requirements before deploying the IPT network, especially when you are using inline power features to provide the power to IP Phones. Based on the IP Phone model, quantity, and placement, the capacity of power supplies required at the LAN switches varies. In addition, each device in the network has a different power requirement. For instance, the power requirement of Catalyst switches varies depending on the model number and type of line cards used. Therefore, when evaluating the additional power requirements for IPT solutions, include all of these devices in your calculations. Use the IPT power calculator that is available on Cisco.com to calculate the power supply requirements for the switches:
An uninterrupted power backup system ensures high availability of the IPT network. Analyze the HVAC requirements for the additional IPT network components that are going to be deployed in the server/data centers. Confirm with facility management that the building where the IPT equipment will be installed has enough air conditioning capacity to meet the IPT equipment cooling requirements.
Assessing the voice network consists of examining the legacy PBX, voice-mail system, ACD systems, voice circuits, extension numbers, dial plan, and various call features. To successfully integrate the legacy equipment with the IPT network, you might need to purchase additional hardware or software licenses for the legacy equipment. The readiness process ensures that you are equipped with all such interfacing equipment before you move the users from the legacy system to the new-world IPT system. You can identify these types of special requirements during the planning phase of the IPT project, as discussed in Chapter 4, “Planning Phase,” and with the help of the questionnaires in Appendix B, “IPT Planning Phase: Network Infrastructure Analysis Questionnaire,” and Appendix C, “IPT Planning Phase: Telecom Infrastructure Analysis Questionnaire.”
A stable, reliable, highly available data network architecture is essential for the success of the converged network deployment. This requires LAN/WAN support teams to complete the preconfiguration tasks discussed in Chapters 4 and 5, “Design Phase: Network Infrastructure Design,” such as configuring the switch ports where IP Phones, gateways, and IPT servers terminate, and configuring the quality of service (QoS) on WAN links. The data network readiness includes analysis of the LAN/WAN infrastructure readiness to ensure that all the prerequisite changes are implemented.
The IPT readiness check verifies that the design is completed for the call-processing servers (such as the CallManager server), the voice-mail system, IPT applications, and all the devices supporting the IPT network. Directly diving into the implementation phase without completing the proper design introduces delays and might prevent you from meeting all the requirements of the new IPT system.
During the design phase of the IPT solution, you should select the equipment and CallManager software version that you need in the network, depending on the features required. Before you deploy the IPT solution, to ensure interoperability, you need to consider the software versions for the other applications, such as Unity and IPCC Express, that need to interact with CallManager and the software versions on the voice gateways.
Refer to the Cisco CallManager Compatibility Matrix on Cisco.com before you make a decision regarding the software versions for the other applications:
After you complete the implementation readiness analysis, you can proceed with the actual implementation of various IPT components. Chapters 5, 6, “Design of Call Processing Infrastructure and Applications,” and 7, “Voice-Mail System Design,” covered various design aspects of the network infrastructure, call processing, enabling features, and voice-mail system. This section covers the basic implementation steps and introduces you to some tools that you can use to verify whether the implementation of the IPT components is successful.
This section covers the high-level implementation steps involved in building the CallManager and application servers. Because the installation procedures might vary from one version to another, you should refer to the installation guides and release notes provided with the CallManager for detailed installation procedures.
The first step in setting up the CallManager or any other application server is to install the operating system on the servers via the Cisco-provided OS CD-ROM/DVD-ROM. You can perform this operation in parallel if you have to build a large cluster with many servers. Collect the information specified in the “Configuration Checklist for Installation of CallManager and Other Application Servers” section of Appendix H before you install any server.
Note
Use the Cisco-provided OS installation CD-ROM/DVD-ROM to install the operating system on Unity systems. Cisco supplies these discs if you purchase the hardware directly from Cisco. You should use original Microsoft Windows 2000/2003 Server CD-ROMs to install the OS on Unity systems that Cisco does not directly supply.
After you install the OS on all the servers, follow these steps to complete the CallManager installation in the entire cluster:
Verify that all servers are running the same base OS version. (Refer to the “Checking CallManager Version” section later in this chapter for the procedure.)
Install operating system updates on all the servers.
Update the C:WinntSystem32Driversetchosts and LMHOSTS files on all servers with all the server entries in the cluster and run the nbtstat -R command from the DOS command prompt.
Install the CallManager software on the publisher server by following the instructions given in the installation guides on Cisco.com.
By default, on the CallManager servers, no CallManager-related services are activated except for the Database Layer Monitor service. To enable other services that you need, choose Tools > Service Activation on the CallManager Serviceability page.
Install CallManager software on other subscribers sequentially; use the same passwords for all the servers in the cluster and activate the necessary services.
Check the SQL subscriptions and ensure that the replication process is working properly. (Refer to the “Database Layer Tool to Check SQL Subscriptions” section later in this chapter for the detailed procedure for doing this task.)
Note
After you install the CallManager, log in to the CallManager Administration page and choose System > Server. By default, you will see the name of the server you entered during the installation. Change this to the IP address of the corresponding server if you are not using DNS. If you are using DNS, ensure that the DNS server has the entry for all the servers in the cluster. Without this, IP Phones will fail to resolve the CallManager DNS name, and IP phones will fail to register with CallManager.
You can install applications such as IP Contact Center Express (IPCC Express) and Cisco Emergency Responder (CER) after you complete the CallManager installation. During the installation of these applications, you might have to provide the IP address or host name of the CallManager publisher and subscriber servers so that the applications can establish the communication with the CallManager servers. It is essential that you build the CallManager servers and make them available on the network before you proceed with the installation of other applications.
After you complete the basic installation of CallManager servers and other application servers, perform the following tasks:
Install the antivirus software and Cisco Security Agent software on all the servers.
Install tools such as Bulk Administration Tool (BAT), Tool for Auto-Registered Phones Support (TAPS), and Dialed Number Analyzer (DNA) on the CallManager publisher server.
Install the Backup and Restore System (BARS) software to back up the CallManager database on the CallManager publisher server.
Voice gateways in the IPT network provide public switched telephone network (PSTN) access to the IP Phones. The following list gives the general implementation tasks that are applicable to all voice gateways:
Install and configure the gateway or voice network module in the network/device. Refer to the installation and configuration documentation on Cisco.com for the model of gateway that you are configuring.
Configure the trunk interface on the gateway to the PSTN and configure dial peers if required. Refer to the voice-feature software configuration documentation or Cisco IOS documentation for the model of the gateway you are configuring.
Add and configure the gateway in CallManager.
Configure the dial plan for the gateway for routing calls out to the PSTN or other destinations.
Configure a route group, route list, and route pattern in CallManager.
Reset the gateway in CallManager to apply the configuration settings.
Verify the connectivity by making test calls.
This section describes the steps involved in configuring two different types of voice gateways proposed for the XYZ IPT network and provides troubleshooting tips. Because there is a wide selection of voice gateways, refer to the documentation on Cisco.com to configure the other types of gateways that are not described here. The following gateways are described in this chapter:
Cisco Catalyst WS-X6608-T1 gateway
Cisco Catalyst Communication Media Module (CMM) gateway
This section covers the steps involved in configuring the Cisco Catalyst WS-X6608-T1 gateway module in Cisco CallManager, procedures to verify the gateway registration status in CallManager, and some common troubleshooting steps.
Before you configure a T1/E1 port on a Catalyst WS-X6608-T1/E1 or WS-SVC-CMM module, you need to obtain the MAC address of the voice port. You can do this on Catalyst 6xxx series switches by running the show module command, as shown in Example 8-1. From the output, you can see that the module in slot 4 is a WS-X6608-T1 module and has eight MAC addresses assigned, which are in the range 00-01-64-11-c6-7c to 00-01-64-11-c6-83. The MAC address of the first port 4/1 is 00-01-64-11-c6-7c, the second port 4/2 is 00-01-64-11-c6-7d, and so forth, with the MAC address of the port 4/8 being 00-01-64-11-c6-83.
Example 8-1. Obtaining the MAC Address of the T1/E1 Port
cat6k-voice> (enable) show module Mod Slot Ports Module-Type Model Sub Status --- ---- ----- ------------------------- ------------------- --- ------- 1 1 2 1000BaseX Supervisor WS-X6K-SUP1A-2GE yes ok 15 1 1 Multilayer Switch Feature WS-F6K-MSFC no ok 3 3 48 10/100BaseTX Ethernet WS-X6348-RJ-45 no ok 4 4 8 T1 WS-X6608-T1 no ok 5 5 24 FXS WS-X6624-FXS no disable 6 6 5 Communication Media Mod. WS-SVC-CMM no ok 7 7 5 Communication Media Mod. WS-SVC-CMM no ok 9 9 8 T1 WS-X6608-T1 no ok Mod Module-Name Serial-Num --- -------------------- ----------- 1 SAD04480PZW 15 SAD04480KXC 3 SAL05031N6H 4 SAD04320KZA 5 SAD04430ASH 6 SAD075303F1 7 SAD0640008A 9 SAD04450DS1 Mod MAC-Address(es) Hw Fw Sw --- -------------------------------------- ------ ---------- --------------- 1 00-02-7e-26-06-a2 to 00-02-7e-26-06-a3 7.0 5.3(1) 8.1(3) 00-02-7e-26-06-a0 to 00-02-7e-26-06-a1 00-d0-03-14-74-00 to 00-d0-03-14-77-ff 15 00-02-7e-26-06-a4 to 00-02-7e-26-06-e3 1.4 12.1(1)E, 12.1(1)E, 3 00-04-6d-44-80-c0 to 00-04-6d-44-80-ef 1.4 5.4(2) 8.1(3) 4 00-01-64-11-c6-7c to 00-01-64-11-c6-83 1.1 5.4(2) 8.1(3) 5 00-d0-d3-3e-9d-34 2.0 5.4(2) 8.1(3) 6 00-03-fe-ad-d9-6a to 00-03-fe-ad-d9-73 2.2 12.2(13)ZP 12.2(13)ZP2, 7 00-02-7e-e4-a2-de to 00-02-7e-e4-a2-e7 2.1 12.2(13)ZP 12.2(13)ZP, 9 00-01-c9-6b-33-20 to 00-01-c9-6b-33-27 1.1 5.4(2) 8.1(3) Mod Sub-Type Sub-Model Sub-Serial Sub-Hw Sub-Sw --- ----------------------- ------------------- ----------- ------ ------ 1 L3 Switching Engine WS-F6K-PFC SAD045007LA 1.1
To assign the IP address for the voice port, the best practice is to assign the static addresses for the critical components such as servers, gateways, and gatekeepers. Example 8-2 shows the Catalyst 6xxx command to configure the static address for the port 4/1. You can see that Dynamic Host configuration Protocol (DHCP) is disabled and the IP address configured for the port is 172.21.54.90 with a subnet mask of 255.255.255.128. The switch port is on VLAN 401. Because DHCP is disabled, the TFTP server address, which in this example is 172.21.51.237, should be configured manually.
Example 8-2. Assigning a Static IP Address for the T1/E1 Port
cat6k-voice> (enable) set port enable 4/1 Port 4/1 enabled. cat6k-voice> (enable) set port voice interface 4/1 dhcp disable 172.21.54.90 255 .255.255.128 vlan 401 tftp 172.21.51.237 gateway 172.21.54.2 Port 4/1 DHCP disabled. System DNS configurations used. cat6k-voice> (enable)
To configure a gateway on the CallManager Administration page, choose Device > Gateway and click the Add a New Gateway option on the Gateway page. On the Add a New Gateway page, select the gateway type and device protocol used for signaling.
To add a T1 port on a WS-X6608-T1 module and configure the T1 port for PRI protocol, choose the Cisco Catalyst 6000 T1 VoIP gateway as a gateway type and Digital Access PRI as the device protocol in the Add a New Gateway Page, and click the Next button. This brings up the Gateway configuration page, as shown in Figure 8-1. You need to type the MAC address of the port. In Figure 8-1, the MAC address entered is for port 4/1.
You need to provide values for the fields such as Device Pool, Interface parameters for the T1/E1, calling search space (CSS), and so forth. These values depend on the design. Refer to the “Gateway Selection and Sizing” section in Chapter 6 to understand the importance of the other parameters.
After configuring the gateway on the CallManager, you can check the status of the gateway registration, as shown in Example 8-3. If the port is successfully registered, you should see the word “registered” under CallManagerState, as shown in Example 8-3.
Example 8-3. Verifying the Gateway Registration Status on the Switch
cat6k-voice> (enable) show port 4/1 * = Configured MAC Address Port Name Status Vlan Duplex Speed Type ----- -------------------- ---------- ---------- ------ ----- ------------ 4/1 Connection-to-PSTN connected 401 full 1.544 T1 Port DHCP MAC-Address IP-Address Subnet-Mask -------- ------- ----------------- --------------- --------------- 4/1 disable 00-01-64-11-c6-7c 172.21.54.90 255.255.255.128 Port Call-Manager(s) DHCP-Server TFTP-Server Gateway -------- ----------------- --------------- --------------- --------------- 4/1 172.21.51.237 - 172.21.51.237 172.21.54.2 Port DNS-Server(s) Domain -------- ----------------- ------------------------------------------------- 4/1 - - Port CallManagerState DSP-Type -------- ---------------- -------- 4/1 registered C549 Port NoiseRegen NonLinearProcessing ----- ---------- ------------------- 4/1 enabled enabled Port Trap IfIndex ----- -------- ------- 4/1 disabled 43 Port Status ErrDisable Reason Port ErrDisableTimeout Action on Timeout ---- ---------- ------------------- ---------------------- ----------------- 4/1 connected - Enable No Change Idle Detection -------------- cat6k-voice> (enable)
You can verify the gateway registration status from the CallManager Gateway configuration page, as shown in Figure 8-2.
You can also use Windows 2000 performance counters or Real-Time Monitoring Tool (RTMT) to view the gateway registration status. Chapter 9 discusses these tools in detail.
Figure 8-3 shows the performance counters on a CallManager server for the performance object MGCP PRI device. To access the Performance Monitor application on a CallManager server, click Start > Programs > Administrative Tools > Performance. Figure 8-3 shows the status of the 23 B channels (channels 1 to 23) and the D channel (channel 24) of the selected MGCP PRI gateway. The status code for channel 23 is 3 (Busy—indicates an active call on the channel), whereas the status code for all the other B channels is 2 (Idle—not in use).
As you can see in Figure 8-3, after registering the gateway with the CallManager, you can check the channel status through the performance counters and monitor the change in the status code after placing the calls. Figure 8-3 shows one active call on the PRI on channel 23. The gateway selected channel 23 because, in the CallManager configuration for this gateway, the channel selection order was configured as bottom up.
A status code of 0 (Unknown) indicates that the status of the channel could not be determined; 1 (Out of service) indicates that this channel is not available for use; 4 (Reserved) indicates that this channel has been reserved for use as a D channel or for use as a synchronous channel for E-1.
Implementing a voice gateway using a T1/E1 port on a CMM slightly differs from the procedure followed for the WS-X6608-T1 (E1) module. As mentioned in Chapter 6, the CMM module has four slots. One slot is an internal slot and is not available to plug in any T1/E1 module. The internal slot can only accept an Ad Hoc Conferencing and Transcoding (ACT) adapter. The three other slots can be filled either with three T1/E1 modules each with 6 T1/E1 ports (18 total) or any combination of T1/E1 modules and ACT adapters.
With WS-X6608-T1 (E1) modules, unused T1/E1 ports can be configured as conferencing and transcoding resources. This is not the case with T1/E1 ports on the CMM module. You require the ACT adapter for conferencing and transcoding purposes. Another difference between the WS-X6608-T1 module and CMM is that CMM supports both H.323 and MGCP protocols, besides supporting Survivable Remote Site Telephony (SRST). The following steps cover how to provision the CMM module.
The CMM module has its own Cisco IOS image. To access the CMM module from the Catalyst switch running the Cat OS and Multilayer Switch Feature Card (MSFC) running the IOS code, enter the session mod_num command on the switch console, as shown in Example 8-4. The mod_num is the module number where CMM is installed. From Example 8-1, the CMM modules are available in modules 6 and 7 on the Cat6k-voice switch used in this configuration.
Example 8-4. Accessing CMM from the Switch Console
cat6k-voice> (enable) session 6 Trying VOICE-GATEWAY-6... Connected to VOICE-GATEWAY-6. Escape character is '^]'. User Access Verification Password: SJ-CMM1>en Password: SJ-CMM1#
Note that the host name used for the CMM is SJ-CMM1. You have to input this host name when configuring the CMM in CallManager Administration.
The CMM runs the Cisco IOS image. Therefore, the configuration steps for T1/E1 ports are similar to those for any T1/E1 port on a Cisco IOS router. Example 8-5 shows the configuration for a T1 port. The configuration for the E1 port is similar except that you select the E1 port and configure different line code and framing.
Example 8-5. Configuring the T1/E1 Port
SJ-CMM1# conf Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. ! Configure the ISDN Switch type SJ-CMM1(config)#isdn switch-type primary-ni ! Enable the MGCP process on the CMM SJ-CMM1(config)#mgcp ! Specify the MGCP Call Agent address, which is, the IP address of the primary ! CallManager. You can specify backup CallManager's by using the command ! ccm-manager redundant-host command SJ-CMM1(config)#ccm-manager mgcp SJ-CMM1(config)#mgcp call-agent 172.21.51.237 ! Configure the Gigabit ethernet interface. This is the interface through ! which the T1/E1 ports communicate with CallManager SJ-CMM1(config)#int gigabitEthernet 1/0 SJ-CMM1(config-if)#ip address 172.21.54.89 255.255.255.128 SJ-CMM1(config-if)#no shutdown SJ-CMM1(config-if)#ip default-gateway 172.21.54.5 ! Configure the T1 port with correct line code and framing SJ-CMM1(config)#controller t1 1/0 SJ-CMM1(config)#no shutdown SJ-CMM1(config-controller)#linecode b8zs SJ-CMM1(config-controller)#framing esf SJ-CMM1(config-controller)#pri-group timeslots 1-24 service mgcp ! After configuring the pri-group command under the T1/E1 controller, ! router adds the D channel interface. ! The ISDN bind command configures the ISDN-PRI back-haul to the CallManager SJ-CMM1(config)#interface serial 1/0:23 SJ-CMM1(config-if)#isdn bind-l3 ccm-manager Configure the POTS dial peer and associate the voice port 1/0:23 to this dial peer. The application command informs the CMM that the voice port 1/0:23 is controlled by MGCP. SJ-CMM1(config)#dial-peer voice 1 pots SJ-CMM1(config-dial-peer)#application mgcp SJ-CMM1(config-dial-peer)#port 1/0:23
Because this is an MGCP gateway, the entire dial plan configuration is configured in the CallManager. If you are configuring the T1/E1 port as an H.323 gateway, an additional step here is to configure the local dial plan on the router. Refer to the Chapter 6 section “Survivable Remote Site Telephony” to see a sample configuration of a local dial plan on routers. When the router is in SRST mode, the gateway falls back to H.323 mode and uses the local dial plan to perform the call routing.
To configure a gateway on the CallManager Administration page, choose Device > Gateway. Click the Add New Gateway option on the Gateway page. On the Add a New Gateway page, choose Communication Media Module as the gateway type and click Next. In the Domain Name field, enter the host name of the CMM module and select the interface cards inserted into the modules, as shown in Figure 8-4. Click Insert to insert the gateway into the CallManager.
After you insert the CMM module, you need to specify the subunits that are inserted in the CMM module. In Figure 8-5, the T1 card WS-X6600-T1 is selected.
After you insert the subunits and update the configuration, click the T1 port that you want to configure. The configuration of the T1 port is similar to that of the T1 port configuration on the 6608, as shown in Figure 8-5. You need to provide values for the fields such as Device Pool, Interface parameters for the T1/E1, calling search space, and so forth.
After completing the configuration, you need to verify whether the physical connection to the PSTN is up. You can use the show isdn status command, as shown in Example 8-6. The Layer 2 status should report MULTIPLE_FRAME_ESTABLISHED.
Example 8-6. Verifying the T1/E1 Port Connectivity Status on the CMM
SJ-CMM1#show isdn status Global ISDN Switchtype = primary-ni ISDN Serial1/0:23 interface dsl 0, interface ISDN Switchtype = primary-ni L2 Protocol = Q.921 L3 Protocol(s) = CCM-MANAGER Layer 1 Status: ACTIVE Layer 2 Status: TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 0 CCBs = 0 The Free Channel Mask: 0x807FFFFF Number of L2 Discards = 0, L2 Session ID = 3 Total Allocated ISDN CCBs = 0 SJ-CMM1#
If you do not see the successful connectivity status, verify that line code, framing, and clocking are configured correctly. You can use the show controllers t1 1/0 command to verify these configurations, as shown in Example 8-7.
Example 8-7. Verifying the Controller Configuration
SJ-CMM1#show controllers t1 1/0 T1 1/0 is up. Applique type is Channelized T1 Cablelength is long gain36 0db No alarms detected. alarm-trigger is not set Framing is ESF, Line Code is B8ZS, Clock Source is Line. Data in current interval (15 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs SJ-CMM1#
To verify the T1/E1 port registration status on the CMM, use the show ccm-manager command, as shown in Example 8-8. The output should show Registered if the port is successfully registered to the CallManager.
Example 8-8. Verifying the Registration Status of the T1/E1 Port on the CMM
SJ-CMM1#show ccm-manager MGCP Domain Name: SJ-CMM1 Priority Status Host ============================================================ Primary Registered 172.21.51.237 First Backup None Second Backup None Current active CallManager: 172.21.51.237 Backhaul/Redundant link port: 2428 Failover Interval: 30 seconds Keepalive Interval: 15 seconds Last keepalive sent: 23:24:31 UTC Mar 22 1993 (elapsed time: 00:00:09 ) Last MGCP traffic time: 23:24:31 UTC Mar 22 1993 (elapsed time: 00:00:09 ) Last failover time: None Last switchback time: None Switchback mode: Graceful MGCP Fallback mode: Not Selected Last MGCP Fallback start time: None Last MGCP Fallback end time: None PRI Backhaul Link info: Link Protocol: TCP Remote Port Number: 2428 Remote IP Address: 172.21.51.237 Current Link State: OPEN Statistics: Packets recvd: 463 Recv failures: 76 Packets xmitted: 390 Xmit failures: 0 PRI Ports being backhauled: Slot 1, port 0 Configuration Error History: FAX mode: cisco SJ-CMM1#
This section provides troubleshooting tips if you are having trouble completing the gateway registration, confronting issues with port status, or experiencing unsuccessful inbound/outbound calls for Catalyst-based voice gateways.
To determine whether the problem is related to a registration issue, do the following:
Check the basic network connectivity by pinging the TFTP server and the CallManager from the gateway module.
Check whether the port that is configured for the voice gateway is enabled.
Check whether the correct IP address, subnet mask, gateway, and VLAN are configured for the port.
If you are not using DHCP, ensure that the DHCP helper address is configured on the routed interface that is directly connected to the subnet where the gateway port resides.
Check whether the correct TFTP server is configured.
If you are using the DNS name for the TFTP server, ensure that the switch can resolve the TFTP server name to the IP address.
If all of the previous points are correct, check that the MAC address entered in the CallManager matches the MAC address of the port.
To determine whether the problem is related to a connectivity issue, check whether the port status is Connected; refer to Example 8-3. If it is not, check that the interface parameters such as the isdn switch-type, line code, and framing configured on the gateway are set according to the values required by your local telco; refer to Example 8-5.
To determine whether the problem is related to unsuccessful calls (made to and from a Cisco IP Phone through the gateway), verify the following:
If you cannot make outbound calls from a Cisco IP Phone, check the dial plan configurations and Cisco IP Phone’s CSS configuration.
If you are not able to receive incoming calls from the gateway, check the values in the Inbound Calls section of the Gateway configuration page in the CallManager, such as the Calling Search Space and Significant Digits fields.
If you still have problems, look into the TFTP traces or CallManager traces to resolve the issue.
The preceding paragraphs discussed the implementation procedures and troubleshooting procedures for commonly used gateways. If your network uses other gateways, refer to the Cisco.com product-specific documentation for configuration and troubleshooting assistance.
You can deploy IPT components such as IP Phones and gateways either manually or by using automated tools such as BAT. Use of the automated tools makes the IPT implementation more robust and smooth. These tools can assist you in speeding up the IPT implementation process in most cases, but using them is not mandatory for the IPT implementation process. The following sections describe the implementation of IP Phones using BAT and the physical installation of IP Phones.
To enable you to configure or update your CallManager database faster and with less manual entry for larger systems, CallManager ships BAT. By using BAT, you can perform bulk add, update, and delete operations of phones, users, and gateways. The export feature in BAT comes in handy when you are consolidating multiple CallManager clusters into a single CallManager cluster. By using the export feature, you can export the configuration information of phones and users from a CallManager cluster into a CSV file and import the contents of the CSV file into the new CallManager cluster.
BAT is available on the CallManager Install Plugins page. You can install BAT only on a CallManager publisher server. After you install BAT, you can access it by entering the following URL:
http://CCM_PUBLISHER_IP_ADDRESS/bat
A complete installation and configuration guide for BAT is available at the following URL:
The next two sections discuss the procedures and tools that you can use to provision Cisco IP Phones in the CallManager.
When you are using BAT to add the MAC address of the IP Phones for a large-scale IPT deployment, you need to type each MAC address, one by one, into the Bat.xlt (BAT Microsoft Excel Template) file, which is a tedious process.
Use of bar-code scanners greatly reduces the chance of human error in entering the MAC addresses while configuring the IP Phones in CallManager and helps you to accelerate largescale IP Phone deployments.
The back of the IP Phone has a barcoded MAC address. Barcode vendors offer a wide variety of models. The scanner you choose needs to scan the MAC address and put it in the database efficiently. Here is a brief list of barcode scanner manufacturers:
Socket Communications—. http://www.socketcom.com/
Symbol Technologies—. http://www.symbol.com
Wasp Technologies—. http://www.waspbarcode.com
While choosing among different scanner models, the following are features to look for:
It can read and insert the barcode value into any type of application that is running on the workstation OS that you are using.
It can write the decoded value into any standard application without the need to install special software on the workstation.
It is easy to hook up with your workstation, such as via a keyboard interface or USB interface.
After you connect the scanner to your workstation, open the Bat.xlt file (you can copy this file from C:CiscoWebsBATExcelTemplate directory on the CallManager publisher server to your location workstation) and scan the barcode of the MAC address on the back of the IP Phone. Repeat this process for all the IP Phones. The scanner records the value of the cell to which the pointer is pointing. The pointer moves automatically to the next row or to the next cell after scanning each input. After scanning the MAC address of the IP Phone, you can input the rest of the phone configuration information, such as the extension number, number of lines on the phone, number of speed dials, and so forth, into the BAT Excel template.
When you are ready with all the information for the IP Phones that need to be deployed, export the data in the BAT Excel template file into a CSV file. You can then import this CSV file via the BAT application to configure the IP Phones in the CallManager.
An alternate approach to the barcode scanners is to use TAPS in conjunction with BAT to update auto-registered phones and replace phones that have a predefined device configuration. TAPS is available on the CallManager Install Plugins page. You can use TAPS to avoid manual entry of the MAC addresses of the IP Phones in the database.
TAPS requires the Customer Response Solution (CRS) server to execute a script that plays prompts and receives the digits from the user to configure the IP Phones. If you have not purchased CRS server software, you can download the optional, free-of-charge software called Cisco CallManager Extended Services, which is available on Cisco.com on the CallManager software downloads page, to provision the IP Phones using TAPS. The Cisco CallManager Extended Services includes the CRA engine that can use applications such as TAPS and Cisco Auto Attendant (AA) can use. The CRA engine that is included with Extended Services comes with a limited number of ports and does not offer you the CRA editor utility to create or modify the application scripts.
The TAPS installation process copies the TAPS script (TAPS.aef) to the C:Program FilesWfavvid directory on to the CRA or Extended Services server.
If you have a co-resident CallManager and CRS/Extended Services application installation, you need to install the TAPS only once on the CallManager publisher server. If you have CRS installed on a separate server, you need to install TAPS both on the CallManager publisher server and on the CRS server.
Refer to the BAT user guide on Cisco.com for instructions on installing and using TAPS:
Install Cisco IP Phones in your network by connecting the Ethernet wire coming from the Ethernet jack in the wall to the back of the IP Phones. IP Phones obtain the DHCP address and TFTP server information and attempt the registration with CallManager.
A complete IP Phone implementation guide is available on Cisco.com:
To troubleshoot issues with Cisco IP Phone registration during implementation and operation, refer to the following document on Cisco.com:
The “Dial Plan Architecture” section in Chapter 6 discussed the steps involved in designing the dial plan. The implementation of the dial plan consists of configuring the following dial plan components in the CallManager:
Partitions
Calling search spaces
Route groups
Route lists
Route patterns
Translational patterns
Configure your dial plan based on the final design. The next section introduces the Dialed Number Analyzer tool and explains how this tool can help you verify whether the dial plan configured in the CallManager is working according to the design.
If you have a large dial plan and complex call-routing requirements, you end up with a huge number of dial plan components. The DNA tool helps you to troubleshoot issues when you have such complex dial plans.
From the CallManager perspective, you can make different types of calls, such as IP Phone-to-IP Phone calls, gateway-to-IP Phone calls, IP Phone-to-gateway calls, gateway-to-gateway calls, and calls to feature-specific patterns. The DNA tool recognizes all of these types of calls to display end-to-end details pertaining to the call. In CallManager, the calling and called party transformations affect the calling and called number. The tool considers all of these transformations configured under various dial plan elements and shows the final transformed number.
The DNA tool compares the dialed digits with the list of route patterns specified in the CSS for the device selected (IP Phone, gateway, trunk) and shows you the call flow path. If the call flow path shown by the DNA tool does not match what you thought it would, you can go back, change your dial plan, and rerun the DNA tool.
As discussed in the next section, you do not have to look at CallManager traces to know whether the call flow is correct. After verifying from the DNA tool that the call flow is as per your design, you can make a real call to check whether the call goes through. If you still have problems, the problem could be configurations on the terminating device or the devices outside the CallManager’s control. For example, if you have an H.323 gateway, the DNA tool can show you the call reaching the H.323 gateway. The configurations on the H.323 gateway are not known to CallManager; therfore, they are not known to the DNA tool.
The DNA tool is available for installation on the Cisco CallManager Install Plugins page. You can also download the tool from Cisco.com:
Recall from the discussion in the “Calling Search Space Design” section in Chapter 6 that you can configure the CSS for an IP phone device at the device level, at the line level, or at both places. If you configure CSS at both places, CallManager places the partitions that appear in the line-level CSS on the top of the list and selects the best match.
Assume that you wanted the IP Phone 2001, with the following configuration, to make only local, long-distance, toll-free, and emergency calls, but no international calls:
The IP phone, 2001, is in partition pt_internal.
The device-level CSS is css_SJ.
The line-level CSS is css_line_LD.
The partitions that CSS references are the same as the ones described in Tables 6-41 to 6-43.
To test the configuration, in DNA, select Analysis > Phones and select the IP Phone whose line is 2001. Enter an international number as the dialed digits 90119187724436598. Figure 8-6 shows the output of the DNA tool.
As shown in Figure 8-6, the device-level CSS, css_SJ, has a partition (pt_INT_SJ) that allows international calls. The css_line_LD CSS has a partition that blocks international calls (pt_block_INT). Based on the CSS combination rule discussed in the “Calling Search Space” section of Chapter 6, the partition at the line level comes first. Hence, the international call from the IP Phone 2001 is blocked, which is the desired result.
You can analyze any dialed digits this way and test your dial plan before deploying it in the production server. In addition, before making major changes to the dial plan in the production servers, configure the changes in the lab servers and use the DNA tool for verification. If you are satisfied with the results, make the changes in the production server.
The IPCC Express standard solution will be deployed to use the AutoAttendant (AA) functionality to meet XYZ’s requirements. This is in addition to the call center previously sized in Chapter 6 for XYZ. As mentioned in Chapter 6, in the “Customer Response Solution Server Scalability and Sizing” section, there will be a general phone number to reach a Cisco IP Interactive Voice Response (Cisco IP IVR) menu. This IP IVR menu gives the caller the choice to transfer to either the AutoAttendant or the sales support queue. The AA application is one of the application scripts available in the CRS server. The CRS server communicates with CallManager (specifically, the CTI Manager service) via the Java Telephony API (JTAPI).
Applications such as AA and IP Integrated Contact Distribution (IP ICD) execute steps configured in the application scripts. The application script that is responsible for the AutoAttendant is aa.aef, and it is stored in the CRS server.
Figure 8-7 shows the call flow that describes the sequence of steps involved in invoking AA. In Figure 8-7, the Computer Telephony Integration (CTI) route point is a virtual device that can receive multiple simultaneous calls for application-controlled redirection. In this case, the application is AA. Multiple simultaneous users, up to the configured number of CTI ports for the application, can dial the number assigned to IP AA and have their calls routed to a user’s extension or the operator’s phone.
The CTI route point and CTI ports behave like a hunt group. All the calls for the applications enter via the CTI route point and are then handed off to another phone (CTI port) for additional processing. This frees up the original CTI route point number to accept the next call.
In the example shown in Figure 8-7, the following sequence of steps takes place:
An external user dials 408-555-3877 from the phone.
The PSTN sends the last ten digits of the Direct Inward Dial (DID) number (4085553877) to the gateway, which is configured to present the last four digits to CallManager.
The call reaches CallManager on the CTI route point DN 3877. This CTI route point is assigned to the JTAPI trigger in the CRS server.
The route points and CTI ports are configured in the CRS server such that all calls received at the CTI route point number are routed through the CRS server’s JTAPI subsystem to its application script—in this case, aa.aef.
The CRS server uses the available CTI port to accept the incoming call.
The CTI port performs a consultative transfer to an IP phone or to an operator based on the user’s response to the application prompts.
Every application has one CTI route point and a few CTI ports associated with it. The call center application will have a CTI route point, and the IP IVR application will have another CTI route point.
Design and implementation of AA involves the following tasks:
Identify the number of CTI ports required.
Identify the CTI route point number.
Identify the operator extension.
The “Customer Response Solution Server Scalability and Sizing” section in Chapter 6 covered the sizing of CTI ports required for the call center. Additional CTI ports are required to handle AA calls.
In Figure 8-6, in addition to a CTI port group, you need to provision media control groups on the CRS server. While designing the CRS server, you have three choices regarding the provision of media:
Cisco Media Termination
Nuance Asynchronous Speech Recognition (ASR)
None (media-less calls)
When determining the number of licenses required for the CRS server, note the following:
All calls configured to use media are counted against the number of licensed IVR ports.
All calls configured to use ASR are counted against the number of licensed ASR ports.
Calls configured to use no media are not counted against media licenses and are free to be processed.
A media-less call is a call for which no media interaction is expected. Examples of applications that require no media are E.911 redirect and simple queuing. Examples of calls that require media interaction are calls that prompt the user to enter digits, calls that get DTMF digits, and calls that use speech recognition.
You can put a media-less call on hold and play Music on Hold (MoH) for the caller. CallManager plays the MoH stream for the caller while the caller is waiting in the queue.
The CRA server does not generate or play the music stream for the caller. The media-less call does not use as much CPU as the other types of calls that require access to media. Hence, avoiding media allows you to increase the capacity of the CRA platform.
Refer to the following URL to find out how to play MoH to IP ICD callers in a queue:
The AA will be deployed using the aa.aef script provided with the IPCC Express standard server. Configuration of AA involves the following:
Configurations in the CallManager
Configurations in the CRS server
Detailed steps of installing and configuring the applications are available on Cisco.com. The following sections discuss only high-level configuration steps.
The following three configuration steps are required to configure the AutoAttendant. The prerequisite for executing these steps is to complete the initial CRA setup. (Refer to the product documentation on the initial setup.)
Configure the CTI route point. On the CallManager Administration page, choose Device > CTI Route Point. (Refer to Table 6-40 in Chapter 6 for the CTI route point that is assigned to the AA application.)
Configure the CTI ports. On the CallManager Administration page, choose Device > Phone. Select Add a New Phone and select the phone type as CTI Port. (Refer to Table 6-40 in Chapter 6 for the directory numbers assigned to CTI ports used for the AA application.)
Create a user in the DC directory. On the CallManager Administration page, choose User > Add a New User to create the user and associate the CTI route point and the CTI ports with the user.
Table 8-1 lists the settings for the CTI route point, CTI ports, and JTAPI user information that need to be configured in the CallManager server to set up the AA application.
Table 8-1. Configuration Settings in CallManager for AA
Step Number | Configured Device | Field | Value |
|---|---|---|---|
1 | CTI Route Point | Device Name | AARP |
Description | AA Route Point | ||
Device Pool | DP-SanJose | ||
CSS | CSS-SJ | ||
Location | SanJose | ||
CTI Route Point DN | Directory No | 3877 | |
Partition | P-Internal | ||
Css-Restricted | |||
Display (Internal Caller ID) | AutoAttendant | ||
External Phone Mask | 408555xxxx | ||
2 | CTI Port Device You need to create multiple CTI ports. Each device will have a unique name (CTIPort1, CTIPort2, and so on). | Device Name | CTIPort# |
Description | CTI Ports | ||
Device Pool | DP-SanJose | ||
CSS | CSS-SJ | ||
Location | SanJose | ||
AAR CSS | None | ||
CTI Port DN Each CTI port will have a unique directory number (1611, 1612 .. 1630). The CFB and CFNA of the first CTI port, 1611, will be set to the 1612, and the CFB and CFNA of the second CTI port, 1612, will be set to 1613. The CFB and CFNA for the last CTI port will be set to the first one, 1611. | Directory No | 1611–1630 | |
Partition | P-Internal | ||
CSS | CSS-Restricted | ||
AAR Group | None | ||
Call Waiting | OFF | ||
CFB | 1612 | ||
CFNA | 1612 | ||
Display (Internal Caller ID) | AA CTI Port | ||
External Phone Mask | |||
3 | JTAPI User When associating devices, ensure that the No Primary Extension and No ICD Extension check boxes are checked. | First Name | Jtapi |
Last Name | User | ||
User ID | Jtapiuser | ||
PIN | 12345 | ||
Password | Cisco123 | ||
Enable CTI Applications Use | Checked | ||
Device Association | 3877, 1611–1630 |
The following configurations are required on the CRS/CRA server to enable the AutoAttendant application. Refer to Figure 8-7 to understand how the following configuration steps fit into the overall call flow. These steps require use of the CRA Admin page, which you can access at the following URL:
http://IP_ADDR_OF_CRA_SERVER/appadmin
Configure the AutoAttendant application. On the CRA Admin page, choose Applications > Configure Applications.
Configure the JTAPI provider. On the CRA Admin page, choose Subsystems > JTAPI > JTAPI Provider.
Configure the CTI port group and JTAPI call control group that consist of CTI ports that are defined in Table 6-40 (DN 1611 to 1630). On the CRA Admin page, choose Subsystems > JTAPI > CTI Port Groups.
Configure one media group consisting of 20 media ports. On the CRA Admin page, choose Subsystems > Cisco Media.
Configure the CTI route point trigger with DN 3877. On the CRA Admin page, choose Subsystems > JTAPI > JTAPI Triggers.
Table 8-2 lists the configuration settings that correspond to the preceding five configuration steps that need to be performed in the CRS server to set up the Cisco IP AA application.
Table 8-2. Configuration Settings in CRS Server for AA
Step Number | Configured Device | Field | Value |
|---|---|---|---|
1 | Application You can customize the welcome prompt by recording your own and uploading it into the CRS server directory. | Application Type | Cisco Script Application |
Name | AA | ||
Description | AutoAttendant | ||
ID | 0 | ||
Maximum No. of Sessions | 20 | ||
Enabled | Yes | ||
Script | aa.aef | ||
Welcome Prompt | AAWelcome.WAV | ||
Max Retry | 3 | ||
Operator Extension | 3000 | ||
Default Script | System Default | ||
2 | JTAPI Provider The JTAPI Provider list comprises the IP addresses of the CallManager servers (Subscriber 1, Subscriber 2). | JTAPI Provider (s) | 10.1.1.6, 10.1.1.7 |
User ID | Jtapiuser | ||
|
(Password is case sensitive) | Cisco123 | ||
3 | CTI Port Groups | Group ID | 0 |
Description | AA-CTI Port Group | ||
Associated CTI Ports | 1611–1630 | ||
CSS for Redirect | Redirecting Party | ||
4 | Cisco Media | Group ID | 0 |
Description | AA-Media Port Group | ||
No. of Channels | 20 | ||
5 | JTAPI Trigger | CTI Route Point DN | 3877 |
Language | System Default | ||
Application Name | AA | ||
Maximum No. of Sessions | 20 | ||
Idle Timeout | 5000 ms | ||
Enabled | Yes | ||
Call Control Group | AA-CTI Port Group | ||
Primary Dialog Group | AA-Media Port Group | ||
Secondary Dialog Group | AA-Media Port Group |
IP ICD is an IP-based Automated Call Distribution (ACD) system. IP ICD queues and distributes incoming calls destined for a group of CallManager users, which are also call center agents. Forty agents will have the capability to log in to the queue to take calls from the IP ICD.
However, based on the XYZ call center sizing, only 20 agents need to be logged in at any one time. The majority of the agents will be in San Jose. Seattle will have two agents, and Dallas will have one agent. At each shift, one supervisor agent will be logged into the queue.
Similar to the AutoAttendant script (aa.aef), IP ICD has a default script, icd.aef. You can customize the default script to your needs by using the CRA Application Editor, shown in Figure 8-8, that comes with CRS. The CRA Application Editor provides a drag-and-drop interface and several steps (including accepting the call, transfering the call, and so on.) that make it user friendly for developers.
To access the CRA Application Editor, on the CRA server, choose Start > Programs > Cisco CRA Administrator > Cisco CRA Editor.
You can also install the CRA Application Editor on your local workstation, create the scripts, and then upload the scripts to the CRA server. To install the CRA Application Editor locally on your workstation, open a web browser, access the CRA Admin page, and choose Tools > Plug-ins > Cisco CRA Editor.
All the application scripts are stored in the CRA server in the C:Program FilesWfavvid directory. Back up the original scripts before you modify them.
For XYZ, the default call center script, icd.aef, will be customized to add the time-of-day and day-of-week routing steps. Figure 8-9 shows the call-flow diagram for the modified script icd1.aef that queues the calls to the sales support queue of XYZ.
Figure 8-10 shows the modified icd.aef script deployed for the sales support group of XYZ based on the flow described in Figure 8-9.
IP ICD will be deployed using the modified icd1.aef script, as shown in Figure 8-10. Configuration of IP ICD involves configuration of the following:
CallManager
CRS server
CRS server that is specific to IP ICD
The detailed steps that you need to follow to install and configure the applications are available on Cisco.com. The following sections discuss only high-level configuration steps.
The steps in the CallManager for configuring IP ICD are similar to those for configuring the AutoAttendant. Table 8-3 explains the various configuration steps specific to IP ICD.
Table 8-3. Configuration Settings for CTI Route Points and CTI Ports, and JTAPI User for ICD
Step Number | Configured Device | Field | Value |
|---|---|---|---|
1 | CTI Route Point | Device Name | ICDRP |
Description | ICD Route Point | ||
Device Pool | DP-SanJose | ||
CSS | CSS-SJ | ||
Location | SanJose | ||
CTI Route Point DN | Directory No. | 3888 | |
Partition | P-Internal | ||
CSS | CSS-Restricted | ||
Display (InternalCaller ID) | ICD | ||
External Phone Mask | 408555xxxx | ||
2 | CTI Port Device You need to create multiple CTI ports. Each device will have a unique name (CTIPort1, CTIPort2, and so on). | Device Name | CTIPort# |
Description | CTI Ports | ||
Device Pool | DP-SanJose | ||
CSS | CSS-SJ | ||
Location | SanJose | ||
AAR CSS | None | ||
CTI Port DN Each CTI port will have a unique directory number (1601, 1602 .. 1610). The CFB and CFNA of the first CTI port, 1601, will be set to 1602, and the CFB and CFNA of the second CTI port, 1602, will be set to 1603. The CFB and CFNA for the last CTI port will be set to the first one, 1601. | Directory No. | 1601–1610 | |
Partition | P-Internal | ||
CSS | CSS-Restricted | ||
AAR Group | None | ||
Call Waiting | OFF | ||
CFB | 1602 | ||
CFNA | 1602 | ||
Display (Internal Caller ID) | ICD CTI Port | ||
3 | Associate ICD CTI Route Points and CTI Ports to the JTAPI User When you are doing device association, ensure that the No Primary Extension and No ICD Extension check boxes are checked. | User ID | jptapiuser |
Device Association | 3888, 1601–1610 | ||
4 | Add an RM JTAPI User When you are doing device association, ensure that the No Primary Extension and No ICD Extension check boxes are checked. | First Name | rmjtapi |
Last Name | user | ||
User ID | rmjtapiuser | ||
PIN | 12345 | ||
Password | Cisco123 | ||
Enable CTI Applications Use | Checked | ||
Device Association | Associate the call center agent phone DNs. | ||
5 | Assign ICD Extension to Call Center Agent Users Click the ICD Extension radio button on the CallManager Device Association page for all call center agent users. | Device Association | For all the call center users, click the ICD Extension and Primary Extension radio buttons. The Primary Extension radio button can be clicked for all other users. |
Configure the CTI route point. On the CallManager Administration page, choose Device > CTI Route Point. (Refer to Table 6-40 for the CTI route point assigned to IP ICD.)
Configure the CTI ports. On the CallManager Administration page, choose Device > Phone. Select Add a New Phone and select the phone type as CTI Port. (Refer to Table 6-40 for the directory numbers assigned to the CTI ports to be used by IP ICD.)
Associate the CTI route point and the CTI ports with the Jtapiuser created in Table 8-1. On the CallManager Administration page, choose User > Global Directory. Search for the Jtapiuser and complete the device association.
Create an RM JTAPI provider in the CallManager. This is a user account in the CallManager. All the IP Phone users that are call center agents are associated with this user. On the CallManager Administration page, choose User > Add a New User. The RM JTAPI user is another provider (refer to Figure 8-6) that monitors the following devices:
—The agent phone devices, such as IP Phones
—CTI ports that are configured for Cisco IP SoftPhones only
—Media-terminated desktop devices
Through this interface, the CRA server learns about the agent states such as work, reserved, ready, and not ready.
Identify the call center agents and, in the CallManager directory in the device association, click the ICD Extension radio button for those users. On the CallManager Administration page, choose User > Global Directory and update the ICD extension for all the call center users.
Notice that in Table 8-3, ICD has been assigned ten CTI ports. In Chapter 6, in the “Customer Response Solution Server Scalability and Sizing” section, the call center sizing calculation (see Figure 6-4) resulted in six IVR/CTI ports. However, ten CTI ports are provisioned so that the system can handle more callers.
The following configurations are required on the CRS/CRA server to enable IP ICD:
Configure ICD. On the CRA Admin page, choose Applications > Configure Applications.
Configure a CTI port group and JTAPI call control group that consists of CTI ports that are defined in Table 8-3 (DN 1601 to 1610). On the CRA Admin page, choose Subsystems > JTAPI > CTI Port Groups.
Configure one media group consisting of ten media ports. On the CRA Admin page, choose Subsystems > Cisco Media.
Configure the CTI route point triggers with DN 3888. On the CRA Admin page, choose Subsystems > JTAPI > JTAPI Triggers.
Table 8-4 lists the settings for the preceding four configuration steps that need to be performed in the CRS server to set up the IP ICD application.
Table 8-4. Configuration Settings on the CRS Server for IP ICD
Step Number | Configured Device | Field | Value |
|---|---|---|---|
1 | Configure Application You can customize the welcome prompt and ICD queue prompts by recording your own and uploading it into the CRS server. | Application Type | Cisco Script Application |
Name | ICD | ||
Description | ICD Application | ||
ID | 1 | ||
Maximum No. of Sessions | 10 | ||
Enabled | Yes | ||
Script | Icd1.aef | ||
Welcome Prompt | ICDWelcome.WAV | ||
Queue Prompt (prompt played while waiting in the queue) | ICDQueue.WAV | ||
Delay While Queued (specifies time between prompts) | 30 | ||
CSQ | SalesQ | ||
Default Script | System Default | ||
2 | CTI Port Groups | Group ID | 1 |
Description | ICD-CTI Port Group | ||
Associated CTI Ports | 1601–1610 | ||
CSS for Redirect | Redirecting Party | ||
3 | Cisco Media | Group ID | 1 |
Description | ICD-Media Port Group | ||
No. of Channels | 10 | ||
4 | JTAPI Trigger | CTI Route Point DN | 3888 |
Language | System Default | ||
Application Name | ICD | ||
Maximum No. of Sessions | 10 | ||
Idle Timeout | 5000 ms | ||
Enabled | Yes | ||
Call Control Group | ICD-CTI Port Group | ||
Primary Dialog Group | ICD-Media Port Group | ||
Secondary Dialog Group | ICD-Media Port Group |
Follow these steps to configure the ICD subsystem:
Configure the RM JTAPI provider. On the CRA Admin page, choose Subsystems > ICD > RM JTAPI Provider.
Add a new skill SK-Sales. On the CRA Admin page, choose Subsystems > ICD > Skills.
Add a new resource group RG-Sales. On the CRA Admin page, choose Subsystems > ICD > Resource Groups.
Assign the skills to resources and the resources to resource groups. The resources here are the users. The skills indicate the users’ specialties and expertise level. With XYZ, only one type of skill level—SK-Sales—is assigned to the users, and all agents are assigned to resource group RG-Sales. On the CRA Admin page, choose Subsystems > ICD > Resources and assign the skills and the resource group to the available resources. All the call center agents appear on the Resources page. If you do not see a user, ensure that in the CallManager that particular user has checked the ICD Extension check box.
Add a new Contact Service Queue (CSQ) CSQ-Sales. On the CRA Admin page, choose Subsystems > ICD > Contact Service Queues.
Table 8-5 shows the configuration settings that need to be performed on the CRS server for the ICD subsystem.
Table 8-5. Configuration Settings on the CRS Server for the ICD Subsystem
Step Number | Configured Device | Field | Value |
|---|---|---|---|
1 | Configure RM JTAPI Provider This is the user ID configured in CallManager in Table 8-3, Step 4. | RM JTAPI Provider (s) | 10.1.2.1, 10.1.3.1 |
User ID | rmjtapiuser | ||
Password | Cisco123 | ||
2 | Skills | Skill Name | SK-Sales |
3 | Resource Group | Resource Group Name | RG-Sales |
4 | Assign Skills to Resources and Group the Resources into Resource Groups | Resource Group | Assign all the resources to RG-Sales. |
Assigned Skills | Assign the users to SK-Skills. | ||
Competence Level | Varies from user to user. | ||
Automatic Available (Enabling this field makes the user immediately ready after finishing the current ICD call.) | Enabled | ||
5 | Contact Service Queue (CSQ) Setting the CSQ service level to 5 does not display the agents whose competency levels are below 5 on the CSQ Configuration page. | CSQ Name | CSQ-Sales |
Contact Queuing Criteria | FIFO | ||
Automatic Work | Enabled | ||
Resource Pool Selection Model | Resource Group | ||
Service Level | 5 | ||
Service Level Percentage | 70 | ||
Resource Selection Criteria | Longest Available | ||
Resource Group | RG-Sales |
Agents can log in to the ICD queue in any of the following ways:
Using the Cisco IP Phone Agent service on the IP Phone
Using the Cisco Agent Desktop on the hard IP Phone
Using the media termination desktop on the IP SoftPhone
Refer to the Cisco Desktop Product Suite Installation Guide for instructions on how to configure various agent login applications:
The supervisor agents will use the Supervisor desktop agent.
In addition to the AA and IP ICD published DID numbers, XYZ has another DID number (408-555-3800) to an IVR system that offers the following three menu choices:
Transfer to an AutoAttendant
Transfer to sales service support
Transfer to an operator
Figure 8-11 shows the XYZ-IVR.aef script deployed to fulfill the main menu function.
The menu application will be deployed using the following parameters for XYZ:
One JTAPI call control group of 20 dedicated CTI ports (DN 1611 to 1630—refer to Table 6-40 in Chapter 6 for the internal numbering plan). The JTAPI call control group is shared with the AA application. This JTAPI call control group has already been created (refer to Table 8-2, Step 3).
One media group of 20 media ports. The media group is shared with the AA application (refer to Table 8-2).
The CTI route point triggers with DN 3800 (refer to Table 6-40 in Chapter 6).
Cisco IP Phone models such as 7960, 7940, and 7970 have the ability to access diverse information such as weather, stock quotes, news updates, or any other information received in eXtensible Markup Language (XML) format. You can access these additional services by pressing the Services button on the Cisco IP Phone. You need a web server to host these services that can accept and process the HTTP requests coming from the Cisco IP Phones and send the response in XML format.
The Cisco IP Phone Services SDK provides sample software libraries and scripts that you can deploy readily in your IPT network. You can download the SDK free of charge from the following URL:
Cisco does not recommend installing this SDK on the CallManager servers. You can use a dedicated web server to host this application along with other IP Phone services such as weather, stock lookup services, and so forth. The next section looks at implementing the corporate directory access from Cisco IP Phones using the LDAP Search COM Server, which is bundled in the SDK.
Chapter 1, “Cisco IP Telephony Solution Overview,” provided information on the CallManager directory architecture and described the two possible scenarios when working with the CallManager directory—directory access and directory integration—and the pros and cons of each approach.
There are limitations on the type of directories supported for integration (currently, Microsoft AD and Netscape iPlanet), but no such limitations apply for providing directory access to the endpoints such as IP Phones and SoftPhones. To provide directory access to the corporate directory from IP Phones, you do not need to integrate CallManager with the corporate directory. By using LDAP queries, users can obtain the information about the other users from the existing LDAPv3-complaint directory through the IP Phones and SoftPhones.
XYZ already has a corporate Active Directory deployment in its enterprise. It requires the directory access/lookup to the existing AD from the IPT endpoints and wants to enable only a few IP Phone services in the network.
Figure 8-12 illustrates directory access. (In this example, the access is provided to a Cisco IP Phone). The IP Phone user performs a user search against an LDAP directory (such as a corporate directory) by pressing the Directories button or Services button on the Cisco IP Phone, and receives numerous matching entries. From the results of the search, the IP Phone user selects a person and presses the Dial softkey on the Cisco IP Phone to make a call.
Figure 8-13 shows how the directory access setup works. The web server is the machine that is running the LDAP Search COM Server application for the directory access and that hosts other IP Phone services. The IP Phones use HTTP to send requests to the web server. The responses from the web server contain some specific XML objects that IP Phones interpret and display on the screen.
In a corporate directory search, the web server operates as a proxy by receiving the request from the IP Phone and translating it into an LDAP request, which in turn is sent to the corporate directory server such as XYZ Inc., Active Directory server as shown in Figure 8-13. The web server receives the response from the corporate directory server and sends the information back to the IP Phone in the form of XML objects.
The sample IP Phone services scripts that are provided in the SDK are Active Server Pages (ASP) scripts. Hence, the web server must be running on Microsoft Internet Information Services (IIS). To build a new web server, select any server hardware platform. Install Windows 2000, IIS, and all the latest service packs and security hot fixes. Follow these steps to install and configure the LDAP Search COM Server:
Run the downloaded installation program, CiscoIPPS_SDK_v3.3.3.exe, on the web server. As previously cited, the SDK download page is http://www.cisco.com/cgi-bin/dev_support/access_level/product_support. You should stop the IIS service on the web server prior to the installation of the SDK to avoid copy violation errors. You have to restart the IIS service after completing the installation of SDK.
The installation program copies DLL files to the C:WINNTSystem32 directory and creates a new directory, C:CiscoIPServices. It also copies a few sample IP Phone services scripts written in ASP to C:CiscoIPServicesASP.
The installation program copies the LDAP Search COM Server into the C:CiscoIPServicesCOMserversLDAPSearch directory. This directory contains the ldapsearch.dll and the ASP script ldapsearch.asp that do the lookups to the external LDAP directory.
Move the C:CiscoIPServicesCOMServersLDAPSearch directory under the C:CiscoIPServicesASP directory.
To install the LDAP Search COM Server:
—Open a command prompt on the web server and change the directory to C:CiscoIPServicesASPLDAPSearch.
—Register the COM server by entering regsvr32 LDAPSearch.dll.
Figure 8-14 shows the procedure for installing the LDAP Search COM Server.
The installation program creates in IIS a virtual directory with the name CiscoIPServices that points to the C:CiscoIPServicesASP directory.
To see the virtual directory on the IP Phone services web server, choose Start > Programs > Administrative Tools > Internet Services Manager. Under Default Web Site, you can see the virtual directory CiscoIPServices, as shown in Figure 8-15.
The virtual directory consists of all other directories in which sample scripts are stored for other IP Phone services. You can either create your own virtual directory or, if you already have an existing virtual directory, move the scripts to that directory. However, this requires modifications to the virtual directory path in all the scripts. Therefore, the easiest way is to use the default virtual directory. You can use this virtual directory as the base directory to reference the other scripts.
The next step is to modify the C:CiscoIPServicesASPLDAPSearchLdapsearch.asp script and configure it to look up the corporate directory.
Figure 8-16 shows the parameters that require modification in the ldapsearch.asp file. As you can see, the password is in clear-text format. Therefore, the best practice is to create a separate user account for the directory search lookup instead of using an administrator account or any other account that has higher privileges. Table 8-6 describes the parameters in detail.
Table 8-6. Parameters in ldapsearch.asp
Attribute | Value | Description |
|---|---|---|
ldapserver | ldap.xyz.com or the IP address of the corporate directory server. | Enter the IP address or host name of the corporate directory server. If you are using a DNS name, ensure that phones can resolve the name to the IP address. |
ldapport | Default port that the corporate directory server will be listening on for LDAP queries. | You can obtain this information from your corporate directory team. For Microsoft AD, the port number is 389. |
ldapuserid | Enter the user ID. This is required to authenticate to the corporate directory. Do not use the Administrator or equivalent ID. Create a new user that requires far fewer privileges. | For AD, the user ID is the display name. If you create a user with first name IPT and last name DirUser, AD puts the display name as “IPT DirUser” with a space in between. Ensure that you include the right display name here. Some directories require a full canonical name, which has the format CN=Administrator, dc=xyz,dc=com |
ldappassword | Password. | Enter the password required along with the user ID to authenticate to the LDAP server and obtain the LDAP queries. |
ldapsearchbase | The user search base for the directory search. | Modify this to match the directory structure that is defined in the corporate directory server. The full canonical name can be written as “cn=Users, dc=xyz, dc=com”; If you have users at multiple containers or multiple organizational units (OUs), set ldapsearchbase to point to the highest level. This ensures that the search includes all OUs. |
After you modify the ldapsearch.asp file, the next step is to define the Directory Lookup service in the CallManager. To define a new IP Phone service, on the CallManager Administration page, choose Feature > Cisco IP Phone Services and click Add New IP Phone Services. This opens the Cisco IP Phone Services Configuration window, shown in Figure 8-17.
You can enter a meaningful service name in the Service Name field. The Cisco IP Phone displays the name you enter here when the user presses the Services button.
For the Service URL field, enter the following value:
http://IP_ADDR/CiscoIPServices/ldapsearch/ldapsearch.asp
You can use the IP address or host name of the web server. If you are using a host name, ensure that IP Phones can communicate with the DNS server to resolve the name-to-IP address mapping.
As mentioned earlier in this section, Directory Lookup is one of the services that is bundled in the IP Phone Services SDK. Other services include Calendar, Measurement conversions, and World Clock. A few services, such as Stock Ticker and World Clock, require access to the Internet for proper functioning.
Table 8-7 describes the URLs required to enable some of these services.
Table 8-7. Defining IP Phone Services
Service Name | Service URL |
|---|---|
Directory lookup | http://IP_ADDR/CiscoIPServices/ldapsearch/ldapsearch.asp |
Measurement conversions | http://IP_ADDR/CiscoIPServices/measurement/measurementmenu.asp |
Calendar | http://IP_ADDR/CiscoIPServices/Calendar/cal.asp |
Clock | http://IP_ADDR/CiscoIPServices/clock/clock.asp |
By default, the Directory button on Cisco IP Phones 7960, 7940, and 7970 points to the CallManager DC directory:
To access the previous setting, on the CallManager Administration page, choose System > Enterprise Parameters.
The parameter that points to the directories is URL Directories. You can change this URL and point it to the Directory Lookup service URL shown in Table 8-7. If you change it at this level, when users press the Directory button, the queries for the directory lookup refer to the corporate directory instead of the CallManager DC directory.
If you want to keep both DC directory lookup and corporate directory lookup, you have to create IP Phone Directory lookup service, as described in Table 8-7. This enables users to view the CallManager DC directory by pressing the Directory button on the IP Phone. To view the corporate directory listing, users press the Services button and choose the Directory Lookup service.
After you define the IP Phone services, subscribe the users to the services by using any one of the following options:
Ask users to go to the CCMuser page (http://CallManager_IP_Address/ccmuser) and subscribe themselves.
Use the BAT to update the subscriptions on all phones.
Manually update the subscriptions on all phones.
If you get errors on the IP Phone when you press the Directory button to access the corporate directory lookup or any other IP Phone services, review the IIS log file stored in the IP Phone services web server under the C:WinntSystem32LogFilesw3svc1 directory.
Following are some common problems and possible resolutions:
The most common problem encountered when troubleshooting the corporate directory access is that someone has entered invalid credentials in the ldapsearch.asp file, as shown in Figure 8-16. If you encounter this problem, you can find the following lines in the log file:
2004-02-05 17:37:07 10.17.168.73 - 172.21.51.217 80 GET /CiscoIPServices/Ldapsearch/ldapsearch.asp action=list|128|800a0031|Invalid_credentials 500 Allegro-Software-WebClient/3.12
This error message clearly indicates that the supplied credentials entered in the ldapsearch.asp file are insufficient for the web server to contact the corporate LDAP server. Possible problems are entry of the wrong username, password, or IP address of the LDAP server. Check the settings and correct any issues.
When you press the Services button on the IP Phone, if you get a Host Not Found error, check the URL Services service parameter on the CallManager Administration page. To access this parameter, on the CallManager Administration page, choose System > Enterprise Parameters. The typical value of this parameter is as follows
http://CallManager_Name/CCMCIP/getservicesmenu.asp
If you are using a name instead of an IP address in this URL, ensure that phones can resolve the name by contacting the DNS server. Otherwise, use the IP address.
After you press the Services button on the IP Phone and the phone displays the list of subscribed services, if you get the Page Not Found error when you select a service, check whether the URL that is configured for the IP Phone services in the CallManager is correct. To test whether this URL is correct, open a web browser and type the same URL that you defined in the IP Phone Services page. If the web browser also reports that the page is not available, check the IIS log file and see whether the URL is right. If you are entering a wrong URL, the log file will have the following entry:
2004-02-05 20:12:54 10.17.168.73 - 172.21.51.217 80 GET /CiscoIPServices/Ldapsearch/ldapsearc.asp |-|0|404_Object_Not_Found 404 Allegro-Software-WebClient/3.12
As you can see, an attempt was made to access URL that does not exist on the server. In this example, the ASP filename entered was wrong. It should have been ldapsearch.asp instead of ldapsearc.asp. Correct this URL error in the CallManager in the IP Phone Services Definition page, and update the subscriptions.
If you still have problems, try restarting the IIS service on the CallManager and on the IP Phone services web server.
Some older ldapsearch.asp and other scripts have a known bug, which should be fixed in the next release of the SDK. The scripts mistakenly reference version 1 of the LDAP Search COM Server, but it cannot be found because the new SDK ships with version 2.
Edit the ldapsearch.asp script and change the following line:
var s = new ActiveXObject(“LDAPSEARCH.LDAPSearchList.1”);
to
var s = new ActiveXObject(“LDAPSEARCH.LDAPSearchList”);
Removing the .1 causes IIS to load the latest version (which is 2) of the LDAP Search COM Server.
The older ldapsearch.asp file also has another problem in which the ldapsearchbase variable is not included. Add the ldapsearchbase variable line in two places:
var ldapserver = "10.1.1.1"; var ldapport = "389"; var ldapuserid = "IPT User"; var ldappassword = "cisco123"; var ldapsearchbase = "CN=Users, dc=xyz, dc=com" s.server = ldapserver; s.port = ldapport; s.AuthName = ldapuserid; s.AuthPasswd = ldappassword; s.searchbase = ldapsearchbase;
Note
Cisco TAC does not provide support for problems with the scripts in the Cisco IP Phone Services SDK. If you still have problems, you can open a case with Developer Support Central:
http://www.cisco.com/en/US/products/svcs/ps3034/ps5408/ps5418/serv_how_to_order.html
All the CallManager servers in a cluster must have the same CallManager OS version, CallManager application version, and SQL server version for successful operation. In a large network deployment, in the initial stages of implementation or during major upgrades, you could miss upgrading one server or applying a hot fix on one or more servers. This section discusses how to check the CallManager OS, CallManager, operating system, and SQL server versions and identify inconsistencies in software versions.
To check the CallManager OS that is running on the CallManager servers, choose Start > Cisco OS Version. The MCS Version Utility displays the CallManager OS version, as shown in Figure 8-18. Notice that the base OS version is 2000.2.4 and that it has been upgraded to 2000.2.6.
To check the CallManager version that you are running in the cluster, on the CallManager Administration page, click the Details button. Figure 8-19 shows the dialog box displaying the CallManager version, 4.0(1), and the active CallManager database name in use, which is CCM0300. You need to provide this information to Cisco personnel when you report problems with CallManager.
The replication process between the CallManager publisher and subscribers within a cluster ensures that the database is consistent across all the servers. If you see errors reported by the SQL service in the application event log, check the CallManager database version in the error message. CallManager makes a copy of the current database before any major upgrades. Therefore, there could be more than one version of the database in SQL, but at any point in time, only one database is active—the one that is specified in the DATABASE field in Figure 8-19.
If the database version reported in the event log is different from the version you see in the database information, you can neglect those types of events because the error indicates a problem with an old or unused version of the database. If the version is the same in both places, you should investigate the issue and see whether reestablishing the SQL replication resolves the issue.
To check the SQL version that is running on the CallManager servers, choose Start > Programs > Microsoft SQL Server > Query Analyzer and enter the query statement select @@version, as shown in Figure 8-20. SQL Query Analyzer displays the SQL version in the result window. In Figure 8-20, the SQL version is 8.00.760.
Whenever you apply a SQL service pack or hot fix, make sure that you apply it to all the servers in the cluster and check the version on all the servers to ensure that all of them are running the same version.
The DBL Helper tool diagnoses problems and restores replication in the CallManager database. To run the DBL Helper tool, run the DBLhelper.exe file located in the C:Program FilesCiscoBin directory on the publisher server.
Note
If you do not have this tool installed on the publisher server, contact Cisco TAC to obtain this tool and copy it into the previously mentioned folder.
Figure 8-21 shows the interface for the DBL Helper tool. The tool has four tabs:
SQLReplication
NameResolution
Compare DB
Export/Import Data
As shown in Figure 8-21, the CallManager cluster consists of two CallManager servers. The SQL Replication tab displays the CallManager database currently used and the SQL server version. You should check these fields whenever you perform CallManager or SQL upgrades to ensure that all the servers in the cluster have the same version of the software.
You can republish or reinitialize SQL subscriptions from the DBL Helper tool. Note that the Republish option is a powerful command, and it takes a considerable amount of time to republish the database. The Republish operation deletes the exiting subscriptions and re-creates them.
The Reinitialize option reinitializes all subscriptions, starts the snapshot agent, and attempts to rebuild the subscription with the current database. If the status column (not shown in Figure 8-21) on any particular CallManager subscriber reports errors, you can select that CallManager and click the Reinitialize button to establish the SQL subscription.
The NameResolution tab checks the name resolution and displays the name of the server in the database, the IP resolved name, the IP address, and the ping time.
The Compare DB tab allows you to compare two databases on the CallManager server. As mentioned before, whenever you perform a major version upgrade to a CallManager server, the old database is stored in the SQL server.
The Export/Import Data tab allows you to export all the data from the CallManager SQL database (or data from selected tables) into a CSV file. The import option does the reverse function. This feature is useful to make any bulk modifications to the database. However, do not make any modifications to the database using this tool unless you are directed to do so by Cisco support personnel. You should use BAT tool to make any bulk changes to the CallManager database.
To check for inconsistent versions of different components within a CallManager cluster, on the CallManager Administration page, choose Help > Component Versions and click the Out of Sync link. If you see inconsistencies, you should examine the files that are not consistent and resolve the issue.
The CallManager Multi-Level Administration (MLA) tool provides different levels of permission and access privileges to CallManager Administration and Serviceability pages. Prior to the release of the MLA tool, access to the CallManager Administration and Serviceability interfaces was global in nature and used basic Windows NT authentication. With this authentication method, all pages were available to anyone who logged in. There was no way of providing the granular access to these pages to classify administrators based on their responsibilities.
In large-scale IPT deployments, companies typically subcontract the deployment of IP Phones to other vendors. Using the MLA tool, the CallManager administrator can create different users and assign privileges to those users that limit them to just configuring and managing the IP Phones. The CallManager administrator can also use the MLA tool to track the changes made by the implementation team.
The MLA tool offers the following benefits:
Keeps a log of changes made by different administrators
Maintains audit logs and login attempt logs:
—The audit logs keep track of the configuration changes to the CallManager Administration page and Serviceability page.
—The login attempt logs keep track of authentication attempts.
For CallManager versions prior to 4.0, MLA was available in a separate software package. Starting with CallManager 4.0, MLA is included in the CallManager software, and no separate installation is required.
To enable the MLA feature in CallManager 4.0, on the CallManager Administration page on the publisher server, choose User > Access Rights > Configure MLA Parameters and set the Enable MultiLevelAdmin parameter to True. When you set the parameter to True, the web page prompts you to set the CCMAdministrator password. After you enable the MLA feature, use the user ID CCMAdministrator and the password you have entered to access the CallManager Administration pages.
You have to restart the web service on all the servers in the cluster after enabling the MLA feature. Use the CCMPwdChanger.exe tool discussed in Chapter 9 to reset the password for the CCMAdministrator user.
The functional groups in MLA comprise different CallManager administration functions. The standard functional groups predefined are as follows:
Standard Plug-In
Standard User Privilege Management
Standard User Management
Standard Feature
Standard Service Management
Standard Service
Standard Serviceability
Standard Gateway
Standard Route Plan
Standard Phone
These standard functional groups contain predefined menu pages that users can access. For example, users who have full access to the Standard Plug-In group have permissions to access the CallManager Install Plugins pages; users who have full access to the Standard Phone functional group have access to all the pages in CallManager Administration that allow them to modify, create, and add phones.
You can create new functional groups based on the predefined functional groups. However, you cannot modify the predefined functional groups.
User groups define the access privileges to various functional groups and users who have access to the functional groups. The following user groups are predefined:
Gateway Administration
Phone Administration
Read Only
Server Maintenance
Server Monitoring
Super User Group
You can assign a user to multiple user groups; the users in the Super User Group have full access. You cannot delete the Super User Group.
By using the MLA authentication method, any user who attempts to access a CallManager menu or web page will be allowed one of three access levels:
Full Access—. Can perform all functions
Read Only Access—. Cannot make any changes
No Access—. Cannot even view the page
You can assign these access privileges to the functional groups.
The View Privileges Report prints all the user groups that are defined with their associated functional groups and privileges. This report will assist in troubleshooting problems with access privileges to different functional groups.
By default, the debug level in MLA is set to None. To enable full logging so that you can see the changes that the other administrators are making to the system, change the debug level to Debug. To access the debug level parameter, on the CallManager Administration page, choose User > Access Rights > Configure MLA Parameters.
MLA stores the log files in the C:Program FilesCiscoTraceMLA directory. The PermissionsXXXXXX.txt file contains debug information. The AccessXX.log file contains login attempts of users and changes made by these users while they are logged in to CallManager web pages.
Before deploying the IPT solution for the entire organization, you should consider deploying an IPT solution pilot. The IPT solution pilot might be the initial deployment of the solution at a site or set of sites that is representative of the final deployed architecture. The goal of conducting a solution pilot is to gather the real world/real user performance feedback that will allow engineering or process changes to be made prior to a full rollout of the IPT solution throughout the organization.
During the deployment of the IPT solution pilot, you will gain experience with the deployment and operations of the solution. This is an opportune time to develop and tune methods and procedures for installation, configuration and operations of the components and systems, and support and training requirements.
It is important to verify the functionality of the IPT network after completing the actual deployment or after deploying the IPT solution pilot. Implementation engineers should conduct different acceptance tests (listed in Appendix H) to verify that the IPT system is functioning as per the requirements.
After you complete IPT implementation, the project management team should document all equipment for asset-tracking purposes. The deployment team should complete documentation that includes the following items. Proper documentation helps in maintaining and operating the network.
Updated IPT network topology diagram
Serial numbers of all IPT devices
CallManager/application server configurations, software versions, and passwords
Call-processing backup or failover strategy
Ethernet switch and router configurations
IP address plan and VLAN assignments
Carrier and circuit ID of all WAN links
Gatekeeper or bandwidth control mechanism
Asset tagging
Cable labeling
Customer acceptance certification and sign-off
Supporting the converged network requires an organization to build a strong support team that has all the required expertise and to develop an escalation procedure. The support team should know the various tools available and how and when to use them.
Unlike the other support teams, the team that supports the converged network has to interact with other groups in the organization, which typically include the following:
LAN/WAN group
Enterprise messaging group
Enterprise directory group
Enterprise security group
Therefore, a strong working relationship among the groups is required. To manage the network, the support team must also understand the following:
Networking, including routing and switching technologies, various routing protocols, and QoS
Cisco CallManager and other deployed Cisco AVVID applications
How to configure and troubleshoot voice gateways
Microsoft OS operation and configuration
In an IPT network, the end customers are users of the IP Phones. By educating users on how to use the new IP Phones and phone features, you can eliminate most basic questions and cases that might otherwise be opened by the users.
Defining clear escalation procedures for handling problems related to the IPT network reduces the problem-resolution times and increases employee productivity.
One suggested approach is to use a four-tier model:
Tier 0: end user—. Refers to the user-facing FAQs and tutorials posted on the internal website.
Tier 1: voice help desk—. Handles the basic user issues even after the user has gone through tier 0.
Tier 2: voice network administration staff—. Handles escalations from tier 1. This group of users has higher-level access privileges to the systems than tier 1 staff and can add new phones and handle moves, adds, and changes (MACs), adding new services based on tier 3 group decisions. This group also gathers information related to a user-reported issue or a network outage issue to pass along to tier 3.
Tier 3: voice network design/architecture staff—. Responsible for network expansions, design changes, and capacity planning. Works with vendors such as Cisco to further investigate and troubleshoot issues.
The goal of many businesses today is to improve employee productivity and reduce costs by deploying new-world technologies such as IP Telephony, wireless, and storage area networking. To successfully deploy the new technologies and gain acceptability within the organization, it is necessary to educate the end users and the support and administration staff.
Following are some tips that can reduce the most basic support calls from the users:
Build an internal website and post all the presentations, FAQs, and videos that teach how to use various features on the IP Phones. You can download the Cisco IP Phone tutorials on Cisco.com from the following URL:
http://www.cisco.com/warp/public/779/largeent/avvid/products/clients.html
Provide training to help desk staff on how to handle basic issues.
Educate users and help desk staff on the escalation procedures.
When switching from analog phones to Cisco IP Phones, end users require minimal training. End users do not have to do anything differently to use the basic phone features, such as making on-net and off-net calls, listening, deleting and leaving voice-mail messages, placing the call on hold, making conference calls, transferring a call, forwarding a call, and so forth. You can retain the same level of functionality in the Cisco IPT solution by designing the dial plan to meet these requirements. For example, if an end user is accustomed to dialing 9 to make off-net calls, configure CallManager to do the same. Also, you can plan to use the available features and buttons on the IP Phones that are similar to the features of the legacy phones, such as hold, transfer, and other functionality.
When end users see a Cisco IP Phone on their desks, they find it similar to legacy phones as far as the basic operation is concerned, with the exception of an LCD screen. This LCD screen is used to show several menus, options, outputs, and enhanced features, and to customize the IP Phone settings.
Cisco IP Phones ship with concise end-user guides, which are also available on Cisco.com. Armed with these guides and the online tutorials mentioned in the previous section, users will quickly feel comfortable using the new phone system.
The IPT support staff requires formal training regarding how to support the deployed IPT solution. Several IPT training courses are available through Cisco Systems training partners all over the world. There are also several IPT certifications available to test the efficiency of the IPT support staff.
The following training and exams are recommended for becoming a Cisco IPT support specialist. Completing this training and the exams enables the support staff to provide tier 1 support to end users when they report a problem.
Cisco Voice over IP (CVOICE) course and CVOICE 642-432 exam
Cisco IP Telephony (CIPT) course and CIPT 642-443 exam
Deploying QoS for Enterprise Networks (DQOS) course and QoS 642-642 exam
IP Telephony Troubleshooting (IPTT) course and IPTT 642-425 exam
In the four-tier support model described earlier, the help desk staff will not have access to the IPT systems to make configuration or design changes to the IPT architecture. The administration staff includes the users who control and manage the IPT network components. The administration staff is responsible for making design and configuration changes in IPT components. The training that is required for administration staff is similar to the IPT support staff training. Usually, administration staff has senior engineers who have prior experience designing, deploying, configuring, troubleshooting, and managing IPT networks.
The network design/architecture staff consists of engineers who are involved from the planning stages of the IPT network. This group typically handles the following:
Proactive monitoring of the network and execution of optimization steps
Critical service failures
Scalability- and performance-related issues
Ongoing network expansion/design projects
Adding products that contribute features to the existing IPT network
This group also interfaces with product vendors such as Cisco during critical problem escalation. Prior to contacting Cisco to report issues, this group should organize and collect the following information:
Clear and concise problem description
What hardware platform(s) are involved
What software version(s) are involved
What network topology is involved (in case of reactive requests)
If more than one Cisco product is involved, an accurate topology diagram, including device names, locations, and IP addresses
Dial-in details (for reactive requests)
Hardware and software configuration(s)
This chapter provided various steps and best practices involved in implementing the IPT solution. For detailed configuration steps and troubleshooting methods, refer to the product-specific documents and configuration guides available on Cisco.com.
Chapter 9 explains the various operational tasks involved in IPT networks and introduces you to some of the commonly used tools and optimization techniques.