cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1956
Views
0
Helpful
7
Replies

Stuck Sessions in UCCX7

sgavan
Level 1
Level 1

New install of UCCX7.0SR4.

I have several "stuck" sessions per the screenshot.  Seems to add one or two a day.

1st, what will happen if they never clear and I reach the "max session" setting for some of my triggers?

2nd, is there any way to clear them short of a reboot?

3rd, what would cause these to get stuck?

Thanks in advance!

Capture.PNG

7 Replies 7

ysawant
Level 1
Level 1

Hi,

To answer your questions,

1st, what will happen if they never clear and I reach the "max session" setting for some of my triggers?

>> No new calls will be accepted, callers will hear busy /reorder tone

2nd, is there any way to clear them short of a reboot?

>> a) restart CCX engine

     b) resynch JTAPI

     c)Try recreating CTI ports( delete the existing one and add them again)

If this does not help, open up a TAC case.

3rd, what would cause these to get stuck?

>>There could be many factors for this like (not limited to)

a) Scripting problem (not ending properly)

b) CTI Port hang

Hope this helps.

--Yuvraj

Hi All

I have similar issue with sessions that stuck. It happens only time to time (every 20-50th call).

I was able to reproduce problem on two different UCCX7 Servers that were running SR4 and SR5 Patches.

To reproduce a problem I created a very simple script that accepts a call, play prompt and terminates call (Called Test).


I've also found out that sessions are opened because contacts associed with these sessions are not handled properly.

Please see attached screenshot (contacts hadled not properly are contacts with Type=Cisco JTAPI and with "Task" fild empty).

At the time the error occurs and these contact is produced (session stucks), callers hears busy/reorder tone.

JTAPI/CTI Ports configuration and scripts looks fine.

When error occurs I can also see it also in logs (2 examples):

%MIVR-SS_CM-7-UNK:RmCm contact -1[null] .setAppContact(1957) from null 654548:
Jan 27 09:59:55.935 GMT %MIVR-SS_TEL-7-UNK:Call.received()
JTAPICallContact[id=1957,implId=157059/1,state=STATE_RECEIVED_IDX,inbound=true,App
name=MainNumber,task=null,session=null,seq
num=-1,cn=8900,dn=8900,cgn=90214304165,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=8900,route=RP[num=8900],TP=null  
654549: Jan 27 09:59:55.935 GMT %MIVR-SS_CM-7-UNK:ICDContactAdapter 1957 :
ContactSessionChanged received for App FW contact 1957, iefSourceContact is
16934275 [157059/1] (1527) 654550: Jan 27 09:59:55.935 GMT
%MIVR-SS_CM-7-UNK:Ignoring contactSessionChanged because either the new or old
session is null 654551: Jan 27 09:59:55.935 GMT
%MIVR-EXECUTOR_MGR-4-CMD_EXCEPTION:Un-handled command exception:
Facility=MIVR,Sub-Facility=SS_TEL,Executor
id=TPG_ROUTE_EXE,Mnemonic=ROUTE_CALL_EV,Thread=MIVR_SS_TEL_TPG_ROUTE_EXE-46-656,Thread
priority=10,Time=0,Exception=com.cisco.jtapi.PlatformExceptionImpl: Active call
exists on this address 654552: Jan 27 09:59:55.935 GMT
%MIVR-EXECUTOR_MGR-4-EXCEPTION:com.cisco.jtapi.PlatformExceptionImpl: Active
call exists on this address 654553: Jan 27 09:59:55.935 GMT
%MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.jtapi.IntraProviderAddress.CTQF(CTQF) 654554: Jan 27 09:59:55.935 GMT
%MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.jtapi.IntraProviderAddress.clearCallConnections(CTQF) 654555: Jan 27
09:59:55.935 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.wf.subsystems.jtapi.TAPIPortGroup$Port.dropAnyConnections(TAPIPortGroup.java:4138)
654556: Jan 27 09:59:55.935 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.wf.subsystems.jtapi.TAPIPortGroup$Port.access$7100(TAPIPortGroup.java:2759)
654557: Jan 27 09:59:55.935 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.wf.subsystems.jtapi.TAPIPortGroup$RouteCallObserver$1.run(TAPIPortGroup.java:18631)
654558: Jan 27 09:59:55.935 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.runCommand(ExecutorStubImpl.java:690)
654559: Jan 27 09:59:55.935 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:486)
654560: Jan 27 09:59:55.935 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:762)
654561: Jan 27 09:59:55.935 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:768)
654562: Jan 27 09:59:55.935 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.executor.impl.PooledExecutorStubImpl$1$WorkerImpl.run(PooledExecutorStubImpl.java:99)
654563: Jan 27 09:59:55.935 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.util.ThreadPoolFactory$ThreadImpl.run(ThreadPoolFactory.java:853)

------------------------------------------------------------------------------------------------------------

%MIVR-SS_CM-7-UNK:RmCm contact -1[null] .setAppContact(3036) from null 876398:
Jan 27 13:31:57.879 GMT %MIVR-SS_TEL-7-UNK:Call.received()
JTAPICallContact[id=3036,implId=158521/1,state=STATE_RECEIVED_IDX,inbound=true,App
name=MainNumber,task=null,session=null,seq
num=-1,cn=8900,dn=8900,cgn=9229401,ani=null,dnis=null,clid=null,atype=DIRECT,lrd=null,ocn=8900,route=RP[num=8900],TP=null
876399: Jan 27 13:31:57.879 GMT %MIVR-SS_CM-7-UNK:ICDContactAdapter 3036 :
ContactSessionChanged received for App FW contact 3036, iefSourceContact is
16935737 [158521/1] (2385) 876400: Jan 27 13:31:57.879 GMT
%MIVR-SS_CM-7-UNK:Ignoring contactSessionChanged because either the new or old
session is null 876401: Jan 27 13:31:57.879 GMT
%MIVR-EXECUTOR_MGR-4-CMD_EXCEPTION:Un-handled command exception:
Facility=MIVR,Sub-Facility=SS_TEL,Executor
id=TPG_ROUTE_EXE,Mnemonic=ROUTE_CALL_EV,Thread=MIVR_SS_TEL_TPG_ROUTE_EXE-46-928,Thread
priority=10,Time=0,Exception=com.cisco.jtapi.PlatformExceptionImpl: Active call
exists on this address 876402: Jan 27 13:31:57.879 GMT
%MIVR-EXECUTOR_MGR-4-EXCEPTION:com.cisco.jtapi.PlatformExceptionImpl: Active
call exists on this address 876403: Jan 27 13:31:57.879 GMT
%MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.jtapi.IntraProviderAddress.CTQF(CTQF) 876404: Jan 27 13:31:57.879 GMT
%MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.jtapi.IntraProviderAddress.clearCallConnections(CTQF) 876405: Jan 27
13:31:57.879 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.wf.subsystems.jtapi.TAPIPortGroup$Port.dropAnyConnections(TAPIPortGroup.java:4138)
876406: Jan 27 13:31:57.879 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.wf.subsystems.jtapi.TAPIPortGroup$Port.access$7100(TAPIPortGroup.java:2759)
876407: Jan 27 13:31:57.879 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.wf.subsystems.jtapi.TAPIPortGroup$RouteCallObserver$1.run(TAPIPortGroup.java:18631)
876408: Jan 27 13:31:57.879 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.runCommand(ExecutorStubImpl.java:690)
876409: Jan 27 13:31:57.879 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:486)
876410: Jan 27 13:31:57.879 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.executor.impl.ExecutorStubImpl$RequestImpl.run(ExecutorStubImpl.java:762)
876411: Jan 27 13:31:57.879 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:768)
876412: Jan 27 13:31:57.879 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.executor.impl.PooledExecutorStubImpl$1$WorkerImpl.run(PooledExecutorStubImpl.java:99)
876413: Jan 27 13:31:57.879 GMT %MIVR-EXECUTOR_MGR-4-EXCEPTION: at
com.cisco.util.ThreadPoolFactory$ThreadImpl.run(ThreadPoolFactory.java:853)

------------------------------------------------------------------------------------------------------------

Does anybody has similar issue? Do you know how to fix it?

Kind Regards

Greg Markiewicz

Currently have TAC cases open for the this issue with several UCCX7 customers.  Appears to be only affecting customers running CUCM7.1.3a or b version at least in our cases.  TAC provided a Callmanager ES for one customer and so far (1 day) it has fixed the issue.  We are going to give it a few more days and then patch our other customers on 7.1.3 running UCCX7.  Hope that helps...  open a TAC case to confirm.

Thanks for letting me know!

I hope new patches will be on cisco website soon.

Regards

Greg Markiewicz

Hi,

I have found myself facing the same issue. Can you tell me what was the defect they have identified for this issue, and what was the UCCX version and CUCM version that fixed your issue?

Thanks in advance,

Regards,

Jose

Upgrade CUCM to 7.1(3b)SU2 or higher to resolve CSCtb77537 per TAC.  This helped for MOST of our customers.  Still have one customer that is seeing stuck sessions after the upgrade and under heavy server load (still have a TAC case  open).  But it did resolve this on all other customer sites having the issue.

Thanks for the reply.

Regards,

Jose

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: