McDewey

Multi-vendor documentation library · semantic search · MCP endpoint at /mcp

Page 258

↗ View in doc context
page
258
source
cucm/v15/jtapi-dev-guide/jtapi-dev-guide.md
chunk_id
cucm::v15::jtapi-dev-guide::jtapi-dev-guide::249

CiscoTransferEndEv This event indicates that the transfer operation ended. After this event is received, the application can assume that all involved parties transferred and that all Connections and TerminalConnections moved to the final call. Transfer Scenarios In the following scenarios, A, B, and C represent three parties that are involved in the transfer. Consult Transfer; B Is the Transfer Controller In a consult transfer, applications can redirect calls to a different address, and the transferrer can “consult” with the transfer destination before redirecting. • A calls B on call Call1. • B answers and consults to C on call Call2. • B transfers call Call2 to call Call1. To do this type of transfer, use the following JTAPI methods: • Call2.setTransferEnable(true) (This optional method means that transfer is enabled in the call object by default.) • Call2.consult(TermConnB, C) • Call1.transfer(Call2) During consult transfer, Call1.transfer(Call2) will transfer the call but not Call2.transfer(Call1). Note The following table lists the core events that observers of A and B receive between the CiscoTransferStartEv and the CiscoTransferEndEv. Table 8: Core Events for Observers of A and B Fields Event Call Meta Event Cause transferredCall = Call2 finalCall = CalltransferController = TermConnB CiscoTransferStartEv Call1 META_UNKNOWN TermConnDroppedEv B CallCtlTermConnDroppedEv B ConnDisconnectedEv B CallCtlConnDisconnectedEv B Call1 META_CALL_TRANSFERRING Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 194 Features Supported by Cisco Unified JTAPI CiscoTransferEndEv

Image 1 from page 258

Page 258 diagram