50% calls are getting aborted/ rejected in uccx 8.5

[Shalid Kurunnan Chalil]

We ahving a client site with uccx 8.5

But we are experiencing a problem that more 50% of the calls are getting aborted or rejected.

when we run the Aborted and Rejected call detail report, we are getting following reason,

Call Rejected    Reject: Trigger Failed

Call Aborted     disconnect call; nested exception is:com.cisco.jtapi.PlatformExceptionImpl: Cti request timed out

Could any one help? Is there any doc where i can refer the reject reaons.

[Jonathan Schulenberg]

Is the *exact* build of CUCM you have listed in the CCX compability matrix?

If so, are the JTAPI versions in sync (page 150) between CUCM and CCX? Something is seems to be wrong in the TSP.

If that all checks out re-sync the telephony data as well; it's possible some of the CTI ports were deleted on CUCM.

[Shalid Kurunnan Chalil]

Thanks for the reply Jonathan,

We have checked the compatibilty ..

UCCX : 8.5.1.11022-22

CUCM : 8.5.113900  It is compatible.

When i check the MIVR logs i found following errior.

EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrOutOfService,cause=1001,Addr=TP[id=119,implId=8517,state=IDLE]

40868: Dec 27 20:10:59.969 EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrOutOfService,cause=1001,Addr=TP[id=249,implId=8373,state=IDLE]

40869: Dec 27 20:10:59.969 EST %MIVR-SS_TEL-2-SS_PARTIAL_SERVICE:JTAPI subsystem in partial service: Failure reason=A number of CTI ports are OOS - TPG[id=0,state=PARTIAL_SERVICE]:Ports[8517]

40870: Dec 27 20:10:59.969 EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrOutOfService,cause=1001,Addr=TP[id=258,implId=8286,state=IDLE]

40871: Dec 27 20:11:00.045 EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrInService,Addr=TP[id=119,implId=8517,state=OUT_OF_SERVICE]

40872: Dec 27 20:11:00.053 EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrInService,Addr=TP[id=249,implId=8373,state=OUT_OF_SERVICE]

EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrOutOfService,cause=1001,Addr=TP[id=119,implId=8517,state=IDLE]

40868: Dec 27 20:10:59.969 EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrOutOfService,cause=1001,Addr=TP[id=249,implId=8373,state=IDLE]

40869: Dec 27 20:10:59.969 EST %MIVR-SS_TEL-2-SS_PARTIAL_SERVICE:JTAPI subsystem in partial service: Failure reason=A number of CTI ports are OOS - TPG[id=0,state=PARTIAL_SERVICE]:Ports[8517]

40870: Dec 27 20:10:59.969 EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrOutOfService,cause=1001,Addr=TP[id=258,implId=8286,state=IDLE]

40871: Dec 27 20:11:00.045 EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrInService,Addr=TP[id=119,implId=8517,state=OUT_OF_SERVICE]

40872: Dec 27 20:11:00.053 EST %MIVR-SS_TEL-6-CTI_ADDRESS_EVENT:Receives: Event=CiscoAddrInService,Addr=TP[id=249,implId=8373,state=OUT_OF_SERVICE]

is this having anything to do with this rejection / abort??

[Gabriel Saavedra]

Hi,

In that case, can you check in your callmanager if all the CTI ports are registered?...check if CTI port 8517 is registered and if it is being control by the JTAPI application user. Also try what Jonathan said, do a resynch

Gabriel.

[Shalid Kurunnan Chalil]

Hi all,

I have checked below things.

1. CTI ports are registered in the cucm

2. Cisco Jtapi Resynch

3. Data synchronisation as well as data check done.

4. Restarted the CTI manger from Pub and then subscriber before resynch.

But i am still facing the issue . the calls are rejecting and in the Historical report it showing Trigger: failes.

Call flow

PSTN--> VG--> CUCM--> CUCX.

[oliverpowell]

Hi,

DId you resolve this issue?

We have a similar problem where 50% of calls are being rejected due to Trigger Rejected reasons.

All data re-sync'd and checked. JTAPI re-sync'd and CTI Manager services restarted on each node.

Thanks

Oli

[monica.bryant]

Did you find out the cause of this problem?  We are experiencing the same issue with UCCX 8.5.1

[Gabriel Saavedra]

Also can you tell us about the call flow?...A few weeks ago I had the same problem, where the calls in queue were disconnected when transfering to the agent. My problem was because of the lack of MTP resources we were using in the SIP trunk where the calls were coming in.

Gabriel.

[Abdulbaseer Mohammed]

wondering your call flow or is this script may be copied from another platform that had dual IP IVR?

can you trace the call and see  in your script if the call fails at a particular spot and is it alternating?

good luck.

Baseer.