RE: New Message from Petrus Buiquy in CTI Server Protocol (GED-188) - CTI S

RE: New Message from David Seeba in CTI Server Protocol (GED-188) - CTI Ser

2013-04-17T20:30:28Z

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

RE: New Message from Petrus Buiquy in CTI Server Protocol (GED-188) - CTI S

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.

RE: New Message from Petrus Buiquy in CTI Server Protocol (GED-188) - CTI S

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.

RE: New Message from Petrus Buiquy in CTI Server Protocol (GED-188) - CTI S

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.

RE: New Message from Goran Selthofer in CTI Server Protocol (GED-188) - CTI

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.

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

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

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

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.

RE: New Message from Bob Miller in CTI Server Protocol (GED-188) - CTI Serv

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.

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

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

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

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.

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

2013-02-13T17:17:26Z

Reason codes are Configured using the UCCE Configuration Tool. There is no method to retrieve these values via CTI Server Protocol.

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

2012-12-19T16:34:56Z

Yes, I have opened a doc defect CSCud79679

RE: New Message from David Lender in CTI Server Protocol (GED-188) - CTI Se

2012-12-19T15:37:56Z

The parameter forced flag is implemented in the Protocol, but just not used in the application layer. This parameter is not used in CTI Server, and it is currently reserved for future use. So, there is no way to authenticate an agent only using CTI Server protocol.

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

2012-12-13T18:33:57Z

There is a “forced flag” you can set in the SET_AGENT_STATE_REQ message which you set to 2 = Agent authentication only. No agent state change. Use with AGENT_STATE_LOGIN

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

2012-12-13T17:04:18Z

I don’t know of any way for password validation without actually logging in the agent.

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

2012-12-13T16:01:57Z

If you specify only agentID on the QUERY_AGENT_STATE_REQ and if the agent is logged in you should receive the extension on the QUERY_AGENT_STATE_CONF. If the agent is not logged in then do the SET_AGENT_STATE_REQ.

RE: New Message from Dale Gantous in CTI Server Protocol (GED-188) - CTI Se

2012-12-13T15:06:57Z

Have you tried QUERY_AGENT_STATE_REQ with just the AgentID before trying the SET_AGENT_STATE_REQ?

RE: New Message from Sabina Mirauta in CTI Server Protocol (GED-188) - CTI

2012-11-14T15:07:48Z

There is not a Java API for UCCX CTI protocol. UCCX CTI protocol and CTI Server protocol are both TCP/IP socket based messaging protocols. You may wish to look into using Cisco Finesse which will shortly offer a UCCX version. Finesse is both an agent desktop and a Webservices API. More information about Finesse can be found here http://developer.cisco.com/web/finesse

RE: CONFERENCE_CALL_REQ does not work with Aspect ACD

2012-10-31T13:31:49Z

I think you have to place the consult call using the [b]CONSULTATION_CALL_REQ[/b] and specify the consult type as conference. You cant just put a call on hold and use the [b]MAKE_CALL_REQ[/b] to make the consult call and then try to conference them.

RE: New Message from Petrus Buiquy in CTI Server Protocol (GED-188) - CTI S

2012-10-15T21:06:34Z

I don’t have any ideas other than making sure you are specifying the right call on hold and don’t have them backwards in the CTISP fields on the CONFERENCE_CALL_REQ message. You could also post the log snippet.