Guest

Cisco Unified Intelligent Contact Management Enterprise

Troubleshoot CMS/MAPD

Cisco - Troubleshoot CMS/MAPD

Document ID: 20467

Updated: Oct 12, 2005

   Print

Introduction

This document contains information and procedures that reduce the time needed to pinpoint and solve many common Call Management System (CMS) and Multi-Application Platform on Definity (MAPD) problems.

Requirements

Prerequisites

Cisco recommends that you have knowledge of these topics:

  • CMS

  • Cisco Intelligent Contact Management (ICM)

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco ICM version 4.6.2 or later

  • Avaya Automatic Call Distribution (ACD)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

CMS - A Brief Description

The CMS provides snapshots of the real-time agent login and logout and of non-ACD-related agent state data to the Peripheral Gateway (PG) through the CMS Ethernet connection. A single CMS report is required for each Peripheral Interface Manager (PIM). For example, a duplexed PG connected to a single Definity Enterprise Communications Server (ECS) requires two CMS reports. Only one report is running at any given time, per the Definity ECS ACD.

CMS Issues

This section covers several items to check when you are troubleshooting the Avaya Definity G3 switch when CMS is implemented.

Check the Network Connection

Open the host file using a text editor. The host file can be found in C:\WINNT\system32\drivers\etc\hosts. Get both the host name and the IP address of the CMS device, and try to ping from a Telnet session or a DOS prompt on the PG that connects to the CMS device that is using the IP address. If you can not ping the CMS device then there is a network connection problem that must be resolved.

A Request timed out indication is a symptom of a broken network connection:

C:\> ping 194.234.25.11

!--- Use the IP address of the CMS device.

   Pinging 194.234.25.11 with 32 bytes of data:
   Request timed out.
   Request timed out.
   Request timed out.
   Request timed out.

Try to ping by the host name instead of the IP address, to verify that the host name is correct.

For additional information, refer to Ping Utility Usage.

Another command used to determine where the network break is located is the tracert command. This command is also run at a command prompt:

C:\> tracert 194.234.25.11

!--- Use the IP address of the CMS device.

For additional information, refer to Using the Trace Route Utility.

Check Timeout Errors

Timeout errors are a direct response from a ping command and, depending on the time delay, can also be a symptom of IP network problems:

C:\> ping 194.234.25.11
   Pinging 194.234.25.11 with 32 bytes of data:
   Reply from 194.234.25.11: bytes=32 time<10ms TTL=128
   Reply from 194.234.25.11: bytes=32 time<123ms TTL=128
   Reply from 194.234.25.11: bytes=32 time<175ms TTL=128
   Reply from 194.234.25.11: bytes=32 time<68ms TTL=128

The ECS PIM process that runs on the PG clearly shows, in either the process window or the PIM log files, that the CMS Real Time feed is down or an ASAI link 0 failure is detected.

If the CMS device is not sending the Real Time Adherence (RTA) report then the ECS PIM process on the PG can not become active; the ECS PIM process continually tries to restart until it receives the RTA report from the CMS device. The customer often is not aware of this type of problem, when the CMS report is viewed from the CMS PC. At this point, the CMS reports must be stopped and started, or the CMS PC must be stopped and started by the customer or Avaya support. This happens frequently when a customer does a CMS backup and forgets to stop and start the RTA report when the backup is completed.

See the Event ID table.

It is very important that the CMSTypicalRefreshRateSec on the PG matches the same time setting on the Avaya Definity G3. The preferred setting is 10 seconds. A mismatch of this setting can cause the CMS to go down randomly. This setting on the PG side can be found in the registry in one of these keys:

ICM 4.6.2 \HKEY_LOCAL_MACHINE\SOFTWARE\Geotel\ICR\<cust_inst>\<pg_inst> \PG\CurrentVersion\PIMS\<pim_inst>\ATTData:
5.x and later \HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\<cust_inst>\<pg_inst>\PG\CurrentVersion\PIMS\<pim_inst>\ATTData:

Note: Those keys are displayed over two lines due to space limitations.

The setting for this field on the Avaya side must be set by Avaya support.

This must be true when the Definity ECS is configured:

  • For a Basic Rate Interface (BRI) Adjunct Switch Application Interface (ASAI) link, the Terminal End Indicator (TEI) value is 3.

  • For a Definity LAN or MAPD, the TEI value is 1.

MAPD - A Brief Description

The MAPD is a card which is plugged into the Avaya Definity switch. The Call Visor LAN (CVLAN) Server software runs on it, and it is used to configure the ASAI links between the Switch and the PG. Most often, the links are on the same LAN segment as the PG.

It is entirely a Avaya product that is supported by Avaya.

Is the Problem Associated with the MAPD Card?

Avaya provides Cisco with a utility called ASAI_TEST that tests the connectivity from the Definity ESC PG over the ASAI link to the MAPD card. A test failure indicates that the trouble is with the MAPD card and that the card needs to be reset. Most often, the card is reset by Avaya onsite support in one of these ways:

  • Restart through software.

  • Press the reset button on the back of card.

This is an example of how to use the ASAI_TEST utility to test MAPD connectivity:

C:\icm\bin> asai_test -m hostname or ipaddress node_id


!--- The node_id is a value from 1 to 8.

The host name and IP address for the MAPD card can be found in the host table.

For additional information, refer to Using the ASAI_TEST Utility.

This is an example of a successful test connection with the host name amexphxg3:

C:\icm\bin> asai_test -m amexphxg3 1
Heartbeat with switch for ASAI node signal01 was successful.

This is an example of a failed test connection with the IP address 172.62.2.1:

C:\icm\bin> asai_test -m 172.62.2.1 1
Open of ASAI communication path for ASAI node signal01 failed.
  :Error messages not available
  open failed errno= 2
  Heartbeat test with switch for ASAI node signal01 failed.

For related Microsoft Event Viewer Application Log error codes associated with CMS and ASAI failures, see the Event ID table. Follow these steps to access the Microsoft Event Viewer on the PG:

  1. Choose Start > Programs > Administrative Tools (Common) > Event Viewer.

  2. Choose File > Open Log File from the Event Viewer menu.

  3. Select CMS/MAPD.

For additional information, refer to What is the NT Event Viewer?.

Microsoft Event Viewer Application Log Error Codes Associated with CMS and ASAI Failures

This table provides definitions of error codes related to CMS and MAPD that are generated by Microsoft Event Viewer:

Event ID Category
49275 ASAI link0 failure detected. Call visor ASAI reports status: 0.
49246 Required minimum number of ASAI links (1) not active.
32791 Client PIM1 stopping due to error.
63 Side A PIM1 process down.
49193 Unable to activate ASAI link 0.
49240 CMS agent real-time feed #0 data timeout.
16387 CMS data (0) processed invalid CMS record.
49134 Unable to activate CMS.
49157 CMS agent real-time feed #1 is down.

Related Information

Updated: Oct 12, 2005
Document ID: 20467