Table Of Contents
Implementing and Configuring the Solution
Collaborative Care Configuration Task List
Cisco IOS Gatekeeper Configuration
Cisco 7985 Devices Configuration
Installing Partner Device Types on CallManager
Polycom VSX-3000/VSX-5000 Device Configuration
Polycom H.323 PVX Configuration
Tandberg T1000 MXP Device Configuration
Cisco Unified Contact Center Express Configuration
Post-Installation Setup Procedures
Accessing the UCCX Administration Functions
Configuring UCCX for CallManager
Creating Contact Service Queues (CSQs)
Linking Applications to Scripts
Cisco 7985 Phone Configuration
Determining the System Information
XML Applications for 7985 for IPPA
Polycom PVX Phone Configuration
Polycom VSX-3000 and VSX-5000 Phone Configuration
Configuring the VSX System to Use SCCP Protocol
Determining the System Information
Tandberg T1000 MXP Phone Configuration
Configuring Cisco Agent Desktop (CAD)
Installing CAD on the Windows Workstation
Installing IP Phone Agent (IPPA)
Subscribing XML Phones to the IPPA XML Service
Starting the IPPA XML Service on Phone
IPPA Caveats for the Cisco 7985
Cisco IOS Gatekeeper Configuration
Phone Configuration on CallManager for QoS
CTI Port Configuration on CallManager for QoS
QoS Marking Using Cisco Security Agent
Additionally for Deployment Models 2 and 3
ASA Configuration ACL FW and NAT/PAT Configuration
Sample Configuration from a Cisco ASA
Implementing and Configuring the Solution
This chapter provides configuration and implementation details for Collaborative Care—Language Interpretation Service. For each product component in the solution, we describe the implementation details required to enable voice and video to interwork with CM and UCCX—and thereby support a language skills-based resource. However, the assumption is that in general basic product installations and configuration items not impacting Collaborative Care are not covered and the general product guides and/or SRNDs should be consulted for complete implementation guidelines.
Implementation
The implementation of Collaborative Care involves the integration of several product components. The specific configuration guidelines provided are intended to ensure successful integration. See Chapter 3, "Solution Features and Components" for information about the product components and software dependencies before proceeding with implementation.
Network Topology
Figure 5-1 provides an overview of the network topology that is described in the implementation details. Refer to Figure 5-1 for a frame of reference as you implement each product.
Figure 5-1 Network Topology
Configuration Task Lists
Configuration of Collaborative Care Language Interpretation Service is a multiple-step process that involves network infrastructure and Unified Communications configuration. The implementation details may vary or require additional steps based on the deployment model implemented. This section provides a checklist of the functionality that must be implemented. The following section provide a step-by-step guide to configuration details. The implementation details focus on the attributes required to activate the services. For basic component installation and configuration guides, refer back to the product specifications. Site-to-site connectivity and business-to-business (B2B) connectivity for MPLS VPN are not covered.
Collaborative Care Configuration Task List
•
Key items to configure on Cisco CallManager:
–
–
–
–
–
•
–
–
–
–
–
–
–
–
–
•
–
–
–
–
•
–
–
•
•
•
•
–
–
–
–
CallManager Configuration
Regions
Regions are configured to provide a boundary for the codec bandwidth and video bandwidth that can be used per call instance. If an endpoint attempts to make a call beyond the limits defined in the region, the call is adjusted back to the values defined in the region.
To configure regions:
Step 1
Step 2
Step 3
Step 4
Step 5
Note
Device Pool
Device pools are defined and associated to each device type to define a series of system-level definitions. The video region defined in the previous section is used as the region defined in the new device pool created for the video devices.
To configure device pools:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Note
Locations
Locations are used for Call Admission Control such that the link speed supporting connections between sites has enough bandwidth to support a video call. Using locations is a static non-topology aware method that is best used for fairly simple network topologies. For this example, deployment model 1 is used as the example where the main campus location is the hospital and a branch office location is the clinic.
To configure locations:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
To create the location for the branch office, repeat steps 1-2 then proceed with the following:
Step 1
Step 2
Step 3
Step 4
Note
Codec
The phone configuration for the codec used in CallManager is a global setting that allows for the use of the G.722 codec.
To configure the codec:
Step 1
Step 2
Cisco IOS Gatekeeper Configuration
As CallManager works as a H.323 VOIP-GW in a H.323 network, a Cisco IOS Gatekeeper must be defined inside CallManager. CallManager then registers as a VOIP-GW to this Gatekeeper.
To configure Cisco IOS Gatekeeper:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Cisco 7985 Devices Configuration
Ensure that the Cisco 7985 image loaded in CallManager is consistent with the image listed in the Software Release Table 3-4. If not, retrieve this image from CCO and upload to the CallManager. Once the image is loaded onto CallManager, the phone automatically downloads the image after the configuration steps for the Cisco 7985 Phone are completed.
The following steps outline how to define a Cisco 7985 for a clinician or an interpretation agent on the Cisco CallManager. Additional steps are also required on the phone itself that are described in a later section.
To configure Cisco 7985 on CallManager:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
•
•
Installing Partner Device Types on CallManager
To configure partner endpoints on CallManager, a Signed device file is required. This device file comes from either Tandberg or Polycom as a Signed File. When getting this file from the vendor, make sure to get the device file that is compliant with CallManager 5.1. Before configuring any partner device, perform the following steps.
To load device files on CallManager:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
After these steps are performed, a confirmation of a successful install soon appears. The device option should then appear in the phone configuration under Phone Type if the installation was successful.
Note
Polycom VSX-3000/VSX-5000 Device Configuration
Ensure that the Polycom VSX3000 and VSX5000 image loaded on the phone is consistent with the image listed in the Software Release Table 3-5. If not, retrieve this image from Polycom and follow the instructions in Polycom VSX-3000 and VSX-5000 Phone Configuration.
The following outlines the steps to define a Polycom VSX-3000 or VSX-5000 device as a clinician endpoint on the Cisco CallManager.
Note
To configure Polycom VSX-3000 or VSX-5000 on CallManager:
Step 1
Step 2
Step 3
Note
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
•
•
Polycom H.323 PVX Configuration
The following outlines the steps to define a Polycom H.323 PVX endpoint as a clinician endpoint on the Cisco CallManager. This additional configuration step is required for H.323 endpoints in addition to the Gatekeeper configurations and endpoint configurations. Additional steps are also required on the phone application that is described in a later section.
Note
To configure Polycom PVX on CallManager:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
Note
Step 14
Note
Step 15
Step 16
Step 17
•
•
Tandberg T1000 MXP Device Configuration
Ensure that the Tandberg T1000 MXP image loaded on the phone is consistent with the image listed in the Software Release Table 3-6. If not, retrieve this image from Polycom and follow the instructions in Tandberg T1000 MXP Phone Configuration.
The following outlines the steps to define a Tandberg T1000 MXP device as a clinician endpoint on the Cisco CallManager.
Note
To configure Tandberg T1000 MXP on CallManager:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
•
•
Cisco Unified Contact Center Express Configuration
The Cisco Unified Contact Center Express (UCCX) was formerly known as the IP Contact Center (IPCC) Express product and has since been renamed. The installation process for UCCX is documented in the Cisco Customer Response Solutions Installation Guide found on Cisco Connection Online. It is recommended to consult this installation guide as it is beyond the scope of this document to describe the installation instructions in detail.
Starting in UCCX version 4.5, the first version of UCCX to support Cisco Unified CallManager 5.x, the term CRS (Customer Response Center) is used to refer to a single server running UCCX. In the IP Contact Center releases previous to UCCX 4.5, a cluster represented two CRS servers. The concept of a cluster however remains and during the installation process you must define the name of the cluster to which this installation of UCCX belongs.
Before beginning the installation process, review the checklist found in the Cisco Customer Response Solutions Installation Guide.
Pre-Installation Checklist
•
•
•
•
•
•
•
•
•
•
•
During the installation process there are a few recommended settings that you may want to consider for your installation. These are described in the following sections.
UCCX Components
During the installation phase, it is recommended to install each of the items shown in Figure 5-2. These include the CRS Engine, CRS Agent Data store, CRS Config Data store, CRS Historical Data store, and Microsoft SQL Server. It is optional to select the Monitoring and Recording options.
Figure 5-2 UCCX Components Installation Recommendations
Prompt IVR Codec
It is recommended to select the G.711 Codec which is used to play prompts to callers. This codec is required if you decide to install Voice Recognition or Recording/Monitoring services post installation or in the future.
Figure 5-3 Prompt IVR Codec
Post-Installation Setup Procedures
There are two initial setup procedures that you must perform before you can access the complete set of Cisco CRS Administration features:
•
•
If you later need to update information that you specify during a setup procedure, you can use Cisco CRS Administration to make changes. For more information, refer to Cisco Customer Response Solutions Administration Guide.
Accessing the UCCX Administration Functions
There are two methods that you can use to gain access to the administration functions:
•
On the Cisco UCCX server, choose Start > Programs > Cisco CRS Administrator> Application Administrator.
•
Use the following URL: http://<servername>/AppAdmin. The PC must meet the following requirements to support the user interface:
–
–
–
Installing License File
Once UCCX has been installed, you must next install the license file which is part of the cluster setup post installation steps.
To install the license file:
Step 1
You see the License Information page.
Step 2
Step 3
Step 4
•
•
The CallManager Configuration screen appears. This page displays the IP address of the primary AXL server provider that is configured for Cisco CRS and lets you specify backup AXL server providers. It also lets you specify the IP addresses of JTAPI providers and RmCm providers that are configured for Cisco CallManager. See the next section for information on completing these steps.
Configuring UCCX for CallManager
Once you have installed the License file, you see the CallManager Configuration screen:
The AXL Service must be configured and running on the Unified CallManager server, but first, this needs to be configured on UCCX.
In the AXL Service Provider Configuration area:
Step 1
Step 2
Step 3
The JTAPI (Java Telephony API) protocol is used by UCCX to communicate with CallManager. It is through this communication protocol that CallManager notifies UCCX of an inbound call and how UCCX likewise informs CallManager of the agent to which the call should be routed.
In the JTAPI Provider Configuration area:
Step 1
Step 2
Step 3
Step 4
The Resource Manager-Contact Manager, otherwise known as RmCm Subsystem, is broken down into two components. The RM or Resource Manager manages resources such as agents as to their state, Not-Ready, Ready, Working, Logged out, etc. The Contact Manager subsystem provides management of queues and participates in routing calls to agent resources.
In the RmCm Provider Configuration area:
Step 1
Step 2
Step 3
Step 4
Configuration of UCCX
For deployment model 3, the UCCX infrastructure is managed by the Language Interpretation Service and therefore this section is not applicable for the health care provider.
Creating Skills
Agents are assigned one or more skills for which they are responsible. The skills assigned to the agents can each have a specific level of competence specified.
To create skills:
Step 1
Step 2
Step 3
Step 4
Creating Contact Service Queues (CSQs)
Unified Contact Center Express uses a grouping mechanism for callers requiring similar services. In our case, these CSQs would map to language. These CSQs are what is referenced within the script which is executing on the UCCX platform and interacting with the caller.
To create CSQs:
Step 1
Step 2
Adding Agent Resources
Agent resources are first defined as users in Unified CallManager. On the "End User" configuration page, there is an option that is used to specify the UCCX Extension. This drop down displays the extension assigned to the user, and if this option is not specified, the userid is not exported to Unified Contact Center Express. This drop down is shown below.
Note
Once the agent has been identified in Unified CallManager as an UCCX agent resource, the agent should now be present in the UCCX system which is found under Subsystem/RmCm/Resources.
The name of the resource shown in Unified Contact Center Express (UCCX) is the last name of the end user as defined in Unified CallManager and not the userid of the end user.
Assigning Agents to Skills
To assign skills to the agent resources, select the Resource Name as shown on the RmCm/Resources menu (shown above). The following screen is displayed.
Select one or more skills and press the left arrow to move that skill into the Assigned Skills column. Each skill selected can have a unique competence level, depending on the skill level of the translator, or for other business reasons. One example is to reduce the calls that may interrupt a translator that has other primary responsibilities, but within the health care organization is used as overflow in the event that the full time interpreters are not available.
Uploading Scripts to UCCX
Scripts are developed using the CRS Editor tool which is included with Unified Contact Center Express. Once the script has been created, it must be uploaded to the UCCX system. These scripts are stored in the Repository Data Store (RDS) database, along with other information such as prompts, grammars, and various document files on the UCCX System.
From the UCCX Administration menu, choose Applications/Script Management.
The Script Management page opens as shown below.
Clicking on the Script Files directory, followed by Upload New Scripts, opens an upload dialogue box that allows you to upload the script file(s) from your local machine.
Once the upload has been performed, you are presented with a dialogue box confirming the upload. If you are replacing a script that is already in use, the dialogue box lets you refresh the script. If you do not refresh the script, the old copy is used by all applications and subsystems within the UCCX system.
There are two script refresh options:
•
•
Note
Linking Applications to Scripts
Once the scripts are uploaded, applications must be created that define a JTAPI trigger (or pilot number) and map it to a script. To create an application, select Applications/Application Management/Add a New Application as shown below.
When adding a new application that uses a script, select Cisco Script Application and press Next.
Specify the maximum number of sessions that this application is allowed to support. This selection directly correlates to the number of CTI ports that have been defined for the UCCX system to use. In this example, up to 10 callers can be interacting with the script at any one time. Next, select the Script name from the script drop down menu. Any variables that have been defined in the script as a parameter are listed below. Typical variables that are defined with the parameters are prompts, retry counts, and delay seconds. This allows you to override the variable without having to edit the script. In most cases, you won't need to change this. Next select the Add button shown above
Once the application has been added, you are presented with the opportunity to define JTAPI triggers. Select Add new trigger from the menu as shown below.
The added trigger can be one of two types:
•
•
In this example, we choose a standard JTAPI trigger that is used when the clinician dials the number specified for the trigger.
On the next screen, you are required to enter values for a number of fields. Specifying the directory number that the end user dials creates the JTAPI trigger. The CTI Route Point is automatically configured in Unified CallManager. Think of these as route patterns that CallManager uses to determine that calls to this number are calls to the application being defined in UCCX. The Route Points in CallManager are by default named RP_ + the directory number specified. In this case it would be RP_4560. Once this has been configured, select Add to complete the JTAPI trigger configuration task.
You may confirm that the route point has been automatically added to the Unified CallManager by selecting Device/CTI Route Point. It is strongly recommended not to manually change the CTI route point configuration from within CallManager as it may be overridden or refreshed from UCCX.
Multiple Route Points
It is possible to configure a number of different route points that all map to the same application. This may be useful in this solution deployment in that 4560 could be the main pilot number that provides the user with an audible list of languages to choose from. It may however be advantageous to offer the caller a number of different entry points in the form of separate phone numbers (JTAPI Triggers) for each language (in our example, 4561 for Spanish,4562 for Sign Language, etc.).
When the script executes, a simple check of the dialed phone number or JTAPI trigger used to invoke the application can be performed. This prevents the caller from having to navigate the IVR-based menu system and streamlines access to the language of choice. Furthermore, speed dials can be configured on the endpoint devices that map the text Spanish to extension 4561 and so on.
Cisco 7985 Phone Configuration
Audio Settings
The audio settings of the Cisco 7985 are configured on CallManager in the Region settings. It is recommended to create a Video Region and associate all Video endpoints, Route Points, and SIP trunks to this region. When the endpoint is defined to Callmanager either through auto registration or manually, it is assigned to either the default region or manually assigned to a administrator-defined region. In this way it is possible to have a subset of devices utilize the G.722 codec, which provides for greater audio clarity.
The Cisco 7985 has an integrated microphone and speakers. The Cisco 7985 supports the G.722 audio codec and adopts this setting as part of the configuration process when registering with Unified CallManager.
Video Settings
The Cisco 7985 support SIF video at 352x240 or CIF at 352x288 when using the SCCP Protocol. The selection of the video protocol used between two endpoints is determined during the H.264 video negotiation and defaults to the lowest resolution available on either endpoint.
•
•
•
•
•
•
Network Settings
To configure LAN or network-related settings, use the menu option by selecting the Settings button to enter configuration menu options. Then select 2 for Network Configurations. You see the following menu:
Note
Use the following procedure:
Step 1
Step 2
Step 3
Step 4
Step 5
If using DHCP:
a.
b.
–
–
–
–
–
–
–
–
–
If not using DHCP:
a.
b.
–
–
–
–
–
–
–
–
–
Verifying Proper Operation
To verify that the Cisco 7985 has successfully registered with CallManager, a phone number appears at the top right corner on the main screen. To get more detail on the status, select the Settings key and choose option 5 Status. To verify the Network settings, select 3 - Network Statistics.
Determining the System Information
To determine the firmware, revision, mac address, and other system details, select Settings and choose option 4. You should see the following:
Note
XML Applications for 7985 for IPPA
Polycom PVX Phone Configuration
This section provides configuration details on configuring the Polycom PVX to work in the Collaborative Care solution.
•
•
•
For installation, general information, PC platform requirements, camera/microphone recommendations, and detailed product guidelines on Polycom PVX, refer to the product page for Polycom PVX:
http://www.polycom.com/products_services/1,,pw-7953,00.html
After completing installation and registration of the Polycom PVX, follow this procedure:
Note
Step 1
•
•
Step 2
Step 3
Step 4
In this setting, ensure the Enhanced video (H.264) status option is checked to use H.264 video.
Step 5
In this menu select the following to achieve the best video performance:
•
•
•
Step 6
This menu selection depends on the audio output and input device. If the device has a hardware-based echo cancellation, then choose External for Echo Cancellation. If the hardware device does not have that capability, then choose Internal.
Always select Automatic Gain Control to help provide consistent volume control.
Step 7
Selection Directly connected to a LAN or behind a fully aware H.323 firewall since the Cisco ASA FW is fully H.323 aware and the CallManager also performs protocol translation to SIP or SCCP depending on the call destination.
Step 8
Ensure that H.323 TCP Port is set for 1720.
Unless there are conflicts with the Media Ports, there is no requirement to change the Media Ports.
Step 9
Select Increase priority of video conferencing data on your network.
Step 10
Under this menu select 768 kbps for both he Default Call Rate and the Maximum Call Rate. All endpoints used are capable of 768 kbps.
Step 11
•
•
Note
Tip
Tip
Polycom VSX-3000 and VSX-5000 Phone Configuration
Audio Settings
The audio settings of the VSX-3000 and VSX-5000 are configured on CallManager in the Region settings. It is recommended to create a Video Region and associate all Video endpoints, Route Points, and SIP trunks to this region. When the endpoint is defined to CallManager either through auto registration or manually, it is assigned to either the default region or manually assigned to an administrator-defined region. In this way, it is possible to have a subset of devices utilize the G.722 codec, which provides for greater audio clarity.
Polycom VSX-3000
The VSX-3000 has an integrated stereo microphone and speakers. There is not an option to add an external microphone to the endpoint. There are however other audio sources that can be used for input from a PC or VCR/DVD for example. The VSX-3000 supports the G.722 wideband audio codec and adopts this setting as part of the configuration process when registering with Unified CallManager.
Polycom VSX-5000
The VSX-5000 requires the use of an external microphone and speaker. Typically the VSX-5000 is placed on the top of a video monitor that has either S-Video or VGA/XGA video output. Stereo outputs are supplied and can be connected to an external speaker system either on the video monitor or external to speakers located in the room.
Video Settings
Both the VSX-3000 and VSX-5000 support SIF video at 352x240 or CIF at 352x288 when using the SCCP protocol. The selection of the video protocol used between two endpoints is determined during the H.264 video negotiation and defaults to the lowest resolution available on either endpoint.
•
•
•
•
•
•
Network Settings
The network settings and general configuration menus are the same for both the VSX-3000 and VSX-5000 devices. To configure LAN or network-related settings, use the remote control to select System/Admin Settings/LAN Properties. Any of the following items can be changed in this menu and are shown below.
•
•
•
•
•
•
•
•
•
Configuring the VSX System to Use SCCP Protocol
Using the remote control, select System/Admin Settings/Network/SCCP Settings and configure the following:
•
•
When the VSX system has registered with CallManager, the directory number that was assigned to the device is displayed directly below the self video image. Additionally the CallManager Address is displayed when you navigate to System/Admin Settings/Network/SCCP.
Verifying Proper Operation
To verify that the VSX system (3000 or 5000) has successfully registered with CallManager, select Diagnostics/System Status found under the System menu option. If registered, you see a green up-arrow indicating that the VSX system has registered to CallManager.
Determining the System Information
To determine the firmware, revision, Mac address, and other system details, select System/System Information. You see the following fields:
•
•
•
•
•
•
•
•
•
•
•
Firmware Upgrades
You can download a new version of firmware directly from Polycom's website. The upgrade process is straightforward through the use of the Softupdate application.
To update your software via the Internet:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Note
Tandberg T1000 MXP Phone Configuration
Audio Settings
The audio settings of the T1000 MXP when using SCCP is configured in the CallManager Region settings. It is recommended to create a Video Region and associate all Video endpoints, Route Points, and SIP trunks to this region. When the endpoint is defined to CallManager either through auto registration or manually, it is assigned to either the default region or manually assigned to an administrator-defined region. In this way, it is possible to have a subset of devices utilize the G.722 codec, which provides for greater audio clarity.
Video Settings
The T1000 MXP supports H.264 video at up to 30fps at the following video resolutions:
•
•
The selection of the video protocol used between two endpoints is determined during the H.264 video negotiation and defaults to the lowest resolution available on either endpoint.
Network Settings
The network settings and general configuration menus for the Tandberg T1000 MXP are navigated using the remote control included with each T1000. To configure the LAN or network-related settings, select Settings/Network Settings. Any of the following items can be changed in this menu and are shown below.
•
•
–
–
–
–
•
–
–
Verifying Proper Operation
To verify that the T1000 MXP has successfully registered with CallManager, select System Status found under the Settings/View Status menu option. If registered to CallManager, you see the word Active next to the CallManager 1 field shown in the lower portion of the second screen below.
You see the following information:
•
•
•
•
•
•
•
•
•
•
•
Firmware Upgrades
Unlike other Cisco endpoints, the T1000 does not download its firmware from the CallManager. Before starting the upgrade, make sure that you have obtained a Release Key from Tandberg. The release key is unique to each T1000 MXP and can only be obtained directly from Tandberg technical support or a Tandberg reseller.
The system can be upgraded through FTP or a Web browser (IE 6.0+) interface.
Web Interface Upgrade Method
To upgrade using the web interface, point the browser to the IP address of the T1000 MXP system. To obtain the IP address of the system, use the System Status menu as shown above. Once you have entered this address, you should be prompted with the system web menu. Select the System Configuration Tab and then select upgrade.
Enter the Release key provided by Tandberg or your Tandberg reseller. Once entered, press the Install Software button. The next menu should be displayed, provided that the serial number dependent release key that you entered is valid for the T1000 MXP. At this point, simply enter the image filename and path or use the browse button to navigate to the location of the file.
Pressing the Install button begins the install process.
FTP Upgrade Method
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Agent Software with UCCX
Configuring Cisco Agent Desktop (CAD)
Configuring an agent in Unified CallManager is as simple as adding an end user and then assigning an endpoint device to the account. The directory numbers assigned to the lines on the phone are automatically displayed in the primary extension field. It is critical to also assign an UCCX Extension to the end user account to trigger the export of that user to UCCX. Note that after the renaming of IPCC to UCCX, Unified CallManager still refers to UCCX as IPCC.
The Cisco Agent Desktop (CAD) is a Windows-based client that allows the agent to interact with the UCCX system. The agent is able to login to UCCX through CAD and change their state as necessary in order to signal to UCCX whether it should direct calls to this particular agent.
Note
Endpoints that use CAD must be associated not only to the primary agent/end user, but also to a special application user account that was created in Unified CallManager during the initial install of UCCX. This user account is listed under User Management/Application User in CallManager and has the form xx-RmCm, where xx was a two character prefix specified at the time of the UCCX installation.
This xx-RmCm application user account needs to be associated with each endpoint that uses CAD. This enabled UCCX to query the status of the endpoint using the JTAPI protocol. Without this association, CAD does not fully initialize and end its agent logon process when it attempts to query CallManager for the device status (register, on-hook, off-hook, etc.).
To associate the endpoint devices, simply move the MAC address of the endpoints from the Available Device section into the associated section as shown below. All devices that use CAD or IPPA must be in the lower section as shown, and not in the upper section.
Installing CAD on the Windows Workstation
To install Cisco Agent Desktop:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Installing IP Phone Agent (IPPA)
IP Phone agent is an XML application that can be used by the agents to identify themselves to the UCCX system. It is resident on Unified Contact Center Express system and is invoked by subscribing an XML-enabled endpoint to the IPPA Application.
Step 1
Step 2
•
•
•
•
Step 3
Subscribing XML Phones to the IPPA XML Service
To subscribe a phone to the newly created IPPA XML Service:
Step 1
Step 2
Step 3
Step 4
Starting the IPPA XML Service on Phone
Step 1
Step 2
Step 3
Step 4
Step 5
IPPA Caveats for the Cisco 7985
The 7985 requires that the DNS which has been configured on the phone either manually or via DHCP must be capable of resolving the fully qualified hostname of the Unified CallManager. In other words, if the domain name passed to the 7985 during DHCP configuration is hospital.org and the Unified CallManager hostname is CM1, the DNS server must resolve CM1.hospital.org to the IP address of the CallManager from the viewpoint of the 7985.
If NAT/PAT is being used between the CallManager and the 7985, the DNS server must return the NATed IP address of the CallManager and not its real address. If there are agents inside a firewall performing NAT on the IP address of the CallManager, that DNS server must respond to the DNS request using the actual IP address of the CallManager.
If this is not done, the Services URL button does not function. You can determine if this is the case by selecting the Settings button on the 7985 and selecting HTML Settings. If the URL fields are empty for Directories, Services, etc., then the 7985 was unable to resolve the fully qualified hostname of the CallManager passed to it during its initial boot up sequence. During this sequence, the 7985 requests its configuration file named SEP+MACAddress.cnf.xml via TFTP. This file contains a field called Process NodeName which is the hostname of the CallManager. This field does not change when you change the CallManager Server name via System/Server from a hostname to an IP address.
Figure 5-4 IPPA Caveat for the Cisco 7985
Cisco IOS Gatekeeper Configuration
To support H.323 devices in this solution, all devices register to the Cisco IOS Gatekeeper. The two devices focus on the Cisco CallManager and the Polycom PVX. Each of these devices is configured to register with the Gatekeeper. The Gatekeeper keeps track of the availability of these devices to receive calls based on its registration table. The registration table has directory numbers for each Polycom PVX endpoint that is registered. The Cisco CallManager is also registered to the Gatekeeper. Calls made from the Polycom PVX are routed to the Cisco CallManager, which then routes the call and provide protocol translation between endpoint types.
Configuration for the gatekeeper is simple:
gatekeeperzone local <gatekeeper name> cisco.com <IP address of Gatekeeper, recommend to use loopback address>gw-type-prefix #1* default-technologyno shutdownOnce CallManager and Polycom PVX register, the following registration table is shown on the gatekeeper. The Polycom PVX registers as a terminal with a unique E164 address and H.323 ID. The Cisco CallManager registers as a VOIP-GW and is a catch all to direct all calls towards with the exception for the E164 address that are registered to the Gatekeeper. With the given example, 3301 and 3302 resolve to the IP address of the registered endpoint while all other numbers resolve to the Cisco CallManager functioning as a VOIP-GW.
GATEKEEPER ENDPOINT REGISTRATION================================CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags--------------- ----- --------------- ----- --------- ---- -----172.21.52.98 33005 172.21.52.98 32787 HosA-gk VOIP-GWH.323-ID: RasAggregator_#1*_HosA-gk_1Voice Capacity Max.= Avail.= Current.= 010.21.153.204 1720 10.21.153.204 1719 HosA-gk TERME164-ID: 3301H.323-ID: PhysicianA10.21.153.205 1720 10.21.153.205 1719 HosA-gk TERME164-ID: 3302H.323-ID: PhysicianBTotal number of active registrations = 3QoS Configuration
AutoQoS
AutoQoS is a powerful tool to rapidly apply and deploy the QoS model to support the traffic class required for this solution. AutoQoS Enterprise introduced the support for video traffic. For Cisco IOS routers, AutoQos Enterprise detects and provisions for up to ten classes of traffic:
•
•
•
•
•
•
•
•
•
•
The AutoQoS Enterprise feature consists of two configuration phases, completed in the following order:
•
•
For devices that do not support the AutoQoS feature, the implementation section provides some configuration steps to classify traffic accordingly using a DIFFSERV QoS model.
Layer 3 Device
The following should be applied on devices that are Layer 3-aware inside the LIS or hospital network. The key elements are
•
•
•
•
Apply these to points of congestion within the network or at the edge of the network. Follow the QoS design rules as provided in the SRND for Enterprise QoS.
Layer 3 Devices
class-map match-all BEARER-TRAFFICmatch ip dscp efmatch ip dscp af41match ip dscp cs5class-map match-any CallSignalingmatch ip dscp cs3match ip dscp af31!!policy-map EGRESS-INTERFACEclass BEARER-TRAFFICpriority percent 33 ! Choose percentage based on traffic model allocated to voiceclass CallSignalingbandwidth percent 5 ! Choose percentage based on traffic model allocated to call signallingclass class-defaultfair-queueinterface GigabitEthernet0/0description connection to Catalyst 6509Eip address 172.21.61.65 255.255.255.240load-interval 30duplex autospeed 10service-policy output EGRESS-INTERFACEPhone Configuration on CallManager for QoS
Step 1
Step 2
•
•
Step 3
Step 4
Step 5
Step 6
•
•
•
CTI Port Configuration on CallManager for QoS
These are mainly the default setting already defined in Call Manager for DSCP settings.
Step 1
Step 2
Step 3
Step 4
Step 5
•
•
Cisco IOS Gatekeeper QoS
The Gatekeeper uses Cisco IOS methods to map H.323 RAS traffic. Once this traffic is mapped, a DSCP bits are set to CS3 through a policy-map. This policy-map is then applied to the Gatekeepers outbound interface to police all H.323 RAS traffic to ensure the proper DSCP is set.
class-map match-all ras_signalingdescription class map for H.323 RAS trafficmatch access-group 100!!policy-map set-qosclass ras_signalingset dscp cs3!!interface GigabitEthernet0/0description To HospitalA-Campus Shared 3750ip address 172.21.52.101 255.255.255.240duplex autospeed automedia-type rj45no keepaliveservice-policy output set-qosASA QoS
The ASA is along the path for traffic flowing from the enterprise to the WAN and the WAN to the enterprise. This setting should be applied to each EGRESS interface to allow for priority queueing for voice, video and signalling traffic.
interface GigabitEthernet0/0nameif outsidesecurity-level 0ip address 172.21.52.114 255.255.255.252!interface GigabitEthernet0/1nameif insidesecurity-level 100ip address 172.21.52.78 255.255.255.240priority-queue outsidepriority-queue inside!class-map RTP-VoIPmatch dscp efclass-map SIGNALINGmatch dscp cs3class-map PVX-RTPmatch dscp cs5class-map inspection_defaultmatch default-inspection-trafficclass-map VIDEO-CLASSmatch dscp af41policy-map VOIP-POLICYclass RTP-VoIPpriorityclass VIDEO-CLASSpriorityclass PVX-RTPpriorityclass SIGNALINGpriority!service-policy global_policy globalservice-policy VOIP-POLICY interface outsideservice-policy VOIP-POLICY interface insideTraffic Reclassification
To comply to the QoS Model used for this solution, some application data requires reclassification to meet the DSCP markings recommended. To implement this model, this setting should be applied to the first Layer 3 QoS-enabled device to remark the DSCP settings for:
•
•
•
•
•
•
The following is the configuration for all JTAPI messaging:
Note
http://www.cisco.com/en/US/products/sw/custcosw/ps1846/products_installation_and_configuration_guides_list.htmlip access list extended IPPA-CADpermit tcp any any eq 42027 ! CAD IPPC Gateway PGpermit tcp any any eq 59020 ! CAD Chat Servicepermit tcp any any eq 59000 ! GIOPpermit tcp any any eq 59003 ! Stat Servicepermit tcp any any eq 59004 ! Enterprise Serverpermit tcp any any eq 65432 ! LRM Services CORBA portpermit tcp any any eq 37350 ! VPN Autodiscoverpermit tcp any any eq 59028 ! CORBA for Cisco Supervisor Desktoppermit tcp any host <UCCX Host> eq 8080 ! IPPA Servelet running under TomCat webserverpermit tcp any any eq 59010 ! IPPA JSP Clientpermit tcp any any eq 38983 ! LDAP Directory Services for CAD, CSD, CDApermit udp any any eq 59010 ! IPPA server CORBA port and VoIP client's to-agent monitoring portpermit tcp any any eq 6293 ! Web Administrators - required for system maintanceclass-map match-all IPPA-CADmatch access-group name IPPA-CADpolicy-map IPPA-CAD-Signalingclass IPPA-CADset ip dscp cs3For H.323 Polycom PVX reclassification, apply the following configuration and apply to the EGRESS interface.
ip access-list extended H.323-Signalingpermit tcp any any range 1718 1720class-map match-all H.323-Signalingmatch access-group name H.323-Signalingpolicy-map H.323-Signalingclass H.323-Signalingset ip dscp af31QoS Marking Using Cisco Security Agent
Beginning in CSA release 5.0, host generated application traffic can be classified and marked using the Differentiated Services Code Point (DSCP) standard. This feature is especially useful when applications running on a host do not self classify their traffic using DSCP, or when access layer switches are not capable.
The Cisco Security Agent uses a centralized server that is used to distribute security and QoS policy to the CSA agents within the administrative domain. This administrator tool is referred to as the CSA MC. Within the CSA MC interface, the network administrator can create and assign QoS and security policies as needed.
The advantage of using CSA to classify and mark traffic generated by the host applications is that it does so at the point of traffic insertion into the network. This approach allows all downstream devices to honor the DSCP based QoS policy as close to the edge as possible. Since the policy is not self administered by the end user, QoS policy consistence can be obtained across the network, again through CSA's centralized approach to policy control.
Some examples of host-based applications that the Cisco Collaborative Care—Language Interpretation Service employs but which do not mark or mark traffic at all or in some cases mark it incorrectly are shown below.
•
•
The configuration of such marking and classification is documented in the Implementing Trusted Endpoint Quality of Service Marking document: http://www.cisco.com/application/pdf/en/us/guest/products/ps6786/c1225/ccmigration_09186a00805b6a81.pdf
In order to complete the configuration of the necessary QoS markings for these applications within CSA MC, the following steps are necessary:
Step 1
This is used to identify the application by name (Polycom PVX in this example), such as **\vvsys.exe. The ** indicates any path that the executable has been launched from.
Step 2
This creates an instance of a rule to be applied to the Application Class just created. An application class can have a number of different rules.
Step 3
This allows the assignment of the rule by type of rule—in this case a QoS DSCP attribute, as we want CSA to reclassify traffic generated based on port number for the specific application.
Step 4
This assigns the desired DSCP QoS markings to the rule module just created.
In summary, the CSA MC tool allows you to identify the application name and a set of rules that should be applied to traffic being generated by the specified application. The application names for Polycom PVX and Cisco Agent Desktop are shown in Table 5-1.
Table 5-1 Application Names
Polycom PVX version 8.x
Vvsys.exe
Cisco Agent Desktop version 4.5(2)
Agent.exe
For detailed information about the proper QoS markings required for an end-to-end QoS implementation for this solution, please see the QoS section of this document.
QoS Configuration—Not Covered
MPLS VPN configurations are not described as these setting are provided as part of the managed service from the service provider.
SIP PSTN Gateway requires QoS settings for the traffic on the IP leg of the call. These can be defined using class-maps that map both signaling and voice bearer traffic.
Access Security
Access security has several features. The three features recommended for Collaborative Care are:
•
•
•
Show below is part of the IOS switch configuration with these three features enabled.
!ip dhcp snooping vlan 80no ip dhcp snooping information optionip dhcp snoopingip arp inspection vlan 80!!!!!no file verify autospanning-tree mode pvstspanning-tree extend system-id!vlan internal allocation policy ascendinginterface FastEthernet1/0/48switchport access vlan 80switchport mode accessswitchport port-security maximum 10switchport port-securityswitchport port-security aging time 2switchport port-security aging type inactivityip arp inspection trustspanning-tree portfast!Additionally for Deployment Models 2 and 3
For deployment model 2 and 3, the addition of site-to-site communication that traverses two different business operations involves extra configuration that is not required for deployment model 1. This section summarized the configuration details required in both deployment model 2 and 3:
•
•
•
ASA Configuration ACL FW and NAT/PAT Configuration
This section provides a sample configuration for the ASA FW to protect traffic entering a site, IP address mapping between public and private addresses using NAT, and IP address overloading using PAT if the number of public IP addresses is less than the number of video calls made from a private IP address. This ASA FW configuration should be applied to each site.
Key steps are:
Step 1
Step 2
Step 3
Step 4
Sample Configuration from a Cisco ASA
interface GigabitEthernet0/0nameif outsidesecurity-level 0ip address 172.21.52.122 255.255.255.252!interface GigabitEthernet0/1nameif insidesecurity-level 100ip address 172.21.52.110 255.255.255.240! well known H.323 portsaccess-list acl_out extended permit tcp any any eq H.323access-list acl_out extended permit udp any any eq 1718access-list acl_out extended permit udp any any eq 1719! allow SIP traffic for SIP trunk communication between CallManagersaccess-list acl_out extended permit tcp any any eq sipaccess-list acl_out extended permit tcp any any eq 8080access-list acl_out extended permit tcp any any eq sshpager lines 24logging enablelogging buffer-size 1048576logging buffered debugginglogging asdm informationallogging debug-traceno logging message 106023mtu outside 1500mtu inside 1500mtu management 1500no failovericmp unreachable rate-limit 1 burst-size 1icmp permit any outsideicmp permit any insideasdm image disk0:/asdm512-k8.binno asdm history enablearp timeout 14400! PAT table for outside address 10.95.2.21 mapping to internal address in the range of 172.21.52.64/28global (outside) 1 10.95.2.21 netmask 255.255.255.240nat (inside) 1 172.21.52.64 255.255.255.240!NAT table for outside to inside addressstatic (inside,outside) 172.21.61.45 172.21.52.70 netmask 255.255.255.255static (inside,outside) 172.21.61.47 172.21.52.66 netmask 255.255.255.255! applies the acl_out to the outside interfaceaccess-group acl_out in interface outsideroute outside 0.0.0.0 0.0.0.0 172.21.52.113 3timeout xlate 3:00:00timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02timeout sunrpc 0:10:00 H.323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00timeout uauth 0:05:00 absolutehttp server enablehttp 192.168.1.0 255.255.255.0 managementno snmp-server locationno snmp-server contactsnmp-server enable traps snmp authentication linkup linkdown coldstartservice resetinboundtelnet timeout 5ssh timeout 5console timeout 0!class-map inspection_defaultmatch default-inspection-traffic!!policy-map global_policyclass inspection_defaultinspect H.323 h225inspect H.323 rasinspect netbiosinspect rshinspect rtspinspect skinnyinspect esmtpinspect sqlnetinspect sunrpcinspect tftpinspect xdmcpinspect sip!Cisco CallManager Locations
The location definitions vary depending on the deployment model. For deployment model 1, refer to the CallManager configuration section for Locations.
For Deployment Model 2, follow these procedures. Each site should have a uniquely-defined location that groups the phones. Separately, each site should have a location for each link of a SIP trunk. The bandwidth allocated for the voice and video resource pool should be designed to fit the data connection that the SIP trunk uses for site-to-site communication.
Note
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
To create the location for the SIP trunk that connects to another business, repeat steps 1-2 then proceed with the following:
Step 1
Step 2
Step 3
Step 4
For Deployment Model 3, follow these procedures. This model is limited to control the resource management defined on the CallManager at the LIS. This model is not aware of the CallManager at the various hospitals that this LIS supports. Each site that the LIS supports should have a unique location defined. In this location, the video endpoints and the SIP trunk should be associated with the same location.
Note
Procedure at LIS CallManager for Hospital A:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Procedure at LIS CallManager for Hospital B:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Cisco CallManager SIP Trunk
To support inter-site calls between two CallManagers that are operated by two different businesses, the connections require an IP data connection with a SIP call control protocol between the two sites. This section provides the steps to configure a SIP connection from a CallManager.
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
•
•
Step 10
Step 11
Step 12
Step 13
Step 14
Step 15
Step 16
•
•
MPLS VPN
MPLS VPN configurations are not covered in this document. This setting is determined by the MPLS VPN service from the Managed Provider. Align the MPLS implementation with the design guidelines provided in the QoS design section.
