UCCX App Transfer to another Application with Queue. Agents see 2 participants in the call

[Nathan Grovhoug]

Hello

We are using UCCX 12.5. I have a script that handles inbound calls on a main number. If the user presses 1 during a menu prompt I am using a call redirect to transfer the call to a trigger of another application that has a queue. When the agent receives the call, finesse shows 2 participants (the Caller and the CTI Port that transfered the call from the first script).

I mark the call as handled and end the call old script but the "CTI" Participant persists on the agent call. 

Attached is a screen showing the script and the participants in Finesse

Anyone know what I am missing?

[Anthony Holloway · Accepted solution]

This was filed as a defect: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu95441

[ValeriKehayov]

Hi, 

Yes, with call redirect step as Anthony mentioned you will face this bug. I have still ongoing ticket with TAC regarding the same issue and I guess the bug was opened for my case.

Anyway so you have 3 different variants to transfer call between scripts and all 3 have different kind of issues/bugs.

1. Call redirect step - the presentation in Finesse preserves the first CTI port from the first script.

2. Trigger application step- unfortunately there is an another defect. When the call enters the queue loop and all agents are in not ready status, when they became ready the transfer is delayed for about 30-40 seconds in the mean time the agent is in reserved state and the customer hears ringing. Sometimes the call is never forwarded to the agent and it is dropped. If the agent is in status ready and the call is transferred to the queue all is working as expected.

3. Call subflow step- there is another bug with that step all the calendar steps are ignored and when you call in non working hours the call is always forwarded to the queue.

So all 3 possible steps to transfer call between scripts have issues.

The best workaround for me is to use subflow step and to use calendar step in the first script if it is possible.

Good luck  

[tannerezell]

Does anyone have a system this occurs regularly on? Might be possible to fix this in scripting..

[Nathan Grovhoug]

Happens on my script everytime. 

[tannerezell]

If you can replicate in a controlled environment (with reactive debug), then set your Select resource step to not auto connect, under the connect branch add the connect step.

Add a contact variable (name: contact, type: Contact, value: null) to your script and set it anywhere at the start of the script using the Get Trigger Info step.

Finally, reactive debug the script and stop right before the connect to agent happens (Connect step). Go to the menu bar, Debug -> Evaluate:

run this:

{

java.lang.reflect.Field ciscoCallField = contact.getClass().getDeclaredField("ciscoCall");
ciscoCallField.setAccessible(true);
com.cisco.jtapi.extensions.CiscoCall ciscoCall = (com.cisco.jtapi.extensions.CiscoCall)ciscoCallField.get(contact);
return ciscoCall.getConnections();

}

and let me know the results. 

[Anthony Holloway]

It happens consistently. You can even try this in devnetsandbox.cisco.com.
https://community.cisco.com/t5/contact-center/finesse-displays-number-of-participants/m-p/4105225/highlight/true#M11088

[tannerezell]

I’ll see what I can find out

[tannerezell]

Accidentally posted to the wrong thread but here we go anyway:

I can confirm this isn't a JTAPI issue. As far as I can tell, this appears to be a bug in the CTI engine used by finesse. The UI is receiving information that it should have two participants plus the agent, which obviously is wrong.

Essentially the first CTI Port from the initial call shows dropped but the second CTI Port (after the call redirect) remains active, according to Finesse. However this is not accurate according to the JTAPI subsystem which shows the CTI Port with no active connections or calls.

This leads me to assume the issue exits in the CTI engine underlying finesse, and quite possible a race condition could be causing the issue, likely in the call observers and event handling. 

This is all a guess, I haven't dug into that system and I'm probably not going to at this point either. I can only assume the following is happening (all assumptions):

1. Initial call comes in, JTAPI Call Contact with the first CTI Port is created, an event is fired when the caller is accepted, caller is connected to CTI Port

2. through script logic, the caller is redirected, the first CTI Port disconnects and the disconnect event message is received by the handler

3. same call contact is now connected to the new CTI Port and a new event is fired, call added to contact. I don't think the disconnects are properly being processed.a 

3a. steps 2-3 can repeat as many times as you want

4. the caller will see the CTI Ports involved as part of the participants in finesse., despite there being no calls or connections on any of the CTI Ports.

I suspect the handler for these messages stops processing after the first disconnect event.

You can chain these for fun and to terrifying effect: 

No workaround at the script level is possible I'm afraid :(. What a disaster.