Finesse going from Ready to Not Ready State during active call auto issue

[Remon Adel]

Hello,
we have faced an issue with some of our agents on finesse  .
some agent when they are going from ready to unready auto during active calls .
also this case happens when they are ready and no active calls.
be informed this happens to some agents not all ,and we set service parameters to let agent ready even after unanswered calls.

UCCX v 11.0 

agent DN :7645 

 use this below URL to download  these logs:

• Finesse
• Engine
• Notification Service
  https://tinyurl.com/ybge4uvt

Thanks for your help

[Mark Swanson]

I have a couple of questions;

1. What's the exact version of CUCM and UCCX?

2. What type of device (i.e. 7965, 7975, 8841, etc.) do agents have? SCCP or SIP? Firmware version?

3. Are agents using unsupported phone actions/features (i.e. DND, iDivert, etc.)? Do they have access to them? Search for 'unsupported actions'...

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_11_0/release/docs/UCCX_BK_R7697E6E_00_release-notes-for-uccx-solution/UCCX_BK_R7697E6E_00_release-notes-for-uccx-solution_chapter_01.html

4. Are agents using unsupported configurations on the device; for example, busy trigger, same DN on multiple devices, etc.? Search the same doc for 'unsupported configurations'.

5. Do agents notice this problem when they move to another workstation/phone? Just make sure the agent's extension doesn't reside on multiple devices.

[Remon Adel]

Hello Mark,

1. What's the exact version of CUCM and UCCX? CUCM 11.5 & UCCX 11.0

2. What type of device agents have? SCCP or SIP? Firmware version? Cisco Jabber Sip

3. Are agents using unsupported phone actions/features (i.e. DND, iDivert, etc.)? Do they have access to them? NO

4. Are agents using unsupported configurations on the device; for example, busy trigger, same DN on multiple devices, etc.? no

5. Do agents notice this problem when they move to another workstation/phone? after agent moved to another workstation r=this issue fixed but still happens randomly with other agents but not at all time

[Mark Swanson]

Try running the Agent State Detail Report after one of these events and post the results. Please include a rough timeline when the agent experienced this problem. Also, check the dependency records within CUCM and make sure there's not multiple devices or user device profiles assigned to the agent(s). What type of device do agents have; device model?

[Anoop Krishnan]

Hi Remon, 

I had seen this issue happening with some of my Agents, please do try the following 

In the UCCX GUI go to Subsystems -> Cisco Unified CM Telephony -> Cisco Unified CM Telephony Control Group and select the group you are using in your application.

At the bottom of the screen hit the "Show More..." button and fill in the correct Device Pool and DN Calling Search Space.  This modifies the CTI ports on the call manager that are used to transfer the calls to your agents.  Without the proper Pool and CS, the agent phones go into a "reserve/not ready' state.

I had followed the instructions as per this thread 

Agent State go to Not Ready while in a call

Regards, 

Anoop 

[deepakcn · Accepted solution]

Hi,

The below is the reason why the agent was toggling between ready and not ready:

Evidence:

We see the agent in talking state :

0002106735: 10.1.20.250: Nov 20 2017 13:14:28.099 +0200: %CCBU_CTIMessageEventExecutor-0-6-DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIAgentStateEvent [skillGroupState=4 (TALKING), stateDuration=0, skillGroupNumber=-1, skillGroupPriority=0, agentState=4 (TALKING), eventReasonCode=0, numFltSkillGroups=0, CTIClientSignature=null, agentID=Seat-55, agentExtension=7645, agentInstrument=null, agentID_Long=Seat-55, duration=null, nextAgentState=3, fltSkillGroupNumberList=[], fltSkillGroupIDList=[], fltSkillGroupPriorityList=[], fltSkillGroupStateList=[]]CTIMessageBean [invokeID=null, msgID=30, timeTracker={"id":"AgentStateEvent","CTI_MSG_RECEIVED":1511176468099,"CTI_MSG_DISPATCH":1511176468099}, msgName=AgentStateEvent, deploymentType=CCX]][cti_response_time=0]: Decoded Message to Finesse from backend cti server

After the call is over, the agent selects not ready reason code 35(custom) and is now in not ready state :

0002107508: 10.1.20.250: Nov 20 2017 13:16:17.324 +0200: %CCBU_CTIMessageEventExecutor-0-6-DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIAgentStateEvent [skillGroupState=2 (NOT_READY), stateDuration=0, skillGroupNumber=-1, skillGroupPriority=0, agentState=2 (NOT_READY), eventReasonCode=35, numFltSkillGroups=0, CTIClientSignature=null, agentID=Seat-55, agentExtension=7645, agentInstrument=null, agentID_Long=Seat-55, duration=null, nextAgentState=null, fltSkillGroupNumberList=[], fltSkillGroupIDList=[], fltSkillGroupPriorityList=[], fltSkillGroupStateList=[]]CTIMessageBean [invokeID=null, msgID=30, timeTracker={"id":"AgentStateEvent","CTI_MSG_RECEIVED":1511176577324,"CTI_MSG_DISPATCH":1511176577324}, msgName=AgentStateEvent, deploymentType=CCX]][cti_response_time=0]: Decoded Message to Finesse from backend cti server

Now the agent manually changes the state from Not ready to Ready as we see a message sent from the client to webservice api in a form of a PUT request to change the state to ready:

0002117785: 10.1.20.250: Nov 20 2017 13:37:12.191 +0200: %CCBU_http-bio-8082-exec-17-6-API_REQUEST: %[REQUEST_URL=User/Seat-55][agent_id=Seat-55][requestId=93f5752f-119b-470d-87e7-b2d9082cb017][request_method=user.PUT][request_parameters= state:READY]: Request from client to webservice api

The agent then moves from Ready to Not Ready due to reason code 32759 = Phone crash/down/unregistered:

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_9_0/user/guide/UCCX_BK_UE5BE47D_00_uccx-historical-reports-ug/UCCX_BK_UE5BE47D_00_uccx-historical-reports-ug_appendix_0111.html#UCCX_TP_P97E849F_00

PHONE_DOWN
Reason Code: 32759
State: Not Ready
The system issues this reason code if the agent’s phone crashes and that agent is placed in the unavailable state.

0002117870: 10.1.20.250: Nov 20 2017 13:37:40.706 +0200: %CCBU_CTIMessageEventExecutor-0-6-DECODED_MESSAGE_FROM_CTI_SERVER: %[cti_message=CTIAgentStateEvent [skillGroupState=2 (NOT_READY), stateDuration=0, skillGroupNumber=-1, skillGroupPriority=0, agentState=2 (NOT_READY), eventReasonCode=32759, numFltSkillGroups=0, CTIClientSignature=null, agentID=Seat-55, agentExtension=7645, agentInstrument=null, agentID_Long=Seat-55, duration=null, nextAgentState=null, fltSkillGroupNumberList=[], fltSkillGroupIDList=[], fltSkillGroupPriorityList=[], fltSkillGroupStateList=[]]CTIMessageBean [invokeID=null, msgID=30, timeTracker={"id":"AgentStateEvent","CTI_MSG_RECEIVED":1511177860705,"CTI_MSG_DISPATCH":1511177860706}, msgName=AgentStateEvent, deploymentType=CCX]][cti_response_time=1]: Decoded Message to Finesse from backend cti server

After toggling between ready and not ready due to phone down issue, the agent sends a logout request to the webservice api and logs out of finesse desktop:

0002118925: 10.1.20.250: Nov 20 2017 13:41:05.475 +0200: %CCBU_http-bio-8082-exec-4-6-API_REQUEST: %[REQUEST_URL=User/Seat-55][agent_id=Seat-55][requestId=a77d5a54-f621-4684-91a1-254d10535240][request_method=user.PUT][request_parameters= state:LOGOUT]: Request from client to webservice api

Conclusion :

Kindly check and make sure there are no network issues with the phone. You can check the Event viewer application and system logs from CUCM to track down the reason for the phone going down. The CCX engine logs is filled with 32759 events for this agent :

++++ Agent is in ready state  :

Nov 20 14:18:49.571 EET %MIVR-SS_RM-7-UNK:Rsrc: Seat-55 New State:AVAILABLE Old State:IN_SESSION Reason code:0

++++ System pushes the agent state from ready to not ready due to reason code 32759 as it suspects a phone crash/down situation

Nov 20 14:18:49.587 EET %MIVR-SS_RM-7-UNK:Rsrc: Seat-55 New State:UNAVAILABLE Old State:AVAILABLE Reason code:32759

+++ The system issues 32756 when the agent’s phone comes up after it has been through a Phone Down state however the agent still remains in not ready status

Nov 20 14:18:49.587 EET %MIVR-SS_RM-7-UNK:Rsrc: Seat-55 New State:UNAVAILABLE Old State:UNAVAILABLE Reason code:32756

Thanks and Regards,

Deepak Nair

[SteveH1]

Hi Deepak, this is a very good analysis, thankyou. Could you please let me know what logs you derived this evidence from ?  Is it from the "send Error Report " initiated by the agent or other logs on the UCCX system please ?