McDewey

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

Page 252

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

• The user presses the CANCEL key after pressing the Active Calls softkey but does this before selecting the call on phone UI. In this case, pressing the Active Calls softkey on the phone UI makes consultCall GC3 IDLE, but there is no CANCEL notification, as other feature operations are possible. However, if the user presses CANCEL, the CiscoCallConsultCancelEv with consult call as null, is trigerred. • The user presses the Active Call softkey, selects a call and then presses CANCEL. In this case, the selected call is returned as a consultCall with CiscoCallFeatureCancelledEv. Interface Changes See CiscoCallFeatureCancelledEv, on page 365 Message Sequences See Swap or Cancel and Transfer or Conference Behavior Change, on page 1174 Backward Compatibility This feature is backward compatible. For this release, the Swap or Cancel feature is enabled without a service parameter to turn it off. This means that Cisco Unified JTAPI always supports or reports events for Swap or Cancel for phones which support this feature. However, to provide backward compatibility for applications, a new permission that enables control of these devices and to enable SWAP or CANCEL operation has been added. A new standard role Standard Supports Connected Xfer/Conf and a standard user group are added in the admin pages for this feature. Applications can control these devices only if this new role is associated to the application user, assuming that the application uses JTAPI client 7.1.2 or higher. So, by default these devices are listed as restricted and only if application upgrades to handle this feature and associates the new permission can it control these devices. If the application uses an older JTAPI client the devices are not restricted but if the application tries to observe these devices (which supports this feature to be invoked manually) then JTAPI throws an exception and marks these devices as restricted from there on. Since, the feature is designed to provide an enhanced user experience, it is strongly recommended for all Cisco Unified JTAPI applications to evaluate and support this feature and upgrade if necessary with the code logic to handle the old behavior and the new behavior. Terminal and Address Capability Settings This feature introduces interfaces that expose different configuration settings of address and terminal. These interfaces can be called even when the terminal or address is in out-of-service state. All interfaces return the values that are configured while registering with Cisco Unified Communications Manager. If the terminal is not registered, an InvalidStateException is returned. Application can get the voice mail pilot even if the terminal is not registered. All the other changes, except voice mail, require the terminal to be reset for the new values to take effect. Interfaces return new values only after phones re-register after reset. Applications can use the interface CiscoProvTerminalRegisteredEv to read the configuration of the terminal and address. The following configurations are exposed on CiscoAddress: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 188 Features Supported by Cisco Unified JTAPI Terminal and Address Capability Settings