CUEAC Console stuck calls in Queue

[arazarvin]

Hello,

We have an issue with stuck calls in CUEAC console. The inbound calls get stuck in All Queue and do not drop to Active calls. Cannot be answered, moved, etc. Operator needs to lift the receiver on the C7965 phone and put it back to terminate the call. 

We tried a lot of steps to fix the issue - completely re-installed CUEAC Server, client, CT gateway devices, CTI Route pointes, and etc with Cisco TAC help. Also replaced network cables, replaced the phone, replaced computer. Same issue.  Everything was working fine for a couple of years, but now it started all of a sudden. We get probably about 10 to 20 issues like that though out the day.

Can anybody advise please?

Thank you,

-Alex

[mohamedatefasal]

Hi,

I have the same exact issue .. did you find a solution for this?

[arazarvin]

Not exactly. 

We had to get our Cisco rep. involved, escalated within CiscoTAC, switch CiscoTAC engineers, got Post Sales team attention and etc., to get somewhat positive results. Very unique experience...

Anyway, the workaround (not a solution) was to go to:

1. Cisco Attendant Console Administration portal

2. User Configuration

3. Queue Management

4. Change "Call Delivery Method" from "Forced Delivery" to "Broadcast".

I would advise to contact CiscoTAC to make these changes for you, since they had to rebuild the queue to make such changes. Needs to be done after business hours, this is very intrusive.

Now, because we have only one operator, the Call Delivery method, Forced or Broadcast, wasn't important to us. The calls stopped getting stuck in the queue, because the additional leg between Cisco Attendant console and the Cisco IP Phone was eliminated by changing the behavior of how an incoming phone call is being answered. 

Right now, a phone call can be answered at the Cisco Attendant Console only, the Cisco IP Phone itself is not ringing.

An incoming call "rings" from the PC speakers. It is not ringing on the Cisco phone at all. The call would need to be answered by operator within the Console itself by clicking with the mouse. Then the call would be directed to the Cisco IP Phone for an operator to handle the call.

Additional thoughts:

Was the issue addressed by this workaround? -yes.

Was the root cause of the issue found, isolated and a solution provided? - no.

I am not sure if our workaround would be a good fix for other organizations. 

Also, we have decided to move to another product if the issue comes back or any issue to be honest. We wasted too much time and energy on this issue. I can share the info on the alternative product to Cisco Attendant console, if needed.

Thank you,

[Alejandro Robles]

Hi.

In our case the reason was the operator. He was using a semi-blind transfers.

Take a look to this BUG:

Calls gets stuck in queue when two or more actions are done to a call at the same time

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve26225 

Symptom:
Calls appear stuck in queue, preventing delivery of subsequent calls to a any user for forced delivery queues or delivery to a specific user for broadcast queues. The calls appearing 'stuck' in queue may appear to 'flash' which is actually the call attempting delivery to an operator, failing, routing back to queue and attempting delivery again.

Conditions:
Background composite
OPR1 has transfer recall enabled for both internal and external calls
QueueB has forced delivery enabled

Scenario:
CallA rings in to QueueA
OPR1 accepts call.
OPR1 initiates consult transfer of CallA to Queue B
OPR2 accepts CallA at the exact time OPR1 completes the consult transfer

Possible Outcome (as it may not happen every time):
Call delivery to OPR2 device fails, resulting in the call bouncing back and forth between delivery attempt and queue (appearing on screen to flash).

Note that in executing a consult transfer as noted, users are attempting semi-blind transfers a method that is not technically supported by the software for reasons just as this.

Workaround:
When executing a transfer from one console queue or console user to an alternate queue location on the same server, use any combination of the following:
A) Use blind transfers
B) Await acceptance of the consult transfer before completing the transfer
--- It is important to note, that by completing a consult transfer prior to acceptance or call connection, users are using a technically unsupported call control action 'semi-blind transfers'. To properly execute with a 100% success rather, users must await acceptance of a consult transfer call before completing the call transaction.
C) Enable direct transfers (Please note, doing this will mean losing transfer recall capability). This is done in the console operator Preferences > Advanced menu (by selecting No Calls).

Further Problem Description:
Root cause is that multiple call controls are being executed for the same call at the same time by two or more operators. In the noted example, it results from OPRA attempting to clear the call at the precise time the answer request is received by OPRB. For lack of better terms this is a race condition, and unfortunately is not unexpected given the circumstances leading to the presumed failure.

[Matheus Lopes]

Hi,

I've had the same problem having the calls stuck in the Queue, but in CUACA.

I've fixed this doing the steps below:

- Deleting the Queue

- Creating a new Queue Device Group

- Create new CT Gateway Devices, Service Devices, Park Devices

-  Recreating the Queue

- Associating the Queue to the Operator

- Log out and Log in on the CUACA client software

I hope it helps!