on 01-24-2014 02:09 PM
John Wagner:We are developing a custom desktop based on the C# Combo desktop and have run into some odd errors. First, we are seeing a problem where agents' buttons become disabled not allowing them to do anything on the desktop. This is often coupled with seeing the agent set to a not ready state in the agent state trace report with a reason code of 50002. The 50002 errors have been occurring in both custom and out-of-the-box desktops, but I am seeing an increase in the number of agents getting the error in the custom version. Additionally, in the CTIOS logs generated by the application, I see a large number of errors for the following:
04/11/2011 16:29:33.6701 CTIObject.OnEvent: Received Event: eOnHeartbeat
Arguments: (EventTime:1487211750)
04/11/2011 16:29:33.6701 SoftphoneForm.OnEvent: Event received with unrecognized EventID: eOnHeartbeat
I am assuming this means that I need to add a handler for the eOnHeartbeat event, but what do I need to do with this event? Is this something the CTI server is expecting a response to, which could maybe account for the increase in 50002 errors?
Also, another issue I am seeing, which may or may not be related the first is agents who are getting stuck in a Talking state and not being able to hang up. All buttons on the desktop get disabled like the above error, but there is nothing in the logs indicating a problem. It seems very similar to the CSCsk90795 bug, but we are running 7.5(9), which this bug should be fixed in as I understand. Is it possible that there is a client side change that I need to implement for this bug that may not have been included in the C# Combo sample app?
Neither of these issues are hugely widespread, and nothing showed up in testing until we added all 500 agents into the mix, so I am not sure, but am assuming that this is an application issue. One other thing that may or may not be related is that we implemented a custom wrap up code functionality requiring a wrap up code selection after each call. I do not think it is related, but figured I would mention it in case it is.
I know that the sample apps do not handle all of the different events in each environment, but is there someplace I can go to determine which ones I need to handle, and which ones I can ignore?
Any assitance will be very much appreciated.
Thanks,
John
Is there any information on how this problem was resolved? A similar case is being encountered here. We have a custom CTIOS-based application for Cisco UCCE 10.5.1 (with two PGs) in which some agents at some sites are getting involuntarily set to 'Not Ready' with a Reason Code of 50002 showing up in the CUIC dashboard, which means "A CTI OS component failed, causing the agent to be logged out. This could be due to closing the agent desktop application, heartbeat time out, a CTI OS Server failure, or a CTI OS failure." However, the CTIOS-based app is showing a 'Ready' status for these agents. It does not happen for all the agents. Below is an example of one of the issues which affected 7 agents in a site with 14 agents; all other sites on the same CTIOS PG were not affected at that time. There are a few agents who are using the standard CTIOS desktop, but those are less than 1% and because the issue does not affect all of the custom CTIOS-based application agents, it cannot be said that the issue is limited to the custom CTIOS-based agents.
o | 7 out of the 14 users were affected by the ‘Not Ready – System Error’ – from the ‘Duration in Current State’ (00:01:56 for 6 users, and 00:00:52 for one user) , I can see that the System Error problem started with 6 agents, and then another 1 agent was affected. |
o | 1 out of the 14 users was in ‘Not Ready – Internal Meeting’ state |
o | 3 out of the 14 users was in ‘Talking’ state |
o | 2 out of the 14 users was in ‘Ready’ state |
o | 1 out of the 14 users was in ‘Work Ready’ state |
Could this be due to Cisco Bug CSCuv50791, a different issue, or a non-Cisco issue? From what we have seen in the CTIOS logs, the agents affected were in talking mode, followed by work ready (wrap) mode, and then directly turned to Not Ready (System Error) state after the 15-second wrap-up timer expired (should have been set to Ready state.) As per the bug report for ID CSCuv50791, the affected releases are 10.5.1 and 10.5.2. The issue is fixed by ICM 10.5.2 ES3 which is specifically for bug ID CSCuv50791.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: