TServer CUCM 8.1.x remain in "Service Unavailable"

fabtor79 · January 22, 2020, 11:04am

Dear Genesys CTI Users,
I’m currently facing an issue integrating Genesys TServer with Cisco UCM.

Here is the current application versions installed on the environment:

Cisco UCM: 11.5.1.14900.11
JTAPI Client: 11.5.(1.14900)-10
Genesys T-Server CUCM: 8.1.500.09 (also tried with 8.1.202.39 as alternative)
Java version: Jre 1.7.0_80 (also tried with 1.8.0_77 as alternative)

When TServer is started the connectivity to Cisco is established but the TServer Genesys remain in status “Service Unavailable” and the cti-link is not correctly established. Looking at the TServer log file I can see that after 25 secs aprox from the startup the following java exception is generated:

@10:43:34.1530 [**1] 1 89 S 137 ‘cti-host query failed - java.net.ConnectException: Connection timed out: connect’
@10:43:34.1530 [((1] 1 152 ISIS 11 0 ‘’ 50 ‘Single JAVA EXCEPTION java.net.ConnectException: Connection timed out: connect in providerChangedEvent.Connection timed out: connect’
@10:43:34.1530 [cm] (process_CCM_TEVENT_ERROR)
@10:43:34.1530 [cm] JTAPI ERROR 50 in call 0, dn :Single JAVA EXCEPTION java.net.ConnectException: Connection timed out: connect in providerChangedEvent.Connection timed out: connect
@10:43:34.1530 [gctmi] TMsg [EventError()] distributing to model
@10:43:34.1530 [gctmi] Switch [sUNK] distributing EventError
@10:43:34.1530 [gctmi] Switch [sUNK] processError
@10:43:34.1530 [cm] CcmDevice::processHardwareError for DN: Message: ‘Single JAVA EXCEPTION java.net.ConnectException: Connection timed out: connect in providerChangedEvent.Connection timed out: connect’.

Looking at the JTAPI log file generated, here is the last entry I can found before the java exception is occuring:

381: Jan 20 10:43:34.153 MEZ %JTAPI-JTAPIIMPL-7-UNK:[com.genesyslab.ciscocm.JInterface@7cf4831b]ObserverProxy.deliverEvents() completed

After that I can see only heartbeat messages exchange among Cisco UCM and Genesys TServer.

Has someone of you already faced this kind of exception in the past could kindly provide help?

Many thanks and Best Regards,
Fabrizio

Kubig · January 22, 2020, 4:39pm

Did you check whether the connectivity between TServer host and CUCM is working? According to your log messages it seems TS cannot reach CUCM CTI link over the network.

fabtor79 · January 23, 2020, 3:02pm

Hi Kubig,
Connectivity seems ok, verified with “netstat” command. The connection among JTAPI client and CUCM on port 2748 is in place in “ESTABLISHED” status.
As I wrote before also the jtapi log file is created.

I can see the channel among Genesys and CUCM established and also the capabilities of the link are exchanged (see JTAPI log excerpt below).



Open Link:

Genesys --> CUCM

35: Jan 23 15:16:10.606 MEZ %JTAPI-PROTOCOL-7-UNK:(P1-193.247.XX.YY) [main] sending: com.cisco.cti.protocol.ProviderOpenRequest {
provider                   = 193.247.XX.YY
qbeClientVersion           = Cisco JTAPI 11.5(1.14900)-10 Release
login                      = com.cisco.cti.protocol.UnicodeString {
  unicodedisplayName = CTIuserMCCS
  count              = 11
  sizeofElement      = 2
  }
filter                     = com.cisco.cti.protocol.ProviderEventFilter {
  deviceRegistered                        = true
  deviceUnregistered                      = true
  directoryChangeNotify                   = true
  deviceConfigChangeNotify                = true
  deviceEMLoginStatusChangeNotify         = true
  deviceMultiMediaCapabilityChangedNotify = true
  }
applicationID              = T-Server
desiredServerHeartbeatTime = 30
requestTimer               = 0
cmAssignedApplicationID    = 0
pluginName                 = CiscoJTAPI
applicationPriority        = 2
lightWeightOpen            = false
authenticationType         = 0
requestOldDeviceLineFetch  = false
}

CUCM --> Genesys:

36: Jan 23 15:16:10.615 MEZ %JTAPI-PROTOCOL-7-UNK:(P1-193.247.XX.YY) received Response: com.cisco.cti.protocol.ProviderOpenResponse {
  sequenceNumber     = 1
  result             = 0
  providerInfoString = 11.5.1.14900-11.i386
  clientHeartbeat    = 30
  serverHeartbeat    = 30
  requestTimer       = 5
  pluginVersion      = 11.5.1.14900-10.i386
  pluginLocation     = http://uci-csra-nc-XXX.domain.net/plugins/
  providerId         = 33554466
  fipsCompliant      = false
  }

CUCM --> Genesys:

43: Jan 23 15:16:10.930 MEZ %JTAPI-PROTOCOL-7-UNK:(P1-193.247.XX.YY) received Event: com.cisco.cti.protocol.ProviderOpenCompletedEvent {
  eventSequence            = 0
  reason                   = 0
  sequenceNumber           = 1
  providerInfoString       = 11.5.1.14900-11.i386
  clientHeartbeat          = 30
  serverHeartbeat          = 30
  failureDescription       = null
  bMonitorCallParkDNs      = true
  providerId               = 33554466
  precedenceValue          = 96
  canSupportIPv6           = false
  loginUserName            = com.cisco.cti.protocol.UnicodeString {
  unicodedisplayName = 
  count              = 0
  sizeofElement      = 2
  }
  daysUntilPasswordExpiry  = -1
  totalControllableDevices = 6
  clusterID                = csra-cucm-001
  }

Capabilities Info:

Genesys --> CUCM:

48: Jan 23 15:16:10.931 MEZ %JTAPI-PROTOCOL-7-UNK:(P1-193.247.XX.YY) [main] sending: com.cisco.cti.protocol.ProviderGetCapabilitiesRequest {
  sequenceNumber = 2
  }

CUCM --> Genesys:

49: Jan 23 15:16:10.939 MEZ %JTAPI-PROTOCOL-7-UNK:(P1-193.247.XX.YY) received Response: com.cisco.cti.protocol.ProviderGetCapabilitiesResponse {
  sequenceNumber           = 2
  result                   = 0
  providerCapabilitiesInfo = com.cisco.cti.protocol.ProviderCapabilitiesInfo {
  controlAnyDevice       = true
  maxNumberOfDevicesOpen = 0
  monitorParkDN          = true
  modifyCallingParty     = true
  allowCallMonitoring    = true
  allowCallRecording     = true
  canSupportIPv6         = false
  providerCapabilityMask = 3
  canAutoPickup          = false
  }

Then Genesys start to receives details about the DN configured on CUCM and immediately after the “completed” message is received:


406: Jan 23 15:16:32.224 MEZ %JTAPI-JTAPIIMPL-7-UNK:[com.genesyslab.ciscocm.JInterface@407cf41]ObserverProxy.deliverEvents() completed

the java exception occured:


@15:16:32.2240 [**1] 1 89 S 137 'cti-host query failed - java.net.ConnectException: Connection timed out: connect'

Starting from this point no other messages are exchanged among Genesys and CUCM except heartbeat messages. So let means the channel at transport level remain established.

After the java exception, today I found also this error on the TServer log file:


@15:17:07.9000 [**1] 1 50 S 137 'JTAPI Mismatch. Local:null. Provider:null'
@15:17:07.9010 [((1] 1 28 S 48 '11.5.1.14900-11.i386'
@15:17:07.9010 [cm] Collected jtapi[1] tevent(48:JTAPI_KEEP_ALIVE)(11.5.1.14900-11.i386:) (0:0)  (:0).
@15:17:07.9010 [))1] RespondCCMKeepAlive 11 60000

On Genesys side I’m using a 64 bit version of the JTAPI client. Could it be that on Cisco side a 32 bit is in use and this could generate the issue?

Many thanks and Kind Regards,
Fabrizio

fabtor79 · February 27, 2020, 10:01am

Dear Genesys CTI Forum users,
i would like to inform all of you that finally I was able to resolve this issue. This was caused because port 80 among Genesys TServer and Cisco CUCM was blocked by the firewall. Evenif the option “jtapi-update-mode” was set to “never”, Genesys TServer CUCM was trying to establish a connection to this port and, since blocked, was raising up this Java exception and stays in “Service Unavailable”. I opened a ticket to Genesys (2691710) about that. Genesys recognized that is a bug and fix this behavior on a newest version of TServer CUCM (8.1.501.33).

Kind Regards,
Fabrizio

cavagnaro · February 27, 2020, 3:29pm

Nice! Thanks for sharing your solution!

Enviado de meu SM-N9600 usando o Tapatalk