Why do logout of agents takes too long sometimes?

[mario.covarrubias]

Hi,

I hope someone can help us.

We implemented Cisco PCCE 10.5, which is integrated with a third party application thanks to web services. These web services use Finesse APIs in order to make the necessary changes in Contact Center, like LOGIN and LOGOUT of agents, and also CHANGE OF AGENT STATE when it's necessary, among other Finesse APIs that are used.

Right now we are facing one issue with the LOGOUT process. Sometimes, the LOGOUT goes smoothly, finishing in an average time of 0.050 seconds. However, there are times when it takes up to 4 or 5 seconds to complete, and we don't really now why this happens.

I attach a log file with an example of an agent with ID = 33, which did a LOGOUT that took about 5 seconds to complete.

Thanks in advance for your help.

Mario

[dekwan]

Hi Mario,

For the log file you attached, the logout request you highlighted was actually a GET for the logout reason codes and not the logout request:

0012760155: 10.10.5.112: Dec 13 2016 06:37:14.458 -0700: %CCBU_http-8080-9-6-REQUEST_START:

%[method_name=GET][parameter_name={ category=[LOGOUT],

}][resource_name=/User/33/ReasonCodes][usr=33]: Request start

In the logs, I only see three API requests:

1) GET NOT_READY reasoncodes:

0012760145: 10.10.5.112: Dec 13 2016 06:37:14.444 -0700: %CCBU_http-8080-9-6-REQUEST_START: %[method_name=GET][parameter_name={ category=[NOT_READY], }][resource_name=/User/33/ReasonCodes][usr=33]: Request start

2) Set to NOT_READY:

0012760149: 10.10.5.112: Dec 13 2016 06:37:14.453 -0700: %CCBU_http-8080-9-6-API_REQUEST: %[REQUEST_URL=User/33][agent_id=33][request_identifier=null][request_method=user.PUT][request_ parameters= state:NOT_READY]: Request from client to webservice api

3) GET LOGOUT reasoncodes:

0012760155: 10.10.5.112: Dec 13 2016 06:37:14.458 -0700: %CCBU_http-8080-9-6-REQUEST_START:

%[method_name=GET][parameter_name={ category=[LOGOUT],

}][resource_name=/User/33/ReasonCodes][usr=33]: Request start

As for #2 of setting to NOT_READY, I see that Finesse makes the request to the CTI server:

0012760151: 10.10.5.112: Dec 13 2016 06:37:14.455 -0700: %CCBU_pool-6-thread-179-6- MESSAGE_TO_CTI_SERVER: %[cti_message=Invoke id :1446329 , agentstate : 2, workmode : 0, reason code: 30, forceflag :1, agentcapacity: 0, agentext: 11861, agentid: 33, supervisorid: null][cti_message_name=SetAgentStateReq]: Message going to the backend cti server

It isn't until 5 seconds later that the CTI is sending back an event:

0012760200: 10.10.5.112: Dec 13 2016 06:37:19.373 -0700: %CCBU_CTIMessageEventExecutor-0-6- DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIAgentStateEvent [skillGroupState=1 (LOGOUT), stateDuration=0, skillGroupNumber=46320, skillGroupPriority=0, agentState=2 (NOT_READY), eventReasonCode=40, numFltSkillGroups=0, CTIClientSignature=Finesse, agentID=33, agentExtension=11861, agentInstrument=11861, agentID_Long=null, duration=null, nextAgentState=null, fltSkillGroupNumberList=[], fltSkillGroupIDList=[], fltSkillGroupPriorityList=[], fltSkillGroupStateList=[]]CTIMessageBean [invokeID=null, msgID=30, timeTracker={"id":"AgentStateEvent","CTI_MSG_RECEIVED":1481636239373,"CTI_MSG_DISPATCH":148163 6239373}, msgName=AgentStateEvent, deploymentType=CCE]][cti_response_time=0]: Decoded Message to Finesse from backend cti server

And for some reason, it gets logged out (without a request or presence driven logout):

DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIAgentStateEvent [skillGroupState=1 (LOGOUT), stateDuration=0, skillGroupNumber=1369832, skillGroupPriority=0, agentState=1 (LOGOUT), eventReasonCode=40, numFltSkillGroups=0, CTIClientSignature=Finesse, agentID=33, agentExtension=11861, agentInstrument=11861, agentID_Long=null, duration=null, nextAgentState=null, fltSkillGroupNumberList=[], fltSkillGroupIDList=[], fltSkillGroupPriorityList=[], fltSkillGroupStateList=[]]CTIMessageBean [invokeID=null, msgID=30, timeTracker={"id":"AgentStateEvent","CTI_MSG_RECEIVED":1481636239373,"CTI_MSG_DISPATCH":148163 6239374}, msgName=AgentStateEvent, deploymentType=CCE]][cti_response_time=1]: Decoded Message to Finesse from backend cti server

What is the agent's state when it is being requested to go NOT_READY? Is it going from NOT_READY -> NOT_READY? This is not a supported agent state transition (since the reason code isn't changing). If not, then this seems to be a product issue and you should open a TAC case.

Thanx,

Denise

[mario.covarrubias]

Hi Denise,

I actually detected some of the things you mentioned:

• The LOGOUT highlighted was a GET and not a PUT, that's why I believed it wasn't actually the LOGOUT, but for me it meant that the LOGOUT process was starting somehow.
• There is no actual PUT request for LOGOUT, even though the agent does log out of the system. That seemed strange to me, what I believe is that for some reason there are some actions that the log doesn't register sometimes. I don't know if I'm right about that.
• The 5 second time span that happens between the request sent to CTI Server and the moment it sends back an event, although I don't know why this occurs.

About your question for the NOT_READY state. Because of the third party application, we were forced to implement, before asking Finesse to LOGOUT, to change the agent state to NOT_READY, because the logout in the application can occur when the agent is in READY state, so what we did is, with our web service, change the state to NOT_READY (assigning a Reason Code), and after that, ask for the LOGOUT. This way, even if the agent is in NOT_READY state, because we assign a different ReasonCode, it should be allowed for the agent to LOGOUT after that.

This is the way is implemented and It works like that for all agents (the same process occurs for all LOGOUTS). What puzzles me is that the 4 or 5 seconds time doesn't happen all the time, and it has happened with different agents and extensions, even if these same agents and extensions can do a fine LOGOUT in other times. For example, the same agent in the LOG example (ID=33), with the same extension (11861), did a LOGOUT 1 hour before the one I'm reporting, and it worked fine (lasted just 0.044 seconds to finish).

I'm really puzzled by this right now, because I don't know what could be causing this.

Mario

[dekwan]

Hi Mario,

From the logs you provided, I don't see any request to go LOGOUT and I also don't see any presence driven logouts. I am not sure why the CTI Server (PCCE) is sending the logout request. You would need to look at the CTI/PCCE logs to figure that out.

As far as the 5 second time span for the NOT_READY request, I suggest opening a TAC case for that.

For the NOT_READY state, I would suggest that you do a GET User to see if the agent is in NOT_READY state before logging out. If they are in READY state, only then you will make the request to go NOT_READY. If they are in talking state, you need to handle that situation too.

It might be that there is something wrong going on within PCCE. From the logs you sent me, Finesse sends the request to CTI right away, but it is the CTI that takes a long time to send stuff back. That points to an issue on the CTI side. Like I said, I would suggest taking a look at those logs or opening a TAC case.

Thanx,

Denise

[mario.covarrubias]

Hi,

We have been keeping track of the case, and I would like to ask something... As part of the change agent state process (in this case to NOT_READY), or as part of the LOGOUT process, does the CTI Server (or Contact Center in general) do any connection and/or validation with the phone extension?

The question is because we detected something... and I would like to explain the case.

Cisco Packaged CCE is implemented in one city A, but there are phone extensions connected to it from three different cities (A, B and C). Cities B and C are connected to city A with fiber optic, so in theory, the network latency should be low.

What we detected is that most of the cases when the 5 second time span occurs is in one of the other cites, let's say: City C, while there are fewer cases of this problem in City B, and isolated (very few) cases in City A (where PCCE is installed). The situation has occured in all 3 locations, but mainly in one of them, being a location in which there is remote connection to PCCE.

I don't know if, as part of the process to change the agent state or LOGOUT, PCCE does some kind of connection to the IP phone extension, and that communication could be the reason the time span because there is some king of network latency occurring.

Is there a possibility this could be the cause of the problem?

Thanks,

Mario

[dekwan]

Hi Mario,

Unfortunately I don't know the answer to your question, so I would suggest that you post the question to the PCCE forum.

Thanx,

Denise