/mcp• The application can transfer any two calls that are present on the line. The following changed or new interfaces exist for Transfer and DirectTransfer: • CiscoTransferStarted. getTransferControllers()—This new interface, which is provided for SharedLine scenarios, supports multiple terminalConnections if a SharedLine is a TransferController. When a transferController is not a SharedLine, only a TerminalConnection occurs in the list. This method returns null if the transfer controller is not being observed. • CiscoTransferStarted. getTransferController()—This current interface, which behaves as it does for a normal transfer, may exhibit a different behavior for SharedLines. When a transferController is a SharedLine, multiple TerminalConnections exist. This method returns an ACTIVE TerminalConnection; however, if the application is not observing the ACTIVE TerminalConnection, this method returns one of the PASSIVE TerminalConnections. • CiscoTransferEnded isSuccess()—This new interface, which is provided for the CiscoTransferEnded event, returns true if the transfer operation succeeds and false if the transfer fails. Transfer failure may result from the following events: • The party dropped the call before CallProcessing could complete the transfer. • CallProcessing cannot Complete the transfer. The following changed or new behaviors exist for JTAPI Transfer: • No Hold or UnHold messages occur with an arbitrary transfer. • If a precondition for a transfer request has been modified, an application can issue transfer in any state of the call. • If an application does not have an active TerminalConnection that is passed as an argument, Call.consult() throws a PreConditionException/InvalidArgumentException. • If controller does not have any active TerminalConnection, Call.Transfer() throws a PreconditionException/InvalidArgumentException. To view the message flow for Transfer and DirectTransfer, see Message Sequence Charts, on page 761 Translation Pattern Support If a calling party transformation mask is configured for a translation pattern that is applied to a JTAPI application-controlled Address, the application may recognize extra connections that are created and disconnected when both the calling and called party are observed. A Connection is created for a transformed calling party instead of the actual calling party and CiscoCall.getCurrentCallingParty() would return the transformed calling party, when only the called party is observed. In general, JTAPI might not be able to create the appropriate Connection in the Call, and might not be able to provide correct information for currentCalling, currentCalled, calling, called, and lastRedirecting parties. For example, consider a translation pattern X that is configured with a calling party transformation mask Y and called party transformation mask B. If A calls X, the call goes to B. In this scenario: • If the application is observing only B, JTAPI creates a Connection for Y and B, and CiscoCall.getCurrentCallingParty() would return Address Y. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 197 Features Supported by Cisco Unified JTAPI Translation Pattern Support