/mcpapplications do not get subjected to the restrictions that are imposed by the JTAPI 1.2 specification, which cautions applications against using JTAPI methods from within observer callbacks. CiscoSynchronousObserver Interface The Cisco Unified JTAPI implementation allows applications to invoke blocking JTAPI methods, such as Call.connect() and TerminalConnection.answer(), from within observer callbacks. This means that applications do not get subjected to the restrictions that the JTAPI 1.2 specification imposes, which cautions against using JTAPI methods from within observer callbacks. Applications can selectively disable the queuing logic of the Cisco Unified JTAPI implementation by implementing the CiscoSynchronousObserver interface on their observer objects. This asynchronous behavior does not adversely affect many applications. Applications that would benefit from a coherent call model during observer callbacks can selectively disable the queuing logic of the Cisco Unified JTAPI implementation. By implementing the CiscoSynchronousObserver interface on its observer objects, an application declares deliver synchronous events to its observers. Events that are delivered to synchronous observers will match the states of the call model objects that are queried from within the observer callback. Objects that implement the CiscoSynchronousObserver interface may not invoke blocking JTAPI methods from within their event callbacks. The consequences of doing so are unpredictable, and may include deadlocking the JTAPI implementation. On the other hand, you may safely use the access or methods of any JTAPI object, such as Call.getState() or Connection.getState(). Applications should avoid calling any interface that returns an array such as Terminal.getAddresses() in synchronous callbacks. Note Querying Dynamic Objects Beware of querying dynamic objects such as call objects. By the time you get an event, the object (such as, call) may exist in a different state than the state that is indicated. For example, by the time you get a CiscoTransferStartEV, the transferred call may have removed all its internal connections. callChangeEvent() When the callChangedEvent() method is called, the validity remains guaranteed for any references that are contained in the event. For example, if the event contains a getConnection() method, the application can call this method and get a valid connection reference. Likewise, a getCallingAddress() method guarantees to return a valid Address object. CiscoConsultCall For the CiscoConsultCall interface, a reference to a consulting terminal connection gets retained forever. For example, when a CiscoConsultCallActive event is processed, getConsultingTerminalConnection() guarantees to return a valid terminal connection reference. Further, the terminal connection guarantees to provide access to the consulting connection and thus the consulting call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 25 Overview CiscoSynchronousObserver Interface