Agent remaining in the TALKING state for more than 20 sec after the inbound call disconnects

[vbashin]

Hello -

We are testing the multi-agent virtual console application that makes the Finesse agents logging in, ready, answering the incoming calls and telling the Finesse to disconnect them

We have the automatic  Hammer dialer that places the calls to the CUCM queue and another Hammer simulating the Agent Cisco Skinny phones that receives the calls.

We tested two scenarios:

1. A call gets disconnected by the dialer phone
2. A call disconnect gets initiated by our virtual agent console product (VA)

In first case the agent is mostly going through the following state transitions:

                2017-12-12T:22:38:51:852   | ........Agent: 50003  State: RESERVED stateChangeTime: 2017-12-13T04:38:51.856Z reasonCodeId:  reasonLabel:

                2017-12-12T:22:38:51:930   | ........Agent: 50003  State: ALERTING  Dialog: 274739935   DNIS:1001008003  fromAddress:8572881483 event: POST

2017-12-12T:22:38:51:930   |     ….. Publish to Core:{"cmd":"ANSWER","data":"{\"userid\":\"50003\",\"password\":\"1234\",\"extension\":\"1001008003\",\"dialogid\":\"274739935\"}"}

                2017-12-12T:22:38:53:258   | ........Agent: 50003  State: TALKING stateChangeTime: 2017-12-13T04:38:53.273Z reasonCodeId:  reasonLabel:

                2017-12-12T:22:38:53:274   | ........Agent: 50003  State: ACTIVE  Dialog: 274739935   DNIS:1001008003  fromAddress:8572881483 event: PUT

                2017-12-12T:22:39:57:900   | ........Agent: 50003  State: DROPPED  Dialog: 274739935   DNIS:1001008003  fromAddress:8572881483 event: DELETE

                2017-12-12T:22:39:57:916   | ........Agent: 50003  State: READY stateChangeTime: 2017-12-13T04:39:57.906Z reasonCodeId:  reasonLabel:

…and then back to RESERVED

                2017-12-12T:22:39:58:369   | ........Agent: 50003  State: RESERVED stateChangeTime: 2017-12-13T04:39:58.372Z reasonCodeId:  reasonLabel:

The problem is that the Agent remains in the TALKING state for quite some time (for more than 20 sec) after the dialer terminates a call, then the agent switches to the READY state. (That creates a problem since a dialer starts placing a new wave of calls while the agents are still in the TALKING state from a previous wave) .

I wonder what might be causing such behavior ? Could it be because of the Hammer–receiver that simulates the agent Cisco phone still staying in a connected state with the UCCX/CUCM?

Could it be that the UCCX would not permit the agent to switch to the READY state even after a dialer disconnects a call so only the agent could propel himself to the next state – either by hanging his softphone or by releasing a call from the Agent Console?

In the 2^nd scenario , when the VA sends DROP commands to the Finesse, the agent immediately after that switches to the next state (READY) . Apparently that DROP command almost instantly tells both the dialer and the agent phone to disconnect.

Could you please explain the UCCX behavior for the 1^st scenario?

The Finesse logs are not available since the testing was performed at a customer site.

Thanks,

Vladimir Bashin

[dekwan]

Hi,

Just wondering, where are the logs you provided coming from? Is that your app logs which is logging the Finesse events? Finesse just receives the call and agent state events from UCCX. From the logs you provided, I do see that big gap between the drop and the ready, but where these logs come from makes a difference.

Having the CTI and Finesse logs is important to debug this issue. Without it, it is hard to figure out. The Finesse logs will determine if the delay is within Finesse and the CTI logs will determine if the delay is within CCX. There isn't anything I can explain without that information.

Thanx,

Denise

[vbashin]

Thanks Denise –

The logs are from our application – the only place from where we’re allowed to collect the logs . Thought of some generic considerations based on your expertise…

Regards,

Vladimir

[vbashin]

Hi Denise ,

1) We finally were able to get Finesse logs from a customer site (attached) but they are covering a slightly different scenario that does not include our Virtual Agent Client – anyway, could you please comment on my log analysis below?

Here is the test description:

Made 4 calls from 5:16-5:18

Call No 1 ANI: 2243159993: goes to agent 123456/extension 1101101999 Call no 2 ANI: 8473971912: in the queue.

Caller drops Call No 1.

Call No 2 goes to same agent.

Caller drops call no 2.

Repeated same as above with agent dropping both calls vs. Caller.

That how I interpret the logs –

In the test captured in the logs regardless whether the caller or the agent disconnects a call, from the Finesse perspective it seems the call always gets disconnected by the agent @ x1101101999 - Is that a correct statement?

See a typical pattern below:

That’s for the direct call :

0000198553: 10.162.100.161: Dec 17 2017 17:18:12.423 -0600: NodeId=/finesse/api/User/123456/Dialogs][Payload=

2) And maybe you could still provide some general considerations on the original issue that I posted on 12/13/17 ? – it would help us a lot….

In short -

the Agent remains in the TALKING state for quite some time (for more than 20 sec) after the dialer terminates a call, then the agent switches to the READY state. (That creates a problem since a dialer starts placing a new wave of calls while the agents are still in the TALKING state from a previous wave) .

I wonder what might be causing such behavior? - Could it be because of the Hammer–receiver that simulates the agent Cisco phone still stays in a connected state with the UCCX/CUCM for a little longer after the dialer disconnects a call?

Could it be that the UCCX would not permit the agent to switch to the READY state even after a dialer disconnects a call since only the agent could propel himself to the next state – either by hanging his softphone or by releasing a call from the Agent Console?

Thanks,

Vladimir Bashin

[dekwan]

Hi Vladimir,

#1. Based off of the logs, UCCX is telling Finesse that 110110199 is the one releasing from the call first. Whether that is true or not, Finesse only knows what it gets from UCCX. From what you are saying, that is incorrect, so you would need to chase that down on the UCCX side.

#2. I really can't make any comment on the original issue. There are no logs to make any conclusions or considerations. There is nothing to work with. You have to have either Finesse logs or CTI logs. In the logs you provided for #1, I don't see this issue.

Thanx,

Denise

[vbashin]

Thank you very much, Denise – your #1 analysis matches my finding.

Regards,

Vladimir Bashin