Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

ACD table record created with long ring time and 0 talk time

UCCX 8.5.1 started creating records in the ACD table with over 100 second ring times (sometimes thosands of seconds) and 0 talk time. I believe this is causing the CSQ Activity Summary report to tag these calls as unhandled (because of 0 talk time), even though the call was handled fine. We originally found that the extensions were set up with multiple devices (shared line) and have fixed that, but the problem persists. The agents are set up with Extension Mobility and look properly configured in CUCM  8.5.1. TAC has been working on it for weeks without definitive resolution.

The call flow is: trigger 1->receptionist app/CSQ-> receptionist who performs a manual transfer to 1 of a few triggers depending on callers needs -> app/script with subflow for caller info lookup and subflow for call queueing -> agent (where the long ring time occurs occasionally).      

Two sets of log files and agent debug files being reviewed by TAC and others have not yieled results yet. 

Has anyone seen CSQ Activity Summary report results showing inaccurate/increased unhandled calls and tracked it to bogus ACD table records with very long ring times and 0 talk times?

Everyone's tags (7)
2 REPLIES
New Member

I started to run into this

I started to run into this after a upgrade to 9.0.2. 

Did you ever figure out the cause?

New Member

The TAC engineer provided the

The TAC engineer provided the following response over the course of many months of going back and forth. I haven't had a chance to determine exactly what the impact is on the current call flows and if we need to implement a process to avoid the occurrence. Hope this helps.

The product development team has confirmed this is an expected behavior because the “Call Consult Transfer” step will always look to associate an IAQ contact. Since you are using this step to transfer a non-IAQ call to an agent’s extension, it will look for any existing IAQ contact before associating a new one and since it finds an existing one (from the 1st IAQ call), it will use the parameters of the 1st call, thereby causing the miscalculation in CCDR stats.

Thus, we officially recommend that you use the ‘Call Redirect’ step to transfer the call to non-IPCC lines of the agents.

But we do understand your need to perform a consult transfer, and so I’ve raised the following enhancement request (ID: CSCuq46764) to improve the current UCCX code:

https://tools.cisco.com/bugsearch/bug/CSCuq46764/?reffering_site=dumpcr

Here are the steps TAC used to reproduce the "expected behavior":

1.   Caller1 calls at RP1.

2.   Agent1 gets selected and handled the call.

3.   Agent1 dials RP2 and Agent2  gets selected

4.   Agent1 and Agent2 are in talking state.

5.   Agent1 hits transfer button.

6.   Caller1 and Agent2 are now in talking state.

7.   After some time another call comes in call center and handled by Agent3.

8.   Agent3 transfers the call to RP3.

9.   Script invoked and does a consult transfer to Agent2’s non-ipcc extension.

10. Since Agent2 is busy with caller1, he rejected this call.

11. Caller1 and Agnet2 are still in talking state.

12. One of them dropped the call and ACDR got written into DB.

Here in step 10, agent2 rejected the call and in this case we are seeing a large ringtime. If he accepts this call, the reports are generated fine.

Thus, the issue looks to be produced only when Agent2 receives a call on his/her non-ipcc extension, while he/she is already on call on the ipcc extension.

65
Views
0
Helpful
2
Replies