Cisco Unified Contact Center Express

Document ID: 53022

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Topology
Problem
Solution
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

This document describes one reason why the Java Telephony API (JTAPI) subsystem is out of service and provides a solution for a Cisco IP Contact Center (IPCC) Express environment.

Prerequisites

Requirements

Cisco recommends you have knowledge of these topics:

• Cisco CallManager

• Cisco Customer Response Solutions (CRS)

Components Used

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

• Cisco CallManager version 3.x

• Cisco CRS

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.

Topology

Two CRS applications run on separate CRS servers, as this diagram shows. However, both CRS applications share the exact same Computer Telephony Integration (CTI) ports in the same CallManager cluster.

Problem

The JTAPI subsystem is in the Out Of Service status. The CTI ports are registered in Cisco CallManager but the route points are no longer registered. Once these steps are complete, the route points are registered again, but the JTAPI subsystem is still Out of Service:

1. Disassociate and associate CTI route points with CTI ports.

2. Reboot Cisco CallManager and CRS.

Solution

When you analyze the JTAPI log, located in the C:\Program Files\wfavvid\log directory by default, these key messages are found:

2452: Jun 09 12:35:26.140 CDT 
%JTAPI-JTAPI-7-UNK:(P1-JTAPIUser)[SS_TEL_INIT][IPCC_PORT_011]Request: register( 
MSRSIPCC/10.79.210.19, 16384, capabilities: "G.711 U-law 64k 30 frame packet 
size", "G.711 A-law 64k 30 frame packet size") 
2453: Jun 09 12:35:26.140 CDT %JTAPI-PROTOCOL-7-UNK:(P1-10.79.210.17) 
[SS_TEL_INIT] sending: com.cisco.cti.protocol.DeviceRegisterDeviceRequest { 
sequenceNumber = 474 
deviceName = IPCC_PORT_011 
ipAddr = 332549898 
rtpPortNumber = 16384 
mediaSpecificationTimeout = 0 
mediaCaps = 2@[ 
com.cisco.cti.protocol.MediaCapability { 
payloadCapability = 4 
maxFramesPerPacket = 30 
bitRate = 1 
}, 
com.cisco.cti.protocol.MediaCapability { 
payloadCapability = 2 
maxFramesPerPacket = 30 
bitRate = 1 
}] 
filter = com.cisco.cti.protocol.DeviceEventFilter { 
deviceModeChanged = false 
keyPressed = false 
featureButtonPressed = false 
lampModeChanged = false 
ringModeChanged = false 
displayChanged = false 
startTransmission = false 
stopTransmission = false 
startReception = false 
stopReception = false 
softKeyPressed = false 
deviceData = true 
} 
disableAutoRecovery = false 
} 
2454: Jun 09 12:35:26.140 CDT %JTAPI-PROTOCOL-7-UNK:(P1-10.79.210.17) received 
Response: com.cisco.cti.protocol.FailureResponse { 
sequenceNumber = 474 
resultCode = -1932787709 
description = 
}

The decimal resultCode (-1932787709) is equal to the hexdecimal 0xFFFFFFFF8CCC0003. Remove all of the leading Fs and the result is 0x8CCC0003. This equates to a cause code of EXISTING_FIRSTPARTY. This indicates another CTI provider is already registered these to ports.

There is another CRS server configured to use the same CTI ports. Change the CRS configuration to allow only one CRS application to use the CTI ports in order to fix the issue.

NetPro Discussion Forums - Featured Conversations

Related Information

• Technical Support & Documentation - Cisco Systems