Stuck Sessions in UCCX7

Unanswered Question

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
ysawant Fri, 02/05/2010 - 01:53

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

gmarkiewicz Fri, 02/12/2010 - 03:23

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

Attachment: 

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.

gmarkiewicz Mon, 02/15/2010 - 01:27

Thanks for letting me know!

I hope new patches will be on cisco website soon.

Regards

Greg Markiewicz

Upgrade CUCM to /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} 7.1(3b)SU2 or higher to resolve /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} 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.

Actions

This Discussion

Related Content