Cisco Cisco Computer Telephony Integration Option 8.5 Developer's Guide

format, that internal memory allocations were successful, and that the request was 
put on the send queue to be transmitted to the CTI OS Server. Generally, the CIL 
error code returned from method calls will be 

CIL_OK, indicating that the method 

call was made successfully. However, this does not indicate that the request was 
actually serviced by the CTI OS Server or successfully completed at the 
PBX/ACD. 

To determine the success or failure of the underlying telephony operation 
requested, the CTI programmer must wait for an event confirming the success or 
failure of the request. To generalize the message flow model, most requests made 
at the CTI OS CIL will be answered with a confirmation message and/or an event 
message. See the object interface reference in Chapters 8-12 for details on each 
particular request. This type of response is called asynchronous – it can arrive at 
any time after the request is made, but typically requests are services in 
sub-second timeframes. 

For each method request in the programmer’s interface sections of this document, 
the expected event sequence is described, so that programmers know which 
events to expect. In the event of a request failure, an eControlFailureConf 
message will be send to the client; the eControlFailureConf message will have a 
parameter called MessageType indicating which request failed, and a parameter 
called ErrorMessage, with a description of the failure cause. 

For example: when sending a MakeCall request, the method will typically return 
CIL_OK, which means that the method call was successful. If the underlying 
make call request is successful, the CIL will receive several follow-on events, 
such as eBeginCallEvent and eServiceInitiatedEvent. If the request fails, the CIL 
will receive the eControlFailureConf message.

A common mistake: developers who have not previously programmed with 
asynchronous events might mistake the error code returned from a method call for 
the actual result of the request. The correct semantics are to interpret the error 
code as being indicative of the result of the method call, and to interpret the 
follow-on events to determine the actual result of the requested operation. 

Whenever a method call is invoked by a custom application using the CIL, an 
error code is returned. The error codes returned only indicate success or failure of 
the method call, as indicated in the previous section.