http://developer.cisco.com/c/message_boards/find_category?p_l_id=&mbCategoryId=1053310 2013-05-22T21:04:51Z 2013-05-22T21:04:51Z Andrey Fandeev http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15409797 2013-05-20T09:03:43Z 2013-05-20T09:03:43Z

The CTI Server Simulator is part of CTIOS Client SDK installation. You can find it in "C:\Program Files\Cisco Systems\CTIOS Client\CTIOS Tools" folder after CTIOS SDK installation. This CTI Server simulator works with CTI protool (GED-188) version 8.0.

Andrey Fandeev 2013-05-20T09:03:43Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=14374063 2013-04-17T20:30:28Z 2013-04-17T20:30:28Z

I have not heard of CtiSim. There is no simulator for CTI Server available for download.

David Lender 2013-04-17T20:30:28Z David Seeba http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=14363630 2013-04-17T18:53:52Z 2013-04-17T18:53:52Z

I've seen some references to a CtiSim executable that simulates the CTI Protocol. This would allow me to get started on CTI without having to interface directly with UCCE (at least until we have some basic functionality). I've only seen references to this in older documentation. Is this still available? If so, where would one find it to download? Thanks!

David Seeba 2013-04-17T18:53:52Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=14010508 2013-04-08T19:04:25Z 2013-04-08T19:04:25Z

I do not know how you log an agent into the hardphone unless you have the IPPhoneControlService from Custom Engineering. UCCE does not support logging in an agent from a hardphone. If it is a TDM ACD then the SYSTEM events are not generated. If its extension mobility and you are just logging into an extension, I do not know what events you can expect when the phone is logged in or out via Extension mobility I will have to escalate that question.

David Lender 2013-04-08T19:04:25Z Petrus Buiquy http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=14004946 2013-04-08T18:27:59Z 2013-04-08T18:27:59Z

Yes I log in and out of the hard phone and observe what we see in the log. I did not use CTI at all. We just want to see what kind of events would be generated if agent logs in/out of the hard phone.

Petrus Buiquy 2013-04-08T18:27:59Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=13999596 2013-04-08T17:52:30Z 2013-04-08T17:52:30Z

When you say you log out of the phone do you mean with Extension Mobility? Logging an agent out using CTI Server to set Agent State to LOGOUT should not result in a System Event with Id = SYS_INSTRUMENT_OUT_OF_SERVICE. I believe logging out of the hardphone using Extension Mobility will. The other time you will get SYS_INSTRUMENT_BACK_IN_SERVICE is after the hardphone phone has been reset.

David Lender 2013-04-08T17:52:30Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=14000505 2013-04-08T17:11:13Z 2013-04-08T17:11:13Z

Is this for UCCE or a TDM ACD? I suggest you open a Service Request and attach a full set of logs (JGW or PIM, OPC, CTI Server) so that I can escalate it as I do not know why you are not receiving the SYS_INSTRUMENT_BACK_IN_SERVICE SystemEventID.

David Lender 2013-04-08T17:11:13Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=13993121 2013-04-08T14:21:30Z 2013-04-08T14:21:30Z

Yes you can use protocol 6 with ICM 8.5 You specify the version you want to use in the OPEN_REQ.

David Lender 2013-04-08T14:21:30Z Goran Selthofer http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=13958252 2013-04-06T13:53:31Z 2013-04-06T13:53:31Z

David, what about Protocol 6? Is that supported with ICM 8.5 ? or the same as for 7 stands for 6 as well ?

Goran Selthofer 2013-04-06T13:53:31Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12877140 2013-03-11T15:40:58Z 2013-03-11T15:40:58Z

I refer you to the CTI Server Protocol guide section on Call Identification which states A valid CTI Server application can make no assumption about the content or format of a ConnectionDeviceID. CTI Server uses the CSTA method of identifying calls. A numeric ConnectionCallID identifies a call; each connection of a device to that call is identified by a ConnectionDeviceID string and an enumerated ConnectionDeviceIDType value (see Figure 3-3). All call related messages identify the ConnectionCallID as well as the ConnectionDeviceIDType and ConnectionDeviceID of the call connection that is the subject of the event. A ConnectionDeviceID uniquely identifies a call connection. However, it cannot directly identify the connected device; use other event message fields for that purpose. In some cases, the ConnectionDeviceID may simply be the ID of the connected device, the connected deviceID with additional identifying data included, or a string that does not contain the deviceID at all. A valid CTI Server application can make no assumption about the content or format of a ConnectionDeviceID. Occasionally, both the ConnectionDeviceID and the numeric ConnectionCallID are required in order to properly identify the subject call. This occurs when the ACD uses the ConnectionCallID value from an ACD call as the ConnectionCallID value for any related consultative calls. This poses two particularly significant requirements for applications: they must be able to keep track of two calls with the same numeric ConnectionCallID value, and they must be able to decide which of the two calls is being referenced by any given call event message. These requirements are relatively easy to implement by keeping track of the ConnectionDeviceIDs associated with each call. The call that has a ConnectionDeviceID that matches the ConnectionDeviceID provided in the call event message is the call that is the subject of the event. The only difficult case is determining which call is the subject when a new call connection is created. For this case, the following rule applies: When more than one call with the same ConnectionCallID value exists, the connection being created by a CALL_ESTABLISHED_ EVENT shall apply to the call that does not yet have a destination connection established

David Lender 2013-03-11T15:40:58Z Dale Gantous http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12876100 2013-03-11T14:56:48Z 2013-03-11T14:56:48Z

You only specify a ConnectionDeviceID if you start a monitor for a call. If you want to monitor a device, you specify a DeviceID.   It would be highly useful to know which ConnectionDeviceIDs in call events refer to the device being monitored (as opposed to the other devices involved in the call). This is what I'm trying to figure out. Any ideas?

Dale Gantous 2013-03-11T14:56:48Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12873622 2013-03-11T14:41:58Z 2013-03-11T14:41:58Z

You can specify the ConnectionDeviceID in the MONITOR_START_REQ. I know of no way to determine which connectiondeviceid refers to the monitored device.

David Lender 2013-03-11T14:41:58Z Dale Gantous http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12811129 2013-03-08T21:27:59Z 2013-03-08T21:27:59Z

When creating a peripheral monitor on a device, how can one determine the ConnectionDeviceID (and ConnectionDeviceIDType) that refers to the device being monitored?   According to the documentation, the ConnectionDeviceID is not necessarily the same as the DeviceID.   We need to know which ConnectionDeviceID refers to the monitored device (as opposed to other devices involved in the call) in order to make sense of all the call messages being monitored for the particular device.   I was hoping one of the SNAPSHOT_ or QUERY_ calls would give us this information, but I don't see it.   Thanks for any help...

Dale Gantous 2013-03-08T21:27:59Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12713485 2013-03-06T19:56:58Z 2013-03-06T19:56:58Z

Yes, you can continue to use protocol version 7. Note however that you might receive new Calltypes over what you received for in ICM 6. Calltype additions are not considered a change to the protocol, since they are values. For changes in the protocol between version 6 and 14 or 15, see the version 15 or 16 protocol guide on CDN here http://developer.cisco.com/web/ctisp/documentation There is an Appendix that lists the protocol changes between versions, so you can accumulate them into what you would need to add to your application to use the newer protocol.

David Lender 2013-03-06T19:56:58Z Bob Miller http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12659211 2013-03-05T18:33:43Z 2013-03-05T18:33:43Z

We are currently running ICM 6 and are moving to ICM 8.5.x.  According to the documentation I have the GED-188 protocol is version 7.  Does ICM version 8.5.x support protcol version 7?   I understand that version 8.5 does support protocol version 14 (which has more features), but if we did not want ot update our API can we continue to use the version 7 API?  If we moved to ICM 9.0 does it support protocol version 7?  Assuming we are satisfied with the API in version 7, is there any disadvantage to continue to use version 7

Bob Miller 2013-03-05T18:33:43Z Dale Gantous http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11947937 2013-02-14T21:40:50Z 2013-02-14T21:40:50Z

Thanks for the info.

Dale Gantous 2013-02-14T21:40:50Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11948384 2013-02-14T21:20:26Z 2013-02-14T21:20:26Z

No, the registry settings are sent by CTIOS Server to the client in an arguments array of the particular CTIOS Cil you are using. These settings are sent in response to a Session.RequestDesktopSettings method request from the CTIOS Cil based client application, in this case, the CTIOS Agent Desktop. For more information about CTIOS Development, see http://developer.cisco.com/web/ctios The Finesse agent desktop also handles reason codes. These are configured through the Finesse Administration. For more information about Finesse Development, see http://developer.cisco.com/web/finesse

David Lender 2013-02-14T21:20:26Z Dale Gantous http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11947432 2013-02-14T21:08:21Z 2013-02-14T21:08:21Z

So, the Agent Desktop, running on a client machine, is directly reading the registry on the server machine where the CTI Server is running?

Dale Gantous 2013-02-14T21:08:21Z David Lender http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11905661 2013-02-13T20:46:26Z 2013-02-13T20:46:26Z

The CTIOS Agent Desktop does not use these values. The CTIOS Agent desktop retrieves the Reason Codes from the CTIOS Server registry in the downloadsettings event. Here is the configuration of ReasonCodes: http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cust_contact/contact_center/ctios/ctios9_0/installation/guide/UCCE_BK_C3D5EC47_00_cti-os-system-manager-guide_chapter_01000.html#UCCE_RF_R402F30A_00 I am not sure what CAD does. The ICM Configured reason codes are for reporting only. Theres no mechanism in either CTI Server protocol or CTIOS to receive the reason codes from the ICM database.

David Lender 2013-02-13T20:46:26Z Dale Gantous http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11907306 2013-02-13T20:36:45Z 2013-02-13T20:36:45Z

Thanks, so how does the Agent Desktop obtain these values to populate its dialog box?

Dale Gantous 2013-02-13T20:36:45Z