CSD shows oldest in queue as 1(00:00:00)

From DocWiki

Revision as of 10:02, 7 March 2011 by Srib (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

CSD shows oldest in queue as 1(00:00:00)

Problem Summary CSD shows oldest in queue as 1(00:00:00)
Error Message CSD shows oldest in queue as 1(00:00:00).
Possible Cause

Some of the causes are for this issue are :

1. Issues with CUCM JTAPI events.
2. Race condition due to transfer being completed by the agent before the consult call made by agent to RP is fully queued at the CTI port.
3. Agent performing unsupported operation like setting up a call between 2 CTI ports.
Recommended Action

Step 1. Enable the necessary log levels and wait for an occurrence.

1. SS_CM - XDebug1 
2. SS_RM - XDebug1 
3. SS_TEL - Debug 
4. ICD_RTDM - XDebug1 
5. ICD_CTI - XDebug1
6. JTAPI client logs in all debug levels

Step 2. To find the stuck call, look for all QUERY_QUEUE_STATISTICS_CONF messages in the logs with oldestCallInQueue =0 and see the ones where callsInPriorityQueue is not 0. This means that even though there is a call in the queue, the waiting time is 0. There is a stuck call in the ESD id indicated by SkillGroupNum.

63652323: Feb 17 11:15:51.077 GMT %MIVR-ICD_CTI-7-UNK:OutboundMessageprocessor : sending msg : { length=-1 type=QUERY_QUEUE_STATISTICS_CONF,invokeId=58819854 SkillGroupNum=120 loggedInAgents=1 inSessionAgents=0 availableAgents=1 unAvailableAgents=0 inWorkAgents=0 selectedAgents=0 callsInPriorityQueue1=1 callsInPriorityQueue2=0 callsInPriorityQueue3=0 callsInPriorityQueue4=0 callsInPriorityQueue5=0 callsInPriorityQueue6=0 callsInPriorityQueue7=0 callsInPriorityQueue8=0 callsInPriorityQueue9=0 callsInPriorityQueue10=0 startTime=Thu Feb 17 00:00:01 GMT 2011 endTime=Thu Feb 17 11:15:51 GMT 2011 totalCall=0 oldestCallInQueue =0 handledCallsToday=0 callsAbandoned=0 callsDequeued=0 averageTalkDuration=0 averageWaitDuration=0 longestTalkDuration=0 longestWaitDuration=0 to socket: Socket[addr=,port=51485,localport=42027] }

Search the logs for the calls in that CSQ to find the stuck call. The stuck call will keep showing up in this ESD for unreasonable time.

63652311: Feb 17 11:15:51.077 GMT %MIVR-SS_RM-7-UNK:ESD: 120 Contacts in Queue[1]: 33833652[279220/2]

Step 3. With the stuck call ID, search the logs for this call when it first entered UCCX and check the call flow to analyze the stuck call and find out how it got stuck. Step 4.If the problem is still not solved then collect logs and raise a support case with the stuck call ID.

Release 8.0(1)
Associated CDETS # CSCsu40814.

Rating: 0.0/5 (0 votes cast)

Personal tools