cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4542
Views
0
Helpful
1
Comments
cdnadmin
Level 11
Level 11
This document was generated from CDN thread

Created by: John Wagner on 11-04-2011 06:15:06 PM
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

Subject: RE: New Message from John Wagner in Computer Telephony Integration Object S
Replied by: David Lender on 12-04-2011 08:47:25 AM
For information regarding reason code 50002, see the UCCE Reporting guide



http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/enterprise_reporting/reporting7_2/user/guide/ICMReportingGuide721.pdf

or



http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/ipcc_enterprise/ipccenterprise8_0_1/user/guide/icmcc80rpg.pdf





You do not need to handle heartbeats in your application.  The CIL handles failure and failover.



Suggest you determine why UCCE components in your environment are failing.



You may want to open a Service Request with Cisco for each of your issues.  Be sure to first duplicate them with the out of box CTIOS Agent Desktop before opening the TAC case.

Subject: RE: New Message from John Wagner in Computer Telephony Integration Object S
Replied by: John Wagner on 13-04-2011 09:41:01 AM
David, thank you very much for the information.  We're working with TAC now to see if they can isolate what is going on.  It looks like we may have some intermittent communication problems with the PGs.  I'll update this thread when they figure out what is causing it in case anyone else runs into something like this.

Thanks,
John

Subject: RE: New Message from John Wagner in Computer Telephony Integration Object S
Replied by: ATIF TANVEER on 31-08-2012 04:50:36 AM
Dear John,
 
Did you find the solultion for this issue. I am having the same issue for last 6 months but still Cisco could not find root casue. 
 
My enviroment is UCCE 8.5 with Siebel connector 
getting cti failure in CUIC reports with error code 50002
 
 
Regards,
Atif

Subject: RE: Error 50002 and agents stuck in "Talking"
Replied by: Hina Jabeen on 29-09-2013 03:27:32 AM
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


Dear John,

Did you get any solution for this?

Regards,
Hina

Subject: RE: New Message from John Wagner in Computer Telephony Integration Object S
Replied by: Dawn Paolino on 22-10-2013 09:06:43 AM
Hello John,

Where you ever able to find out what was causing the Intermittent communication loss to the PG's.  We are having the same exact issues.  We have looked at our Network intensively and added a larger tunnel.  We have locations in 3 different states, I am located in RI and our PG is located in TX.  We have our back up PG here in RI.  We seem to be getting a great deal of 50002 and 50003 error codes and we also have the client on the desktop go gray as well.  We have to reset the agent mac address in the PGuser on the Call Manager to get the agent back up and working again.


Please see the attched spreadsheet with 50002 and 50003 errors and the amount of time is what is bring much attention to upper management.

Any help you can provide would be greatly appreicated.

Dawn
Comments
amanbasra
Level 1
Level 1

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.

o7 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.
o1 out of the 14 users was in ‘Not Ready – Internal Meeting’ state
o3 out of the 14 users was in ‘Talking’ state
o2 out of the 14 users was in ‘Ready’ state
o1 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.

lohjintiam harish.ruparel amanbasra gvkdebest

Getting Started

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:

Quick Links