Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lxiv Contents

C H A P T E R 1 New and Changed Information This chapter describes new and changed JTAPI information for this release of Cisco Unified Communications Manager and features supported in the previous releases. For more information, go to the Programming Guides website at http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html. • Cisco Unified Communications Manager Release 15SU3, on page 1 • Cisco Unified Communications Manager Release 15SU2, on page 2 • Cisco Unified Communications Manager Release 15, on page 2 • Cisco Unified Communications Manager Release 14SU2, on page 2 • Cisco Unified Communications Manager Release 12.5(1), on page 2 • Cisco Unified Communications Manager, Release 11.5(1), on page 2 • Cisco Unified Communications Manager, Release 11.0(1), on page 3 • Cisco Unified Communications Manager Release 10.5(2), on page 3 • Cisco Unified Communications Manager Release 10.0(1), on page 3 • Cisco Unified Communications Manager Release 9.0(1), on page 4 • Cisco Unified Communications Manager Release 8.6(1), on page 4 • Cisco Unified Communications Manager Release 8.5(1), on page 4 • Cisco Unified Communications Manager Release 8.0(1), on page 5 • Cisco Unified Communications Manager Release 7.1(3), on page 5 • Cisco Unified Communications Manager Release 7.1(2), on page 5 • Cisco Unified Communications Manager Release 7.0(1), on page 6 • Cisco Unified Communications Manager Release 6.1, on page 7 • Cisco Unified Communications Manager Release 6.0, on page 8 • Cisco Unified Communications Manager Release 5.1, on page 8 • Cisco Unified Communications Manager Release 5.0, on page 9 Cisco Unified Communications Manager Release 15SU3 The following sections contain information about the new and changed features for Cisco Unified Communications Manager, Release 15SU3: • Transport Layer Security (TLS), on page 198 • Fields in the jtapi.ini File, on page 241 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1

• CiscoJtapiProperties, on page 435 • Methods, on page 436 • CiscoJtapiProperties, on page 1687 Cisco Unified Communications Manager Release 15SU2 The following sections contain information about the new and changed features for Cisco Unified Communications Manager, Release 15SU2: FIPS Compliance, on page 95 Transport Layer Security (TLS), on page 198 Cisco Unified Communications Manager Release 15 There are no new or changed JTAPI specifications for Unified Communications Manager Release 15. Cisco Unified Communications Manager Release 14SU2 This section contains information about the new and changed features for Unified Communications Manager Release 14SU2: FIPS Compliance, on page 95 Cisco Unified Communications Manager Release 12.5(1) This section contains information about the new and changed features for Cisco Unified Communications Manager, Release 12.5(1): • Call Recording for SIP or TLS Authenticated Calls, on page 43 • Multi-fork Recording using CUBE Media Proxy Server, on page 125 • Linux and Windows installation procedure is updated in Installing the Cisco Unified JTAPI Software section. Cisco Unified Communications Manager, Release 11.5(1) This section contains information about the new and changed features for Cisco Unified Communications Manager, Release 11.5(1): • Hunt Log Status, on page 105 • End to End Session ID for Calls, on page 94 • Redirect to Device, on page 149 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 2 New and Changed Information Cisco Unified Communications Manager Release 15SU2

• SHA-512 Support for Digital Signatures, on page 193 Starting from Release 11.5(1)SU9 and any subsequent SU or ES releases in this release train, the Cisco JTAPI Plugin follows installer less approach. You must have JRE installed on the system before the installation. The installation runs in the command prompt and does not have a GUI. Also, the same will not be listed in the software installed list of Windows Control Panel. Cisco Spark Device has been added as a new device type for this release of Unified Communications Manager and may appear in the user's control list. However, Cisco Spark Device is not a supported device for this release of Cisco Unified JTAPI. Note Cisco Unified Communications Manager, Release 11.0(1) This section contains information about the new and changed features for Cisco Unified Communications Manager, Release 11.0(1). • Default CTI IP Addressing for Devices, on page 75 • Ringback on SIP 183 for Transferred Calls, on page 153 Cisco Unified Communications Manager Release 10.5(2) This section contains the new and changed features for Cisco Unified Communications Manager release 10.5(2): • AES 256 Algorithm IDs, on page 34 Cisco Unified Communications Manager Release 10.0(1) This section describes the new and changed features in Cisco Unified Communications Manager Release 10.0(1): • CTI RD Call Forward, on page 72 • CTI Video Support, on page 73 • Encryption Enhancement, on page 89 • Mobility Interaction Support, on page 72 • NuRD (Number Matching for Remote Destination) Support, on page 71 • Play Announcement, on page 70 • Persistent Connection, on page 135 • SSO Cookie, on page 171 • Recording, on page 144 • Verify Remote Destination Support, on page 71 • Video Capabilities and Multi-Media Information, on page 209 • Video On Hold Support, on page 213 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 3 New and Changed Information Cisco Unified Communications Manager, Release 11.0(1)

Cisco Unified Communications Manager Release 9.0(1) This section describes the new and changed features in Cisco Unified Communications Manager release 9.0(1): • Cius Persistency, on page 59 • CTI Remote Device for JTAPI, on page 69 • E911 Teleworker, on page 88 • Hunt List Connected Number, on page 105 • Native Queuing, on page 125 • URI Dialing, on page 208 Cisco Unified Communications Manager Release 8.6(1) This section describes the new and changed features in Cisco Unified Communications Manager release 8.6(1): • Account Lockout, on page 33 • EnergyWise Deep Sleep Mode, on page 90 • FIPS Compliance, on page 95 • Password Expiry, on page 135 • New JTAPI x64 client for 64-bit operating systems. Cisco Unified Communications Manager Release 8.5(1) This section describes the new and changed features in Cisco Unified Communications Manager release 8.5(1): • Agent Greeting, on page 33 • API for Exposing Built-In-Bridge Status, on page 35 • Play Zip Tone, on page 137 • Single Sign-On, on page 170 • Support for VMware, on page 186 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 4 New and Changed Information Cisco Unified Communications Manager Release 9.0(1)

Cisco Unified Communications Manager Release 8.0(1) This section describes the new and changed features in Cisco Unified Communications Manager release 8.0(1): • Call Control Discovery, on page 41 • Call Pickup, on page 42 • CallFwdAll Key Press Notification, on page 46 • End to End Call Tracing, on page 89 • Extension Mobility Cross Cluster, on page 92 • External Call Control, on page 93 • Hunt List, on page 103 • iSac Codec, on page 109 • Secured Monitoring and Recording, on page 162 • Support for Cisco Unified IP Phone 6901, on page 183 • Support for 100+ Directory Numbers, on page 185 • Support for VMware, on page 186 • Verification Involving PSTN Reachability, on page 209 Cisco Unified Communications Manager Release 7.1(3) This section describes the new and changed features in Cisco Unified Communications Manager release 7.1(3): • Terminal and Address Capability Settings, on page 188. Cisco Unified Communications Manager Release 7.1(2) This section describes the new and changed features in Cisco Unified Communications Manager release 7.1(2): • Component Updater, on page 62 • Direct Transfer Across Lines, on page 77 • Drop Any Party, on page 85 • IPv6 Support, on page 108 • Join Across Lines or Connected Conference Across Lines, on page 112 • Logical Partitioning, on page 119 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 5 New and Changed Information Cisco Unified Communications Manager Release 8.0(1)

• Message Waiting Indicator Enhancement, on page 122 • Park Monitoring and Assisted DPark Support, on page 129 • Swap or Cancel and Transfer or Conference Behavior, on page 187 Cisco Unified Communications Manager Release 7.0(1) This section describes the new and changed features in Cisco Unified Communications Manager from release 6.1 to release 7.0(1) and Cisco Unified JTAPI enhancements. It has the following sections: • Call Pickup, on page 42 • Calling Party Normalization, on page 46 • Click to Conference, on page 60 • Do Not Disturb-Reject, on page 84 • Extension Mobility Username Login, on page 93 • Java Socket Connect Timeout, on page 110 • Join Across Lines with Conference Enhancements (SCCP and SIP), on page 116 • Locale Infrastructure Development, on page 118 • selectRoute() with Calling Search Space and Feature Priority, on page 164 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 6 New and Changed Information Cisco Unified Communications Manager Release 7.0(1)

Cisco Unified Communications Manager release 7.0(1) does not support the following IPv6 related methods: canSupportIPv6() setProviderOpenRetryAttempts (int retryAttempts) getProviderOpenRetryAttempts() getIPAddressingMode() (available on CiscoMediaTerminal and CiscoRouteTerminal interfaces) register(java.net.InetAddress address, int port, CiscoMediaCapability [] capabilities, int[] algorithmIDs, java.net.InetAddress address_v6, int activeAddressingMode) register(CiscoMediaCapability [] capabilities, int[] int registration Type, int[] algorithmIDs, int activeAddressingMode) getTerminals() (available on new interface CiscoProviderTermCapabilityChangedEv) getAddressingModeForMedia() getCallingPartyIpAddr_v6() (available on CiscoCallCtlConnOfferedEv and CiscoRouteEvent interfaces) CTIERR_IPADDRMODEMISMATCH CTIERR_DYNREG_IPADDRMODE_MISMATCH hasIPv6CapabilityChanged() CiscoTerminal.IP_ADDRESSING_MODE_IPv4 CiscoTerminal.IP_ADDRESSING_MODE_IPv6 CiscoTerminal.IP_ADDRESSING_MODE_IPv4_v6 CiscoTerminal.IP_ADDRESSING_MODE_Unknown CiscoTermRegistrationFailedEv.IP_ADDRESSING_MODE_MISMATCH Note For the features, Join Across Lines, Do Not Disturb-Reject, and Calling Party Normalization, each Cisco JTAPI must be upgraded to a version that supports these features. Additionally, if you are upgrading from release 5.1 and you use Join Across Lines, the Conference Chaining feature must not be enabled or used until all applications are either upgraded to a version compatible with the new unified CM version. Also, you should verify that the applications are not impacted by the Conference Chaining feature. Note Cisco Unified Communications Manager Release 6.1 This section describes the new and changed features in Cisco Unified Communications Manager from release 6.0 to release 6.1 and Cisco Unified JTAPI enhancements. It has the following sections: • Certificate Download API Enhancement, on page 47 • Intercom Support for Extension Mobility, on page 108 • Join Across Lines, on page 110 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 7 New and Changed Information Cisco Unified Communications Manager Release 6.1

Cisco Unified Communications Manager Release 6.0 This section describes the new and changed features in Cisco Unified Communications Manager, release 6.0 and Cisco Unified JTAPI enhancements. It has the following sections: • Arabic and Hebrew Language Support, on page 36 • Calling Party IP Address, on page 44 • CiscoRTPHandle Interface on Cisco RTP Events, on page 57 • Cisco Unified IP 7931G Phone Interaction, on page 54 • Conference Chaining, on page 67 • Directed Call Park, on page 82 • Do Not Disturb, on page 83 • Forwarding on No Bandwidth and Unregistered DN, on page 100 • Hold Reversion, on page 103 • Intercom, on page 106 • Multilevel Precedence and Preemption Support, on page 125 • Noncontroller Adding of Parties to Conferences, on page 129 • Silent Monitoring, on page 167 • Secure Conferencing, on page 155 • Translation Pattern Support, on page 1709 • Version Format Change, on page 209 • Voice MailBox Support, on page 214 Cisco Unified Communications Manager Release 5.1 This section describes the new and changed features in Cisco Unified Communications Manager, from release 5.0 to release 5.1 and Cisco Unified JTAPI enhancements. It has the following sections: • Call Forward Override, on page 41 • Join Across Lines (Only SCCP), on page 111 • New Error Code in CiscoTermRegistrationFailedEv, on page 128 • Star (*) 50 Update, on page 180 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 8 New and Changed Information Cisco Unified Communications Manager Release 6.0

Cisco Unified Communications Manager Release 5.0 This section describes the new and changed features in Unified Communications Manager, from release 4.x to release 5.0 and Cisco Unified JTAPI enhancements. It has the following: • Auto Updater for Linux, on page 36 • Call Select Status, on page 43 • Command Line Invocation, on page 62 • Hairpin Support, on page 101 • Half-Duplex Media Support, on page 102 • JRE 1.2 and JRE 1.3 Support Removal, on page 117 • JTAPI Version Information, on page 118 • Network Alerting, on page 127 • Partition Support, on page 132 • QoS Support, on page 140 • Secure Real-Time Protocol Key Material, on page 156 • SIP 3XX Redirection, on page 172 • SIP REFER or REPLACE, on page 176 • SIP Phone Support, on page 173 • Superprovider and Change Notification, on page 181 • Terminal and Address Restrictions, on page 189 • Transport Layer Security (TLS), on page 198 • Unicode Support, on page 205 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 9 New and Changed Information Cisco Unified Communications Manager Release 5.0

Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 10 New and Changed Information Cisco Unified Communications Manager Release 5.0

C H A P T E R 2 Overview Cisco Unified Communications Manager (Unified CM) is the powerful call-processing component of the Cisco Unified Communications Solution. It is a scalable, distributable, and highly available enterprise IP telephony call-processing solution. Unified CM acts as the platform for collaborative communication and as such supports a wide array of features. In order to provision, invoke the features, monitor, and control such a powerful system, Unified CM supports different interface types. This chapter gives an introduction to the different interfaces of Unified CM and describes the major concepts with which you need to be familiar before creating Java Telephony Application Programming Interface (JTAPI) applications for Cisco Unified Communications Manager systems. For information about Cisco Unified Communications Manager features, see Features Supported by Cisco Unified JTAPI, on page 29 Also see CTI Supported Devices, on page 1661 and Cisco Unified JTAPI Operations by Release, on page 1655 for more information and CTI devices and supported features. • Cisco Unified Communications Manager Interfaces, on page 11 • JTAPI Overview, on page 15 • Cisco Unified JTAPI Concepts, on page 17 • Threaded Callbacks, on page 24 • Alarm Services, on page 26 • Software Requirements, on page 26 • Development Guidelines, on page 26 Cisco Unified Communications Manager Interfaces The interface types supported by Unified CM are divided into the following types: • Provisioning Interfaces, on page 12 • Device Monitoring and Call Control Interfaces, on page 12 • Serviceability Interfaces, on page 13 • Routing Rules Interface, on page 14 • Cisco Unified Communications Manager Interfaces, on page 11 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 11

Provisioning Interfaces The following are the provisioning interfaces of Unified CM: • Administration XML • Cisco Extension Mobility Service Administrative XML The Administration XML (AXL) API provides a mechanism for inserting, retrieving, updating and removing data from the Unified CM configuration database using an eXtensible Markup Language (XML) Simple Object Access Protocol (SOAP) interface. This allows a programmer to access Unified CM provisioning services using XML and exchange data in XML form, instead of using a binary library or DLL. The AXL methods, referred to as requests, are performed using a combination of HTTP and SOAP. SOAP is an XML remote procedure call protocol. Users perform requests by sending XML data to the Unified CM Publisher server. The publisher then returns the AXL response, which is also a SOAP message. For more information, See the Administrative XML Tech Center on the Cisco Developer Network http://developer.cisco.com/web/axl/home. Cisco Extension Mobility The Cisco Extension Mobility (Extension Mobility) service, a feature of Unified CM, allows a device, usually a Cisco Unified IP Phone, to temporarily embody a new device profile, including lines, speed dials, and services. It enables users to temporarily access their individual Cisco Unified IP Phone configuration, such as their line appearances, services, and speed dials, from other Cisco Unified IP Phones. The Extension Mobility service works by downloading a new configuration file to the phone. Unified CM dynamically generates this new configuration file based on information about the user who is logging in. You can use the XML-based Extension Mobility service API with your applications, so they can take advantage of Extension Mobility service functionality. For more information, see the Extension Mobility API Tech Center on the Cisco Developer Network https://developer.cisco.com/site/extension-mobility/develop-and-test/documentation/latest-version/ emapi-developer-guide.gsp. Also, see Cisco Unified Communications Manager XML Developers Guide for relevant release of Unified CM at the following location: http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html. Device Monitoring and Call Control Interfaces The following are the device monitoring and call control interfaces of Unified CM: • Cisco TAPI and Media Driver • Cisco JTAPI • Cisco Web Dialer Cisco TAPI and Media Driver Unified CM exposes sophisticated call control of IP telephony devices and soft-clients via the Computer Telephony TAPI interface. Cisco's Telephone Service Provider (TSP) and Media Driver interface enables Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 12 Overview Provisioning Interfaces

custom applications to monitor telephony-enabled devices and call events, establish first- and third-party call control, and interact with the media layer to terminate media, play announcements, record calls. For more information, see the TAPI and Media Driver Tech Center on the Cisco Developer Network http://developer.cisco.com/web/tapi/home. Also, see the Cisco Unified TAPI Developers Guide for Cisco Unified Communications Manager for relevant release of Unified CM at the following location: http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html. Cisco JTAPI For more information, see the JTAPI Tech Center on the Cisco Developer Network http://developer.cisco.com/web/jtapi/home and JTAPI Overview, on page 15. Cisco Web Dialer The Web Dialer, which is installed on a Unified CM server, allows Cisco Unified IP Phone users to make calls from web and desktop applications. For example, the Web Dialer uses hyperlinked telephone numbers in a company directory to allow users to make calls from a web page by clicking the telephone number of the person that they are trying to call. The two main components of Web Dialer comprise the Web Dialer Servlet and the Redirector Servlet. For more information, see the Web Dialer Tech Center on the Cisco Developer Network https://developer.cisco.com/site/webdialer/develop-and-test/documentation/latest-version/. For more information on Cisco Web Dialer, see the Cisco Unified Communications Manager XML Developers Guide for relevant release of Unified CM at the following location: http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html. Serviceability Interfaces The following are the serviceability interfaces of Unified CM: • Serviceability XML • SNMP/MIBs Serviceability XML A collection of services and tools designed to monitor, diagnose, and address issues specific to Unified CM serviceability XML interface: • Provides platform, service and application performance counters to monitor the health of Unified CM hardware and software • Provides real-time device and CTI connection status to monitor the health of phones, devices, and applications connected to Unified CM. • Enables remote control (Start/Stop/Restart) of Unified CM services. • Collects and packages Unified CM trace files and logs for troubleshooting and analysis. • Provides applications with Call Detail Record files based on search criteria. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 13 Overview Cisco JTAPI

• Provides management consoles with SNMP data specific to Unified CM hardware and software. For more information, see the Serviceability XML Tech Center on the Cisco Developer Network http://developer.cisco.com/web/sxml/home. SNMP/MIBs SNMP interface allows external applications to query and report various UCMgr entities. It provides information on the connectivity of the Unified Communication Manager to other devices in the network, including syslog information. The MIBs supported by Unified CM includes: • Cisco-CCM-MIB, CISCO-CDP-MIB, Cisco-syslog-MIB • Standard Mibs like MIB II, SYSAPPL-MIB, HOST RESOURCES-MIB • Vendor MIBs For more information, see the SNMP/MIB Tech Center on the Cisco Developer Network https://developer.cisco.com/site/sxml/. Also, see the Cisco Unified Communications Manager XML Developers Guide for relevant release of Unified CM at the following location: http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html. Routing Rules Interface Cisco Unified Communication Manager 8.0(1) and later supports the external call control (ECC) feature, which enables an adjunct route server to make call-routing decisions for Cisco Unified Communications Manager by using the Cisco Unified Routing Rules Interface. When you configure external call control, Cisco Unified Communications Manager issues a route request that contains the calling party and called party information to the adjunct route server. The adjunct route server receives the request, applies appropriate business logic, and returns a route response that instructs Cisco Unified Communications Manager on how the call should get routed, along with any additional call treatment that should get applied. For more information, see the Routing Rules Interface Tech Center on the Cisco Developer Network https://developer.cisco.com/site/curri/develop-and-test/documentation/latest-version/. Cisco Connection Interface This interface has the APIs that can be invoked on a connection object. Connections retain their references to calls and addresses forever. A connection reference that is obtained from a call event can be used to obtain the connection call (getCall()) and address (getAddress()). The following are the cisco connection interfaces of Cisco Unified Communications Manager: • Local Universal Unique Identifier of Party Associated with the Connection • Local Universal Unique Identifier of Party Associated on the Other Side of the Call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 14 Overview SNMP/MIBs

JTAPI Overview Cisco Unified JTAPI serves as a programming interface standard developed by Sun Microsystems for use with Java-based computer–telephony applications. Cisco JTAPI implements the Sun JTAPI 1.2 specification with additional Cisco extensions. You use Cisco JTAPI to develop applications that: • Control and observe Cisco Unified Communications Manager phones. • Route calls by using Computer–Telephony Integration (CTI) ports and route points (virtual devices). Basic telephony APIs that are supported comprises conference, transfer, connect, answer, and redirect APIs. A package of JTAPI interfaces, located in the javax.telephony.* hierarchy, defines a programming model by which Java applications interact with telephony resources. For more information about interfaces, see Cisco Unified JTAPI Classes and Interfaces, on page 1605. This section describes the following subjects: • Cisco Unified JTAPI and Contact Centers, on page 15 • Cisco Unified JTAPI and Enterprises, on page 15 • Cisco Unified JTAPI Applications, on page 16 • Jtprefs Application, on page 17 Cisco Unified JTAPI and Contact Centers Cisco Unified JTAPI gets used in a contact center to monitor device status and to issue routing instructions to send calls to the right place at the right time, to start and stop recording instructions while retrieving call statistics for analysis; and to screen-pop calls into CRM applications, automated scripting, and remote call control. Cisco Unified JTAPI and Enterprises Cisco Unified JTAPI, used in an enterprise environment, combines user availability, location, and preferences for a uniquely tailored environment for presence-based routing. For example, in a financial environment, market data, business logic, and call control combine in a browser-based application to enable brokers and analysts to respond to rapid changes in the global financial markets. In a heathcare environment, call control, doctor/patient lookup, and emergency response team paging combine in a browser-based console. Further, in a hospitality environment, caller data gets linked with POS systems to automate room or restaurant reservations, dispatch taxis, and schedule wakeup calls. The following figure shows a typical Cisco Unified Communications Manager and Cisco Unified JTAPI in an enterprise configuration. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 15 Overview JTAPI Overview

Figure 1: Cisco Unified Communications Manager and Cisco Unified JTAPI Cisco Unified JTAPI Applications A Cisco Unified JTAPI application can flow as follows: • Obtain JTAPIPeerobject instance from JTAPIPeerFactory. • Obtain a Provider by using the getProvider() API on JTAPIPeer. • Obtain from the Provider, the Terminal and Address for use in your application. • Determine capabilities of relevant objects. • Add observers for the objects that application wants to monitor/control. • Begin application flow (for example, begin calls). The following example shows a basic JTAPI application. public void getProvider () { try { JtapiPeer peer

JtapiPeerFactory.getJtapiPeer ( null ); System.out.println ("Got peer "+peer); Provider provider

peer.getProvider("cti-server;login = username;passwd = pass"); System.out.println ("Got provider "+provider); MyProviderObserver providerObserver

new MyProviderObserver (); provider.addObserver(providerObserver); while (outOfService ) { Thread.sleep(500); } System.out.println ("Provider is now in service"); Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 16 Overview Cisco Unified JTAPI Applications

Address[] addresses

provider.getAddresses(); System.out.println ("Found "+ addresses.length +" addresses"); for(int i = 0; i< addresses.length; i++) { System.out.println(addresses[i]); } provider.shutdown(); catch (Exception e) { } } Jtprefs Application The jtapi.ini file includes parameters that are required for configuring Cisco Unified JTAPI. Cisco Unified JTAPI looks for this file in a Java classpath. The parameters get modified by using the Jtprefs application that Cisco Unified JTAPI installs. The Jtprefs application sets only the parameters that it requires. This proves beneficial because a single point of application administration exists, independent of jtapi.ini. The jtapi.ini file contains default values, but client applications can modify values without having to specifically modify the jtapi.ini file. Different instances of client applications, however, can impose different settings for these parameters. The com.cisco.jtapi.extensions package defines the CiscoJtapiProperties interface. Applications obtain a CiscoJtapiProperties object from the CiscoJtapiPeer and make changes to the parameters by using the accessor and mutator methods. These properties must get set and applied to all providers that are derived from a CiscoJtapiPeer prior to the first getProvider () call on that peer. Applications that run in non GUI based platform, in which jtprefs.ini cannot be invoked, can write a jtapi.ini file and place it along with jtapi.jar. See the following topics for more information: • Administering User Information for JTAPI Applications, on page 241 • Fields in the jtapi.ini File, on page 241 Cisco Unified JTAPI Concepts This section describes the following concepts: • CiscoObjectContainer Interface, on page 18 • JtapiPeer and Provider, on page 18 • Address and Terminal Relationships, on page 20 • Connections, on page 21 • Terminal Connections, on page 21 • Terminal and Address Restrictions, on page 21 • CiscoConnectionID, on page 24 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 17 Overview Jtprefs Application

CiscoObjectContainer Interface The CiscoObjectContainer interface allows applications to associate an application-defined object to objects that implement the interface. In Cisco Unified JTAPI, the following interfaces extend the CiscoObjectContainer interface: • CiscoJTAPIPeer • CiscoProvider • CiscoCall • CiscoAddress • CiscoTerminal • CiscoConnection • CiscoTerminalConnection • CiscoConnectionID • CiscoCallID JtapiPeer and Provider The Provider object, which gets created through the implementation of the JtapiPeer object, acts as the main point of contact between applications and JTAPI implementations. The Provider object contains the entire collection of call model objects, Addresses, Terminals, and Calls, which are controllable at any time by an application. The JTAPI Preferences (JTPREFS) application administers JtapiPeer.getServices(), which returns server names. The Provider entails two basic processes: initialization and shutdown. Ensure that the following information is passed in the JtapiPeer.getProvider() method for applications to obtain a CiscoProvider: • Hostname or IP address for the Cisco Unified Communications Manager server • Login of the user who is administered in the directory • Password of the user that is specified • (Optional) Application information (This parameter may comprise a string of any length.) Applications must include enough descriptive information, so if the appinfo were logged in and an alarm were to occur, administrators would know which application caused the alarm. Applications should not include hostname or IP address where they reside, nor the time at which they were spawned. Also, ensure that no “ = ” or “;” characters are included in the appinfo string because they delimit the getProvider () string. When the appinfo is not specified, you can use a generic and quasi-unique name (JTAPI[XXXX]@hostname, where XXXX represents a random, four-digit number) instead. The parameters get passed in key value pairs that are concatenated in a string as follows: JtapiPeer.getProvider(“CTIManagerHostname;login = user;passwd = userpassword;appinfo = Cisco Softphone”) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 18 Overview CiscoObjectContainer Interface

Initialization The JtapiPeer.getProvider() method returns a Provider object as soon as the TCP link, the initial handshake with the Cisco Unified Communications Manager, and the device list enumeration are complete. The provider now exists in the OUT_OF_SERVICE state. Cisco Unified JTAPI applications must wait for the provider to go to the IN_SERVICE state before the controlled device list is valid. A ProvInServiceEv event gets delivered to an object that is implementing the ProviderObserver interface. Implementing only the CiscoProviderObserver does not do enough; the observer must also get added to the provider with provider.addObserver(). Applications must wait for a notification that the Provider is in service. Note As a part of the QoS baselining effort in JTAPI, ProviderOpenCompletedEv provides the “DSCP value for Applications” to JTAPI. JTAPI sets this DSCP value for its connection with CTI, and all JTAPI messages to CTI will have this DSCP value as long as the Provider object exists. Shutdown When an application calls provider.shutdown(), JTAPI loses communications permanently with the Cisco Unified Communications Manager, and a ProvShutdownEv event gets delivered to the application. The application can assume that the Provider will not come up again, and the application must handle a complete shutdown. Provider.getTerminals() This method returns an array of terminals that are created for the devices that are administered in the user control list in the directory. Refer to the Cisco Unified Communications Manager Administration Guide to administer the user control list. Provider.getAddresses() This method returns an array of addresses that are created from the lines that are assigned to the devices that are administered in the user control list in the directory. Changes to the User Control List in the Directory If a device is added to the user control list after the JTAPI application starts, a CiscoTermCreatedEv, and the respective CiscoAddrCreatedEv, gets generated and sent to observers that are implementing the CiscoProviderObserver. In addition, applications can monitor the current registration state of the controlled devices and dynamically track the availability of these devices. The events for an in-service Address or Terminal get delivered to observers that are implementing the CiscoAddressObserver and the CiscoTerminalObserver. Implementing only the observers does not do enough; the observers must also get added by address.addObserver() and, similarly, for the terminal by the terminal.addObserver() method. Note Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 19 Overview Initialization

Before invoking the call.connect() method, add a CallObserver to the address or terminal that is originating the call; otherwise, the method returns an exception. Note Address and Terminal Relationships The Cisco Unified Communications system architecture includes three fundamental types of endpoints: • Phones • Virtual devices (media termination points and route points) • Gateways Of these endpoints, only phones and media termination points get used by using the Cisco Unified JTAPI implementation. Cisco Unified Communications Manager allows users to configure phones to have one or more lines, dialable numbers, which multiple phones may share simultaneously, or lines can be configured for exclusive use by only one phone at a time. Each line on a phone can terminate two calls simultaneously, one of which must be on hold. This operation acts in a similar way to the operation of the “call waiting” feature on home phones. Figure 2: Phone Diagram, on page 20 shows two configurations: Peter and Mary share one phone line, 5001, while Paul has his own phone line, 5002. Figure 2: Phone Diagram A unique name identifies all types of Cisco Unified Communications Manager endpoints. The phone Media Access Control (MAC) address (such as, “SEP0010EB1014”) identifies it, and the system administrator can assign any name to a media termination point, so long as its name is unique. For each endpoint that a provider controls, the Cisco Unified JTAPI implementation uses the administrator-assigned name to construct a corresponding terminal object. Terminal objects in turn have one or more address objects, each of which corresponds to a line on the endpoint. Figure1-2 “Address and Terminal Relationship” shows a graphical representation of the relationship between addresses and terminals. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 20 Overview Address and Terminal Relationships

Figure 3: Address and Terminal Relationship If two or more endpoints share a line (DN), the corresponding address object relates to more than one terminal object. Unobserved Addresses and Terminals Cisco Unified JTAPI perceives calls only when a CallObserver attaches to the terminals and addresses of the provider. This means that methods such as Provider.getCalls() or Address.getConnections() will return null, even when calls exist at the address, unless a CallObserver attaches to the address. The system also requires adding a CallObserver to the address or terminal that is originating a call via the Call.connect() method. Connections Connections retain their references to calls and addresses forever. So, you can always use a connection reference that is obtained from a call event to obtain the connection call (getCall()) and address (getAddress()). Terminal Connections Terminal connections always retain their references to terminals and connections. So, you can always use a terminal connection reference that is obtained from a call event to obtain the terminal connection terminal (getTerminal()) and connection (getConnection()). Terminal and Address Restrictions Terminal and address restrictions prohibit applications from controlling and monitoring a certain set of terminals and addresses when the administrator configures them as restricted in Cisco Unified Communications Manager Administration. The administrator can configure a particular line on a device (address on a particular terminal) as restricted. If a terminal is added into the restricted list in Cisco Unified Communications Manager Administration, all addresses on that terminal also get marked as restricted in JTAPI. If an application comes up after the configuration completes, it can perceive whether a particular terminal or address is restricted from checking the interface CiscoTerminal.isRestricted() and CiscoAddress.isRestricted(Terminal). For shared lines, applications can query the interface CiscoAddress.getRestrictedAddrTerminals(), which indicates whether an address is restricted on any terminals. If a line (address on a terminal) is added into the restricted list after an application comes up, the applications will perceive CiscoAddrRestrictedEv. If the address has any observers, applications will recognize CiscoAddrOutOfService. When a line is removed from the restricted list, applications will perceive CiscoAddrActivatedEv. If an address has any observers, applications see CiscoAddrInServiceEv. Ifan application tries to add observers on an address after it is restricted, a PlatformException gets thrown. However, if any observers are added before the address is restricted, they will remain as is, but applications cannot get any events on these observers unless the address is removed from the restricted list. Applications can also choose to remove observers from an address. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 21 Overview Unobserved Addresses and Terminals

If a device (terminal) is added to the restricted list after an application comes up, the application will see CiscoTermRestrictedEv. If the terminal has any observers, the application will see CiscoTermOutOfService. If a terminal is added to the restricted list, JTAPI also restricts all addresses that belong to that terminal and applications will perceive CiscoAddrRestrictedEv. If a terminal is removed from the restricted list, applications will perceive CiscoTermActivatedEv and CiscoAddrActivatedEv for the corresponding addresses. If an application tries to add observers on a terminal after it is added to the restricted list, a PlatformException is thrown. However, if any observers are added before the terminal is restricted, they will remain as is, but applications cannot get any events on these observers unless the terminal is removed from the restricted list If a shared line is added to the restricted list after an application comes up, the application will perceive CiscoAddrRestrictedOnTerminalEv. If any address observers exist on the address, the application will recognize CiscoAddrOutOfServiceEv for that terminal. If all shared lines are added to the restricted list, when the last one is added, applications will perceive CiscoAddrRestrictedEv. If a shared line is removed from the restricted list after the application comes up, applications will perceive CiscoAddrActivatedOnTerminalEv. If any observers exist on the address, the application will perceive CiscoAddrInServiceEv for that terminal. Ifall shared lines in the control list are removed from the restricted list, applications will recognize CiscoAddrActivatedEv when the last one is removed, and all addresses on terminals will receive InService events. If all shared lines in the control list are marked as restricted, and an application tries to add observers, a platform exception gets thrown. If a few shared lines are in the restricted list, while others are not, when an application adds an observer on the address only nonrestricted lines will go in service. If any active calls are present when an address or terminal is added to the restricted list and reset, applications will recognize connection and TerminalConnections get disconnected. If no addresses or terminals are added to the restricted list, this feature remains backward compatible with earlier versions of JTAPI: no new events get delivered to applications. The following sections describe the interface changes for address and terminal restrictions. CiscoTerminal isRestricted() Indicates whether a terminal is restricted. If the terminal is restricted, all associated addresses on this terminal also get restricted. Returns true if the terminal is restricted; returns false if it is not restricted. boolean CiscoAddress getRestrictedAddrTerminals() Returns an array of terminals on which this address is restricted. If none are restricted, this method returns null. In shared lines, a few lines on terminals may get restricted. This method returns all the terminals on which this particular address is restricted. Applications cannot perceive any call events for restricted lines. If a restricted line is involved in a call with any other control device, an external connection gets created for the restricted line. javax.telephony.Terminal[] isRestricted(javax.telephony.Terminal terminal) Returns true if any address on this terminal is restricted.Returns false if no addresses on this terminal are restricted. boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 22 Overview Terminal and Address Restrictions

public interface CiscoRestrictedEv extends CiscoProvEv { public static final int ID

com.cisco.jtapi.CiscoEventID.CiscoRestrictedEv; /**

• The following define the cause codes for restricted events */ public final static int CAUSE_USER_RESTRICTED = 1; public final static int CAUSE_UNSUPPORTED_PROTOCOL = 2; } This represents the base class for restricted events and defines the cause codes for all restricted events. CAUSE_USER_RESTRICTED indicates the terminal or address is marked as restricted. CAUSE_UNSUPPORTED_PROTOCOL indicates that the device in the control list is using a protocol that Cisco Unified JTAPI does not support. Existing Cisco Unified IP 7960 and 7940 phones that are running SIP fall in this category. CiscoAddrRestrictedEv Public interface CiscoAddrRestrictedEv extends CiscoRestrictedEv. Applications will recognize this event when a line or an associated device is designated as restricted from Cisco Unified Communications Manager Administration. For restricted lines, the address will go out of service and will not come back in service until it is activated again. If an address is restricted, addCallObserver and addObserver will throw an exception. For shared lines, if a few shared lines are restricted, and others are not, no exception gets thrown, but restricted shared lines will not receive any events. If all shared lines are restricted, an exception gets thrown when observers are added. If an address is restricted after observers are added, applications will perceive CiscoAddrOutOfServiceEv, and when the address is activated, the address will go in service. CiscoAddrActivatedEv Public interface CiscoAddrActivatedEv extends CiscoProvEv. Applications will perceive this event whenever a line or an associated device is in the control list and is removed from the restricted list in the Cisco Unified Communications Manager Administration. If any observers exist on the address, applications will perceive CiscoAddrInServiceEv. If no observers exist, applications can try to add observers, and the address will go in service. CiscoAddrRestrictedOnTerminalEv Public interface CiscoAddrRestrictedOnTerminalEv extends CiscoRestrictedEv. If a user has a shared address in the control list, and if one of the lines is added into the restricted list, this event will get sent. Interface getTerminal() returns the terminal on which the address is restricted. Interface getAddress() returns the address that is restricted. getAddress() javax.telephony.Address getTerminal() javax.telephony.Terminal CiscoAddrActivatedOnTerminal Public interface CiscoAddrActivatedOnTerminalEv extends CiscoProvEv. When a shared line or a device that has a shared line is removed from the restricted list, this event will get sent. The interface getTerminal() returns the terminal that is being added to the address. The interface getAddress() returns the address on which the new terminal is added. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 23 Overview Terminal and Address Restrictions

getAddress() javax.telephony.Address getTerminal() javax.telephony.Terminal CiscoTermRestrictedEv Public interface CiscoTermRestrictedEv extends CiscoRestrictedEv. Applications will perceive this event when a device is added into restricted list from Cisco Unified Communications Manager Administration after the application launches. Applications cannot perceive events for restricted terminals or addresses on those terminals. If a terminal is restricted when it is in InService state, applications will get this event, and terminal and corresponding addresses will move to the out-of-service state. CiscoTermActivatedEv Public interface CiscoTermActivatedEv extends CiscoRestrictedEv. getTerminal() Returns the terminal that is activated and is removed from the restricted list. javax.telephony.Terminal CiscoOutOfServiceEv CAUSE_DEVICE_RESTRICTED Indicates whether an event is sent because a device is restricted. static int CAUSE_LINE_RESTRICTED Indicates whether an event is sent because a line is restricted. static int CiscoCallEv CAUSE_DEVICE_RESTRICTED Indicates whether an event is sent because a device is restricted. static int CAUSE_LINE_RESTRICTED Indicates whether an event is sent because a line is restricted. static int CiscoConnectionID The CiscoConnectionID object represents a unique object that is associated with each connection in Cisco Unified JTAPI. Applications may use the object itself or the integer representation of the object. Threaded Callbacks The Cisco Unified JTAPI implementation design allows applications to invoke blocking JTAPI methods such as Call.connect() and TerminalConnection.answer() from within their observer callbacks. This means that Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 24 Overview CiscoConnectionID

applications 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

CiscoTransferStartEv For the CiscoTransferStartEv, the references to the transferred call, transfer controller, and final call in the event become valid when callChangedEvent() is called. However, getConnections() may or may not return the connections on these calls. Alarm Services Part of the general serviceability framework for Cisco Unified Communications applications includes support for sending alarms to a service. The com.cisco.services.alarm package defines the alarm components. An alarm interface and framework support the sending of alarm notifications in XML over TCP to an Alarm Service that is available on the network in a Cisco Unified JTAPI application. The alarm package includes the following features: • XML definition of alarms, resolved by a catalog in the alarm service • A bounded rollover queue to buffer alarms at the sender • Alarm sending on a separate thread to avoid blocking at the sending application • A TCP-based reconnection scheme to the alarm service The overall framework of the Cisco Unified JTAPI alarm system includes similarities to the existing JTAPI tracing package. Applications must instantiate an AlarmManager for a particular facility code from which alarm objects can be created. Part of the implementation includes DefaultAlarm and DefaultAlarmWriter implementation classes. Software Requirements The following table lists the software requirements for JTAPI applications, JTPREFS, and sample code. Required Software Application Any JDK 1.6 compliant Java environment JTAPI applications Any JDK 1.6 compliant environment. JTPREFS Any JDK 1.6 compliant Java environment JTPREFS Development Guidelines Cisco maintains a policy of interface backward compatibility for at least one previous major release of Cisco Unified Communications Manager (Cisco Unified CM). Cisco still requires Cisco Technology Developer Program member applications to be retested and updated as necessary to maintain compatibility with each new major release of Cisco Unified CM. The following practices are recommended to all developers, including those in the Cisco Technology Developer Program, to reduce the number and extent of any updates that may be necessary: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 26 Overview CiscoTransferStartEv

• The order of events and/or messages may change. Developers should not depend on the order of events or messages. For example, where a feature invocation involves two or more independent transactions, the events or messages may be interleaved. Events related to the second transaction may precede messages related to the first. Additionally, events or messages can be delayed due to situations beyond control of the interface (for example, network or transport failures). Applications should be able to recover from out of order events or messages, even when the order is required for protocol operation. • The order of elements within the interface event or message may change, within the constraints of the protocol specification. Developers must avoid unnecessary dependence on the order of elements to interpret information. • New interface events, methods, responses, headers, parameters, attributes, other elements, or new values of existing elements, may be introduced. Developers must disregard or provide generic treatments where necessary for any unknown elements or unknown values of known elements encountered. • Previous interface events, methods, responses, headers, parameters, attributes, and other elements, will remain, and will maintain their previous meaning and behavior to the extent possible and consistent with the need to correct defects. • Applications must not be dependent on interface behavior resulting from defects (behavior not consistent with published interface specifications) since the behavior can change when defect is fixed. • Use of deprecated methods, handlers, events, responses, headers, parameters, attributes, or other elements must be removed from applications as soon as possible to avoid issues when those deprecated items are removed from Cisco Unified CM. • Application Developers must be aware that not all new features and new supported devices (for example, phones) will be forward compatible. New features and devices may require application modifications to be compatible and/or to make use of the new features/devices. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 27 Overview Development Guidelines

Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 28 Overview Development Guidelines

C H A P T E R 3 Features Supported by Cisco Unified JTAPI This chapter describes features supported by the Cisco Unified JTAPI specification. • Account Lockout, on page 33 • Agent Greeting, on page 33 • AES 256 Algorithm IDs, on page 34 • Alternate Script Support, on page 35 • API for Exposing Built-In-Bridge Status, on page 35 • Arabic and Hebrew Language Support, on page 36 • Auto Updater for Linux, on page 36 • AutoAccept Support for CTI Ports and Route Points, on page 37 • Autoupdate of API, on page 38 • Barge and Privacy Event Notification, on page 40 • Call Control Discovery, on page 41 • Call Forward, on page 41 • Call Forward Override, on page 41 • Call Park, on page 42 • Call Pickup, on page 42 • Call Recording for SIP or TLS Authenticated Calls, on page 43 • Call Select Status, on page 43 • Calling Party Display Name, on page 44 • Calling Party IP Address, on page 44 • Calling Party IP Address, on page 45 • Calling Party Normalization, on page 46 • CallFwdAll Key Press Notification, on page 46 • CallSelect and UnSelect Event Notification, on page 47 • Certificate Download API Enhancement, on page 47 • Changes in DeviceType Name Handling, on page 47 • Cisco MediaTerminal, on page 48 • Cisco Unified Communications Manager Media Endpoint Model, on page 51 • Cisco Unified Communications Manager Server Failure, on page 53 • Cisco Unified IP 7931G Phone Interaction, on page 54 • Cisco Unified JTAPI Install Internationalization, on page 55 • Cisco VG248 and ATA 186 Analog Phone Gateways, on page 55 • CiscoJtapiExceptions, on page 55 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 29

• CiscoProvAuthenticationInfoEv, on page 56 • CiscoRTPHandle Interface on Cisco RTP Events, on page 57 • Cisco Terminal Filter and ButtonPressedEvents, on page 57 • CiscoTermRegistrationfailed Event, on page 58 • Cius Persistency, on page 59 • Clear Calls, on page 60 • Click to Conference, on page 60 • Cluster Abstraction, on page 61 • Command Line Invocation, on page 62 • Component Updater, on page 62 • Conference, on page 63 • Conference and Join, on page 66 • Conference Chaining, on page 67 • Consult Without Media, on page 68 • CTI Ports, on page 69 • CTI RoutePoints, on page 69 • CTI Remote Device for JTAPI, on page 69 • CTI RD Call Forward, on page 72 • CTI Video Support, on page 73 • Default CTI IP Addressing for Devices, on page 75 • DeleteCall, on page 75 • Device Recovery, on page 75 • Device Recovery for Phones, on page 75 • Device State Server, on page 76 • Direct Transfer Across Lines, on page 77 • Directed Call Park, on page 82 • Directory Change Notification, on page 83 • Do Not Disturb, on page 83 • Do Not Disturb-Reject, on page 84 • Drop Any Party, on page 85 • Dynamic CTI Port Registration, on page 86 • E911 Teleworker, on page 88 • Enable or Disable Ringer, on page 88 • Encryption Enhancement, on page 89 • End to End Call Tracing, on page 89 • EnergyWise Deep Sleep Mode, on page 90 • Extension Mobility Cross Cluster, on page 92 • Extension Mobility Username Login, on page 93 • External Call Control, on page 93 • End to End Session ID for Calls, on page 94 • FIPS Compliance, on page 95 • Forced Authorization and Client Matter Codes, on page 98 • Forwarding on No Bandwidth and Unregistered DN, on page 100 • GetCallID in RTP Events, on page 100 • GetCallInfo, on page 101 • GetGlobalCallID, on page 101 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 30 Features Supported by Cisco Unified JTAPI

• Hairpin Support, on page 101 • Half-Duplex Media Support, on page 102 • Hold Reversion, on page 103 • Hunt List, on page 103 • Hunt List Connected Number, on page 105 • Hunt Log Status, on page 105 • Intercom, on page 106 • Intercom Support for Extension Mobility, on page 108 • IPv6 Support, on page 108 • iSac Codec, on page 109 • Java Socket Connect Timeout, on page 110 • Join Across Lines, on page 110 • Join Across Lines (Only SCCP), on page 111 • Join Across Lines with Conference Enhancements (SCCP and SIP), on page 116 • JRE 1.2 and JRE 1.3 Support Removal, on page 117 • JTAPI Version Information, on page 118 • Locale Infrastructure Development, on page 118 • Logical Partitioning, on page 119 • Media Termination at Route Point, on page 119 • Media Termination Extensions, on page 122 • Message Waiting Indicator Enhancement, on page 122 • Modifying Calling Number, on page 123 • Multi-fork Recording using CUBE Media Proxy Server, on page 125 • Multilevel Precedence and Preemption Support, on page 125 • Multiple Calls Per DN, on page 125 • Native Queuing, on page 125 • Network Alerting, on page 127 • Network Events, on page 128 • New Error Code in CiscoTermRegistrationFailedEv, on page 128 • Noncontroller Adding of Parties to Conferences, on page 129 • Park DN Monitor, on page 129 • Park Monitoring and Assisted DPark Support, on page 129 • Park Reminder, on page 131 • Park Retrieval, on page 131 • Partition Support, on page 132 • Password Expiry, on page 135 • Persistent Connection, on page 135 • Play Zip Tone, on page 137 • Presentation Indicator for Calls, on page 138 • Privacy On Hold, on page 139 • Progress State Converted to Disconnect State, on page 140 • Q.Signaling (QSIG) Path Replacement, on page 140 • QoS Support, on page 140 • Quiet Clear, on page 142 • Receiving and Responding to Media Flow Events, on page 142 • Recording, on page 144 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 31 Features Supported by Cisco Unified JTAPI

• Redirect, on page 147 • Redirect Set Original Called ID, on page 148 • Redirect to Device, on page 149 • Redundancy, on page 150 • Redundancy in CTI Managers, on page 150 • Ringback on SIP 183 for Transferred Calls, on page 153 • Routing, on page 153 • Secure Conferencing, on page 155 • Secure Real-Time Protocol Key Material, on page 156 • Secured Monitoring and Recording, on page 162 • SelectRoute Interface Enhancement, on page 163 • selectRoute() with Calling Search Space and Feature Priority, on page 164 • Set MessageWaiting, on page 164 • Shared Line Support, on page 165 • Silent Monitoring, on page 167 • Single Sign-On, on page 170 • Single Step Transfer, on page 171 • SIP 3XX Redirection, on page 172 • SIP Phone Support, on page 173 • SIP REFER or REPLACE, on page 176 • SIP Trunk Early Offer, on page 177 • Star (*) 50 Update, on page 180 • Super Provider (Disable Device Validation), on page 180 • Superprovider and Change Notification, on page 181 • Support for Cisco Unified IP Phone 6901, on page 183 • Support for Cisco Unified IP Phone 6900 Series, on page 184 • Support for 100+ Directory Numbers, on page 185 • Support for VMware, on page 186 • Swap or Cancel and Transfer or Conference Behavior, on page 187 • Terminal and Address Capability Settings, on page 188 • Terminal and Address Restrictions, on page 189 • SHA-512 Support for Digital Signatures, on page 193 • Transfer, on page 193 • Transfer and Conference Extensions, on page 196 • Transfer and DirectTransfer, on page 196 • Translation Pattern Support, on page 197 • Transport Layer Security (TLS), on page 198 • Unicode Support, on page 205 • Unrestricted Unified CM, on page 207 • URI Dialing, on page 208 • Version Format Change, on page 209 • Verification Involving PSTN Reachability, on page 209 • Video Capabilities and Multi-Media Information, on page 209 • Video On Hold Support, on page 213 • Voice MailBox Support, on page 214 • XSI Object Pass Through, on page 214 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 32 Features Supported by Cisco Unified JTAPI

Account Lockout The administrator can use the CUCM Admin Panel to configure options for the account lockout. To configure account lockout options, an administrator can perform either of the following: 1. Click the Locked by Administrator checkbox in the user credential page. 2. Set the number of login attempts, which signifies the number of failed logins due to invalid credentials. 3. Set the maximum idle time (in days) and if the user does not login for that many days, the account is locked. In case of account lockout, JTAPI delivers detailed exceptions without any warning messages. JTAPI does not allow applications to modify any of these values, it only reports the information. Interface Changes CiscoJtapiExceptions, on page 55 Message Sequences There are no message sequences. Backward Compatibility This feature is backward compatible. Agent Greeting The Agent Greeting feature enables the JTAPI application to instruct the Cisco Unified Communications Manager to automatically play a pre-recorded announcement following a successful media connection to the agent device. The greeting helps to keep the agent sounding fresh as they do not have to repeat common phrases on each call. Agent Greeting is audible for the agent and the customer. Agent Greeting can be initiated from any phone with a Built-in-Bridge (BIB). A call is initiated from the BIB to the DN specified in the request. Applications are responsible for answering this call and playing the media. There are two types of calls: • A basic call between the customer and agent. • A secondary call, known as the Interactive Voice Response (IVR) call, which is created between an IVR device and the BIB of the agent phone. The application invokes the new Agent Greeting API on a call, which creates an IVR call. The application then answers the call, and is responsible to play a recorded message. The connection is not created for the agent on the IVR call, and as a result, the applications see the secondary call only. The IVR call has only one connection to play the IVR message. Regardless of whether or not the application observes the IVR device, the Agent Greeting media plays. Observers on the agent receive an event to start the media. When the media finishes, the application must Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 33 Features Supported by Cisco Unified JTAPI Account Lockout

disconnect the IVR or CTI port that streams the media. When the second call is disconnected, an event is sent to observers on the agent and receives an event to end the media. This feature is available only on phones that have BIBs. The majority of Cisco Unified IP Phones have BIBs, but the feature may not be available in various older or lower-end phone models. Administrators must enable the BIB for the device and configure it using the Cisco Unified Communications Manager Admin panel. Whenever a request to addMediaStream is made, JTAPI blocks the request until the IVR device answers the call or CTI responds with a timeout error. Due to this, the JTAPI thread that invoked the addMediaStreamRequest cannot answer its own call, because it is blocked waiting for the request to finish. Applications intending to use this feature must ensure that one of the following is applicable: • The IVR DN is configured to auto-answer incoming calls • A separate JTAPI thread or application is set up to answer on the IVR DN Interface changes See CiscoTerminalConnection, on page 636, CiscoFeatureReason, on page 408, CiscoJtapiException, on page 416, CiscoMediaStreamStartedEv, on page 431, CiscoMediaStreamEndedEv, on page 432 Message Sequences See Agent Greeting, on page 762 Backward Compatibility This feature is backward compatible. • This is a new feature and has no impact on existing features. • There are two new events for this feature, but they are only generated if the application observes the addresses in which the feature is invoked. • The odd call model for the IVR call, with only one connection, can have implications for applications that look at the number of connections for any of their logic. • Feature interaction is not supported on IVR calls. For example, invoking features such as redirect and creating a conference from the IVR call are not supported. • The IVR call is intended to stream media. Applications invoke features on the IVR call at their own risk and there are no event flows or call diagrams for any feature interaction on the IVR calls. AES 256 Algorithm IDs From release 10.5(2) Cisco Unified Communications Manager now supports the following encryption algorithm IDs: • CiscoMediaEncryptionAlgorithmType • CiscoMediaEncryptionAlgorithmType.AES_128_COUNTER_80 • CiscoMediaEncryptionAlgorithmType.F8_128_COUNTER_32 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 34 Features Supported by Cisco Unified JTAPI AES 256 Algorithm IDs

• CiscoMediaEncryptionAlgorithmType.F8_128_COUNTER_80 • CiscoMediaEncryptionAlgorithmType.AEAD_128_COUNTER • CiscoMediaEncryptionAlgorithmType.AEAD_256_COUNTER The CiscoMediaEncryptionAlgorithmType.AEAD_128_COUNTER and CiscoMediaEncryptionAlgorithmType.AEAD_256_COUNTER will be negotiated only for a secure call between two SIP endpoints. CTI ports can register with any of the above algorithms, but will negotiate on AES_128_COUNTER_80 for secure calls. From Release 12.5(1)SU5 onwards, CTI ports can register with any of the above algorithms for secure calls. For more information, see "Stronger Cipher Suites on CTI Ports" section in Security Guide for Cisco Unified Communications Manager. Note Alternate Script Support Certain IP phone types support an alternate language script other than the default script that corresponds to the phone-configurable locale. For example, the Japanese phone locale has two written scripts. Some phone types support only the default Katakana script, while other phones types support both the default script and the alternate Kanji script. Because applications can send text information to the phone for display purposes, they need to know what alternate script a phone supports, if any. The new getAltScript() method provides alternate script information for an observed device. Currently there is only one known alternate script: Kanji for the Japanese locale. JTAPI provides a new method for CiscoTerminal to provide alternate script information. getAltScript() Only one alternate script, Kanji for the Japanese locale, is currently supported. An empty string return value indicates there is no alternate script configured or the terminal does not support an alternate script. java.lang.String Backward Compatibility The alternate script feature does not impact JTAPI backward compatibility. API for Exposing Built-In-Bridge Status JTAPI exposes the API, CiscoTerminal.isBuiltInBridgeEnabled() to let applications know if the BIB capability is enabled on the terminal or not. Accordingly, the return value is true or false. This API throws MethodNotSupportedException if it is invoked on a CiscoMediaTerminal or a CiscoRouteTerminal as these devices do not support a BIB. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 35 Features Supported by Cisco Unified JTAPI Alternate Script Support

This API throws InvalidStateException if invoked on a terminal that is not registered with the Cisco Unified Communications Manager. Interface Changes See CiscoTerminal, on page 617 Message Sequences See API for Exposing Built-in-Bridge Status, on page 766 Backward Compatibility This change is backward compatible and does not affect the existing applications. Arabic and Hebrew Language Support This version of the Cisco Unified JTAPI supports the Arabic and Hebrew languages, which users may select during installation and in the Cisco Unified JTAPI Preferences user interface. Backward Compatibility This feature is backward compatible. Auto Updater for Linux In order to support this feature for Linux based JTAPI client machines, auto updater feature has the following changes in its interface. The interface required that applications provide component name, provider IP address, user name and password. Applications do not need to specify an URL for downloading the component. This is done to avoid the issue with updater application in case URL changes between various releases of Cisco Unified Communications Manager Administration. A new API called “Replace()” is part of the component interface. This facilitates replacing of old component with a newly downloaded component. The following section defines the operation of updater after the new interface changes. The new updater will: • Use the same API signature as the old one. • Create a file newjtapi.jar in the current folder of application which is the new version of the jar file. • Copy the current jtapi.jar to a file by name component.temp in the classpath specified. • Replace the current jar file with the new jar file. At the end of this operation, the current jar file becomes the component.temp and new jar file becomes jtapi.jar. Applications can still use old component interface which take URL either by specifying the URL themselves or by querying the URL through the new interface provided on CiscoProvider. The API required to get the URL information is present in the Interface summary for this feature. This operation is supported for both Unix and Windows. Backward compatibility This feature is not backward compatible. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 36 Features Supported by Cisco Unified JTAPI Arabic and Hebrew Language Support

AutoAccept Support for CTI Ports and Route Points This feature provides applications with the ability to enable or disable AutoAccept for the addresses on CTIPorts and Route Points. When AutoAccept status changes for the address, Cisco Unified JTAPI provides the event to inform the application for changes. The maximum number of lines that are supported for route points equals 34. Note The new interface setAutoAcceptStatus(), provided on the CiscoAddress object, allows the capability to set AutoAccept to ON or OFF. Interface getAutoAcceptStatus(), also provided on the CiscoAddress object, allows applications to query the current status of AutoAccept on the address. When AutoAccept status changes for the address, applications get CiscoAddrAutoAcceptStatusChangedEv on AddressObservers. This event includes the interface getTerminal(), which returns the terminal on which the AutoAccept status gets changed, and the interface getAutoAcceptStatus(), which returns integers that specify whether AutoAccept is ON or OFF. If an address observer is not added, the event does not get provided. The following interfaces support AutoAccept on CTIPort and RoutePoint: Cisco Address • init init getAutoAcceptStatus (javax.telephony.Terminal terminal) Ciscoaddress.getAutoAccept(Terminal iterminal) returns an AutoAccept status of address on terminal. • void setAutoAcceptStatus (int autoAcceptStatus, javax.telephony.Terminal terminal) This allows an application to enable AutoAccept for addresses on the CiscoMediaTerminal and or the CiscoRouteTerminal. CiscoAddrAutoAcceptStatusChangedEv CiscoAddrAutoAcceptStatusChangedEv Public interface: CiscoAddrAutoAcceptStatusChangedEv Extends com.cisco.jtapi.exension.CiscoAddrEv The CiscoAddrAutoAcceptStatusChangedEv event gets sent to applications whenever AutoAccept status for the address on the terminal gets changed. If an address has multiple terminals, this event gets sent for the address AutoAccept status on each individual terminal. This event provides the following interface: • init getAutoAcceptStatus () CiscoAddrAutoAcceptStatusChangedEv.getAutoAcceptStatus returns the following value of AutoAccept status of address on terminal CiscoAddress.AUTOACCEPT_OFF CiscoAddress.AUTOACCEPT_ON. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 37 Features Supported by Cisco Unified JTAPI AutoAccept Support for CTI Ports and Route Points

• com.cisco.jtapi.extensions.CiscoTerminal getTerminal () Returns the terminal at which this address AutoAccept status gets changed. For details on the interface changes, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for AutoAccept on CTIPort and RoutePoint, see Message Sequence Charts, on page 761 Autoupdate of API Be aware that when the Cisco Unified Communications Manager is upgraded to a higher version, the APIs may or may not be compatible with the new Cisco Unified Communications Manager version. Ensure that the APIs are upgraded to a compatible version, so the applications work as expected. Because the APIs are installed locally on the client server, the upgrade must take place on multiple machines. In the case of fewer client applications, you can easily do this by connecting to the Cisco Unified Communications Manager Administration and downloading and installing the Cisco Unified Communications Manager compatible plug-in. For multiple client applications, this feature provides a facility by which an application at startup can identify itself to a web server via an HTTP request and receives a response with the version of the required JTAPI API. The application compares the version that is available on the server to the local version in the application classpath and determines whether an upgrade is necessary. This allows applications to refresh the jtapi.jar component to match the Cisco Unified Communications Manager and provides a way to centrally deploy the jtapi.jar to which applications can auto update. The API that is required to perform this functionality gets packaged in the form of an updater.jar. The jtapi.jar and updater.jar get packaged with the standard manifest, which can be used to compare versions. This feature does not update JTAPI Preferences, JTAPITestTools, Updater.jar and javadoc components. If applications require these components, install JTAPI from the Cisco Unified Communications Manager plug-in pages. Auto Update supports JTAPI Release 2.0 and later. Note Refer to Cisco Unified JTAPI Installation, on page 217 for more information. The following new or changed interfaces exist for autoupdate of APIs: Class com.cisco.services.updater.ComponentUpdater queryLocalComponentVersion (java.lang.String componentName, java.lang.String path) Throws an IOException, IllegalArgumentException. Component queryServerComponentVersion (java.lang.String componentName, java.lang.String urlString) Throws an IOException, IllegalArgumentException, and sends an HTTP query to the server to determine the remote server installed components version. Component Interface com.cisco.services.updater.Component Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 38 Features Supported by Cisco Unified JTAPI Autoupdate of API

compareTo (Component otherComponent) int fetchFromServer () Performs an HTTP fetch of the component from the server and writes to the local file system with the file name temp.jar in the local directory. Component getBuildDescription () Returns the string 'Release' for a version of the form 'a.b(c.d) Release'. java.lang.String getBuildNumber () Returns 'd' for a version of the form a.b(c.d). int getLocation () The string form location of the component. java.lang.String getMajorVersion () Returns 'a' version for a version of the form a.b(c.d). int getMinorVersion () Returns 'b' version for a version of the form a.b(c.d). int getName () Returns the name of the component. java.lang.String getRevisionNumber () Returns 'c' for a version of the form a.b(c.d). int The Autoupdater feature in JTAPI also allows applications to download the latest version of JTAPI.JAR directly from the Cisco Unified Communications Manager. 1. Updater creates a newjtapi.jar file in the current folder of the application, which represents the new version of the jar file that was downloaded from the Cisco Unified Communications Manager. 2. Updater copies the current jtapi.jar to a file that is named component.temp in the classpath specified. 3. Updater replaces the current jtapi.jar file with the new jtapi.jar file. At the end of this operation, the current jar file becomes component.temp and the new jar file becomes jtapi.jar. This operation is supported for both Linux and Windows. Example Usage of Autoupdater Command Line : java com.cisco.services.updater.ComponentUpdater <server> <component name> <login> <passwd>Component localComponent, downloadedComponent; ComponentUpdater updater

new ComponentUpdater(); String localPath

updater.getLocalComponentPath(args[1]); localComponent

updater.queryLocalComponentVersion("jtapi.jar", localPath); localComponent.copyTo("component.temp"); String provString

args[0] + ";login = " + args[2] + ";passwd = " + args[3]; CiscoJtapiPeer peer

(CiscoJtapiPeer) (JtapiPeerFactory.getJtapiPeer(null)); CiscoJtapiProperties tempProp

( (CiscoJtapiPeerImpl) (peer)). getJtapiProperties(); tempProp.setLightWeightProvider(true); Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 39 Features Supported by Cisco Unified JTAPI Autoupdate of API

Provider provider

peer.getProvider(provString); String url

( (CiscoProvider) (provider)).getJTAPIURL(); provider.shutdown(); Component serverComponent

updater.queryServerComponentVersion("jtapi.jar", url); downloadedComponent

serverComponent.fetchFromServer(); int retVal

downloadedComponent.replaces(localComponent); The “replaces” API will replace the existing JTAPI version with the new version. The updater will only update the JTAPI.JAR file and not the other sample applications and Cisco JTAPI documentation that are bundled with the JTAPI plug-in. To get these other components, applications must download the plug-in from the Cisco Unified Communications Manager and install it. Note Barge and Privacy Event Notification The Barge Feature provides the ability for shared addresses to barge into an established call of address on another terminal. This feature gets activated when an address TerminalConnection is in the passive state and CallCtlTerminalConnection is in the bridged state. This version of Cisco Unified JTAPI only supports feature activation manually on application-controlled terminals (IP phones). For this release, you cannot activate the feature through an API. The Privacy feature provides the ability to enable or disable other shared addresses to barge into call. When privacy is enabled, other shared addresses cannot barge into a call and vice versa. Privacy represents a terminals property. IP phones have a “Privacy” softkey and pressing it enables or disables the privacy. Privacy can be dynamically enabled or disabled for the active calls on the terminal. When privacy is on for the call, the TerminalConnection for the call appearances on the shared address appear in the “InUse” state. If privacy status changes during the CallProgress, CiscoTermConnPrivacyChangedEvent gets delivered to the application. Two types of barge feature functionalities exist in Cisco Unified Communications Manager: one uses built-in conference bridge called “Barge, ” while another uses shared conference bridge resources called “CBarge”. From the application point of view, no interface changes exists between Barge and CBarge; however, some behavioral changes, which are described in the message flow diagram in Message Sequence Charts, on page 761 occur. Barge, CBarge, and Privacy have these interfaces: Interface CiscoTerminalConnection.getPrivacyStatus() booleangetPrivacyStatus() This interface returns the privacy status of a call on the terminal. Interface CiscoTermConnPrivacyChangedEv javax.telephony.TerminalConnectiongetTerminalConnection() A new reason code, CiscoCall.CAUSE_BARGE gets added to CiscoCall for barge events. JTAPI provides CallCtiCause as CiscoCall.CAUSE_BARGE when a SharedLine TerminalConnection or CallCtiTerminalConnection goes to an active or talking state as a result of barge. This cause code also gets provided in CallCtiEvents for dropping temporary calls that are created during the barge operation. This cause code is not provided for the CBarge scenario. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 40 Features Supported by Cisco Unified JTAPI Barge and Privacy Event Notification

For details on these interfaces, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for barge, CBarge, and privacy, see Message Sequence Charts, on page 761. Call Control Discovery The Call Control Discovery (CCD) feature facilitates provisioning for inter-call agent communications. It uses the Service Advertisement Framework (SAF) network service to advertise itself as a call control entity and to discover other call control entities (Cisco Unified Communications Managers or CMEs) on the network so that it can dynamically adapt their routing behavior. When a call is made between two devices on different clusters and the call is rejected with a cause code other than unallocated , unassigned number and user busy, the CCD feature fails over the call to a PSTN network. That is, the call is routed through a PSTN network instead of an IP network to reach the same destination. JTAPI supports the SAF CCD feature. However, applications are not notified when a normal SAF call fails over to a PSTN trunk. JTAPI exposes a new reason CiscoFeatureReason.REASON_SAF_CCD_PSTN_FAILOVER for the new connection created for the redirect or forward destination. This occurs when there is a redirect or forward across the cluster through an SAF trunk and the call fails over to a PSTN trunk. Interface Changes See CiscoFeatureReason, on page 408 Message Sequences See Call Control Discovery, on page 785 Backward Compatibility This feature is backward compatible. Call Forward Cisco Unified JTAPI supports setting the Call Forward feature according to the JTAPI Specification. Cisco Unified JTAPI implementation does not support all the forwarding characteristics but supports only the FORWARD_ALL attribute for the Address. Applications can invoke setForwarding, getForwarding, and cancelForwarding methods on a CallControlAddress object, but the CallControlForwarding instruction can only be of type FORWARD_ALL. Call Forward Override This feature provides a mechanism to override the call forward all feature. If a user (CFA Initiator) sets CFA to another user (CFA target), the CFA should be ignored if the CFA target calls the CFA initiator. This would allow the CFA Target to reach the CFA Initiator for important calls. The behavior of this CallManager feature is configurable via service parameter - CFADestinationOverride. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 41 Features Supported by Cisco Unified JTAPI Call Control Discovery

Example: Alice has a phone with DN 1000 * Bob has a phone with DN 2000 * Daniel has a phone with DN 4000 * Alice does a CFA to 2000 CFA behavior * Bob calls Alice. Call goes to Alice and does not follow CFA back to himself. * Daniel calls Alice. Call follows CFA to Bob. * Bob answers and transfers the call to Alice. Bob can do this because Alice has her phone forwarded to Bob. There is no interface change to JTAPI layer with this feature. However JTAPI applications could perceive a difference in behavior when CiscoAddress.setForward() API is invoked. In scenario where CFA target calls the CFA initiator as described in example, call is not forwarded if feature is enabled. Backward Compatibility JTAPI applications that were written for Release 5.0 should be backward compatible with Release 5.1. JTAPI Client Upgrade Application does not require JTAPI Client upgrade to run or be backward compatible. JTAPI Client upgrade is required only if new features are used. Call Park Cisco Unified JTAPI supports user interactions with Call Park and reports the appropriate events to the applications. When a call is parked from an IP phone, the connection that belongs to the parking address moves into Disconnected state, and the associated TerminalConnection moves into Dropped state. A new connection in queued state for the park number gets created. If an application is monitoring only the address that parked the call, all existing connections get Disconnected, TerminalConnections get Dropped, and the call moves to Invalid state. Call Pickup Call Pickup enables devices to receive alerts within Call Pickup Groups and events, to act on these alerts by invoking APIs that support variants of Call Pickup. These APIs allow applications to gather information about existing Call Pickup groups, and register and unregister for receiving pickup alerts for specific pickup groups. JTAPI supports invoking Pickup, Group Pickup, Other Pickup, and Directed Call Pickup from applications. In Cisco Unified Communications Manager releases prior to release 8.0(1), all these features except Other Pickup were supported as observed events, but were not invoked. Call Pickup is not supported on CTI route points. Note Interface Changes CiscoPickupGroup, on page 478, CiscoAddress, on page 289, CiscoTerminal, on page 617, CiscoProvider, on page 492, CiscoProviderCapabilities, on page 504, CiscoProvPickupCallAlertEv, on page 487, ProviderPickupNotificationRegistrationClosedEv, on page 671, CiscoAddrPickupGroupChangedEv, on page 313. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 42 Features Supported by Cisco Unified JTAPI Call Park

Message Sequences Call Pickup, on page 1109 Backward Compatibility This feature is backward compatible. Call Recording for SIP or TLS Authenticated Calls Prior to 12.5(1) version, the phones which are authenticated (phone with Security profile having Device Security Mode as Authenticated) were not allowed to make use of the Call Recording feature. Whereas, Non–Secured phones or Secured/ Encrypted phones could use Call Recording feature with Non-Secured or Secured recorders, respectively. With the release 12.5(1), Cisco Unified CM JTAPI interface has been enhanced to allow recording in Authenticated Phones based on the value of the new service parameter Authenticated Phone Recording. The expectation is that the authenticated phones should also be allowed to make use of the Call Recording feature. It depends on value set in the newly added service parameter Authenticated Phone Recording which can be set to the following values: • Allow Recording – Authenticated Phones can be allowed to record the calls. • Do Not Allow Recording – Authenticated Phones cannot make use of Call Recording feature. This is the default value for the service parameter. The behavior would be the same as that of the current behavior. Backward Compatibility This feature is backward compatible. JTAPI will support the current API’s. Call Select Status Cisco Unified JTAPI sends CiscoTermConnSelectChangedEv event whenever the call is selected either by feature or by manually. Once application receives the event, application can use TerminalConnection.getSelectStatus() to get proper call select status. There are three possible statuses by calling TerminalConnection.getSelectStatus() as follows: • CiscoTerminalConnection. CISCO_SELECTEDNONE: The select status means that the call is not selected • CiscoTerminalConnection. CISCO_SELECTEDLOCAL: The select status means that the call is selected on the terminal connection • CiscoTerminalConnection. CISCO_SELECTEDREMOTE: Passive TerminalConnection will get this select status if the call is selected by it's shared line Backward compatibility This feature is not backward compatible. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 43 Features Supported by Cisco Unified JTAPI Call Recording for SIP or TLS Authenticated Calls

Calling Party Display Name The CiscoCall interface provides methods to get name displays of the calling party and the called party in a call. Applications can use getCurrentCallingPartyDisplayName() to get the display name of the calling party. JTAPI applications can use the following interface to get the display names of the calling party and the called party. {.. .. /** *This interface returns the display name of the called party in the call. *It returns null if display name is unknown. */ public String getCurrentCalledPartyDisplayName(); /** *This interface returns the display name of the calling party. *It returns null if display name is unknown. */ public String getCurrentCallingPartyDisplayName(); } The address objects store the display name internally, and the name gets updated when currentCallingAddress and currentCalledAddress are updated. NULL returns if the call is not in the active state and if currentCalling and currentCalled addresses of the call are not initialized. The system does not support Call.getCurrentCalledAddress() and call.getCurrentCallingAddress() for conference calls. Also, the system does not support call.getCurrentCalledPartyDisplayName() and call.getCurrentCallingPartyDisplayName() for a conference call. Note Calling Party IP Address Extensions to CallCtlConnOfferedEv and RouteEvent provide a method for retrieving the IP address of the calling party. This feature provides the calling party IP address to the destination side of basic calls, consultation calls for transfer and conference, and basic redirect and forwarding. The system does not support other scenarios and feature interactions, including those where the calling party changes. This feature only supports IP phones as calling party devices, although IP address of other calling devices may also be provided. See CiscoCallCtlConnOfferedEv, on page 350 and CiscoRouteEvent, on page 522. Backward compatibility This feature is backward compatible. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 44 Features Supported by Cisco Unified JTAPI Calling Party Display Name

Calling Party IP Address The Calling Party IP Address enhancement provides the calling party IP address to the destination side of basic calls, consultation calls for transfer and conference, and basic redirect and forwarding. Only calling party IP phones are supported, although IP address of other calling devices may also be provided. Other feature interactions are not supported including those during which the calling party changes. Note New Cisco extensions to the CallCtlConnOfferedEv and RouteEvent classes are created and expose a method to obtain the calling party IP address. The new extensions are CiscoCallCtlConnOfferedEv and CiscoRouteEvent. An empty returned value indicates that the calling party IP address is not available. Basic Call scenario JTAPI application monitors party B Party A is an IP phone A calls B IP Address of A available to JTAPI application monitoring B consultation transfer scenario JTAPI application monitors party C Party B is an IP phone A talks to B B initiates a consultation transfer call to C IP Address of B is available to JTAPI application monitoring party C Consultation conference scenario JTAPI application monitors party C Party B is an IP phone A talks to B B initiates a consultation conference call to C IP Address of B is available to JTAPI application monitoring party C Redirect scenario JTAPI application monitors party B and party C Party A is an IP phone A calls B IP Address of A is available to JTAPI application monitoring party B Party A redirects B to party C Calling IP address is not available to JTAPI application monitoring party B Calling IP address of B is provided to JTAPI application monitoring party C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 45 Features Supported by Cisco Unified JTAPI Calling Party IP Address

Backward compatibility This feature is backward compatible. Application must invoke a new API to query IP address of a call. Calling Party Normalization Calling Party Normalization (CPN) is an enhancement. This feature provides the option to transform or normalize the incoming call number and convert into the E.164 format, which includes the (country code, state code, and number type). The number type field identifies the subscriber, national, international, or unknown. The number type is not supported in conference scenarios. Interface changes This feature introduces a new method in CiscoCall that is getGlobalizedCallingParty() and a new method in CiscoPartyInfo that is getNumberType(). See CiscoCall, on page 332 and CiscoPartyInfo, on page 476 for more information. Message sequences See Calling Party Normalization, on page 1085 Backward compatibility This feature is backward compatible. CallFwdAll Key Press Notification This feature enables applications to know whether the call is a normal call or a temporary call, when the CallFwdAll key is enabled. JTAPI exposes this information through the API getCFwdAllKeyPressIndicator() which is exposed on the CiscoCall interface. This API enables the application to know if the call is created due to pressing of CallFwdAll softkey or not. The newly added getCFwdAllKeyPressIndicator()” could return following constants that are also new: • If it is pressed on a phone that is in on-hook state to set CallFwdAll, this API returns CiscoCall.CFWD_ALL_SET. • If it is pressed on a phone that is in on-hook state to clear the CallFwdAll, this API returns CiscoCall.CFWD_ALL_CLEAR. • If the call is made first and then the user presses CallFwdAll key when phone is in off-hook state, this API returns CiscoCall.CFWD_ALL_NONE. Interface changes See CiscoCall, on page 332 Message Sequences See CallFwdAll Keys Press Notification, on page 793 Backward Compatibility This feature is backward compatible. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 46 Features Supported by Cisco Unified JTAPI Calling Party Normalization

CallSelect and UnSelect Event Notification You can select or unselect call on a phone for doing DirectTransfer or join or any other feature operation. When a SharedLine user selects a call, the RemoteInUse shares line TerminalConection will go passive, and CallCtlTermiCallConnection goes in InUse state. When call is unselected, CallCtlTerminalConnection goes into a bridged state. An application cannot invoke any API on Passive/InUse TerminalConnection. CallProcessing also performs a Select/UnSelect operation during features (such as transfer/conference) operation. Applications will also perceive these events if the applications monitor RemoteInUse terminal. For example, if A and A' are SharedLine, and A selects the call, CallCtlTerminalConnection of A' goes into a passive or InUse state. If A “UnSelects” the call, the CallCtlTerminalConneciton of A' goes into the passive or bridged state. To view the message flow for CallSelect or UnSelect, see Message Sequence Charts, on page 761 Certificate Download API Enhancement Currently Cisco Unified JTAPI certificate download API has some security issues, to solve the problem, Cisco provides new certificate download APIs. New APIs require applications to specify a certificate pass phrase and the certificate pass phrase is used to encrypt Java key store where client/server certificates are stored. Old certificate download APIs are deprecated, however, it will still remain for some time to avoid backward compatibility issue for applications. Cisco highly recommends to migrate the application to new APIs. Cisco Unified JTAPI also provides new API deleteCertificate() and deleteSecurityPropertyForInstance() that can be used by application to delete certificates already installed. To change pass phrase for certificate java key store, the application must delete the old certificate by using this API and upload new certificate. JTAPIPreferences UI security tab enhancement provides two new buttons, one for DeleteCertificate and another for Update Certificate. DeleteCertificate button allows users to delete the certificate for required username/instanceID. Update Certificate button allows users to upload the certificate from CAPF server. If certificate update is successful, certificate update box is updated to show Updated; authorization string and certificate pass phrase are cleared. If certificate update operation fails, certificate box continues to show status Not Updated status unless certificate was previously updated. User/Applications must provide certificate pass phrase every time they try to update certificate, Cisco Unified JTAPI does not save certificate pass phrase for security reason in any circumstances. Applications own the responsibility to secure the pass phrase and provide it through API when needed. Backward Compatibility This feature is backward compatible. Changes in DeviceType Name Handling Currently, TSP hardcodes the DeviceTypeName depending on the DeviceType. When a new device type is added, we have to manually add the new device type name to the list of supported devices. Because CTI does not fetch and store the device type name in its cache, TSP cannot get this info from CTI. TSP needs to update the device type name when a new device type is added without any manual intervention. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 47 Features Supported by Cisco Unified JTAPI CallSelect and UnSelect Event Notification

In JTAPI, the changes have been made to ensure that QBE interface changes to handle the receive devicetypename that is sent from CTI and is stored in the deviceInfo structure. It is not used anywhere in JTAPI and will not be exposed to applications. Only the QBE interface changed as follows: public DeviceRegisteredEvent ( String ride, int deviceType, boolean allowsRegistration, int deviceID, boolean loginAllowed, UnicodeString userID, boolean controlled, int reasonInt, int registrationType, int unicodeEnabled, int locale, // added for deviceTypeName change String devTypeName) { public DeviceUnregisteredEvent ( String deviceName, int deviceType, boolean allowsRegistration, int deviceID, UnicodeString userID, boolean controllableBool, int reasonInt , int locale, //added for devtypename support String devTypeName) { Cisco MediaTerminal In JTAPI, the terminal object represents the logical endpoint for a call and is presumed to be able to receive and transmit data (digital encoded voice samples, for example). Thus, terminals in JTAPI represent Cisco Unified IPPhones. Even though gateways terminate media, terminals do not represent them. The CiscoMediaTerminals in particular represent a special kind of endpoint for which applications take responsibility for media termination. The following four steps associate with using CiscoMediaTerminals: • Provisioning • Registration • Adding Observers • Accepting Calls Provisioning Ensure CiscoMediaTerminals, which are analogous to physical terminals, get provisioned accordingly in Cisco Unified Communications Manager, even though they do not represent actual hardware IP phones or gateways. Just as IP phones must be added to Cisco Unified Communications Manager database by using the Device Wizard, CiscoMediaTerminals get added the same way, so Cisco Unified Communications Manager can associate the application endpoint with a directory number and other call control properties such as call forwarding. No device type called CiscoMediaTerminal exists in the DeviceWizard. Instead, Cisco Unified Communications Manager has one or more device types that support application registration—each of these types get exposed as a CiscoMediaTerminal through JTAPI. Currently, only the device type CTI port represents a CiscoMediaTerminal in JTAPI. This procedure lists the steps for provisioning a CTI port for use as an application-controlled endpoint. 1. Within the Cisco Unified Communications Manager configuration windows, add a CTI port device from the Device-Phone window by using the Device Wizard. The CTI port device name specifies the name of the corresponding CiscoMediaTerminal in JTAPI. 2. Add the new CTI port device, by using the User-Global Directory window, to the list of devices that the application controls by using the User window. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 48 Features Supported by Cisco Unified JTAPI Cisco MediaTerminal

For more information, refer to the Cisco Unified Communications Manager Administration Guide. Registration After a media termination device is properly provisioned in Cisco Unified Communications Manager, the application may obtain a reference to the corresponding CiscoMediaTerminal object by using either the Provider.getTerminal() method or CiscoProvider.getMediaTerminal() method. The two methods differ in that the CiscoProvider.getMediaTerminal() method only returns CiscoMediaTerminals, whereas Provider.getTerminal() will return any terminal object that is associated with the provider, including those representing physical IP phones. Use the CiscoMediaTerminal.register() method to notify Cisco Unified Communications Manager of the intent to terminate RTP streams of certain payload types. The CiscoMediaTermina.register() method takes an IP address, a port number, and an array of CiscoMediaCapability objects that indicate the types of codecs that the application supports as well as codec-specific parameters. The IP address and port indicate the address where the application can receive media streams. The following sample code demonstrates how to register a CiscoMediaTerminal and bind it to a local address, port number 1234: CiscoMediaTerminal registerTerminal (Provider provider, String terminalName) { final int PORT_NUMBER

1234; try { CiscoMediaTerminal terminal

provider.getTerminal (terminalName); CiscoMediaCapability [] caps

new CiscoMediaCapability [1]; caps[0]

CiscoMediaCapability.G711_64K_30_MILLISECONDS; terminal.register (InetAddress.getLocalHost (), PORT_NUMBER, caps); } catch (Exception e) { return null; } } For this sample code to work, ensure the specified provider is IN_SERVICE. Further, be aware that this code uses the constant CiscoMediaCapability.G711_64K_30_MILLISECONDS. This actually represents a static reference to a CiscoG711MediaCapability object that specifies a 30-millisecond maximum RTP packet size. The CiscoMediaCapability class predefines this and other common media formats. To specify a media payload that is not listed in the CiscoMediaCapability class, two options exist. If the desired payload type is a simple variation of one of the existing subclasses of CiscoMediaCapability, you only need to construct a new instance of the subclass. For instance, if an application can support G.711 payloads with a 60-millisecond maximum RTP packet size, it can construct the CiscoG711MediaCapability object directly; including specifying 60 milliseconds in the constructor. Alternatively, if no existing subclass of CiscoMediaCapability that matches the desired payload type exists, construct an instance of the CiscoMediaCapability class directly. The maximum packet size, for example, 30-milliseconds, represents the only other parameter that may be specified when a CiscoMediaCapability is constructed. The following code illustrates registering a custom payload capability: CiscoMediaTerminal registerTerminal (Provider provider, String terminalName) { final int PORT_NUMBER

1234; try { CiscoMediaTerminal terminal

provider.getTerminal (terminalName); CiscoMediaCapability [] caps

new CiscoMediaCapability [1]; Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 49 Features Supported by Cisco Unified JTAPI Registration

caps[0]

new CiscoMediaCapability ( RTPPayload.G728, 30 // maximum packet size, in milliseconds ); terminal.register (InetAddress.getLocalHost (), PORT_NUMBER, caps); } catch ( Exception e) { return null; } } The payload type parameter that is used for constructing the CiscoMediaCapability object corresponds to the payload field in the RTP header. The RTPPayload interface defines a number of well-known payload types for this purpose. Adding Observers To receive events that indicate where and when to transmit and receive RTP data, place a CiscoTerminalObserver on the CiscoMediaTerminal. The CiscoTerminalObserver extends the standard JTAPI TerminalObserver interface without defining any new methods; it provides a marker interface that signals the application interest in receiving RTP events. Because this is a TerminalObserver, not a CallObserver, it must get added by using the Terminal.addObserver() method, not the Terminal.addCallObserver() method. Note Additionally, add a CallControlCallObserver to the Address object that is associated with the CiscoMediaTerminal. This guarantees that the application will get notified when calls are offered to the CiscoMediaTerminal. Unlike regular IP phones, which automatically accept any offered call, CiscoMediaTerminals accept, disconnect (reject), or redirect any call that is offered to it. Because the CallCtlConnOfferedEv only gets presented to CallControlCallObservers that are placed on Address objects, not Terminal objects, the application places its CallControlCallObserver in the correct place. Be sure to implement the CallControlCallObserver interface, not just the CallObserver interface; the CallCtlConnOfferedEv will not get delivered to observers that implement only the core CallObserver interface. Note Accepting Calls When an inbound call arrives at the CiscoMediaTerminal address, it must be accepted by using the CallControlConnection.accept() method before a terminal connection gets created. This process does not apply for outbound calls —the connection will occur in the CallControlConnection.ESTABLISHED state as soon as the call progresses beyond digit recognition. After the connection is accepted, answer the ringing terminal connection to start media flow. Assuming that Cisco Unified Communications Manager can match the capabilities that were registered with the capabilities of the calling endpoint, Cisco Unified Communications Manager sends the Media Flow events, so the application can begin transmitting and receiving RTP data. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 50 Features Supported by Cisco Unified JTAPI Adding Observers

Cisco Unified Communications Manager Media Endpoint Model Endpoints represent the entities within the Cisco Unified Communications Solutions platform that terminate media, such as IP telephones and gateways. A call from one endpoint to another results in media flowing between the two endpoints. All endpoints in the Cisco Unified Communications Solutions platform transmit voice data by using real-time protocol (RTP). The Cisco Unified Communications Solutions telephones and gateways, for example, include built-in RTP stacks. Applications may also act as endpoints in a Cisco Unified Communications Solutions system; that is, they may terminate media. Because all Cisco Unified Communications Solutions endpoints use RTP, applications also must be able to transmit and receive RTP packets. Payload and Parameter Negotiation In addition to bearer data and payload, each RTP packet contains a header that helps endpoints to determine how to reassemble and decode a sequence of such packets into a media stream. RTP does not provide, however, a means for endpoints to negotiate which payload type to use for a particular stream: for example, audio data that is encoded by using the G.711 standard. Furthermore, RTP does not offer a means of negotiating unique payload type parameters such as the sampling rate of the encoded data or the number of samples that are to be transferred in each RTP packet. Instead, RTP usually gets used in conjunction with another protocol such as H.323, which specifies its own method for endpoints to negotiate these parameters. All such negotiation occurs prior to transmitting RTP packets between endpoints. Cisco Unified Communications Manager, not the endpoints, has responsibility for selecting the payload and encoding parameters for RTP streams. The following five steps that are involved in a typical bidirectional audio telephone call apply: • Initialization • Payload Selection • Receive Channel Allocation • Starting Transmission and Reception • Stopping Transmission and Reception Initialization Upon startup, each endpoint informs Cisco Unified Communications Manager of its media capabilities, that is, G.711, G.723, G.729a, and so on. Startup for an IP phone, for example, occurs when the phone is first turned on, or after it recontacts Cisco Unified Communications Manager after losing its former connection. The endpoint cannot express a preference for one payload type versus another, but it can specify certain parameters for each payload type, such as, packet size. The capability list that the endpoint registers remains exclusive and immutable. If the endpoint specifies that it can support both G.711 and G.723, it implicitly declares that it cannot support G.729a. Moreover, the endpoint must disconnect from Cisco Unified Communications Manager and reinitialize to change the list of capabilities that it supports. JTAPI applications perform this step by registering a CiscoMediaTerminal with Cisco Unified Communications Manager. The CiscoMediaTerminal.register() method allows applications to supply an array of media capability Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 51 Features Supported by Cisco Unified JTAPI Cisco Unified Communications Manager Media Endpoint Model

objects for registration with Cisco Unified Communications Manager. This step informs Cisco Unified Communications Manager that the application will act as the endpoint for all calls to or from a particular directory number, as determined by the device configuration in the Cisco Unified Communications Manager configuration. Payload Selection When a bidirectional media stream is about to be created between two endpoints, for instance, when a call is answered at an endpoint, Cisco Unified Communications Manager selects an appropriate payload type (codec) for the media stream. Cisco Unified Communications Manager compares the media capabilities of both endpoints that are involved in the call and selects the appropriate common payload type and payload parameters to use. The basis for payload selection includes endpoint capabilities and location, although other criteria may get added to this selection logic in the future. Endpoints do not get dynamically involved in selecting payload types on a call-by-call basis. Receive Channel Allocation If Cisco Unified Communications Manager can find a common payload type for the RTP stream between the two endpoints, it requests that each endpoint create a logical “receive channel”; that is, a unique IP address and port at which the endpoint will receive RTP data for the call. Each endpoint returns an IP address and port to Cisco Unified Communications Manager in response to this request. Currently, only IP phones and gateways perform this step. Cisco Unified Communications Manager requires JTAPI applications to specify a fixed IP address and port during initialization. Therefore, JTAPI applications cannot terminate more than one media stream simultaneously for the same endpoint. Applications that want to terminate multiple media streams must register multiple endpoints simultaneously. If the endpoint does not respond to the open receive channel request quickly enough, Cisco Unified Communications Manager disconnects the call. Because JTAPI applications always supply an IP address when CiscoMediaTerminals are registered, calls to application-controlled endpoints do not get disconnected for this reason. However, if Cisco Unified Communications Manager cannot find a common payload type between the two endpoints that are involved in the call, Cisco Unified Communications Manager disconnects the call. Starting Transmission and Reception After Cisco Unified Communications Manager receives channel information for both parties, it informs each endpoint of the codec parameters that it selected for the RTP stream and the destination address for the other endpoint. This information gets conveyed in two messages to each endpoint: a start transmission message and a start reception message. JTAPI applications receive the CiscoRTPOutputStartedEv and CiscoRTPInputStartedEv events that contain all the codec parameters that are necessary for sending and receiving RTP data. As a part of the QoS baselining effort in JTAPI, CiscoRTPOutputStartedEv provides the getPrecedenceValue() API to applications. CTI presents this value, The DSCP for Audio Calls to JTAPI. Using this value, applications can set the DSCP value for the media streams that they open. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 52 Features Supported by Cisco Unified JTAPI Payload Selection

Stopping Transmission and Reception When the RTP stream must get interrupted because of a feature such as hold or disconnect, Cisco Unified Communications Manager requests that each endpoint stop its transmission and reception of RTP data. Just as when the media flow is started, the stop transmission and stop reception messages get sent separately. JTAPI applications receive the CiscoRTPOutputStoppedEv and CiscoRTPInputStoppedEv. Cisco Unified Communications Manager Server Failure If a Cisco Unified Communications Manager server fails, the associated devices re-home to the next Cisco Unified Communications Manager server in the group. The prioritized list of Cisco Unified Communications Managers in the device pool information configuration for each device defines this process. Failure of a Cisco Unified Communications Manager server only results in a partial outage of devices in the cluster. Those devices remain available following a successful Cisco Unified Communications Manager failover and registration with a secondary Cisco Unified Communications Manager. A device such as a Cisco Unified IPPhone 7960 fails over to a secondary Cisco Unified Communications Manager server only when no active calls exist on that device. The failure of a Cisco Unified Communications Manager server during a call results only in termination of observation of that device. The media path continues to exist but without any further call control features. Note Cisco Unified JTAPI communicates this partial outage to applications by using CiscoAddrOutOfServiceEv and CiscoTermOutOfServiceEv events. When the Cisco Unified Communications Manager fails over, the device must successfully register to the secondary Cisco Unified Communications Manager before the device is available to the JTAPI applications. Cisco Unified JTAPI will send the CiscoAddrInServiceEv and CiscoTermInServiceEv events. The Provider remains in service during this time. Devices on other Cisco Unified Communications Manager servers remain available for call control. The events get sent on callbacks of the respective Address or Terminal observer objects. CiscoAddrOutOfServiceEv and CiscoAddrInServiceEv events get sent to an object that is implementing the AddressObserver and get added to an Address by using the addressChangedEvent() callback object method. The CiscoTermOutOfServiceEv and CiscoTermInServiceEv events get sent to an object that is implementing the TerminalObserver interface and get added to a Terminal that is using the terminalChangedEvent() callback method. If the devices are currently in a call, a CallObservationEnded message is sent on the CallObserver callChangedEvent() callback, followed by the CiscoAddrOutOfServiceEv and CiscoTermOutOfServiceEv messages. Applications must monitor for and respond to the CiscoAddrOutOfServiceEv, CiscoTermOutOfServiceEv, CiscoAddrInServiceEv, and CiscoTermInServiceEv events before the calling call control functions on the address or terminal. Applications that do not support this action may encounter unexpected errors because the applications do not know the exact state of the system. Note Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 53 Features Supported by Cisco Unified JTAPI Stopping Transmission and Reception

Cisco Unified IP 7931G Phone Interaction You can configure Cisco Unified IP 7931G phones in two modes: • NoRollOver • RollOver (across the same DN or across different DNs) When Cisco Unified IP 7931G phones are configured in NoRollOver mode, they operate like regular phones that are running SCCP, and in this mode transfers or conferences cannot occur across the different addresses. JTAPI will support controlling and monitoring of a 7931G phone when it is configured in NoRollOver mode. In RollOver mode, Cisco Unified IP 7931G phones support transfer or conference across different addresses. In this mode, JTAPI does not allow controlling and monitoring of a Cisco Unified IP 7931G phone. Applications see such terminal/addresses as restricted. If a Cisco Unified IP 7931G phone is in the control list of an application user and the phone configuration changes from NoRollOver to RollOver mode, JTAPI sends a CiscoAddrRestrictedEv event for addresses on the Cisco Unified IP 7931G phone and sends a CiscoTermRestrictedEv for terminals, with cause CiscoRestrictedEv.CAUSE_UNSUPPORTED_DEVICE_CONFIGURATION. However, if the phone configuration changes from RollOver to NoRollOver mode, JTAPI sends a CiscoAddrActivatedEv event for addresses on the Cisco Unified IP 7931G phone and sends a CiscoTermActivatedEv for terminals. If a Cisco Unified IP 7931G phone that is configured in RollOver mode transfers or conferences to JTAPI-controlled addresses, JTAPI applications do not recognize a common controller in the final and the consult call. This would provide different behavior to the JTAPI application. Depending on how the JTAPI application is processing information that is provided in events, applications may require changes to handle JTAPI events for this transfer or conference scenario. You can disable transfers and conferences across the line by configuring the Cisco Unified IP 7931G phone to NoRollOver mode through the phone configuration window of Cisco Unified Communications Manager Administration. There are two new cause codes for the CiscoRestrictedEv interface. When the terminal or address is restricted because a Cisco Unified IP 7931G phone is configured in RollOverMode, JTAPI sends CiscoAddrRestrictedEv with cause CiscoRestrictedEv.UNSUPPORTED_DEVICE_CONFIGURATION. This release also introduces a default cause code CAUSE_UNKNOWN, which applications should handle. Backward Compatibility This feature is backward compatible. You can disable this feature by configuring all Cisco Unified IP 7931G phones in a cluster in NoRollOver mode or by not having any Cisco Unified IP 7931G phones in a Cisco Unified Communications Manager cluster. If any phone in a Cisco Unified Communications Manager cluster is configured with RollOver mode, it may cause changes to the behavior of JTAPI-controlled addresses and terminals. For more information, see CiscoRestrictedEv, on page 519. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 54 Features Supported by Cisco Unified JTAPI Cisco Unified IP 7931G Phone Interaction

Cisco Unified JTAPI Install Internationalization Cisco Unified JTAPI supports multiple languages for the JTAPI installation and user preference UI. When JTAPI launches, you receive options for choosing languages for the installation. After choosing a language, further installation instructions display in the chosen language. The first option always specifies English. If certain phrases are missing in the locale language, the instructions default to English. See Cisco Unified JTAPI Installation, on page 217 for more information. Cisco VG248 and ATA 186 Analog Phone Gateways Cisco Unified JTAPI supports control of analog phones that are connected to the Cisco VG248 and ATA 186 Analog Phone Gateways. By adding the Cisco VG248 and ATA 186 Analog Phone Gateways to the user-controlled list, applications can control the devices. Applications receive events for the devices in a way similar to other IP phones. Applications can also initiate calls and invoke other features except answer Request through APIs. Make call works only when the device goes physically off hook. Applications cannot answer calls from APIs for the devices. If an application attempts to answer () on TerminalConnection for the VG248 and ATA 186 Terminal, the system throws PlatformException with error CiscoJtapiException.COMMAND_NOT_IMPLEMENTED_ON_DEVICE.To answer calls, you must manually pick up the handset, and then you can invoke other call control features such as transfer, conference, blind transfer, and park from the API. CiscoJtapiExceptions Cisco Unified JTAPI notifies the application of CTI-generated error codes. These codes return when an exception or error occurs in the CTIManager. The CTI returned error code propagates to the application separately. The application can extract the error code by invoking getErrorCode() method on the exception object, can get CTI error code name by invoking getErrorName() method, and can get error description by invoking method getErrorDescription(). The methods getErrorName(int errorCode) and getErrorDescription (int errorCode) deprecate and get removed in future releases. Cisco recommends that application users do not use these methods. CiscoJtapiExceptions interface defines error codes in JTAPI. When a PlatformException is thrown, it can be queried to get the error code, which can be compared to the following. Errors Problem Error Message CTIERR_LOGIN_FAILED_PWD_EXPIRED_USER_CAN_RESET Possible Cause This value is a static definition that identifies an error code as a login failure due to an expired password. In addition, this error code lets the application know that the user can change their password. Solution Try resetting the password. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 55 Features Supported by Cisco Unified JTAPI Cisco Unified JTAPI Install Internationalization

Problem Error Message CTIERR_LOGIN_FAILED_PWD_EXPIRED_USER_CANNOT_RESET Possible Cause Explanation This value is a static definition that identifies an error code as a login failure due to an expired password. In addition, this error code lets the application know that the user cannot change their password, and that an administrator will have to reactivate the account. Solution Contact the administrator to reactivate the account. Problem Error Message CTIERR_LOGIN_FAILED_ACCOUNT_LOCKED Possible Cause This value is a static definition that identifies an error code as a login failure due to the user account being locked. This is a generic exception for the various types of account lockout. The applications are not informed the reason for the account lockout. Solution Contact the administrator to unlock the account. Problem Error Message CTIERR_RECORDING_INVOCATION_TYPE_NOT_MATCHING Possible Cause This error code is returned when an application invokes a stopRecording() request and passes a method of recording other than the method that was specified when the recording was started. Problem Error Message CTIERR_INVALID_REMOTE_DESTINATION_NUMBER Possible Cause This error code is returned when an invalid remote destination number is enterred. Problem Error Message CTIERR_DUPLICATE_REMOTE_DESTINATION_NUMBER Possible Cause This error code is returned when the same remote destination number is entered twice. Problem Error Message CTIERR_REMOTEDESTINATION_LIMIT_EXCEEDED Possible Cause This error code is returned when the number of remote destinations has exceeded the max number limit. Problem Error Message CTIERR_REMOTE_DEVICE_REQUEST_FAILED_ACTIVE_RD_NOT_SET Possible Cause This error code is returned when the active remote destination is not set. Problem Error Message CTIERR_ENDUSER_NOT_ASSOCIATED_WITH_DEVICE Possible Cause This error code is returned when the enduser is not associated with the device. Problem Error Message CTIERR_DEVICE_ALREADY_REGISTERED_NONEXTEND Possible Cause This error code is returned when the device registration failed due to the device already being registered in non-extend mode. Problem Error Message CTIERR_MEDIA_ALREADY_TERMINATED_EXTEND Possible Cause This error code is returned when the device registration failed due to the device already being registered in extend mode. Problem Error Message CTIERR_INVALID_REMOTE_DESTINATION_NAME Possible Cause This error code is returned when an invalid remote destination name is entered. CiscoProvAuthenticationInfoEv CiscoProvAuthenticationInfoEv code returns to notify the application that the password is about to expire or has already expired. The application should have Provider Observer onto the Provider object to receive this event. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 56 Features Supported by Cisco Unified JTAPI CiscoProvAuthenticationInfoEv

If the application invokes a connection and it fails because of an expired password, it will receive a PlatformException with a newly defined error code. For more information, see CiscoJtapiExceptions, on page 55. In the case of a failover, the application will not explicitly request a connection, and will not receive a PlatformException. As the provider will already have an observer, it will deliver a CiscoProvAuthenticationInfoEv to it with getDaysUntilPasswordExpiry() = CiscoProvAuthenticationInfoEv.PASSWORD_EXPIRED. CiscoRTPHandle Interface on Cisco RTP Events The following interfaces are enhanced to allow applications to get a CiscoRTPHandle from the events: • CiscoRTPInputStartedEv, on page 557 • CiscoRTPInputStoppedEv, on page 559 • CiscoRTPOutputStartedEv, on page 565 • CiscoRTPOutputStoppedEv, on page 575 CiscoRTPHandle represents the callID of the call in Cisco Unified Communications Manager and stays the same as long as the call is active on the terminal. At any particular terminal/address, although the call and the associated GCID can change, CiscoRTPHandle will remain constant. Cisco Terminal Filter and ButtonPressedEvents Prior to the JTAPI 2.0 release, Cisco Unified JTAPI applications did not have direct control over terminal events. Applications can now receive button pressed events by setting the appropriate filter in the terminal observer. Applications no longer need to add call observer to get RTP events. When setButtonPressedEv gets enabled by using CiscoTermEvFilter, applications receive CiscoTermButtonPressedEv when a digit gets pressed on the phone. The following new or changed interfaces exist for CiscoTerminal Filter and ButtonPressedEvents: CiscoTerminal setFilter (CiscoTermEvFilter terminalEvFilter) Allows an application to have more control over the events thatget delivered to the TerminalObserver. void CiscoTermEvFilter getButtonPressedEnabled() Gets the enable or disable status of the button-pressed events for the terminal. The default value specifies disabled. boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 57 Features Supported by Cisco Unified JTAPI CiscoRTPHandle Interface on Cisco RTP Events

getDeviceDataEnabled() Gets the enable or disable status of the device data events for the terminal. The default value specifies disabled. boolean getRTPEventsEnabled() Gets the enable or disable status of the RTP events for the terminal. Thedefault value specifies disabled. boolean setButtonPressedEnabled (boolean enabled) Enables or disables the button pressed events for the terminal. void setDeviceDataEnabled (boolean enabled) Enables or disables the device data status events for the terminal. void setRTPEventsEnabled (boolean enabled) Enables or disables the RTP events for the terminal. void CiscoTermButtonPressedEv getButtonPressed () int For details on the interface changes, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for CiscoTerminal Filter and ButtonPressedEvents, see Message Sequence Charts, on page 761 CiscoTermRegistrationfailed Event This event gets provided to the application when CiscoMediaTerminal or CiscoRouteTerminal registration fails asynchronously. Usually when registration fails, the application gets a CiscoRegistrationFailedException; however, it is possible that the registration request was successful, but the CTI rejected the registration. This event is provided for the cases where the registration request is successful, but the registration gets rejected. The application should have TerminalObserver to receive this event. Upon receipt of this event, the applications should reregister with the new parameter, depending on the error code that is provided for this event. The following list provides the errors that get returned and the actions to take, by the application, to resolve them. Errors Problem Error Message CiscoTermRegistrationFailedEv.MEDIA_CAPABILITY_MISMATCH Possible Cause Registration cannot get done because the terminal is already registered. Do the second registration with the same media capability. Solution Try re-registering with the same capability. ProblemErrorMessageCiscoTermRegistrationFailedEv.MEDIA_ALREADY_TERMINATED_NONE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 58 Features Supported by Cisco Unified JTAPI CiscoTermRegistrationfailed Event

Possible Cause Registration cannot get done because the terminal is already registered with media termination type 'none'. Solution Try re-registering with media termination type 'none'. Problem Error Message CiscoTermRegistrationFailedEv.MEDIA_ALREADY_TERMINATED_STATIC Possible Cause Registration cannot get done because the terminal is already registered with static media termination. For static registration, the second registration is not allowed. Solution Wait until the terminal UnRegisters. Problem Error Message CiscoTermRegistrationFailedEv.MEDIA_ALREADY_TERMINATED_DYNAMIC Possible Cause Registration cannot get done because the terminal is already registered with dynamic media termination. Solution Try re-registering with dynamic media termination. Problem Error Message CiscoTermRegistrationFailedEv.OWNER_NOT_ALIVE Possible Cause When trying to register the terminal, registration gets in a race condition. Solution Try re-registering the terminal. The following interface is defined for this event: int getErrorCode () // Returns the errorCode for this exception No changes exist in the message flow. Cius Persistency Wireless devices introduced by Cisco, for example the Cisco Cius, have the capability to move between WiFi networks and still retain their registration to a single CiscoUCM. However, due to the change in the network the IP address of the device might undergo a change.To indicate this change in IP address of wireless devices like Cius, Cisco JTAPI will expose a new interface to applications with the 9.0.1 release. The new provider event - CiscoProvTerminalIPAddressChangedEv, will indicate that the IP address of the terminal has changed. Applications may choose to ignore this new event if they do not plan to support a Cius device. On receiving this event, applications can query for the changed IP address of the terminal using the methods exposed in the new event or on the CiscoTerminal. This interface will also expose the IP addressing mode of the terminal, based on which IPv4/IPv6 address of the terminal can be queried. Sample Code public synchronized void providerChangedEvent( ProvEv[] eventList ) { try { for ( int i

0; i < eventList.length; i++ ) { Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 59 Features Supported by Cisco Unified JTAPI Cius Persistency

case (eventList[i].getID()) ){ switch: CiscoProvTerminalIPAddressChangedEv.ID: Terminal term

eventList[i] .getTerminal(); int ipAddrMode

eventList[i].getIPAddressingMode(); InetAddr ipV4Addr

null; InetAddr ipV6Addr

null; if(ipAddrMode

CiscoTerminal.IP_ADDRESSING_MODE_IPv4) { ipV4Addr

eventList[i].getIPv4Address(); } else if(ipAddrMode

CiscoTerminal.IP_ADDRESSING_MODE_IPv6) { ipV6Addr

eventList[i].getIPV6Address(); } System.out.println(" TerminalName = " + term.getName() + " ipAddressing Mode = " + ipAddrMode + " IPv4 Address = " + ipV4Addr + " IPv6 Address = " + ipV6Address); } } catch (exception e) { … } } Interface Changes See CiscoProvTerminalIPAddressChangedEv, on page 488 for more information. Message Sequences See Cius Persistency, on page 798. Backward Compatibility This feature is backward compatible. Clear Calls Cisco Unified JTAPI applications can clear phantom calls without dropping active calls. The CiscoAddress provides a clearCallConnections message to allow applications to clear the calls when no active calls exist on the Cisco Unified Communications Manager (formerly Cisco Unified Call Manager). Click to Conference Click to conference feature provides interfaces on SIP trunk for applications such as Instant Messenger (IM) to add parties to a conference. Users can add other parties to a conference or remove parties by using such applications. When click to conference is used to add a party to conference, a call is offered to the target address. Only one connection for target address is created on this initial call. This call then gets added to conference which results in a new callID for the call on the target address and connections for other addresses in the call are created on the new call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 60 Features Supported by Cisco Unified JTAPI Clear Calls

This section describes the interface changes in Cisco Unified JTAPI to handle the interactions when an address is added to a conference by using click to conference feature. When click to conference feature is used, consult call does not occur and Cisco Unified JTAPI applications do not receive CiscoConferenceStartEv or CiscoConferenceEndEv. The feature can be disabled by turning off the “ENABLE CLICK TO CONFERENCE” CallManager service parameter. Interface Changes CiscoFeatureReason, on page 408 Message Sequences Click to Conference, on page 1092 Backward Compatibility This feature is backward compatible. No change in Cisco Unified JTAPI applications when this feature is not configured or used. Cluster Abstraction The CTIManager provides a virtual representation of all the Cisco Unified Communications Managers in a cluster. Cisco Unified JTAPI applications communicate with the CTIManager instead of with a specific Cisco Unified Communications Managers. The CTIManager also maintains connection between Cisco Unified Communications Managers in a cluster. This allows a provider to represent any devices in the cluster under the CTIManager. Figure 4: Single-Box Configuration with JTAPI, Cisco Unified Communications Manager, and CTIManager in One Box, on page 61 illustrates “Figure 4: Single-Box Configuration with JTAPI, Cisco Unified Communications Manager, and CTIManager in One Box, on page 61.” Figure 5: Redundant Cisco Unified Communications Manager and CTIManagers with JTAPI Deployed as a Separate Client, on page 62 illustrates “Figure 5: Redundant Cisco Unified Communications Manager and CTIManagers with JTAPI Deployed as a Separate Client, on page 62.” For more details about the cluster administration and device pool settings, refer to the Cisco Unified Communications Manager help information. Figure 4: Single-Box Configuration with JTAPI, Cisco Unified Communications Manager, and CTIManager in One Box Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 61 Features Supported by Cisco Unified JTAPI Cluster Abstraction

Figure 5: Redundant Cisco Unified Communications Manager and CTIManagers with JTAPI Deployed as a Separate Client In previous releases of Cisco Unified Communications Manager, applications that are running on Cisco Unified JTAPI could only control or monitor devices that are registered under a single Cisco Unified Communications Manager. If a Cisco Unified Communications Manager server went down, the connection between the Cisco Unified Communications Manager server and JTAPI would terminate and the Provider would shut down. Note Command Line Invocation This mode helps to install JTAPI in systems that do not have GUI support (for example, a Linux account). The entire installation procedure is guided by a character input based menu, where the user is asked to provide a series of inputs, based on the install time conditions. This mode also provides all the other options provided by the GUI based installer. Component Updater The Component Updater interface is enhanced to allow applications to specify the location of updater log. Currently the updater log is created in the same directory as the application. This enhancement allows applications to specify the trace location. Interface Changes See ComponentUpdater, on page 670 Message Sequences See ComponentUpdater Enhancement Use Cases, on page 1236 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 62 Features Supported by Cisco Unified JTAPI Command Line Invocation

Backward Compatibility This feature is backward compatible. Conference When you conference two calls together, JTAPI specifies that all the parties from one call be moved to the other call. The call whose parties are moved away and that subsequently becomes invalid gets identified as the “merged” or “consult” call. The call to which the merged parties move gets identified as the “final” call hereafter. When parties move from the merged call to the final call, the application receives events that indicate that all parties dropped from the merged call and events that indicate that the parties reappeared on the final call. To correlate the newly created connection objects with the old connection objects, use the CiscoConection.getConnectionID() method to obtain CiscoConnectionID objects for all old connections and all new connections. Matching connections will have identical CiscoConnectionID objects when you compare them by using the CiscoConnectionID.equals() method. Conference support exists for the following methods: • javax.telephony.callcontrol.CallControlCall.conference(Call) • javax.telephony.callcontrol.CallControlCall.getConferenceController() • javax.telephony.callcontrol.CallControlCall.getConferenceEnable() • javax.telephony.callcontrol.CallControlCall.setConferenceController(TerminalConnection) • javax.telephony.callcontrol.CallControlCall.setConferenceEnable(boolean) As of Cisco Unified Communications Manager Release 8.6, Cisco TelePresence MCU conference bridges are supported through JTAPI/TSP. From a JTAPI/TSP perspective, this conference bridge behaves in the same way as other supported conference bridges. Note Cisco Extensions Cisco Unified JTAPI implementation provides two extra events that signal the Start and End of Conference: CiscoConferenceStartEv and CiscoConferenceEndEv. These events get sent when Conference initiates and when it completes. They give handles to the final call, the merged conference (consult) call, and the two controlling TerminalConnections (in HELD and TALKING state). CiscoConferenceStartEv This event gets sent when call1.conference(call2) is invoked or if the Conference button is pressed for the second time on an IPphone. The ConferenceStartEv signifies the start of the merging process. A sequence of merging events that are reflected by the Conference process in Cisco Unified Communications Manager follows. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 63 Features Supported by Cisco Unified JTAPI Conference

CiscoConferenceEndEv This event gets sent at the end of the merge process after a ConferenceStartEv is sent. It signifies the completion of the merge of the Consult (or Merged) call into the Final Conference Call. The Merged call specifies an INVALID state, and an ObservationEndedEv gets sent for the call observer. CiscoCall.setConferenceEnable() The Cisco Unified JTAPI implementation uses the CiscoCall.setConferenceEnable() and the CiscoCall.setTransferEnable() methods to control whether the consult call will be initiated via the conference or the transfer feature. If none of the features is enabled explicitly, transfer gets used by default. Conference Scenarios The following scenarios describe the two typical types of conference that can be invoked. Consult Conference; B as the Conference Controller The following sequence of steps typically describes this scenario: • A calls B (Call 1). • B answers. • B Consults C (Call 2). setConferenceEnable() call2.consult(tc, C) • C answers. • B Completes Conference. Call1.conference(Call2) You must invoke the conference() method on the original call to complete a conference after a consultation. Invoking conference in the consult call object throws an exception. Note Arbitrary Conference; B as the Conference Controller The following sequence of steps typically describe this scenario: • A calls B (Call 1). • B answers. • B places the call on hold. • B calls C (Call 2). • C answers. • B Completes Conference. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 64 Features Supported by Cisco Unified JTAPI Conference Scenarios

Call1.conference(Call2) or Call2.conference(Call1) Conference Events This table provides the sequence of Core, Call control, and Cisco Extension events when Call1.Conference(Call2) is called: Table 1: Sequence of Events Fields Event Call Meta Event Cause consultCall = Call2finalCall = Call1conference Controller = TermConnB CiscoConferenceStartEv Call1 META_UNKNOWN CallCtlTermConnTalkingEv B Call1 META_CALL_MERGING ConnCreatedEv C ConnConnectedEv C CallCtlConnEstablishedEv C TermConnCreatedEv C TermConnActiveEv C CallCtlTermConnTalkingEv C Call1 META_CALL_MERGING TermConnDroppedEv B CallCtlTermConnDroppedEv B ConnDisconnectedEv B CallCtlConnDisconnectedEv B Call2 META_CALL_MERGING consultCall = Call2finalCall = Call1conferenceController = TermConnB TermConnDroppedEv C CallCtlTermConnDroppedEv C ConnDisconnectedEv C CallCtlConnDisconnectedEv C CallInvalidEv C Call2 META_CALL_MERGING CallObservationEndedEv Call2 META_UNKNOWN CiscoConferenceEndEv Call1 META_UNKNOWN Transfer and Conference Enhancement All parties who are involved in the call transfer get sent CiscoTransferStartEv and CiscoTransferEndEv. All parties who are involved in the call conference get sent CiscoConferenceStartEv and CiscoConferenceEndEv. A call transfer still generates two events—the dropping of a connection to the first call and the creation of a connection to the second call. Cisco Unified Communications ManagerRelease3.1 changed this order of events. Connections first get created in the final call and then get dropped in the consult call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 65 Features Supported by Cisco Unified JTAPI Conference Events

In Cisco Unified Communications ManagerRelease3.0, not all parties who are involved in the transfer of calls received these events Note Applications should not rely on the order of events between CiscoTransferStartEv and CiscoTransferEndEv or between CiscoConferenceStartEv and CiscoConferenceEndEv for transferring and conferencing when porting applications from Cisco Unified Communications ManagerRelease3.0 to 3.1. Note Conference and Join The Conference Feature provides the ability to conference more than two people into a single call. Events at CTI layer change, and Cisco Unified JTAPI gets enhanced to support the new CTI events. Join Feature provides the ability to join multiple calls into one single conference call. This functionality now supports multiple calls. Applications need to pass an array of calls to be conferenced together. The following new or changed interfaces exist for conference and joining of multiple calls into one conference call: • The following interface allows Join to conference multiple calls into one conference call: Call.Conference(Call[] otherCalls) A precondition requires that all the otherCalls must have controller as one leg of the call. Note • The following new or modified interfaces exist in CiscoConferenceStartEv: • TerminalConnection getHeldConferenceController()—This interface proves useful only for the arbitrary conferencing of two calls and returns only one of the held calls. • TerminalConnection[] getHeldConferenceControllers()—This interface gets all of the held calls when multiple calls are joined. • TerminalConnection getTalkingConferenceController()—This interface returns the talking conference controller; however, if no talking conference controller exists when all the calls that are being joined into conference are held, this interface returns null. • Call getConferencedCall()—This interface returns only one of the many calls that are going to join into a conference and may not have any meaning for a join conference when more than two calls exist. • New interface in CiscoConferenceEnded event Boolean isSuccess(): This interface returns true or false depending on whether conference is successful or failed. Application can use interface to find whether conference is successful. The following events get defined as conference failure: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 66 Features Supported by Cisco Unified JTAPI Conference and Join

• If the application issues the request Call.conference(otherCalls[]), this conference would be considered failed if one or more than one calls could join into conference. Applications can use the interface getFailedCalls() to find the failed call. • If no conference bridge is available and the conference could not complete at all, the application can use getFailedCalls() to get a list of calls that could not join the conference. • A party that was being conferenced dropped out before conference could complete. • An interface on the CiscoConferenceEnded event (Call[] getFailedCalls()) gets all the calls that failed to join the conference when the conference fails. The following new or changed behaviors exist for Conference: • No hold or unHold message such as applications see when an arbitrary conference occurs. • An arbitrary conference does not require, as a precondition, that any calls be in a talking state; however, all the otherCalls must have a controller as one leg of the call. • Applications can conference two or more held calls into a conference call. In finalCall, the controller automatically gets retrieved to a talking state. • Always include an active call in the request Call.Conference(otherCalls). If an active call is not included in the conference request, the request fails. • If no active call exists at the controller, the Call.Conference(otherCalls) request remains successful; however, if one active call exists, it the request must include it. • If the application does not have an active TerminalConnection that is passed as an argument, Call.consult() throws a PreConditionException/InvalidArgumentException. • If the controller does not have an active TerminalConnection, Call.Conference()/Call.Conference(Call[]) throws a PreconditionException/InvalidArgumentException. For details on the interface changes, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for conference and join, see Message Sequence Charts, on page 761 Conference Chaining The conference chaining feature lets applications join two separate conference calls together. JTAPI applications see chained conference calls that are represented as two separate calls. When conference calls are chained, JTAPI creates a new connection for the conference chain and provides the CiscoConferenceChainAddedEv event on CallCtlCallObserver. When the conference chain is removed from the call, JTAPI disconnects the conference chain connection and provides the CiscoConferenceChainRemovedEv event on CallCtlCallObserver. From CiscoConferenceChainAdded/RemovedEv, applications can obtain CiscoConferenceChain, which provides a link for all the conference chain connections. The following figure shows parties A, B, and C in conference call GC1 and parties C, D, and E in conference call GC2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 67 Features Supported by Cisco Unified JTAPI Conference Chaining

Figure 6: Calls Prior to Chaining After the conference chain is created, the calls will look like the following figure. Figure 7: Calls After Chaining Applications may get all the participants of a chained conference from the CiscoChainedConference object, which provides conference chain connections from all the conference calls that are chained together. By browsing through the connections list, applications can get a list of all the chained conference calls; however, applications must have at least one participant of each conference that is observed. For any conference scenario that involves chaining conferences or adding parties to a chained conference call, JTAPI will not provide ConferenceStarted/Ended event. Note For more information, see the following topics: • CiscoCall, on page 332 (for the getConferenceChain() interface) • CiscoConferenceChain, on page 371 • CiscoConferenceChainAddedEv, on page 372 • CiscoConferenceChainRemovedEv, on page 375 Consult Without Media Applications can inform Cisco Unified Communications Manager that a consultation call for a transfer is being placed without establishing the media path. The system does not require establishing the media path for the intermediate call, if the consultation call is being placed to determine whether an agent is available before the actual transfer. The consultWithoutMedia method as defined in the CiscoConsultCall interface creates a consultation call without establishing the media path. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 68 Features Supported by Cisco Unified JTAPI Consult Without Media

The system allows only transferring of the consultation call; it does not allow the call to be in conference. Note CTI Ports CTI Ports that are registered by an application include a mechanism similar to phone devices. When the Cisco Unified Communications Manager that is handling signaling for a CTIPort fails, the CTIManager recovers its services according to the device pool administration for this device. On a CTIManager failure, Cisco Unified JTAPI reregisters the CTI Port after it connects to the backup CTIManager. The CiscoAddrOutOfServiceEv and CiscoTermOutOfServiceEv events and the corresponding in-service events get sent after recovery of the CTI Port. The application controls media streaming for these devices, and streaming continues even when the port is out of service. The application has responsibility to ensure that new calls do not get presented to the device until it is ready to accept them. CTI RoutePoints On a Cisco Unified Communications Manager server failure, the CTIManager recovers the device from the Cisco Unified Communications Manager server group as defined in the device pool administration for the CTI RoutePoint. When the primary Cisco Unified Communications Manager server recovers, the CTIManager attempts to recover the device on its primary Cisco Unified Communications Manager. This re-homing happens when no more calls exist on the device (similar to physical devices). On a CTIManager failure, Cisco Unified JTAPI recovers the device on the backup CTIManager. The application receives notification of the availability of a device with the CiscoAddrOutOfServiceEv and CiscoAddrInServiceEv events. CTI Remote Device for JTAPI Changes in personal device preferences and an increasing number of mobile and remote workers necessitates a more flexible Unified Communications solution that extends UC features with a Bring Your Own Device philosophy. Extend and Connect addresses this change. Extend and Connect is a feature that allows administrators to rapidly deploy Unified Communications (UC) Computer Telephony Integration (CTI) applications which interoperate with any endpoint. Extend and Connect lets users leverage the benefits of UC applications from any location using any device. This feature allows interoperability between newer UC solutions and legacy systems, so customers can migrate over time as existing hardware is deprecated. For more information, please refer to the Cisco Unified Communications Manager Features & Services guide. Interface Changes See CiscoRemoteDestinationInfo, on page 513, CiscoProvTerminalRemoteDestinationChangedEv, on page 511, CiscoProvider, on page 492, CiscoTerminalProtocol, on page 643. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 69 Features Supported by Cisco Unified JTAPI CTI Ports

Message Sequences See CTI Remote Device, on page 807. Backward Compatibility This feature is backward compatible. Play Announcement Play Announcement allows a specified preconfigured announcement to be played or streamed to a remote destination. Only announcements that are uploaded to the Cisco Unified Communications Manager can be played. All announcement requirements and limitations are applicable to Play Announcement. As part of this feature, new JTAPI APIs, events, and error codes are added. Only CTI Remote Devices with a persistent call support play announcement. Play announcement is not supported on IP phones or CTI ports. Cisco recommends that the persistent call plays an announcement when answered. Announcements can be played on persistent calls even without customer calls. However, if there are customer calls incoming to the remote device, announcements are played only when that call is not in a connected state. Multiple announcements cannot be played at the same time. No features (transfer, conference, hold) can be performed on the announcement call. The following are required for the application to play the announcement: at least one remote destination must be configured, the active remote destination must be set, and a persistent call must be created. JTAPI supports a new API, CiscoCall.startAnnouncement(), which allows applications to start to play an announcement. This API creates an announcement call. This newly created announcement call counts toward both the busy trigger and maximum calls limit. JTAPI APIs such as Provider.getCalls(), Address.getConnections(), and Terminal.getTerminalConnections() return information for the announcement call. No new APIs are added to disconnect/drop the announcement calls. Use Existing Call.drop() and Connection.disconnect() JTAPI APIs to disconnect the announcement calls. In addition to the APIs that explicitly end the announcement call, the announcement call is also automatically disconnected after the announcement is complete. Any state change in the announcement call stops the announcement, and also disconnect the announcement call. For example, if there is an incoming customer call in ringing state and the announcement is still being played, after the customer call is answered, the announcement call is disconnected. As a part of this feature, new JTAPI events are introduced. The CiscoAnnouncementStartedEv is a new JTAPI event that is delivered to applications, notifying applications when the play announcement starts. To notify applications when the play announcement has ended, another new JTAPI event, the CiscoAnnouncementEndedEv, is delivered to apps. If during any time, an error occurs during play announcement, a new JTAPI event delivers that information to apps as well: CiscoAnnouncementErrorEv. Some of the new JTAPI error codes that are introduced as part of this feature include: • CiscoJtapiException.CTIERR_NO_PERSISTENT_CALL_EXISTS: This error codes indicates that no persistent call exists. • iscoJtapiException.CTIERR_ANNOUNCEMENT_ALREADY_IN_PROGRESS: This error code indicates that there is already an announcement in progress. • CiscoJtapiException.CTIERR_ERROR_PLAYING_ANNOUNCEMENT: This error code indicates that there is an error in playing the announcement. • CiscoJtapiException.CTIERR_PLAY_ANNOUNCEMENT_FAILED: This error code indicates that play announcement failed. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 70 Features Supported by Cisco Unified JTAPI Play Announcement

Interface Changes • CiscoAddress, on page 289 • CiscoAnnouncementStartedEv, on page 328 • CiscoAnnouncementEndedEv, on page 328 • CiscoAnnouncementErrorEv, on page 329 • CiscoFeatureReason, on page 408 Message Sequences See Play Announcement, on page 1356. Backward Compatibility This feature is backward compatible and existing applications are not affected by its introduction. Verify Remote Destination Support In Cisco Unified Communications Manager 10.0(1), the existing CiscoRemoteTerminal.addRemoteDestionation(), CiscoRemoteTerminal.updateRemoteDestination(), and CiscoRemoteTerminal.updateRemoteDestinationNumber() APIs are enhanced to allow validation of the remote destination. As part of this feature, when an application attempts to add or update a remote destination using JTAPI API, Cisco JTAPI validates the remote destination to determine whether the destination is reachable. If the destination is not reachable, the add or update remote destination request returns an error of CiscoJtapiException.CTIERR_EXTEND_AND_CONNECT_DESTINATION_NOT_REACHABLE. The remote destination is then not updated in the database. A sucessful update is possible only if the remote destination is reachable, and the database is then updated with the remote destination number. The verification of the remote destination in the update applies only when the JTAPI API is invoked. Adding or updating the remote destination information through the ccmadmin page does not result in the verification of the remote destination. No new APIs are added as part of this feature. A new error is introduced. Interface Changes CiscoJtapiException, on page 416 Message Sequences Verify Remote Destination Support, on page 1452 Backward Compatibility This feature is backward compatible and existing applications are not affected by this enhancement. NuRD (Number Matching for Remote Destination) Support Starting in Cisco Unified Communications Manager 10.0(1), the existing “Cisco Extend and Connect” feature is enhanced to include number matching for remote destination support. When users make a direct call to a number that is configured as a remote destination for CTI Remote Device (CTI RD), and if that remote destination is active, the call is offered on the CTI Remote Device and extended to the remote destination. From the application, the current called party is the CTI RD. If the active remote destination is not set, when users call a remote destination number, the call will be a direct call between the caller and the remote destination. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 71 Features Supported by Cisco Unified JTAPI Verify Remote Destination Support

The same situation applies to a call from a remote destination to an enterprise dial number. If the remote destination is active, the CTI RD is initiating the call to the enterprise dial number. If the active remote destination is not set, calls from a remote destination to an enterprise dial number are direct calls between the remote destination and the enterprise dial number. For those calls from and to a remote destination number, all existing features that are allowed on CTI RD are available. Interface Changes There are no interface changes for this feature. Usage Cases Use Cases for NuRD (Number Matching for Remote Destination), on page 1307 Backward Compatibility This feature may change existing expected behavior in direct calls to and from remote destination numbers. Applications that do not leverage this NuRD feature keep the clusterwide service parameter “Reroute Remote Destination Calls to Enterprise Number” set to False. Enabling the parameter enables the NuRD features. This parameter is set to False by default. Mobility Interaction Support Starting in Cisco Unified Communications Manager 10.0(1), the existing “Cisco Extend and Connect” feature is extended to include mobility interaction. Users can now specify remote destinations that are shared between the CTI Remote Device (CTI RD) and the Remote Destination Profile (RDP). When both the CTI RD and the RDP are configured for the same user, and if the application is active (active rd is set), CTI RD will process the call first and then offer the call to the RDP. If the application is not active, the RDP processes the call first and does not offer the call to the CTI RD. When only CTI RD is configured for a user, the existing "Cisco Extend and Connect" feature behavior with remote destinations remains unchanged. When only RDP is configured for a user, there is no application support because the devices are not CTI controllable. Interface Changes There are no interface changes for this feature. Usage Cases Mobility Interaction Support, on page 1265 Backward Compatibility This feature is backward compatible and existing applications are not affected by the enhancement. CTI RD Call Forward Beginning in Release 10.0(1), CTI RD Call Forward provides applications with the ability to control when incoming calls are forwarded to all configured Remote Destinations on the CTI Remote Device, when no active remote destination is set. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 72 Features Supported by Cisco Unified JTAPI Mobility Interaction Support

A new check box Route calls to all remote destinations when client is not connected, is added to the Cisco Unified Communications Manager device page. The check box determines whether calls are routed to all remote destinations when active remote destination is not set. When the check box, Route calls to all remote destinations when client is not connected is enabled, and Active Remote Destination is not set, the call is routed to all remote destinations. If this check box is disabled, and Active Remote Destination is not set, the call will be disconnected with User_Busy error. In scenarios where Active Remote Destination is set, the call will be always routed to the Active Remote Destination even if the check box Route calls to all remote destinations when client is not connected is selected. Interface Changes There are no interface changes for this feature. Use Cases CTI RD Call Forward, on page 876 Backward Compatibility Applications should enable the check box Route calls to all remote destinations when client is not connected to maintain the old behavior. CTI Video Support The CTI Video Support feature allows the JTAPI Application to detect the multimedia capabilities of Line Devices; such as receiving video, sending video and both receiving and sending video. Cisco JTAPI provides the applications with the ability to expose the video capabilities of a terminal through the enhancement CTI Video Support. CTI applications can differentiate a video-enabled device from a non video-enabled device, and, a video call from an audio only call. Cisco JTAPI provides a new API, getCiscoMultiMediaCapabilityInfo() on the CiscoTerminal to expose the multimedia capabilities of the device. Cisco JTAPI exposes the multimedia capabilities of the terminal after the device is in registered state. The multimedia capabilities of the terminal include: • video capability (either none or video enabled), • telepresence interoperability (either none or telepresence interoperability enabled on the device), and, • screen count (to know the number of screens available on device). The multimedia capabilities are exposed on a new interface CiscoMultiMediaCapabilityInfo, which has the following APIs to expose these capabilities. • getVideoCapability(), • getTelepresenceInfo(), and, • getScreenCount(). The following APIs on the CiscoCall are used by the application to determine the calling party or called party multimedia capability prior to media setup. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 73 Features Supported by Cisco Unified JTAPI CTI Video Support

• getCallingTerminalMultiMediaCapabilityInfo()—of the calling party in a call • getCalledTerminalMultiMediaCapabilityInfo()—of the called party in a call When the video capability of the terminal changes, a new Cisco JTAPI event, CiscoProvTerminalMultiMediaCapabilityChangedEv, notifies the application. This event is a JTAPI provider event, and is delivered when the application adds a Provider Observer. The terminal must be in registered state, to receive this event. Plugging in or plugging out the Cisco camera will not affect the video capability status, therefore, the event will not be triggered. However, you can modify the video capability using the Cisco UCM Administration Interface > Device Configuration page. The initial video capability API on CiscoTerminal is not supported for CTI Route Points and CTI Ports; however, they can receive the video information of the calling party. Note The following devices supports the CTI Video feature: • 89xx (SIP only) • 99xx • E20 • EX60/90 • CTS 500 • CTS 500-32 • Jabber(CSF) • CTI RoutePoint • CTI Port Interface Changes See the following sections for interface changes: • CiscoCall, on page 332 • CiscoMultiMediaCapabilityInfo, on page 468 • CiscoProvTerminalMultiMediaCapabilityChangedEv, on page 489 • CiscoTerminal, on page 617 Message Sequences See CTI Video Support, on page 885. Backward Compatibility This feature is backward compatible. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 74 Features Supported by Cisco Unified JTAPI CTI Video Support

Default CTI IP Addressing for Devices A new CTIManager service parameter, IP Addressing Mode for Devices, has been added that allows you to configure the default CTI IP addressing mode for a device that does not have an associated Common Device Configuration. When an application invokes the CiscoTerminal.getIPAddressingMode() method for a device that does not have a Common Device Configuration, JTAPI returns the value of the service parameter. The default setting for the new service parameter is IPv4 and IPv6. JTAPI communicates the value via CiscoTerminal.IP_ADDRESSING_MODE_IPV4_V6. For an individual CTI device, if that device has an associated Common Device Configuration, the IP Addressing Mode setting in the Common Device Configuration overrides the value of the IP Addressing Mode for Devices service parameter. Note DeleteCall DeleteCall interface provides applications with the ability to delete a call that was created by using the createCall interface. This method accepts a call and throws an InvalidStateException if a provider is not in service or if the call is not in the IDLE state. DeleteCall moves the call to the INVALID state. The following interface gets added to CiscoProvider: { public void deleteCall( Call call ) throws InvalidStateException; } Applications can use this interface to delete the call that was created by using createCall interface. This method accepts a call and throws an InvalidStateException if the provider is not in service or if the call is not in the IDLE state. DeleteCall moves the call to the INVALID state. To successfully delete a call, the application creates the call by using createCall, and the call should be in the IDLE state. Device Recovery Cisco Unified JTAPI supports automatic device recovery. Device Recovery for Phones For devices such as the Cisco Unified IPPhone 7960, the re-homing feature represents part of the device firmware. On a primary Cisco Unified Communications Manager failure, the phone attempts to connect to the backup Cisco Unified Communications Manager when it is no longer on a call. This transition gets communicated to applications in the form of out-of-service and in-service events described in CTIManager Failure, on page 152. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 75 Features Supported by Cisco Unified JTAPI Default CTI IP Addressing for Devices

For virtual devices with no firmware such as CTI Ports and CTI RoutePoints, the CTIManager or Cisco Unified JTAPI performs the failover. Device State Server The Device State server provides the cumulative state of all the addresses on a terminal. These events are delivered as TerminalEvent. Applications need to add TerminalObserver to get these events. The states follow: • IDLE—If no calls exist on any of the addresses on the terminal, consider the DeviceState as IDLE, and Cisco Unified JTAPI sends CiscoTermDeviceStateIdleEv to applications. • ACTIVE—If any addresses on the terminal have an outgoing call (in CTI State Dialtone, Dialing, Proceeding, Ringback, or Connected) or an incoming call (in CTI State Connected), the consider DeviceState as ACTIVE, and Cisco Unified JTAPI sends CiscoTermDeviceStateActiveEv to the application. • ALERTING—If address on the terminal has an outgoing call (in CTI State Dialtone, Dialing, Proceeding, Ringback, or Connected) or an incoming call (in CTI State Connected) and at least one of the addresses on the terminal has an unanswered incoming call (in CTI State Offering, Accepted, or Tinging), the DeviceState is ALERTING, and Cisco Unified JTAPI sends CiscoTermDeviceStateAlertingEv to the application. • HELD—If all the calls on any of the address on the terminal are held (in CTI State OnHold), the DeviceState is HELD and Cisco Unified JTAPI sends CiscoTermDeviceStateHeldEv to the application. New Events • CiscoTermDeviceDeviceStateIdleEv • CiscoTermDeviceStateActiveEv • CiscoTermDeviceStateAlertingEv • CiscoTermDeviceStateHeldEv New and Changed Interfaces public int getDeviceState() returns the device state of the terminal. The following new interfaces on CiscoTermEvFilter set and get the device state: setDevideStateActiveEvFilter(boolean filterValue) Enables and disables the CiscoTermDeviceStateActiveEv filter.The default value is disable. void setDeviceStateAlertingEvFilter(boolean filterValue) Enables and disables the CiscoTermDeviceAlertingEv filter.Thedefault value is disable. void setDeviceStateHeldEvFilter(boolean filterValue) Enables and disables the CiscoTermDeviceHeldEv filter.Thedefault value is disable. void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 76 Features Supported by Cisco Unified JTAPI Device State Server

setDeviceStateIdleEvFilter(boolean filterValue) Enables and disables the CiscoTermDeviceIdleEv filter. Thedefault value is disable. void getDeviceStateActiveEvFilter() Gets the CiscoTermDeviceStateActiveEv filter status. boolean getDeviceStateAlertingEvFilter() Gets the CiscoTermDeviceStateAlertingEv filter status. boolean getDeviceStateActiveEvFilter() Gets the CiscoTermDeviceStateAlertingEv filter status. boolean getDeviceStateActiveEvFilter() Gets the CiscoTermDeviceStateAlertingEv filter status. boolean For details on the interface changes, see Cisco Unified JTAPI Extensions, on page 249 Direct Transfer Across Lines The Direct Transfer Across Lines feature allows support for connected transfer across lines. It allows two calls on different addresses of the same terminal to be transferred though the Transfer softkey on the phone or by using the transfer() API that is provided by Cisco Unified JTAPI. When a transfer is performed across lines, the JTAPI application behavior changes, as applications do not see a common controller address in final and consult calls. There is no change in the API and the same events are delivered whether calls are transferred on the same address (regular transfer) or across addresses (direct transfer across lines). This feature is supported on all supported phones, including CTI port, SCCP devices and SIP devices. If an observer is not added to either of the two addresses from which the direct transfer is being attempted from the JTAPI API, then Cisco Unified JTAPI throws PlatformException with this error: Transfer controller is not set and could not find a suitable TerminalConnection. Usage Guidelines The points below indicate how applications must use the Direct Transfer Across Lines feature: • Applications must add Call Observer on the both the lines across which they try a direct transfer. • Earlier, applications were recommended to check if both the calls have a common address and if that address is on the same Terminal. For Direct Transaction Across Lines, it is not required to check this, if the address is common between two calls across which direct transaction is invoked. It must be ensured that both the calls should each have an address which exists in a common terminal. • Cisco Unified JTAPI reports the same set of events, as it does currently, for transferring of a call on same address. Applications are not required do anything with these calls after invoking Transfer() until receiving CiscoTransferEndEv. • As transfer is done across addresses, applications do not get a common controller in CiscoTransferStartEv and should upgrade the application logic. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 77 Features Supported by Cisco Unified JTAPI Direct Transfer Across Lines

Event Flow Comparison and Sample Code The following table provides details of the event flow. Table 2: Event Flow Comparison and Sample Code for Transfer Invocation Transfer Across Lines Transfer on Same Lines Setup Address A on Terminal T1 Address B1, B2 on Terminal T2 Address C on Terminal T3 Address A on Terminal T1 Address B1, B2 on Terminal T2 Address C on Terminal T3 Feature Invocation A calls B1 [GC1 = GolbalCallID1] GC1: Connection A->Conn1 GC1: Connection B1->Conn2 B2 calls C [GC2 = GolbalCallID2] GG2: Connection B2->Conn3 GC2: Connection C->Conn4 GC1.transfer(GC2); A calls B1 [GC1 = GolbalCallID1] GC1: Connection A1-> Conn1 GC1: Connection B1->Conn2 B1 calls C [GC2 = GolbalCallID2] GG2: Connection B1-> Conn3 GC2: Connection C->Conn4 GC1.transfer(GC2); Events Delivered to Application (assuming all parties are observed) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 78 Features Supported by Cisco Unified JTAPI Event Flow Comparison and Sample Code

Transfer Across Lines Transfer on Same Lines GC1: CiscoTransferStartEv [getTransferControllerAddress() returns B1] ConnCreatedEv for C ConnConnectedEv for C CallCtlConnEstablishedEv for C TermConnCreatedEv for T3(Address C) ConnDisconnectedEv for B1 CallCtlConnDisconnectedEv for B1 TermConnDroppedEv for T2(Address B1) CallCtlTermConnDroppedEv for T2(Address B1) CiscoTransferEndEv GC2: CiscoTransferStartEv [getTransferControllerAddress() returns B1] TermConnDroppedEv for T2(Address B2) CallCtlTermConnDroppedEv for T2(Addresss B2) ConnDisconnectedEv for B2 CallCtlConnDisconnectedEv for B2 TermConnDroppedEv for T3(Address C) ConnDisconnectedEv for C CallCtlConnDisconnectedEv for C CallCtlTermConnDroppedEv for T3(Address C) CiscoTransferEndEv CallInvalidEv CallObservationEndedEv Note GC2 - Disconnect events are for Address B2 on Terminal T2 GC1: CiscoTransferStartEv [getTransferControllerAddress() returns B1] ConnCreatedEv for C ConnConnectedEv for C CallCtlConnEstablishedEv for C TermConnCreatedEv for T3(Address C) ConnDisconnectedEv for B1 CallCtlConnDisconnectedEv for B1 TermConnDroppedEv for T2(Address B1) CallCtlTermConnDroppedEv for T2(Address B1) CiscoTransferEndEv GC2: CiscoTransferStartEv [getTransfeControllerAddress() returns B1] TermConnDroppedEv for T2(Address B1) CallCtlTermConnDroppedEv for T2(Addresss B1) ConnDisconnectedEv for B1 CallCtlConnDisconnectedEv for B1 TermConnDroppedEv for T3(Address C) ConnDisconnectedEv for C CallCtlConnDisconnectedEv for C CallCtlTermConnDroppedEv for T3(Address C) CiscoTransferEndEv CallInvalidEv CallObservationEndedEv Note GC2 - Disconnect events are for Address B1 on Terminal T2 In connected Transfer Across Lines scenario, apart from events mentioned, applications can see another temporary call GC3 going active(CallActiveEv) and GC3 goes idle (CallInvalidEv) immediately after the transfer is completed Note Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 79 Features Supported by Cisco Unified JTAPI Event Flow Comparison and Sample Code

Transfer on Same Lines Sample Code Handle(CiscoCallEv event) { ….. ….. if (event instanceOf CiscoTransferStartEv) { CiscoTransferStartEv ev

(CiscoTransferStartEv)event; processTransfer(ev); } } processTransfer(CiscoTransferStartEv ev){ CiscoAddress commonAddr

ev.getTransferControllerAddress(); CiscoCall GC2

ev.getTransferringCall(); CiscoCall GC1

ev.getFinalCall(); CiscoConnection droppedConn1

findConnection(GC1, controllerAddr); CiscoConnection droppedConn2

findConnection(GC2, controllerAddr); //Additional App logic to clear connections. } Connection findConnection(CiscoCall GCx, CiscoAddress addr){ CiscoConnection[] conns

GCx.getConnections(); for (i = 0; i<conns.length; i++) { if conns[i] .getAddress().equals(addr) { return conns[i]; } } } Application logic is based on common transferControllerAddress and works fine in this case, because commonAddr is there in both final and consult call Note Transfer Across Lines Sample Code Handle(CiscoCallEv event) { ….. ….. if (event instanceOf CiscoTransferStartEv) { CiscoTransferStartEv ev

(CiscoTransferStartEv)event; processTransfer(ev); } } processTransfer(CiscoTransferStartEv ev){ String termName

ev.getControllerTerminalName(); CiscoCall GC2

ev.getTransferringCall(); CiscoCall GC1

ev.getFinalCall(); CiscoConnection droppedConn1

findConnection(GC1, termName); Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 80 Features Supported by Cisco Unified JTAPI Event Flow Comparison and Sample Code

CiscoConnection droppedConn2

findConnection(GC2, termName); //Additional App logic to clear connections. } Connection findConnection(CiscoCall GCx, String termName){ CiscoConnection[] conns

GCx.getConnections(); for (i = 0; i<conns.length; i++) { CiscoTerminalConnection[] termConns

conns[i].getTerminalConnections(); for(j = 0; j<termConns.length; j++) { if(termConns[j].getTerminal().getName.equals(termName) && termConns[i].getState() ! = TerminalConnection.PASSIVE) { return termConns[i].getConnection(); } } } } There is no common address for controllers in final and consult call, but the controller TerminalName is same for both the controller Addreses. So, application should rely on CommonTerminalName to find out the connections, terminal connections and controllers. Note Interface Changes See CiscoTransferStartEv, on page 665 Message Sequences See Direct Transfer Across Lines Use Cases, on page 1157 Backward Compatibility This feature is backward compatible. To provide backward compatibility for applications, a new permission to devices that allow connected transfer across lines has been added, along with a new standard role and a standard user group for this permission. Applications can control these devices only if this new role Standard Supports Connected Xfer/Conf is associated to the application user. Applications will be able to control these devices only if this new role "Standard CTI Allow Control of Phones supporting Connected Xfer/Conf" is associated to the application user. So, by default these devices are listed as restricted, assuming that the application uses JTAPI 7.1.2 or higher 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), JTAPI throws an exception and marks these devices as restricted from there on. However, the application can invoke DirectTransfer Across Lines from existing JTAPI transfer() API on any type of phone and there is no restriction on this behavior as applications are expected to issue this request only if they support this feature. Also, a FarEnd point performing a Direct/Connected Transfer Across Lines is uncontrolled and can cause problems to applications. This means that JTAPI always reports events for Direct Transfer Across Lines for all the phones. Be aware that any old JTAPI application will not have any BWC issues if it is run in an environment where Direct Transfer Across Lines is not invoked (either on phones or through JTAPI API). However, applications changes are required if this this feature is used in such a setup. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 81 Features Supported by Cisco Unified JTAPI Event Flow Comparison and Sample Code

Cisco assumes that two or more applications do not control or observe the same terminal or address simultaneously. If they do, all instances of this application make changes to support this feature or coordinate to avoid any problem. Otherwise, application behavior may be unforeseen. For example, if App1 and App2 are two applications controlling or observing the same terminal or address and App1 makes changes to support this feature then App2 is also expected make changes to support the feature. Else, invocation of this feature by App1 on common devices can break App2. As, the feature is designed to provide an enhanced user experience, Cisco strongly recommends that all Cisco Unified JTAPI applications should evaluate and support this feature and upgrade if necessary with the code logic to handle both the old and new behavior. Directed Call Park This feature allows the user to park a call by transferring the call to a user-selected park code. Examples A calls B; B transfers the call to a parked DN. On completion of the transfer, the A to B call is parked at the specified parked DN. A will receive MOH (if configured). When C unparks the call (by dialing the prefix code and park code), A and C connect. If A calls the parked DN directly, A connects to the parked DN, and the system marks this parked DN as busy. A stays connected to this parked DN until park reversion. If C does not unpark the call at the parked DN, the call park reverses to the DN that parked the call (B), and A and B connect again. B can again try to d-Park to another parked DN. When park reversion occurs, Cisco Unified Communications Manager JTAPI passes a new reason code to the application. CTI sends the parked number to Cisco Unified Communications Manager JTAPI in the form “Park Number: (<Prefix Code>)<DPark DN>”. Cisco Unified Communications Manager JTAPI parses this and exposes both Prefix Code and DPark DN to applications. When a call is unparked, the parked party and unparking party both receive a CPIC event with the reason given by CTI, and the parked party connects to the unparking party. When party A calls a dPark DN and party B also calls the same dPark DN, the system can connect either A or B to the dPark DN, and the other party is disconnected. Cisco Unified Communications Manager JTAPI Support Cisco Unified Communications Manager JTAPI supports this feature. When the system transfers a call to a directed call park DN (dparked), the application sees a connection created for directed call park DN, and the call control connection state is CallControlConnection.QUEUED. The system delivers CiscoTransferstart and end events. An application can use the new interface on CiscoConnection to get the prefix code needed to unpark the call. Performance and Scalability This feature provides the same performance impact as the existing transfer feature. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 82 Features Supported by Cisco Unified JTAPI Directed Call Park

Directory Change Notification Applications require notification asynchronously of device additions or deletions from the user control list and device deletions from the Cisco Unified Communications Manager database. Applications also receive notification about line changes to a device. This notification gets sent to Cisco Unified JTAPI and propagates to applications with CiscoAddrCreatedEv, CiscoAddrRemovedEv, CiscoTermCreatedEv, and CiscoTermRemovedEv on the AddressObserver and TerminalObservers, respectively. Ensure that the device is registered for CTIPorts and CTIRoutePoints to receive the line change notification. Note Do Not Disturb Do-Not-Disturb (DND) gives phone users the ability to go into the DND state on the phone when they are away from their phones or do not want to answer the incoming calls. The DND softkey enables and disables this feature. From the user windows, users can configure the following settings for DND: • DND Option-Ringer off • DND Incoming Call Alert-beep only/flash only/disable • DND Timer-value between 0-120 minutes. It specifies a “period in minutes to remind the user that DND is active”. • DND status-on/off The Application can only enable or disable the DND status. Note • The Application can set the DND status by invoking a new interface on CiscoTerminal. • JTAPI will also query the application about any change in the DND status when DND status is set by phone, Cisco Unified Communications Manager Administration, or application. • The application must enable the filter in CiscoTermEvFilter to receive the preceding notification. • The application can also query for the DND status through a new interface on CiscoTerminal. • The application can also query for the DND option through a new interface on CiscoTerminal. This feature applies to phones and CTI ports. It does not apply to Route points. Note In the case of emergency calls (made by a CER application) landing on an application that has DND enabled, the system overrides the DND settings and presents the call to the application. A new parameter, FeaturePriority, in the redirect() and selectRoute() APIs on CiscoCall, CiscoConnection, and CiscoRouteSession, respectively, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 83 Features Supported by Cisco Unified JTAPI Directory Change Notification

makes this possible. The CER application that initiates the emergency call sets FeaturePriority as FeaturePriority_Emergency. The application sets the feature priority only for emergency calls. In the case of normal calls, applications either do not set the feature priority at all or set it to FeaturePriority_Normal. Applications do not set FeaturePriority_Emergency in case of normal calls. When initiating feature calls such as intercom, applications must specify FEATUREPRIORITY_URGENT. The connect() API on CiscoCall does not support the FeaturePriority parameter. Note The application receives an exception if it tries to perform a getDNDStatus(), setDNDStatus(), or getDNDOption() before the device is in service. A Post condition is added to DND to handle a DB update failure or device out-of-service situations if they occur after the setDNDStatus() request is sent. If a DB update failure or device out-of-service condition occurs after the setDNDStatus() request is sent, setDNDStatus() delivers a CiscoTermDNDStatusChangedEv to the application. If this event is not received, a post-condition time-out occurs, and the following exception is thrown: could not meet post conditions of setDNDStatus(). Backward Compatibility This feature is backward compatible. Applications recognize new events if this feature is configured. You can filter the new events through the TerminalEventFilter interface (CiscoTermEvFilter). By default, this filter is disabled and the system does not deliver the new events. For additional information, see the following topics: • CiscoTerminal, on page 617 • CiscoTermDNDStatusChangedEv, on page 610 • CiscoTermEvFilter, on page 614 • CiscoCall, on page 332 • CiscoConnection, on page 386 • CiscoRouteSession, on page 523 • CiscoTermInServiceEv, on page 644 Do Not Disturb-Reject Do Not Disturb–Reject (DND–R) is an enhancement to the existing DND feature. Cisco Unified Communications Manager and JTAPI previously supported only the Ringer off DND. The user can reject calls with DND–Reject. You can set DND–R from the phone configuration window or the phone profile configuration window in Cisco Unified Communications Manager Administration. When DND–R is enabled, the call is not presented to the terminal that has Call Reject enabled. There is no audible or visual indication of incoming calls on that end point. To enable DND–R, set the DND Status as true and the DND option to Call Reject. FeaturePriority overrides DND. It can have any of the following values: • 1: Normal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 84 Features Supported by Cisco Unified JTAPI Do Not Disturb-Reject

• 2: Urgent • 3: Emergency This release introduces FeaturePriority in connect() API on CiscoCall. FeaturePriority in selectRoute() and redirect() API is already supported in prior releases. When feature priority as EMERGENCY is specified in connect() API, and the destination terminal has DND–R enabled, the call still rings at the destination terminal and overrides the DND–R settings. When a terminal has DND–R enabled and receives an intercom call, DND–R settings are overridden and call presents. This is because feature priority is always 2 (URGENT) for intercom calls. In non- shared line scenario where A calls B and Terminal B has DND–R enabled, CallCtlConnFailedEv with cause USER_BUSY is delivered on A. Users would see the same behavior if DND–R is enabled on all the terminals that have shared DNs. In the case of shared lines when at least one of the terminal does not have DND–R enabled and a call is placed to the shared line, Cisco Unified JTAPI delivers TermConnPassiveEv and CallCtlTermConnInUseEv for the terminals that have DND–R enabled (assuming the call was made with NORMAL feature priority). TermConnPassiveEv and CallCtlTermConnBridgedEv is delivered if DND–R is disabled on the terminal during a call. A new event CiscoTermDNDOptionChangedEv will be sent to the terminal observer whenever the DND option changes on the phone window or Common Phone Profile window in Cisco Unified Communications Manager Administration. Default DND option is Ringer–off and Route points do not support DND. Interface Changes CiscoTermDNDStatusChangedEv, on page 610; CiscoCall, on page 332; CiscoTermEvFilter, on page 614 Message Sequences DND-R, on page 899 Backward Compatibility This feature is backward compatible. Application will receive new events if this feature is configured. The new events are filtered through TerminalEventFilter interface (CiscoTermEvFilter). By default filter is disabled and the new events are not delivered. Drop Any Party This feature provides the capability to drop any participants from a conference call. Cisco Unified JTAPI allows applications to drop participants from conference using the existing interface Connection.disconnect() even if the application is not observing the address for the connection. Previously, applications could only disconnect connections for which Address is an observed Address. Feature behavior varies based on the settings for the Cisco Unified Communications Manager service parameter Advanced Ad Hoc Conference Enabled. If this service parameter is set to False, applications can drop connections for an unobserved address in a conference call only if the application observes the conference controller's address. If this parameter is set to True, applications can drop connections without any restriction. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 85 Features Supported by Cisco Unified JTAPI Drop Any Party

Cisco Unified JTAPI provides an interface on CiscoConnection to get an array of CiscoPartyInfo objects for the connection. CiscoPartyInfo is used to disconnect participants from a conference using a new interface, disconnect(), provided on CiscoConnection. A normal line has only one CiscoPartyInfo on its connection, but a shared line has one CiscoPartyInfo for each line in the shared line. This enables applications to selectively disconnect a shared line participant if more than one shared line participants are in the conference call. Since shared line participants have only one connection, if the application uses the existing Connection.disconnect() API, it drops all the shared line participants. Cisco Unified JTAPI provides an interface setDropAnyPartyEnabled() on CiscoJtapiProperties to enable or disable this feature and by default, it is enabled. Alternatively, applications can have the JTAPI ini parameter dropAnyPartyEnabled = 0 in jtapi.ini file to disable Drop Any Party feature and dropAnyPartyEnable = 1 to enable this feature. If dropAnyPartyEnable parameter is not present in jtapi.ini file, the feature is enabled by default. Cisco Unified JTAPI also provides an interface, isConferenceCall(), on CiscoCall to determine if a call is a conference call. This simple method returns a Boolean. Interface Changes See CiscoCall, on page 332 and CiscoConnection, on page 386 Message Sequences See Drop Any Party Use Cases, on page 1184 Backward Compatibility This feature is backward compatible. Dynamic CTI Port Registration This feature lets applications provide an IP address (ipAddress) and port number (portNumber) for each call or whenever media is established. To use this feature, applications must register the media terminal by supplying media capabilities. When a call is answered at this media terminal, CiscoMediaOpenLogicalChannelEv is sent to applications. This event gets sent whenever media is established. Applications must react to this event and specify the IP address and port number where media gets established. A CiscoMediaTerminal represents a special kind of CiscoTerminal that allows applications to terminate RTP media streams. Unlike a CiscoTerminal, a CiscoMediaTerminal does not represent a physical telephony endpoint, which is observable and controllable in a third-party manner. Instead, a CiscoMediaTerminal represents a logical telephony endpoint, which may be associated with any application that terminates media. Such applications include voice messaging systems, interactive voice response (IVR), and softphones. Only CTIPorts appear as CiscoMediaTerminals through Cisco Unified JTAPI. Note Terminating media comprises a two-step process. To terminate media for a particular terminal, an application adds an observer that implements the CiscoTerminalObserver interface by using the Terminal.addObserver method. Finally, the application registers its IP address and port number to which the terminal incoming RTP streams get directed by using the CiscoMediaTerminal.register method. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 86 Features Supported by Cisco Unified JTAPI Dynamic CTI Port Registration

To register the ipAddress and portNumber dynamically on a per-call basis, applications must register by only providing capabilities that they support. Applications must react to CiscoMediaOpenLogicalChannelEv that gets sent whenever media is established. If any features are performed before applications react to CiscoMediaOpenLogicalChannelEv, the features may fail. If the applications do not respond to this event during the time that is specified in the Media Exchange Timer in the Cisco Unified Communications Manager Administration windows, the call may fail. For details on the interface changes, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for Dynamic CTIPort Registration Per Call, see Message Sequence Charts, on page 761 The ChangeRTPDefaults interface is not supported on CiscoMediaTerminal. Note The following new or changed interfaces exist for Dynamic CTIPort Registration Per Call: Interface CiscoMediaOpenLogicalChannelEv Extends CiscoTermEv getpacketSize() Returns the packet size of the far end in milliseconds. int getPayLoadType() Returns the payload format of the far end, one of the following constants: int getCiscoRTPHandle () Returns the CiscoTerminalConnection object on which applications must invoke the setRTPParams request. CiscoRTPHandle Interface CiscoRTPHandle getHandle() Returns an integer representation of this object, currently the Cisco Unified Communications Manager CallLeg ID. int CiscoProvider getCall (CiscoRTPHandle rtpHandle) Returns the call object with the rtpHandle that is associated with a specific terminal. If no callobserver gets added to the terminal at the time when the applications receive CiscoRTPHandle in CallOpenLogicalChannelEv, CiscoCall may be null. CiscoCall Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 87 Features Supported by Cisco Unified JTAPI Dynamic CTI Port Registration

E911 Teleworker The main purpose of this feature was intended to provide Location awareness for teleworkers and off premise users so that they can make emergency calls from off premises. The API's can also be used by all applications in a generic way as described below. Primarily this feature adds two JTAPI API methods (selectRoute & redirect) that are overloaded to add an additional XML parmater to the list of their exisiting parameters. Any application can use these overloaded selectRoute() and redirect() methods to pass XML data to the call receiving side. The format of the XML data that can be passed is seen below: <data> <item> <type>contact</type> <operation>append</operation> <protocol>SIP</protocol> <value>;+sip.instance = "<urn:uuid = *guid*>"</value> </item> </data> When an application sends XML data using one of the above API, CTI parses the data and extracts the text from the 'value' node in the XML and passes it on to CCM. CCM will then append this text to the outgoing SIP Invite message 'contact:' header. Once the end points like the SIP trunk or the SIP phone receives it, they can extract that data from the contact header and process it. Currently only SIP protocol's contact header field data is the only one supported but this can be expanded to include others headers fields and other protocols in future releases. In the current release of CUCM only the following values for the XML nodes are supported: type: contact, operation: append, protocol: SIP. The value node in the above xml format is the one that carries the required application data to the end point. The new parameter is a double byte array for overloaded selectRoute () Method to accommodate xml data for each selected routes and single byte array for the redirect () method. The parameter takes either a XML format String or a NULL value. Interface Changes CiscoRouteSession, on page 523, CiscoConnection, on page 386 Message Sequence E911 Teleworker, on page 902 Backward Compatibility This is a new feature and will be backward compatible Enable or Disable Ringer The CiscoAddress extension allows applications to set the status of the ringer for all lines on a device. No events generate when the ringer setting gets changed from the administration windows or anywhere else. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 88 Features Supported by Cisco Unified JTAPI E911 Teleworker

Encryption Enhancement Unified Communications Manager Release 10.0(1) adds support for public key encryption which is more secure than the former symmetric key method. All JTAPI clients must be upgraded to the latest version bundled with Unified Communications Manager Release 10.0(1) to leverage this security enhancement. The JTAPI client is available under the “Applications-Plugins” menu from CCMAdministration. The service parameter “Require Public key encryption” has been added. This parameter determines the encryption method required by Unified Communications Manager when authenticating CTI applications. When set to True, Unified Communications Manager requires CTI applications to authenticate using public key encryption; available in JTAPI client version 10 or later. When set to False (default), Unified Communications Manager allows CTI applications to authenticate by using either symmetric key or public key encryption. CTI applications must upgrade JTAPI/TSP client plugins to version 10.0(1) or later to authenticate when using public key encryption. Although there are no interface changes for this enhancement, Cisco recommends that applications update CiscoJTAPI libraries to take advantage of this security enhancement. No changes are required in the application layer. Applications need to update the Cisco JTAPI to the 10.x version to leverage the new security enhancement. Note Cisco recommends that applications upgrade their Cisco JTAPI versions and set this service parameter to true. In future releases this service parameter will be deprecated. Note Interface Changes There are no interface changes for this feature. Message Sequences See Encryption Enhancement, on page 903. Backward Compatibility To maintain backward compatibility, a new CTI Manager service parameter is introduced: “Require Public Key Encryption.” End to End Call Tracing This feature enables the application to track any call uniquely. JTAPI associates a uniqueID with every Connection object. The same ID is exposed to the application through a new API getUniqueID(Terminal term) on the interface CiscoConnection. This uniqueID is only available for connection of observed addresses. When a connection is created, the application can receive the uniqueID and write it in the Call Details Record. For Shared Line scenarios, each shared line has a uniqueID, which can be retrieved by passing the corresponding Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 89 Features Supported by Cisco Unified JTAPI Encryption Enhancement

Terminal to getUniqueID API. UniqueID may or may not be the same for different shared lines depending on the scenario. The application can query the uniqueID corresponding to each shared line on receiving TermConnActiveEv for that shared line Terminal. Whenever the uniqueID changes, JTAPI delivers CiscoConnectionUniqueIDChangedEv to the call observer of the application. As of Release 8.0(1), there is no supporting use case where JTAPI delivers CiscoConnectionUniqueIDChangedEv event to the application. Note Interface Changes CiscoConnection, on page 386, CiscoConnectionUniqueIDChangedEv, on page 399. Message Sequences End to End Call Tracing, on page 904 Backward Compatibility This feature is backward compatible. EnergyWise Deep Sleep Mode This feature allows the phone to participate in an EnergyWise enabled system. The phone reports its power usage to a EnergyWise compliant switch to allow the tracking and control of power within the customer premise. The phone provides alternate reduced power modes including an extremely low, off mode. The Cisco Unified Communications Manager administrator configures and exclusively manages the phones power state through vendor specific configuration on the Cisco Unified CM Admin pages. When the phone turns off power after negotiation with an EnergyWise switch, it unregisters from Cisco Unified CM and enters Deep Sleep/PowerSavePlus mode. Phones automatically re-register back with the Cisco Unified CM once the Deep Sleep mode configured PowerON time is reached. However, you can press the ‘select’ key on the Cisco Unified IP Phones Series 9900 and 6900 while in Deep Sleep/PowerSavePlus mode to wake up the phone, these phones automatically power on and re-register back with the Cisco Unified CM. However, for Cisco Unified IP Phones 7900 Series phones, you can neither power on nor re-register back with the Cisco Unified CM during Deep Sleep/PowerSavePlus mode unless the ‘PowerON’ time is reached. You can configure Deep Sleep mode on the Device page of the Cisco Unified CM. Configure Deep Sleep mode for the phones at least 10 minutes before the actual power off time to allow the information to synchronize between the switch and the phone. The Power off idle timer enables only in the case when there is physical interaction on the phone. For example if there is a call on the EnergyWise configured phone during the deep sleep time and the user tries to disconnect the call from the application, then the power off idle timer defaults to 10 minutes but if the user disconnects the call manually from the phone, then the power off idle timer takes the value configured on the Cisco Unified CM device page. When a terminal unregisters from Cisco Unified CM, JTAPI exposes CiscoProvTerminalUnRegisteredEV event to application with a new reason “CiscoProvterminal UnRegisteredEV.ENERGYWISE_POWER_SAVE_PLUS”. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 90 Features Supported by Cisco Unified JTAPI EnergyWise Deep Sleep Mode

JTAPI sends CiscoTermOutOfServiceEv event to the application with the cause “CiscoOutOfServiceEv.CAUSE_ENERGYWISE_POWER_SAVE_PLUS” when a terminal goes out of service due to Deep Sleep mode configured. JTAPI sends CiscoAddrOutOfServiceEv event to application with a new cause “CiscoOutOfServiceEv.CAUSE_ENERGYWISE_POWER_SAVE_PLUS” when an address goes out of service due to Deep Sleep mode configured. Interface Changes public interface CiscoProvTerminalUnRegisteredEv When a terminal unregisters from the Cisco Unified CM because of Deep Sleep mode, JTAPI sends CiscoProvTerminalUnregisteredEv to the application with the reason “ENERGYWISE_POWER_SAVE_PLUS”. Field Summary ENERGYWISE_POWER_SAVE_PLUS public static final int Reason Codes ENERGYWISE_POWER_SAVE_PLUS Sample Code:public class MyTermObserver implements ProviderObserver { public void providerChangedEvent (ProvEv[] evlist) { for(int i = 0; evlist ! = null && i < evlist.length; i++){ … … If ( evlisth[i] instanceof CiscoProvTerminalUnregisteredEv){ CiscoProvTerminalUnregisteredEv ev

(CiscoProvTerminalUnregisteredEv)evlist[i]; if(ev.getReason()

= CiscoProvTerminalUnregisteredEv.ENERGYWISE_POWER_SAVE_MODE){ System.out.println(“Terminal Unregistered from CUCM because of deep with the reason as ENERGYWISE_POWER_SAVE_PLUS ”); } public interface CiscoOutOfServiceEv When a terminal/address unregisters from the Cisco Unified CM because of deep sleep mode, Jtapi delivers CiscoTermOutOfServiceEv and CiscoAddrOutOfServiceEv to the application with this new cause “CAUSE_ENERGYWISE_POWER_SAVE_PLUS”. Field Summary CAUSE_ENERGYWISE_POWER_SAVE_PLUS public static final int Cause Code CAUSE_ENERGYWISE_POWER_SAVE_PLUS Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 91 Features Supported by Cisco Unified JTAPI EnergyWise Deep Sleep Mode

Message Sequences Energywise Deep Sleep Mode, on page 923 Backwards Compatibility This feature is backward compatible. Extension Mobility Cross Cluster This feature allows users to log in to an IP phone registered to a cluster with user profiles configured with another cluster. The Extension Mobility feature allows a user to log in to an IP phone to appear as user's desk phone temporarily, subject to the administrative policy. After logging on to an IP phone, the user can receive incoming calls normally routed to the user's desk phone and retain the personalized configuration, such as speed dials, services links and other user-specific properties. Currently, Extension Mobility service is limited to a single Cisco Unified Communications Manager (Cisco Unified Communications Manager) cluster. A user provisioned in one cluster today cannot log in to an IP phone of another cluster with the Extension Mobility feature, even though both clusters may belong to the same enterprise. This limitation is overcome with the introduction of this new feature, which allows the user provisioned in one cluster to log in to an IP phone of another cluster. With the existing behavior, when a user logs in to a terminal with a user ID that matches the user ID used by Cisco Unified Communications Manager JTAPI application, the terminal is treated as part of the control list and application is able to add call observer on the terminal and/or address. As part this feature support, Extension Mobility profiles can be added to the user's control list via the Cisco Unified Communications Manager Admin pages. When a user uses Extension Mobily to log into a device using a profile in the control list, JTAPI delivers CiscoAddrCreatedEv and CiscoTermCreatedEv, and application can add call observer to control the terminal or address. JTAPI exposes getCiscoCause () API on all provider events. For provider events associated with non-Extension Mobility login or logout scenarios, the cause delivered will be CiscoProvEv.NORMAL. For provider events associated with Extension Mobility login or logout scenario, the cause may be any of the below depending on the type of Extension Mobility login or logout: CiscoProvEv.CAUSE_EM_LOGIN CiscoProvEv.CAUSE_EM_LOGOUT CiscoProvEv.CAUSE_EM_LOGIN_PROFILE_ADD CiscoProvEv.CAUSE_EM_LOGOUT_PROFILE_REMOVE Interface changes explain more about each of these causes. The following is a complete set of provider events that have API getCiscoCause(): CiscoAddrActivatedEvCiscoAddrActivatedOnTerminalEv CiscoProvFeatureEv CiscoProvTerminalCapabilityChangedEv CiscoAddrRestrictedEv CiscoTermActivatedEv CiscoTermRestrictedEv CiscoAddrCreatedEv CiscoTermCreatedEv CiscoAddrRemovedEv CiscoTermRemovedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 92 Features Supported by Cisco Unified JTAPI Extension Mobility Cross Cluster

CiscoAddrAddedToTerminalEv CiscoAddrRemovedFromTerminalEv. JTAPI exposes getLoginType () on CiscoTerminal to indicate if the terminal is part of the Home or Visiting cluster when a user does an Extension Mobility login or logout. Accordingly, return value will be CiscoTerminal.NO_LOGIN, CiscoTerminal.NATIVE_LOGIN or CiscoTerminal.VISITOR_LOGIN. Home Cluster is the Cisco Unified Communications Manager cluster from which the traveling EMCC user starts. This is the user's home cluster where the user profile resides. Visiting Cluster is the Cisco Unified Communications Manager cluster which the traveling EMCC user visits. This is also the cluster that owns the phone at which the user does Extension Mobility login. Interface Changes CiscoProvEv, on page 481, CiscoTerminal, on page 617 Message Sequences Extension Mobility Cross Cluster, on page 978 Backward Compatibility This feature is backward compatible. Extension Mobility Username Login The Extension Mobility Login Username enables applications to get the Extension Mobility login username from the API provided on CiscoTerminal. Interface Changes CiscoTerminal, on page 617 Message Sequences Extension Mobility Login Username, on page 1126 External Call Control External Call Control enables Cisco Unified Call Manager (Cisco Unified Communications Manager) to route calls based on enterprise policies and presence-based routing rules of individual users. When call intercept is enabled, Cisco Unified Communications Manager queries the designated web services hosting the enterprise policies or user rules and routes the calls following the routing decisions returned. Starting from Release 8.0(1), JTAPI supports wildcard routepoins, as well as translation patterns. Interface Changes CiscoCall, on page 332, CiscoConnection, on page 386, CiscoAddress, on page 289 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 93 Features Supported by Cisco Unified JTAPI Extension Mobility Username Login

Message Sequences External Call Control, on page 929 Backward Compatibility This feature is backward compatable. Existing applications will not be impacted by the changes for this feature. There are, however, implications and limitations to applications regarding Wildcard Routepoints as they exist today, which are being addressed by adding a service parameter, described below. Applications that do not use Wildcard Route Points will be completely unaffected by this development. The first is that an application controlling wildcard routepoints used to get three JTAPI connections on a call. One with the caller, the second with the dialed Directory Number and the third with the wildcard routepoint that JTAPI is observing. The third connection has been removed with this feature. The second backward compatability issue is with the various called party fields during a Wildcard Routepoint scenario. Before implementation of this feature, CiscoCall.getCalledAddress() and CiscoCall.getCurrentCalledAddress() both returned the actual dialed Directory Number, and it was not possibl eto retrieve the Wildcard Directory Number. After this fix, both CiscoCall.getCalledAddress() and CiscoCall.getCurrentCalledAddress() return the Wildcard Directory Number, while CiscoCall.getModifiedCalledAddress() returns the actual dialed Directory Number. This is a fix for an issue that built an errorenous call model in JTAPI, but it may cause applications using this feature in this way to break. Both these issues have been addressed by adding a new service parameter at the CTI layer, known as Use WildCard pattern in CTI Call Info. This service parameter is set to OFF by default and continues the existing behavior. If an application wants to take advantage of the new information provided to it regarding Wildcard Routepoints, the service parameter must be changed to ON. This service parameter applies only when wild card Route Point is the called party. You must note that there are use cases for this feature that provide details of the Wildcard Routepoint scenario with the service parameter set to both ON and OFF, but the use case where it is set to OFF is currently not supported, shows the call flow as it exists today. End to End Session ID for Calls Cisco Unified Communications Manager generates a unique session identifier for each leg in a call. This feature enables the application to track a call end to end uniquely with a Session ID. Cisco JTAPI exposes the following new methods for applications to get unique session identifiers for each connection in a call: • CiscoConnection.getLocalUUID(TerminalConnection) • CiscoConnection.getPeerUUID(TerminalConnection) The methods accept a TerminalConnection object associated to that connection as a parameter, and return a String representing the UUIDs of the local and peer participant in a given CiscoConnection respectively. If a null object is passed as a parameter, the methods will return the UUID of the active TerminalConnection in the CiscoConnection. The SessionID is acquired by merging the localUUID and the peerUUID in the following format: device=<localUUID>;remote=<peerUUID>; The Session ID is generated within Cisco Unified Communication Manager for non-SIP devices. SIP devices generate their own Session IDs and publish them in the SIP INVITE message to Cisco Unified Communication Manager. This information is visible to the application through the respective interface. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 94 Features Supported by Cisco Unified JTAPI End to End Session ID for Calls

The Local Universal Unique Identifer (localUUID) for a CiscoConnection in a CiscoCall is generated in the peerUUID on the other side in the CiscoCall and vice versa. This relation is assured for a basic two party call and is retained through the following features: • Redirect • Call Forward • Transfer • Hold/Resume If the Cisco call is shared between multiple devices, the CiscoConnection.getPeerUUID(null) on the calling side will return the UUID of any of the available terminals while the CiscoConnection on the called side is in CiscoConnection.ALERTING state. Once the call is answered CiscoConnection.getPeerUUID(null) on the calling side will return the uuid of the active TerminalConnection. Interface Changes CiscoConnection, on page 386. Message Sequences End to End Session ID for Calls, on page 981 Backward Compatibility This feature is backward compatible. FIPS Compliance This feature allows Unified Communications Manager to operate in Federal Information Processing Standard (FIPS) mode. FIPS specifies a minimum security level for cryptographic functions, limitations on how data is stored, and which algorithms are allowed to be used to encrypt sensitive information. These strictly defined requirements are important to government agencies, hospitals, and other customers who're interested in a higher level of security. To enable FIPS Compliance, Unified Communications Manager applications must request this mode when they download certificates with JTAPI and open a provider. When operating in FIPS, Unified Communications Manager experiences minimal performance loss. You can only witness this loss during the certificate downloads and opening of a Cisco Unified Communications Manager JTAPI provider. FIPS does not affect anything when the application is running. Starting from Release 8.6(1), JTAPI can be configured as FIPS-compliant. Important Notes In FIPS, there are two distinct “cryptographic entities”: The JTAPI application and the Unified CM server (or cluster). The FIPS compliance of one does not, in any way, affect the other. Setting JTAPI to run in FIPS compliance encrypts the client-side certificates with a FIPS-compliant algorithm, and connect using only approved SSL/TLS algorithms. It will not make the Unified CM server or cluster secure or FIPS-compliant. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 95 Features Supported by Cisco Unified JTAPI FIPS Compliance

Likewise, having the Unified CM operate in FIPS mode will not make JTAPI store certificates with FIPS-compliant algorithms. They are distinct items, separated by a”cryptographic boundary.” Also, even if JTAPI operates in FIPS-compliant mode, your application may not. Your applications must handle cryptographic information and other sensitive data with special attention to be FIPS-compliant. As mentioned earlier, applications that need to use FIPS compliance must not only explicitly request it, but also download cryptographic libraries and modify their classpath variables to include them. Until Unified Communications Manager Release 12.5(1), JTAPI used RSA libraries for FIPS-compliant operations. With Release 12.5(1) and later, JTAPI on Windows uses RSA libraries, while on Linux it uses CiscoJ libraries. As of Unified Communications Manager Release 14SU2, JTAPI uses BCFIPS libraries for all security-related operations. If configured to operate in FIPs mode, JTAPI moves BCFIPS libraries to approved only mode to enforce FIPS compliance. The libraries are detailed below: The RSA libraries are: “jcmFIPS.jar” “cryptojcommon.jar”, “ cryptojce.jar” and “sslj.jar”, are FIPS-compliant libraries from RSA, Inc. The CiscoJ libraries are: The CiscoJ libraries are “CiscoJCEProvider.jar”, “log4j-1.2.17.jar”, “slf4j-api-1.7.24.jar”, “slf4j-log4j12-1.7.24.jar”, “slf4j-simple-1.7.24.jar”, “bcpkix-jdk15on-154.jar”, and “bcprov-jdk15on-154.jar”. From Release 12.5(1)SU5 on this train and up to 14SU1, “bcpkix-jdk15on.jar” and “bcprov-jdk15on.jar” are used instead of “bcpkix-jdk15on-154.jar” and “bcprov-jdk15on-154.jar” respectively. Note From Release 14SU2 to 15SU1, the BCFIPS libraries are: • bc-fips.jar (version 1.0.2.3) • bctls-fips.jar (version 1.0.12.3) • bcpkix-fips.jar (version 1.0.5) Note Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 96 Features Supported by Cisco Unified JTAPI FIPS Compliance

From Release 15SU2 onwards, the BCFIPS libraries are: • bc-fips.jar (version 2.0.0) • bctls-fips.jar (version 2.0.19) • bcpkix-fips.jar (version 2.0.6) • bcutil-fips.jar (version 2.0.1) If you're upgrading the BCFIPS jars in your runtime environment to the latest supported (2.x as aforementioned) and an application is using an older jtapi.jar (earlier than 15SU2), while setting up the application environment, you must explicitly set "org.bouncycastle.jsse.fips.allowRSAKeyExchange" to True as a runtime system property to ensure that CAPF operation succeeds. Note These libraries contain special implementations of several key cryptographic functions that replace the older implementation in jtapi.jar. If your application contains a lib folder where third-party libraries are stored, the classpath looks as follows: • For the JTAPI plugin using RSA libraries (refer above for library usage information as per the Unified Communications Manager release): ./libs/jcmFIPS.jar;./libs/cryptojcommon.jar;./libs/cryptojce.jar;./libs/sslj.jar;./libs/jtapi.jar • For the JTAPI plugin using CiscoJ libraries (refer above for library usage information as per the Unified Communications Manager release): ./libs/CiscoJCEProvider.jar;./libs/CiscoJUtils.jar;./libs/CiscoJCEJNI.so;./libs/libssl.so; ./libs/libssl.so.1.0.1;./libs/log4j-1.2.17.jar;./libs/libciscosafec.so;./libs/libciscosafec.so.4; ./libs/libciscosafec.so.4.0.1;./libs/libcrypto.so;./libs/libcrypto.so.1.0.1; ./libs/slf4j-api-1.7.24.jar;./libs/slf4j-log4j12-1.7.24.jar;./libs/slf4j-simple-1.7.24.jar; ./libs/bcpkix-jdk15on.jar;./libs/bcprov-jdk15on.jar;./libs/jtapi.jar • For the JTAPI plugin using BCFIPS libraries (refer above for library usage information as per the Unified Communications Manager release): ./libs/bc-fips.jar;./libs/bcpkix-fips.jar;./libs/bctls-fips.jar;./libs/jtapi.jar Even with the classpath set this way, the JTAPI security code works the same way it does now unless the application specifically requests to run in FIPS mode. To request that JTAPI run in a FIPS-compliant mode, applications must use some of the new methods that are introduced as part of this feature development and specify the new “fipsCompliant” parameter as True. For more information, see the following “Interface Changes” section. Interface Changes CiscoJtapiPeerImpl, on page 434, CiscoProvider, on page 492, and CiscoJtapiProperties, on page 435 Message Sequences No impact. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 97 Features Supported by Cisco Unified JTAPI FIPS Compliance

Backward Compatibility This feature is backward compatible. JTAPI, including secure providers, runs exactly as they do today, if the application does not specify that they wish to run in FIPS-compliant mode. This choice is deliberate; applications unaffected by FIPS compliance do not interact with FIPS compliance. No changes are required on the applications’ part. Applications that want to operate in a FIPS-compliant mode has to explicitly request it when downloading certificates with JTAPI, and when opening a provider. In addition, applications are required to download supplementary cryptographic libraries (jar files) from the Unified CM server, and modify their classpath accordingly to include them before the jtapi.jar library. Forced Authorization and Client Matter Codes Forced Authorization Codes (FACs) force the user to enter a valid authorization code prior to extending calls to specified classes of dialed numbers (DN), such as external, toll, or international calls. Authorization information is written to the Cisco Unified Communications Manager CDR database. Client Matter Codes (CMCs) let the user enter a code before extending a call. Customers can use Client Matter Codes for assigning accounting or billing codes to calls that are placed, and Client Matter Code information is written to the Cisco Unified Communications Manager CDR database. Supported Interfaces Cisco Unified JTAPI supports FAC and CMC in the following interfaces: • Call.Connect() • Call.Consult() • Call.Transfer(String) • Connection.redirect() • RouteSession.selectRoute() Call.Connect() and Call.Consult() When an application initiates a call with one of these interfaces to a DN that requires an FAC, CMC, or both codes, CiscoToneChangedEv is delivered on a CallObserver that also contains which code or codes are required for the DN. The getCiscoCause() interface returns CiscoCallEV.CAUSE_FAC_CMC for this even if it is delivered because of FAC_CMC feature. The getTone() interface returns CiscoTone.ZIPZIP to indicate that a ZIPZIP tone played. Upon receiving the CiscoToneChangedEv, applications need to enter the appropriate code or codes by using the connection.addToAddress interface with a # terminating string. Digits either can be entered one at a time within the interdigit timer value (T302 timer) for each digit including the # terminating character, or all the digits, including the # termination character, can be entered within the T302 timer value that is configured in Cisco Unified Communications Manager Administration. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 98 Features Supported by Cisco Unified JTAPI Forced Authorization and Client Matter Codes

When FAC and CMC Are Both Required For a DN that requires both codes, the first event is always applies for the FAC, and the second code applies for the CMC, but the application can send both codes, separated by a pound sign (#), in the same request. The second event remains optional, based on what the application sends in the first request. The application can send both codes at the same time, but both codes must end with #. as shown in the following example: connection.addToAddress(“1234#678#”) where 1234 represents the FAC and 678 specifies the CMC. In this case, the application does not receive a second CiscoToneChanged. The first CiscoToneChangesEv will have getWhichCodeRequired() = CiscoToneChanged.FAC_CMC_REQUIRED, and getCause() = CiscoCallEv.CAUSE_FAC_CMC. In response, one of the following cases can occur: • The application sends FAC and CMC in the same connection.addToAddres(code1#code2#) request. In this case, no second CiscoToneChangedEv gets sent to the application. • The application sends only a FAC code in connection.addToAddress(code#1). In this case, the application receives a second CiscoToneChangedEv with getWhichCodeRequired() = CiscoToneChangedEv.CMC_REQUIRED. • The application sends only part of the first code or the complete first code and incomplete second code (if the code is not terminated with #, it remains is incomplete and the system waits for the T302 timer to expire and tries to validate the code). If the code is incomplete, a second CiscoToneChangedEv tone gets generated with getWhichCodeRequired() = CiscoToneChangedEv.CMC_REQUIRED and getCause() = CiscoCallEv.CAUSE_FAC_CMC. PostCondition Timer The PostCondition timer resets each time that the connection.addToAddress interface is invoked to send code. FAC and CMC must have the terminal # [for example, Connection.assToAddress(“1234#”), where 1234 is the FAC]. The system waits for the T302 timer to expire, then extends the call if all codes have been entered. If all codes have not been entered, the system plays reorder tone. In this case, the application could receive PlatformException with postConditionTimeout even if the call is extended. To avoid this, the application needs to increase the postcondition timeout by using JTAPI Preferences. If the application uses call.connect() or call.consult() to initiate a call, but the FAC or CMC (including #) is not entered from a Cisco Unified IP Phone within the postcondition timeout limit, the request could get a platformException with postCondition timeout, but the call may actually get extended. To avoid this, the application needs to increase the postcondition timeout by using JTAPI preferences. Shared Lines If the initiating party is a shared line, applications need to use setRequestController to set active terminalConnection before passing additional digits by using the connection.addToAddress interface. Invalid or Missing Codes If a code is invalid or no code is entered before the T302 timer expires, the call gets rejected with callCtlCause cause code as CiscoCallEv.CAUSE_FAC-CMC. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 99 Features Supported by Cisco Unified JTAPI Call.Connect() and Call.Consult()

Call.transfer(String) and Connection.redirect() Two additional string parameters (facCode, cmcCode) are added to these interfaces to support FAC and CMC. The default value for these codes represent null values. No CiscoToneChangedEv gets delivered for these requests for DNs that require codes. A call that is conditionally redirected to a DN, a FAC, a CMC, or both, does not get rejected but remains connected if either code is incorrect. RouteSession.selectRoute() Two additional arrays of string parameters (facCode, cmcCode) support FAC and CMC. For each routeselect element, applications can specify the code for the DN. Applications need to specify null values for DNs that do not require any codes. The default values for the codes are null values. If one routeselected element does not contain the correct code, the next element in the arrays gets tried. If all of them fail, reRouteEvent gets sent to the application. The system does not support forwarding to a DN that requires an FAC or CMC code. The application can set the forward number to these DNs by using the Address API, but calls forwarded to these numbers are rejected. Note Forwarding on No Bandwidth and Unregistered DN This feature enhances the forwarding logic to handle the No Bandwidth & Unregistered DN cases: • No Bandwidth: When a call cannot be delivered to a remote destination due to no bandwidth, the system reroutes the call to the AAR Destination Mask or voice mail. The user makes these configuration changes from the directory number window of the Cisco Unified Communications Manager GUI. • Unregistered DN: When a call is placed to an unregistered DN, the system delivers the call to a DN that is configured for Call Forward on No Answer (CFNA). When a call is forwarded due to Call Forward No Bandwidth (CFNB) to another cluster destination over a trunk/gateway that is using QSIG, call history might get lost. For example, if Phone A calls Phone B, which is in a low bandwidth location, with CFNB set to forward calls to Phone C, which is in a different cluster, and the QSIG protocol is used for this intercluster forwarding, then the original called party and the last redirecting party might not get passed to the destination party. GetCallID in RTP Events GetCallID provides an interface on RTP events to access any call information, such as calling party or called party, so applications can link RTP events with the calls. The callLegID that is received in the RTP events from CTIManager gets used to determine the ICCNCall on the client side. This call passes on to the JTAPI layer, and the CiscoCall gets determined, from which CiscoCallID is obtained. This information gets used to construct the RTP events that are delivered to the application. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 100 Features Supported by Cisco Unified JTAPI Call.transfer(String) and Connection.redirect()

The following interface gets added to CiscoRTPInputStoppedEv, CiscoRTPInputStartedEv, CiscoRTPOutputStoppedEv, and CiscoRTPOutputStartedEv: { public CiscoCallID getCallID(); } GetCallInfo GetCallInfo interface on address provides applications with the ability to query CallInfo on an address. A query returns the CiscoAddressCallInfo object, which contains information about the number of active or held calls, maximum number of active or held calls, and the call object for current calls on the address. This interface also specifies what calls are at a specific address at a specific time. Use the following interface to get information about calls that are present at the terminal: { public CiscoAddressCallInfo getAddressCallInfo(Terminal iterminal);} GetGlobalCallID GetGlobalCallID provides an interface on the CiscoCallID to get the nodeID and the Global Call ID (GCID) of the call; this exposes the GCID information that is available in the internal call object. The following methods get added to the CiscoCallID interface: { /**

• returns the callmanager nodeID of the call */ public int getCallManagerID(); /**
• returns the GlobalCallID of the call */ public int getGlobalCallID (); } } Hairpin Support A hairpin call happens when the call leaves one cluster to some other device across the gateway, then comes back to a device in the same cluster. The GCID for the call coming back into the cluster would differ from the GCID that originally initiated the call, even though both are in the same cluster. In previous releases, if JTAPI controlled both parties, there were two connections: one for CiscoAddress.Internal and the other for CiscoAddress.External. JTAPI supports hairpin calls when an application monitors both ends of the hairpin call. Previously, only one end of the hairpin call could be monitored because the address was represented only as a DN. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 101 Features Supported by Cisco Unified JTAPI GetCallInfo

In the current release, if two addresses exist with the same DN but one is within the same cluster and the other is across the gateway, JTAPI creates a separate address object for the external DN, and only one connection is returned for an address, based on its type. This process avoids hairpin issues, as in previous releases when the address was represented only as a DN and when an application retrieved connections for the address it used to get two connections. Since fixing these issues could have caused compatibility issues with previous releases, a generic solution for these issues was developed in this release. Calls that involve an external party with the same DN as the monitored local party are now properly supported; however, no new interface is added for this feature. Backward Compatibility This feature is not backward compatible. Half-Duplex Media Support Currently JTAPI media events CiscoRTPInputStarted, CiscoRTPOutputStarted, CiscoRTPInputStopped and CiscoRTPOutputStopped do not indicate whether media is half duplex (receive only / transmit only) or full duplex (both receive and transmit). This enhancement adds the capability to provide this information in a JTAPI media event. JTAPI provides an interface on the above media events to query whether media is half duplex or full duplex. The half duplex media support feature does not impact JTAPI backward compatibility. A new interface getMediaConnectionMode() is added to Cisco Unified JTAPI RTP events. This interface will return the following values depending on the media: • CiscoMediaConnectionMode.NONE • CiscoMediaConnectionMode.RECEIVE_ONLY • CiscoMediaConnectionMode.TRANSMIT_ONLY • CiscoMediConnectionMode.TRANSMIT_AND_RECEIVE. CiscoRTPInputStarted/StoppedEv should only return RECEIVE_ONLY and TRANSMIT_AND_RECEIVE. The interface should not return NONE or TRANSMIT_ONLY. Ifthat happens, applications should ignore the event or log an error. CiscoRTPOutputStarted/StoppedEvshould only return TRANSMIT_ONLY and TRANSMIT_AND_RECEIVE. The interface should not return values NONE or RECEIVE_ONLY. Ifthat happens, applications should ignore the event or log an error. CiscoMediaOpenLogicalChannedEvshould only return RECEIVE_ONLY and TRANSMIT_AND_RECEIVE. The interface should not return values NONE or TRANSMIT_ONLY. Ifthat happens, applications should ignore the event or log an error. public interface CiscoRTPInputStartedEv getMediaConnectionMode() Returns CiscoMediaConnectionMode int public interface CiscoRTPOutputStartedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 102 Features Supported by Cisco Unified JTAPI Half-Duplex Media Support

getMediaConnectionMode() Returns CiscoMediaConnectionMode int public interface CiscoRTPInputStoppedEv getMediaConnectionMode() Returns CiscoMediaConnectionMode int public interface CiscoRTPOutputStoppedEv getMediaConnectionMode() Returns CiscoMediaConnectionMode int Hold Reversion The Hold Reversion feature provides applications with a notification when Cisco Unified Communications Manager notifies an address about the presence of a held call, when the call has been ONHOLD for a certain amount of time. Applications receive this notification as the CiscoCallCtlTermConnHeldReversionEv call control terminal connection event on their call observers on the particular address that has put the call ONHOLD. This notification is provided only once for the applications for the held call. The event is sent only to the terminal connection of the terminal where the call was put on hold. If the address represents a shared line address, other terminal connections of the shared line address will not receive the event. To receive this event, applications must add a call observer to the address. The cause for this event will be CAUSE_NORMAL. If the call observer is added after the hold reversion timer has expired and the notification has already been sent to the phone, applications will receive CiscoCallCtlTermConnHeldReversionEv with cause CAUSE_SNAPSHOT. For more information, see CiscoCallCtlTermConnHeldReversionEv, on page 352. Hunt List This feature enables the JTAPI application to observe addresses and terminals that are HuntList LineGroup members. Calls can arrive at these addresses either by another address calling it directly or through HuntPilot. When a call is made to HuntPilot, JTAPI creates a CiscoHuntConnection to represent HuntPilot and provides a Call Model that gives applications the information that the call is routed through HuntPilot. When a call is routed through HuntPilot and is connected to LineGroup Member, JTAPI call has three connections, two regular connections for calling and called addresses, and one CiscoConnection to HuntPilot through which that call was routed. HuntPilot is not an observable address. The address representing Hunt Pilot is created when a call is made to a Hunt Pilot and is removed when the call is over. Applications cannot receive the Hunt Pilot address from the provider by using the getAddress() method. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 103 Features Supported by Cisco Unified JTAPI Hold Reversion

In normal Hunt List calls, there are three connections, Calling, Hunt Pilot, and Hunt Member. When a call is made to the Hunt Pilot Directory Number, the call is offered to one of its members depending on the algorithm. The initial state of the call is Offering at the member. If members are not observed, the connection to Hunt Pilot goes through the normal states as CallCtrlConnection or Connection. If members are observed, connection to member goes to Offering state and the connection to Hunt Pilot goes to Established state. Applications must use the states of the observed party to track the state of the call. call.getCurrentCalledParty() for a call to Hunt Pilot returns an address of type CiscoAddress.HUNT_PILOT. If the Hunt List member is the called address and is not observed by the application, connection to the member is created only when the call is answered. CiscoHuntConnection extends CallControlConnection and can get into states that a call control connection could transition to expect for the network states. Hunt pilots are represented by CiscoAddress objects and getType () would return CiscoAddress.HUNT_PILOT. Only addresses returned for Cisocall.getCurrentCalledAddres () and CiscoCall.getCurrentCallingAddress () will have CiscoAddress.HUNT_PILOT type. When calls to hunt pilot are involved in transfer or conference operations CiscoTransferStartEv, CiscoTransferEndEv, CiscoConferenceStartEv and CicsoConferenceEndEv are not delivered. Applications should use CiscoCallChangedEv to identify surviving call. If consult calls or final call have CiscoHuntConnection, the application should not expect Transfer or Conference start and end events. When configured in broadcast mode, all Hunt List members ring simulatenously. In JTAPI, call connections and terminal connections for Hunt List members are created only for members observed by the application. Applications must enable this feature using the setHuntListFeatureEnabled (boolean) on CiscoJtapiProperties. This feature is disabled by default and applications are encouraged to adapt to the above call model and enable the feature using setHuntListFeatureEnabled () API. Observing a hunt list member without enabling the feature using setHuntListFeatureEnabled () is not a supported configuration and if observed, results in inconsistent call model and events. setHuntListFeatureEnabled() is introduced to enable applications that are currently using unsupported call scenarios with Hunt List to migrate to a supported model without breaking the existing functionality. Applications can also enable this feature by adding, HuntListEnabled = 1, to jtapi.ini file and restarting the application. Interface Changes CiscoHuntConnection, on page 411, CiscoConnection, on page 386, CiscoAddress, on page 289, CiscoJtapiProperties, on page 435 Message Sequences Hunt List, on page 1000 Backward Compatibility This feature is backward compatible. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 104 Features Supported by Cisco Unified JTAPI Hunt List

Hunt List Connected Number In Cisco Unified CM 9.0, the support for hunt pilots is enhanced to expose the connected number as the modifiedCalledAddress in a call involving a hunt pilot. With this enhancement, when a user calls a hunt pilot and the call is answered by the hunt member L1, call.getModifiedAddress() returns the address of the member L1, whereas call.getCurrentCalledAddress() returns the address of hunt pilot. Before the call is answered, both these values will return the address of hunt pilot. Interface Changes There are no interface changes for this feature. Message Sequences See Hunt List Connected Number, on page 1043 Backward Compatibility This feature is backward compatible. To enable this feature, a new Hunt Pilot configuration, "Display Line Group Member DN as Connected Party" is introduced. Application may choose to enable or disable feature based on their requirements. By default, this feature is disabled. Hunt Log Status With this feature, the Cisco JTAPI interface includes the ability of a terminal to sign in and sign out of the hunt group through CTI applications. Previously, this functionality was only available from Cisco Unified CM Administration interface. Once a terminal is logged into a hunt group, it is able to receive calls which are offered on the line group where the line of terminal is associated. Cisco Terminal is enhanced with two new methods: • CiscoTerminal.getHuntLogStatus() • CiscoTerminal.setHuntLogStatus() These two new methods are used to get and set the value of huntLogStatus and the three new constants CiscoTerminal.DEVICE_HUNT_LOGGED_IN, CiscoTerminal. DEVICE_HUNT_LOGGED_OUT and CiscoTerminal. DEVICE_HUNT_NOT_APPLICABLE. The value is CiscoTerminal.DEVICE_HUNT_LOGGED_IN by default for any terminal that has the ability to log in to the hunt group. A new interface, CiscoTermHuntLogStatusChangedEv, is introduced for applications to be notified with the event CiscoTermHuntLogStatusChangedEv when the value of hunt log status is changed and the filter is set. CiscoTermEvFilter is enhanced with two new methods: CiscoTermEvFilter. setHuntLogStatusChangedEvFilter(boolean filterValue) and CiscoTermEvFilter.getHuntLogStatusChangedEvFilter() to set and get the value of filter, if the application Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 105 Features Supported by Cisco Unified JTAPI Hunt List Connected Number

wants to be notified by the event CiscoTermHuntLogStatusChangedEv the filter should be set to true. The value of filter is false by default. The above methods are invoked only on devices which have observers added on it and the terminal object is in service. Note Interface Changes CiscoTermHuntLogStatusChangedEv, on page 672 CiscoTerminal, on page 617 CiscoTermEvFilter, on page 614 Message Sequences Hunt Log Status for Phone Devices, on page 920 Backward Compatibility This feature is backward compatible. Intercom The Intercom feature allows one user to call another user and have the call answered automatically with one-way media from the caller to the called party, regardless of whether the called party is busy or idle. The called user can press the talk back softkey (unmarked key) on their phone display, or the called user can invoke the join() JTAPI API, that is provided on TerminalConnection, to start talking to the caller. Only a specially configured intercom address on the phone can initiate an intercom call. Cisco Unified JTAPI creates a new type of address object named CiscoIntercomAddress for intercom addresses that are configured on the phone. The application can get all the CiscoIntercomAddresses that are present in the provider domain by calling the interface getIntercomAddresses () on CiscoProvider. An intercom call can be initiated from the Cisco Unified JTAPI interface by calling the CiscoIntercomAddress.ConnectIntercom () interface. The application provides an intercom target DN for this interface. If the intercom target DN is preconfigured or preset by the application, the application can get the target DN by calling the CiscoIntercomAddress.getTargetDN() interface; otherwise, the application must provide a valid intercom target for the call to be successful. An intercom call is autoanswered at the intercom target; Cisco Unified JTAPI will move TerminalConnection/CallCtlTerminalConnection at the intercom target to the Passive/Bridged state. The application can invoke a join () interface on the TerminalConnection of the intercom target to initiate talk back. If join () is successful, the TerminalConnection/CallCtlTerminalConnection of the intercom target will move to an Active/Talking state. For an intercom call, Cisco Unified JTAPI only supports the following interfaces: • Call.drop () • Connection.disconnect () • CallCtlTerminalConnection.join () Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 106 Features Supported by Cisco Unified JTAPI Intercom

The application cannot perform any feature operations on an intercom call. Cisco Unified JTAPI will throw an exception if the application invokes redirect, consult, transfer, conference, or park for a Connection on a CiscoIntercomAddress. The application will also receive an exception if it tries to invoke setForwarding (), getForwarding (), cancelForwarding (), unPark (), setRingerStatus (), setMessageWaiting (), getMessageWaiting (), setAutoAcceptStatus (), or getAutoAcceptStatus () on CiscoIntercomAddress. Applications can get the value of a configured intercom target DN and the label on a CiscoIntercomAddress from the provided API. Cisco Unified JTAPI provides two types of APIs: one to return the default and another to return the current value set for the intercom target. The default value is the intercom target DN and label that are preconfigured through Cisco Unified Communications Manager Administration. The current value is the interim target DN and label that the application sets. If the application has not set any value, the current value remains the same as the default value. Applications can invoke the API setIntercomTarget () on CiscoIntercomAddress to set the intercom target DN, label, and unicode label. Only one application can set the intercom target, label, and unicode label for an intercom address. If two applications try to set the value, the first succeeds, and the second receives an exception. When a intercom target DN and label changes, Cisco Unified JTAPI provides a CiscoAddressIntercomInfoChangedEv to the AddressObserver that is added to CiscoIntercomAddress. If the application has set an intercom target DN and label, and a JTAPI or CTI failover or failback occurs, JTAPI or CTI will restore the previously set value of the intercom target DN, label, and unicode label. If the JTAPI or CTI cannot restore the intercom target DN, label, or unicode label, Cisco Unified JTAPI provides a CiscoAddrIntercomInfoRestorationFailedEv to the AddressObserver on CiscoIntercomAddress. In the case of an application failure, or if for any reason the application goes down, the target DN, label, and unicode label will reset to the default. JTAPI provides the interface resetIntercomTarget () on the CiscoIntercomAddress to reset the intercom target. Auto-answer always stays enabled for CiscoIntercomAddress. The application can invoke the method getAutoAnswerEnabled () on CiscoAddress to get the auto-answer capability of an address. For an intercom target that is connected with one-way media to the Intercom initiator, the device state would be set to CiscoTermDeviceStateWhisper. This is a new device state for the terminal object. In this state, the terminal can initiate a new call or receive a new incoming call. If the application enables a filter to receive this device state, the application receives CiscoTermDeviceStateWhisperEv. The application can enable a filter by calling setDeviceStateWhisperEvFilter() on CiscoTermEvFilter. The DeviceStates DEVICESTATE_ACTIVE, DEVICESTATE_HELD, and DEVICESTATE_ALERTING all override DEVICESTATE_WHISPER; if one call exists in active, held, or alerting state, and another in whisper, the DeviceState will be DEVICESTATE_ACTIVE, DEVICESTATE_HELD, or DEVICESTATE_ALERTING, respectively. The Cisco Unified JTAPI implements the javax.telephony.TerminalConnection interface join() to let the intercom target talk back to the initiator. The system implements this interface for CiscoIntercomAddresses only. If applications invoke this interface for regular shared lines in a passive or bridged state, JTAPI throws a MethodNotImplimented exception. Note This feature is backward compatible if the application-controlled devices (terminals) do not have intercom lines configured on them. Applications can disable the intercom feature by not having an intercom line configured on the application-controlled devices (terminals). Tip For detailed information about these interface changes, see the following topics: • CiscoHuntConnection, on page 411 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 107 Features Supported by Cisco Unified JTAPI Intercom

• CiscoAddrIntercomInfoRestorationFailedEv, on page 311 • Related Documentation, on page 289 • CiscoCall, on page 332 • CiscoProvider, on page 492 • CiscoTermEvFilter, on page 614 • CiscoTerminal, on page 617 • CiscoTerminalConnection, on page 636 • CiscoTermDeviceStateWhisperEv, on page 607 Intercom Support for Extension Mobility In Release 6.0(1) of Cisco Unified Communication Manager, support for intercom feature was added. Intercom feature requires destination to be auto-answered with one-way audio; therefore, no shared addresses can be configured for intercom. When user logs in by using Extension Mobility (EM) profile, it is possible to end up with shared address for intercom; so, currently extension mobility is not supported with intercom. Due to the wide use of extension mobility, this CIA is addressing the need to support intercom for extension mobility while still maintaining the single destination nonsharable nature of intercom addresses. This feature requires intercom addresses to be configured with default terminal, and allows configuring of intercom address on EM profile. When EM user logs in to a terminal with EM profile that is configured with an intercom address, intercom address is available only if default terminal of intercom address is same as terminal where user has logged in. If an intercom address is configured on terminal but default terminal for intercom address is not that terminal, intercom address does not appear on terminal. If this terminal is configured in the control list of Cisco Unified JTAPI application, JTAPI does not create intercom address in the provider domain. From Cisco Unified JTAPI point of view, there is no new interface or changes to support this feature. However, this feature introduces some transitional scenarios where intercom functionality may not work on intercom addresses. See the use cases. Backward Compatibility This feature is backward compatible. IPv6 Support This feature provides support for a nonsecure JTAPI connection in IPv6 only deployments. It enables Cisco Unified JTAPI applications to see the IPv6 address as the calling party address if the IPv6 support feature is enabled and if the Calling Party is using an IPv6-enabled phone. This feature supports the following functions: • Cisco Unified JTAPI exposes the new API canSupportIPv6() on the CiscoProviderCapabilities Interface to indicate whether Cisco Unified Communications Manager configuration is supporting IPv6. • Cisco Unified JTAPI closes the media or route terminal if there is a mismatch between what has been previously registered and what is currently configured. CiscoTermRegistrationFailedEv and the new reason code IP_ADDRESSING_MODE_MISMATCH are then sent as per this scenario. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 108 Features Supported by Cisco Unified JTAPI Intercom Support for Extension Mobility

• The IP Address capability of the Terminal is exposed by API getIPAddressingMode() on the CiscoTerminal Interface. The IP Address capability is available on CiscoTerminal/CiscoMediaTerminal and CiscoRouteTerminal. • The IPv6 calling party IP address is provided through the Cisco extensions of CallCtlConnOfferedEv and RouteEvent in an InetAddress object as well as the IPv4 address for IPv4-enabled devices. The RTP Address in CiscoRTPOutputStartedEv and CiscoRTPInputStartedEv also has an IPv6 address in case the observed device is an IPv6 device. That is, the API getLocalAddress() on CiscoRTPInputProperties and the API getRemoteAddress() on CiscoRTPOutputProperties can now return an IPv6 format IP Address. The API returns an InetAddress object, and applications can verify that it is an instance of Inet4Address or Inet6Address to determine if it is an IPv4 or IPv6 format IP Address. Applications must reset the devices after their IP Addressing Mode is changed, otherwise there might be ambiguity in the expected results. From Release 7.1, Cisco Unified JTAPI provides getIPAddressingMode() API on CiscoTerminal. The getIPAddressingMode() API for CTI Ports and Route Points are also supported from this release. Cisco Unified JTAPI extends the same API on CiscoTerminal and it returns the configured IP addressing mode of the IP phone on the Cisco Unified Communications Manager Admin pages. If the user modifies the IP Addressing mode from the Cisco Unified Communications Manager Admin pages after the device is registered, the device must be reset. The updated value from Cisco Unified JTAPI is exposed only after the IP phone is reset. If the configured IP Addressing mode supports both IPv4 and IPv6 addresses, the phone may be registered with either of these addresses or with both. This depends on conditions such as network type and Cisco Unified Communications Manager support for IPv6. So, if the IP Addressing mode mode supports both IPv4 and IPv6 addresses, getIPAddressingMode() on CiscoTerminal returns CiscoTerminal.IP_ADDRESSING_MODE_IPV4_V6. We do not support a secure JTAPI connection in IPv6 only deployments with TLS. Note Interface Changes See CiscoTerminal, on page 617 Message Sequences See IPv6 Support, on page 1129 and IPv6 Support, on page 1236 Backward Compatibility This feature is backward compatible. iSac Codec This enhancement provides support for iSac codec and enables the application to register CiscoMediaTerminal or CiscoRouteTerminal with iSac codec capability. For this codec, frame size and bit rate are variable and determined dynamically. Applications do not set these values. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 109 Features Supported by Cisco Unified JTAPI iSac Codec

The bit rate and packetSize that are exposed on interface CiscoRTPInputProperties and CiscoRTPOutputProperties will not be a constant for this codec, so application logic should not rely on these values if codec (payloadType) is iSac. Interface Changes See CiscoIsacMediaCapability, on page 415 Message Sequences iSac Codec, on page 1057 Backward Compatibility This feature is backward compatible. Java Socket Connect Timeout The Java Socket Connect Timeout enhancement enables the configuration of a timeout in seconds by using the Cisco Unified JTAPI specification and prevents connection delays to the CTIManager when the primary CTI Manager. The default is 15 seconds. If the default of 15 seconds is unacceptable to the application, the default JAVA API of zero (0) sets the behavior to the normal JAVA Socket Connect API. The values range from 5 through 180 seconds. Zero defaults to Java behavior of the socket connect without any time-out for connection. Interface Changes See CiscoJtapiProperties, on page 435. Message Sequences See CiscoJtapiProperties, on page 1128. Backward Compatibility This feature is backward compatible. Join Across Lines In this version, this feature allows applications to conference two calls that are on different addresses of the same terminal. It will also let applications add participants to a conference using a noncontroller. Join across lines is not supported on CTI-supported phones that run SIP. You can disable join across lines feature by turning off Join Across Lines Policy service parameter, while you can disable Conference Chaining and feature to allow noncontroller adding participant to conference by disabling the “Advanced Ad Hoc Conference Enabled” and “Non-linear Ad Hoc Conference Linking Enabled” service parameters. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 110 Features Supported by Cisco Unified JTAPI Java Socket Connect Timeout

Join Across Lines is supported only on phones that run SCCP. Note Interface Changes There are no interface changes for this feature. Applications can use the current conference interfaces to conference calls on different addresses on the same terminal. Backward Compatibility This feature is backward compatible. Join Across Lines (Only SCCP) The Join Across Lines feature allows support for conference across lines. It allows two or more calls on different addresses of the same terminal to be joined though the join softkey on the phone or conference() API that JTAPI provides. The behavior to JTAPI applications change, as applications do not perceive a common controller in final and consult calls. There is no change in the API and the same events are delivered whether calls are conferenced on the same address (regular conference) or across addresses (Join across lines). When join across lines feature is performed CiscoConferenceStartEv/EndEv will be provided to all addresses on the controller terminal that have consult or final calls that are being joined together into one conference. In CiscoConferenceStartEv, the conferenceControllerAddress will always be the primary controller address. Application can now set the controller via the setConferenceController() API. If application does not specify this, then JTAPI itself would find a suitable controller for the conference. Cisco recommends that applications set the controller address when Join Across Lines feature is invoked. If observer is not added on the controller address, applications may see null values for either the talking or held terminal connection values in the CiscoConferenceStartEv. Before this release, when application tried a conference across lines, the request failed at the JTAPI layer itself. With this release, the conference() API implementation enhances all requests to pass through after finding suitable terminal connections of the final and consult calls. JTAPI relies on the common terminal of the addresses involved in the call to find suitable terminal connections. Multiple conference across address is also supported when more than two calls need to be joined. SIP devices in 5.1.2 release do not support this feature. JTAPI throws exception (ILLEGAL_HANDLE) if this feature is requested on a SIP device. There are no interface changes for this feature. Behavior changes with respect to events provided to applications. Backward Compatibility This feature is backward compatible, as there are no changes in the behavior of conference when this feature is not enabled. You can enable or disable this feature on a per-device basis. If the Join Across Lines setting on the device is set to Default, the system-wide CallManager service parameter Join Across Lines Policy setting is used. If this feature is enabled and application does a join across lines, there is a difference in behavior as stated. JTAPI applications written for Release 5.1 should be backward compatible with JTAPI that was released with Release 5.1.2. Consider a JTAPI client upgrade only if new features are used. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 111 Features Supported by Cisco Unified JTAPI Join Across Lines (Only SCCP)

Join Across Lines or Connected Conference Across Lines User experience is enhanced in this release by introducing Cisco Unified IP Phone models that fall outside the purview of existing Join Across Lines service parameter. For these phones this feature is always enabled, without any service parameter to turn it off. For a detailed feature description, information about interface changes, and use cases, see Join Across Lines with Conference Enhancements (SCCP and SIP), on page 116. Usage Guidelines The points below indicate how applications must use the Direct Transfer Across Lines feature: • Applications must add Call Observer on the both the lines across which they try join across lines or connected conference. • Earlier, applications were recommended to check if both the calls have a common address and if that common address is on the same Terminal. For Join Across Lines, it is not required to check if the address is comoomon between two calls across which direct conference is invoked. It must be ensured that both the calls should each have an address that exists in common terminal. • Cisco Unified JTAPI reports the same set of events, as it does currently, for conferencing of calls on the same address. Applications are not required do anything with these calls after invoking Conference() until receiving CiscoConferenceEndEv. • As conference is done across addresses, applications do not get a common controller in CiscoConferenceStartEv and should upgrade the application logic. See Event Flow Comparison and Sample Code, on page 112 for details. Event Flow Comparison and Sample Code The following table provides details of the event flow also sample code. Table 3: Event Flow Comparison and Sample Code for Conference Invocation Join Across Lines Join on Same Lines Setup Address A on Terminal T1 Address B1, B2 on Terminal T2 Address C on Terminal T3 Address A on Terminal T1 Address B1, B2 on Terminal T2 Address C on Terminal T3 Feature Invokation A calls B1[GC1 = GolbalCallID1] GC1: Connection A1 Conn1 GC1: Connection B1 Conn2 B2 calls C[G = GolbalCallID2] GG2: Connection B2 Conn3 GC2: Connection C Conn4 GC1.conference(GC2) A calls B1[GC1 = GolbalCallID1] GC1: Connection A1 Conn1 GC1: Connection B1 Conn2 B1 calls C[GC2 = GolbalCallID2] GG2: Connection B1 Conn3 GC2: Connection C Conn4 GC1.conference(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 112 Features Supported by Cisco Unified JTAPI Join Across Lines or Connected Conference Across Lines

Join Across Lines Join on Same Lines Events Delivered to Application (assuming all parties are observed) GC1: CiscoConferenceStartEv [getConferenceControllerAddress() returns B1] ConnCreatedEv for C ConnConnectedEv for C CallCtlConnEstablishedEv for C TermConnCreatedEv for T3(Address C) CiscoConferenceEndEv GC2: CiscoConferenceStartEv [getConferenceControllerAddress() returns B1] TermConnDroppedEv for T2(Address B2) CallCtlTermConnDroppedEv for T2(Addresss B2) ConnDisconnectedEv for B2 CallCtlConnDisconnectedEv for B2 TermConnDroppedEv for T3(Address C) ConnDisconnectedEv for C CallCtlConnDisconnectedEv for C CallCtlTermConnDroppedEv for T3(Address C) CiscoConferenceEndEv CallInvalidEv CallObservationEndedEv Note GC2 - Disconnect events are for Address B2 on Terminal T2 GC1: CiscoConferenceStartEv [getConferenceControllerAddress() returns B1] ConnCreatedEv for C ConnConnectedEv for C CallCtlConnEstablishedEv for C TermConnCreatedEv for T3(Address C) CiscoConferenceEndEv GC2: CiscoConferenceStartEv [getConferenceControllerAddress() returns B1] TermConnDroppedEv for T2(Address B1) CallCtlTermConnDroppedEv for T2(Addresss B1) ConnDisconnectedEv for B1 CallCtlConnDisconnectedEv for B1 TermConnDroppedEv for T3(Address C) ConnDisconnectedEv for C CallCtlConnDisconnectedEv for C CallCtlTermConnDroppedEv for T3(Address C) CiscoConferenceEndEv CallInvalidEv CallObservationEndedEv Note GC2 - Disconnect events are for Address B1 on Terminal T2 Note There is no common address for controllers in final and consult call, but the controller TerminalName is same for both the controller addresses. So, application should rely on CommonTerminalName to find out the connections, terminal connections and controllers. Note Application logic is based on common transferControllerAddress and works fine in this case, because commonAddr is present in both final and consult call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 113 Features Supported by Cisco Unified JTAPI Event Flow Comparison and Sample Code

In connected Conference Across Lines scenario, apart from the events mentioned, applications can see another temporary call GC3 going active(CallActiveEv) and GC3 goes idle (CallInvalidEv) immediately after the conference is completed. Note Join on Same Lines Sample Application Code Handle(CiscoCallEv event) { ….. ….. if (event instanceOf CiscoConferenceStartEv) { CiscoConferenceStartEv ev

(CiscoConferenceStartEv)event; processConference(ev); } } processConference(CiscoConferenceStartEv ev){ CiscoAddress controllerAddr

ev.getConferenceControllerAddress(); CiscoCall[] consultCalls

ev.getConferenedCalls(); CiscoCall GC1

ev.getFinalCall(); CiscoConnection[] movedConns[]

findConnections(consultCalls, controllerAddr); //Additional App logic to clear connections. } Connection[] findConnections(CiscoCall[] calls, CiscoAddress addr){ ArrayList connList

new ArrayList(); for(x = 0; x < calls.length; x++) { CiscoConnection[] conns

calls[x].getConnections(); for (i = 0; i<conns.length; i++) { if conns[i] .getAddress().equals(addr) { connList.add(conns[i]); } } } return connList.toArray(Connection[] conns); } Join Across Lines Sample Application Code Handle(CiscoCallEv event) { ….. ….. if (event instanceOf CiscoConferenceStartEv) { CiscoConferenceEv ev

(CiscoConferenceStartEv)event; processConference(ev); Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 114 Features Supported by Cisco Unified JTAPI Event Flow Comparison and Sample Code

} } processConference(CiscoConferenceStartEv ev){ String controllerTermName

ev.getControllerTerminalName(); CiscoCall[] consultCalls

ev.getConferenedCalls(); CiscoCall GC1

ev.getFinalCall(); CiscoConnection[] movedConns

findConnections(consultCalls, controllerTermName); //Additional App logic to clear connections. } Connection[] findConnections(CiscoCall calls, String termName){ ArrayList connList

new ArrayList(); for(x = 0; x < calls.length; x++) { CiscoConnection[] conns

calls[x].getConnections(); for (i = 0; i<conns.length; i++) { CiscoTerminalConnection[] termConns

conns[i].getTerminalConnections(); for(j = 0; j<termConns.length; j++) { if(termConns[j].getTerminal().getName.equals(termName) && termConns[i].getState() ! = TerminalConnection.PASSIVE) { connList.add(conns[i]); } } } } return connList.toArray(Connection[] conns); } Interface Changes See CiscoConferenceStartEv, on page 382 Message Sequences See Connected Conference or Join Across Lines Use Cases - New Phones Behavior , on page 1165 Backward Compatibility This feature is backward compatible. This feature cannot be turned off for certain devices and Cisco Unified JTAPI always reports events for Join Across Lines for these phones. However, to provide backward compatibility for applications, a new permission to allow controlling these devices and to allow connected conference across lines has been added. A new standard role Standard CTI Allow Control of Phones supporting Connected Xfer and conf and a standard user group are also added. Applications can control these devices only if this new role is associated to the application user, assuming that application is using JTAPI client 7.1.2 or higher. So, by default these devices are listed as Restricted. The application must upgrade to handle this feature and associate the new permission to 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), JTAPI throws an exception and marks these devices as restricted from there on. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 115 Features Supported by Cisco Unified JTAPI Event Flow Comparison and Sample Code

Cisco assumes that two or more applications do not control or observe the same terminal or address simultaneously. If they do, all instances of this application make changes to support this feature or coordinate to avoid any problem. Otherwise, application behavior may be unforeseen. For example, if App1 and App2 are two applications controlling or observing the same terminal or address and App1 makes changes to support this feature then App2 is also expected make changes to support the feature. Else, invocation of this feature by App1 on common devices can break App2. As, the feature is designed to provide an enhanced user experience, Cisco strongly recommends that all Cisco Unified JTAPI applications should evaluate and support this feature and upgrade if necessary with the code logic to handle both the old and new behavior. Join Across Lines with Conference Enhancements (SCCP and SIP) Join Across Lines feature supports on CTI-supported SIP phones and SCCP phones. The enhancements are: • Applications can conference two calls in which each conference is on a different address but on the same terminal. • Add participants to a conference using a non-controller. You can disable Join Across Lines by turning off the Join Across Lines Policy service parameter. Conference Chaining and the feature that allows Non-Controller adding participant to conference can be disabled by disabling the Advanced Ad Hoc Conference Enabled and Non-linear Ad Hoc Conference Linking Enabled service parameters. Note The following behavior occurs when an application issues a conference request, but selected and active calls are not part of the conference request. It also applies for user-selected calls that are not part of the conference request, but become part of the resulting conference: • The Active Call on a Terminal is always added to the resulting conference when conference is invoked on a call on any address on that terminal. Consider that B1 and B2 addresses exist on the same terminal, then: • A --> B1- GC1 • C --> B1- GC2 • D --> B2- GC3 (active call) The application invokes GC1.conference (GC2) and results in A-B1-C-D in a conference with GC1, although the call with D was not part of the conference request. An active conference call on a terminal is added to the resulting conference when conference is invoked on a call on any line on that terminal. In this case, the active conference call becomes the surviving final call (provided the application-specified primary call is not a conference call). In this example, the application specified primary call is cleared after the conference operation. It is possible that the application-specified primary call may not join the resulting conference and in that case the call is not cleared after the conference is complete. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 116 Features Supported by Cisco Unified JTAPI Join Across Lines with Conference Enhancements (SCCP and SIP)

• Consider that the B1 and B2 addresses on the same terminal and conf1 is a conference call with A-B1-C in conference with B1 as the controller, then: • B1 --> D – GC1 (on hold) • conf1 – GC2 (active call) • B2 --> E – GC3 (on hold) Application invokes GC1.conference(GC2, GC3). This results in A-B1-C-D-E in conference with GC2 as the surviving call. Although application had specified GC1 to be the primary call, GC1 does not survive after the conference. The behavior also applies to regular conferencing with a common controller. Consider A, B, C, and D are lines on different terminals, then: • A --> B - GC1 • C --> - GC2 • D --> - GC3 (active call) The application requests GC1.conference (GC2). This results in A-B-C-D in conference with GC1. Although a direct call with Dwas not part of the conference request, D joins the conference. Interface Changes There are no interface changes. You can use the current interfaces to conference calls on different addresses on the same terminal. Message Sequences Join Across Lines with Enhancements, on page 800 Backward Compatibility This feature is backward compatible. JRE 1.2 and JRE 1.3 Support Removal This release of the CiscoJTAPIClient supports only JRE 1.4. There are no interface changes; however, the JRE 1.2 and 1.3 versions are no longer supported. This change is to support QoS, which is available only in the JDK1.4 version (and above). Inaddition, jtapi.jar contains Cisco encryption files that depend on the JRE 1.3 version (and above). This provides a stronger password encryption algorithm when it is sent over TCP to CTIManager. As part of this feature, JTAPI invokes the API provided by IMS (Identity Management System, a Cisco Unified Communications Manager component) to encrypt a password before sending it. JRE 1.4 also enables Cisco Unified JTAPI to use additional JDK 1.4 APIs. Applications that use previous versions of JRE must install JDK 1.4 to use Cisco Unified JTAPI. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 117 Features Supported by Cisco Unified JTAPI JRE 1.2 and JRE 1.3 Support Removal

There are no interface changes to JTAPI Applications, however JTAPI.jar contains RSA jsafe.jar (3.3) and Apache log4j-1.2.8.jar files. If Applications are using any jar files that are not compatible with these versions of jsafe.jar (Version 3.3) and log4j-1.2.8.jar, then JTAPI or the Application may not work, depending on which one is in the classpath first Note As part of this migration, JTAPIPreferences and sample applications dependency on MS-JVM was also removed. Two new configuration parameters were provided on the Advanced tab in the JTAPI Preferences dialog box: • JTAPI Post Condition Timeout • Use Progress As Disconnected Backward compatibility This feature is not backward compatible. JTAPI Version Information In order to connect to Release 5.0 of Cisco Unified Communications Manager Administration, JTAPI clients have to upgrade to the new version of JTAPI bundled with the Cisco Unified Communications Manager Administration Release 5.0. JTAPI version is in the form of 3.0(X.Y), where X and Y depend on the sub-release. Applications cannot connect with prior release of JTAPI. Locale Infrastructure Development This feature removes currently supported languages for Cisco Unified JTAPI client install. Cisco Unified JTAPI client install is only supported in English. It also adds the capability to dynamically update the locale in JTAPI Preference application from the Cisco Unified Communications Manager server. JTAPI Preference application will continue to support all the languages that are supported in prior releases. Support for adding new languages and updating locale files is also added. Before this release, the Cisco Unified JTAPI client install and JTAPI Preferences application were localized during builds and did not add support for new languages or update locales for existing languages. The JTAPI client locale updates were performed in Cisco Unified Communications Manager maintenance releases. This feature adds capability to dynamically update locale file for JTAPI Preferences application, and JTAPI Client install is installable only in English languages. The JTAPI Client install needs the Cisco Unified Communications Manager TFTP server IPaddress. The TFTP IP address is used for downloading locale files for the preferences application. If the TFTP IP address is not entered or an incorrect IP address is entered, the preference application displays only in English language. Further on, whenever new locale updates are available, JTAPI Preferences application will notify user about available updates and update locale files. Interface Changes There are no interface changes. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 118 Features Supported by Cisco Unified JTAPI JTAPI Version Information

Message Sequences Locale Infrastructure Development Scenarios, on page 1084 Backward Compatibility This feature is backward compatible from the JTAPI Application perspective, but from the JTAPI Client install perspective, currently supported languages have been removed. In this regard, it is not backward compatible. Logical Partitioning This feature enables administrators to configure geographic locations and restrict calls that pass through a PSTN gateway to be connected directly to a VoIP phone or VoIP PSTN gateway in another geographic location. This feature allows use of single line analog phones and remains compliant with the Telecom Regulatory Authority of India (TRAI) regulation. This feature can be turned off by using the Logical Partitioning Enabled service parameter, which is disabled by default. Interface Changes See CiscoJtapiException, on page 416 Message Sequences See Logical Partitioning Feature Use Cases, on page 1233 Backward Compatibility This feature is backward compatible. Media Termination at Route Point This feature enables multiple active calls at the route point, and applications can terminate media for all active calls by specifying the IP address and port number for each call or whenever media is established. To use this feature, applications must register the route point by supplying media capabilities. When a call gets answered at this route point, CiscoMediaOpenLogicalChannelEv gets sent to the applications. This event gets sent whenever media is established. Applications must react to this event and specify the IP address and port number where they want to terminate media. A CiscoRouteTerminal represents a special kind of CiscoTerminal that allows applications to terminate RTP media streams. Unlike a CiscoTerminal, a CiscoRouteTerminal does not represent a physical telephony endpoint, which is observable and controllable in a third-party manner. Instead, a CiscoRouteTerminal represents a logical telephony endpoint, which may get associated with any application that intends to route calls and also terminate media. Unlike CiscoMediaTerminal, CiscoRouteTerminal can have multiple active calls at the same time. Typically, CiscoRouteTerminals get used to place calls in queue until an agent is available to service the caller. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 119 Features Supported by Cisco Unified JTAPI Logical Partitioning

Only RoutePoint Terminals appear as CiscoRouteTerminal through JTAPI. Note Terminating media comprises a three-step process. 1. The application registers its media capabilities with this terminal by using the CiscoRouteTerminal.register method. 2. An application adds an observer that implements CiscoTerminalObserver interface by using the Terminal.addObserver method. 3. The application must add addCallObserver on CiscoRouteTerminal or on CiscoRouteAddress to receive CiscoCall object from the provider by using CiscoRTPHandle. Applications receive CiscoMediaOpenLogicalChannelEv for each call and must supply the IP address and port number by using the setRTPParams method on CiscoRouteTerminal. You must modify applications that are written for the CiscoJtapiClient 1.4(x) release or earlier to register with CiscoRouteTerminal. NO_MEDIA_TERMINATION if the applications are not interested in media termination. Multiple applications can register with the same route point as long as they are registered with the same media capabilities and registrationType. All applications, if they have registered with CiscoRouteTerminal.DYNAMIC_MEDIA_REGISTRATION and then add a terminal observer, receive CiscoMediaOpenLogicalChannelEv, but only one application can invoke setRTPParams. Applications that terminate media must use the CallControl package for answering and redirecting calls. Applications that only route calls can use a routing package. Note Applications should be aware that, if any features are performed before reacting to CiscoMediaOpenLogicalChannelEv, the features may fail. If applications do not respond to these events in the time that is specified in the Media Exchange Timeout parameter in the Cisco Unified Communications Manager Administration windows, the call may fail. Note The following new or changed interfaces exists for Media Termination at Route Point: Interface CiscoRouteTerminal Extends CiscoTerminal isRegistered() If the CiscoMediaTerminal gets registered, this method returns true. Otherwise, it specifies false. boolean isRegisteredByThisApp() If the application issues a successful registration request, this method returns true and remains true until the application unregisters the device. This remains valid even if the device is out of service because of CTIManager failure. boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 120 Features Supported by Cisco Unified JTAPI Media Termination at Route Point

register (CiscoMediaCapability[] capabilities, intregistrationType) The CiscoRouteTerminal must exist in the CiscoTerminal.UNREGISTERED state, and the provider must exist in the Provider.IN_SERVICE state. void setRTPParams (CiscoRTPHandle rtphandle, CiscoRTPParams rtpParams) Applications set the ipAddress and the RTP port number to dynamically stream media for a call. void Unregister() Ensure the CiscoRouteTerminal is registered, and the provider is in the Provider.IN_SERVICE state. void Interface CiscoMediaOpenLogicalChannelEv Extends CiscoTermEv getpacketSize () Returns the packet size of the far end in milliseconds. int getPayLoadType () Returns the payload format of the far end, one of the following constants: int getCiscoRTPHandle () Returns the CiscoTerminalConnection object on which applications must invoke the setRTPParams request. CiscoRTPHandle Interface CiscoRTPHandle getHandle() Returns an integer representation of this object, currently the Cisco Unified Communications Manager CallLeg ID. int CiscoProvider getCall (CiscoRTPHandle rtpHandle) Returns the call object with the rtpHandle that is associated with a specific terminal. If no callobserver gets added to the terminal at the time when the applications receive CiscoRTPHandle in CallOpenLogicalChannelEv, CiscoCall may register null. CiscoCall For details on these interfaces, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for media termination at route point, see Message Sequence Charts, on page 761 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 121 Features Supported by Cisco Unified JTAPI Media Termination at Route Point

Media Termination Extensions The media termination feature allows applications to transmit and capture the bearer of a call, for example, audio or video. This action sometimes gets referred to as “rendering and recording” or “sourcing and sinking” media. It remains distinct from call control because media termination concerns the data that flows between endpoints in a call, not the details of setting up or tearing down calls. For example, an automatic call distributor (ACD) uses call control to route calls among available agents but does not terminate media. An interactive voice response (IVR) application, on the other hand, uses call control to answer and disconnect calls and uses media termination to play sound files to callers. Although no telephony applications are solely interested in media termination, this feature always gets used in combination with call control. JTAPI 1.2 primarily represents a call control specification and offers very limited support for applications that require media termination. Because the Cisco Unified Communications Solutions platform supports media termination to a much greater degree than JTAPI standard, the Cisco Unified JTAPI implementation extends JTAPI to add full support for this feature. In Cisco Unified JTAPI, software-based media termination occurs by using Computer Telephony Integration (CTI) ports. They include one or more lines (dialable numbers) that can be used to originate or receive calls. They however need a controlling application to provide the source and sink of the media. An application registers its interest in the media termination port with the Cisco Unified Communications Manager. The Cisco Unified Communications Manager then delivers all the events that relate this virtual device to the application. InCisco Unified JTAPI, CTI ports get referred to as CiscoMediaTerminals. The following figure shows the CTI port configuration. For details about administering and configuring a CTI port, refer to the Cisco Unified Communications Manager Administration information. Figure 8: CTI Port Diagram To implement a softphone application (where the PC acts as the telephone set, for example), the Cisco Unified JTAPI application would manage a CTI port. Message Waiting Indicator Enhancement The Enhanced Message Waiting Indicator (MWI) feature enables applications to provide the following message counts to be displayed on phones that support the enhanced message waiting counts: • Total number of new voice messages (includes normal and high priority messages) • Total number of old voice messages (includes normal and high priority messages) • Number of new high priority voice messages • Number of old high priority voice messages • Total number of new fax messages (includes normal and high priority messages) • Total number of old fax messages (includes normal and high priority messages) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 122 Features Supported by Cisco Unified JTAPI Media Termination Extensions

• Number of new high priority fax messages • Number of old high priority fax messages Two new APIs are added as CiscoAddress JTAPI extensions to provide the enhanced MWI message summary information. Similar to the existing setMessageWaiting APIs, one of the APIs allows summary information to be set up for the observed address. The other API allows message summary information to be set up on any address that is reachable on the observed address, as defined by the configured calling search space of the observed address. These new APIs can also be used on phone types that do not support the enhanced message counts. If used on non-supported phones, these APIs behave similar to the existing setMessageWaiting method, that is, only the messaging waiting indicator lamp is turned on or off and counts are not displayed. Interface Changes See Related Documentation, on page 289 Message Sequences See Enhanced MWI Use Cases, on page 1166 Backward Compatibility This feature is backward compatible. The existing setMessageWaiting APIs will not be modified. Applications that do not want to use the new enhanced MWI feature can continue to use these APIs for setting the MWI lamp. Modifying Calling Number This feature enables applications to modify the calling party DN in the select route API from the route point. Applications may pass an array of modifying calling numbers in the selectRoute API and an array length of modifying calling numbers may equal the length of the route that is selected. If no modifying calling number element is present for a corresponding routeSelected index or if the element is null, then no modifying calling number gets set for that route selected element. Two new interfaces getModifiedCallingAddress () and getModifiedCalledAddress () are exposed on the call object, which returns modified calling or called number. If no modification occurs, these interfaces may return the same values as getCurrentCallingAddress () and getCurrentCalledAddress () interfaces. If an application is only controlling the route point and modifies the calling number by using selectRoute API, it may not get modified calling address in the getModifiedCallingAddress interface. If an application is controlling any calling or called parties, it may get correct values after it receives call control events after the calling number is modified. A new interface, getRouteSelectedIndex (), gets exposed on the new class CiscoRouteUsedEvent, an extension of RouteUsedEvent, which gives the index of the selected route. Applications need to cast the RouteUsedEvent to the CiscoRouteUsedEvent to get access to this method. Example routeSelected[0]

133555 routeSelected[1]

144911 routeSelected[2]

143911 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 123 Features Supported by Cisco Unified JTAPI Modifying Calling Number

routeSelected[3]

5005 modifiedCallingNumber[0] = null modifiedCallingNumber[1] = 9721234567 modifiedCallingNumber[2] = 9721234568 modifiedCallingNumber[3] = null If routeSelected[0] or routeSelected[3] is selected for routing, the modifying calling number may not get applied. You can only use this feature after an administrator enables the modifying calling number check box in the Cisco Unified Communications Manager Administration for a particular user, which by default is False. If it is not configured, a RerouteEvent with the cause of RouteSession.CAUSE_PARAMETER_NOT_SUPPORTED gets sent to the applications. The application that is modifying the calling number needs to be aware that display name on the called party is affected, and subsequent feature interactions of the calling or called party may result in inconsistent behavior. The following new or changed interfaces exist for Modifying Calling Number: CiscoRouteSession selectRoute (java.lang.String[] routeSelected, intcallingSearchSpace, String[] modifiedCallingNumber) This interface allows applications to modify the calling party number to the routeSelected address. If no modifiedCallingNumber element exists for the corresponding routeSelected element, the calling number does not get modified if a call gets routed to that particular routeSelected element. void CiscoCall getModifiedCalledAddress () This interface returns a modified called address for the call if an application modifies the calling party by using the selectRoute API; however, this information may not be accurate if an application is only controlling the route point that modifies the calling number. If no modified calling number gets performed, this acts similar to the getCurrentCalledAddress interface. Typically, this gets varied from getCurrentCalledAddress when a feature gets invoked after modified calling number modifications. javax.telephony.Address getModifiedCallingAddress () This interface returns a modified calling address for the call if an application modifies the calling party by using the selectRoute API; however, this information may not be accurate if an application is only controlling the route point that modifies the calling number. If no modified calling number gets performed, this interface acts similar to the getCurrentCallingAddress interface. javax.telephony.Address CiscoRouteUsedEvent getRouteSelectedIndex() This method returns an array index of the route to where the call gets routed. int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 124 Features Supported by Cisco Unified JTAPI Modifying Calling Number

For details on the interface changes, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for Modifying Calling Number, see Message Sequence Charts, on page 761. Multi-fork Recording using CUBE Media Proxy Server Prior to Cisco Unified Communications Manager, Release 12.5(1), the Unified Communications Manager supported only single recorder for a call. With the Cisco Unified Communications Manager, Release 12.5(1), the Unified Communications Manager supports Multi-forking for Call Recording feature. The Unified Communications Manager is connected to CUBE Media Proxy server which is connected to multiple recorders. The JTAPI interface is enhanced to get the details of multiple recorders in case of Multi-Forking recording through CUBE Media Proxy server. Backward Compatibility This feature is backward compatible. JTAPI supports the current APIs. Multilevel Precedence and Preemption Support Cisco Unified Communications Manager enables the use of supplementary services by phones that are configured for Multilevel Precedence and Preemption (MLPP). Cisco Unified Communications Manager does this by maintaining the precedence level for calls. JTAPI does not provide the precedence level of applications. Note Multiple Calls Per DN Multiple calls per DN represent the ability to support multiple calls on a line (DN) and the features operation on these calls. Prior to Cisco Unified Communications ManagerRelease4.0(1), the system supported a maximum of only two calls. Cisco JTAPI now supports multiple calls per line, which allows multiple calls on the same line and feature operation on that line. No interface or message flow changes occurred for Multiple Calls Per DN. Native Queuing It is very common in a Cisco Unified CM deployment that a hunt pilot has more calls distributed through the call distribution feature than its hunt members can handle at any given time. Native Queuing feature holds the calls in a queue until they are answered. When a hunt member is available, the call is removed from the queue and offerred to the hunt member. To enable this feature, the Cisco Unified CM administrator needs to enable the check box Queue Calls in Queuing section of the Hunt Pilot configuration page. Following settings are available under Native Queuing feature configuration: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 125 Features Supported by Cisco Unified JTAPI Multi-fork Recording using CUBE Media Proxy Server

• Maximum Number of Callers Allowed in Queue (1–100): This is the queue depth configuration and reflects the maximum number calls that can be in the queue at any point of time. • Destination When Queue is Full: User Configurable Destination number to which the calls are forwarded when the Maximum Number of callers allowed in queue limit is reached. • Disconnect: This option results in the call getting rejected and dropped when the Maximum Number of callers allowed in queue limit is reached. • Maximum Wait Time in Queue (10–3600 seconds): User configurable Maximum wait time a call can be in the queue. • Destination When Maximum Wait Time is met: User Configurable destination DN to which the call is forwarded when the maximum wait time in queue is reached. • Disconnect: This option results in the call getting rejected and dropped when the the maximum wait time in queue is reached. • When There Are No Hunt Members Logged In or Registered: User configurable destination DN to which the queue feature forwards the calls when none of the hunt members in the HuntPilot are registered or logged in. • Disconnect: This option results in the call getting rejected and dropped when there are no hunt members available for the dialed hunt pilot. • Destination: User Configurable destination DN to which the call is forwarded when no hunt members available for the dialed hunt pilot. If a caller calls a hunt pilot with all its members busy, a CiscoHuntConnection will be created temporarily. Then, when this feature is enabled, the hunt connection will drop and a new connection will be created which will have the address name same as that of the hunt pilot and the address type will be CiscoAddress.INTERNAL. This new connection will be moved to CallControlConnection.QUEUED state and it will remain in this state until the call gets dequeued or dropped. Cisco JTAPI exposes the following new reasons: • CiscoFeatureReason.REASON_QUEUING • CiscoFeatureReason.REASON_DEQUEUING • CiscoFeatureReason.REASON_DEQUEUING_TIMER_EXPIRED • CiscoFeatureReason.REASON_DEQUEUING_AGENTS_BUSY • CiscoFeatureReason.REASON_DEQUEUING_AGENTS_UNAVAILABLE The above reasons indicate when a call gets enqueued and dequeued respectively because of the various configurations on the Hunt Pilot. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 126 Features Supported by Cisco Unified JTAPI Native Queuing

The behavior is different when conferencing a queued calls. If a caller which is in a queue conferences the call with another party, then the queued connection is dropped and a new connection is created with the address of the hunt pilot number and the address type is CiscoAddress.UNKNOWN, and it will be moved to CallControlConnection.ESTABLISHED state. If a call is removed from the queue, for example when an agent becomes free, the agent will be added to the conference and a connection will be created for it. For the Hunt Pilot, JTAPI creates a normal connection instead of a CiscoHuntConnection. This is a limitation of JTAPI in handling a conference with Hunt Pilot. In a case where only the Hunt member is observed, there will be no issues and JTAPI will be able to handle it. Note Interface Changes See CiscoFeatureReason, on page 408 Message Sequences See Native Queuing, on page 1287. Backward Compatibility This feature is backward compatible. Check the Queue Calls checkbox in the Hunt Pilot Configuration window to enable this feature. By default this feature is disabled. Network Alerting In earlier releases of CiscoJTAPI (CiscoJTAPI versions 1.4(x.y)), when a call was made to an address outside of the cluster, CallCtlConnNetworkReachedEv and CallCtlConnNetworkAlertingEv events were delivered to the farend address. In later versions of Cisco Unified Communications Manager (4.0 and above) and Cisco Unified JTAPI (2.0), these events were not delivered. In these versions CallCtlConnection for the farend address went to the ESTABLISHED state from the OFFERED state. The previous versions of Cisco Unified JTAPI delivered CallCtlConnOfferedEv, CallCtlConnEstablishedEv for the farend address when a call was made across a gateway with “overlap sending” turned off. CallCtlConnNetworkReachedEv and CallCtlConnNetworkAlertingEv events were not delivered to the application. In Cisco Unified Communications Manager4.0 and 4.1, the “Allow overlap sending” flag on the route pattern configured for the gateway or the “AllowNetworkEventsAfterOffered” parameter in jtapi.ini needed to be turned on to receive network events. In Cisco Unified Communications ManagerRelease 5.0, if the “Allow overlap sending” flag is enabled, an application sees ConnCreatedEv, CallCtlConnNetworkReachedEv, CallCtlConnNetworkAlertingEv, and CallCtlConnEstablishedEv for the farend address for calls across a gateway. If the “Allow overlap sending” flag is not enabled, an application sees ConnCreatedEv, CallCtlConnOfferedEv, CallCtlConnNetworkReachedEv, CallCtlConnNetworkAlertingEv, and CallCtlConnEstablishedEv for the farend address for calls across a gateway. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 127 Features Supported by Cisco Unified JTAPI Network Alerting

AllowNetworkEventsAfterOffered is not available in Cisco Unified Communications Manager Release5.0. The above events are delivered regardless of the jtapi.ini parameter setting. Note Backward Compatibility This feature is not backward compatible. Network Events In previous releases of Cisco Unified JTAPI, when a call is made to an address outside the cluster, CallCtlConnNetworkReachedEv and CallCtlConnNetworkAlertingEv events are delivered for the far-end address. In Cisco Unified Communications Manager 4.0 and later, these events do not get delivered. In these versions CallCtlConnection for the far-end address goes to the ESTABLISHED state from OFFERED state. The application will receive CallCtlConnOfferedEv, CallCtlConnEstablishedEv for the far-end address. The CallCtlConnNetworkReachedEv and CallCtlConnNetworkAlertingEv events do not get delivered to the application. To receive network events, the “Allow overlap sending” flag on the route pattern that is configured for the gateway must be turned on. A new jtapi.ini parameter, AllowNetworkEventsAfterOffered, that is introduced allow the application to control the delivery of these events. Applications that need the network events but cannot turn on this flag can use this new jtapi.ini parameter to receive network events for outgoing calls. To turn on the parameter, complete the following steps: Procedure Step 1 Run jtprefs and select the required options. This creates jtapi.ini file in c:\winnt\java\lib, if Cisco Unified JTAPI is installed in the default directory. If the jtapi.ini file already exists, you can update the file directly without running jtprefs. Step 2 Add AllowNetworkEventsAfterOffered = 1 to the end of the file and save it. Step 3 Repeat the preceding step every time Cisco Unified JTAPI is reinstalled. When the AllowNetworkEventsAfterOffered flag is enabled, the application will receive CallCtlConnOfferedEv, CallCtlConnNetworkReachedEv or CallCtlConnNetworkAlertingEv and CallCtlConnEstablishedEv for the far-end address. New Error Code in CiscoTermRegistrationFailedEv This event is sent to application when TerminalRegistration fails for some reason. The return value of getErrorCode() interface indicates the type of failure. On receiving this event, application should try to reregister the Terminal. In this version a new return value is added to this interface. CiscoTermRegistraionFailedEv.UNKNOWN is introduced in this version to handle unknown failures. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 128 Features Supported by Cisco Unified JTAPI Network Events

Backward Compatibility This feature is backward compatible. Noncontroller Adding of Parties to Conferences Any party in a conference can now add participants into the conference. In previous releases, only the conference controller could add participants. • CiscoConferenceStartEv, on page 382 contains an identifier for the requestor party. • The method getConferenceControllerAddress returns the terminal connection of the requestor. • The new method getOriginalConferenceControllerAddress() for CiscoConferenceStartEv, on page 382 returns the terminal connection of the original controller. Park DN Monitor Cisco Unified JTAPI applications can register to receive events when calls are parked and unparked. CiscoProvCallParkEv events will be delivered to provider observer when the application registers for this feature. To successfully register for this feature, ensure that the “call park retrieval allowed” flag for the user is turned on. You can access this flag with the user configuration on Cisco Unified Communications Manager Administration. After registering for this feature, the application will receive CiscoProvCallParkEv events whenever a call is parked or unparked from any device in the cluster. The following new interfaces allow applications to register and unregister for this feature: public interface CiscoProvider { public void registerFeature ( int featureID ) throws InvalidStateException, PrivilegeViolationException; public void unregisterFeature ( int featureID ) throws InvalidStateException; } The featureID is CiscoProvFeatureID.MONITOR_CALLPARK_DN. Park Monitoring and Assisted DPark Support This feature provides a new park reversion behavior to applications invoking park request. Currently, when the park reversion timer expires, the call is reverted to the address of the parker. With the new behavior, the call remains parked at the park DN, even as the Park Monitoring reversion timer expires. This feature also enables status monitoring of the parked call at the address of the parker. After a call is parked using the existing CiscoConnection.park() JTAPI API on newer phones or directly from the phone itself, Cisco Unified JTAPI delivers a new event CiscoAddrParkStatusEv, which includes the current status of the parked call. The application must then add AddressObserver on the address of the parker, and enable a filter to receive this event. If application adds an observer after the call is parked, then the events are delivered with CAUSE_SNAPSHOT. The park status in the new event can be one of the following: • Parked—Indicates a call was parked by the user of the application. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 129 Features Supported by Cisco Unified JTAPI Noncontroller Adding of Parties to Conferences

• Reminder—Indicates the park monitoring reversion timer for the parked call has expired. • Retrieved—Indicates a previously parked call was retrieved. • Abandoned—Indicates a previously parked call is disconnected while waiting to be retrieved. • Forwarded: indicates the parked call has been forwarded to the configured Park Monitoring Forwarded No Retrieve destination, as the Park Monitoring Forward-No-retrieve timer has expired. When the cause is CAUSE_SNAPSHOT the park status can be either Parked or Reminder state only. On the phone, these notifications are targeted, that is, only the device parking the call can see these notifications (devices sharing line with the parker's device does not receive similar notifications). In Cisco Unified JTAPI, getTerminal() interface on CiscoAddrParkStatusEv has been added tomanage this. This returns the terminal on whose address, these notifications were received and this is the terminal that parked the call. Cisco Unified JTAPI also provides the CiscoCallID to applications in this new event. Applications may use this to retrieve the call object. However CiscoCallID.getCall() may return null value if the call does not exist in the provider's domain at the time this event is received. Cisco Unified JTAPI provides a new interface CiscoAddrEvFilter to control or filter the new event notifications to applications. Applications may get or set the filter value through the APIs getCiscoAddrParkStatusEvFilter() and setCiscoAddrParkStatusEvFilter() on the CiscoAddrEvFilter interface. Two new methods, getFilter() and setFilter(), have also been provided in the CiscoAddress to get and set the values of the filters in the CiscoAddrEvFilter interface. Applications receive the new event notification CiscoAddrParkStatusEv only if the filter is enabled and the setFilter() is invoked on CiscoAddress. By default, the filter value for CiscoAddrParkStatusEvFilter is false to maintain backward compatibility. When a call is parked, the Park monitoring reversion timer starts and then expires. After this, Park Monitoring Forward No Retrieve timer starts. When this timer expires, and the Forward No Retrieve destination is configured, the call is forwarded to this destination. A new CiscoFeatureReason FORWARD_NO_RETRIEVE is delivered in the connection events, when connections are created at the forwarded destination. If the Forward No Retrieve destination is not configured, call is forwarded back to the parker's DN, with the same reason as when park reversion occurs (CiscoFeatureReason.PARKREMINDER). When application invokes CiscoAddress.getAddressCallInfo(Terminal term), the CiscAddressCallInfo which is returned is now enhanced to include number of parked calls. This returns the number of parked calls. Cisco Unified IP Phone 7900 Series with SIP/SCCP returns zero value even if there are calls parked by this address. This feature is applicable only when newer phones park the call. If Cisco Unified IP Phone 7900 Series with SIP/ SCCP, parks the call, user continues to see the existing behavior. So, if a Cisco Unified IP Phone parks the call and is sharing a line with a Cisco Unified IP Phone 7900 Series with SIP, the new Park Monitoring enhancements can be seen. However, if the Cisco Unified IP Phone 7900 Series with SIP or SCCP invoked park, the old Park behavior would be seen on all the phones, if application is monitoring any of these lines. Users can set the Park Monitoring Reversion Timer to zero and set the Park Monitoring Forward No Retrieve Destination to the existing Park Reversion Duration timer to get the old behavior on the Cisco Unified IP Phone (provided the Forward No Retrieve destination is not configured) if the user so desires. However, the event notification cannot be controlled. On Cisco Unified Communications Manager Service Parameter pages, the timers mentioned above can be configured. These would apply only for SIP versions of future models of Cisco Unified IP Phone . Park Monitoring Reversion timer: This timer is started as soon as the call is parked. This is the amount of time that a call remains parked before the user is reminded that there is a parked call. The range is 0-1200 seconds, with default value of 60 seconds. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 130 Features Supported by Cisco Unified JTAPI Park Monitoring and Assisted DPark Support

Park Monitoring Periodic reversion timer: The frequency in which the user is reminded about the parked call. The range is 0-1200 seconds, with default value of 30 seconds. Park Monitoring Forward No Retrieve timer: This timer is started when the park monitoring reversion timer expires. This is how long, in seconds, the park reminder notification plays before the parkee is redirected to the parker's Park Monitoring Forward No Retrieve (FNR) destination. The range is 30-1200 seconds, with default value of 300 seconds. Park Monitoring Forward No Retrieve Destination is configurable on the line page in Cisco Unified Communications Manager Line page settings. Assisted DPark provides an alternative one step way to perform DPark operation on phones. When user performs Assisted DPark from newer phones and application is monitoring the parked party, Cisco Unified JTAPI provides reason CiscoFeatureReason.REASON_REFER in the connection events (ConnCreatedEv, ConnInProgressEv and CallCtlConnQueuedEv) for DPark DN. Currently when DPark is done, application gets connection events with CiscoFeatureReason.REASON_TRANSFER. Interface Changes See CiscoAddrParkStatusEv, on page 316 Message Sequences See Park Monitoring Support, on page 1206 Backward Compatibility Park Monitoring enhancements and Assisted DPark support are backward compatible. The new park reversion behavior improves the user experience to allow the parked call to be retrievable for as long as possible. It also improves the usability of the park feature by allowing the user to monitor the status of a parked call through the new event being delivered. Applications can conditionally enable/disable filter to receive event via setCiscoAddrParkStatusEvFilter() API on CiscoAddeEvFilter. By default this filter is disabled and therefore maintains backward compatibility. If the application uses a JTAPI client older than 7.1.2, the devices are not restricted but if the application tries to observe these devices (which supports this feature to be invoked manually), JTAPI throws an exception and marks these devices as restricted from there on. Park Reminder When a parked call is not retrieved for a specified time, a reminder call returns to the address that parked the call, and Park Number connection moves to the Disconnected state. The call reconnects and moves to the Established state. A terminal connection in Talking state gets created for the address that parked the call. Park Retrieval When a call is parked from an IP phone, the park number displays on the phone. Any terminal can unpark the call by dialing the park number. When a call is unparked, a new call gets created with connections to unparked address. The CallControlConnection for the park number in the original call, which is in the Queued state, moves to the Disconnected state. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 131 Features Supported by Cisco Unified JTAPI Park Reminder

Partition Support Prior to Cisco Unified Communications Manager Release 5.0, JTAPI did not support partitions. JTAPI considered addresses with the same DN, but different partitions, as same address. It created only one Address object for such cases because addresses are identified only by their DN and not by their partition information. Beginning with Release 5.0, JTAPI supports addresses that have the same DN but belong to different partitions and treats them as different addresses. Partition information of the addresses is exposed to applications through the methods specified below. Applications that want to make use of this partition support feature must use the API provided to them through JTAPI interfaces and use the address objects accordingly. This feature is backward compatible. JTAPI supports the current APIs that are used to open and access address objects. In Cisco Unified Communications Manager Release 5.0, JTAPI is partition aware, and the following configurations are supported. • Addresses with the same DN, in the same partition, and in different devices get treated as shared lines. • The system does not allow addresses with the same DN, in the same partition and in the same device. • Addresses with the same DN, in different partitions, and in the same device get treated as different addresses. Two address objects get created for this scenario, and the application can distinguish between the two by calling the getPartition() API on the address objects. • Addresses with the same DN, in different partitions, and in different devices get treated as different addresses. Two address objects get created for this scenario and the application can distinguish between the two by calling the getPartition() API on the address objects. Partition support changes in JTAPI are confined to the address objects and do not affect any other functions or classes of JTAPI. The following sections specify the interface changes. CiscoAddress Interface A new method is provided in this class with the following signature. string getPartition () Returns the partition string of the address object. Applications need to use this method to get the partition information. JTAPI uses this partition information to distinguish between addresses that have the same DN but belong to different partitions and sends the partition information to open the specific addresses. For example, a provider open returns two addresses, A(1000, P1) and B (1000, P2), where A and B denote the address objects, 1000 denotes the DN of the address objects, and P1, P2 indicate the partitions to which the addresses belong. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 132 Features Supported by Cisco Unified JTAPI Partition Support

Figure 9: Provider Open Returns Two Addresses When the user invokes A.getPartition (), P1 gets returned while B.getPartition () returns P2. The provider.getAddresses() method returns multiple addresses in which the Address objects have the same DN but different partition information. An Application can use this method to distinguish between two Address objects that have the same DN but belong to different partitions. CiscoProvider Interface The CiscoProvider interface provides the following methods: getAddress(String number) Returns an array of Address objects that corresponds to the number and different partitions. Address[] getAddress(String number, String partition) Returns the Address object that has the same DN as the number parameter and belongs to the same partition as specified by the partition parameter. Address If two addresses A(1000, P1) and B(1000, P2) exist, where A and B denote the address objects, 1000 denotes the DN of the address objects, and P1, P2 indicate the partitions to which the addresses belong, when an application calls provider.getAddress(“1000”), it gets two address objects, A and B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 133 Features Supported by Cisco Unified JTAPI Partition Support

Figure 10: provider.GetAddress() Returns Two Address Objects When the application calls A.getPartition(), it returns P1, B.getPartition() returns P2, and so on. An Application can distinguish between the two address objects that are using the getPartition method. Consider the case where the application calls provider.getAddress(1000, P1). In this case, the application specifically looks for the address object whose DN is 1000 and partition is P1. In this case, “A” gets returned by the provider object. Figure 11: Provider Calls a Specific Address and Partition CiscoProvCallParkEv Event CiscoProvCallParkEv provides the following methods in this interface. string getParkingPartyPartition() Returns the partition string of the parking party. string getParkedPartyPartition() Returns the partition string of the parked party. string getParkPartyPartition() Returns the partition string of the park DN. For details on the interface changes, see Cisco Unified JTAPI Extensions, on page 249 To view the message sequences for partitions support, see Message Sequence Charts, on page 761 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 134 Features Supported by Cisco Unified JTAPI Partition Support

Password Expiry The administrator can use the CUCM Admin Panel to configure options for login credentials. The password expiry configuration allows the administrator to specify the following two parameters: 1. The time before the password expires (in days) and 2. The number of days before the end of the password expiry to alert the user to change the password. If a password is expired, JTAPI delivers an exception to the application. In a situation where a password is going to expire soon, JTAPI delivers a new event to the application. JTAPI does not allow applications to modify any of these values, it only reports the information. Interface Changes CiscoProvAuthenticationInfoEv, on page 56; CiscoJtapiExceptions, on page 55 Message Sequences There are no message sequences. Backward Compatibility This feature is backward compatible. Persistent Connection Persistent Connection is an extension Cisco Extend and Connect feature that was implemented in Unified Communications Manager Release 9.1. A persistent call refers to a call between the Unified Communications manager (CTI Remote Device) and a remote destination that stays up even after calls to it are dropped. JTAPI APIs and error codes were added. JTAPI supports a new API, CiscoAddress.createPersistentCall(), which allows applications to create persistent calls. At least one remote destination must be configured and the active remote destination must be set. There can be only one persistent call per remote device. Persistent calls cannot be created if there is already a call on the remote device; otherwise, the application receives CiscoJtapiException.OPERATION_NOT_AVAILABLE_IN_CURRENT_STATE. Furthermore, no feature invocations are allowed on or involving persistent calls (park, hold, conference, and transfer). Two new JTAPI APIs return information about the persistent call. The CiscoAddress.getPersistentConnection() API returns the connection object that is associated to the persistent call. It returns null if no persistent call exists. This API also allows you to check if an address has a persistent connection created on it and from there you can get the call object. The other newly added API is CiscoCallisPersistentCall(), which returns true if the call is a persistent call and false if the call is a normal call. Existing JTAPI APIs such as Provider.getCalls(), Address.getConnections(), and Terminal.getTerminalConnections() return only the information for normal calls and do not return anything for the persistent call. Provider.getCalls() returns all the calls that are associated with the provider, excluding the persistent calls. Address.getConnections() returns all the connection objects that are associated with this address, excluding the connection for the persistent call. Terminal.getTerminalConnections() returns all the terminal connection objects that are associated with this device, excluding the terminal connection for the Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 135 Features Supported by Cisco Unified JTAPI Password Expiry

persistent call. This functionality helps with backward compatibility so applications do not need to make any changes to their current implementations. No new APIs are added to disconnect the persistent calls. Existing Call.drop() and Connection.disconnect() JTAPI APIs can be used to disconnect or drop the persistent calls. Persistent calls cannot be dropped if there is an active call to the remote device. Persistent calls can also be dropped in any of the following scenarios: • The call is dropped by the remote destination (the remote destination hangs up). • The remote destination is no longer active. If there is an active call, as soon as that call is over, the persistent call will drop. After they are created, persistent calls remain connected until the maximum call duration timer expires in which case the call will be cleared. Some of the new JTAPI Error Codes introduced as part of this feature include the following: • CiscoJtapiException.CTIERR_CREATE_PERSISTENT_CALL_FAILED: Indicates that there is an issue with creating a persistent call. • CiscoJtapiException.CTIERR_PERSISTENT_CALL_EXISTS: Indicates that a persistent call already exists. • CiscoJtapiException.CTIERR_OPERATION_NOT_ALLOWED_ON_PERSISTENT_CALL: Indicates that the specified operation is not allowed on a persistent call. • CiscoJtapiException.CTIERR_DISCONNECT_PERSISTENT_CALL_FAILED_CALL_ACTIVE: Indicates that the request to disconnect the persistent call failed because there is an active customer call. Only when there are no active calls can the persistent call be disconnected. • CiscoJtapiException.CTIERR_PERSISTENT_CALL_BEING_SETUP: Indicates that the request failed because a persistent call is already being set up. Backward Compatibility This feature is backward compatible and existing applications are not affected by this feature. Interface CiscoAddress Changes CiscoAddress is enhanced with the addition of new APIs to create a persistent call and to retrieve the connection object that is associated to the persistent call. createPersistentCall (Terminal terminal, String callerIDNumber, String callerIDName) This interface creates a persistent call for this address and will return the call object for the newly created call. Note that CiscoProvider and the address must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. This API cannot be invoked on external addresses. Doing so will result in MethodNotSupportedException to be thrown. If while trying to allocate a globalCallId for the persistent call and an error occurs, ResourceUnavailableException will be thrown. All other errors encountered will result in PlatformException to be thrown. CiscoCall getPersistentConnection (Terminal terminal) This interface will return the connection object that is associated with the persistent call. It returns null if there is no persistent call. This API cannot be invoked on external addresses. Doing so will result in MethodNotSupportedException to be thrown. Connection Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 136 Features Supported by Cisco Unified JTAPI Persistent Connection

Interface CiscoCall Changes CiscoCall represents a call in the JTAPI model. This interface is enhanced with the addition of a new API. isPersistentCall () This interface returns true if the call is a persistent call and false otherwise (if it is a normal call). boolean Interface CiscoJtapiException Changes CiscoJtapiException contains all of the error codes that can be delivered by JTAPI to applications. This interface is enhanced with the addition of new error codes. public static final int • CTIERR_CREATE_PERSISTENT_CALL_FAILED = "Failed to create Persistent Call." (0x8CCC0132) • CTIERR_PERSISTENT_CALL_EXISTS = "Persistent Call exists." (0x8CCC0133) • CTIERR_OPERATION_NOT_ALLOWED_ON_PERSISTENT_CALL = "Operation is not allowed on a Persistent Call." (0x8CCC0134) • CTIERR_DISCONNECT_PERSISTENT_CALL_FAILED_CALL_ACTIVE = "Disconnect persistent call failing, there are active calls." (0x8CCC0136) • CTIERR_PERSISTENT_CALL_BEING_SETUP = "Persistent Call is being set up." (0x8CCC0139) Play Zip Tone The Play Zip Tone feature allows Cisco JTAPI application to play zip tones on active calls. The application specifies the type and the direction of the tone. Zip tones are played at local or remote end of the call. They are audible and played only for IP phones. These tones are not played if the remote side is a trunk, conference or Cisco Media Terminal or Route Terminal. The following tones can be played: • CiscoTone.ZIPZIP • CiscoTone.ZIP • CiscoTone.CALLWAITINGTONE Sample Code Void playTone(TerminalConnection termConn, int tone, int direction){ If ( termConn ! = null ){ try { ((CiscoTerminalConnection)termConn).playTone(tone, direction); } catch (Exception e){ System.out.println("Exception for playtone request " + e); } Interface Changes See CiscoTerminalConnection, on page 636, CiscoTone, on page 658 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 137 Features Supported by Cisco Unified JTAPI Play Zip Tone

Message Sequences See Play Zip Tone, on page 1390 Backward Compatibility This feature is backward compatible. Presentation Indicator for Calls The presentation indicator (PI) on a call provides the application with the ability to hide or reveal Calling/Called/CurrentCalling/CurrentCalled/LastRedirecting parties name and number to the end user. JTAPI provides functions on CiscoCall to get PI value for the party. Use this PI info to present the parties information to the end user. These functions return a value of true or false. A value of “True” indicates that presentation in “Allowed, ” and a value of “False” indicates the presentation is “Restricted.” For a conference call, the interfaces on CiscoCall do not return a correct value. Applications must iterate through all the connections in the call to get the PI value that is associated with the address for which the connection gets created. The interface that is provided on CiscoConnection is getAddressPI(). The following new interfaces exist on CiscoCall retrieve PI values. CiscoCall getCalledAddressPI() Returns the PI that is associated with getCalledAddressPI. If it returns true, the application displays the address name. If it returns false, the application must not display the address name. boolean getCallingAddressPI() Returns the PI that is associated with getCallingAddressPI. If it returns true, the application displays the address name. If it returns false, the application must not display the address name. boolean getCurrentCalledAddressPI() Returns the PI that is associated with CurrentCalledAddressPI. If it returns true, the application displays the address name. If it returns false, the application must not display the address name. boolean getCurrentCalledDisplayNamePI() Returns the PI that is associated with CurrentCalledDisplayNamePI. If it returns true, the application displays the address name. If it returns false, the application must not display the address name. boolean getCurrentCallingAddressPI() Returns the PI that is associated with getCurrentCallingAddressPI. If it returns true, the application displays the address name. If it returns false, the application must not display the address name. boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 138 Features Supported by Cisco Unified JTAPI Presentation Indicator for Calls

getCurrentCallingDisplayNamePI() Returns the PI that is associated with getCurrentCallingDisplayNamePI. If it returns true, the application displays the address name. If it returns false, the application must not display the address name. boolean getLastRedirectingAddressPI() Returns the PI that is associated with getLastRedirectingAddressPI. If it returns true, the application displays the address name. If it returns false, the application must not display the address name. boolean The following interface on CiscoConnection retrieves the PI value for the address that is associated with the connection: CiscoConnection getAddressPI() Returns the PI that is associated with the address on which the connection gets created. If it returns true, the application displays the address name. If it returns false, the application must not display the address name. boolean No change exist in the message flow. Privacy On Hold This feature enhances the privacy of private held calls. When privacy is enabled, only the phone that placed a call on hold can retrieve that call, and the calling name and number are not displayed. The feature provides the ability for a shared address to determine whether other shared addresses may barge into a call. When privacy is enabled, other shared address cannot barge into the call. Privacy is a terminals property. On IP phones, a Privacy feature button allows the users to enable and disable the privacy feature. Privacy can be dynamically enabled and disabled for the active calls on the terminal. When Privacy is on for a call, the TerminalConnection state available to other shared addresses is set to In Use. If Privacy status is changed during the CallProgress, CiscoTermConnPrivacyChangedEvent is delivered to the application. In prior releases, if Privacy is enabled and the call is put on hold, all TerminalConnections were in TermConnHeld state and any other shared Address terminalConnection could unhold the call. In Cisco Unified Communications Manager 4.2, if the Enforce Privacy on Held Calls service parameter is enabled, and if Privacy is enabled for a call, putting the call on hold does not change the terminalConnections of other shared addresses and they remain in the In Use state. Performance and Scalability There is no performance impact with this feature because there is no additional traffic generated between Cisco Unified JTAPI, applications, and Cisco Unified Communications Manager. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 139 Features Supported by Cisco Unified JTAPI Privacy On Hold

Progress State Converted to Disconnect State If an outbound call is initiated through the API to an unallocated directory number across the European PSTN, the application will perceive the ConnFailedEv event with the cause as CiscoCallEv.CAUSE_UNALLOCATEDNUMBER. For the US PSTN, the application may not see any event. To make the behavior consistent across the European and American PSTNs and also to address backward compatibility issues, a new service parameter UseProgressAsDisconnectedDuringErrorEnabled was added to the jtapi.ini file starting with JTAPI Version 1.4(3.21), which, when enabled (1 = enable; 0 = disable; the default is disable), causes applications to perceive ConnFailedEv in both cases. Q.Signaling (QSIG) Path Replacement QSIG Path Replacement, a network feature, optimizes the real-time protocol (RTP) path when calls are transferred or forwarded to other PBXs that are connected through QSIG trunks. When path replacement is in progress, a small window of time exists when the feature requests from applications would be ignored and JTAPI would throw an exception to the application. The Global Call ID or the call is changed when the RTP path is optimized with a direct path between the starting terminating PBXs. JTAPI provides new interfaces to monitor the call. QoS Support QoS support is enhanced in this release to enable QoS (DSCP marking) in both directions of the application <--> CTIManager connectivity. In previous releases it was enabled in only one direction: CTIManager --> application. The DSCP (QoS) values for both directions of the link are set by the “DSCP IP CTIManager to Application” value in the CTIManager service parameters. The default value is CS3(precedence 3) DSCP (011000). The “DSCP value for Audio calls” service parameter is the recommended QoS value for audio calls. Thisvalue is exposed to JTAPI applications. You must perform one of the following setup procedures on the client machine for JTAPI QoS to work on Windows platforms. Procedure Step 1 If you are running Windows 2000, follow the steps in QoS Setup on Windows 2000, on page 141. Step 2 If you are running Windows XP or Windows Server 2003, follow the steps in QoS Setup on Windows XP Server 2003, on page 141. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 140 Features Supported by Cisco Unified JTAPI Progress State Converted to Disconnect State

What to do next For more information on using the Registry Editor to set the Internet Protocol Type of Service bits, see the topic “Setsockopt is unable to mark the Internet Protocol type of service bits in Internet Protocol packet header” on the Microsoft technical support website. These JTAPI interfaces support QoS: Provider Interface getAppDSCPValue() Returns the “DSCP IP for CTI applications” service parameter. This value specifies the DSCP value that JTAPI sets on its link to CTI. Applications can get this value by querying the provider object by using this API every time that they get a ProviderInServiceEvent. int precedenceValue = 0x00 Stores the DSCP value that CTI provides. private int For details on these interfaces, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for QoS, see Message Sequence Charts, on page 761. QoS Setup on Windows 2000 If you are running Windows 2000, follow these steps. Procedure Step 1 Start the Registry Editor (Regedt32.exe). Step 2 Go to key: HKEY_LOCAL_MACHINE on Local Machine\System\CurrentControlSet\Services\Tcpip\Parameters
Step 3 On the Edit menu, click Add Value. Step 4 In the Value name box, enter DisableUserTOSSetting. Step 5 In the Data Type list, click REG_DWORD and then click OK. Step 6 In the Data box, enter a value of 0 (zero) and then click OK. Step 7 Quit Registry Editor and then restart the computer. QoS Setup on Windows XP Server 2003 If you are running Windows XP or Windows Server 2003, follow these steps. Procedure Step 1 Start Registry Editor (Regedt32.exe). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 141 Features Supported by Cisco Unified JTAPI QoS Setup on Windows 2000

Step 2 Go to key: HKEY_LOCAL_MACHINE on Local Machine\System\CurrentControlSet\Services\Tcpip\Parameters
Step 3 On the Edit menu, point to New, and then click DWORD Value. Step 4 Enter DisableUserTOSSetting as the entry name, and then press ENTER. When you add this entry, the value gets set to 0 (zero). Do not change the value. Step 5 Quit Registry Editor and then restart the computer. Quiet Clear QuietClear occurs at the other end when two parties are on a call, and one address goes out of service because of a network outage, the Cisco Unified Communications Manager goes down, the application controlling CTIPort goes down, or CTIManager goes down. At this stage, the other end of the call can only drop the call or disconnect the connection. It cannot perform any other callControl operations. For the party that went out of service, applications will perceive ConnDisconnectedEv and/or TermConnDroppedEv, and the other end of the call receives ConnFailedEv with CiscoCause of CiscoCallEv.CAUSE_TEMPORARYFAILURE. If applications try to invoke the following features during QuietClear mode, PlatformException with error code of CiscoJtapiException.CTIERR_OPERATION_FAILER_QUIETCLEAR gets thrown: • Consult transfer • Consult conference • Blind transfer • Hold • Unhold Applications may only drop the call in this mode. Note Receiving and Responding to Media Flow Events Whenever a media stream must be created between two endpoints, Cisco Unified Communications Manager issues start transmission and start reception events to both endpoints. In JTAPI, the CiscoRTPOutputStartedEv and CiscoRTPInputStartedEv events represent the start transmission and start reception events. The CiscoRTPOutputStartedEv.getRTPOutputProperties() method returns a CiscoRTPOutputProperties object, from which the application can determine the destination address of its peer endpoint in the call, as well as the other RTP properties for the stream such as payload type and packet size. Similarly, the CiscoRTPInputStartedEv.getRTPInputProperties() method returns a CiscoRTPInputProperties object that informs the application of the RTP characteristics for the inbound stream. At any time while media is flowing, the current CiscoRTPOutputProperties and CiscoRTPInputProperties also remain available from the CiscoMediaTerminal.getRTPOutputProperties() and Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 142 Features Supported by Cisco Unified JTAPI Quiet Clear

CiscoMediaTerminal.getRTPInputProperties() methods as well. These methods throw an exception if the CiscoMediaTerminal is not currently supposed to transmit or receive media. When Cisco Unified Communications Manager wants the application to stop sending or receiving media as the result of a call disconnecting or being put on hold, for example, it sends the CiscoRTPOutputStoppedEv and CiscoRTPInputStoppedEv events. These events mean that the current RTP media stream that exists between the two endpoints should be torn down. Inbound Call Media Flow Event Diagram The following table illustrates the dialogue between Cisco Unified Communications Manager and a JTAPI application when a call is presented to an application-controlled endpoint. The events in the left column represent JTAPI events that are sent to the CallObserver of the application, and the requests in the right column represent methods that the application invokes. Table 4: Inbound Media Flow Event Application Request Direction JTAPI Event Æ CallActiveEv ConnCreatedEv ConnProceedingEv CallCtlConnOfferingEv CallControlConnection.accept () ¨ Æ CallCtlConnAlertingEv TermConnCreatedEv TermConnRingingEv TerminalConnection.answer () ¨ Æ ConnConnectedEv CallCtlConnEstablishedEv TermConnTalkingEv CiscoRTPOutputStartedEv CiscoRTPInputStartedEv CallControlConnection.disconnect () ¨ Æ CiscoRTPOutputStoppedEv CiscoRTPInputStoppedEv TermConnDroppedEv CallCtlConnDisconnectedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 143 Features Supported by Cisco Unified JTAPI Inbound Call Media Flow Event Diagram

The table above shows JTAPI events for the local connection: that is, for the application endpoint. TheactualJTAPI meta event stream contains events that describe the state of the calling party. Note Cisco Unified Communications Solutions RTP Implementation The Cisco Unified Communications Solutions architecture puts a premium on performance, and thus Cisco Unified Communications Solutions phones and gateways do not implement some of the features of RTP and its often-associated real-time control protocol (RTCP). To ensure its compatibility, applications must consider the following points: • Because RTCP is not supported. Cisco Unified Communications Solutions endpoints will not send RTCP messages, and they will ignore any such messages that are sent to them. • Cisco Unified Communications Solutions endpoints do not currently make use of the synchronization source (SSRC) field in the RTP header. Applications must not multiplex RTP streams by using the SSRC field, or phones and gateways may not correctly decode and present the media. Recording Introduction New regulations require organizations to archive contact interactions to meet compliance directives and Contact Centers need to guarantee the quality of service their Agents provide. Cisco’s Recording feature enables organizations to archive the conversation of two or more parties for review, analysis, and/or legal compliance. The recording feature lets applications record conversations on any observed address. Three recording configurations are available: • No recording • Automatic recording: The system initiates a recording session and streams media to the configured recording device whenever a call goes to a connected state. • Application-controlled recording: If application-controlled recording is configured on an address, the application can start and stop recording. The call must exist in the connected state before the application can start recording. The ability to record calls was introduced in Unified Communications Manager Release 6.0 with phone-based built-in bridge (BIB) recording. Cisco IP Phones were instructed to send copies of conversations to supervisors and recorders. In Release 8.0, Encrypted media (sRTP) support was added and was expanded to have the information sent to recorders (meta-data) in Release 8.6(2). With Release 9.0 selective user controlled recording was added to the feature In Unified Communications Manager Release 10.0(1), the recording feature is enhanced so that Dynamic combinations of Cisco Gateways and IP Phone are instructed to send copies of conversations to recorders based on call flows, participants, and media requirements. Also, recording Serviceability counters and alarms Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 144 Features Supported by Cisco Unified JTAPI Cisco Unified Communications Solutions RTP Implementation

have been added to help compliance officers ensure calls are recorded by monitoring the real-time status and historical performance of the feature. For internal calls within a cluster between end users, the media-forking device is the end user device involved in the call that triggers the recording session. For an external call from a recording gateway, both the end user device and the gateway involved in the call can be used as the media-forking device. Unified Communications Manager enables the administrator to select one over the other as the preferred recording media source: "Phone preferred" or "Gateway preferred", using the device's line configuration. If the phone preferred recording media source is selected, the phone that triggers the recording is used to fork the media for the recording session, provided that the phone is capable of media forking and phone's BIB is enabled. If the phone is not capable of media forking or the phone's BIB is not enabled, and the gateway involved in the call has the media forking capability and is enabled for recording, then the gateway is used to fork the media for the recording session. If the gateway preferred recording media source is selected, the gateway that is already in the media path will be used to fork the media for the recording session, provided that the gateway is capable of media forking and is enabled for recording. If gateway is not capable of media forking or is not enabled for recording, and the phone triggering the recording is capable of media forking and the phone's BIB is enabled, then the phone is used to fork the media for the recording session. If none of the recording resources is available, this recording request fails. Similar to the phone-based recording, gateway-based recording is also triggered from the end-user's device or CTI/JTAPI application. Virtual devices without BIB such as CTI Port, Route Point, and CTI Remote Device can only be set to Gateway-Preferred. Note When a gateway is registered with the same cluster as the device that initiates a recording, it is called a "Single Cluster" gateway recording. When a gateway is registered with a cluster that is different than where the recording request is initiated, it is called an "Inter-Cluster" gateway recording. The cluster where the recording initiates is a recording triggering cluster (Trigger) and the cluster where the recording gateway registers to is a recording anchoring cluster (Anchor). The inter-cluster recording is only supported by SIP trunks. Note When there is any mid-call feature involved with the call being recorded, the recording resource may change due to the feature interactions. In previous Unified Communications Manager releases, the recording sessions started by a near-end party continues when the far-end party can hold or transfer the call while the near-end party remains connected. The only time the recording session restarts is when the near-end party holds and resumes the call. However, for Gateway-based Recording, Unified Communications Manager no longer maintains this behavior. Instead of continuing the recording session when the connected party of the near-end changes, the recording session is re-started by the near-end party. In JTAPI, this "Recording-Re-trigger" behavior results in extra CiscoTermConnRecordingEndEv and CiscoTermConnRecordingStartEv events sent to applications. With the new behavior, each recording session is a complete section of the conversion between two unique parties. A near-end connected party change can be caused by mid-call features such as call transfer, call redirect, conference, shared line hold/resume, etc. Therefore, from JTAPI application perspective, there can be multiple RecordingStart/Stop events within a single call. This applies to both Gateway-based recording and Phone/BIB-based recording. In Cisco Unified Communications Manager Release 10.0(1), CTI is introducing support for Gateway Recording (in addition to existing phone-based BIB Device Recording). CTI applications, using Cisco JTAPI, is able to differentiate a recording call's recording type and media forking device/cluster info from existing JTAPI Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 145 Features Supported by Cisco Unified JTAPI Recording

interface and event; and a new JTAPI event is also introduced to identify recording failure as described below. With this new Gateway Recording feature, either the gateway or the built-in bridge (BIB) can be used as the recording resource based on the end user's preference and the availability. The following interfaces extend TermConnEv and are delivered to callobserver. For shared lines, the system delivers these events to call observers on the address or terminal of the talking terminal connections. Applications receive no events if they have only the terminal whose connection is in the INUSE or BRIDGED state. CiscoTermConnRecordingStartEv CiscoTermConnRecordingStartEv Indicates the start of recording and is delivered to the call observer of the recording initiator. Auto recording configuration or an application request can trigger recording. CiscoTermConnRecordingEndEv CiscoTermConnRecordingEndEv Indicates the end of recording and is delivered to the recording initiator. CiscoTermConnRecordingFailedEv CiscoTermConnFailedEv This interface is added for Cisco Unified Communications Manager Release 10.0(1) and indicates when a call recording failed. Exposing Recording Media Forking Info on CiscoRecorderInfo Cisco JTAPI provides new APIs for Release 10.0(1): getMediaForkingDeviceType(), getMediaForkingDeviceName(), getProtocolReferenceGUID(), and getMediaForkingClusterID() to expose various call recording media forking information of a recording call to JTAPI application. These capabilities are exposed on the existing interface of CiscoRecorderInfo, where applications can extract from CiscoTerminalConnection and CiscoTermConnRecordingTargetInfoEv. Exposing Recording Media Forking Device Type on CiscoCall With Release 10.0(1), Cisco JTAPI introduces three new forking device types: • CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_NONE • CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE • CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW Exposing Cluster ID on CiscoProvider Cisco JTAPI provides API of CiscoProvider.getClusterID(), which returns the clusterID enterprise parameter configured for the cluster. (Note that the cluster ID is an Enterprise parameter configurable from CUCM admin page, and when this parameter is changed by administrator, the CTIManager service and CallManager service would need to be restarted for it to take effect). Secured Recording With this enhancement a recording device can record a secure call if its device security capability is same as or more than that of the agent. A recording request fails if the recording is attempted for an authenticated device, or if the security capability of the recorder is non-secured and that of the agent is encrypted. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 146 Features Supported by Cisco Unified JTAPI Recording

Backward Compatibility This feature is not backward compatible and existing applications can be affected with the introduction of this new feature. That is, when mid-call feature(s) is involved, there can be recording retrigger(s) with multiple recording sessions within a single call, applications need to coordinate these recording sessions accordingly. This new change of behavior applies to both Gateway-based recording as well as Phone/BIB-based recording. For detailed information about these interface changes, see the following topics: • CiscoJtapiException, on page 416 • Related Documentation, on page 289 • CiscoCall, on page 332 • CiscoProvider, on page 492 • CiscoProviderCapabilities, on page 504 • CiscoProviderCapabilityChangedEv, on page 506 • CiscoProviderObserver, on page 508 • CiscoRecorderInfo, on page 511 • CiscoTerminalConnection, on page 636 • CiscoTermConnRecordingTargetInfoEv, on page 594 Redirect JTAPI 1.2 specifies that one of the preconditions of the CallControlConnection.redirect() method specifies for the state of the connection to be in either the CallControlConnection.OFFERING or the CallControlConnection.ALERTING state. Cisco Unified JTAPI also allows a connection in the CallControlConnection.ESTABLISHED state to get redirected. The redirect() method includes the following overloaded form in the CiscoConnection interface. It allows applications to specify the behavior that is desired when a failure occurs while a call is redirected and specifying the calling search space, or resetting the original called field. Applications choose the desired behavior, by passing one of the following INT parameters in the overloaded redirect method from the CiscoConnection interface: • Redirect drop on failure—When a call is directed to a busy or an invalid destination, Cisco Unified Communications Manager can either drop the call if the redirect fails or leave the call at the redirect controller. The JTAPI application can then take corrective action, such as redirecting the call to another destination. The option for the redirect mode parameter follows: • CiscoConnection.REDIRECT_DROP_ON_FAILURE • CiscoConnection.REDIRECT_NORMAL • Calling Address search space—Redirect uses the calling search space parameter to indicate which callingSearchSpace is used. Applications can either use the calling party search space or the redirect controller search space. The parameter options for this scenario follow: • CiscoConnection.CALLINGADDRESS_SEARCH_SPACE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 147 Features Supported by Cisco Unified JTAPI Redirect

• CiscoConnection.ADDRESS_SEARCH_SPACE • Resetting original called—The called address option parameter gets used to reset the original called fields. The options for this scenario follow: • CiscoConnection.CALLED_ADDRESS_UNCHANGED • CiscoConnection.CALLED_ADDRESS_SET_TO_REDIRECT_DESTINATION. This option affects the fields when the call arrives at the redirect destination. For more information, refer to the com.cisco.jtapi.extensions.CiscoConnection documentation. For the scenario where A Calls B, B redirects to C, and C (redirect destination) does not represent a provider observed address, JTAPI would provide CallCtlConnAlertingEv for C with cause code Ev.CAUSE_NORMAL. Prior to release 5.0, the cause code specified Ev.CAUSE_REDIRECT for the same scenario. This change kept the behavior consistent for scenarios where C observed or did not observe the provider. When C is observed, for the same scenario, CallCtlConnAlertingEv at C is provided with CAUSE_NORMAL from releases prior to 5.0, and that behavior continues without change. Note Redirect Set Original Called ID Cisco Unified JTAPI applications can specify the preferred original called party DN in the redirect request. The Redirect Set Original Called ID feature lets applications redirect a call on a connection to another destination while letting the applications set the OriginalCalledID to any value. This enables applications to transfer the call directly to the voice mail of another. For example, if A calls B and B wants to transfer the call to CVoice Mail, applications can specify in the enhanced redirect request C as the preferred original called party and destination party as CVoice Mail profile. With this request, calls appear in C Voice Mail profile with the Cisco Unified Communications Manager originalCalledParty field as C. Typical voice mail applications look for originalCalledParty information to identify a user voice mailbox. Any application that redirects a call to a party by modifying the original called party can take advantage of this feature. This feature also changes the lastRedirectedAddress to the preferredOriginalCalledParty that gets specified in the redirect request. Note The following callControlConnection interface applies for Redirect Set Original Called ID: Interface CiscoConnection Extends callControlConnection With Additional Cisco Unified Communications Manager-Specific Capabilities redirect (java.lang.String destinationAddress, intmode, int callingSearchSpace, java.lang.String preferredOriginalCalledParty) This method overloads the CallControlConnection.redirect() method. javax.telephony.Connection Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 148 Features Supported by Cisco Unified JTAPI Redirect Set Original Called ID

For details on the interface, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for Redirect Set Original Called ID, see Message Sequence Charts, on page 761 Redirect to Device With Release 11.5(1), the Redirect feature of Cisco Unified JTAPI is enhanced to allow you to redirect calls to a specific device via the deviceName parameter. Even in shared line situations, the redirected call goes to the target device only and not to other devices that share the phone line. To support this feature, the following methods have been enhanced with a new deviceName field: • CiscoConnection.redirect now includes a deviceName field, which allows you to target the redirect to a specific device. If another device shares the same phone line, that device goes into remote-in-use state. Cisco JTAPI delivers a TermConnPassiveEv and CallCtlTermConnInUseEv to the shared line devices. • CiscoRouteSession.selectRoute also includes a deviceName field allowing the selectRoute() method to take an array of destination device names. The order of device names corresponds to the order of route selected. Once the route is selected, Cisco JTAPI attempts to redirect the call to the destination device. Table 5: Method Structure Method Interface redirect(String destinationAddress, int mode, int callingSearchSpace, int calledAddressOption, String preferredOriginalcalledParty, String facCode, String cmcCode, int featurePriority, byte[] applicationXMLData, String deviceName) CiscoConnection selectRoute(String[] routeSelected, int[] callingSearchSpace, String[] modifyingCallingNumber,String[] preferedOriginalCalledNumber, int[] preferedOriginalCalledOption, String[] facCode, String[] cmcCode,int[] featurePriority, byte[][] applicationXMLData, String[] deviceName) CiscoRouteSession Restrictions The following restrictions apply: • If an invalid deviceName is passed to the redirect method, the REDIRECT_CALL_INVALID_DEVICE_NAME error gets thrown. • The deviceName can be used to redirect calls within the cluster only. If the application attempts to redirect a call across clusters with the deviceName completed, the REDIRECT_CALL_INVALID_DEVICE_NAME gets thrown. To redirect calls across clusters, the deviceName must be null, or the application must use other redirect methods. • The deviceName must be associated to the directory number that the application passes to the redirect method and not any other directory number. Otherwise, the REDIRECT_CALL_INVALID_DEVICE_NAME error gets thrown Backward Compatibility There is no impact on backward compatibility as the above methods are overloaded. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 149 Features Supported by Cisco Unified JTAPI Redirect to Device

Message Sequence Charts Redirect to a Device, on page 1449 Redundancy Configuration requires that devices are configured into device pools and are assigned static Cisco Unified Communications Manager groups. Devices register with a particular Cisco Unified Communications Manager server that handles call control signaling. When a server fails, the devices failover to the backup server in the group. When the primary server comes back online, it waits until no active calls exist on the device, then re-homes to the primary Cisco Unified Communications Manager server. Cisco Unified JTAPI informs the applications of this transition by sending a temporary out-of-service message while registering to the backup server. Redundancy in CTI Managers Cisco Unified JTAPI also offers transparent applications for redundancy via the CTI Manager. When the primary CTIManager fails, Cisco Unified JTAPI automatically connects to the backup CTI Manager and communicates the reconnection to applications. Instead of connecting to a single Cisco Unified Communications Manager server, applications now connect to a set of CTIManagers. The applications supply the CTIManager server names when they invoke JTAPI. Cisco Unified JTAPI and the CTIManager maintain bidirectional heartbeat signals to detect a loss of connectivity between them. The CTIManager detects when an application no longer runs and cleans up its allocated resources. The following figure illustrates the“Logical Representation of JTAPI, CTIManager and Cisco Unified Communications Manager in a cluster” After Cisco Unified JTAPI successfully connects to the primary CTIManager, it alternately will attempt to reconnect to the primary or backup CTIManager if the JTAPI connection to the CTIManager fails. Note Figure 12: Logical Representation of JTAPI, CTIManager and Cisco Unified Communications Manager in a Cluster Invoking CTIManager Redundancy When getProvider() method on the CiscoJtapiPeer is called during the application startup, Cisco Unified JTAPI attempts a connection to the first CTIManager in the list and tries a connection to the next CTIManager Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 150 Features Supported by Cisco Unified JTAPI Redundancy

if connection attempt fails with the first. If all the CTIManagers in the list are not available or if connection is refused by all CTIManagers, an exception gets sent to the application, and no further reconnection attempts occur. After the first successful connection, Cisco Unified JTAPI alternatively attempts to connect to the backup or primary CTIManager when a failure to CTIManager or connection to CTIManager is detected. The list of redundant CTIManagers designates a comma-separated list that is passed into the CiscoJtapiPeer.getProvider(String providerString) method as a String. The usage for the providerString follows: • providerString = CTIManager;login = XXX;passwd = YYY;appinfo = ZZZ (Non-redundant feature) • providerString = CTIManager1, CTIManager2;login = XXX, passwd = YYY;appinfo = ZZZ (Redundant feature) Because the appinfo parameter is optional, the application provides no specific appinfo parameter. Cisco Unified JTAPI generates one from a JTAPI instance ID and the local host name. Note Additionally, the jtapi.ini file may define different CTIManager lists to support the CiscoJtapiPeer.getServices() method. Cisco Unified JTAPI accepts the following definition: CtiManagers = <CTIManager1>, <CTIManager2>;<CTIManager3> where <CTIManager1>, <CTIManager2> specifies a redundant group. <CTIManager3> specifies a nonredundant group. From Unified CM Release 14SU3 onwards, support has been added to allow an application to specify a CTIManager as having least priority. Prior to this, all CTIManagers in a redundancy group have equal weightage. JTAPI would attempt to failover to the next availabe CTIManager in the group, if connection is lost or not established to the current server. This feature support is added to aid Dedicated Instance (DI) deployments that are cloud managed. It has been extended as a general usage API for all applications. An application needs to invoke setLeastPriorityCtiServer exposed on the <CiscoProvider>. Once a CTIManager is marked as least priority, JTAPI includes the configured CTIManager internally into the redundancy group. JTAPI attempts a connection to this CTIManager only if no other CTIManager is available. Once connected to the least priority CTIManager, JTAPI would deliver a CiscoProvConnToLeastPriorCtiServerEv on provider to indicate it is now connected to least priority CTIMaanger. JTAPI internally monitors availability or reachability to the other servers in the group. Once one of the servers are available, JTAPI would deliver a CiscoProvPrimNwReachableEv on the Provider observer to indicate one of the other servers are reachable now. JTAPI would later attempt a failover based on the configured fallback initiation time as specified by application via the API. If no time is specified, it would default to 10 min, post which JTAPI would forcefully failover application to the CTIManager which is available now. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 151 Features Supported by Cisco Unified JTAPI Invoking CTIManager Redundancy

On successful fallback, JTAPI would deliver a CiscoProvFallbackToPrimNwCompltdEv on Provider to indicate it is no longer connected to the least priority CTIManager server. CTIManager Failure When Cisco Unified JTAPI detects a loss of connection to a CTIManager, the application receives notification of this loss in service. The following events get sent to the application on the appropriate Observers: • A CallObservationEndedEv event gets sent to all call observers on an address, and calls in progress end. The calls get physically connected, but the application observation of the call ends because Cisco Unified JTAPI cannot send call state changes. • A CiscoAddrOutOfServiceEv event gets sent to all addresses on a terminal and a CiscoTermOutOfServiceEv event gets sent to the terminal. • This process repeats for all terminals in the provider user-controlled list. (A CiscoAddrOutOfServiceEv event gets sent only to the addresses that have an active AddressObserver, and a CiscoTermOutOfServiceEv event gets sent only to terminals with an active TerminalObserver.) • The provider gets set in the out-of-service state, and the ProvOutOfServiceEv event gets delivered on any ProviderObserver callbacks present on the provider. Cisco Unified JTAPI attempts a connection to the next CTIManager in the list, and the ProvInServiceEv gets sent to the ProviderObserver. The devices that previously registered under the application control get reinstated in the new CTIManager After the device is reinstated, CiscoAddrInServiceEv and CiscoTermInServiceEv events get sent to the application via the respective observers. All previously added observers are maintained. If any calls exist on the devices, a snapshot of the call gets sent to the respective call observers. CTI ports that were previously registered are reregistered with the same media parameters. RouteAddress callbacks are maintained as before, and these calls get recovered on the new CTIManager. No call snapshot, however, gets delivered to the RouteAddresses. If a least priority CTIManager was set, and an application fails over to it, JTAPI delivers a CiscoProvConnToLeastPriorCtiServerEv on Provider. Heartbeats Cisco Unified JTAPI and the CTIManager maintain heartbeat signals to discover a failure in either the CTIManager or JTAPI. The CTIManager server controls the heartbeat parameters in the bidirectional heartbeat. Applications can request a desired server heartbeat interval when they are initializing Cisco Unified JTAPI, but the CTIManager can override it. Applications specify the desired heartbeat parameter by using DesiredServerHeartbeatInterval in the jtapi.ini setting. Cisco Unified JTAPI specifies the desired heartbeat interval for the client during initialization. The CTIManager specifies the client side heartbeat interval to Cisco Unified JTAPI and specifies the interval at which the server (CTIManager) will send heartbeats. A failure to receive heartbeat message for twice the server-specified interval results in a client-initiated teardown of the connection. To minimize heartbeat traffic, any messages from the client to the server or events from the server to the client substitute for a heartbeat. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 152 Features Supported by Cisco Unified JTAPI CTIManager Failure

Ringback on SIP 183 for Transferred Calls In Release 11.0(1), Cisco JTAPI has been updated with how it responds to SIP 183 messages when a call is transferred over a gateway or trunk. When an established call gets transferred over a trunk and a SIP 183 is received, Cisco JTAPI moves the call to CallControlConnection.NETWORK_ALERTING state. When the call is answered, Cisco JTAPI moves the call state to CallControlConnection.ESTABLISHED. A new Cisco CallManager service parameter, CTI Report Ringback on SIP 183 with SDP, has been added to configure this feature. When this sevice parameter is set to True, the above behavior applies. This is the default setting. If an application needs to use the legacy behavior, you can set the service parameter to False. Under this setting, if the call call is transferred over a gateway or trunk, CTI will use the CallControlConnection.NETWORK_REACHED state to report that the other network has been reached, but CTI will not report back that a connection has been established. Routing Routing in JTAPI requires the configuration of a CTI Route Point on the Cisco Unified Communications Manager. Multiple calls can be queued to this Route Point, but only a single line can be configured on a CTI Route Point device. JTAPI implementation of adjunct Routing, as described in the call center package, includes the following actions: • Registering route callbacks on Route Addresses • Creating appropriate handlers in response to the various routing events (routeSelect, routeEnd) CTI Route Points represent devices that can process any number of incoming calls simultaneously on the same line. You can route calls by using the methods in the javax.telephony.callcenter package, or you can accept, redirect, or disconnect calls by using the methods in the javax.telephony.callcontrol package. You can configure each CTI Route Point with a maximum of 34 lines. To support more than 34 lines, provision additional route points. For details on how to configure and administer the CTI Route Point, refer to the Cisco Unified Communications Manager Administration Guide. Note The following figure shows the CTI Route Point configuration. Figure 13: CTI Route Points Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 153 Features Supported by Cisco Unified JTAPI Ringback on SIP 183 for Transferred Calls

Cisco Route Session Implementation When a call comes in to the RouteAddress, the implementation starts a Route Session thread and sends the application a RouteEvent. This thread in turn starts a timer thread to time the application response to a RouteEvent with either a routeSelect() or an endRoute(). If the application responds with a routeSelect (String[] selectedRoutes), JTAPI verifies that all preconditions are satisfied and then attempts to route the call to the first destination that is specified in the array. If the destination is a valid and available number, the call gets routed, and the application gets a RouteUsedEvent followed by a RouteEndEvent. Otherwise, if an error occurs in routing (which may be caused by an invalid/busy/unavailable destination), the application gets a ReRouteEvent. JTAPI starts the Timer Thread again before it sends the re-Route Event. Because Cisco Unified Communications Manager does not support re-Routing, if the routing was unsuccessful, either the caller will receive a busy tone, or the call will get dropped. The application can clean up all failure instances and/or send JTAPI an endRoute to clean up the RouteSession. If the application does not respond with an endRoute(), the JTAPI timer once again expires, and JTAPI cleans up the Route Session by sending the application a RouteEndEvent(). If the routing timer expires before the application returns with a selectRoute() or an endRoute() method, the Cisco Unified Communications Manager applies same treatment as when a call is made to an unregistered phone (that is, play fast busy). If ForwardNoAnswer is configured on the Route Point, the call immediately forwards to that number when the timer expires. If the application cannot respond with a valid address to which to route the call, the application may choose to call endRoute with an error. The JTAPI specification defines three errors in the RouteSession interface: ERROR_RESOURCE_BUSY, ERROR_RESOURCE_OUT_OF_SERVICE, and ERROR_UNKNOWN. If an endRoute is invoked on the RouteSession, the implementation currently accepts() the call at the RouteAddress, so the caller may begin to receive ringback. If forwarding is configured for the Route Point, the call gets forwarded when the Forwarding Timer expires. Select Route Timer Configure this timer via the JTAPI.ini configuration file that has a key called RouteSelectTimeout = 5000. Use milliseconds as the unit. The default value for this timer specifies 5 seconds; however, depending on the needs of the application, you can extend or decrease this timer to improve Route Session cleanup efficiency. Ensure that this timer is not unreasonably large. Each Route Session as a thread represents a call to the Route Point, and these Route Sessions should be cleaned up. Should an application expect significant delays between receiving the Route Event and responding with a routeSelect/endRoute event, the application would want to appropriately extend this timer. Forwarding Timer You can configure the timer for Forward on No Answer that is currently systemwide (that is, it applies to all devices on Cisco Unified Communications Manager) via the Cisco Unified Communications Manager Service Parameters configuration. The default value for this timer specifies 12 seconds. In future releases, a separate timer for CTI Route Points might get included, so forwarding for the route point takes effect immediately after JTAPI accepts the call (when the application calls an endRoute or if the routing timer expires). Route Session Extension CiscoRouteSession acts as a Cisco Extension to the JTAPI specification. Most importantly, this extension exposes the underlying Call object to the Applications. CiscoRouteSession.getCall() returns CiscoCall, and Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 154 Features Supported by Cisco Unified JTAPI Cisco Route Session Implementation

this call exposes other Call Model Objects such as the associated Addresses, Connections, and so on. The extension also defines additional errors for the application. Caller Options Summary In the absence of a callback, or if RouteSession.routeSelect() or endRoute() has not responded to a routeEvent, the caller receives nothing until • The application can disconnect() or reject() the connection on the Route Point, and, thereby, the caller receives a busy tone. • The application can accept the call, and the Forward No Answer, if configured, kicks in. • The application can drop the call. The caller holds the receiver but does not know what happened. With a callback, if the application chooses to call an endRoute(), after endRoute() returns, the caller receives a ringback until • The client calls a disconnect() that would drop the call. • The client redirects() the call. • The forward on no answer timer that is configured via the scm.ini will kick in and forward the call unless the preceding two options have already kicked in. • If no forwarding is configured for the Route Point, the caller continues to receives a ringback unless the first two options kick in. Fault Tolerance When Using Route Points One way for an application that uses route points to deal with fault tolerance requires connecting two JTAPI applications to two different Cisco Unified Communications Managers, each registering a different RouteAddress. For example, Application1 manages RouteAddress1 by using Communications Manager1. Application2 manages RouteAddress2 by using Communications Manager2. In Cisco Unified Communications Manager Administration, ensure the ForwardNoAnswer configuration for these CTI Route Points is administered, so they point to each other. In this example, RouteAddress1 would have FNA = RouteAddess2, and RouteAddress2 would have FNA = RouteAddress1. If Communications Manager1 goes down, calls forward to RouteAddress2, so Application2 takes over. Furthermore, both applications could be configured to reconnect to the proper Cisco Unified Communications Manager server when they receive a ProviderShutdown event. Secure Conferencing This feature informs applications whether a call is secure, allowing for secure conference calls. When the overall security status of the call changes, secure conferencing provides applications with a notification in the form of an event on the call. Applications receive the overall call security status of the call in the CiscoCallSecurityStatusChangedEv when the overall call security status changes. When a terminal goes to the talking state, JTAPI provides the call security status information to the applications. Applications can query the security status of the call by using a new interface on CiscoCall. The system makes the security status information available to applications when the applications start monitoring an existing call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 155 Features Supported by Cisco Unified JTAPI Caller Options Summary

In shared address scenarios, the system also reports CiscoCallSecurityStatusChangedEv to the RIU parties. The OverallCallSecurityStatus matches the status reported on the active terminals. For example, in a three-party conference with A (Encrypted), B (Encrypted), C (Authenticated), and C' (Authenticated), the system reports CiscoCallSecurityStatusChangedEv with OverallCallSecurityStatus = Authenticated to C and C'. The system delivers this event on a per-call basis. SRTP key information will continue to be sent for encrypted parties whether or not the OverallCallSecurityStatus is Encrypted. For example, in a three-party conference with A (Encrypted), B (Encrypted), and C (non-secure), the OverallCallSecurityStatus of the conference call is NotAuthenticated. However, the media that connects A, B, and the conference bridge continues to be encrypted because they are encrypted parties. Thus, A and B receive SRTP keys despite the OverallCallSecurityStatus. Backward Compatibility This feature is backward compatible. The new parameter, EnableSecurityStatusChangedEv, in the jtapi.ini file controls the new event CiscoCallSecurityStatusChangedEv that the secure conferencing feature generates. Applications can turn on this parameter by adding the line “EnableSecurityStatusChangedEv = 1” to the jtapi.ini file to receive this new event. By default, this parameter does not appear in the jtapi.ini file, so event notification is disabled. The setCallSecurityStatusChangedEv() interface on com.cisco.jtapi.extensions.CiscoJtapiProperties lets applications set this ini parameter programmatically. For additional information, see CiscoCallSecurityStatusChangedEv, on page 368. Secure Real-Time Protocol Key Material This feature provides the mechanism that is needed to deliver Secure Real-Time Protocol (SRTP) key material of an encrypted media session between authenticated end points within Cisco Unified Communications Manager based Enterprise systems. To receive this key material, the administrator must configure the TLS Enabled and SRTP Enabled flags in the Cisco Unified Communications Manager Administrator windows and a TLS link must be established between JTAPI and the CTIManager. Key materials get exposed in CiscoRTPInputKeyEv and CiscoRTPOutputKeyEv. To get these events, applications must enable rtpKeyEvenabled in CiscoTermEvFilter. By default, filters are disabled to maintain backward compatibility. If filters are enabled, application always get CiscoRTPInputKeyEv and CiscoRTPOutputKeyEv. A security indicator in these events indicates whether the media is encrypted and whether keys are available. CiscoRTPInputKeyEv contains key material of the input stream and CiscoRTPOutputKeyEv contains key material of the output stream. Applications can use this key material to decrypt the packets and start monitoring or recording the media. Applications must not store this key material in a way that leaves the material vulnerable to tampering, and applications must zero out or clear the entry for these keys when they go out of scope. This key material contains • Key Length • Master Key • Salt Length • Master Salt • AlgorithmID • isMKIPresent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 156 Features Supported by Cisco Unified JTAPI Secure Real-Time Protocol Key Material

• Key Derivation Rate This enhancement also supports a secure media termination for CTIPorts and RoutePoints. To do this, the application passes in supported encrypted algorithms in CTIPort and route point register requests. The application gets an error if no TLS link and no SRTP Enabled flags exist. Whether media are encrypted or not depends on whether the other end is interested in secure media and whether the algorithm is negotiated successfully. For mid-call monitoring, if the application comes up after a call is established between two end points, the application must query Terminal.createSnapshot() and snapshot event CiscoTermSnapshotEv. CiscoTermSnapshotCompletedEv gets sent, which indicates whether the current media between end points is secure or not. Applications can query CiscoMediaCallSecurityIndicator to get a security indicator for a call; however, this does not contain any key material in the event. If no calls exist on any of the lines on the terminal, applications only get CiscoTermSnapshotCompletedEv. To maintain backward compatibility, these events get generated only when an application enables the snapShotRTPEnabled filter in CiscoTermEvFilter. CiscoRTPHandle gets added in all RTP events so that applications can correlate RTP events related to a single call. For backward compatibility, no new events are generated when there is no secure media. For more information on SRTP, see the Secure RTP Library API Documentation by David McGrew on SourceForge.net. The following sections describe the interface changes for SRTP key material. Public Interface CiscoMediaEncryptionKeyInfo getAlgorithmID() This method returns the media encryption algorithm for the current stream. int getIsMKIPresent() An MKI indicator that indicates whether MKI is present. Key management defines, signals, and uses the MKI. int getKeyLength () This method returns the master key length. int getKey() This method returns the master key for the stream. byte[] getSaltLength () This method returns the salt length. int getSalt() This method returns the salt key for the stream. byte[] keyDerivationRate() Indicates the SRTP key derivation rate for this session. int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 157 Features Supported by Cisco Unified JTAPI Secure Real-Time Protocol Key Material

CiscoMediaSecurityIndicator MEDIA_ENCRYPTED_KEYS_AVAILABLE Indicates that media terminated is secured and keys are available. static int MEDIA_ENCRYPTED_KEYS_UNAVAILABLE Indicates that media is terminated in secured mode, but keys are not available because SRTP is not enabled in Cisco Unified Communications Manager Administration User windows. This could be because either no TLS exists or no IPSec is configured for this application. static int MEDIA_ENCRYPTED_USER_NOT_AUTHORIZED Indicates that media is terminated in secured mode, but keys are not available because user is not authorized to get the keys. static int MEDIA_NOT_ENCRYPTED Indicates that media is not encrypted for this call. static int CiscoRTPInputKeyEv getCiscoMediaEncryptionKeyInfo () Returns CiscoMediaEncryptionKeyInfo only if the provider is opened with TLS link and if SRTP enabled option is set for the application in Cisco Unified Communications Manager User Administration; otherwise, it returns null. CiscoMedia EncryptionKeyInfo getCiscoMediaSecurityIndicator() Returns media security indicator, which is one of the following constants from the CiscoMediaSecurityIndicator: MEDIA_ENCRYPTED_KEYS_AVAILABLE MEDIA_ENCRYPT_USER_NOT_AUTHORIZED MEDIA_ENCRYPTED_KEYS_UNAVAILABLE MEDIA_NOT_ENCRYPTED int getCallID () Returns CiscoCallID object if CiscoCall is present when this event is sent. If no CiscoCall is present, this method returns null. CiscoCallID getCiscoRTPHandle () Returns CiscoRTPHandle object. Applications can get a call reference by usingCiscoProvider.getCall( CiscoRTPHandle ). If no call observer exists, or if there was no call observer when this event is delivered, CiscoProvider.getCall( CiscoRTPHandle ) may return null. CiscoRTPHandle Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 158 Features Supported by Cisco Unified JTAPI Secure Real-Time Protocol Key Material

CiscoRTPOutputKeyEv getCiscoMediaEncryptionKeyInfo () Returns CiscoMediaEncryptionKeyInfo only if the provider is opened with TLS link and if the SRTP enabled option is set for the applicationin Cisco Unified Communications Manager User Administration. Otherwise, it returns null. CiscoMedia EncryptionKeyInfo getCiscoMediaSecurityIndicator() Returns media security indicator, which is one of the following constantsfrom CiscoMediaSecurityIndicator: MEDIA_ENCRYPTED_KEYS_AVAILABLE MEDIA_ENCRYPT_USER_NOT_AUTHORIZED MEDIA_ENCRYPTED_KEYS_UNAVAILABLE MEDIA_NOT_ENCRYPTED int getCallID () Returns CiscoCallID object if CiscoCall is present when this event is sent. If no CiscoCall is present, this method returns null. CiscoCallID getCiscoRTPHandle () Returns CiscoRTPHandle object. Applications can get a call reference by usingCiscoProvider.getCall(CiscoRTPHandle). If no call observer exists, or if there was no call observer when this event is delivered, CiscoProvider.getCall( CiscoRTPHandle ) may return null. CiscoRTPHandle CiscoTermSnapshotEv getMediaCallSecurityIndicator () Returns media security status for each active call on this device. CiscoMediaCall MediaSecurity Indicator[] CiscoTermSnapshotCompletedEv This event has no methods. CiscoMediaCallSecurityIndicator getCiscoMediaSecurityIndicator() Returns media security indicator, one of the following constants from CiscoMediaSecurityIndicator: MEDIA_ENCRYPTED_KEYS_AVAILABLE MEDIA_ENCRYPT_USER_NOT_AUTHORIZED MEDIA_ENCRYPTED_KEYS_UNAVAILABLE MEDIA_NOT_ENCRYPTED int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 159 Features Supported by Cisco Unified JTAPI Secure Real-Time Protocol Key Material

getCallID () Returns a CiscoCallID object if a CiscoCall is present when this event is sent. If no CiscoCall is present, this method returns null. CiscoCallID getCiscoRTPHandle () Returns a CiscoRTPHandle object. Applications can get a call reference by using CiscoProvider.getCall( CiscoRTPHandle ). If no callobserver exists or if there was no callobserver when this event is delivered, CiscoProvider.getCall( CiscoRTPHandle ) may return null. CiscoRTPHandle CiscoRTPInputStartedEv getCiscoRTPHandle () Returns a CiscoRTPHandle object. Applications can get a call reference by usingCiscoProvider.getCall(CiscoRTPHandle). If no call observer exists, or if there was no call observer when this event is delivered, CiscoProvider.getCall(CiscoRTPHandle) may return null. CiscoRTPHandle CiscoRTPInputStoppedEv getCiscoRTPHandle () Returns a CiscoRTPHandle object. Applications can get call reference by usingCiscoProvider.getCall(CiscoRTPHandle). If no call observer exists, or if there was no call observer when this event is delivered, CiscoProvider.getCall(CiscoRTPHandle) may return null. CiscoRTPHandle CiscoRTPOutputStartedEv getCiscoRTPHandle () Returns a CiscoRTPHandle object. Applications can get a call reference by usingCiscoProvider.getCall(CiscoRTPHandle). If no call observer exists, or if there was no call observer when this event is delivered, CiscoProvider.getCall(CiscoRTPHandle) may return null. CiscoRTPHandle CiscoRTPOutputStoppedEv getCiscoRTPHandle () Returns CiscoRTPHandle object. Applications can get call reference usingCiscoProvider.getCall(CiscoRTPHandle). If there is no call observer, or if there was no call observer when this event is delivered, thenCiscoProvider.getCall(CiscoRTPHandle) may return null. CiscoRTPHandle Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 160 Features Supported by Cisco Unified JTAPI Secure Real-Time Protocol Key Material

CiscoTermEvFilter getSnapshotEnabled () Returns the enable/status of CiscoTermSnapshotEv and CiscoTermSnapshotCompletedEv for the terminal. boolean setSnapshotEnabled (boolean enabled) Sets enable/disable status of CiscoTermSnapshotEv. If disabled, CiscoTermSnapshotEv and CiscoTermSnapshotCompletedEv are not sent to applications. void getRTPKeyEvEnabled () Returns the enable/disable status of CiscoRTPInputKeyEv and CiscoRTPOutputKeyEv. boolean setRTPKeyEvEnabled (boolean enabled) Sets enable/disable status for CiscoRTPInputKeyEv and CiscoRTPOutputKeyEv. void CiscoTerminal createSnapshot () throws InvalidStateException This method generates CiscoTermSnapshotEv, which contains security statusof current active call on the terminal. To access this method, the terminal must be in CiscoTerminal.IN_SERVICE state, and CiscoTermEvFilter.setSnapshotEnabled () must be set to True. void CiscoMediaTerminal register (CiscoMediaCapability[] capabilities, int[]supportedAlgorithms) The CiscoMediaTerminal must be in the CiscoTerminal.UNREGISTERED state and its provider must be in the Provider.IN_SERVICE state. Thisinterface provides dynamic registration with secure media. Ifapplications do not invoke this method, the media gets terminated in non-secure mode. void register (java.net.InetAddress address, int port, CiscoMediaCapability[] capabilities, int[] algorithmIDs) The CiscoMediaTerminal must be in the CiscoTerminal.UNREGISTERED state, and its provider must be in the Provider.IN_SERVICE state. This interface provides static registration with secure media. If applications do not register this interface, the media remains non-secured. AlgorithmIDs indicate SRTP algorithms that this CTIPort supports. AlgorithmIDs maybe only one of CiscoSupportedAlgorithms. void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 161 Features Supported by Cisco Unified JTAPI Secure Real-Time Protocol Key Material

CiscoRouteTerminal register (CiscoMediaCapability)[] capabilities, int registrationType, int[] algorithmIDs The CiscoRouteTerminal must be in the CiscoTerminal.UNREGISTERED state, and its provider must be in the Provider.IN_SERVICE state. By default, media gets terminated in non-secure mode. AlgorithmIDs indicate SRTP algorithms that this CTIPort supports. AlgorithmIDs may be only one of CiscoSupportedAlgorithms. void CiscoSupportedAlgorithm Constants AES_128_COUNTER Secured Monitoring and Recording This feature enables Cisco JTAPI to monitor and record secured calls. Monitoring and recording of calls was introduced in Release 6.0 of the Cisco Unified Communications Manager, but it did not support secured monitoring or recording of calls. For this release, the feature also supports secured calls. With this enhancement a supervisor or recorder can monitor or record a secure call only if its device security capability is same as or more than that of the agent. If the security capability of the monitor initiator's device is less than that of the target, the request for monitor fails. Recording request fails if the recording is attempted for an authenticated device, or if the security capability of the recorder is non-secured and that of the agent is Encrypted. Cisco JTAPI throws a PriviledgeViolationException with CTIERR_SECURITY_CAPABILITY_MISMATCH, when the monitoring request is rejected due to the supervisor not meeting the security capabilities of the agent. A new API getTransactionID() is added to CiscoTermConnMonitorInitiatorInfoEv and CiscoTermConnMonitorTargetInfoEv. CiscoJTAPI delivers a new event CiscoAddrMonitoringTerminatedEv when the monitoring session is torn down. This event is delivered to the Supervisor who had started the secured monitoring session but had dropped off from the monitoring call. New APIs getCiscoAddrMonitoringTerminatedEvFilter() and setCiscoAddrMonitoringTerminatedEvFilter() have been added to the interface CiscoAddrEvFilter for applications to get or set the filter value for the CiscoAddrMonitoringTerminatedEv. By default, the filter is set to True and the event is delivered. To stop receiving this event, applications must set this filter to False. As before, When a monitoring call (call used by monitor initiator) is conferenced, the final call may not have any connection to monitor target. When monitor initiator conferences another party to a monitoring call, both parties can to listen to the audio between monitor target and caller. Interface Changes CiscoJtapiException, on page 416, CiscoTermConnMonitorInitiatorInfoEv, on page 587, CiscoTermConnMonitorTargetInfoEv, on page 589, CiscoAddrMonitorTerminatedEv, on page 288, CiscoAddrEvFilter, on page 305, Message Sequences Secured Monitoring Use Cases, on page 1282, Secured Recording, on page 1446 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 162 Features Supported by Cisco Unified JTAPI Secured Monitoring and Recording

Backward Compatibility This feature is backward compatible. SelectRoute Interface Enhancement The SelectRoute interface gets enhanced to take the parameters PreferredOriginalCalledNumber and PreferredOriginalCalledOption. This enables applications to reset the OriginalCalled value to a specified PreferredOriginalCalledNumber when the call gets routed. This interface takes a list of PreferredOriginalCalledNumber, PreferredOriginalCalledOption, and corresponds them to the RouteSelected list. If the call gets routed to Route at index I in the RouteSelected list, the PreferredOriginalCalledNumber and PreferredOriginalCalledOption at index I get used. Applications get the following behavior with different values for these parameters. Below x, point to the index where the call is being routed. For example, if the call gets routed to Route n, then value of x will equal n. If a PreferredOriginalCalledOption at index x is invalid or out of range, JTAPI defaults it to CiscoRouteSession.DONOT_RESET_ORIGINALCALLED, and if PreferredOriginalCalledOption is null, all the routing gets done with option CiscoRouteSession.DONOT_RESET_ORIGINALCALLED. Note When PreferredOriginalCalledOption[x] Is Set to CiscoRouteSession.RESET_ORIGINALCALLED • If RouteSelected list contains Routes R1, R2 .. Rn, and preferredOriginalCalled list contains O1, O2, … On, if R1 is available, then call will be routed to R1, and OriginalCalledNumber will be set to O1; if R1 is busy and R2 is available, then call will be routed to R2, and OriginalCalledNumber will be set to O2 … and so on. • If RouteSelected list contains Routes R1, R2 .. Rn, and preferredOriginalCalled list contains O1, O2, … Om, and m < n, if R1 is available, the call will be routed to R1, and preferredOriginalCalled will be set to O1; if R1 is busy and R2 is available, the call will be routed to R2, and OriginalCalledNumber will be set to O2 and so on until m. From Route m+1, if Rm+1 is available, the call will be routed to Rm+1, and OriginalCalledNumber will be set to Rm+1, and so on. Lastly, if Rn is available, the call gets routed to Rn, and OriginalCalledNumber gets set to Rn". • If RouteSelected list contains Routes R1, R2 .. Rn, and preferredOriginalCalled list is NULL, then if R1 is available, the call will be routed to R1, and OriginalCalledNumber will be set to R1; if R1 is busy and R2 is available, the call will be routed to R2, and OriginalCalledNumber will be set to R2 … and so on. When PreferredOriginalCalledOption[x] Is Set to CiscoRouteSession.DONOT_RESET_ORIGINALCALLED • If RouteSelected list contains Routes R1, R2 .. Rn, and preferredOriginalCalled list contains O1, O2, .. On, the call will be routed to one of the available routes, and the OriginalCalledNumber will remain unchanged. • If RouteSelected list contains Routes R1, R2 .. Rn, and preferredOriginalCalled list contains O1, O2, … Om, and m < n, the call will be routed to one of the available routes, and the OriginalCalledNumber will remain unchanged. • If RouteSelected list contains Routes R1, R2 .. Rn, and preferredOriginalCalled list is NULL, the call will be routed to one of the available routes and OriginalCalledNumber will remain unchanged. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 163 Features Supported by Cisco Unified JTAPI SelectRoute Interface Enhancement

When OriginalCalled gets set to PreferredOriginalCalled, LastRedirectingParty number also gets reset to PreferredOriginalCalled. Note The following new or changed interfaces exist for SelectRoute Interface Enhancement: selectRoute (java.lang.String[] routeSelected, int callingSearchSpace, java.lang.String[] preferredOriginalCalledNumber, int[] preferredOriginalCalledOption) Selects one or more possible destinations for routing a call. int PreferredOriginalCalledOption takes one of the following values: DONOT REESET_ORIGINALCALLED Optional parameter value for PreferredOriginalCalledOption that specifies not to reset OriginalCalled. static int REESET_ORIGINALCALLED Optional parameter value for PreferredOriginalCalledOption that resets OriginalCalled to preferredOriginalCalledNumber. static int For details on the interface changes, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for SelectRoute Interface Enhancement, see Message Sequence Charts, on page 761. selectRoute() with Calling Search Space and Feature Priority The selectRoute() has feature priority and calling search space parameters as an array. This API provides the flexibility of different feature priorities and calling search spaces for each route selected. Interface Changes CiscoRouteSession, on page 523 Message Sequences selectRoute() with Calling Search Space and Feature Priority, on page 1124 Backward Compatibility This feature is backward compatible. The selectRoute() API remains functional and interoperates with the overloaded selectRoute() API. Set MessageWaiting SetMessageWaiting provides a method for applications to set the message-waiting lamp or indicator for an address. Invoke the method on an address that is in the same partition as the destination. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 164 Features Supported by Cisco Unified JTAPI selectRoute() with Calling Search Space and Feature Priority

The following interface specifies whether the message waiting indicator should be activated or deactivated for the address that the destination specifies. If enable is true, message waiting activates if not already activated. If enable is false, message waiting deactivates if not already deactivated. { public void setMessageWaiting (java.lang.String destination, boolean enable) throws javax.telephony.MethodNotSupportedException, javax.telephony.InvalidStateException, javax.telephony.PrivilegeViolationException } Shared Line Support Shared line represents the same DN appearances on multiple terminals. CiscoJtapi provides support for Shared Line, which provides applications with the ability to control shared DN terminals, hold a call on one shared DN Terminal and unhold the same call from another shared DN Terminal, make calls between two shared lines, initiate a call from one shared line terminal while another active call exists on another shared line terminal with the same DN. Share line provides the following interfaces: • CiscoAddress.getInServiceAddrTerminals()—Returns an array of terminals for which the address is in service. Terminal {} getInServiceAddrTerminals(); • CiscoAddrOutOfService.getTerminal()—Returns the terminal that is going out of service. Terminal getTerminal(); • CiscoAddrInService.getTerminal()—Returns the terminal that is going in service. Terminal getTerminal(); • CiscoConnection.setRequestController(TerminalConnection tc)—Allows an application to select a terminalConnection that is associated with a connection on which you can perform park, redirect, or disconnect operations. You need to do this in a situation where more than one active TerminalConnection exists in a SharedLine scenario. • CiscoConnection.getRequestController()—Returns TerminalConnection that application sets as request controller. • CiscoAddrAddedToTerminalEv—Gets sent when the following conditions occur: • A Terminal/Device gets added into the user controlList that contains a SharedDN, which sends the event to the application. In other words, if user has an address in control list, and a new device gets added with same address in control list, this event gets sent. • An EM (extension mobility) user logs into the terminal with a profile that contains a SharedDN. In this scenario, this event notifies that a new terminal is added to an already existing Address. • A new SharedDN is added to a device in a user control list Interface getTerminal() returns the terminal that gets added to the address. Interface getAddress() returns the address on which a new terminal is added. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 165 Features Supported by Cisco Unified JTAPI Shared Line Support

• CiscoAddrRemoveFromTerminalEv—Gets sent when the following conditions occur: • A user removes a Terminal/Device from the user controlList that contains a SharedDN. In other words, if a user has a shared address in a control list, and one of the devices with same address gets removed, this event gets sent. • An EM(extension mobility) user logs out from the terminal that had a profile that contains a SharedDN. This event notifies applications that one of the terminals is removed from an existing Address. • A new SharedDN (SharedLine) is removed from a device in a control list. Interface getTerminal() returns the terminal that gets removed from the address. Interface getAddress() returns the address from where the terminal gets removed. The following changed or new behaviors exist for a SharedLine: • Behavior changes for CiscoAddress event include • JTAPI applications will receive multiple CiscoAddrInServiceEv for shared line addresses. Applications can use CiscoAddrInServiceEv.getTerminal() to get the terminal on which address goes in service. • JTAPI applications receive multiple CiscoAddrOutOfServiceEv for shared line addresses. Applications can use CiscoAddrInServiceEv.getTerminal() to get terminal on which address goes out of service. • The address state goes in service when a first shared line goes in service; for example, when the first CiscoAddressInServiceEv gets received. • The address state goes out of service when the last shared line goes out of service; for example, when the last CiscoAddressOutOfServiceEv gets received. • For an incoming call, all the line appearances of a shared line ring. To applications, this gets presented as one active call (callActiveEv), one Connection(ConnCreatedEv), and multiple terminalConnection(TermConnCreatedEv one each for each shared line). • Calls get presented to all terminals. When a call is in a ringing state, the state of the terminal connection equals Ringing. When a the shared line answers, the terminalConnection state goes to an active state, while other terminalConnections on the shared line go to a passive state, and callControlTerminalConnection for all the shared lines at this point go into a bridged state. When a call is put on hold, all the terminal connections go into an active state, and callControllTerminalConnection goes to a held state. At this point, any terminal can retrieve the call. The retrieving terminal terminalConnection remains in an active state, and callControlTerminalConnection goes to a talking state while all other shared terminals terminalConnections go into a passive state. Simultaneously, CallControlTerminalConnection changes from a held state to a bridged state. • A shared line can make a call to another shared line of the same DN. In this scenario, the call includes only one connection and multiple terminal connections. • When a shared line makes a call to another shared line of the same DN, the post condition for this equals only one connection. • For a shared line connection with two active terminalConnections (such as barge), Connection.Disconnect() does not result in disconnected connection. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 166 Features Supported by Cisco Unified JTAPI Shared Line Support

If an application is monitoring only a SharedDN Connection with only a passive or bridged TerminalConnection, invoking any API on the connection results in a PreConditionException. • Similar to the previous scenario, if all the connections of a call monitored by an application have only a Passive or Bridged TerminalConnection, all APIs on the call throw a PreConditionException (such as Call.Drop()). • If more than one active TerminalConnection exists on a shared line, Call.drop() does not return in CallInValid in the following scenarios: • A normal two-party call between A and B, where A represents a SharedLine with A' and A' barged into the call The application does not monitor A' and B. If the application issues a Call.drop(), the A’ TerminalConnection goes into a passive state, but the call does not go InValid. • Similar to above, if A, A' , A" and B are in a Conference Call The application monitors only A and A', and Call.drop() does not result in the call going InValid. Only the A and A' terminal connections go passive. • A, A', and B, B' represent a SharedLine address A calls B, B answers, and A' and B' barge into the call. The application monitors only A and B. In this scenario, Call.drop() results in a TerminalConnection of A and B going passive, but the call does not go InValid. • If a TerminalConnection is in a passive or bridged state or Passive/InUse state, all APIs on the TerminalConnection() throw a PreConditionException. A TerminalConnection only allows an API Terminal ConnectionJoin() (called Barge) in the passive or bridged state. TerminalConnection does not currently support TerminalConnection Join(). • If more than one active or talking TerminalConnections exists in a connection, applications may have to end one before issuing an API on the connection like Redirect(), Park(), Disconnect(). You can select TerminalConnection by using API Connection.setRequestController (TerminalConnection tc). • If a call gets held on SharedLine terminals and an application issues a Connection.Disconnect (), the applications may set a particular TerminalConnection through API Connection.setRequestController(TerminalConnection tc). If requestcontroller is not set, all HeldTerminalConnections get dropped, and connection goes to a disconnected state. If only one HeldConnection gets dropped, the call remains present on other SharedLines terminals. The call appearance disappears from the dropping terminal, which disallows the terminal from barging into the call or participating in feature operations on the call. For details on the interface changes, see Cisco Unified JTAPI Extensions, on page 249 To view the message flow for shared lines, see Message Sequence Charts, on page 761 Silent Monitoring This feature provides the ability to silently monitor calls using an IP Phone. The caller represents the end point, which calls or receives a call from the monitor target. The monitor target is the party to monitor (in a call centre, the agent), and the monitoring party is the monitor initiator (the supervisor). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 167 Features Supported by Cisco Unified JTAPI Silent Monitoring

The recording feature lets applications record conversations on any observed address. Three recording configurations are available: The silent monitoring feature lets applications listen to a live conversation between two other parties. The monitor initiator cannot talk to either the monitor target or the caller. The feature provides notification tones when legal compliance is required. Only an application request can initiate monitoring. The application must send a monitor request for each call that it wants to monitor. The system can only monitor calls that are in a connected state. On the successful completion of a monitor request, the audio stream between the monitor target and the caller streams to the monitor initiator. The monitor target receive a tone: • if the monitor target is configured to receive a tone, or • if the application requests a tone when it starts the monitor Applications can monitor calls if they belong to the Standard CTI Allow Call Monitor user group or can be used outside of contact center. The system delivers monitoring-related events to all call observers. “Monitor” is a reserved word that should not be configured as display names for any lines in the system. Other reserved words are “Conference, ” “Park Number, ” “Barge, ” and “CBarge.” When a monitoring session is established, the terminal observer on the monitoring initiator receives Cisco RTP events. Although the media for a silent monitoring call flows only in one direction, getMediaConnectionMode() would return CiscoMediaConnectionMode.TRANSMIT_AND_RECEIVEinstead of CiscoMediaConnectionMode.RECEIVE_ONLY. Applications should expect to find the same behavior in CiscoMediaOpenLogicalChannelEv if a CTIPort is used as the monitor initiator. When a monitoring call (the call used by the monitor initiator) is conferenced, the final call does not have any connection to the monitor target. When the monitor initiator conferences another party into a monitoring call, both parties can listen to the audio between the monitor target and the caller. The following interfaces extend TermConnEv and are delivered to the call observer. For shared lines, the system delivers these events to call observers on the address or terminal of the talking terminal connections. Applications receive no events if they have only the terminal whose connection is in the INUSE or BRIDGED state. CiscoTermConnMonitoringStartEv CiscoTermConnMonitoringStartEv Indicates the start of monitoring and is delivered to the call observer on the monitor target. Using getMonitorType() on this event returns the monitor type. CiscoTermConnMonitoringEndEv CiscoTermConnMonitoringEndEv Indicates the end of monitoring and is delivered to the call observer on the monitor target. CiscoTermConnMonitorInitiatorInfoEv Exposes monitor initiator information and is delivered to the call observer of the monitor target. This interface has one method:CiscoMonitorInitiatorInfo getCiscoMonitorInitiatorInfo () Returns a CiscoMonitorInitiatorInfo that exposes the terminal name and address of the monitor initiator. CiscoTermConnMonitorTargetInfoEv Exposes monitor target information and is delivered to the call observer of monitor target. This interface has one method:CiscoMonitorInitiatorInfo getCiscoMonitorTargetInfo() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 168 Features Supported by Cisco Unified JTAPI Silent Monitoring

Returns a CiscoMonitorInitiatorInfo that exposes the terminal name and address of the monitor target. Two new error codes notify applications about monitoring failures: • CTIERR_PRIMARY_CALL_INVALID is returned by CiscoException.getErrorCode() for exceptions that occur when a monitoring request fails due to the call going idle or getting transferred. • CTIERR_PRIMARY_CALL_STATE_INVALID is returned when the monitoring request fails due to the call transitioning to a different state where monitoring cannot be invoked. This release introduces a new AddressType, MONITORING_TARGET. JTAPI creates a connection on an address of this type for a monitoring target address; CiscoAddress.getType() returns this value. Backward Compatibility This feature is backward compatible. Applications will not see any new events unless this feature is configured and used on one of the application-controlled addresses. The administrator can enable this feature by adding Standard CTI Allow Call Monitor user groups. For detailed information about these interface changes, see the following topics: • CiscoJtapiException, on page 416 • Related Documentation, on page 289 • CiscoCall, on page 332 • CiscoMediaTerminal, on page 454 • CiscoMonitorTargetInfo, on page 466 • CiscoMonitorInitiatorInfo, on page 465 • CiscoProvider, on page 492 • CiscoProviderCapabilities, on page 504 • CiscoProviderCapabilityChangedEv, on page 506 • CiscoRecorderInfo, on page 511 • CiscoTerminalConnection, on page 636 • CiscoTermConnMonitorInitiatorInfoEv, on page 587 • CiscoTermConnMonitorTargetInfoEv, on page 589 Secured Monitoring With this enhancement a supervisor can monitor a secure call only if its device security capability is same as or more than that of the agent. If the security capability of the monitor initiator's device is less than that of the target, the request for monitor fails. Cisco JTAPI throws a PriviledgeViolationException with CTIERR_SECURITY_CAPABILITY_MISMATCH, when the monitoring request is rejected due to the supervisor not meeting the security capabilities of the agent. A new API getTransactionID() is added to CiscoTermConnMonitorInitiatorInfoEv and CiscoTermConnMonitorTargetInfoEv. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 169 Features Supported by Cisco Unified JTAPI Silent Monitoring

CiscoJTAPI delivers a new event CiscoAddrMonitoringTerminatedEv when the monitoring session is torn down. This event is delivered to the Supervisor who had started the secured monitoring session but had dropped off from the monitoring call. The APIs getCiscoAddrMonitoringTerminatedEvFilter() and setCiscoAddrMonitoringTerminatedEvFilter() have been added to the interface CiscoAddrEvFilter for applications to get or set the filter value for the CiscoAddrMonitoringTerminatedEv. By default, the filter is set to True and the event is delivered. To stop receiving this event, applications must set this filter to False. As before, When a monitoring call (call used by monitor initiator) is conferenced, the final call may not have any connection to monitor target. When monitor initiator conferences another party to a monitoring call, both parties can to listen to the audio between monitor target and caller. Secured Monitoring Interface Changes CiscoJtapiException, on page 416, CiscoTermConnMonitorInitiatorInfoEv, on page 587, CiscoTermConnMonitorTargetInfoEv, on page 589, CiscoAddrMonitorTerminatedEv, on page 288, CiscoAddrEvFilter, on page 305 Message Sequences Secured Monitoring Use Cases, on page 1282, Secured Recording, on page 1446 Backward Compatibility This feature is backward compatible. Single Sign-On The Single Sign-On feature allows Cisco JTAPI applications to use the single sign-on ticket to authenticate instead of a user ID and password. Applications fetch the service ticket for the OpenSSO server from the active directory and then pass the ticket to Cisco JTAPI in the string used in the getProivder(String str) API. Applications can set the single sign-on ticket as ssoticket = "ssotokenfromat". Only end users can use this feature. Applications using this feature need not specify the user ID and password in the getProvider string. If an application is used by an end user and has the Standard CTI Secure Connection role enabled, then a user ID is required in the provider string. No password is required. This solution is designed around an active directory with a Kerberos environment to achieve Windows desktop Single Sign-On. If an active directory with a Kerberos environment is unavailable, then an alternate equivalent setup is available, which includes a KDC, an authentication server, and a domain controller. Sample Code String ssoticket

getSSOticket(); //application implementation String providerString

cucmserver + ssoticket +";"; JtapiPeer peer

JtapiPeerFactory.getJtapiPeer ( null ); try { Provider provider

peer.getProvider (providerString); } catch (Exception exp ) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 170 Features Supported by Cisco Unified JTAPI Single Sign-On

{ if ( exp instanceof PlatformException) { switch (((CiscoJtapiException)exp).getErrorCode() ) { case CiscoJtapiException. CTIERR_SSO_DISABLED: System.out.println("SSO feature not enabled on CUCM "); break; case CiscoJtapiException. CTIERR_SSO_AUTH_SERVER_DOWN: System.out.println("server down"); break; } } else { System.out.println("Exception

" + exp.toString()); } } SSO Cookie JTAPI supports authentication using SSO Cookie from Release 10.0.1 and later. An SSO Cookie, once generated, is valid for the entire session. The cookie can be reused during that session. SSO Cookie is supported only on a Secure Connection. Cisco JTAPI does not allow authentication using SSO Cookie over non-secure connections. Applications must also provide the fully qualified name of the client and server certificates in the providerString. The following new keywords are being introduced to be used in the provider string : ssocookie, cCert, sCert. The providerString must be in the following format when using an SSO Cookie: providerString = "ssocookie = <cookie>;cCert = <fully qualified client certificate>;sCert = <fully qualified server certificate>;" Interface Changes See CiscoJtapiException, on page 416 Message Sequences See Single Sign-On, on page 1474 Backward Compatibility This feature is backward compatible. Single Step Transfer This interface allows applications to transfer a call to an address. Cisco Unified JTAPI continues to support this interface as defined in JTAPI 1.2 specification, but the events that are delivered to applications are changed from the previous versions of Cisco Unified JTAPI. In previous versions of Cisco Unified JTAPI, the original call goes to a held state, and a new call gets created between the transfer controller and destination when applications use this interface. After successful completion of transfer, both calls on transfer controller go to an IDLE state. If a transfer fails, the original call remains in Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 171 Features Supported by Cisco Unified JTAPI Single Step Transfer

a held state, and applications retrieve the call. CiscoTransferStart and end events get delivered to the applications at the start and completion of the transfer operation. Applications get the following changes: • A new call does not get created. • CiscoTransferStartEv and CiscoTransferEndEv do not get delivered to applications. • The state of the original call is retained if the transfer operation fails. The pre and post conditions of this interface did not change. To view the message flow for Single Step Transfer, see Message Sequence Charts, on page 761 SIP 3XX Redirection The SIP Redirect server receives SIP requests and responds with 3xx(redirection) responses, which direct the client to contact an alternate set of SIP addresses. This enhancement supports the Cisco Unified Communications Manager Redirection (3xx) Call Control primitive in compliance with RFC 3261. The Cisco Unified Communications Manager Redirection primitive processes SIP 3xx responses and does sequential hunting to each contact address from the 3xx response. Cisco Unified Communications Manager Redirection primitive also handles feature interactions that result from performing this operation. Cisco Unified JTAPI exposes new reason codes in all CallEvs, which indicate when connection and terminalConnection are created and destroyed as a result of this primitive. LastRedirectAddress may change if feature interactions like JTAPI Redirect or CallForwardNoAnswer occur when the Redirection primitive is hunting for a target. If the target does not answer and Cisco Unified Communications Manager Redirect takes control of the call to send it to next target, lastRedirectAddress is set to the party who originally sent the SIP 3xx response. If a diversion header is present in the SIP 3xx response, the 3xx primitive uses the first value of the diversion header for lastRedirectParty, and JTAPI applications will see the diversion header element as lastRedirectAddress. To maintain backward compatibility, JTAPI exposes the new API CiscoCallEv.getCiscoFeatureReason() in the CiscoCallEv interface, which contains the reason as CM_REDIRECTION. Applications should be aware that new feature-specific reason codes could be returned from this API, and applications should provide default behavior for unrecognized reason codes. Note The following sections describe the interface changes for SIP 3XX Redirection. Public Interface CiscoFeatureReason REASON_CM_REDIRECTION This reason indicates that event is a result of 3xx response from the CM_REDIRECTION primitive in Cisco Unified Communications Manager. static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 172 Features Supported by Cisco Unified JTAPI SIP 3XX Redirection

CiscoCallEv getCiscoFeatureReason() A feature specific reason for this event. Applications should make sure to handle unrecognized reasons and provide default behavior as this interface may not be backward compatible as new reasons might be added in the future. int SIP Phone Support This release of Cisco Unified Communications Manager allows phones that run SIP to register and interoperate with phones that run SCCP. The following sections describe the new interfaces introduced to support phones that run SIP along with the limitations and differences in behavior with respect to phones that support SCCP. Though not all existing features are supported on phones that run SIP, the general behavior in terms of JTAPI events and interfaces for phones that run SIP are similar to that of a phone that runs SCCP. JTAPI applications can only control Cisco Unified IP Phone 7900 Series that run SIP, which includes Cisco Unified IP 7970 phones. Applications should not include Cisco Unified IP 7960, 7940, and other phones that run the SIP protocol in their control list. JTAPI applications cannot control third-party phones that run SIP, so third-party phones that run SIP should not be included in the control list. In prior releases, JTAPI supported an initial feature set on phones that run SIP. In this release support is added for the following functionality on phones that run SIP: • Park for Phones that run SIP • Unpark Phones that run SIP The order of events for consult calls differs for phones that run SIP and SCCP phones. Consider the following scenario: Tip 1. Terminal A initiates a call to the shared line B/B'. 2. The shared line initiates a consult call to Terminal C. If the shared line is a SIP device, the following call events occur: • B (active) receives: OnHold -> Select -> NewCall • B' (remote-in-use) receives: Select -> NewCall -> OnHold However, if the shared line is a SCCP device, the call events are Select -> OnHold -> NewCall on both terminals. If the application is only monitoring, call.getConsultingTerminalConnection() may return null. JTAPI supports the following features for phones that run SIP: • Call.connect; offhook • answer; disconnect; drop; hold, unhold • consult; transfer; conference; redirect Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 173 Features Supported by Cisco Unified JTAPI SIP Phone Support

• playdtmf, deviceData JTAPI supports the following events for phones that run SIP: • CiscoTermDeviceStateEv, RTP events, inService, and OutOfService • MediaTermConnDtmfEv (only out of band is supported), transfer start and end events, conference start and end events, CiscoToneChangedEv, and CiscoTermConnPrivacyChangedEv Behavior of phones that run SIP differ from that of phones that run SCCP in the following ways: • Call Rejection—When a call is made to a phone that runs SIP, the phone can choose to reject the call. In this case, applications perceive CallActive, ConnCreatedEv followed by ConnDisconnectedEv for the address on the SIP terminal. This is similar to RP rejecting the call. • Consult without media calls involving SIP phones should be transferred within 1.5 seconds after the call is connected. • For phones that run SIP, enbloc dialing is always used even if the user first goes off hook before dialing digits. The phone waits until all the digits are collected before sending the digits to the Cisco Unified Communications Manager . This means that CallCtlConnDialingEv is delivered only after enough digits are pressed on the phone to match one of the configured dialing patterns. • Applications should configure “out of band DTMF” on all devices to receive MediaTermConnDtmfEv. Events for CTI ports, route points, and phones that run SCCP are not changed. When a Cisco Unified IP Phone 7900 Series model that runs SIP using UDP as transport fails connectivity with Cisco Unified Communications Manager , JTAPI applications receive the events CiscoTermOutOfServiceEv and CiscoAddrOutOfServiceEv for the terminal and address defined for the phone. Because of the inherent delay in UDP in detecting the connectivity loss, the Cisco Unified IP Phone 7900 Series that runs SIP may visually show as registered after applications have already been notified with the out-of-service events. If Cisco Unified IP Phone s 7960, 7940, and non-Cisco Unified IP Phone 7900 Series that run SIP are included in the control list, exceptions are thrown when observers (both observer and call observers) are added to the address or terminal and CiscoTermRestrictedEv is delivered to a provider observer. The cause for these events would be CiscoRestrictedEv.CAUSE_UNSUPPORTED_PROTOCOL. CiscoTerminal exposes new interface getProtocol() to indicate whether terminal is a phone that runs SCCP or a phone that runs SIP. CiscoTerminalProtocol defines the values that are returned by getProtocol(). The following new interfaces that are defined on CiscoCall let applications get URL information for external SIP entities. Public Interface CiscoCall getLastRedirectingPartyInfo() CiscoPartyInfo getCurrentCallingPartyInfo() CiscoPartyInfo getCurrentCalledPartyInfo() CiscoPartyInfo getCalledPartyInfo() CiscoPartyInfo Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 174 Features Supported by Cisco Unified JTAPI SIP Phone Support

Public Interface CiscoPartyInfo getUrlInfo() CiscoUrlInfo getAddress() Address getDisplayName() string getUnicodeDisplayName() string getAddressPI() boolean getDisplayNamePI() boolean getlocale() boolean Public Interface CiscoUrlInfo getUrlType() Final int URL_TYPE_TEL Final int URL_TYPE_SIP Final int URL_TYPE_UNKNOWN int getHost() string getUser() string getPort() int getTransportType() Final int TRANSPORT_TYPE_UDP Final int TRANSPORT_TYPE_TCP int Public Interface CiscoTerminal getProtocol () int CiscoTerminalProtocol PROTOCOL_NONE Indicates an unrecognized or unknown protocol type static int PROTOCOL_SCCP Indicates the device is using SCCP to communicate to Cisco Unified Communications Manager static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 175 Features Supported by Cisco Unified JTAPI SIP Phone Support

PROTOCOL_SIP Indicates the device is using SIP to communicate to Cisco Unified Communications Manager static int SIP REFER or REPLACE REFER is a SIP method that is defined by RFC 3515. The REFER method indicates that the recipient (referee, identified by the Request-URI) should contact a third party (referred to as the target) by using the contact information that is provided in the request. This REFER method allows the party who is sending the REFER (referrer) to be notified of the outcome of the referenced request. Cisco Unified Communications Manager, being a Back-To-Back User Agent (B2BUA), processes both inside and outside dialog inbound REFER on behalf of the Referee. As result of REFER, Cisco Unified Communications Manager creates a call between the Referee and the Refer-to-Target. Ifthere is a previously existing call between the Referrer and the Referee, the call at the Referrer gets dropped after REFER completes. The REPLACES feature is the replacement of an existing SIP dialog with a new dialog. A SIP dialog is a call between two SIP user agents; a Cisco Unified Communications Manager dialog is a half call (callleg). The REPLACES feature is triggered either by REFER or by an INVITE. Cisco Unified Communications Manager handles a REPLACES request on behalf of the recipient of the REPLACES header. The request is associated with a new dialog and the requesting party is the party that wants to replace another party in the existing dialog (call) identified in the REPLACES header. Cisco Unified Communications Manager disconnects the dialog (call) identified in the REPLACES header and connects the requesting party. JTAPI is enhanced to model Call events caused by the Cisco Unified Communications Manager REFER and REPLACE features in the JTAPI call model. JTAPI provides applications with the capability to handle call events caused by REFER and REPLACE features. JTAPI does not provide any interface for applications to initiate REFER or REFER/INVITE with REPLACES requests; however, JTAPI can handle the call events properly. These two features are backward compatible. JTAPI provides events that are caused by REFER/REPLACE with CAUSE_NORMAL. Applications can get feature-specific reasons from the new interface CiscoCallEv.getCiscoFeatureReason(). This interface provides feature-specific reasons for current and new features, but this method will not remain backward compatible in future releases. Applications using this interface must implement default handling to avoid future backward-compatibility issues. Note The following sections describe the interface changes for SIP REFER/REPLACE. CAUSE Provided for REFER/REPLACE JTAPI provides CAUSE_NORMAL for events that caused by REFER/REPLACES. Applications should use CiscoCallEv.getCiscoFeatureReason() to get the feature-specific reason. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 176 Features Supported by Cisco Unified JTAPI SIP REFER or REPLACE

Interface Provided on CiscoCallEv This interface provides CiscoFeatureReason in the JTAPI call event. Older features, such as transfer, continue to receive the old CiscoCause that is provided by the previous interface, CiscoCallEv.getCiscoCause(). This new interface provides REASON_TRANSFER for transfer. com.cisco.jtapi.extensions Interface CiscoCallEv getCiscoFeatureReason() This interface returns Cisco Unified Communications Manager Feature Reason. int Interface CiscoFeatureReason JTAPI provides CiscoFeatureReason in Call events caused by features. CiscoFeatureReason is provided for existing as well as new Cisco Unified Communications Manager features. For REFER and REPLACES features, the reason would be REASON_REFER and REASON_REPLACES. This interface will provide new reasons for any new features that may be introduced in the future, and is not backward compatible. Applications using CiscoFeatureReason should expect to receive new reasons in later releases and must implement default behavior to maintain the Application’s backward compatibility. Applications that use CiscoFeatureReason should expect to receive new reasons in later releases and must implement default behavior to maintain backward-compatibility. Public Interface CiscoFeatureReason REASON_REFER Reason returned for events that are sent for REFER by Cisco Unified Communications Manager. static int REASON_REPLACE Reason returned for events that are sent for REPLACE by Cisco Unified Communications Manager. static int SIP Trunk Early Offer The SIP Trunk Early Offer feature allows the SIP trunk to support early offer outbound calls. The SIP trunk does not use a Media Termination Point (MTP) when the media capabilities and port information of the phone is available. If the media port information is not available, the Cisco Unified Communications Manager allocates an MTP to provide an offer. If the application enables this feature and makes a call that goes though a SIP trunk, the Cisco Unified Communications Manager must have the IP address and the port information of the registered terminal even before the media is established. This eliminates the need for MTP. The following are the changes done from the JTAPI perspective: • A new interface, CiscoBaseMediaTerminal, extends CiscoTerminal. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 177 Features Supported by Cisco Unified JTAPI SIP Trunk Early Offer

• A new register() API has the following arguments: • IP Address • Port • Media Capability • Algorithm ID • IP_V6 Address • Addressing Mode • Registration Type Applications use register() API to register CiscoMediaTerminal and CiscoRouteTerminal with the following registration types available in CiscoBaseMediaTerminal. • CiscoBaseMediaTerminal.NO_MEDIA_REGISTRATION (applicable only for route points) • CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION (for dynamic registration of CTI ports and route points) • CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT • CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION (for static registration of CTI port) • CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT The applications use the register() APIs on CiscoRouteTerminal and CiscoMediaTerminal for route points and CTI ports to specify the registration type. Note To enable this feature, select one of the following: • CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT for registration type to register a CTI port or a route point dynamically • CiscoBaseMediaTermial.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT for registration type to register a CTI port or a route point statically. If an application has enabled this feature and initiated a call that goes through a SIP Trunk, CiscoJTAPI delivers a new event CiscoMediaOpenIPPortEv. On recieving this event, applications query for the registration type using the API getRegistrationType(), which is exposed on this interface, and do the following based on the value returned. • If return value is CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT, applications must set the RTP Parameters and open the port. At present, the applications set the RTP parameters upon receiving CiscoMediaOpenLogicalChannelEv for dynamically registered CiscoMediaTerminal and CiscoRouteTerminal. • If return value is CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 178 Features Supported by Cisco Unified JTAPI SIP Trunk Early Offer

applications must open the port. At present, most of the applcations open statically registered terminals when they receive RTP events. If an application tries to register a terminal, which is already registered with registration type as CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT or CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT, with a different registration type, JTAPI throws a PlatformException with the error code as CiscoJtapiException.CTIERR_MEDIA_ALREADY_TERMINATED_DYNAMIC_GETPORT_SUPPORT or CiscoJtapiException.CTIERR_MEDIA_ALREADY_TERMINATED_STATIC_GETPORT_SUPPORT, respectively. A new API, isRTPRequired(), is also exposed on the interface CiscoMediaOpenLogicalChannelEv to indicate if the applications must set the RTP parameters or not when they receive this event. Applications must check the API when they recieve the CiscoMediaOpenLogicalChannelEv and set the RTP Parameters only when the return value is true. Early offer is not supported for IPv6 calls in release 8.5(1). Note If an application registers a terminal with registration type as CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT or CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT and the IP addressing mode as IPv6, the registration follows but this feature does not come into effect. The applications do not receive the CiscoMediaOpenIPPortEv. The application must close the ports when it receives media termination events or when a call is disconnected. When IPv6 support is added, the application receives two CiscoMediaOpenIPPortEv, for dual mode devices, one for IPv4 and the other for IPv6 addresses. When the call is answered, application closes the unused port based on MediaIPAddressingType in CiscoMediaOpenLogicalChannelEv. The service parameter, Fail Call Over SIP Trunk if MTP Allocation Fails, decides if the call must go through as a delayed offer or not. If applications do not set the RTP parameters when they receive CiscoMediaOpenIPPortEv for a dynamically registered terminal with get port support, this service parameter decides if the call must go through as a delayed offer or not. Interface Changes See CiscoBaseMediaTerminal, on page 329, CiscoMediaOpenIPPortEv, on page 448, CiscoMediaOpenLogicalChannelEv, on page 449, CiscoJtapiException, on page 416 Message Sequences See SIP Trunk Early Offer, on page 1498 Backward Compatibilty This feature is backward compatible. This feature is applicable only when applications register the CiscoMediaTerminals and CiscoRouteTerminals with registrationType as CiscoTerminal. DYNAMIC_MEDIA_REGISTRATION_GET_PORT or CiscoBaseMediaTerminal. STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 179 Features Supported by Cisco Unified JTAPI SIP Trunk Early Offer

Star (*) 50 Update The Star (*) 50 feature enables you to divert a call to original called party (value returned by CiscoCall.getCalledAddress() method) and the called party (value returned by CiscoCall.getCurrentCalledAddress() method) from phone UI. After pressing the iDivert softkey, a menu displays that identifies the names of the original called party and the called party. The user selects one of the two names and the call is redirected to the voice mailbox of the selected party. With the legacy iDivert, the call is diverted to original called party voice mailbox by just pressing iDivert softkey. Cisco Unified Communications Manager Administration introduced the following Service parameters to configure this feature: • iDivert Legacy Behavior—Determines whether the phone uses the legacy iDivert behavior when a user presses the iDivert softkey or the enhanced *50 iDivert behavior. If the iDivert legacy service parameter is set to true, the iDivert legacy behavior is adopted and vice versa. • Allow QSIG during iDivert–Determines whether iDivert legacy is allowed in deployments that have voice messaging integration over QSIG trunks and only used when the Use Legacy iDivert service parameter is set to true. • iDivert User Response timer–Determines the number of seconds that Cisco Unified Communications Manager Administration waits for a response from the user before the iDivert screen is removed. If no user action occurs by the time this timer expires, the screen is removed from the phone. If the Use Legacy iDivert service parameter is set to true, Cisco Unified Communications Manager Administration ignores this parameter. There is no interface change at JTAPI layer for this feature. The behavior changes from JTAPI application point of view means that Calls could either go to voice mail of OrigicalCalled Party or Called. Backward Compatibility This feature is backward compatible. Super Provider (Disable Device Validation) When a JTAPI application user is configured, the system administrator normally associates a certain set of terminals (Cisco Unified IP Phones and devices) with this application user, who can control and monitor only this set of terminals. The Super Provider feature gives applications the ability to control and monitor any terminal in a Cisco Unified Communications Manager cluster. The new createTerminal() new interface in CiscoProvider lets the application create a terminal by specifying a terminalName. JTAPI does not provide the capability to get the terminalName through any interface. The CiscoProvider.createTerminal(terminalName) returns the terminal. If the terminal already exists in the provider domain, JTAPI returns the existing terminal. A second new interface, CiscoProvider.deleteTerminal(), lets the application delete the CiscoTerminal objects that are created by using the CiscoProvider.createTerminal() interface. If the terminal object does not exist or the application did not create the terminal with the CiscoProvider.createTerminal() interface, JTAPI throws exceptions. JTAPI also provides a new interface on CiscoProviderCapabilities, canObserveAnyTerminal(), which can be enabled for application users through Cisco Unified Communications Manager Administration user Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 180 Features Supported by Cisco Unified JTAPI Star (*) 50 Update

configuration. Applications can use this interface to determine whether they have sufficient capability to invoke the createTerminal(terminalName) interface. If the application does not have sufficient capability and this interface is invoked, JTAPI throws a PrivilegeViolationException. If the application provides a terminalName that does not exist in the Cisco Unified Communications Manager cluster, JTAPI throws a InvalidArgumentException. Superprovider and Change Notification Superprovider enhancements for JTAPI in this release consist primarily of the following changes. When the “Superprovider privilege” gets disabled from Cisco Unified Communications Manager Administration after a provider opens, JTAPI gets notified through a CTI Change Notification Event and cleans up all the devices that it has opened that are not in its control list. JTAPI informs applications about the change using the “CiscoProviderCapabilityChangedEvent.” This new event gets issued when the flag changes and indicates whether the flag has been enabled or disabled. When a device that is not in the control list is opened in the Superprovider mode, then moved to the control list, JTAPI moves the device into its control list. • When a normal application receives a “CiscoProviderCapabilityChangedEvent” with the flag set, it means the Superprovider privilege has been granted to it, and it can start acquiring devices not in its control list. • When a Superprovider application receives a “CiscoProviderCapabilityChangedEvent” with the Superprovider flag not set, it means that the Superprovider privilege has been removed for it. The following sequence of events then occurs: • Applications receive a Provider OOS event and all devices acquired/opened by it are closed. • Applications receive a CiscoTermRemovedEv for all devices not in the control list that have been acquired or opened. • Applications receive a Provider inService event when JTAPI succeeds in reconnecting to CTI as a normal user. • Applications receive device and line information. • Applications receive CiscoTermCreatedEv for all controlled devices that were open before the provider went OOS. • JTAPI notifies applications by using the “CiscoProviderCapabilityChangedEvent” when the “park DN monitoring” flag is changed from Cisco Unified Communications Manager Administration. • When an application receives this event with the flag set, it does a register feature for the controlling park DN. • When an application receives this event with the flag not set, JTAPI again informs applications by using a “CiscoProviderCapabilityChangedEvent” and closes all the park DN addresses. • JTAPI notifies applications by using the CiscoProviderCapabilityChangedEvent” when the “change calling party number” flag is changed from Cisco Unified Communications Manager Administration. • When an application receives this event with the flag set, it can change the calling party number. • When an application receives this event with the flag not set, it cannot change the calling party number. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 181 Features Supported by Cisco Unified JTAPI Superprovider and Change Notification

Applications should not change the calling party number when this flag is disabled. • When a device that is not in the control list is opened or acquired by Superprovider, and is then deleted from Cisco Unified Communications Manager Administration, JTAPI closes the terminal object and sends a CiscoTermRemovedEvent to the application for that device. Interface Changes As a part of the Superprovider and change notification enhancements, JTAPI exposes the following API to applications. The JTAPI implementation for Superprovider and the handling of certain Provider capabilities has changed as a result. Superprovider enhancements for JTAPI in this release consist of the JTAPI QBE interface, changes in JTAPI behavior, and the new API which is exposed to applications. JTAPI delivers CiscoProviderCapabilityChangedEv to the applications, with the following format. Applications should be able to receive and process this new event from JTAPI. public interface CiscoProviderCapabilityChangedEv { public CiscoProviderCapabilities getCapability (); } CiscoProviderCapabilities have the following new methods for setting calling party modify privilege for the provider: public boolean canModifyCallingParty(); public void setCanModifyCallingParty(boolean value); CiscoProviderCapabilityChangedEv is delivered to the applications with the appropriate flag values. After this, the following sequence of events occurs: • JTAPI sends provider OOS events to the application and device/line OOS to devices and lines in the control list that are open. • JTAPI then tries to reconnect to CTI. • If reconnect succeeds, JTAPI sends a provider inService event and reopens all the devices in the control list that were previously open. • If reconnect does not succeed, JTAPI shuts down the provider and sends a ProviderClosedEvent. • If Superprovider privilege is added, JTAPI sends a CiscoProviderCapabilityChangedEv to the applications with the appropriate flag values. • If the MonitorParkDN flag is enabled, JTAPI sends a CiscoProviderCapabilityChangedEv with the monitor park DN flag set to true. • If the MonitorParkDN flag is disabled, JTAPI sends a CiscoProviderCapabilityChangedEv with the monitor park DN flag set to false. JTAPI also closes all the park DN addresses and delivers a CiscoAddrRemovedEv to applications. • When the ModifyCgPn flag is changed, JTAPI sets a flag in the provider object that is checked during redirect scenarios, and applications are accordingly allowed or denied permission to change the calling party. JTAPI also delivers a CiscoProviderCapabilityChangedEv with the flag set to modify CgPn. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 182 Features Supported by Cisco Unified JTAPI Superprovider and Change Notification

CiscoProvider Interface hasSuperproviderChanged() Tells the application whether the Superprovider privilege changed. boolean hasModifyCallingPartyChanged() Tells the application whether the ModifyCgPn privilege changed. boolean hasMonitorParkDNChanged() Tells the application whether the Park DN monitoring privilege changed. boolean Backward Compatibility This feature is not backward compatible. Support for Cisco Unified IP Phone 6901 Cisco Unified IP Phone 6901 is a new IP phone with keypad similar to other basic Cisco IP phones but this phone does not have display, speaker phone, or head set jack. This phone supports only SCCP protocol. Features such as Park, Unpark, Call Pickup, Group Call Pickup, Direct Transfer, Call Forward All, and Join are not supported as softkeys are not provided for these features. These features are supported only from Cisco Unified Communication Manager. Cisco Unified IP Phone 6901 is a one line device and can support two calls per line. So, features such as Join Across Lines and Direct Transfer Across Lines cannot be supported by these devices. One of the limitations of this phone is that to intiate or answer a call, the phone must be off-hook. If the phone is on-hook and the user initiates or answers a call, JTAPI throws InvalidStateException to the application with error code as CiscoJtapiException.OPERATION_NOT_AVAILABLE_IN_CURRENT_STATE. Another limitation is that Cisco Unified IP Phone 6901 does not accept XSI objects from applications, but if the application calls sendData() API for these phones, JTAPI throws an exception for the request to the application with the error code as CiscoJtapiException.COMMAND_NOT_IMPLEMENTED_ON_DEVICE. Table 6: List of Supported or Unsupported Features on Cisco Unified IP Phone 6901 Scope Supported/Unsupported Feature From application only Supported Park From application only Supported UnPark From application only Supported CallPickup From phone and application Supported Hold/Retrieve From phone and application Supported DirectTransfer Unsupported sendData() API As only one line can be configured on the phone Unsupported JoinAcrossLines Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 183 Features Supported by Cisco Unified JTAPI Support for Cisco Unified IP Phone 6901

Scope Supported/Unsupported Feature As only one line can be configured on the phone Unsupported DirectTransferAcrossLines From phone only Supported AutoBarge BIB cannot be configured on the phone Unsupported Recording From application only Note If 6901device is a supervisor. If it is an agent then monitoring is not supported. Supported Monitoring Supported Hunt-list support From phone and application. Supported Conference From application only. Supported CallForwardAll From application only. Supported Redirect Unsupported EM-Login Intercom line cannot be configured Unsupported Intercom Interface Changes See CiscoJtapiException, on page 416 Message Sequences See Support for Cisco Unified IP Phone 6901, on page 1512 Backward Compatibility This feature is backward compatible. Support for Cisco Unified IP Phone 6900 Series This feature allows Cisco Unified JTAPI applications to control terminals with rollover mode enabled. In rollover mode, terminals are configured with multiple addresses with the same DN but in different partitions or with different DNs. When rollover mode is enabled, consult calls can be created on the next available address on the terminal. Cisco Unified IP Phone 6900 Series can be configured with rollover mode. A new role Standard CTI Allow Control of phones supporting rollover mode has also been introduced to allow applications to control terminals with rollover enabled. Applications that support this new behavior where consult calls are created on a different address, must include this role to their application or end user. If not, all terminals configured with rollover mode are restricted and exceptions are thrown to addObserver() requests. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 184 Features Supported by Cisco Unified JTAPI Support for Cisco Unified IP Phone 6900 Series

Applications that support this behavior are must add call observer on the terminal or add call observers on all addresses on the terminal. Since consult call is created on the next available addresses, exceptions are thrown to consult requests if call observers are not added to all addresses. Join across lines must be enabled on Cisco Unified IP Phone 6900 Series to successfully complete conferences from applications. Cisco Unified Communications Manager Release 8.6, JTAPI supports multiple calls per line configuration on Cisco Unified IP Phone 69xx series. Prior to Release 8.6, Cisco Unified IP Phone 69xx series supported only one call per line, where Maximum Number of Calls/Busy Trigger defined for a line (MNC/BT) cannot exceed 2/1. With multiple calls per line, Cisco Unified IP Phone 69xx series supports more than one call per line, and MNC/BT is configured to values greater than 2/1. Outbound Rollover Behavior for 69xx Phones With MNC/BT configured as 2/1, When a second call is initiated from a line, the new call will be created on (rollover to) the second line. Cisco Unified Communications Manager Release 8.6 supports outbound rollover. If MNC is greater than 2, there can be multiple calls on the line before the rollover occurs. For both Cisco Unified Communications Manager Release 8.5 and 8.6, the outbound rollover occurs if MNC-1 calls are active on the line. Outbound Rollover is supported only on the endpoints. Using the JTAPI application, you can make MNC calls for a line; however, rollover will not happen at MNC-1, even if a second line exists). Interface Changes See CiscoProviderCapabilities, on page 504 and CiscoProviderCapabilityChangedEv, on page 506 Message Sequences See Support for Cisco Unified IP Phone 6900 Series, on page 1236 Backward Compatibility This feature is backward compatible. Support for 100+ Directory Numbers This feature enables users to have more than 100 Directory Numbers associated with a Device (Phones, CTI Ports and Route Points). JTAPI supports this feature and displays the corresponding addresses on the terminal to the application. Interface Changes There are no interface changes. Message Sequences There are no message sequences. Backward Compatibility This feature is backward compatible. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 185 Features Supported by Cisco Unified JTAPI Support for 100+ Directory Numbers

Support for VMware From Cisco Unified Communications Manager Release 8.0(1), Cisco JTAPI can be used on VMware ESXi version 4.0. The application can use Windows 2003 and Windows 2008 virtual machines on the above VMware version to run Cisco JTAPI. For more information on the supported Java Virtual Machines, see the following table. Table 7: Supported JVM Versions for Cisco Unified Communications Manager Unified CM 12.5 Unified CM 12.0 Unified CM 11.5 Unified CM 11.0 Unified CM 10.5 Unified CM 10.0 Version Operating System Not supported Not supported Not supported Not supported Not supported Not supported AS 3.0 Linux Supported Not supported Not supported Not supported Not supported Not supported RHEL 7 (64 bit) Linux Not supported Not supported Not supported Not supported Not supported Not supported RHEL 3.7 Linux RH 5.5 Oracle JVM 1.7.0.79 RH 5.5 Oracle JVM 1.7.0.79 RH 5.5 Oracle JVM 1.7.0.79 RH 5.5 Oracle JVM 1.7.0.76 RH 5.5 Oracle JVM 1.7.0.40 RH 5.5 Sun JVM 1.6.0.29 RHEL (32 bit) Linux Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Sun JVM 1.6.0.29 RHEL 5.5 (64 bit) Linux Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Sun JVM 1.7.0.40 RHEL 6 (64 bit) Linux Not supported Not supported Not supported Not supported Not supported Not supported 6.2 on Sparc and x86 Solaris Not supported Not supported Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Sun JVM 1.6.0.29 Windows XP 2003, 2008 Server(32-bit) Windows Not supported Not supported Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Sun JVM 1.6.0.29 Vista (32 bit) Windows Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Sun JVM 1.6.0.29 Windows 7(32 and 64 bit) 2008 Server R2(64 bit) Windows Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Sun JVM 1.6.0.29 Windows 8(32 and 64 bit) Windows Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Sun JVM 1.6.0.29 Windows Server 2012 R1 (32 bit) Windows Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Not supported Windows 8.1(32 and 64 bit) Windows Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 186 Features Supported by Cisco Unified JTAPI Support for VMware

Unified CM 12.5 Unified CM 12.0 Unified CM 11.5 Unified CM 11.0 Unified CM 10.5 Unified CM 10.0 Version Operating System Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Sun JVM 1.7.40 Windows Server 2012 R2 (64 bit) Windows Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.76 Oracle JVM 1.7.0.40 Not supported Windows 10(32 and 64 bit) Windows Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Oracle JVM 1.7.0.79 Not supported Not supported Not supported Windows Server 2016(64 bit) Windows Interface Changes There are no interface changes. Message Sequences There are no message sequences. Backward Compatibility Not applicable. Swap or Cancel and Transfer or Conference Behavior This feature enables Cisco Unified JTAPI support for Swap and Cancel operations on supported IP phones. When a Swap operation is invoked, it puts an active call on hold and retrieves the held call. When a Cancel operation is invoked, it breaks the consulting relationship between primary and consulting calls. These operations can only be invoked from supported phones. The Cisco Unified JTAPI interface does not allow SWAP/CANCEL operations to be invoked from the application. Whenever a user presses the SWAP key on a phone, JTAPI delivers CallCtlTermConnHeldEv and CallCtlTermConnTalkingEv for active and held calls and indicates their state change with CiscoFeatureReason.REASON_NORMAL. When a CANCEL operation is invoked and the relationship is broken between primary and consulting calls, Cisco Unified JTAPI is still able to use the Direct Transfer or Join feature to complete the transfer or conference operation. If the user presses the CANCEL key on phone after initiating a consult, the conference or transfer is not completed. Pressing the CANCEL key on phone triggers a Cancel notification to the application; Cisco Unified JTAPI sends CiscoCallFeatureCancelledEv to indicate the CANCEL operation. CiscoCallFeatureCancelledEv.getConsultCall() returns the earlier created consult call. When the CANCEL operation is performed during a connected transfer or conference, the following can occur: • The user presses the CANCEL key before selecting the Active Call softkey: In this case, pressing the Transfer key creates a consultCall GC3, and pressing the CANCEL key triggers CiscoCallFeatureCancelledEv on GC2 with GC3 as a consult call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 187 Features Supported by Cisco Unified JTAPI Swap or Cancel and Transfer or Conference Behavior

• 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

• Max calls configured • Busy Trigger • Position of address on a terminal • Voice mail pilot • ASCII and Unicode labels CiscoTerminal provides new interfaces to applications to get the following configurations of a terminal: • IPV4 and IPV6 IP addresses • Outbound Rollover configuration Terminal and address capability feature introduces new interfaces to determine if the terminal is capable of performing the following features: • Consult call rollover • Out bound call rollover • Join across lines • Direct transfer across lines • Join on same line • Direct transfer on same line Interface Changes See Related Documentation, on page 289, CiscoAddrEvFilter, on page 305, CiscoAddrVoiceMailPilotChangedEv, on page 326, CiscoTerminal, on page 617, CiscoProvFeatureID, on page 485, CiscoProvTerminalRegisteredEv, on page 490, and CiscoProvTerminalUnRegisteredEv, on page 491. Message Sequences See Terminal and Address Capability Settings Use Cases, on page 1240 Backward Compatibility This feature is backward compatible. Terminal and Address Restrictions This enhancement restricts applications from controlling and monitoring a certain set of terminals and addresses when the administrator configures them as restricted in Cisco Unified Communications Manager Administration. The administrator can configure a particular line on a device (address on a particular terminal) as restricted. If a terminal is added into the restricted list in Cisco Unified Communications Manager Administration, all addresses on that terminal are also marked as restricted in JTAPI. If an application comes up after the configuration is completed, it can know whether a particular terminal or address is restricted from checking the interface CiscoTerminal.isRestricted() and CiscoAddress.isRestricted(Terminal). For shared lines, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 189 Features Supported by Cisco Unified JTAPI Terminal and Address Restrictions

applications can query the interface CiscoAddress.getRestrictedAddrTerminals(), which indicates whether an address is restricted on any terminals. If a line (address on a terminal) is added into the restricted list after an application comes up, the applications will see CiscoAddrRestrictedEv. If the address has any observers, applications will see CiscoAddrOutOfService. When a line is removed from the restricted list, applications will see CiscoAddrActivatedEv. If an address has any observers, applications see CiscoAddrInServiceEv. Ifan application tries to add observers on an address after it is restricted, a PlatformException gets thrown. However, if any observers are added before the address is restricted, they will remain as is, but applications cannot get any events on these observers unless the address is removed from the restricted list. Applications can also choose to remove observers from an address. If a device (terminal) is added to the restricted list after an application comes up, the application will see CiscoTermRestrictedEv. If the terminal has any observers, the application will see CiscoTermOutOfService. If a terminal is added to the restricted list, JTAPI also restricts all addresses that belong to that terminal and applications will see CiscoAddrRestrictedEv. If a terminal is removed from the restricted list, applications will see CiscoTermActivatedEv and CiscoAddrActivatedEv for the corresponding addresses. If an application tries to add observers on a terminal after it is added to the restricted list, a PlatformException is thrown. However, if observers are added before the terminal is restricted, they remain as is, but applications cannot get any events on these observers unless the terminal is removed from the restricted list. If a shared line is added to the restricted list after an application comes up, the application will see CiscoAddrRestrictedOnTerminalEv. If any address observers exist on the address, the application will see CiscoAddrOutOfServiceEv for that terminal. If all shared lines are added to the restricted list, when the last one is added, applications will see CiscoAddrRestrictedEv. If a shared line is removed from the restricted list after the application comes up, applications will see CiscoAddrActivatedOnTerminalEv. If any observers exist on the address, the application will see CiscoAddrInServiceEv for that terminal. Ifall shared lines in the control list are removed from the restricted list, applications will see CiscoAddrActivatedEv when the last one is removed, and all addresses on terminals will receive InService events. If all shared lines in the control list are marked as restricted, and an application tries to add observers, a platform exception is thrown. If a few shared lines are in the restricted list, while others are not, when an application adds an observer on the address. Only non-restricted lines go in service. If any active calls are present when an address or terminal is added to the restricted list and reset, applications will see connection and TerminalConnections get disconnected. If no addresses or terminals are added to the restricted list, this feature is backward compatible with earlier versions of JTAPI: no new events are delivered to applications. The following sections describe the interface changes for address and terminal restrictions. CiscoTerminal isRestricted() Indicates whether a terminal is restricted. If the terminal is restricted, all associated addresses on this terminal are also restricted. Returns true if the terminal is restricted; returns false if it is not restricted. boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 190 Features Supported by Cisco Unified JTAPI Terminal and Address Restrictions

CiscoAddress getRestrictedAddrTerminals() Returns an array of terminals on which this address is restricted. If none are restricted, this method returns null. In shared lines, a few lines on terminals may be restricted. This method returns all the terminals on which this particular address is restricted. Applications cannot see any call events for restricted lines. If a restricted line is involved in a call with any other control device, an external connection gets created for the restricted line. javax.telephony.Terminal[] isRestricted(javax.telephony.Terminal terminal) Returns true if any address on this terminal is restricted. Returns false if no addresses on this terminal are restricted. boolean public interface CiscoRestrictedEv extends CiscoProvEv { public static final int ID

com.cisco.jtapi.CiscoEventID.CiscoRestrictedEv; /**

• The following define the cause codes for restricted events */ public final static int CAUSE_USER_RESTRICTED = 1; public final static int CAUSE_UNSUPPORTED_PROTOCOL = 2; } This is the base class for restricted events and defines the cause codes for all restricted events. CAUSE_USER_RESTRICTED indicates the terminal or address is marked as restricted. CAUSE_UNSUPPORTED_PROTOCOL indicates that the device in the control list is using a protocol that is not supported by Cisco Unified JTAPI. Existing Cisco Unified IP 7960 and 7940 phones that are running SIP fall in this category. CiscoAddrRestrictedEv Public interface CiscoAddrRestrictedEv extends CiscoRestrictedEv. Applications will see this event when a line or an associated device is designated as restricted from Cisco Unified Communications Manager Administration. For restricted lines, the address goes out of service and does not come back in service until it is activated again. If an address is restricted, addCallObserver and addObserver throws an exception. For shared lines, if a few shared lines are restricted, and others are not, no exception is thrown, but restricted shared lines do not receive any events. If all shared lines are restricted, an exception is thrown when adding observers. If an address is restricted after adding observers, applications see CiscoAddrOutOfServiceEv, and when the address is activated, the address goes in service. CiscoAddrActivatedEv Public interface CiscoAddrActivatedEv extends CiscoProvEv. Applications see this event whenever a line or an associated device is in the control list and is removed from the restricted list in the Cisco Unified Communications Manager Administration. If any observers exist on the address, applications see CiscoAddrInServiceEv. If no observers exist, applications can try to add observers, and the address goes in service. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 191 Features Supported by Cisco Unified JTAPI Terminal and Address Restrictions

CiscoAddrRestrictedOnTerminalEv Public interface CiscoAddrRestrictedOnTerminalEv extends CiscoRestrictedEv. If a user has a shared address in the control list, and if one of the lines is added into the restricted list, this event is sent. Interface getTerminal() returns the terminal on which the address is restricted. Interface getAddress() returns the address that is restricted. getAddress() javax.telephony.Address getTerminal() javax.telephony.Terminal CiscoAddrActivatedOnTerminal Public interface CiscoAddrActivatedOnTerminalEv extends CiscoProvEv. When a shared line or a device that has a shared line is removed from the restricted list, this event will be sent. The interface getTerminal() returns the terminal that is being added to the address. The interface getAddress() returns the address on which the new terminal is added. getAddress() javax.telephony.Address getTerminal() javax.telephony.Terminal CiscoTermRestrictedEv Public interface CiscoTermRestrictedEv extends CiscoRestrictedEv. Applications see this event when a device is added into restricted list from Cisco Unified Communications Manager Administration after the application launches. Applications cannot see events for restricted terminals or addresses on those terminals. If a terminal is restricted when it is in InService state, applications get this event and terminal and corresponding addresses move to the out-of-service state. CiscoTermActivatedEv Public interface CiscoTermActivatedEv extends CiscoRestrictedEv. getTerminal() Returns the terminal that is activated and is removed from the restricted list. javax.telephony.Terminal CiscoOutOfServiceEv CAUSE_DEVICE_RESTRICTED Indicates whether an event is sent because a device is restricted. static int CAUSE_LINE_RESTRICTED Indicates whether an event is sent because a line is restricted. static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 192 Features Supported by Cisco Unified JTAPI Terminal and Address Restrictions

CiscoCallEv CAUSE_DEVICE_RESTRICTED Indicates whether an event is sent because a device is restricted. static int CAUSE_LINE_RESTRICTED Indicates whether an event is sent because a line is restricted. static int SHA-512 Support for Digital Signatures From Release 11.5(1), Cisco Unified Communications Manager supports the SHA-512 algorithm for CTL, ITL and TFTP configuration file encryption. The TFTP File Signature Algorithm enterprise parameter has been added to allow administrators to select which encryption algorithm will be used. By default, this enterprise parameter is set to SHA-1, but you can reconfigure the parameter to SHA-512. Backward Compatibility The SHA-512 algorithm is not supported prior to release 11.5(1). If an application is running a Cisco JTAPI version that is prior to 11.5(1), that application must be using the SHA-1 algorithm in order to maintain a secure connection. Use Cases SHA Support for Digital Signatures, on page 1535 Transfer The transfer feature moves the participants of one call, the transferred call, to another call, the final call. Moving participants in a call trasitions their associated connections to the DISCONNECTED state in the transferred call and new connections for these participants getting created in the final call. Similarly, any associated TerminalConnections transition into the DROPPED state in the transferred call and get created in the final call. Cisco extensions by definition mark the start and the end of the events that relate to transfer. You can correlate the newly created connection objects with the old connection objects by use of the CiscoConnection.getConnectionID() method to obtain the CiscoConnectionID for the old and new connections. Matching connections possess identical CiscoConnectionID objects when you compare them by using the CiscoConnectionID.equals() method. CiscoTransferStartEv This event indicates that the transfer operation started, and the events that follow relate to this operation. Specifically, Connections and TerminalConnections get both removed and added as a result of the transfer. Applications may obtain the two calls that are involved in transfer-transferred call and final call and the transfer controller information from this event. If the JTAPI application is not observing the transfer controller, the transfer controller information does not get made available in this event. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 193 Features Supported by Cisco Unified JTAPI SHA-512 Support for Digital Signatures

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

Fields Event Call Meta Event Cause ConnCreatedEv C ConnConnectedEv C CallCtlConnEstablishedEv C TermConnCreatedEv C TermConnActiveEv C CallCtlTermConnTalkingEv C Call1 META_CALL_TRANSFERRING TermConnDroppedEv B CallCtlTermConnDroppedEv B ConnDisconnectedEv B CallCtlConnDisconnectedEv B Call2 META_CALL_TRANSFERRING TermConnDroppedEv C CallCtlTermConnDroppedEv C ConnDisconnectedEv C CallCtlConnDisconnectedEv CCallInvalidEv C Call2 META_CALL_TRANSFERRING CallObservationEndedEv Call2 META_UNKNOWN transferredCall = Call2 FinalCall = Call1 transferController = TermConnB CiscoTransferEndEv Call1 META_UNKNOWN Arbitrary Transfer; A Is the Transfer Controller In an arbitrary transfer, one call can get transferred to another call, irrespective of how either call was created. Unlike consult transfer, no need exists to first create one of the calls by using the consult method. • A calls B on call Call1. • A puts Call1 on hold. • A calls C on call Call2. • A transfers Call1 to Call2. To do this type of transfer, use the following JTAPI methods: • Call2.transfer(Call1) to transfer call Call1 to final call Call2, or • Call1.transfer(Call2) to transfer call Call2 to final call Call1 Assuming Call1.transfer(Call2) was called, the following table lists the core events that observers on A and C receive between CiscoTransferStartEv and CiscoTransferEndEv. Table 9: Core Events for Observers of A and C Fields Event Call Meta Event Cause transferredCall = Call2 finalCall = Call1 transferController = TermConnB CiscoTransferStartEv Call1 META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 195 Features Supported by Cisco Unified JTAPI Transfer Scenarios

Fields Event Call Meta Event Cause TermConnDroppedEv B CallCtlTermConnDroppedEv B ConnDisconnectedEv B CallCtlConnDisconnectedEv B Call1 META_CALL_TRANSFERRING ConnCreatedEv C ConnConnectedEv C CallCtlConnEstablishedEv C TermConnCreatedEv C TermConnActiveEv C CallCtlTermConnTalkingEv C Call1 META_CALL_TRANSFERRING TermConnDroppedEv B CallCtlTermConnDroppedEv B ConnDisconnectedEv B CallCtlConnDisconnectedEv B Call2 META_CALL_TRANSFERRING TermConnDroppedEv C CallCtlTermConnDroppedEv C ConnDisconnectedEv C CallCtlConnDisconnectedEv C CallInvalidEv C Call2 META_CALL_TRANSFERRING Transfer and Conference Extensions You may find that transfer and conference events are difficult to understand in JTAPI. This happens because, when the participants are moved from one call to the other, JTAPI represents this action by deleting the parties from one call and adding them to the other call. It may confuse you for an application to receive an indication that a party dropped from the call when, in reality, it is in the process of being moved. The Cisco Unified JTAPI implementation defines some extra events that make it easier for applications to deal with these functions. Transfer and DirectTransfer The transfer feature provides the ability to transfer a call. The direct transfer feature represents the ability to transfer any of the two calls that are present on the line, so controller of the call drops out, and other two parties remain active on the call. This functionality gets supported with one enhancement: this feature can be done in any state of the call and also can be redesigned to work with new CTI events. The following enhancements apply to the transfer feature: • The application can transfer two held calls. • The application can have OneHeld and OneConnected call in any order. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 196 Features Supported by Cisco Unified JTAPI Transfer and Conference Extensions

• 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

• If the application is observing both A and B, a Connection for A and B gets created, a Connection for Y gets temporarily created and dropped, and CiscoCall.getCurrentCallingParty() would return Address Y. Other inconsistencies in the calling information could occur if further features get performed on a basic call. Cisco recommends that you not configure a calling party transformation mast for a translation pattern that might get applied to JTAPI application-controlled addresses. Transport Layer Security (TLS) This feature lets JTAPI applications communicate with CTIManager through a secure connection. CTIManager runs a TLS listener socket to accept connections from JTAPI. Establishing a TLS connection requires a client certificate, which the server uses to authenticate the client, and a server certificate, which the client uses to authenticate the server. In the Cisco Unified Communications Manager environment, the server certificate exists in the form of CTL on the TFTP server, and JTAPI downloads this certificate. The initial download of CTL is trusted and occurs without verification, so Cisco strongly recommends performing this download in a secure environment. One of the two System Administrator Security Tokens (SAST) that are present in the CTL file signs the CTL; subsequent CTL downloads get verified with the SAST from the old CTL file. JTAPI connects to CAPF by using the CAPF protocol to get the client certificate (LSC). You can authenticate these certificates with the issuers certificate present in CTL. CTI tracks the number of provider connections that are created per client certificate. Applications can create only one provider by using a client certificate. If more than one instance of a provider is created, both providers get disconnected from CTI and go out of service. JTAPI will retry the connection to CTI to bring the original provider in service; however, if both instances of the provider continue to exist, after a certain number of retries, the provider gets permanently shut down, and the client certificate is marked as compromised. Any further attempt to create a provider by using this client certificate fails. Applications must contact the administrator to configure a new instanceId and download a new client certificate to resume operation. Each client certificate is associated with a unique instanceId configured in the Cisco Unified Communications Manager database. Applications can provide an instanceId in providerString as an optional parameter to use a unique certificate while creating a CiscoProvider. Note Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 198 Features Supported by Cisco Unified JTAPI Transport Layer Security (TLS)

From Release 15SU2 onwards, JTAPI supports TLS 1.3. However, TLS 1.3 support depends on the Java version used. Java version 1.8 (minor version 261) onwards supports TLS 1.3. CiscoJTAPI supports Java 1.8. The supported ciphers when communicating with CAPF are as follows: FIPS enabled: TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA FIPS disabled: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA The supported ciphers when communicating with CTI Manager are as follows: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA Note From Release 15SU3 onwards, CiscoJtapiProperties interface has been enhanced to update the minimum TLS version that an application uses while establishing a secure communication channel to CTI Manager and CAPF. Note To run multiple instances of applications with TLS, ensure that the application user is configured in the Cisco Unified Communications Manager database with multiple instanceIDs. Applications use these unique instanceIDs to get unique client certificates for each instance. The JTAPI preferences application provides a graphic user interface to configure the Security parameters and update server/client certificates. Application users need to configure the TFTPServer IP address, CAPFServer IP address, Username, InstanceID, and AuthorizationString parameters through the JTAPI preferences to download/install certificates on the application server. New interfaces are provided for JTAPI client applications on the client layer object. For example, a JTAPI client interface is provided on the CTIClientProperties class. This feature is backward compatible with previous releases as JTAPI Applications can still connect to CTIManager on non-secure socket connections. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 199 Features Supported by Cisco Unified JTAPI Transport Layer Security (TLS)

The following sections describe the interface changes for TLS support in JTAPI. CiscoJtapiPeer.getProvider() public javax.telephony.Provider getProvider(java.lang.String providerString) throws javax.telephony.ProviderUnavailableException This modified interface takes a new optional parameter InstanceID. It returns an instance of a Provider object, given a string argument that contains the desired service name. Optional arguments may also be provided in this string, with the following format: < service name > ; arg1

val1; arg2

val2; ... Where < service name > is not optional, and each optional argument = value pair that follows is separated by a semicolon. The keys for these arguments are implementation-specific, except for two standard-defined keys: • login—Provides the login user name to the Provider. • passwd—Provides a password to the Provider. CiscoJtapiPeer in providerString expects a new optional argument: • InstanceID—Provides InstanceID for Application Instance. InstanceID is needed when two or more instances of an application want to connect to a Provider (CTIManager) through a TLS connection from the same client machine. Each instance of an application requires its own unique X.509 certificate to establish a TLS connection. If JTAPI attempts to open more that one connection with the same username/instanceID, CTIManager rejects the TLS connection. If instanceID is not provided, JTAPI randomly picks one of the instances of USER and, in that case, the connection may fail if a connection for the selected Instance already exists. If the argument is null, this method returns some default provider as determined by the JtapiPeer object. The returned provider is in the Provider.OUT_OF_SERVICE state. Post-conditions: this.getProvider().getState()

Provider.OUT_OF_SERVICE Specified by getProvider in interface javax.telephony.JtapiPeer Parameters providerString The name of the desired service plus an optional argument. Returns An instance of the Provider object. Throws javax.telephony.ProviderUnavailableException Indicates that a provider that corresponds to the given string is unavailable. CiscoJtapiProperties JTAPI provides an interface on CiscoJtapiProperties to enable or disable the security option and install the client/server certificates that are required to establish a secure TLS socket connection. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 200 Features Supported by Cisco Unified JTAPI Transport Layer Security (TLS)

com.cisco.jtapi.extensions Interface CiscoJtapiProperties getSecurityPropertyForInstance public java.util.Hashtable getSecurityPropertyForInstance() This interface returns a Hash table with all the parameters set for User/InstanceID. The Hash table gets set with the following “key–value” pairs: VALUE KEY userName “user” InstanceID string “instanceID” authCode string “AuthCode” capfServer IP-Address string “CAPF” capfServer IP-Address port string “CAPFPort” tftpServer IP-Address string “TFTP” tftpServer IP-Address port string “TFTPPort” certificate Path string “CertPath” Boolean security option(true for enable/ false for disabled) string “securityOption” Boolean certificate status(true for updated/ false for not updated) string “certificateStatus” Returns—Hash table in the format described previously for the first user and instance. getSecurityPropertyForInstance public java.util.Hashtable getSecurityPropertyForInstance (java.lang.String user, java.lang.String instanceID) This interface returns a Hash table with all the parameters set for User/InstanceID. The Hash table is set with the following “key–value” pairs: VALUE KEY userName “user” InstanceID string “instanceID” authCode string “AuthCode” capfServer IP-Address string “CAPF” capfServer IP-Address port string “CAPFPort” tftpServer IP-Address string “TFTP” tftpServer IP-Address port string “TFTPPort” certificate Path string “CertPath” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 201 Features Supported by Cisco Unified JTAPI Transport Layer Security (TLS)

VALUE KEY Boolean security option(true for enable/ false for disabled) string “securityOption” Boolean certificate status(true for updated/ false for not updated) string “certificateStatus” Parameters: user - UserName for which you want security parameters instanceID - InstanceID for which you want security parameters Returns—Hash table in preceding format. setSecurityPropertyForInstance public void setSecurityPropertyForInstance(java.lang.String user, java.lang.String instanceID, java.lang.String authCode, java.lang.String tftp, java.lang.String tftpPort, java.lang.String capf, java.lang.String capfPort, java.lang.String certPath, boolean securityOption) You can use this interface to set security properties for the following parameters: Parameters: user—UserName for which the security parameter is being updated instanceID—InstanceID for which the security parameter is being updated authCode—Authorization string capf—IP-Address of CAPF server capfPort—IP-Address port number on which the CAPF server is running, as defined in a CallManager Service parameter. If the value is null, the default value is 3804. tftp—IP-Address of TFTP server tftpPort—IP-Address port number on which the TFTP server is running. The Cisco Unified Communications Manager TFTP server usually runs on port 69. If the value is null, the default value is 69. certPath—Path where certificate needs to be installed updateCertificate public void updateCertificate(java.lang.String user, java.lang.String instanceID, java.lang.String authcode, java.lang.String ccmTFTPAddress, java.lang.String ccmTFTPPort, java.lang.String ccmCAPFAddress, java.lang.String ccmCAPFPort, java.lang.String certificatePath) This interface installs an X.509 client certificate for the USER instance in the certificate store by connecting to the Cisco Unified Communications Manager Certificate Authority Proxy Function (CAPF) server. Italso downloads the Certificate Trust List (CTL) from the Cisco Unified Communications Manager TFTP server. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 202 Features Supported by Cisco Unified JTAPI Transport Layer Security (TLS)

If the user credentials are not valid, this method throws a PrivilegeViolationException. If the TFTP server or CAPF server address is not correct, this method throws an InvalidArgumentException. Every instance of an application requires a unique client certificate. If a multiple instanceID is configured in the Cisco Unified Communications Manager database, applications can call this interface multiple times to install a client certificate for every instance. Pre-conditions—When calling this interface, an application should have network connectivity with the Cisco Unified Communications Manager CAPF and TFTP servers. Post-conditions—This process installs client and server certificates on the JTAPI application machine. Parameters: user—Name of the CTI application user that is configured in the Cisco Unified Communications Manager database instanceID—Application instance ID that is configured in the Cisco Unified Communications Manager database. Everyinstance of an application requires a unique ID. authCode—Authorization string that is configured in the Cisco Unified Communications Manager database. You can use the authCode only once for getting certificates. ccmTFTPAddress—IP-Address of the Cisco Unified Communications Manager TFTP server. ccmTFTPPort—IP-Address port number on which the Cisco Unified Communications Manager TFTP server is running. The Cisco Unified Communications Manager TFTP server usually runs on port 69. Ifnull, the default value is 69. ccmCAPFAddress—IP address of the Cisco Unified Communications Manager CAPF server. ccmCAPFPort—Port number on which the Cisco Unified Communications Manager CAPF server is running, as defined in the Cisco Unified Communications Manager Service parameters. If the value is null, the default value is 3804. certificatePath—Directory path where the certificate needs to be installed Throws: InvalidArgumentException—This exception gets thrown for an invalid TFTP server or CAPF server address. PrivilegeViolationException—This exception gets thrown for an invalid user, instanceID, or authCode. IsCertificateUpdated public boolean IsCertificateUpdated (java.lang.String user, java.lang.String instanceID) This interface provides information about whether client and server certificates are updated for a given user/instanceID. Parameters: user—UserName as defined in the Cisco Unified Communications Manager Administration. instanceID—InstanceID for the specified UserName. Returns—True if certificates are already updated; false if certificates are not updated. updateServerCertificate public void updateServerCertificate(java.lang.String ccmTFTPAddress, java.lang.String ccmTFTPPort, java.lang.String ccmCAPFAddress, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 203 Features Supported by Cisco Unified JTAPI Transport Layer Security (TLS)

java.lang.String ccmCAPFPort, java.lang.String certificatePath) This interface installs an X.509 server certificate that is given the certificate path. If the TFTP server address is not correct, this method throws an InvalidArgumentException. Auto update applications should use this interface to update the server certificate before invoking an HTTPS connection with Cisco Unified Communications Manager. Pre-conditions—When calling this interface, applications should have network connectivity with the TFTP server. Post-conditions—This interface installs the server certificate on the JTAPI application machine. Parameters: ccmTFTPAddress—IP address of the Cisco CallManager TFTP server. ccmTFTPPort—Port number on which the Cisco Unified Communications Manager TFTP server is running. If null, the default value is 69. certificatePath—Directory path for installing the certificate. ccmCAPFAddress—IP address of the Cisco Unified Communications Manager CAPF server. ccmCAPFPort—Port number on which the Cisco Unified Communications Manager CAPF server is running. If the value is null, the default value is 3804. Throws: InvalidArgumentException—If the TFTP server address is invalid. Interface Provided on JTAPI Preferences The JTAPI Preferences dialog box includes a Security tab to let application users configure the username, instanceId, authCode, TFTP IP address, TFTP port, CAPF IP server address, CAPF server port, and certificate path, and enable secure connection. • “CAPF server port” number defaults to 3804. You can configure this value in the Cisco Unified Communications Manager Administration service parameters window. The CAPF server port value entered through JTAPI Preferences should match the one that is configured in Cisco Unified Communications Manager Administration. • “TFTP server port” number defaults to 69. Do not change this value unless you are advised to do so by the System Administrator. • “Certificate Path” is where the application wants the server and client certificates to be installed. If this field is left blank, the certificates get installed in the ClassPath of JTAPI.jar. • “Certificate update Status” provides information on whether a certificate has been updated or not. • Select “Enable Secure Connection” to enable a secure TLS connection to Cisco Unified Communications Manager. If “Enable Security Connection” is not selected, JTAPI makes a non-secure connection to CTI even if the certificate is updated/installed. • The “Enable Security Tracing” check box lets you enable or disable tracing for the certificate installation operation. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 204 Features Supported by Cisco Unified JTAPI Transport Layer Security (TLS)

If tracing is enabled, you can select three different levels, Error, Debug, or Detailed, from the drop-down menu. You can use the JTAPI Preference UI to configure a security profile for one or more than one userName/instanceID pair. When application users revisit this window, and have previously configured the security profile for a userName/instanceID pair, the security profile automatically gets populated when the user enters a username/instanceID and clicks on other edit box. The Trace Levels tab in the JTAPI Preferences UI is renamed as JTAPI Tracing. This highlights the fact that the JTAPI Tracing tab only lets you change trace setting for the JTAPI layer. Tracing for the installation of Security certificates must be enabled on the Security tab. Unicode Support Cisco Unified Communications Manager release 5.0 supports unicode display names on unicode-enabled IP phones. You can configure ASCII names and unicode names for display names. JTAPI receives all names in unicode and ASCII formats and provides two new interfaces, getCurrentCalledPartyUnicodeDisplayName and getCurrentCallingPartyUnicodeDisplayName, toallow applications to get display names in unicode. Italso provides the ability to get unicode display names during call progress. JTAPI receives the encoding capability of application controlled IP phones in device registered and device in service events from CTI, locale and language group information in device info response, and provides interfaces to applications to get the locale, alternate script, and unicode capability of IP phones. CiscoTerminal and CiscoTermInServiceEv interfaces are enhanced to provide this information for phones that are in the application control list when the CiscoTerminal is in the inservice state. JTAPI receives the alternate script information of all parties in the call and provides interfaces to applications to get the language group of the current calling and current called party. Two interfaces, getCurrentCallingPartyLanguageGroup and getCurrentCalledPartyLanguageGroup, are available on CiscoCall to get this information. Applications also receive both ASCII and UCS-2 encoded unicode display names for the current calling and called addresses. Unicode support for JTAPI also includes: • CiscoCall interface changes • CiscoLocales interface changes • CiscoTerminal / CiscoTerminalInServiceEv interface changes Applications might need to reconfigure their username/password after upgrading to Release 5.0. The following sections describe the interface changes for unicode support. Interface CiscoCall Changes The following new methods on CiscoCall let applications get the unicode display names and the corresponding locales. /**

• This interface returns the unicode display name of the current called party
• in the call. */ public String getCurrentCalledPartyUnicodeDisplayName(); /** Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 205 Features Supported by Cisco Unified JTAPI Unicode Support

• This interface returns the locale of the current called party unicode
• display name. CiscoLocales interface lists the supported locales. */ public int getCurrentCalledPartyUnicodeDisplayNamelocale(); /**
• This interface returns the unicode display name of the current calling party
• in the call. */ public String getCurrentCallingPartyUnicodeDisplayName (); /**
• This interface returns the locale of the current called party
• unicode display name */ public int getCurrentCallingPartyUnicodeDisplayNamelocale(); CiscoLocales The CiscoLocales interface lists all the locales that Cisco Unified JTAPI supports. For a list of all supported locales in the most recent release, see the man page for CiscoLocales, on page 442. Note public interface CiscoLocales { public static final int LOCALE_ENGLISH_UNITED_STATES; public static final int LOCALE_FRENCH_FRANCE; public static final int LOCALE_GERMAN_GERMANY; public static final int LOCALE_RUSSIAN_RUSSIA ; public static final int LOCALE_SPANISH_SPAIN ; public static final int LOCALE_ITALIAN_ITALY ; public static final int LOCALE_DUTCH_NETHERLAND ; public static final int LOCALE_NORWEGIAN_NORWAY ; public static final int LOCALE_PORTUGUESE_PORTUGAL; public static final int LOCALE_SWEDISH_SWEDEN ; public static final int LOCALE_DANISH_DENMARK public static final int LOCALE_JAPANESE_JAPAN; public static final int LOCALE_HUNGARIAN_HUNGARY ; public static final int LOCALE_POLISH_POLAND ; public static final int LOCALE_GREEK_GREECE ; public static final int LOCALE_TRADITIONAL_CHINESE_CHINA; public static final int LOCALE_SIMPLIFIED_CHINESE_CHINA; public static final int LOCALE_KOREAN_KOREA; } CiscoTerminalInServiceEv Interface getLocale() This method returns the current locale information for this terminal. int getSupportedEncoding () This method returns true if this terminal supports unicode. int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 206 Features Supported by Cisco Unified JTAPI Unicode Support

CiscoTerminal Interface getLocale() This method returns the current locale information for this terminal. The CiscoTerminal must be in the CiscoTerminal.IN_SERVICE state to access this method. int getSupportedEncoding () This method returns the unicode capability of this Terminal. The CiscoTerminal must be in the CiscoTerminal.IN_SERVICE state to access this method. int The getSupportedEncoding () returns one of the following results that are defined in CiscoTerminal. /**

• Indicates the <Code>CiscoTerminal.getSupportedEncoding ()</CODE>
• for this Terminal is UNKNOWN */ public final static int UNKNOWN_ENCODING = 0; /**
• Indicates the <Code>CiscoTerminal.getSupportedEncoding ()</CODE>
• for this is NOT_APPLICABLE.
• This is valid for only CiscoMediaTerminals and RoutePoints */ public final static int NOT_APPLICABLE = 1; /**
• Indicates the <Code>CiscoTerminal.getSupportedEncoding ()</CODE> for this
• Terminal is ASCII and this terminal supports only ASCII_ENCODING */ public final static int ASCII_ENCODING = 2; /**
• Indicates the <Code>CiscoTerminal.getSupportedEncoding ()</CODE>
• for this Terminal is UCS2UNICODE_ENCODING */ public final static int UCS2UNICODE_ENCODING = 3; Unrestricted Unified CM Cisco Unified JTAPI provides support for Unrestricted Cisco Unified Communications Manager, where encryption is disabled. This feature was added in Cisco Unified Communications Manager 7.1(5) and is available in 8.5(1) or later versions. Upgrade from an unrestricted version to a restricted version is not supported. Note Currently, the administrator is unable to create a new role with security groups and roles - ‘Standard CTI Secure Connection’ and ‘Standard CTI Allow Reception of SRTP Key Material’ as these roles are not available in unrestricted Cisco Unified Communications Manager. In case of an upgrade from non-secure restricted Cisco Unified Communications Manager to unrestricted Cisco Unified Communications Manager, all the security features are disabled and standard CTI secure roles associated with the end user are removed. But, the custom administrative roles created with CTI secure privileges are not disabled in the Cisco Unified Communications Manager database. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 207 Features Supported by Cisco Unified JTAPI Unrestricted Unified CM

In such cases, the application connects to the unrestricted Cisco Unified Communications Manager as a non-secure application as the CTIManager filters out the information about CTI secure roles. Upgrading from a secure restricted Cisco Unified Communications Manager to an unrestricted Cisco Unified Communications Manager is not supported. To do so, you should first set the security mode of the secure restricted Cisco Unified Communications Manager to non-secure and then upgrade to unrestricted Cisco Unified Communications Manager. Also, after an upgrade, the secure JTAPI application will not be able to connect to upgraded Cisco Unified Communications Manager version. To achieve this, the application must delete the existing certificates and disable secure connections. If the application tries to register to the CTI ports or route points as secure phones in unrestricted Cisco Unified Communications Manager, the request fails and JTAPI throws CiscoRegistrationExceptionImpl with error code as CiscoJtapiException.CTIERR_USER_NOT_AUTH_FOR_SECURITY. However, in some scenarios the registration request may pass but is followed by CiscoTermRegistrationFailedEv with a new errorCode CTI_SECURITY_NOT_ALLOWED. Interface Changes See CiscoTermRegistrationFailedEv, on page 648 Message Sequences See Unrestricted Unified CM, on page 1541 Backward Compatibility This feature is backward compatible. URI Dialing Cisco Unified JTAPI provides CTI support for URI dialing using directory URIs. Cisco Unified JTAPI differentiates between directory numbers and directory URIs by the presence of the @ symbol. If an @ symbol is present, the address is a directory URI. URI dialing is also supported for CTI Remote Devices. Remote destinations can be configured with directory URIs as the remote destination number. Interface Changes The following interfaces support directory URI addresses as the dialed digits or destination address: • Call.connect(Terminal origterm, Address origaddr, java.lang.String dialedDigits) • CallControlCall.consult(TerminalConnection tc, java.lang.String dialedDigits) • CallControlConnection.redirect(java.lang.String destinationAddress) • CallControlCall.transfer(java.lang.String address) • CallControlForwarding(java.lang.String destAddress) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 208 Features Supported by Cisco Unified JTAPI URI Dialing

Message Sequence No effect on the message sequence Backward Compatibility No backward incompatible changes Version Format Change In release 6.0, the Cisco Unified JTAPI version changed from a 4-digit format to a 5-digit format that is similar to the format used by Cisco Unified Communications Manager. The JTAPI version will remain similar to the Cisco Unified Communications Manager version. New interfaces let applications get the extended version number. See CiscoJtapiVersion, on page 261. Backward Compatibility This feature is backward compatible. Verification Involving PSTN Reachability The Verification Involving PSTN Reachability (VIPR) feature routes calls that are currently routed over PSTN, over the internet. For a normal VIPR call, JTAPI supports a VIPR call but no notification is sent to the application indicating that it is a VIPR call. Currently, VIPR calls are similar to Gateway or ICT calls. When the quality of VIPR calls over an IP trunk drops below a certain threshold, the calls are automatically routed through PSTN. JTAPI supports this fallback but does not report this to applications. Whenever VIPR PSTN fallback happens, media is terminated and reestablished. Applications can view CiscoRTPInputStoppedEv, CiscoRTPOutputStoppedEv followed by CiscoRTPInputStartedEv and CiscoRTPOutputStartedEv indicating the same. Interface Changes There are no interface changes. Message Sequences See Verification Involving PSTN Reachability, on page 1583. Backward Compatibility This feature is backward compatible. Video Capabilities and Multi-Media Information In Cisco Unified Communications Manager 10.0(1), JTAPI is exposing video capabilities for supported terminals and calls. Video capabilities for near and far-end terminals include whether they are video-enabled, inter-operability with TelePresence, and the number of screens. Video attributes for calls will also be available to JTAPI applications which would include IP/port address, codec, and other information. Using the provided Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 209 Features Supported by Cisco Unified JTAPI Version Format Change

video terminal and call information, JTAPI applications will be able to better handle calls like routing incoming video-capable calls to agents with video-enabled terminals. Exposing Multimedia Capability on CiscoTerminal Cisco JTAPI provides a new API, getCiscoMultiMediaCapabilityInfo() on CiscoTerminal to expose the multimedia capabilities of the terminal. The Video Capabilities and Multi-Media Information application can determine: • the video capability (either video disabled or video enabled) of the device, • the number of screens on a SIP device (only), and • if the device supports interoperability with telepresence devices. These capabilities are exposed on a new interface CiscoMultiMediaCapabilityInfo, which will have the following APIs to expose these capabilities: • getVideoCapability(), • getTelepresenceInfo(), and • getScreenCount(). Exposing Changes in Multimedia Capability Via a New Provider Event Any change in video capability of the terminal will be notified to the application by a new JTAPI event (CiscoProvTerminalMultiMediaCapabilityChangedEv). Video capability can be changed only from the Admin Device Configuration pages. Plugging in or out a Cisco Camera does not affect the video capability status, hence the new event is not triggered in this case. This event is a JTAPI provider event, and will be delivered only if the application has added provider observers. The terminal has to be in the registered state as a pre-condition for receiving this event. A change in Multimedia Capability through CiscoProvTerminalMultiMediaCapabilityChangedEv will not be delivered to applications when the video capability of an SCCP Phone changes. In this case, the terminal will unregister and register back; therefore the application needs to update the video capability after the terminal is registered. See Scenario Three, on page 1543. Note Exposing Multimedia Capability on a CiscoCall An application can detect if the far-end Party for an incoming call is video capable prior to media setup. Consider a scenario where A calls B, the multimedia capabilities of the calling and called party will be exposed on the CiscoCall on terminal B after the call is offered to terminal B. The Cisco JTAPI provides the getCallingTerminalMultiMediaCapabilityInfo () and getCalledTerminalMultiMediaCapabilityInfo() APIs on the CiscoCall to expose the multimedia capabilities of the calling and called party in a call. The same APIs can be used to determine the multimedia capabilities for an outgoing call, but note that the video capability will be known only after the call is answered. Consider a scenario where A calls B, B answers the call, the multimedia capabilities of the calling and called party will be exposed on the CiscoCall on terminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 210 Features Supported by Cisco Unified JTAPI Exposing Multimedia Capability on CiscoTerminal

A after the call is answered by terminal B. The APIs getCallingTerminalMultiMediaCapabilityInfo() and getCalledTerminalMultiMediaCapabilityInfo() return CiscoMultiMediaCapabilityInfo. Exposing Multimedia Streams Information on CiscoTerminal The new JTAPI terminal event CiscoMultiMediaStreamsInfoEv will be delivered to a terminal observer to indicate multimedia streams information of a call. The multimedia streams information is exposed on the interface CiscoMultiMediaProperties, via the API getProperties() on CiscoMultiMediaStreamsInfoEv. The Cisco JTAPI provides the multimedia streams information of the terminal after a call is connected. A MultiMedia Stream may include a video stream, a presentation stream, or both. A video capable device is a device that can do any of the following: • receive video (Video capability enabled in Admin Device Configuration pages and Cisco Camera not plugged in) • send video (Video capability enabled in Admin Device Configuration pages and Cisco Camera plugged in) • both send and receive video (Video capability enabled on Admin Device Configuration pages and Cisco Camera plugged in) The following table describes the video capabilities that is provided by Cisco JTAPI for currently supported devices. Dynamic Video Capability Change SupportsMultimedia Streams Information SupportsMultimedia Capabilities on CiscoCall Support Initial Device Multimedia Capability on CiscoTerminal Protocol Phone Model Yes No Yes Yes SCCP 8945 Yes Yes Yes Yes SIP 8945 Yes Yes Yes Yes SIP 9951/9971 N/A Yes Yes Yes SIP EX60/90 N/A No Yes N/A SCCP CTIPort N/A No Yes N/A SCCP CTIRoutePoint N/A Yes Yes Yes SIP CTS 500-32 N/A Yes Yes Yes SIP Jabber (CSF/softphone mode) Supported Features (Within the Same Cluster) JTAPI will provide video capability information for same cluster calls involved in the following features: • Originating Call and Consult Call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 211 Features Supported by Cisco Unified JTAPI Exposing Multimedia Streams Information on CiscoTerminal

• Redirect • Call Forward • Hold and Resume • Hunt List • Transfer • Super Provider • Extension Mobility Supported Features (Across Clusters) JTAPI will provide video capability information for across-cluster calls involved in the following features: • Originating Call and Consult Call • Redirect • Call Forward • Hold and Resume • Hunt List • Super Provider • Extension Mobility Limitations The following are the limitations of the Video Capabilities and Multi-Media Information feature: • Outgoing call - Applications observing only calling party will have calling and called party multimedia capabilities as UNKNOWN until the called party answers the call. Refer to Scenario Eleven, on page 1553. • Shared Line - Incoming call - calling and called party multimedia capabilities only if at least one of the terminal connections on the cisco call is not in passive state. Refer to Scenario Nine, on page 1549. • Shared Line - Incoming Call - Called party multimedia capabilities will not have correct multimedia capabilities when more than one terminal connection is in ringing state. Refer to Scenario Ten, on page 1551. • MultiMedia Streams Information - Cisco JTAPI will not deliver CiscoMultiMediaStreamsInfoEv on a CiscoTerminal which is a SCCP phone. • Incoming Call - If an outbound call is initiated over SIP Trunk configured with Early Offer then the called party will just respond back with the capabilities it was offered during the initial offer and not its complete capabilities. Refer to Scenario Fifteen, on page 1566. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 212 Features Supported by Cisco Unified JTAPI Supported Features (Across Clusters)

• Change in called party - In scenarios like Shared Lines or redirect, where the called party changes, the application will be notified of the new called party capability only if they configure the called party with unique display names. • HuntList - Cisco JTAPI will not deliver correct multimedia capabilities for calls involving huntlist in broadcast mode. Interface Changes See the following sections for interface changes: • CiscoCall, on page 332 • CiscoMasterKeyIndicator, on page 445 • CiscoMultiMediaCapabilityInfo, on page 468 • CiscoMultiMediaConnectionMode, on page 470 • CiscoMultiMediaEncryptionKeyInfo, on page 470 • CiscoMultiMediaProperties, on page 471 • CiscoMultiMediaStreamsInfoEv, on page 472 • CiscoMultiMediaType, on page 473 • CiscoProvTerminalMultiMediaCapabilityChangedEv, on page 489 • CiscoRTPPayload, on page 577 • CiscoRTPProperties, on page 578 • CiscoTermEvFilter, on page 614 • CiscoTerminal, on page 617 Message Sequences See Video Capabilities and Multi-Media Information, on page 1542. Backward Compatibility This feature is backward compatible. Video On Hold Support In Cisco Unified Communications Manager Release 10.01, existing CiscoTerminalConnection.hold() API is enhanced to take an additional parameter - contentID. This enhancement was designed/developed for the Remote Expert solution. This newly added contentID is a pass through from application (JTAPI) to CCM. JTAPI will not process or manipulate this value. The contentID will reference a VoH stream to be played when the call is placed on hold. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 213 Features Supported by Cisco Unified JTAPI Video On Hold Support

The VoH files are housed externally on a media sense server. To have video on hold capability, the video on hold server must be configured in CCM Admin. This server coincides to the media sense server which houses all the VoH files. Backward Compatibility This feature is backward compatible and existing applications will not be affected by this enhancement. Voice MailBox Support This feature exposes voice mailbox numbers, which let Cisco Unified Communications Manager JTAPI applications forward calls from a directory number to the correct voice mailbox. The Cisco Unified Communications Manager Administrator can associate a voicemail profile for each directory number. When the voicemail option is enabled for any forward setting, and if the corresponding forward is enabled, the call rolls down to the voicemail pilot number that is associated with the voicemail profile. The voicemail profile contains voicemail pilot number and voice mailbox mask fields. Voice mailbox mask specifies the mask that is used to format the voice mailbox number for auto-registered phones. When forwarding a call to a voice messaging system from a directory line on an auto-registered phone, Cisco Unified Communications Manager applies this mask to the number that is configured in the Voice Mail Box field for that directory line. For example, if you specify a mask of 972813XXXX, the voice mailbox number for directory number 7253 becomes 9728137253. If you do not enter a mask, the voice mailbox number matches the directory number (7253 in this example). Cisco Unified Communications Manager JTAPI Support To support this feature, Cisco Unified Communications Manager JTAPI exposes voice mailbox numbers for called party, lastRedirected party and originalCalled party. These voice mailbox fields are exposed on CiscoPartyInfo, which is exposed on CiscoCall object. If voicemail is not configured for a party, then Cisco Unified Communications Manager JTAPI will return empty Strings for voice mailbox fields. In prior releases Cisco Unified Communications Manager JTAPI did not expose voice mailbox fields to applications, so Cisco Unified Communications Manager JTAPI voice mailbox applications could not determine whether a voice mailbox mask was configured for a voicemail profile, which could result in a voice mailbox number that differs from the directory number. Performance and Scalability This feature does not increase the traffic from the Cisco Unified Communications Manager JTAPI layer to the application layer. However, small performance impact could occur because of additional fields that are passed over the network. XSI Object Pass Through Applications can pass XML objects through JTAPI and CTI interfaces to the phone. The XML object can contain display updates, softkey update/enable/disable, and other types of updates on the phone that are available through IP phone services features. This allows applications to access IP phone service capabilities through JTAPI and CTI interfaces without maintaining independent connections to the phones. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 214 Features Supported by Cisco Unified JTAPI Voice MailBox Support

CiscoTerminal Method Applications can send an XSI object in the byte format to the Cisco Unified IPPhone through the CiscoTerminal interface method. The system limits the payload to 2000 bytes of data with this interface. CiscoTerminal must be in the <CODE>CiscoTerminal.REGISTERED</CODE> state; its provider must be in the <CODE>Provider.IN_SERVICE</CODE> state. Successful response indicates that the data that was pushed has arrived at the phone; however, the application cannot receive any XML, including the CiscoIPPhoneResponse object from the push, back from the phone. If the application request is not successful, a PlatformException is thrown. Any request with more than 2000 bytes of data is rejected. public String sendData (String terminalData) throws InvalidStateException, MethodNotSupportedException; Before the application can make use of this feature, it must add TerminalObserver on the terminal. Authentication and Mechanism Sending an HTTP POST request to the phone web server, which requires the phone IP address, performs an object push. The web server parses the request, authorizes the request through the HTTP that is returned to the Cisco Unified Communications Manager, executes the request, and returns an XML response that indicates the success or failure of the request to the application. With XSI, the IP phone services object gets sent directly to the phone by the Skinny Client Control Protocol (SCCP). The phone does not authenticate the request, because the JTAPI client is trusted and does not require the phone IP address. For more information on actual XML contents, refer to the Cisco IPPhone Services Application Development Notes. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 215 Features Supported by Cisco Unified JTAPI CiscoTerminal Method

Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 216 Features Supported by Cisco Unified JTAPI Authentication and Mechanism

C H A P T E R 4 Cisco Unified JTAPI Installation This chapter describes how to install and configure the Cisco Unified JavaTelephonyAPI (JTAPI) client software for Cisco Unified Communications Manager. • Overview, on page 217 • Required Software, on page 218 • Supported Platforms, on page 218 • Installing the Cisco Unified JTAPI Software, on page 218 • Using Cisco Unified CM JTAPI, on page 227 • Cisco Unified JTAPI Configuration Settings, on page 227 • Managing the Cisco Unified CM JTAPI, on page 240 • Administering User Information for JTAPI Applications, on page 241 • Fields in the jtapi.ini File, on page 241 Overview The Cisco Java Telephony API (JTAPI) implementation comprises Java classes that reside on all client machines that run JTAPI applications. Installation of the Cisco Unified JTAPI client must take place before these applications can function correctly. Make sure that the Cisco Unified JTAPI classes are installed wherever JTAPI applications run, whether on Cisco Unified Communications Manager Administration, a separate machine, or both. Starting from Release 11.5(1)SU9, Release 12.5(1), and any subsequent SU or ES releases in this release train, Cisco JTAPI Client for Linux, and Windows will be available as the zip file (.zip) which includes the JTAPI packages for Linux (32 and 64 bit) or Windows (32 and 64 bit), documentation, and sample codes. You can download the zip files (CiscoJTAPIWindows.zip or CiscoJTAPILinux.zip), by clicking the Download link corresponding to the Cisco JTAPI Client for Linux (32 and 64 bit) or Cisco JTAPI Client for Windows (32 and 64 bit) available in the Cisco Unified CM Administration interface, Find and List Plugins window (Application > Plugins). The JTAPI Installer provides a unified installation/uninstallation process for the JTAPI client for Linux and Windows, as listed in the following table. For Cisco Unified Communications Manager 8.6(1) and later, Cisco JTAPI is also supported on 64-bit platforms. For Linux versions, the installer generates a binary file (.bin), and for the Windows version, it generates an executable file (.exe). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 217

Supported JVM Versions for Cisco Unified Communications Manager Administration For a detailed breakdown of supported JVM versions for this release of Cisco Unified Communications Manager, see https://developer.cisco.com/site/jtapi/documents/cisco-unified-jtapi-supported-jvm-versions/. If you have upgraded from Cisco Unified Communications Manager Administration 4.x to 5.0 or later, you must upgrade the JTAPI client software on any application server or client workstation on which JTAPI applications are installed. If you do not upgrade the JTAPI client, your application fails to initialize. Upgraded JTAPI client software does not work with previous releases of Cisco Unified Communications Manager. Note Required Software Cisco JTAPI requires the following software: • Cisco Unified Communications Manager • Supported Operating System Platform Supported Platforms For a detailed breakdown of supported Windows, Linux, and VMware platforms for Cisco Unified JTAPI, see https://developer.cisco.com/site/jtapi/documents/cisco-unified-jtapi-supported-jvm-versions/. For additional information on virtualization within a Unified Communications environment, see http://docwiki.cisco.com/wiki/Virtualization_for_Cisco_Unified_Communications_Manager_(CUCM). Installing the Cisco Unified JTAPI Software Installation Procedures The following sections describe the installation procedures for the Linux and Windows platforms. From Release 11.5(1)SU9, the following installers are replaced with .zip files (CiscoJTAPIWindows.zip and CiscoJTAPILinux.zip). • CiscoJTAPIClient-linux.bin • CiscoJTAPIClient.exe • CiscoJTAPIx64-Windows.exe • CiscoJTAPIx64-Linux.bin The following table lists the default JTAPI zip directory details. Classpath must be set accordingly to refer to the new jars. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 218 Cisco Unified JTAPI Installation Required Software

LD_LIBRARY_PATH CLASSPATH – Till 14SU2 CLASSPATH – 14SU2 Sample applications, documentation, and JTPrefs JTAPI Libraries Name/ Type of Client Not Applicable {Unzip Location}\CiscoJTAPIx32\lib\cryptojcommon.jar; {Unzip Location}\CiscoJTAPIx32\lib\cryptojce.jar; {Unzip Location}
CiscoJTAPIx32\lib\jcmFIPS.jar; {Unzip Location}
CiscoJTAPIx32\lib\sslj.jar; {Unzip Location}\CiscoJTAPIx32\lib\jtapi.jar {Unzip Location}\CiscoJTAPIx32\lib\bc-fips.jar; {Unzip Location}\CiscoJTAPIx32\lib\bcpkix-fips.jar; {Unzip Location}\CiscoJTAPIx32\lib\bctls-fips.jar; {UnzipLocation}\CiscoJTAPIx32\lib\jtapi.jar {Unzip Location}
CiscoJTAPIx32 {Unzip Location}
CiscoJTAPIx32\lib CiscoJTAPIWindows.zip Not Applicable {Unzip Location}\CiscoJTAPIx64\lib\cryptojcommon.jar; {Unzip Location}
CiscoJTAPIx64\lib\cryptojce.jar; {Unzip Location}
CiscoJTAPIx64\lib\jcmFIPS.jar; {Unzip Location}
CiscoJTAPIx64\lib\sslj.jar; {Unzip Location}
CiscoJTAPIx64\lib\jtapi.jar {Unzip Location}\CiscoJTAPIx64\lib
bc-fips.jar; {Unzip Location}\CiscoJTAPIx64\lib\bcpkix-fips.jar; {Unzip Location}\CiscoJTAPIx64\lib\bctls-fips.jar; {Unzip Location}\CiscoJTAPIx64 \lib\jtapi.jar {Unzip Location}
CiscoJTAPIx64 {Unzip Location}
CiscoJTAPIx64\lib Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 219 Cisco Unified JTAPI Installation Installation Procedures

LD_LIBRARY_PATH CLASSPATH – Till 14SU2 CLASSPATH – 14SU2 Sample applications, documentation, and JTPrefs JTAPI Libraries Name/ Type of Client export LD_LIBRARY_PATH= $LD_LIBRARY_PATH: {Unzip Location}/ CiscoJTAPIx32/lib Note The LD_LIBRARY_PATH need not be set from Release 14SU2. export CLASSPATH=$CLASSPATH: {Unzip Location}/ CiscoJTAPIx32/lib/CiscoJCEProvider.jar: {Unzip Location}/ CiscoJTAPIx32/lib/libCiscoJCEJNI.so: {Unzip Location}/ CiscoJTAPIx32/lib/libssl.so: {Unzip Location}/ CiscoJTAPIx32/lib/libssl.so.1.0.1: {Unzip Location}/ CiscoJTAPIx32/lib/log4j-1.2.17.jar: {Unzip Location}/ CiscoJTAPIx32/lib/libciscosafec.so: {Unzip Location}/ CiscoJTAPIx32/lib/libciscosafec.so.3: {Unzip Location}/ CiscoJTAPIx32/lib/libciscosafec.so.3.0.1: {Unzip Location}/ CiscoJTAPIx32/lib/libcrypto.so: {Unzip Location}/ CiscoJTAPIx32/lib/libcrypto.so.1.0.1: {Unzip Location}/ CiscoJTAPIx32/lib/slf4j-api-1.7.24.jar: {Unzip Location}/ CiscoJTAPIx32/lib/slf4j-log4j12-1.7.24.jar: {Unzip Location}/ CiscoJTAPIx32/lib/slf4j-simple-1.7.24.jar: {Unzip Location}/ CiscoJTAPIx32/lib/jtapi.jar: {Unzip Location}/ CiscoJTAPIx32/lib/bcpkix-jdk15on-154.jar: {Unzip Location}/ CiscoJTAPIx32/lib/bcprov-jdk15on-154.jar Note Starting from release 12.5(1)SU5, 14SU1 and any subsequent SU or ES releases in this release train, the JTAPI Linux plugin will bundle bcpkix-jdk15on.jar and bcprov-jdk15on.jar instead of bcpkix-jdk15on-154.jar and bcprov-jdk15on-154.jar. Classpath must be set accordingly to refer to the new jars. export CLASSPATH=$CLASSPATH: {Unzip Location}\CiscoJTAPIx32\lib
bc-fips.jar; {Unzip Location}\CiscoJTAPIx32\lib\bcpkix-fips.jar; {Unzip Location}\CiscoJTAPIx32\lib\bctls-fips.jar; {Unzip Location}\CiscoJTAPIx32 \lib\jtapi.jar {Unzip Location}
CiscoJTAPIx32 {Unzip Location}
CiscoJTAPIx32\lib CiscoJTAPILinux.zip {Unzip Location}
CiscoJTAPIx64 {Unzip Location}
CiscoJTAPIx64\lib Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 220 Cisco Unified JTAPI Installation Installation Procedures

LD_LIBRARY_PATH CLASSPATH – Till 14SU2 CLASSPATH – 14SU2 Sample applications, documentation, and JTPrefs JTAPI Libraries Name/ Type of Client export LD_LIBRARY_PATH= $LD_LIBRARY_PATH: {Unzip Location}/ CiscoJTAPIx64/lib export CLASSPATH=$CLASSPATH: {Unzip Location}/ CiscoJTAPIx64/lib/CiscoJCEProvider.jar: {Unzip Location}/ CiscoJTAPIx64/lib/libCiscoJCEJNI.so: {Unzip Location}/ CiscoJTAPIx64/lib/libssl.so: {Unzip Location}/ CiscoJTAPIx64/lib/libssl.so.1.0.1: {Unzip Location}/ CiscoJTAPIx64/lib/log4j-1.2.17.jar: {Unzip Location}/ CiscoJTAPIx64/lib/libciscosafec.so: {Unzip Location}/ CiscoJTAPIx64/lib/libciscosafec.so.3: {Unzip Location}/ CiscoJTAPIx64/lib/libciscosafec.so.3.0.1: {Unzip Location}/ CiscoJTAPIx64/lib/libcrypto.so {Unzip Location}/ CiscoJTAPIx64/lib/libcrypto.so.1.0.1: {Unzip Location}/ CiscoJTAPIx64/lib/slf4j-api-1.7.24.jar: {Unzip Location}/ CiscoJTAPIx64/lib/slf4j-log4j12-1.7.24.jar: {Unzip Location}/ CiscoJTAPIx64/lib/slf4j-simple-1.7.24.jar: {Unzip Location}/ CiscoJTAPIx64/lib/jtapi.jar: {Unzip Location}/ CiscoJTAPIx64/lib/bcpkix-jdk15on-154.jar: {Unzip Location}/ CiscoJTAPIx64/lib/bcprov-jdk15on-154.jar Note Starting from release 12.5(1)SU5, 14SU1 and any subsequent SU or ES releases in this release train, the JTAPI Linux plugin will bundle bcpkix-jdk15on.jar and bcprov-jdk15on.jar instead of bcpkix-jdk15on-154.jar and bcprov-jdk15on-154.jar. Classpath must be set accordingly to refer to the new jars. export CLASSPATH=$CLASSPATH: {Unzip Location}\CiscoJTAPIx64\lib\bc-fips.jar; {Unzip Location}\CiscoJTAPIx64\lib\bcpkix-fips.jar; {Unzip Location}\CiscoJTAPIx64\lib\bctls-fips.jar; {Unzip Location}\CiscoJTAPIx64 \lib\jtapi.jar Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 221 Cisco Unified JTAPI Installation Installation Procedures

Linux Platforms Cisco Unified JTAPI supports multiple languages for the installation and JTAPI Preferences user interface. The Cisco Unified JTAPIInstaller installs the following items on the local disk drive: • JTAPI java classes in $HOME/.jtapi/lib • JTAPI Preferences in $HOME/.jtapi/bin • JTAPI sample applications (makecall, jtrace) in $HOME/.jtapi/bin • JTAPI documentation in $HOME/.jtapi/bin/doc Applicable from 8.6 release: For 64-bit JTAPI Installer on 64-bit OS: • JTAPI java classes in $HOME/.jtapi64/lib • JTAPI Preferences in $HOME/.jtapi64/bin • JTAPI sample applications (makecall, jtrace) in $HOME/.jtapi64/bin • JTAPI documentation in $HOME/.jtapi64/bin/doc Perform the following steps to install the Cisco Unified JTAPI software on a Linux platform: 1. Log in to the computer where you want to install the Cisco Unified JTAPI client software. 2. Locate the appropriate ISMP/IA installer and launch it: Applicable from 8.6 release:: For 64-bit JTAPI Installer on 64-bit OS, • CiscoJTAPIx64-Linux.bin - for Linux OS 1. Log in to the computer where you want to install the Cisco Unified JTAPI client software. 2. Locate the appropriate ISMP/IA installer and launch it: 3. Follow the instructions that the Cisco Unified JTAPI Installer presents. Applicable for 11.5(1)SU9 and any subsequent SU or ES releases in this release train and also 12.5(1) release onwards. Perform the following steps to install the Cisco Unified JTAPI software on a Linux platform: Before you begin • If you are using Cisco JTAPI version earlier to release 11.5(1)SU9, then uninstall the earlier version. Procedure Step 1 Log in to the computer where you want to install the Cisco Unified JTAPI client software. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 222 Cisco Unified JTAPI Installation Linux Platforms

Step 2 Click Download link to download the required JTAPI client from the Unified Communications Manager Administrative interface Plugins page (Application > Plugins). Save the zipped file on the CTI application server where JTAPI is used. Step 3 Un-zip the downloaded folder to extract the files. The files include the JTAPI packages for Linux (32-bit and 64-bit), documentation, and sample code. Update the classpath variable. Go to Step 6. Step 4 Alternatively, run install32.sh or install64.sh depending on the platform . Follow the instructions mentioned in the scripts to install and update classpath. Step 5 After installation, go to the installed location. Step 6 Run the jtprefs.bat file. The Cisco Unified Communications Manager Jtapi Preferences <version number> Release dialog box is displayed. Note JTPrefs is an application, which provides a user interface to configure the jtapi.ini parameters. JTprefs is used to create the jtapi.ini file if one does not exist and to configure or modify the trace settings. In Linux Machines after installation the session must be logged out and logged in again for the changes to take effect. In Linux, for example, the default directory is unzipped folder\CiscoJTAPILinux\CiscoJTAPIx64\lib or unzipped folder\CiscoJTAPILinux\CiscoJTAPIx32\lib. Note The installation software installs the Cisco Unified JTAPI software on the default drive. In Linux, for example, the default directory is $HOME/.jtapi/lib( for 32 bit installer); $HOME/.jtapi64/lib( for 64 bit installers). Verifying Linux Installation To ensure that the JTAPI installation has been done properly, perform the following steps: Procedure Step 1 Check that the .jtapiver.ini file is created in the $HOME directory. Step 2 Check that the JTAPI Program files and documentation are present under the folder $HOME/.jtapi/bin. Look for the makecall, jtrace, Locale_files, and doc folders. Step 3 Check that the JTAPI Library is present under the folder $HOME/.jtapi/lib. Look for the jtapi.jar, jtracing.jar, and updater.jar files. Step 4 After ensuring that jtapi.jar is present in the classpath, run the following command from the command line prompt of $HOME/.jtapi/bin ./_jvm/bin/java: com.cisco.services.jtprefs.jtprefsFrame The JTAPI Preferences dialog box appears. Note In the absence of the JTPrefs application, you can generate the jtapi.ini file by entering: < jview | java > CiscoJtapiVersion -parms Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 223 Cisco Unified JTAPI Installation Verifying Linux Installation

This command generates a jtapi.ini file in the current directory. For Cisco Unified Communications Manager 8.6(1) and later, for 64 bit installer on a 64 bit OS, the default install directory is $HOME/.jtapi64/. After installation, CLASSPATH is updated with the location of jtapi.jar. For linux a file .jtapiver.ini is updated with the install location in user home directory. For classpath changes to take effect, you need to log off and login again. During installation, you can choose a different folder than $HOME to install JTAPI. In this case, the system creates a folder called .jtapi within the specified folder and creates the bin and lib folders within that folder for copying the corresponding files. For example, if you choose the folder name /home/jtapiuser, the folder structure would be /home/jtapiuser/.jtapi/bin (for 32 bit installers)—Contains the makecall, jtrace, Locale_files, and doc folders. or /home/jtapiuser/.jtapi64/bin (for 64 bit installers) /home/jtapiuser/.jtapi/lib(for 32 bit installers)—Contains the jtapi.jar, jtracing.jar, and updater.jar files or /home/jtapiuser/.jtapi64/lib (for 64 bit installers) In this case, run the command at Step4 from the /home/jtapiuser/.jtapi/bin folder (for 32 bit installer) or /home/jtapiuser/.jtapi64/bin folder (for 64 bit installer). Windows Platforms Cisco Unified JTAPI supports multiple languages for the installation and JTAPI Preferences user interface. The Cisco Unified JTAPI Installer installs the following items on the local disk drive: Applicable from 8.6 release: • JTAPI Java classes in %SystemRoot%\java\lib • JTAPI Preferences in Program Files\JTAPITools • JTAPI sample applications (makecall, jtrace) in Program Files\JTAPITools • JTAPI documentation in Program Files\JTAPITools\doc For 64-bit JTAPI Installer on 64-bit OS, • JTAPI Java Preferences in Program Files\Cisco\JTAPI64Tools • JTAPI Java classes in Program Files\Cisco\JTAPI64Tools\lib • JTAPI sample applications (makecall, jtrace) in Program Files\Cisco\JTAPI64Tools • JTAPI documentation in Program Files\Cisco\JTAPI64Tools\doc Post installation, CLASSPATH is updated with the location of jtapi.jar. For windows, registry is updated, [HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\JTAPI\Client\Tools HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\JTAPI\Client\Tools\Lib] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 224 Cisco Unified JTAPI Installation Windows Platforms

To install the Cisco Unified JTAPI software on a Windows platform, perform the following steps: 1. Log in to the computer where you want to install the Cisco Unified JTAPI client software. 2. Close all Windows programs. 3. Locate the Cisco Unified JTAPI installer (CiscoJTAPIClient.exe) and launch it. 4. Follow the installer instructions. Applicable for 11.5(1)SU9 and any subsequent SU or ES releases in this release train and also 12.5(1) release onwards. Perform the following steps to install the Cisco Unified JTAPI software on a Windows platform: Before you begin • If you are using Cisco JTAPI version earlier to release 11.5(1)SU9, then uninstall the earlier version. Procedure Step 1 Log in to the computer where you want to install the Cisco Unified JTAPI client software. Step 2 Click Download link to download the required JTAPI client from the Unified Communications Manager Administrative interface Plugins page (Application > Plugins). Save the zipped file on the CTI application server where JTAPI is used.. Step 3 Un-zip the downloaded folder to extract the files. The files include the JTAPI packages for Windows (32-bit and 64-bit), documentation, and sample code. Update the classpath variable. Go to Step 6. Step 4 Alternatively, run install32.bat or install64.bat depending on the platform . Follow the instructions mentioned in the scripts to install and update classpath. Step 5 After installation, go to the installed location. Step 6 Run the jtprefs.bat file. The Cisco Unified Communications Manager Jtapi Preferences <version number> Release dialog box is displayed. Note JTPrefs is an application, which provides a user interface to configure the jtapi.ini parameters. JTprefs is used to create the jtapi.ini file if one does not exist and to configure or modify the trace settings. In Windows, for example, the default directory is unzipped folder\CiscoJTAPIWindows\CiscoJTAPIx64\lib or unzipped folder\CiscoJTAPIWindows\CiscoJTAPIx32\lib. Verifying Windows Installation To verify the JTAPI Windows installation, you can use the makecall application that allows you to place a call via JTAPI. Perform the following steps to use the makecall application. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 225 Cisco Unified JTAPI Installation Verifying Windows Installation

Procedure Step 1 From the Windows command line, navigate to the directory where you installed Cisco Unified JTAPI Tools. By default, this directory is C:\ProgramFiles\JTAPITools (for 32 bit installers) and C:\ProgramFiles\JTAPI64Tools (for 64 bit installers). Step 2 Execute the following command: java CiscoJtapiVersion Step 3 Execute the following command: java makecall <server name> <login> <password> 1000 <phone1> <phone2> Note The server name variable specifies the hostname or IP address of the Cisco Unified Communications Manager (for example, 192.168.1.100 or Subscriber2). The phone1 and phone2 variables designate directory numbers of IP phones or virtual phones that the user controls according to the user configuration. Refer to the chapter ‘Directory Number Configuration’ in Cisco Unified Communications Manager Administration Guide for details. For the login and password variables, use the user ID and password that you configured in the Cisco Unified Communications Manager User Configuration window. Linux and Windows Installation Reinstall or Upgrade or Downgrade This feature provides a uniform install and uninstall procedure for the Cisco Unified JTAPI Client on Linux and Windows platforms. Starting from Release 11.5(1)SU9, Release 12.5(1), and any subsequent SU or ES releases, the Linux and Windows versions generate the zip file (.zip) which includes the JTAPI packages for Linux (32 and 64 bit) or Windows (32 and 64 bit), documentation, and sample codes. You can download the zip files (CiscoJTAPIWindows.zip or CiscoJTAPILinux.zip), by clicking the Download link available in the Cisco Unified CM Administration interface, Find and List Plugins window (Application > Plugins). From the Unified Communications Manager release 12.5(1) to the 14SU2 plugin URL, you can download the CiscoJ Libraries of Linux (32 and 64 bit): • https://<IP address>/plugins/lib_ciscoj_x32.zip • https://<IP address>/plugins/lib_ciscoj_x64.zip To reinstall or upgrade, replace the existing files with the newly extracted files downloaded from the Cisco Unified CM Administration interface. For more details, see the "Installation Procedure" chapter. To reinstall or downgrade or install the JTAPI version earlier to release 12.5(1), excluding 11.5(1)SU9 ESs and SU releases, refer to the "Cisco Unified JTAPI Installation chapter. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 226 Cisco Unified JTAPI Installation Linux and Windows Installation

To determine the JTAPI version for both Windows and Linux platforms, run the following command: • java CiscoJtapiVersion Using Cisco Unified CM JTAPI The following section describes the program group and program elements created by the installation of Cisco JTAPI. Program Group and Program Elements After the installation of Cisco JTAPI, a program group called CiscoJTAPI is created which contains the following elements: • Cisco Unified Communications Manager JTAPI Javadocs — Opens the Javadocs reference guide for Cisco JTAPI. • Cisco Unified Communications Manager JTAPI Preferences — Launches the JTAPI Preferences application. • ReadMe — Launches the readme.htm file in the default web browser. • Updater Javadocs — Opens the Javadocs Updater package that is bundled with Cisco JTAPI. Cisco Unified JTAPI Configuration Settings You can use the Cisco Unified JTAPI Preferences application to configure trace levels and trace destinations as well as several other system parameters. When using Windows 7 and Windows 2008 Server, you must run the JTAPI Preferences application in Administrative Mode when the User Access Control (UAC) service is running. If the UAC service is disabled, the JTAPI Preference application can run without administrative privileges. Note This section, which describes how to use the Cisco Unified JTAPI Preferences application, includes the following topics: • JTAPI Tracing Tab, on page 228 • Log Destination Tab, on page 229 • Cisco Unified CM Tab, on page 232 • Advanced Tab, on page 233 • Security Tab, on page 236 • Language Tab, on page 238 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 227 Cisco Unified JTAPI Installation Using Cisco Unified CM JTAPI

JTAPI Tracing Tab The JTAPI Tracing tab lets you change trace settings for the JTAPI layer. The following figure illustrates the JTAPI Tracing tab of the Cisco Unified JTAPI Preferences application. The window title shows the JTAPI version number. Figure 14: JTAPI Tracing Tab The JTAPI Tracing tab lets you enable or disable JTAPI trace levels as listed in the following table. Table 10: JTAPI Trace Levels Description Jtapi.ini fields Trace Levels Low-level warning events WARNING Status events INFORMATIONAL Highest level debugging events DEBUG Debug Levels Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 228 Cisco Unified JTAPI Installation JTAPI Tracing Tab

Description Jtapi.ini fields JTAPI methods and events trace JTAPI_DEBUGGING Internal JTAPI implementation trace JTAPIIMPL_DEBUGGING Trace Cisco Unified Communications Manager events that are sent to JTAPI CTI_DEBUGGING Internal CTICLIENT implementation trace CTIIMPL_DEBUGGING Full CTI protocol decoding PROTOCOL_DEBUGGING Miscellaneous low-level debug trace MISC_DEBUGGING Log Destination Tab The Log Destination tab allows you to configure how JTAPI creates traces and where they are stored. The following figure illustrates the Log Destination tab of the Cisco Unified JTAPI preferences application. The following table contains descriptions of the log destination fields. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 229 Cisco Unified JTAPI Installation Log Destination Tab

Figure 15: Log Destination Tab Table 11: Log Destination Fields Description Max Min Default Field name When this option is enabled, JTAPI alarms go to an alarm service that is running on the specified machine. You must specify the host name and port number when you enable this option. NA Not Applicable (NA) 0 Enable Alarm Service(UseAlarmService) When this option is enabled, traces go to a UDP port as specified in the Collector and Port Number fields. Syslog collector service collects traces and directs them to the Cisco Operations Manager Suite server. NA NA FALSE Use Syslog (UseSyslog) Alarm Service Settings Use this field to specify the host name of the alarm service server. NA NA Host Name Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 230 Cisco Unified JTAPI Installation Log Destination Tab

Description Max Min Default Field name Use this field to specify the host port of the alarm service server. NA NA Host Port Syslog Settings Use this field to specify the Syslog collector service that collects traces. NA NA 0 Collector Use this field to specify the UDP port of the collector. NA NA 514 Port Number This field allows you to direct traces to a specific path and folder. No fewer than two log files and no more than 99 files can exist. Cisco Unified JTAPI rotates through the log files in numerical order, returning to the first log file after filling the last. Log files increase in size in 1-megabyte increments. NA NA FALSE Use Rotating Log Files (SyslogCollector) When this option is enabled, tracing goes to the standard output or console (command) window. NA NA FALSE Use Java Console (UseSystemDotOut) Log File Settings This setting lets you specify the maximum number of log files to be written. 1000 2 10 Maximum Number of Log Files (NumTraceFiles) This setting lets you specify the maximum size of log files to be written. NP 1048576 1048576 Maximum Log File Size (TraceFileSize) This setting lets you specify whether the same folder name should be used for each instance of an application. When this option is enabled, JTAPI traces the log files to the same directory. In this case, successive instances of a JTAPI application will restart the log files, starting at index 01. When this option is disabled, each instance of the application, whether successive or simultaneous, will cause trace files to be placed in a new folder sequential to the last folder that was written. Cisco Unified JTAPI detects the last folder present in the trace path and automatically increments the numeric index. NA NA 1 Use the Same Directory (UseSameDirectory) This setting lets you specify the path name to which trace files are written. When the path is not specified, JTAPI defaults to the application path. NA NA . Trace Path (TracePath) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 231 Cisco Unified JTAPI Installation Log Destination Tab

Description Max Min Default Field name This setting lets you specify a folder name where the trace files will be contained. NA NA . Directory Name Base (Directory) Use this value to create the trace file name. NA NA Cisco Jtapi File Name Base (FileNameBase) This setting lets you specify a numerical index to append to the file base name indicates the order in which trace files are created. If you enter “jtapiTrace” in the File Name Base field and “log” in the File Name Extension field, the system names the trace files jtapiTrace01.log, jtapiTrace02.log, and so on. If the File Name Base and File Name Extension fields are left blank, JTAPI picks the trace files names as CiscoJtapi01.log, CiscoJtapi02.log, and so on. NA NA log File Name Extension (FileNameExtension) Cisco Unified CM Tab This tab allows you to define a list of IP addresses for Cisco Unified Communications Manager Subscribers where CTIManager is enabled. Applications can query JTAPI for this list and use it to find the IP addresses to connect to. You can define a maximum 10 IP addresses. The following figure illustrates the Cisco Unified CM tab of the preferences application. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 232 Cisco Unified JTAPI Installation Cisco Unified CM Tab

Figure 16: Cisco Unified CM Tab Advanced Tab You can configure the parameters in the table in this section through the Advanced tab in the JTAPI Preferences application. These low-level parameters are used for troubleshooting and debugging purposes only. The following figure illustrates the Advanced tab of the preferences application. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 233 Cisco Unified JTAPI Installation Advanced Tab

Figure 17: Advanced Tab Cisco strongly recommends that you not modify the parameters in the following table unless the Cisco Technical Assistance Center (TAC) instructs you to do so. Note Table 12: Advanced Configuration Fields Description Max Min Default Field Enables (or disables) a heartbeat in the internal message queue that JTAPI uses. If JTAPI has not received a message in the time that is defined in PeriodicWakeupInterval, it causes the thread to wake up and creates a log event. NA Not Applicable (NA) FALSE Enable Periodic Wakeup(PeriodicWakeupEnabled) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 234 Cisco Unified JTAPI Installation Advanced Tab

Description Max Min Default Field Allows you to define a period of inactivity in the JTAPI internal message thread (in seconds). If JTAPI has not received a message during this time, the thread wakes up and logs an event. NP Not Present (NP) 50 Periodic Wakeup Interval(PeriodicWakeupInterval) Causes JTAPI to log the max queue depth over the specified number of messages that are queued to JTAPI main event thread. For every x messages processed, JTAPI logs a DEBUGGING level trace that reports the maximum queue depth over that interval, where x represents the number of messages that are specified in Queue Size Threshold. NA NA FALSE (disabled) Enable Queue Stats(QueueStatsEnabled) Specifies the number of messages that define the interval over which JTAPI will report the maximum queue depth. NP 10 25 Queue Size Threshold(QueueSizeThreshold) Specifies the number of seconds that JTAPI will wait for a response from a CTI request. NP 10 15 CTI Request Timeout(CtiRequestTimeout) Specifies the number of seconds that JTAPI will wait for a response to a Provider Open Request. NP 10 200 Provider Open Request Timeout(ProviderOpenRequestTimeout) Specifies the number of seconds that JTAPI will retry opening connection to a Cisco Unified Communications Manager cluster in case of system failure. NP 5 30 Provider Retry Interval(ProviderRetryInterval) Specifies the interval at which the connection between JTAPI and the Cisco Unified Communications Manager cluster will get verified (in seconds). If JTAPI fails to receive heartbeats, it will establish a connection via the second CTIManager that is specified in the provider open request. NP

0 30 Server Heartbeat Interval(DesiredServerHeartbeatInterval) Specifies the interval in milliseconds that JTAPI will wait for the application to respond to the Route event. If the application does not respond in this time, JTAPI ends the route and sends the corresponding RouteEnd event. NP 0 5000 Route Select Timeout(RouteSelectTimeout) Specifies the timeout. NP 0 15 Post Condition Timeout Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 235 Cisco Unified JTAPI Installation Advanced Tab

Security Tab The following figure illustrates the Security tab of the preferences application. Figure 18: Security Tab Administrators need to configure the User Name, Instance ID, Authorization Code, TFTP Server IP-Address, and CAPF Server IP-Address parameters through the JTAPI Preferences application before invoking the JTAPI API or JTAPI Preferences to download/install certificates on the application server. You can use JTAPI Preferences to configure security profiles for one or more User Name/Instance ID pairs. If an application user has previously configured a security profile for a User Name/Instance ID pair, the security profile automatically populates when the user enters the User Name/Instance ID and clicks any of the other edit boxes. Apart from the GUI that is provided through JTAPI Preferences, an application can also install a client certificate by calling the interface that is provided at CiscoJtapiProperties. When Interface UpdateCertificate is called, the JTAPI client connects to the TFTP server to download the CTL file and extract certificates to the given certificate path. It then connects to the CAPF server to download the client certificate and installs it into the given certificate path. The jtapi.ini files store user security records in comma separated value (CSV) format. Semicolons separate individual records. An example of a users security record is as follows: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 236 Cisco Unified JTAPI Installation Security Tab

SecurityProperty = user, 123, 12345, 172.19.242.37, 3804, 172.19.242.37, 69, .\, true, false;<next record>; … You can configure the following parameters on the Security tab: Table 13: JTAPI Security Configuration Fields Description Max Min Default Field You can enable (or disable) tracing for certificate install operations by checking this check box and choosing the desired trace level. NA Not Applicable (NA) FALSE Enable Security Tracing(SecurityTraceEnabled) You can choose one of three different trace levels: • Error = 0 — Logs error events • Debug = 1 — Logs debugging events • Detailed = 2 — Logs all events 2 0 0 Select Trace Level(SecurityTraceLevel) If application users have previously configured a security profile for a User Name/Instance ID pair, that security profile automatically populates when the user enters the User Name/Instance ID and clicks any of the other edit boxes. NA NA NA User Name(Username) This field specifies the application instance identifier. If an application is connecting to CTIManager with the same user, it needs to define an instanceID for each instance of the application to download the certificate Authorization String. NA NA NA Instance ID(instanceID) This field specifies a one-time string that is used to download a certificate. NA NA NA Authentication String(authcode) This field specifies the IP address of the TFTP server (normally the Cisco Unified Communications Manager IP Address). NA NA NA TFTP Server IP Address The TFTP Server Port defaults to 69. Do not change this value unless the System Administrator advises you to do so. NP Not Present (NP) 69 TFTP Server Port This field specifies the IP address of the CAPF server in dotted decimal. NA NA NA CAPF Server IP Address Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 237 Cisco Unified JTAPI Installation Security Tab

Description Max Min Default Field The CAPF Server Port number defaults to 3804; however, you can also configure this number in the Cisco Unified Communications Manager Administration. Ensure that the value that is entered through the JTAPI Preferences matches the one that is configured in Cisco Unified Communications Manager Administration. NP NP 3804 CAPF Server Port This field specifies the path where the application wants server and client certificates to be installed. If this field is blank, the system installs certificates in the ClassPath of JTAPI.jar. NA NA JTAPI. jarlocation Certificate Path Check this option to enable a secure TLS connection to Cisco Unified Communications Manager. If this option is not checked, JTAPI cannot make a nonsecure connection to CTI even if the certificate is updated/installed. NA NA FALSE Enable Secure Connection This field provides information on whether the certificate has been updated. NA NA NA Certificate Update Status This button deletes the existing certificate. NA NA NA Delete Certificate This button updates the existing certificate with the changed parameters. NA NA NA Update Certificate Check this option to enable JTAPI to be FIPS compliant. NA NA FALSE FIPS Compliant Language Tab The following figure illustrates the Language tab of the preferences application. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 238 Cisco Unified JTAPI Installation Language Tab

Figure 19: Language Tab The Language tab allows you to select one of the installed languages to view the configuration settings in that language. You must install the language pack on the TFTP server before using this feature. Note You can select the following languages: Czech Croatian Chinese Taiwan Brazilian Portuguese Arabic French Finnish English Dutch Danish Italian Hungarian Hebrew Greek German Portuguese Polish Norwegian Nederlands Japanese Swedish Spanish Slovak Simplified Chinese Russian Select a language, and the tabs display with text in that language. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 239 Cisco Unified JTAPI Installation Language Tab

Managing the Cisco Unified CM JTAPI You can perform the following actions on all the Cisco JTAPI clients. Reinstalling, Upgrading or Downgrading the Cisco JTAPI Applicable from 11.5(1)SU9 and 12.5(1) ES and SU releases only. Use the following procedure to reinstall or upgrade or downgrade the Cisco JTAPI client on all supported platforms from release 12.5(1) and later versions. Before you begin To reinstall or upgrade the JTAPI version earlier to release 12.5(1), refer to the “Cisco Unified JTAPI Installation”. Note Procedure Step 1 Delete the contents of the previous zip folder present in the system and clear the classpath variables . Alternatively, you can run the Uninstall Script present in the installed folder to delete the files and update classpath. Step 2 Click Download link to download the required JTAPI client from the Unified Communications Manager Administrative interface Plugins page (Application > Plugins). Save the zipped file on the CTI application. Step 3 Un-zip the downloaded folder to extract the files . Manually update the classpath variables. Additionally, you can run the Install Script present in the extracted folder to install Cisco JTAPI and update the classpath. Note You can keep a copy of the jtapi.ini file present in [{Unzip Location}\lib\jtapi.ini ] location and replace the same in the newly extracted Zip folder if you want to keep the previous Jtapi settings. It is applicable only for upgrading/downgrading/reinstallation.l In Linux Machines, after uninstallation the session must be logged out and logged in again for the changes to take effect. Uninstalling the Cisco JTAPI Uninstalling the Cisco JTAPI To remove the JTAPI version release 12.5(1), delete the folder (CiscoJTAPIWindows or CiscoJTAPILinux) and its extracted files from the system. 1. Delete the contents of the previous zip folder present in the system and clear the classpath variables. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 240 Cisco Unified JTAPI Installation Managing the Cisco Unified CM JTAPI

You can also run the Uninstall Script present in the extracted folder to delete the files and update classpath. Run uninstall32.bat or uninstall32.sh for 32-bit machines and uninstall64.bat or uninstall64.sh for 64-bit machines. 3. Follow the instructions mentioned in the script. To uninstall the JTAPI version earlier to release 12.5(1), refer to the “Cisco Unified JTAPI Installation” chapter of the Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 11.5(1), at https://www.cisco.com/c/en/us/support/unified-communications/ unified-communications-manager-callmanager/products-programming-reference-guides-list.html. Administering User Information for JTAPI Applications The JTAPI application requires that users be given the privilege to control one or more devices. Follow the procedures for adding an application user and assigning devices to an application user in the “Application user setup” chapter of the Cisco Unified Communications Manager Administration Guide before using the JTAPI application. The list of devices that are assigned to the user represents the phones that the user needs to control from the application (for example, make calls and answer calls). Fields in the jtapi.ini File Applications that run in non-GUI-based platforms, where the JTAPI Preferences application cannot be invoked, can write their own jtapi.ini file and place it along with jtapi.jar based on the values that are provided here. JTAPI will make use of these values. Applications should ensure that they provide valid data as described in the following table. Applications are responsible for errors that are caused in JTAPI behavior due to improper jtapi.ini file values. Table 14: Fields in jtapi.ini File Description Max Min Default Jtapi.ini fields This field specifies status events NA Not Applicable (NA) 0 INFORMATIONAL This field specifies highest level debugging events NA NA 0 DEBUG This field specifies low-level warning events NA NA 0 WARNING This field specifies JTAPI methods and events trace NA NA 0 JTAPI_DEBUGGING This field specifies internal JTAPI implementation trace NA NA 0 JTAPIIMPL_DEBUGGING This field specifies trace Cisco Unified Communications Manager events that are sent to the JTAPI implementation NA NA 0 CTI_DEBUGGING Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 241 Cisco Unified JTAPI Installation Administering User Information for JTAPI Applications

Description Max Min Default Jtapi.ini fields This field specifies internal CTICLIENT implementation trace NA NA 0 CTIIMPL_DEBUGGING This field specifies full CTI protocol decoding NA NA 0 PROTOCOL_DEBUGGING This field specifies miscellaneous low-level debug trace NA NA 0 MISC_DEBUGGING This field specifies how often, in seconds, the connection between JTAPI and the Cisco Unified Communications Manager cluster will be verified. If JTAPI fails to receive heartbeats, it will establish a connection via the second CTIManager that is specified in the provider open request. Not Present (NP)

0 30 DesiredServerHeartbeatInterval This field specifies the path name to which the trace files are written. When the path is not specified, JTAPI makes the application path as the default. NA NA . TracePath This field specifies a numerical index that is appended to the file base name to indicate the order in which the files are created. For example, if you enter jtapiTrace in the File Name Base field and log in the File Name Extension field, the trace files would rotate between jtapiTrace01.log, jtapiTrace02.log, and jtapiTrace10.log. If the File Name Base and File Name Extension fields are left blank, Cisco Unified JTAPI picks the trace files names as CiscoJtapi01.log, CiscoJtapi02.log, and so on. NA NA log FileNameExtension This field specifies you to direct the traces to a specific path and folder in the system. No fewer than two log files and no more than 99 files can exist. Cisco Unified JTAPI rotates through the log files in numerical order, and returns to the first log file after filling the last. Log files increase in size in 1-megabyte increments. NA NA FALSE SyslogCollector This field allows you to specify the maximum size of log files to be written. NP 1048576 1048576 TraceFileSize Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 242 Cisco Unified JTAPI Installation Fields in the jtapi.ini File

Description Max Min Default Jtapi.ini fields When this option is enabled, JTAPI alarms go to an alarm service that is running on the specified machine. Specify the host name and port number if you enable this option. NA NA 0 UseAlarmService This field specifies the time in seconds that JTAPI will wait for a response for the Provider Open Request. The default is 10 seconds. NP 10 200 ProviderOpenRequestTimeout JTAPI has post conditions for events, and if the post condition is not met before a timeout, JTAPI will throw exceptions. Use this field to set the timeout value of such conditions. 20 10 15 JtapiPostConditionTimeout This field prioritizes multiple provider open requests. Currently, JTAPI only sends a default value. NA NA 2 ApplicationPriority This field enables tracing for security-related messages. You can enable (or disable) tracing for certificate install operations by selecting this check box and selecting the desired trace level. NA NA FALSE SecurityTraceEnabled This field is used for sending alarms to a different server. Users can select the alarm server host name and port on which the service is running, and JTAPI will send the alarms to the specified server and port. NP NP 1444 AlarmServicePort This field displays the alarm server host name. NA NA null AlarmServiceHostname This field specifies the time, in milliseconds, that JTAPI waits for the application to respond to the Route event. If the application does not respond in this time, JTAPI ends the route and sends the corresponding RouteEnd event. NP 0 5000 RouteSelectTimeout This field specifies the time, in seconds, that JTAPI will retry opening a connection to the Cisco Unified Communications Manager cluster in case of system failure. NP 5 30 ProviderRetryInterval Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 243 Cisco Unified JTAPI Installation Fields in the jtapi.ini File

Description Max Min Default Jtapi.ini fields This field is used by JTAPI to log the max queue depth over the specified number of messages that are queued to JTAPI main event thread. In other words, for every x messages processed, JTAPI logs a DEBUGGING level trace that reports the maximum queue depth over that interval, where x represents the number of messages that are specified in Queue Size Threshold. NA NA FALSE QueueStatsEnabled This field specifies a value to create the trace file name. NA NA CiscoJtapi FileNameBase This field enables (or disables) a heartbeat in the internal message queue that JTAPI uses. If JTAPI has not received a message in the time that is defined in PeriodicWakeupInterval, it causes the thread to wake up and creates a log event. NA NA FALSE PeriodicWakeupEnabled This field specifies the Port through which the JTAPI parameter changes are communicated to JTAPI applications during runtime. NP 1 2789 JTAPINotificationPort This field allows you to define a time of inactivity in the JTAPI internal message thread. If JTAPI does not received a message during this time, the thread wakes up and logs an event. NP NP 50 PeriodicWakeupInterval This field allows you to specify the number of messages that define the time over which JTAPI will report the maximum queue depth. NP 10 25 QueueSizeThreshold This field is used to display traces on the console. NA NA FALSE UseSystemDotOut Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 244 Cisco Unified JTAPI Installation Fields in the jtapi.ini File

Description Max Min Default Jtapi.ini fields This field allows you to specify whether the same folder name must be used for each instance of an application. When this option is enabled, JTAPI traces the log files to the same directory. In this case, successive instances of a JTAPI application will restart the log files, starting at index 01. When this option is disabled, each instance of the application, whether successive or simultaneous, will cause the trace files to be placed in a new folder sequential to the last folder that was written. Cisco Unified JTAPI detects the last folder in the trace path and automatically increments the numeric index. NA NA 1 UseSameDirectory This field allows you to specify the maximum number of log files to be written. 1000 2 10 NumTraceFiles This field, when enabled, allows the traces go to a UDP port as specified in the Collector and Port Number fields. Syslog collector service collects traces and directs them to the Cisco Operations Manager Suite server. NA NA FALSE UseSyslog This field specifies trace level for security messages 0 = Error, 1 = debug, 2 = detailed 2 0 0 SecurityTraceLevel This field enables the writing of logs to logFile Trace Writer. NA NA TRUE UseTraceFile This field specifies the feature ID that is assigned to the application. Cisco Unified Communications Manager preassigns this ID. NA NA 0 CMAssignedAppID This field specifies the list of CTI Managers for which tracing needs to be collected. NA NA null CtiManagers This field allows you to specify a folder name where the trace files will be contained. NA NA . Directory This field specifies the minimum TLS protocol version used by JTAPI when establishing secure communication to the CTIManager or CAPF service. 3 0 0 MinimumTLSVersion Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 245 Cisco Unified JTAPI Installation Fields in the jtapi.ini File

Description Max Min Default Jtapi.ini fields This field specifies the users security record (username, instanceId, authcode, tftp ip address, tftp port, capf ip address, capf port, certificate path, security option, certificate status, fips compliance), that will be stored in jtapi.ini files in a comma separated string. A semicolon separates the records. SecurityProperty = user, 123, 12345, 172.19.242.37, 3804, 172.19.242.37, 69, .\, true, false, false; <next record>;… NA NA NA Security Property SecurityProperty = username, instanceId, authcode, tftp ip address, tftp port, capf ip address, capf port, certificate path, security option, certificate status, fips compliant Security Property Entries This field automatically populates the security profile of an application user who has previously configured a User Name/Instance ID pair and clicks any of the other edit boxes. NA NA NA Username This field specifies the application instance identifier. If an application is connecting to CTIManager with the same user, it needs to define an Instance ID for each instance of the application to download the certificate Authorization String. NA NA NA instanceId This field specifies authorization string that is configured in the Cisco Unified Communications Manager database. This can be used only once for getting certificate. NA NA NA authcode This field specifies the TFTP Address of Cisco Unified Communications Manager (normally, the Cisco Unified Communications Manager IP Address) NA NA NA Communications Manager TFTP IP address This field displays the default value of the CallManager TFTP port.Do not change the default value of 69 unless advised to do so by the System Administrator. NP NP 69 CallManager TFTP port This field specifies CAPF Server IP Address NA NA NA Communications Manager CAPF IP server address Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 246 Cisco Unified JTAPI Installation Fields in the jtapi.ini File

Description Max Min Default Jtapi.ini fields This field displays the default value (3804) for CAPF server port. Be aware, you can configure this value in Cisco Unified Communications Manager Administration service parameters. Ensure that the value you enter through this interface should match the value configured on Cisco Unified Communications Manager Administration window. NP NP 3804 Communications Manager CAPF server port This field specifies the location where application wants sever and client certificates to be installed. If this field is left blank, the system installs certificates in the ClassPath of JTAPI.jar NA NA JTAPI.jar location Certificate path This field, if set to TRUE then JTAPI will make a nonsecure connection to CTI even if certificates are updated/installed. NA NA TRUE Enable secure connection The JTAPI Preferences dialog box is used to configure the security profile for one or more User Name/Instance ID pairs. NA NA NA Certificate Update Status This field, if set to TRUE, will enable the use of FIPS-compliant cryptography algorithms and libraries in JTAPI. NA NA FALSE FIPS Compliance Sample jtapi.ini File with Default Values #Cisco Unified JTAPI version 7.0(1.1000)-1 Release ini parameters #Wed Sep 14 16:55:30 PDT 2008 INFORMATIONAL = 0 DesiredServerHeartbeatInterval = 30 TracePath = . FileNameExtension = log SyslogCollector = TraceFileSize = 1048576 UseAlarmService = 0 ProviderOpenRequestTimeout = 200 JtapiPostConditionTimeout = 15 ApplicationPriority = 2 SecurityTraceEnabled = 0 AlarmServicePort = 1444 RouteSelectTimeout = 5000 ProviderRetryInterval = 30 QueueStatsEnabled = 0 FileNameBase = CiscoJtapi JTAPI_DEBUGGING = 0 PeriodicWakeupEnabled = 0 CTI_DEBUGGING = 0 JTAPINotificationPort = 2789 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 247 Cisco Unified JTAPI Installation Sample jtapi.ini File with Default Values

Traces = WARNING;INFORMATIONAL;DEBUG PeriodicWakeupInterval = 50 AlarmServiceHostname = QueueSizeThreshold = 25 Debugging = JTAPI_DEBUGGING;JTAPIIMPL_DEBUGGING;CTI_DEBUGGING;CTIIMPL_DEBUGGING; PROTOCOL_DEBUGGING;MISC_DEBUGGING PROTOCOL_DEBUGGING = 0 UseSystemDotOut = 0 MISC_DEBUGGING = 0 UseSameDirectory = 1 NumTraceFiles = 10 UseSyslog = 0 DEBUG = 0 SecurityTraceLevel = 0 UseTraceFile = 1 WARNING = 0 CMAssignedAppID = 0 UseProgressAsDisconnectedDuringErrorEnabled = 0 CtiManagers = ;;;;;;;;; Directory = CTIIMPL_DEBUGGING = 0 CtiRequestTimeout = 30 JTAPIIMPL_DEBUGGING = 0 SyslogCollectorUDPPort = 514 SecurityProperty = cisco, 123, 12345, A.B.C.D, 3804, A.B.C.D, 69, /C:/Program Files/JTAPITools/./, false, false; Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 248 Cisco Unified JTAPI Installation Sample jtapi.ini File with Default Values

C H A P T E R 5 Cisco Unified JTAPI Extensions The Cisco Unified JTAPI extension consists of a set of classes and interfaces that expose the additional functionality not readily exposed in JTAPI 1.2 specification but are available in Cisco Unified Communications Manager. Developers can use the extensions to create new applications or modify existing extensions to create new methods. This chapter describes the extensions (interfaces and classes) that are available for implementation in a Cisco Unified Communications Manager. • Class Hierarchy, on page 253 • CiscoAddressCallInfo, on page 253 • CiscoG711MediaCapability, on page 255 • CiscoG723MediaCapability, on page 256 • CiscoG729MediaCapability, on page 258 • CiscoGSMMediaCapability, on page 259 • CiscoJtapiVersion, on page 261 • CiscoMediaCapability, on page 262 • CiscoMultiMediaCapabilityInfo, on page 264 • CiscoRegistrationException, on page 265 • CiscoRTPParams, on page 267 • CiscoUnregistrationException, on page 268 • CiscoWideBandMediaCapability, on page 269 • Interface Hierarchy, on page 271 • CiscoAddrActivatedEv, on page 277 • CiscoAddrActivatedOnTerminalEv, on page 281 • CiscoAddrAddedToTerminalEv, on page 283 • CiscoAddrAutoAcceptStatusChangedEv, on page 284 • CiscoAddrCreatedEv, on page 286 • CiscoAddrMonitorTerminatedEv, on page 288 • CiscoAddress, on page 289 • CiscoAddressObserver, on page 303 • CiscoAddrEv, on page 304 • CiscoAddrEvFilter, on page 305 • CiscoAddrInServiceEv, on page 308 • CiscoAddrIntercomInfoChangedEv, on page 310 • CiscoAddrIntercomInfoRestorationFailedEv, on page 311 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 249

• CiscoAddrPickupGroupChangedEv, on page 313 • CiscoAddrOutOfServiceEv, on page 314 • CiscoAddrParkStatusEv, on page 316 • CiscoAddrRecordingConfigChangedEv, on page 318 • CiscoAddrRemovedEv, on page 319 • CiscoAddrRemovedFromTerminalEv, on page 321 • CiscoAddrRestrictedEv, on page 323 • CiscoAddrRestrictedOnTerminalEv, on page 325 • CiscoAddrVoiceMailPilotChangedEv, on page 326 • CiscoAnnouncementStartedEv, on page 328 • CiscoAnnouncementEndedEv, on page 328 • CiscoAnnouncementErrorEv, on page 329 • CiscoBaseMediaTerminal, on page 329 • CiscoCall, on page 332 • CiscoCallChangedEv, on page 345 • CiscoCallConsultCancelledEv, on page 349 • CiscoCallCtlConnOfferedEv, on page 350 • CiscoCallCtlTermConnHeldReversionEv, on page 352 • CiscoCallEv, on page 354 • CiscoCallFeatureCancelledEv, on page 365 • CiscoCallID, on page 366 • CiscoMediaCallSecurityIndicator, on page 367 • CiscoCallSecurityStatusChangedEv, on page 368 • CiscoConferenceChain, on page 371 • CiscoConferenceChainAddedEv, on page 372 • CiscoConferenceChainRemovedEv, on page 375 • CiscoConferenceEndEv, on page 378 • CiscoConferenceStartEv, on page 382 • CiscoConnection, on page 386 • CiscoConnectionID, on page 398 • CiscoConnectionUniqueIDChangedEv, on page 399 • CiscoConsultCall, on page 400 • CiscoConsultCallActiveEv, on page 403 • CiscoEv, on page 407 • CiscoFeatureReason, on page 408 • CiscoHuntConnection, on page 411 • CiscoIntercomAddress, on page 411 • CiscoIsacMediaCapability, on page 415 • CiscoJtapiException, on page 416 • CiscoMediaStreamStartedEv, on page 431 • CiscoMediaStreamEndedEv, on page 432 • CiscoJtapiPeer, on page 433 • CiscoJtapiPeerImpl, on page 434 • CiscoJtapiProperties, on page 435 • CiscoLocales, on page 442 • CiscoMasterKeyIndicator, on page 445 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 250 Cisco Unified JTAPI Extensions

• CiscoMediaConnectionMode, on page 445 • CiscoMediaEncryptionAlgorithmType, on page 446 • CiscoMediaEncryptionKeyInfo, on page 447 • CiscoMediaOpenIPPortEv, on page 448 • CiscoMediaOpenLogicalChannelEv, on page 449 • CiscoMediaSecurityIndicator, on page 453 • CiscoMediaTerminal, on page 454 • CiscoMonitorInitiatorInfo, on page 465 • CiscoMonitorTargetInfo, on page 466 • CiscoMultiForkingRecorderInfo, on page 467 • CiscoMultiMediaCapabilityInfo, on page 468 • CiscoMultiMediaConnectionMode, on page 470 • CiscoMultiMediaEncryptionKeyInfo, on page 470 • CiscoMultiMediaProperties, on page 471 • CiscoMultiMediaStreamsInfoEv, on page 472 • CiscoMultiMediaType, on page 473 • CiscoObjectContainer, on page 474 • CiscoOutOfServiceEv, on page 475 • CiscoPartyInfo, on page 476 • CiscoPickupGroup, on page 478 • CiscoProvCallParkEv, on page 479 • CiscoProvEv, on page 481 • CiscoProvFeatureEv, on page 483 • CiscoProvFeatureID, on page 485 • CiscoProvPickupCallAlertEv, on page 487 • CiscoProvTerminalIPAddressChangedEv, on page 488 • CiscoProvTerminalMultiMediaCapabilityChangedEv, on page 489 • CiscoProvTerminalRegisteredEv, on page 490 • CiscoProvTerminalUnRegisteredEv, on page 491 • CiscoProvider, on page 492 • CiscoProviderCapabilities, on page 504 • CiscoProviderCapabilityChangedEv, on page 506 • CiscoProviderObserver, on page 508 • CiscoProvTerminalCapabilityChangedEv, on page 509 • CiscoProvTerminalRemoteDestinationChangedEv, on page 511 • CiscoRecorderInfo, on page 511 • CiscoRemoteDestinationInfo, on page 513 • CiscoRemoteTerminal, on page 514 • CiscoRestrictedEv, on page 519 • CiscoRouteAddress, on page 521 • CiscoRouteEvent, on page 522 • CiscoRouteSession, on page 523 • CiscoRouteTerminal, on page 542 • CiscoRouteUsedEvent, on page 551 • CiscoRTPBitRate, on page 552 • CiscoRTPHandle, on page 553 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 251 Cisco Unified JTAPI Extensions

• CiscoRTPInputKeyEv, on page 554 • CiscoRTPInputProperties, on page 556 • CiscoRTPInputStartedEv, on page 557 • CiscoRTPInputStoppedEv, on page 559 • CiscoRTPOutputKeyEv, on page 561 • CiscoRTPOutputProperties, on page 563 • CiscoRTPOutputStartedEv, on page 565 • CiscoRTPOutputStoppedEv, on page 567 • CiscoRTPOutputKeyEv, on page 569 • CiscoRTPOutputProperties, on page 571 • CiscoRTPOutputStartedEv, on page 572 • CiscoRTPOutputStoppedEv, on page 575 • CiscoRTPPayload, on page 577 • CiscoRTPProperties, on page 578 • CiscoSynchronousObserver, on page 580 • CiscoTermActivatedEv, on page 581 • CiscoTermButtonPressedEv, on page 582 • CiscoTermConnMonitoringEndEv, on page 584 • CiscoTermConnMonitoringStartEv, on page 586 • CiscoTermConnMonitorInitiatorInfoEv, on page 587 • CiscoTermConnMonitorTargetInfoEv, on page 589 • CiscoTermConnPrivacyChangedEv, on page 591 • CiscoTermConnRecordingEndEv, on page 591 • CiscoTermConnRecordingStartEv, on page 593 • CiscoTermConnRecordingTargetInfoEv, on page 594 • CiscoTermConnRecordingFailedEv, on page 595 • CiscoTermConnSelectChangedEv, on page 596 • CiscoTermCreatedEv, on page 598 • CiscoTermDataEv, on page 599 • CiscoTermDeviceStateActiveEv, on page 601 • CiscoTermDeviceStateAlertingEv, on page 602 • CiscoTermDeviceStateHeldEv, on page 604 • CiscoTermDeviceStateIdleEv, on page 606 • CiscoTermDeviceStateWhisperEv, on page 607 • CiscoTermDNDOptionChangedEv, on page 609 • CiscoTermDNDStatusChangedEv, on page 610 • CiscoTermEv, on page 612 • CiscoTermEvFilter, on page 614 • CiscoTerminal, on page 617 • CiscoTerminalConnection, on page 636 • CiscoTerminalObserver, on page 643 • CiscoTerminalProtocol, on page 643 • CiscoTermInServiceEv, on page 644 • CiscoTermOutOfServiceEv, on page 647 • CiscoTermRegistrationFailedEv, on page 648 • CiscoTermRemovedEv, on page 651 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 252 Cisco Unified JTAPI Extensions

• CiscoTermRestrictedEv, on page 653 • CiscoTermSnapshotCompletedEv, on page 654 • CiscoTermSnapshotEv, on page 656 • CiscoTone, on page 658 • CiscoToneChangedEv, on page 659 • CiscoTransferEndEv, on page 662 • CiscoTransferStartEv, on page 665 • CiscoUrlInfo, on page 669 • ComponentUpdater, on page 670 • ProviderPickupNotificationRegistrationClosedEv, on page 671 • CiscoTermHuntLogStatusChangedEv, on page 672 • CiscoProvConnToLeastPriorCtiServerEv, on page 672 • CiscoProvFallbackToPrimNwCompltdEv, on page 673 • CiscoProvPrimNwReachableEv, on page 674 Class Hierarchy The following class hierarchy is contained in the com.cisco.jtapi.extensions package. hierarchy.java.lang.Object com.cisco.jtapi.extensions.CiscoAddressCallInfo com.cisco.jtapi.extensions.CiscoJtapiVersion com.cisco.jtapi.extensions.CiscoMediaCapability com.cisco.jtapi.extensions.CiscoG711MediaCapability com.cisco.jtapi.extensions.CiscoG723MediaCapability com.cisco.jtapi.extensions.CiscoG729MediaCapability com.cisco.jtapi.extensions.CiscoGSMMediaCapability com.cisco.jtapi.extensions.CiscoWideBandMediaCapability com.cisco.jtapi.extensions.CiscoRTPParams java.lang.Throwable (implements java.io.Serializable) java.lang.Exception com.cisco.jtapi.extensions.CiscoRegistrationException com.cisco.jtapi.extensions.CiscoUnregistrationException CiscoAddressCallInfo Class History Description Cisco Unified Communications Manager Release Added the history table to track changes. 7.1 (2) Declaration public class CiscoAddressCallInfo extends java.lang.Object java.lang.Object com.cisco.jtapi.extensions.CiscoAddressCallInfo Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 253 Cisco Unified JTAPI Extensions Class Hierarchy

Constructors CiscoAddressCallInfo (int inumActiveCalls, int imaxActiveCalls, int inumCallsOnHold, int imaxCallsOnHold) CiscoAddressCallInfo (int inumActiveCalls, int imaxActiveCalls, int inumCallsOnHold, int imaxCallsOnHold, CiscoCall[] icalls) Fields None Methods Table 15: Methods in CiscoAddressCallInfo Description Method Interface Returns the array of Cisco calls on the CiscoAddress. getCalls() CiscoCall[] Returns the terminal on which the address got activated (i.e. marked unrestricted) getTerminal() CiscoCall[] Returns the maximum number of active calls supported on the CiscoAddress, as an integer. getMaxActiveCalls() int Returns the maximum number of calls that can be put on hold on the CiscoAddress, as an integer. getMaxCallsOnHold() int Returns the number of active calls on the CiscoAddress, as an integer. getNumActiveCalls() int Returns the number of held calls on the CiscoAddress, as an integer. getNumCallsOnHold() int Inherited Methods From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait Related Documentation None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 254 Cisco Unified JTAPI Extensions Constructors

CiscoG711MediaCapability The CiscoG711MediaCapability object specifies the properties for a G.711 encoded RTP stream. Applications that support G.711 media termination use this object to specify their preferred packet size when registering a CiscoMediaTerminal. The default packet size is thirty milliseconds. Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1(x) Declaration public class CiscoG711MediaCapability extends CiscoMediaCapability java.lang.Object com.cisco.jtapi.extensions.CiscoMediaCapability com.cisco.jtapi.extensions.CiscoG711MediaCapability Constructors Table 16: Constructors in CiscoG711MediaCapability Description Constructor Interface Constructs a CiscoG711MediaCapability. CiscoG711MediaCapability(intrtpPacketFrameSize) public Constructs a CiscoG711MediaCapability. CiscoG711MediaCapability() public Fields Table 17: Fields in CiscoG711MediaCapability Description Field Interface RTP Packet Framesize: Twenty millisecond RTP packet. FRAMESIZE_TWENTY_MILLISECOND_PACKET public static final int RTP Packet Framesize: Thirty millisecond RTP packet. FRAMESIZE_THIRTY_MILLISECOND_PACKET public static final int RTP Packet Framesize: Sixty millisecond RTP packet. FRAMESIZE_SIXTY_MILLISECOND_PACKET public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 255 Cisco Unified JTAPI Extensions CiscoG711MediaCapability

Inherited Fields From Class com.cisco.jtapi.extensions.CiscoMediaCapability G711_64K_30_MILLISECONDS, G723_6K_30_MILLISECONDS, G729_30_MILLISECONDS, GSM_80_MILLISECONDS, WIDEBAND_256K_10_MILLISECONDS Methods None Inherited Methods From Class com.cisco.jtapi.extensions.CiscoMediaCapability getMaxFramesPerPacket, getPayloadType, isSupported, toString From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation See Constant Field Values, on page 1667. CiscoG723MediaCapability The CiscoG723MediaCapability object specifies the properties for a G.723 encoded RTP stream. Applications that support G.723 media termination use this object to specify their preferred packet size and bit rate when registering a CiscoMediaTerminal. The default packet size is thirty milliseconds and the default bit rate is 6.4k. Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1x Declaration public class CiscoG723MediaCapability extends CiscoMediaCapability java.lang.Object com.cisco.jtapi.extensions.CiscoMediaCapability com.cisco.jtapi.extensions.CiscoG723MediaCapability Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 256 Cisco Unified JTAPI Extensions Inherited Fields

Constructors Table 18: Constructors in CiscoG723MediaCapability Description Constructor Interface Constructs a CiscoG723MediaCapability. CiscoG723MediaCapability (intrtpPacketFrameSize, intbitRate) public Fields Table 19: Fields in CiscoG723MediaCapability Description Field Interface RTP Packet Framesize: Twenty millisecond RTP packet. FRAMESIZE_TWENTY_MILLISECOND_PACKET public static final int RTP Packet Framesize: Thirty millisecond RTP packet. FRAMESIZE_THIRTY_MILLISECOND_PACKET public static final int RTP Packet Framesize: Sixty millisecond RTP packet. FRAMESIZE_SIXTY_MILLISECOND_PACKET public static final int Inherited Fields From Class com.cisco.jtapi.extensions.CiscoMediaCapability G711_64K_30_MILLISECONDS, G723_6K_30_MILLISECONDS, G729_30_MILLISECONDS, GSM_80_MILLISECONDS, WIDEBAND_256K_10_MILLISECONDS Methods Table 20: Methods in CiscoG723MediaCapability Description Method Interface Returns the bit rate specified by this capability object. Returns: a bit rate from the RTPBitRate interface. getBitRate() public int Overwrites the Object.toString() method. Overrides: toString in class CiscoMediaCapability. toString() public java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 257 Cisco Unified JTAPI Extensions Constructors

Inherited Methods From Class com.cisco.jtapi.extensions.CiscoMediaCapability getMaxFramesPerPacket, getPayloadType, isSupported From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation See Constant Field Values, on page 1667. CiscoG729MediaCapability The CiscoG729MediaCapability object specifies the properties for a G.729 encoded RTP stream. Applications that support G.729 media termination use this object to specify their preferred packet size when registering a CiscoMediaTerminal. The default packet size is thirty milliseconds. Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1x Declaration public class CiscoG729MediaCapability extends CiscoMediaCapability java.lang.Object com.cisco.jtapi.extensions.CiscoMediaCapability com.cisco.jtapi.extensions.CiscoG729MediaCapability Constructors Table 21: Constructors in G729MediaCapability Description Constructor Constructs a CiscoG729MediaCapability. CiscoG729MediaCapability(int payload, int rtpPacketFrameSize) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 258 Cisco Unified JTAPI Extensions Inherited Methods

Fields Table 22: Fields in CiscoG729MediaCapability Description Fields Interface RTP Packet Framesize: Sixty millisecond RTP packet. FRAMESIZE_SIXTY_MILLISECOND_PACKET staticint RTP Packet Framesize: Thirty millisecond RTP packet. FRAMESIZE_THIRTY_MILLISECOND_PACKET staticint RTP Packet Framesize: Twenty millisecond RTP packet. FRAMESIZE_TWENTY_MILLISECOND_PACKET staticint Inherited Fields From Class com.cisco.jtapi.extensions.CiscoMediaCapability G711_64K_30_MILLISECONDS, G723_6K_30_MILLISECONDS, G729_30_MILLISECONDS, GSM_80_MILLISECONDS, WIDEBAND_256K_10_MILLISECONDS Methods None Inherited Methods From Class com.cisco.jtapi.extensions.CiscoMediaCapability getMaxFramesPerPacket, getPayloadType, isSupported, toString From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation See Constant Field Values, on page 1667. CiscoGSMMediaCapability The CiscoGSMMediaCapability object specifies the properties for a GSM encoded RTP stream. Applications that support GSM media termination use this object to specify their preferred packet size when registering a CiscoMediaTerminal. The default packet size is thirty milliseconds. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 259 Cisco Unified JTAPI Extensions Fields

Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1x Declaration public class CiscoGSMMediaCapability extends CiscoMediaCapability java.lang.Object com.cisco.jtapi.extensions.CiscoMediaCapability com.cisco.jtapi.extensions.CiscoGSMMediaCapability Constructors Table 23: Constructors in CiscoGSMMediaCapability Description Constructor Interface Constructs a CiscoGSMMediaCapability CiscoGSMMediaCapability() public Constructs a CiscoGSMMediaCapability. CiscoGSMMediaCapability(int rtpPacketFrameSize) public Fields Table 24: Fields in CiscoGSMMediaCapability Description Field Interface RTP Packet Framesize: Eighty millisecond RTP packet FRAMESIZE_EIGHTY_MILLISECOND_PACKET staticint Inherited Fields From Class com.cisco.jtapi.extensions.CiscoMediaCapability G711_64K_30_MILLISECONDS, G723_6K_30_MILLISECONDS, G729_30_MILLISECONDS, GSM_80_MILLISECONDS, WIDEBAND_256K_10_MILLISECONDS Methods None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 260 Cisco Unified JTAPI Extensions Declaration

Inherited Methods From Class com.cisco.jtapi.extensions.CiscoMediaCapability getMaxFramesPerPacket, getPayloadType, isSupported, toString From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation None CiscoJtapiVersion This class gives the version information of the installed Cisco JTAPI. Programs can get the version number using the accessor methods. Cisco Jtapi Version is in a.b(x.y) format where “a” indicates the major version, “b” indicates the minor version, “x” indicates the revision number, and “y” indicates the build number . Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1x Declaration public class CiscoJtapiVersion extends java.lang.Object java.lang.Object com.cisco.jtapi.extensions.CiscoJtapiVersion Constructors publicCiscoJtapiVersion()None Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 261 Cisco Unified JTAPI Extensions Inherited Methods

Methods Table 25: Methods in CiscoJtapiVersion Description Method Interface Returns “release” if it is a release version or debug if it is not a release version. getBuildDescription() java.lang.String Returns the build number of the version. getBuildNumber() int Returns the extended build number of the version. getExtendedBuildNumber() int Returns the major version number. getMajorVersion() int Returns the minor version number. getMinorVersion() int Returns the revision number of the version. getRevisionNumber() int Returns the version information in a.b(x.y)-z format without a name. getVersion() public java.lang.String Returns the version information in a.b(x.y)-z format. Overrides toString in class java.lang.Object. toString() public java.lang.String Inherited Methods From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation None CiscoMediaCapability The CiscoMediaCapability object specifies the properties of a particular media format that an application can support for CiscoMediaTerminals that it registers. Because CiscoMediaCapability is an abstract class, applications may only construct its subclasses directly. Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1x Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 262 Cisco Unified JTAPI Extensions Methods

Declaration public class CiscoMediaCapability extends java.lang.Object java.lang.Object com.cisco.jtapi.extensions.CiscoMediaCapability Subclasses CiscoG711MediaCapability, CiscoG723MediaCapability, CiscoG729MediaCapability, CiscoGSMMediaCapability, CiscoWideBandMediaCapability Constructors Table 26: Constructors in CiscoMediaCapability Description Constructor Interface Constructs a CiscoMediaCapability object for the specified payload type and packet size (in milliseconds). CiscoMediaCapability(intpayloadType, intmaxFramesPerPacket) public Fields Table 27: Fields in CiscoMediaCapability Description Field Interface G.711 capability with default parameters. G711_64K_30_MILLISECONDS static G.723 capability with default parameters. G723_6K_30_MILLISECONDS static G.729 capability with default parameters. G729_30_MILLISECONDS static GSM capability with default parameters. GSM_80_MILLISECONDS static Wideband capability with default parameters. WIDEBAND_256K_10_MILLISECONDS static Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 263 Cisco Unified JTAPI Extensions Declaration

Methods Table 28: Methods in CiscoMediaCapability Description Method Interface Returns the packet size (in milliseconds) that this object specifies.The maxFramesPerPacket parameter is a carryover from the H.245 protocol definition. Cisco Unified Communications Manager does not use this field as the number of frames per RTP packet, but rather as the number of milliseconds of audio per RTP packet that the device can receive. Third-party IP phones may use different (higher) rates even though these rates may not be exceeded to and or from Cisco Unified IP phones. getMaxFramesPerPacket( int Returns a payload type from the RTPPayload interface that this object specifies. getPayloadType() int Returns whether the payload of this object is supported or not. True if the payloadType is supported, or otherwise false isSupported() boolean Overrides toString in class java.lang.Object. toString() java.lang.String Inherited Methods From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation See CiscoG711MediaCapability, CiscoG723MediaCapability, CiscoG729MediaCapability, CiscoGSMMediaCapability, CiscoWideBandMediaCapability, CiscoRTPBitRate, and CiscoRTPPayload. CiscoMultiMediaCapabilityInfo CiscoMultiMediaCapabilityInfo interface contains the multimedia capabilities of a terminal. Applications can get the video capability, number of screens, and telepresence interoperability of the terminal using this API. Declaration public interface CiscoMultiMediaCapabilityInfo com.cisco.jtapi.extensions.CiscoMultiMediaCapabilityInfo Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 264 Cisco Unified JTAPI Extensions Methods

Fields Table 29: Fields in CiscoMultiMediaCapabilityInfo Description Field Interface Indicates that the CiscoMultiMediaCapabilityInfo.getVideoCapability () for this terminal is NONE. NONE static final int CiscoMultiMediaCapabilityInfo.getVideoCapability () for this terminal is VIDEO_ENABLED. VIDEO_ENABLED static final int Indicates that the CiscoMultiMediaCapabilityInfo.getTelepresenceInfo() for this terminal is TELEPRESENCEINTEROP_NONE. TELEPRESENCEINTEROP_NONE static final int CiscoMultiMediaCapabilityInfo. getTelepresenceInfo () for this terminal is TELEPRESENCEINTEROP_ENABLED TELEPRESENCEINTEROP_ENABLED static final int Methods Table 30: Methods in MultiMediaCapabilityInfo Description Method Interface Returns the video capability of the Terminal. The video capability can be NONE or VIDEO_ENABLED getVideoCapability() int Returns the telepresence capability of the Terminal. The telepresence capability can be TELEPRESENCEINTEROP_NONE or TELEPRESENCEINTEROP_ENABLED getTelepresenceInfo() int Returns the number of screens present on the Terminal. getScreenCount() int CiscoRegistrationException The CiscoMediaTerminal.register method throws this exception when the registration process fails for any reason. For example, registration would fail if the Provider were OUT_OF_SERVICE or if the device were already registered. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 265 Cisco Unified JTAPI Extensions Fields

Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1x Declaration public class CiscoRegistrationException extends java.lang.Exception java.lang.Object java.lang.Throwable java.lang.Exception com.cisco.jtapi.extensions.CiscoRegistrationException Implemented Interfaces java.io.Serializable Constructors Table 31: Constructors in CiscoRegistrationException Description Constructor Interface Takes the description of the exception as a parameter. CiscoRegistrationException (java.lang.Stringdescription) public Methods None Inherited Methods From Class java.lang.Throwable fillInStackTrace, getCause, getLocalizedMessage, getMessage, getStackTrace, initCause, printStackTrace, printStackTrace, printStackTrace, setStackTrace, toString From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation See CiscoMediaTerminal.register(java.net.InetAddress, int, com.cisco.jtapi.extensions.CiscoMediaCapability[]). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 266 Cisco Unified JTAPI Extensions Declaration

CiscoRTPParams You can use the CiscoRTPParams class to specify a dynamic RTP address and port number for a media terminal on a per-call basis. Applications can pass this object in setRTPParams() of CiscoMediaTerminal. These parameters are only valid for a particular call. Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1x Declaration public class CiscoRTPParams extends java.lang.Object java.lang.Object Constructors CiscoRTPParams (java.net.InetAddress, rtpAddress, int rtpPort) Fields None Methods Table 32: Methods in CiscoRTPParams Description Method Interface Returns the Internet address for the inbound RTP stream of the associated call. getRTPAddress() java.net.InetAddress Returns the IP host name for the inbound RTP stream of the associated call. getRTPAddressHostName() java.lang.String Returns the Internet address in byte format for the inbound RTP stream. getRTPByteAddress() byte[] Returns the UDP port for the inbound RTP stream. getRTPPort() int Returns a String in the format “IP address/port number.” Overrides toString in class java.lang.Object. toString() java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 267 Cisco Unified JTAPI Extensions CiscoRTPParams

Inherited Methods From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation See CiscoTerminal and CiscoMediaTerminal. CiscoUnregistrationException The CiscoMediaTerminal.unregister method throws this exception when the unregistration process fails. For example, registration fails if the Provider is OUT_OF_SERVICE or the Terminal is already unregistered. Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1x Declaration public class CiscoUnregistrationException extends java.lang.Exception java.lang.Object java.lang.Throwable java.lang.Exception com.cisco.jtapi.extensions.CiscoUnregistrationException Implemented Interfaces java.io.Serializable Constructors Table 33: Constructors in CiscoUnregistrationException Description Constructor Interface None CiscoUnregistrationException ()(java.lang.Stringdescription) public Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 268 Cisco Unified JTAPI Extensions Inherited Methods

Fields None Methods None Inherited Methods From Class java.lang.Throwable fillInStackTrace, getCause, getLocalizedMessage, getMessage, getStackTrace, initCause, printStackTrace, printStackTrace, printStackTrace, setStackTrace, toString From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation See CiscoMediaTerminal.unregister(), Serialized Form. CiscoWideBandMediaCapability The CiscoWideBandMediaCapability object specifies the properties for a wide band encoded RTP stream. Applications that support wide band media termination use this object to specify their preferred packet size when registering a CiscoMediaTerminal. The default packet size is ten milliseconds. Class History Description Cisco Unified Communications Manager Release Added history table to track changes. 7.1x Declaration public class CiscoWideBandMediaCapability extends CiscoMediaCapability java.lang.Object com.cisco.jtapi.extensions.CiscoMediaCapability com.cisco.jtapi.extensions.CiscoWideBandMediaCapability Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 269 Cisco Unified JTAPI Extensions Fields

Constructors Table 34: Constructors in CiscoWideBandMediaCapability Description Constructor Interface Constructs a CiscoWideBandMediaCapability object with the specified packet size. The default is ten–millisecond packet size. Parameters • packetsize—The RTP packet Framesize. CiscoWideBandMediaCapability(intpacketsize) public Fields Table 35: Fields in CiscoWideBandMedicaCapability Description Field Interface RTP Packet Framesize: Ten millisecond RTP packet FRAMESIZE_TEN_MILLISECOND_PACKET staticint Inherited Fields From Class com.cisco.jtapi.extensions.CiscoMediaCapability G711_64K_30_MILLISECONDS, G723_6K_30_MILLISECONDS, G729_30_MILLISECONDS, GSM_80_MILLISECONDS, WIDEBAND_256K_10_MILLISECONDS Methods None Inherited Methods From Class com.cisco.jtapi.extensions.CiscoMediaCapability getMaxFramesPerPacket, getPayloadType, isSupported, toString From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait Related Documentation See Constant Field Values, on page 1667. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 270 Cisco Unified JTAPI Extensions Constructors

Interface Hierarchy The following interface hierarchy is contained in the com.cisco.jtapi.extensions package hierarchy. javax.telephony.Address com.cisco.jtapi.extensions.CiscoAddress (also extends com.cisco.jtapi.extensions.CiscoObjectContainer) com.cisco.jtapi.extensions.CiscoIntercomAddress javax.telephony.callcenter.RouteAddress com.cisco.jtapi.extensions.CiscoRouteAddress javax.telephony.AddressObserver com.cisco.jtapi.extensions.CiscoAddressObserver javax.telephony.Call javax.telephony.callcontrol.CallControlCall com.cisco.jtapi.extensions.CiscoCall (also extends com.cisco.jtapi.extensions.CiscoObjectContainer) com.cisco.jtapi.extensions.CiscoConsultCall com.cisco.jtapi.extensions.CiscoCallCtlTermConnHeldReversionEv com.cisco.jtapi.extensions.CiscoConferenceChain com.cisco.jtapi.extensions.CiscoFeatureReason com.cisco.jtapi.extensions.CiscoJtapiException com.cisco.jtapi.extensions.CiscoJtapiProperties com.cisco.jtapi.extensions.CiscoLocales com.cisco.jtapi.extensions.CiscoMediaSecurityIndicator com.cisco.jtapi.extensions.CiscoMediaConnectionMode com.cisco.jtapi.extensions.CiscoMediaEncryptionAlgorithmType com.cisco.jtapi.extensions.CiscoMediaEncryptionKeyInfo com.cisco.jtapi.extensions.CiscoMediaSecurityIndicator com.cisco.jtapi.extensions.CiscoMonitorInitiatorInfo com.cisco.jtapi.extensions.CiscoMonitorTargetInfo com.cisco.jtapi.extensions.CiscoObjectContainer com.cisco.jtapi.extensions.CiscoAddress (also extends javax.telephony.Address) com.cisco.jtapi.extensions.CiscoIntercomAddress com.cisco.jtapi.extensions.CiscoCall (also extends javax.telephony.callcontrol.CallControlCall) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 271 Cisco Unified JTAPI Extensions Interface Hierarchy

com.cisco.jtapi.extensions.CiscoConsultCall com.cisco.jtapi.extensions.CiscoCallID com.cisco.jtapi.extensions.CiscoConnection (also extends javax.telephony.callcontrol.CallControlConnection) com.cisco.jtapi.extensions.CiscoConnectionID com.cisco.jtapi.extensions.CiscoConsultCall com.cisco.jtapi.extensions.CiscoIntercomAddress com.cisco.jtapi.extensions.CiscoJtapiPeer (also extends javax.telephony.JtapiPeer, com.cisco.services.tracing.TraceModule) com.cisco.jtapi.extensions.CiscoMediaTerminal com.cisco.jtapi.extensions.CiscoProvider com.cisco.jtapi.extensions.CiscoRouteTerminal com.cisco.jtapi.extensions.CiscoTerminal (also extends javax.telephony.Terminal) com.cisco.jtapi.extensions.CiscoMediaTerminal com.cisco.jtapi.extensions.CiscoRouteTerminal com.cisco.jtapi.extensions.CiscoTerminalConnection (also extends javax.telephony.callcontrol.CallControlTerminalConnection) com.cisco.jtapi.extensions.CiscoPartyInfo com.cisco.jtapi.extensions.CiscoProvFeatureID com.cisco.jtapi.extensions.CiscoProviderCapabilityChangedEv com.cisco.jtapi.extensions.CiscoRecorderInfo com.cisco.jtapi.extensions.CiscoRTPBitRate com.cisco.jtapi.extensions.CiscoRTPHandle com.cisco.jtapi.extensions.CiscoRTPInputProperties com.cisco.jtapi.extensions.CiscoRTPOutputProperties com.cisco.jtapi.extensions.CiscoRTPPayload com.cisco.jtapi.extensions.CiscoSynchronousObserver com.cisco.jtapi.extensions.CiscoTermConnPrivacyChangedEv com.cisco.jtapi.extensions.CiscoTermEvFilter com.cisco.jtapi.extensions.CiscoTerminalProtocol com.cisco.jtapi.extensions.CiscoTone com.cisco.jtapi.extensions.CiscoUrlInfo javax.telephony.Connection javax.telephony.callcontrol.CallControlConnection com.cisco.jtapi.extensions.CiscoConnection (also extends com.cisco.jtapi.extensions.CiscoObjectContainer) javax.telephony.events.Ev Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 272 Cisco Unified JTAPI Extensions Interface Hierarchy

javax.telephony.events.AddrEv com.cisco.jtapi.extensions.CiscoAddrEv (also extends com.cisco.jtapi.extensions.CiscoEv) com.cisco.jtapi.extensions.CiscoAddrAutoAcceptStatusChangedEv com.cisco.jtapi.extensions.CiscoAddrInServiceEv com.cisco.jtapi.extensions.CiscoAddrIntercomInfoChangedEv com.cisco.jtapi.extensions.CiscoAddrIntercomInfoRestorationFailedEv com.cisco.jtapi.extensions.CiscoAddrOutOfServiceEv (also extends com.cisco.jtapi.extensions.CiscoOutOfServiceEv) com.cisco.jtapi.extensions.CiscoAddressRecordingConfigChangedEv javax.telephony.callcontrol.events.CallCtlEv javax.telephony.callcontrol.events.CallCtlCallEv (also extends javax.telephony.events.CallEv) javax.telephony.callcontrol.events.CallCtlConnEv (also extends javax.telephony.events.ConnEv) javax.telephony.callcontrol.events.CallCtlConnOfferedEv com.cisco.jtapi.extensions.CiscoCallCtlConnOfferedEv javax.telephony.events.CallEv javax.telephony.events.CallActiveEv com.cisco.jtapi.extensions.CiscoConsultCallActiveEv (also extends com.cisco.jtapi.extensions.CiscoCallEv) javax.telephony.callcontrol.events.CallCtlCallEv (also extends javax.telephony.callcontrol.events.CallCtlEv) javax.telephony.callcontrol.events.CallCtlConnEv (also extends javax.telephony.events.ConnEv) javax.telephony.callcontrol.events.CallCtlConnOfferedEv com.cisco.jtapi.extensions.CiscoCallCtlConnOfferedEv com.cisco.jtapi.extensions.CiscoCallEv (also extends com.cisco.jtapi.extensions.CiscoEv) com.cisco.jtapi.extensions.CiscoCallChangedEv com.cisco.jtapi.extensions.CiscoCallSecurityStatusChangedEv com.cisco.jtapi.extensions.CiscoConferenceChainAddedEv com.cisco.jtapi.extensions.CiscoConferenceChainRemovedEv com.cisco.jtapi.extensions.CiscoConferenceEndEv com.cisco.jtapi.extensions.CiscoConferenceStartEv com.cisco.jtapi.extensions.CiscoConsultCallActiveEv (also extends javax.telephony.events.CallActiveEv) com.cisco.jtapi.extensions.CiscoToneChangedEv com.cisco.jtapi.extensions.CiscoTransferEndEv com.cisco.jtapi.extensions.CiscoTransferStartEv javax.telephony.events.ConnEv javax.telephony.callcontrol.events.CallCtlConnEv (also extends javax.telephony.callcontrol.events.CallCtlCallEv) javax.telephony.callcontrol.events.CallCtlConnOfferedEv com.cisco.jtapi.extensions.CiscoCallCtlConnOfferedEv javax.telephony.events.TermConnEv com.cisco.jtapi.extensions.CiscoTermConnMonitoringEndEv com.cisco.jtapi.extensions.CiscoTermConnMonitoringStartEv com.cisco.jtapi.extensions.CiscoTermConnMonitorInitiatorInfoEv com.cisco.jtapi.extensions.CiscoTermConnMonitorTargetInfoEv com.cisco.jtapi.extensions.CiscoTermConnRecordingEndEv com.cisco.jtapi.extensions.CiscoTermConnRecordingStartEv com.cisco.jtapi.extensions.CiscoTermConnRecordingTargetInfoEv com.cisco.jtapi.extensions.CiscoTermConnSelectChangedEv com.cisco.jtapi.extensions.CiscoEv com.cisco.jtapi.extensions.CiscoAddrActivatedEv com.cisco.jtapi.extensions.CiscoAddrActivatedOnTerminalEv com.cisco.jtapi.extensions.CiscoAddrAddedToTerminalEv com.cisco.jtapi.extensions.CiscoAddrAutoAcceptStatusChangedEv com.cisco.jtapi.extensions.CiscoAddrCreatedEv com.cisco.jtapi.extensions.CiscoAddrEv (also extends javax.telephony.events.AddrEv) com.cisco.jtapi.extensions.CiscoAddrAutoAcceptStatusChangedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 273 Cisco Unified JTAPI Extensions Interface Hierarchy

com.cisco.jtapi.extensions.CiscoAddrInServiceEv com.cisco.jtapi.extensions.CiscoAddrIntercomInfoChangedEv com.cisco.jtapi.extensions.CiscoAddrIntercomInfoRestorationFailedEv com.cisco.jtapi.extensions.CiscoAddrOutOfServiceEv (also extends com.cisco.jtapi.extensions.CiscoAddrEv, com.cisco.jtapi.extensions.CiscoOutOfServiceEv) com.cisco.jtapi.extensions.CiscoAddressRecordingConfigChangedEv com.cisco.jtapi.extensions.CiscoAddrInServiceEv com.cisco.jtapi.extensions.CiscoAddrIntercomInfoChangedEv com.cisco.jtapi.extensions.CiscoAddrIntercomInfoRestorationFailedEv com.cisco.jtapi.extensions.CiscoAddrOutOfServiceEv (also extends com.cisco.jtapi.extensions.CiscoAddrEv) com.cisco.jtapi.extensions.CiscoAddressRecordingConfigChangedEv com.cisco.jtapi.extensions.CiscoAddrRemovedEv com.cisco.jtapi.extensions.CiscoAddrRemovedFromTerminalEv com.cisco.jtapi.extensions.CiscoAddrRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedOnTerminalEv com.cisco.jtapi.extensions.CiscoCallChangedEv com.cisco.jtapi.extensions.CiscoCallEv (also extends javax.telephony.events.CallEv) com.cisco.jtapi.extensions.CiscoCallChangedEv com.cisco.jtapi.extensions.CiscoCallSecurityStatusChangedEv com.cisco.jtapi.extensions.CiscoConferenceChainAddedEv com.cisco.jtapi.extensions.CiscoConferenceChainRemovedEv com.cisco.jtapi.extensions.CiscoConferenceEndEv com.cisco.jtapi.extensions.CiscoConferenceStartEv com.cisco.jtapi.extensions.CiscoConsultCallActiveEv (also extends javax.telephony.events.CiscoCallEv) com.cisco.jtapi.extensions.CiscoToneChangedEv com.cisco.jtapi.extensions.CiscoTransferEndEv com.cisco.jtapi.extensions.CiscoTransferStartEv com.cisco.jtapi.extensions.CiscoCallSecurityStatusChangedEv com.cisco.jtapi.extensions.CiscoConferenceChainAddedEv com.cisco.jtapi.extensions.CiscoConferenceChainRemovedEv com.cisco.jtapi.extensions.CiscoConferenceEndEv com.cisco.jtapi.extensions.CiscoConferenceStartEv com.cisco.jtapi.extensions.CiscoConsultCallActiveEv (also extends javax.telephony.events.CallActiveEv, com.cisco.jtapi.extensions.CiscoCallEv) com.cisco.jtapi.extensions.CiscoMediaOpenLogicalChannelEv com.cisco.jtapi.extensions.CiscoOutOfServiceEv com.cisco.jtapi.extensions.CiscoAddrOutOfServiceEv (also extends com.cisco.jtapi.extensions.CiscoAddrEv) com.cisco.jtapi.extensions.CiscoTermOutOfServiceEv (also extends com.cisco.jtapi.extensions.CiscoTermEv) com.cisco.jtapi.extensions.CiscoProvCallParkEv com.cisco.jtapi.extensions.CiscoProvFeatureEv (also extends javax.telephony.events.ProvEv) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 274 Cisco Unified JTAPI Extensions Interface Hierarchy

com.cisco.jtapi.extensions.CiscoAddrActivatedEv com.cisco.jtapi.extensions.CiscoAddrActivatedOnTerminalEv com.cisco.jtapi.extensions.CiscoAddrAddedToTerminalEv com.cisco.jtapi.extensions.CiscoAddrCreatedEv com.cisco.jtapi.extensions.CiscoAddrRemovedEv com.cisco.jtapi.extensions.CiscoAddrRemovedFromTerminalEv com.cisco.jtapi.extensions.CiscoAddrRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedOnTerminalEv com.cisco.jtapi.extensions.CiscoProvCallParkEv com.cisco.jtapi.extensions.CiscoProvFeatureEv com.cisco.jtapi.extensions.CiscoProvCallParkEv com.cisco.jtapi.extensions.CiscoRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedOnTerminalEv com.cisco.jtapi.extensions.CiscoTermActivatedEv com.cisco.jtapi.extensions.CiscoTermCreatedEv com.cisco.jtapi.extensions.CiscoTermRemovedEv com.cisco.jtapi.extensions.CiscoTermRestrictedEv com.cisco.jtapi.extensions.CiscoProvFeatureEv com.cisco.jtapi.extensions.CiscoProvCallParkEv com.cisco.jtapi.extensions.CiscoRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedOnTerminalEv com.cisco.jtapi.extensions.CiscoRTPInputKeyEv com.cisco.jtapi.extensions.CiscoRTPInputStartedEv com.cisco.jtapi.extensions.CiscoRTPInputStoppedEv com.cisco.jtapi.extensions.CiscoRTPOutputKeyEv com.cisco.jtapi.extensions.CiscoRTPOutputStartedEv com.cisco.jtapi.extensions.CiscoRTPOutputStoppedEv com.cisco.jtapi.extensions.CiscoTermActivatedEv com.cisco.jtapi.extensions.CiscoTermButtonPressedEv com.cisco.jtapi.extensions.CiscoTermCreatedEv com.cisco.jtapi.extensions.CiscoTermDataEv com.cisco.jtapi.extensions.CiscoTermDeviceStateActiveEv com.cisco.jtapi.extensions.CiscoTermDeviceStateAlertingEv com.cisco.jtapi.extensions.CiscoTermDeviceStateHeldEv com.cisco.jtapi.extensions.CiscoTermDeviceStateWhisperEv com.cisco.jtapi.extensions.CiscoTermDeviceStateWhisperEv com.cisco.jtapi.extensions.CiscoTermDNDStatusChangedEv com.cisco.jtapi.extensions.CiscoTermEvFilter (also extends javax.telephony.events.TermEv) com.cisco.jtapi.extensions.CiscoMediaOpenLogicalChannelEv com.cisco.jtapi.extensions.CiscoRTPInputKeyEv com.cisco.jtapi.extensions.CiscoRTPInputStartedEv com.cisco.jtapi.extensions.CiscoRTPInputStoppedEv com.cisco.jtapi.extensions.CiscoRTPOutputKeyEv com.cisco.jtapi.extensions.CiscoRTPOutputStartedEv com.cisco.jtapi.extensions.CiscoRTPOutputStoppedEv com.cisco.jtapi.extensions.CiscoTermButtonPressedEv com.cisco.jtapi.extensions.CiscoTermDataEv com.cisco.jtapi.extensions.CiscoTermDeviceStateActiveEv com.cisco.jtapi.extensions.CiscoTermDeviceStateAlertingEv com.cisco.jtapi.extensions.CiscoTermDeviceStateHeldEv com.cisco.jtapi.extensions.CiscoTermDeviceStateIdleEv com.cisco.jtapi.extensions.CiscoTermDeviceStateWhisperEv com.cisco.jtapi.extensions.CiscoTermDNDStatusChangedEv com.cisco.jtapi.extensions.CiscoTermInServiceEv com.cisco.jtapi.extensions.CiscoTermOutOfServiceEv(also extends com.cisco.jtapi.extensions.CiscoOutOfServiceEv) com.cisco.jtapi.extensions.CiscoTermRegistrationFailedEv com.cisco.jtapi.extensions.CiscoTermSnapshotCompletedEv com.cisco.jtapi.extensions.CiscoTermSnapshotEv com.cisco.jtapi.extensions.CiscoTermInServiceEv com.cisco.jtapi.extensions.CiscoTermOutOfServiceEv (also extends Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 275 Cisco Unified JTAPI Extensions Interface Hierarchy

com.cisco.jtapi.extensions.CiscoOutOfServiceEv, com.cisco.jtapi.extensions.CiscoTermEv) com.cisco.jtapi.extensions.CiscoTermRegistrationFailedEv com.cisco.jtapi.extensions.CiscoTermRemovedEv com.cisco.jtapi.extensions.CiscoTermRestrictedEv com.cisco.jtapi.extensions.CiscoTermSnapshotCompletedEv com.cisco.jtapi.extensions.CiscoTermSnapshotEv com.cisco.jtapi.extensions.CiscoToneChangedEv com.cisco.jtapi.extensions.CiscoTransferEndEv com.cisco.jtapi.extensions.CiscoTransferStartEv javax.telephony.events.ProvEv com.cisco.jtapi.extensions.CiscoProvEv (also extends com.cisco.jtapi.extensions.CiscoEv) com.cisco.jtapi.extensions.CiscoAddrActivatedEv com.cisco.jtapi.extensions.CiscoAddrActivatedOnTerminalEv com.cisco.jtapi.extensions.CiscoAddrAutoAcceptStatusChangedEv com.cisco.jtapi.extensions.CiscoAddrCreatedEv com.cisco.jtapi.extensions.CiscoAddrRemovedEv com.cisco.jtapi.extensions.CiscoAddrRemovedFromTerminalEv com.cisco.jtapi.extensions.CiscoAddrRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedOnTerminalEv com.cisco.jtapi.extensions.CiscoProvCallParkEv com.cisco.jtapi.extensions.CiscoProvFeatureEv com.cisco.jtapi.extensions.CiscoProvCallParkEv com.cisco.jtapi.extensions.CiscoRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedOnTerminalEv com.cisco.jtapi.extensions.CiscoTermActivatedEv com.cisco.jtapi.extensions.CiscoTermCreatedEv com.cisco.jtapi.extensions.CiscoTermRemovedEv com.cisco.jtapi.extensions.CiscoTermRestrictedEv javax.telephony.events.TermEv com.cisco.jtapi.extensions.CiscoTermEv (also extends com.cisco.jtapi.extensions.CiscoEv) com.cisco.jtapi.extensions.CiscoMediaOpenLogicalChannelEv com.cisco.jtapi.extensions.CiscoRTPInputKeyEv com.cisco.jtapi.extensions.CiscoRTPInputStartedEv com.cisco.jtapi.extensions.CiscoRTPInputStoppedEv com.cisco.jtapi.extensions.CiscoRTPOutputKeyEv com.cisco.jtapi.extensions.CiscoRTPOutputStartedEv com.cisco.jtapi.extensions.CiscoRTPOutputStoppedEv com.cisco.jtapi.extensions.CiscoTermButtonPressedEv com.cisco.jtapi.extensions.CiscoTermDataEv com.cisco.jtapi.extensions.CiscoTermDeviceStateActiveEv com.cisco.jtapi.extensions.CiscoTermDeviceStateAlertingEv com.cisco.jtapi.extensions.CiscoTermDeviceStateHeldEv com.cisco.jtapi.extensions.CiscoTermDeviceStateIdleEv com.cisco.jtapi.extensions.CiscoTermDeviceStateWhisperEv com.cisco.jtapi.extensions.CiscoTermDNDStatusChangedEv com.cisco.jtapi.extensions.CiscoTermInServiceEv com.cisco.jtapi.extensions.CiscoTermOutOfServiceEv (also extends com.cisco.jtapi.extensions.CiscoOutOfServiceEv) com.cisco.jtapi.extensions.CiscoTermRegistrationFailedEv com.cisco.jtapi.extensions.CiscoTermSnapshotCompletedEv com.cisco.jtapi.extensions.CiscoTermSnapshotEv javax.telephony.JtapiPeer com.cisco.jtapi.extensions.CiscoJtapiPeer (also extends com.cisco.jtapi.extensions.CiscoObjectContainer, com.cisco.services.tracing.TraceModule) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 276 Cisco Unified JTAPI Extensions Interface Hierarchy

javax.telephony.Provider com.cisco.jtapi.extensions.CiscoProvider (also extends com.cisco.jtapi.extensions.CiscoObjectContainer) javax.telephony.capabilities.ProviderCapabilities com.cisco.jtapi.extensions.CiscoProviderCapabilities javax.telephony.ProviderObserver com.cisco.jtapi.extensions.CiscoProviderObserver javax.telephony.callcenter.RouteSession com.cisco.jtapi.extensions.CiscoRouteSession javax.telephony.callcenter.events.RouteSessionEvent javax.telephony.callcenter.events.RouteEvent com.cisco.jtapi.extensions.CiscoRouteEvent javax.telephony.callcenter.events.RouteUsedEvent com.cisco.jtapi.extensions.CiscoRouteUsedEvent javax.telephony.Terminal com.cisco.jtapi.extensions.CiscoTerminal (also extends com.cisco.jtapi.extensions.CiscoObjectContainer) com.cisco.jtapi.extensions.CiscoMediaTerminal com.cisco.jtapi.extensions.CiscoRouteTerminal javax.telephony.TerminalConnection javax.telephony.callcontrol.CallControlTerminalConnection com.cisco.jtapi.extensions.CiscoTerminalConnection (also extends com.cisco.jtapi.extensions.CiscoObjectContainer) javax.telephony.TerminalObserver com.cisco.jtapi.extensions.CiscoTerminalObserver com.cisco.services.tracing.TraceModule com.cisco.jtapi.extensions.CiscoJtapiPeer (also extends com.cisco.jtapi.extensions.CiscoObjectContainer, javax.telephony.JtapiPeer) CiscoAddrActivatedEv If an address is controlled and the restriction status changes to active, the system sends the CiscoAddrActivatedEv event to the application. Applications see this event whenever an Address or associated Terminal is in the control list. If any observers exist on the address already, applications see CiscoAddrInServiceEv. If no observers are present, applications can try to add observers, and the address will go in service. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 277 Cisco Unified JTAPI Extensions CiscoAddrActivatedEv

Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoAddrActivatedEv extends CiscoProvEv Fields Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 36: Methods in CiscoAddrActivatedEv Description Method Interface Returns the Address which is activated. getAddress() javax.telephony.Address Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 278 Cisco Unified JTAPI Extensions Superinterfaces

Inherited Methods From Interface javax.telephony.events.ProvEv getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. Superinterfaces javax.telephony.callcontrol.events.CallCtlCallEv, javax.telephony.callcontrol.events.CallCtlConnEv, javax.telephony.callcontrol.events.CallCtlConnOfferedEv, javax.telephony.callcontrol.events.CallCtlEv, javax.telephony.events.CallEv, javax.telephony.events.ConnEv, javax.telephony.events.Ev Declaration public interface CiscoCallCtlConnOfferedEv extends javax.telephony.callcontrol.events.CallCtlConnOfferedEv Fields None Inherited Fields From Interface javax.telephony.callcontrol.events.CallCtlConnOfferedEv None From Interface javax.telephony.callcontrol.events.CallCtlEv CAUSE_ALTERNATE, CAUSE_BUSY, CAUSE_CALL_BACK, CAUSE_CALL_NOT_ANSWERED, CAUSE_CALL_PICKUP, CAUSE_CONFERENCE, CAUSE_DO_NOT_DISTURB, CAUSE_PARK, CAUSE_REDIRECTED, CAUSE_REORDER_TONE, CAUSE_TRANSFER, CAUSE_TRUNKS_BUSY, CAUSE_UNHOLD From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 279 Cisco Unified JTAPI Extensions Inherited Methods

META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 37: Methods in CiscoCallCtlConnOfferedEv Description Method Interface Returns the IP address of the calling party, or 0 (or null) if the IP Address is not available. getCallingPartyIpAddr() java.net.InetAddress Inherited Methods From Interface javax.telephony.callcontrol.events.CallCtlCallEv getCalledAddress, getCallingAddress, getCallingTerminal, getLastRedirectedAddress From Interface javax.telephony.callcontrol.events.CallCtlEv getCallControlCause From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 280 Cisco Unified JTAPI Extensions Methods

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ConnEv getConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation None CiscoAddrActivatedOnTerminalEv The CiscoAddrActivatedOnTerminalEv event gets sent when a shared line gets activated or a Terminal which has shared line gets activated. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoAddrActivatedOnTerminalEv extends CiscoProvEv Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 281 Cisco Unified JTAPI Extensions Related Documentation

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 38: Methods in CiscoAddrActivatedOnTerminalEv Description Method Interface Returns the address that is marked unrestricted on the terminal. getAddress() javax.telephony.Address Returns the terminal on which the address got activated (i.e. marked unrestricted). getTerminal() javax.telephony.Terminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 282 Cisco Unified JTAPI Extensions Inherited Fields

Related Documentation See Constant Field Values, on page 1667 for more information. CiscoAddrAddedToTerminalEv The system sends CiscoAddrAddedToTerminalEv when: • A user adds a Terminal into the control list that contains a shared line, the system sends this event to the application. If a user has an address in the control list, and you add a new Terminal with the same address in control list, this event gets sent. • An Extension Mobility (EM) user logs into a Terminal with a profile that contains a shared line, this event notifies that a new Terminal has been added to an already existing address. • A new shared line gets added to a Terminal in a user control list, the system sends this event to the application. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoAddrAddedToTerminalEv extends CiscoProvEv Fields Table 39: Fields in CiscoAddrAddedToTerminalEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 283 Cisco Unified JTAPI Extensions Related Documentation

CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 40: Methods in CiscoAddrAddedToTerminalEv Description Method Interface Returns the address on which the new terminal is added. getAddress() javax.telephony.Address Returns the terminal that gets added to the Address. getTerminal() javax.telephony.Terminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. CiscoAddrAutoAcceptStatusChangedEv The system sends CiscoAddrAutoAcceptStatusChangedEv to applications whenever the AutoAccept status for the Address on the Terminal changes. If an Address has multiple Terminals, this event gets sent for the Address AutoAccept status on each individual Terminal. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 284 Cisco Unified JTAPI Extensions Methods

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.events.AddrEv, CiscoAddrEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoAddrAutoAcceptStatusChangedEv extends CiscoAddrEv Fields Table 41: Fields in CiscoAddrAutoAcceptStatusChangedEv Field Interface ID static int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUTUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_R_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 285 Cisco Unified JTAPI Extensions Superinterfaces

Methods Table 42: Methods for CiscoAddrAutoAcceptStatusChangedEv Description Method Interface Returns the AutoAccept Status of the Address on the Terminal. Returns CiscoAddress.AUTOACCEPT_OFF or CiscoAddress.AUTOACCEPT_ON getAutoAcceptStatus() int Returns the Terminal at which the AutoAccept status for this address is changing. getTerminal() CiscoTerminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.AddrEv getAddress From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See getAutoAcceptStatus and CiscoAddress.getAutoAcceptStatus(Terminal terminal). CiscoAddrCreatedEv The CiscoAddrCreatedEv event gets sent when an Address gets added to the provider domain. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 286 Cisco Unified JTAPI Extensions Methods

Declaration public interface CiscoAddrCreatedEv extends CiscoProvEv Fields Table 43: Fields in CiscoAddrCreatedEv Field Interface static final int ID ID Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 44: Methods in CiscoAddrCreatedEv Description Method Interface Returns the address which got added to the provider domain. Returns the address that is added to the provider domain. javax.telephony.Address getAddress() getAddress Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 287 Cisco Unified JTAPI Extensions Declaration

Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoAddrMonitorTerminatedEv When a monitor session is terminated, the Supervisor who had initiated the session will be notified with this event. Interface History Description Cisco Unified Communications Manager Release Number New interface 8.0(1) Declaration pubic interface CiscoAddrMonitorTerminatedEv extends CiscoAddrEv Methods Table 45: Methods in CiscoAddrMonitorTerminatedEv Description Method Interface Returns the transaction ID for the session termination. getTransactionID() Int Returns the target address that was being monitored. getMonitorTargetAddress() Address Returns the monitored device name. getMonitorTargetDevieName() String Returns the call leg identifier for the monitored target. getMonitorTargetCalllegHandle() Int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 288 Cisco Unified JTAPI Extensions Inherited Methods

Description Method Interface Returns the device name for the device that initiated the monitoring session. getMonitorInitiatorDeviceName() String Returns the reason that the monitoring session was terminated. getCause() Int Related Documentation CiscoAddress The CiscoAddress interface extends the Address interface with additional Cisco Unified Communications Manager capabilities. Interface History Description Cisco Unified Communications Manager Release Number Added voice and fax message counts for the Enhanced Message Waiting Indication (MWI) feature for supported phones only. 7.1(1, 2) Updated for Terminal and Address Capability settings changes. 7.1(3) Enhanced with the following: • New APIs getPickupGroup() to enable applications to get information about the Pickup Group the Address belongs to • New address type to indicate that the address represents hunt pilot. • New field that will represent a new kind of recording type, device-based recording. 8.0(1) A new constant, SELECTIVE_RECORDING, is added. Two constants, APPLICATION_CONTROLLED_RECORDING, and DEVICE_CONTROLLED_RECORDING, are deprecated. Applications that upgrade to Release 9.0 or later releases should use the new SELECTIVE_RECORDING constant and not the deprecated APPLICATION_CONTROLLED_RECORDING and DEVICE_CONTROLLED_RECORDING constants. In Release 9.0 or later releases Unified CM and JTAPI never return the DEVICE_CONTROLLED_RECORDING constant. 9.0(1) Enhanced with the following: • New APIs to create a persistent call and to retrieve the connection object associated to the persistent call. • a new API to create an announcement call in order to play announcements to the remote destinations. 10.0(1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 289 Cisco Unified JTAPI Extensions Related Documentation

Superinterfaces javax.telephony.Address, CiscoObjectContainer, on page 474 Subinterfaces CiscoIntercomAddress Fields Table 46: Fields in CiscoAddress Description Field Interface Application controlled Recording is configured on the Address. APPLICATION_CONTROLLED_RECORDING Static int Auto Recording is configured on the Address. AUTO_RECORDING Static int AutoAnswer is off. AUTOANSWER_OFF Static int AutoAnswer status is unknown. AUTOANSWER_UNKNOWN Static int AutoAnswer is allowed with a headset. AUTOANSWER_WITHHEADSET Static int AutoAnswer is allowed with a speaker set. AUTOANSWER_WITHSPEAKERSET static int This value will be used to specify a new recording type. This type is used when the recording profile is configured on the device, and is thus “device controlled” DEVICE_CONTROLLED_RECORDING public static final int This represents an external address with a valid name. EXTERNAL static int This represents an external address with an unknown name. EXTERNAL_UNKNOWN static int The address is in service. IN_SERVICE static int This is an internal address. INTERNAL static int This represents an address with a monitoring target or agent. MONITORING_TARGET static int Recording is off on the Address. NO_RECORDING static int The address is out-of-service. OUT_OF_SERVICE static int Sets the ringer status to the configured value. RINGER_DEFAULT static int Disables the ringer for the address. RINGER_DISABLE static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 290 Cisco Unified JTAPI Extensions Superinterfaces

Description Field Interface Enables the ringer for the address. RINGER_ENABLE static int This constant is added to replace the deprecated constants APPLICTION_CONTROLLED_RECORDINGand DEVICE_CONTROLLED_RECORDING SELECTIVE_RECORDING static int This represents an address with an unknown name. UNKNOWN static int Methods Table 47: Methods in CiscoAddress Description Method Interface Use this interface to clear any phantom calls on the address. Throws javax. telephony. PrivilegeViolationException—Use this interface to clear any phantom calls on the address. clearCallConnections () void This interface creates a persistent call for this address and will return the call object for the newly created call. Note that CiscoProvider and the address must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. This API cannot be invoked on external addresses. Doing so will result in MethodNotSupportedException to be thrown. If while trying to allocate a globalCallId for the persistent call and an error occurs, ResourceUnavailableException will be thrown. All other errors encountered will result in PlatformException to be thrown. createPersistentCall (Terminal terminal, String callerIDNumber, String callerIDName) CiscoCall This interface creates an announcement call for this address in order to play announcements to the remote destination. It returns the call object for the newly created call. Note that CiscoProvider and the address must be in IN_SERVICE state, otherwise InvalidStateException is thrown. This API cannot be invoked on external addresses. Doing so results in MethodNotSupportedException being thrown. If while trying to allocate a globalCallId for the announcement call and an error occurs, ResourceUnavailableException ise thrown. All other errors encountered results in PlatformException being thrown. startAnnouncement (Terminal terminal, String announcementID) Use this interface to get information about calls that are present at the Terminal. getAddressCallInfo (javax. telephony. Terminal terminal) CiscoAddressCallInfo Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 291 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method returns the ASCII label configured for this address on Terminal term. Throws InvalidStateException, MethodNotSupportedException, InValidParameterException. getAsciiLabel (Terminal term) String Returns the AutoAccept status of the Address on the Terminal. Throws javax. telephony. PlatformException, javax. telephony. InvalidStateException, javax. telephony. MethodNotSupportedException Returns the AutoAccept status of the Address on the Terminal. It may return one of the following constants: • CiscoAddress. AUTOACCEPT_OFF • CiscoAddress. AUTOACCEPT_ON Pre-conditions (this. getProvider ()). getState () = = Provider. IN_SERVICE (getState () = = IN_SERVICE Parameters • terminal - The Terminal on which the AutoAccepts getAutoAcceptStatus (javax. telephony. Terminal terminal) int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 292 Cisco Unified JTAPI Extensions Methods

Description Method Interface This interface returns the AutoAnswer status of this Address on given Terminal. Throws javax. telephony. PlatformException, javax. telephony. InvalidStateException, javax. telephony. MethodNotSupportedException If return value is AUTOANSWER_OFF, that means AutoAnswer is disabled. If return value is AUTOANSWER_WITHHEADSET, that means AutoAnswer is enabled with HEADSET. If return value is AUTOANSWER_WITHSPEAKERSET, that means AutoAnswer is enabled with SPEAKERSET. If return value is AUTOANSWER_UNKNOWN, that means AutoAnswer status is UNKNOWN. Pre-conditions (this. getProvider ()). getState () = = Provider. IN_SERVICE (getState () = = IN_SERVICE Parameters • term - Terminal at which AutoAnswer is checked Returns one of the following values: • CiscoAddress. AUTOANSWER_OFF • CiscoAddress.AUTOANSWER_WITHHEADSET • CiscoAddress. AUTOANSWER_WITHSPEAKERSET • CiscoAddress. AUTOANSWER_UNKNOWN Throws javax. telephony. InvalidStateException - The Provider or Address is not"IN_SERVICE". javax. telephony. PlatformException - If Address is not on Terminal term javax. telephony. MethodNotSupportedException - If Address is an External Address getAutoAnswerStatus (javax. telephony. Terminal term) int This method returns the busy trigger configured for this address on terminal term. Throws InvalidStateException, InvalidArgumentException, MethodNotSupportedException. getBusyTrigger (Terminal term) int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 293 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method returns the button position of the address on terminal term. Throws InvalidStateException, InvalidArgumentException, MethodNotSupportedException. getButtonPosition (Terminal term) int Use this interface to find out which Shared Lines are in service. In Shared Lines, the same Address appears on different Terminals. Returns: Terminal[]—An array of Terminals on which the Address is in service. getInServiceAddrTerminals () javax. telephony. Terminal[] This new method returns the maximum calls configured for an address on a terminal. This method throws InvalidStateException if the associated terminal is not registered to Cisco Unified Communication Manager. It throws InvalidArgumentException if terminal does not have this address. MethodNotSupportedException is be thrown if address is not in Provider getMaxCalls (Terminal term) int It returns the partition associated with an Address. getPartition () java. lang. String This interface will return the connection object that is associated with the persistent call. It returns null if there is no persistent call. This API cannot be invoked on external addresses. Doing so will result in MethodNotSupportedException to be thrown. getPersistentConnection (Terminal terminal) Connection This method returns a CiscoPickupGroup object that represents the Pickup Group DN and Partition that this Address belongs to. getPickupGroup () CiscoPickupGroup Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 294 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns the configured recording type on this Address. Throws javax. telephony. PlatformException, javax. telephony. InvalidStateException, javax. telephony. MethodNotSupportedException Returns • int—The configured recording type on this Address. • CiscoAddess. NO_RECORDING —The call cannot be recorded. • CiscoAddress. AUTO_RECORDING—Cisco Unified Communications Manager records all answered calls to/from this address. • CiscoAddress. APPLICATION_CONTROLLED_RECORDING—Calls get recorded only when the application initiates recording. Throws javax. telephony. InvalidStateException - The Provider or Address is not"IN_SERVICE". javax. telephony. PlatformException - If Address is not on Terminal term javax. telephony. MethodNotSupportedException - If Address is an External Address getRecordingConfig (javax. telephony. Terminal term) int Deprecated. This method has been replaced by the getState () method. Returns the state of this address can be any of the following constants: • CiscoAddress. OUT_OF_SERVICE • CiscoAddress. IN_SERVICE getRegistrationState () int Returns the array of Terminals on which this Address is restricted. In shared lines, few lines on Terminals may be restricted. Applications cannot see any call events for restricted Addresses. If a restricted Address is involved in a call with any other controlled Terminal, the system creates a Connection for the restricted Address, but there is not any TerminalConnection for the restricted Address. Returns: Terminal[]—An array of Terminals on which this Address is restricted. If none is restricted, this method returns null. getRestrictedAddrTerminals () javax. telephony. Terminal[] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 295 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns the state of this address. The state may be any of the following constants: • CiscoAddress. OUT_OF_SERVICE • CiscoAddress. IN_SERVICE getState () int Returns the following address constants: • CiscoAddress. INTERNAL • CiscoAddress. EXTERNAL • CiscoAddress. EXTERNAL_UNKNOWN • CiscoAddress. UNKNOWN • CiscoAddress. MONITORING_TARGET • CiscoAddress. HUNT_PILOT, if address is in a CiscoHuntConnection. • CiscoAddress. HUNT_PILOT, if address represents hunt pilot. getType () int This method returns the Unicode label configured for this address on Terminal term. Throws InvalidStateException, MethodNotSupportedException, InValidParameterException. getUnicodeLabel (Terminal term) String This method returns the voice mail pilot of the address. Throws InvalidStateException, MethodNotSupportedException. getVoiceMailPilot () int This method returns true if this Address on Terminal is restricted. ; false if not restricted. isRestricted (javax. telephony. Terminal terminal) boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 296 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method lets an application enable AutoAccept for this Address on CiscoMediaTerminal and/or CiscoRouteTerminal. Addresses on CiscoTerminal other than CiscoMediaTerminal or CiscoRouteTerminal will always have AutoAccept on. If the Terminal passed in the parameter is not a CiscoMediaTerminal or CiscoRouteTerminal, this method throws an exception. For a CiscoMediaTerminal that shares an Address with CiscoTerminal, Cisco recommends enabling AutoAccept on CiscoMediaTerminal. Throws javax. telephony. PlatformException, javax. telephony. InvalidStateException, javax. telephony. MethodNotSupportedException Pre-conditions (this. getProvider ()). getState () = = Provider. IN_SERVICE (getState () = = IN_SERVICE Post-conditions Enables or Disables auto accept status Parameters • autoAcceptStatus - can be either CiscoAddress. AUTOACCEPT_OFF or CiscoAddress. AUTOACCEPT_ON. If autoAcceptStatus is AUTOACCEPT_ON, it will enable AutoAccept for Address on Terminal. If autoAcceptStatus is AUTOACCEPT_OFF, it will disable AutoAccept for Address on Terminal. • terminal - The Terminal on which AutoAccept will be enabled Throws javax. telephony. InvalidStateException - The Provider or Address is not "In_Service". javax. telephony. PlatformException - The Terminal does not have this Address. javax. telephony. MethodNotSupportedException - If the Terminal is not CiscoMediaTerminal or CiscoRouteTerminal. setAutoAcceptStatus (int autoAcceptStatus, javax. telephony. Terminal terminal) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 297 Cisco Unified JTAPI Extensions Methods

Description Method Interface Specifies whether the message-waiting indicator should be activated or deactivated for the Address specified by the destination. If enable is true, message-waiting gets activated if not already activated. If enable is false, message-waiting gets deactivated if not already deactivated. Throws javax. telephony. MethodNotSupportedException, javax. telephony. InvalidStateException, javax. telephony. PrivilegeViolationException Pre-conditions (this. getProvider ()). getState () = = Provider. IN_SERVICE Post-conditions Enables or disables the Message Waiting Indicator depending on the enable status. Note This implementation currently does not enforce the post-conditions as specified in CallControlAddress as follows: this. getMessageWaiting () = = enable CallCtlAddrMessageWaitingEv gets delivered for this Address. Parameters • destination - DN/Address message-waiting indicator is activated/deactivated • enable - True to activate message-waiting, false to deactivate Throws • javax. telephony. MethodNotSupportedException—This method is not supported by the given implementation. javax. telephony. InvalidStateException Note The Provider is not“in service. ” javax. telephony. PrivilegeViolationException Note The Provider user has insufficient privileges to invoke the message-waiting indicator for this destination. setMessageWaiting (java. lang. String destination, boolean enable) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 298 Cisco Unified JTAPI Extensions Methods

Description Method Interface Changes the ringer status on this address. Throws javax. telephony. MethodNotSupportedException, javax. telephony. InvalidStateException, javax. telephony. InvalidArgumentException Accepts one of the following constants: • CiscoAddress. RINGER_DEFAULT • CiscoAddress. RINGER_DISABLE • CiscoAddress. RINGER_ENABLE setRingerStatus (int status) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 299 Cisco Unified JTAPI Extensions Methods

Description Method Interface setMessageSummary (boolean enable, boolean voiceCounts, int totalNewVoiceMsgs, int totalOldVoiceMsgs, boolean highPriorityVoiceCounts, int newHighPriorityVoiceMsgs, int oldHighPriorityVoiceMsgs, boolean faxCounts, int totalNewFaxMsgs, int totalOldFaxMsgs, boolean highPriorityFaxCounts, int newHighPriorityFaxMsgs, int oldHighPriorityFaxMsgs) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 300 Cisco Unified JTAPI Extensions Methods

Description Method Interface Use this interface to set the message-waiting indicator along with voice/fax message waiting counts If enable is true, message-waiting gets activated if not already activated. If enable is false, message-waiting gets deactivated if not already deactivated. Pre-conditions (this. getProvider ()). getState () = = Provider. IN_SERVICE Post-conditions Enables or disables the Message Waiting Indicator and sets message waiting counts. Parameters • enable - True to activate message-waiting, false to deactivate • voiceCounts - indicates if voice message counts are provided • totalNewVoiceMsgs - specifies the total number of new voice messages waiting • totalOldVoiceMsgs - specifies the total number of old voice messages waiting • highPriorityVoiceCounts - indicates if high priority voice message counts are provided • newHighPriorityVoiceMsgs - specifies the number of new high priority voice messages waiting • oldHighPriorityVoiceMsgs - specifies the number of old high priority voice messages waiting • faxCounts - indicates if fax message counts are provided • totalNewFaxMsgs - specifies the total number of new fax messages waiting • totalOldFaxMsgs - specifies the total number of old fax messages waiting • highPriorityFaxCounts - indicates if high priority fax message counts are provided • newHighPriorityFaxMsgs - specifies the number of new high priority fax messages waiting • oldHighPriorityFaxMsgs - specifies the number of old high priority fax messages waiting Throws javax. telephony. MethodNotSupportedException - This method is not supported by the given implementation. javax. telephony. InvalidStateException - The Provider is not "in service. " Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 301 Cisco Unified JTAPI Extensions Methods

Description Method Interface javax. telephony. PrivilegeViolationException - The Provider user has insufficient privileges to set the message-waiting indicator or message counts for this destination. Use this interface to set the message-waiting indicator along with voice/fax message waiting counts for the Address specified by the destination Pre-conditions (this. getProvider ()). getState () = = Provider. IN_SERVICE Post-conditions Enables or disables the Message Waiting Indicator and sets message waiting counts. Parameters • destination - DN/Address whose message-waiting indicator should be activated/deactivated • enable - True to activate message-waiting, false to deactivate • voiceCounts - indicates if voice message counts are provided • totalNewVoiceMsgs - specifies the total number of new voice messages waiting • totalOldVoiceMsgs - specifies the total number of old voice messages waiting • highPriorityVoiceCounts - indicates if high priority voice message counts are provided • newHighPriorityVoiceMsgs - specifies the number of new high priority voice messages waiting • oldHighPriorityVoiceMsgs - specifies the number of old high priority voice messages waiting • faxCounts - indicates if fax message counts are provided • totalNewFaxMsgs - specifies the total number of new fax messages waiting • totalOldFaxMsgs - specifies the total number of old fax messages waiting • highPriorityFaxCounts - indicates if high priority fax message counts are provided • newHighPriorityFaxMsgs - specifies the number of new high priority fax messages waiting • oldHighPriorityFaxMsgs - specifies the number of old high priority fax messages waiting setMessageSummary (java. lang. String destination, boolean enable, boolean voiceCounts, int totalNewVoiceMsgs, int totalOldVoiceMsgs, boolean highPriorityVoiceCounts, int newHighPriorityVoiceMsgs, int oldHighPriorityVoiceMsgs, boolean faxCounts, int totalNewFaxMsgs, int totalOldFaxMsgs, boolean highPriorityFaxCounts, int newHighPriorityFaxMsgs, int oldHighPriorityFaxMsgs) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 302 Cisco Unified JTAPI Extensions Methods

Inherited Methods From Interface javax.telephony.Address addCallObserver, addObserver, getAddressCapabilities, getCallObservers, getCapabilities, getConnections, getName, getObservers, getProvider, getTerminals, removeCallObserver, removeObserver From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Parameters • Terminal terminal: The terminal object you want to create the persistent call for. • String callerIDNumber: The number you wish to show up on the remote destination's Caller ID. • String callerIDName: The name you wish to show up on the remote destination's Caller ID. Related Documentation See Constant Field Values, on page 1667 for more information. CiscoAddressObserver Applications implement this interface to receive CiscoAddrEv events such as CiscoAddrInServiceEv 0 CiscoAddrOutOfServiceEv when observing Addresses via the Address.addObserver method. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.AddressObserver Declaration public interface CiscoAddressObserver extends javax.telephony.AddressObserver Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 303 Cisco Unified JTAPI Extensions Inherited Methods

Methods None Inherited Methods From Interface javax.telephony.AddressObserver addressChangedEvent Related Documentation See CiscoAddrInServiceEv, CiscoAddrOutOfServiceEv for more information. CiscoAddrEv The CiscoAddrEv interface extends the JTAPI core javax.telephony.events.AddrEv interface and serves as the base interface for all Cisco extended JTAPI Address events. Every Address related event in this package extends this interface, directly or indirectly. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.events.AddrEv, CiscoEv, javax.telephony.events.Ev Subinterfaces CiscoAddrAutoAcceptStatusChangedEv, CiscoAddrInServiceEv, CiscoAddrIntercomInfoChangedEv, CiscoAddrIntercomInfoRestorationFailedEv, CiscoAddrOutOfServiceEv, CiscoAddrRecordingConfigChangedEv Declaration public interface CiscoAddrEv extends CiscoEv, javax.telephony.events.AddrEv Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 304 Cisco Unified JTAPI Extensions Methods

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.AddrEv getAddress From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See javax.telephony.events.AddrEv for more information. CiscoAddrEvFilter CiscoAddrEvFilter provided for applications to set filters for address events. The application can use the following APIs to enable/disable the filters to receive the event notifications on address or to check the value Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 305 Cisco Unified JTAPI Extensions Inherited Fields

set of the filter. Application can enable the filter, if it wishes to receive the new event (CiscoAddrParkStatusEv), for the rest of the events the filter values are true by default. Interface History Description Cisco Unified Communications Manager Release Number Added this event for Park Monitoring and Assisted DPark Support feature. 7.1(1) Interface is enhanced to allow application set filter on address to enable and disable CiscoAddrVoiceMailPilotChangedEv. 7.1.(3) Enhanced with the following: • getCiscoAddrMonitoringTerminatedEvFilter() • setCiscoAddrMonitoringTerminatedEvFilter() By default the filter will be set to ‘true’ and CiscoMonitoringTerminatedEv will be delivered. To stop receiving this event applications need to set the filter to false. 8.0(1) Fields None Methods Table 48: Methods in CiscoAddrEvFilter Description Method Interface Application can invoke this API to know status of the filter for CiscoAddrParkStatusEv. Default value returned is false. getCiscoAddrParkStatusEvFilter () boolean Application can invoke this API to know the stutus of the filter for CiscoAddrIntercomInfoChangedEv. Default value is true. getCiscoAddrIntercomInfoChangedEvFilter () boolean Application can invoke this API to know the status of the filter for CiscoAddrIntercomInfoRestorationFailedEv. Default value is true. getCiscoAddrIntercomInfoRestorationFailedEvFilter () boolean Application can invoke this API to know the status of the filter for CiscoAddrMonitorTerminatedEv. Default value is true. getCiscoAddrMonitorTerminatedEvFilter () boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 306 Cisco Unified JTAPI Extensions Fields

Description Method Interface Application can invoke this API to get the status of the filter for the CiscoAddrRecordingConfigChangedEv. The default value is true. getCiscoAddrRecordingConfigChangedEvFilter () boolean This method returns true if voice mail pilot changed event filter is turned on else false. getCiscoAddrVoiceMailPilotChangedEvFilter () boolean Application can invoke this API to set the status of the filter for CiscoAddrIntercomInfoChangedEv. setCiscoAddrIntercomInfoChangedEvFilter (boolean filter value) void Application can invoke this API to set the status of the filter for CiscoAddrIntercomInfoRestorationFailedEv. setCiscoAddrIntercomInfoRestorationFailedEvFilter (boolean filter value) void Parameter Boolean setCiscoAddrMonitorTerminatedEvFilter (Boolean filterValue) void Application can invoke this API to set the status of the filter for CiscoAddrParkStatusEv. setCiscoAddrParkStatusEvFilter (Boolean filterValue) Void Application can invoke this API to set the value of the filter for CiscoAddrRecordingConfigChangedEv. setCiscoAddrRecordingConfigChangedEvFilter (boolean filter value) void This method enables or disables the address voice mail changed event. When this filter is turned on CiscoAddrVoiceMailPilotChangedEv is delivered to address observer when voice mail configuration is changed. setCiscoAddrVoiceMailPilotChangedEvFilter (boolean filterValue) void Sample Code CiscoAddress caddr

(CiscoAddress) provider.getAddress("2000"); If ( caddr ! = null ){ CiscoAddrEvFilter filter

caddr.getFilter(); filter.setCiscoAddrVoiceMailPilotChangedEvFilter(true); caddr.addObserver(myAddrObserver); } try { JtapiPeer peer

JtapiPeerFactory.getJtapiPeer ( null ); MyProviderObserver providerObserver

new MyProviderObserver (); provider

peer.getProvider ( ipaddress;login = useid;passwd = password ); if ( provider ! = null ) { provider.addObserver ( providerObserver ); provInService.waitTrue(); CiscoAddrEvFilter filter; CiscoAddress addr

provider.getAddress(S1, S1p); filter.setCiscoAddrMonitoringTerminatedEvFilter(false); addr.setFilter(filter); System.out.println(“ Current filter value is : “+ addr.getFilter().getCiscoAddrMonitoringTerminatedEvFilter()); } Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 307 Cisco Unified JTAPI Extensions Methods

Inherited Methods None Parameters The set methods take a Boolean value as the parameter. Value Range The get methods return a Boolean value (true or false). Related Documentation See Constant Field Values, on page 1667. CiscoAddrInServiceEv The CiscoAddrInServiceEv indicates that the Address is now IN_SERVICE. With Shared Lines (where the same Address appears on different Terminals), applications may receive multiple CiscoAddressInService events for all the Terminals. Applications can use this interface to find out the Terminal on which the Address (or Shared Line) is going IN_SERVICE. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.events.AddrEv, CiscoAddrEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoAddrInServiceEv extends CiscoAddrEv Fields Table 49: Fields in CiscoAddrInService Field Interface ID Static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 308 Cisco Unified JTAPI Extensions Inherited Methods

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 50: Methods in CiscoAddrInService Description Method Interface Returns the Terminal at which this Address is going IN_SERVICE. CiscoTerminal getTerminal() getTerminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.AddrEv getAddress From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Related Documentation, on page 289.getInServiceAddrTerminals() and Constant Field Values, on page 1667 for more information. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 309 Cisco Unified JTAPI Extensions Inherited Fields

CiscoAddrIntercomInfoChangedEv The system sends the CiscoAddrIntercomInfoChangedEv event to the application whenever the target DN or intercom target label changes for a CiscoIntercomAddress. The system provides this event to all of the application observers that have been added to the CiscoIntercomAddress. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.events.AddrEv, CiscoAddrEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoAddrIntercomInfoChangedEv extends CiscoAddrEv Fields Table 51: Fields in CiscoAddrIntercomInfoChangedEv Field Interface ID Static Int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 310 Cisco Unified JTAPI Extensions CiscoAddrIntercomInfoChangedEv

META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 52: Methods in CiscoAddrIntercomInfoChangedEv Description Method Interface Returns the intercom address for which the information changed. getIntercomAddress() getIntercomAddress Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.AddrEv getAddress From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See CiscoAddrEv and Constant Field Values, on page 1667 for more information. CiscoAddrIntercomInfoRestorationFailedEv The system sends the CiscoAddrIntercomInfoRestorationFailedEv event to the application when JTAPI cannot restore the application set intercom target DN or the intercom target label for the CiscoIntercomAddress during failover or fallback. The system provides this event on the application observer for the application that set the intercom target DN or the intercom target label. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 311 Cisco Unified JTAPI Extensions Methods

Superinterfaces javax.telephony.events.AddrEv, CiscoAddrEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoAddrIntercomInfoRestorationFailedEv extends CiscoAddrEv Fields Table 53: Fields in CiscoAddrIntercomInfoRestorationFailedEv Field Interface ID Static int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 54: Methods in CiscoAddrIntercomInfoRestorationFailedEv Description Method Interface This interface returns the Cisco IntercomAddress for which intercom information restoration failed. getIntercomAddress() CiscoIntercomAddress Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 312 Cisco Unified JTAPI Extensions Superinterfaces

Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.AddrEv getAddress From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 and CiscoAddrEv for additional information. CiscoAddrPickupGroupChangedEv CiscoAddrPickupGroupChangedEv is a new interface being added with Call Pickup feature development. This event is fired whenever a pickup group’s information changes, and the line info gets updated. The line info will only be updated when the line is updated with the “apply config” button in the CUCM. Interface History Description Cisco Unified Communications Manager Release Number New interface 8.0(1) Declaration public interface CiscoAddrPickupGroupChangedEv extends CiscoProvEv Methods Table 55: Methods in CiscoAddrPickupGroupChangedEv Description Method Interface This method returns the old Pickup Group information for this event. getOldPickupGroup() CiscoPickupGroup This method returns the new Pickup Group information for this event, what the pickup group has changed to. getNewPickupGroup() CiscoPickupGroup Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 313 Cisco Unified JTAPI Extensions Inherited Methods

New Error Code CTIERR_PICKUPGROUP_CHANGED CTIERR_PICKUPGROUP_DELETED CiscoAddrOutOfServiceEv The CiscoAddrOutOfServiceEv event notifies applications that an Address has gone OUT_OF_SERVICE. With Shared Lines(where the same Address appears on different Terminals), applications may receive multiple CiscoAddrOutOfServiceEv events for all the Terminals. Applications can use this interface to find out the Terminal on which the Address(or Shared Line) is going OUT_OF_SERVICE. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.events.AddrEv, CiscoAddrEv, CiscoEv, CiscoOutOfServiceEv, javax.telephony.events.Ev Declaration public interface CiscoAddrOutOfServiceEv extends CiscoAddrEv, CiscoOutOfServiceEv Fields Table 56: Fields in CiscoAddrOutOfServiceEv Field Interface ID Static int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 314 Cisco Unified JTAPI Extensions New Error Code

From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface com.cisco.jtapi.extensions.CiscoOutOfServiceEv CAUSE_CALLMANAGER_FAILURE,CAUSE_CTIMANAGER_FAILURE,CAUSE_DEVICE_FAILURE, CAUSE_DEVICE_RESTRICTED, CAUSE_DEVICE_UNREGISTERED, CAUSE_LINE_RESTRICTED, CAUSE_NOCALLMANAGER_AVAILABLE, CAUSE_REHOME_TO_HIGHER_PRIORITY_CM, CAUSE_REHOMING_FAILURE From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 57: Methods in CiscoAddrOutOfServiceEv Description Method Interface Returns the Terminal at which this Address is going OUT_OF_SERVICE. getTerminal() CiscoTerminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.AddrEv getAddress From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 315 Cisco Unified JTAPI Extensions Methods

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 and Related Documentation, on page 289.getInServiceAddrTerminals() for more information. CiscoAddrParkStatusEv When parking a call using the Cisco Unified IP Phone, JTAPI reports park states by using this event. It is provided to all the applications, which have address observers added on the address, which has invoked park. This event gets delivered only when park gets invoked from Cisco Unified IP Phones. Interface History Description Cisco Unified Communications Manager Release Number Added interface for Park Monitoring and Assisted DPark feature. 7.1(1 and 2) Declaration public interface CiscoAddrParkStatusEv extends CiscoAddrEv Fields Table 58: Fields in CiscoAddrParkStatusEv Description Field Interface Park status when the call is parked. PARKED static int Park status when the park monitoring reversion timer expires. REMINDER static int Park status when the parked call is retrieved by the parker or a third party. RETRIEVED static int Park status when the parked call is forwarded when the park monitoring forward- no-retrieve timer expires. FORWARDED static int Park status when the parked call is disconnected. ABANDONED static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 316 Cisco Unified JTAPI Extensions Related Documentation

Inherited Fields None Methods Table 59: Methods in CiscoAddrParkStatusEv Description Method Interface Returns the current park state of the parked call. getParkState() int Returns an id which is unique for a particular parked call. Transaction ID would remain the same in the different park states for the same parked call. getTransactionID() int Returns CiscoCallID. getCiscoCallID() CiscoCallID Returns the DN where call is parked. getParkDN() String Returns the partition of the Park DN. getParkDNPartition() String Returns the DN of the parked party. getParkedParty() String Returns the partition of the Parked party. getParkedPartyPartition() String Returns the terminal on whose address this event is delivered. getTerminal() Terminal Value Ranges The following are values of fields: • PARKED: 2 • REMINDER: 3 • RETRIEVED: 4 • ABANDONED: 5 • FORWARDED: 6 Related Documentation See Constant Field Values, on page 1667 for more information. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 317 Cisco Unified JTAPI Extensions Inherited Fields

CiscoAddrRecordingConfigChangedEv The system delivers the CiscoAddrRecordingConfigChangedEv event to the Address Observer if the recording setting on the Address changes. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.events.AddrEv, CiscoAddrEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoAddrRecordingConfigChangedEv extends CiscoAddrEv Fields Table 60: Fields in CiscoAddrRecordingConfigChangedEv Field Interface ID static int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 318 Cisco Unified JTAPI Extensions CiscoAddrRecordingConfigChangedEv

META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 61: Methods in CiscoAddrRecordingConfigChangedEv Description Method Interface Returns the new recording configuration on this Address. The value is one of the following: • CiscoAddress.NO_RECORDING • CiscoAddress.AUTO_RECORDING • CiscoAddress.APPLICATION_CONTROLLED_RECORDING getRecordingConfig() Int Returns the Terminal on which the recording configuration changed. getTerminal() javax.telephony.Terminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.AddrEv getAddress From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 and CiscoAddrEv for more information. CiscoAddrRemovedEv JTAPI sends the CiscoAddrRemovedEv event when an Address gets removed from the Provider domain. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 319 Cisco Unified JTAPI Extensions Methods

Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoAddrRemovedEv extends CiscoProvEv Fields Table 62: Fields in CiscoAddrRemovedEv Field Interface ID static int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 63: Methods in CiscoAddrRemovedEv Description Method Field Returns the Address that is removed from provider domain and the address which is removed from the user control list. getAddress() javax.telephony.Address Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 320 Cisco Unified JTAPI Extensions Superinterfaces

Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. CiscoAddrRemovedFromTerminalEv The system sends the CiscoAddrRemovedFromTerminalEv event under the following conditions: • When an Administrator removes a Terminal from the user control list that contains a Shared Line. • When an Extension Mobility (EM) user logs out from a Terminal with a profile that contains a Shared Line, this event notifies that one of the Terminals got removed from an existing Address. • When a Shared Line is removed from a Terminal that is in a user control list. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoAddrRemovedFromTerminalEv extends CiscoProvEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 321 Cisco Unified JTAPI Extensions Inherited Methods

Fields Table 64: Fields in CiscoAddrRemovedFromTerminalEv Field Interface ID Static int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 65: Methods in CiscoAddrRemovedFromTerminalEv Description Method Interface Returns the Address from which the Terminal got removed. getAddress() javax.telephony.Address Returns the Terminal that got removed from the Address. getTerminal() javax.telephony.Terminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 322 Cisco Unified JTAPI Extensions Fields

From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See also Constant Field Values, on page 1667 for more information. CiscoAddrRestrictedEv If an Address is observed and the restriction status is changed to restricted, the system sends this event to the application. Applications will see this event whenever an Address or an associated Terminal is Restricted from Cisco Unified Communications Manager Administration. For restricted lines, the Address will go OUT_OF_SERVICE and will not come back IN_SERVICE until it is activated again. If an Address is restricted, addCallObserver and addObserver will throw an exception. For shared lines, if a few shared lines are restricted, and others are not, the system does not throw an exception but the restricted shared lines will not receive any events. If all shared lines are restricted, an exception is thrown when application try adding observers. If an Address gets restricted after observers are added, applications will see CiscoAddrOutOfServiceEv, and when the Address is activated, the Address will go IN_SERVICE. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces CiscoEv, CiscoProvEv, CiscoRestrictedEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoAddrRestrictedEv extends CiscoRestrictedEv Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 323 Cisco Unified JTAPI Extensions Related Documentation

Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoRestrictedEv CAUSE_UNKNOWN, CAUSE_UNSUPPORTED_DEVICE_CONFIGURATION, CAUSE_UNSUPPORTED_PROTOCOL, CAUSE_USER_RESTRICTED From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE,CAUSE_SNAPSHOT, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE,CAUSE_SNAPSHOT, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 66: Methods in CiscoAddrRestrictedEv Description Method Interface Returns the Address which is changed to Restricted on Cisco Unified Communications Manager. getAddress() javax.telephony.Address Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 324 Cisco Unified JTAPI Extensions Inherited Fields

Related Documentation See Constant Field Values, on page 1667 for more information. CiscoAddrRestrictedOnTerminalEv If the user has Shared lines in the control list, and one of those lines is marked restricted on Cisco Unified Communications Manager, the system sends this event. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces CiscoEv, CiscoProvEv, CiscoRestrictedEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoAddrRestrictedOnTerminalEv extends CiscoRestrictedEv Fields Table 67: Fields in CiscoAddrRestrictedOnTerminalEv Field Interface ID Static int Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoRestrictedEv CAUSE_UNKNOWN, CAUSE_UNSUPPORTED_DEVICE_CONFIGURATION, CAUSE_UNSUPPORTED_PROTOCOL, CAUSE_USER_RESTRICTED From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE,CAUSE_SNAPSHOT, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 325 Cisco Unified JTAPI Extensions Related Documentation

META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE,CAUSE_SNAPSHOT, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 68: Methods in CiscoAddrRestricedOnTerminalEv Description Method Interface Returns the Address that is restricted. getAddress() javax.telephony.Address Returns the Terminal on which the Address is restricted. getTerminal() javax.telephony.Terminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. CiscoAddrVoiceMailPilotChangedEv This event indicates that the voice mail pilot configuration on address is changed and is delivered to address observer. Application needs to enable the corresponding filter in CiscoAddrEvFilter to receive this event. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 326 Cisco Unified JTAPI Extensions Methods

Interface History Description Cisco Unified Communications Manager Release Number New interface. 7.1(3) Sample Code: class myAddrObserver extends CiscoAddressObserver { public synchronized void addressChangedEvent ( AddrEv [] eventList ) { if ( eventList[i] instanceof CiscoAddrVoiceMailPilotChangedEv){ CiscoAddrVoiceMailPilotChangedEv ev

(CiscoAddrVoiceMailPilotChangedEv) eventList[i]; Address cAddr

ev.getAddress(); String newVoiceMailPilot

ev.getVoiceMailPilot(); System.out.println(" New voice mail pilot for " + ev.getAddress() + " is " + newVoiceMailPilot ); } } } Superinterfaces NA Declaration NA Fields Table 69: Fields in CiscoAddrVoiceMailPilotChangedEv Field Interface Inherited Fields Methods Table 70: Methods in CiscoAddrVoiceMailPilotChangedEv Description Method Interface This method returns the new voice mail pilot of the address. getVoiceMailPilot() String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 327 Cisco Unified JTAPI Extensions Superinterfaces

Inherited Methods Related Documentation See Constant Field Values, on page 1667 for more information. CiscoAnnouncementStartedEv CiscoAnnouncementStartedEv is a new JTAPI event that is delivered to applications as a Call Event. This new event is delivered to call observers added by applications to notify when a play announcement starts. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes 10.01 Declaration Public interface CiscoAnnouncementStartedEv extends CiscoCallEv. Methods Description Method Interface This interface returns the name of the announcement identifier. getAnnouncementID () String CiscoAnnouncementEndedEv CiscoAnnouncementEndedEv is a new JTAPI event that is delivered to applications as a Call Event. This new event is delivered to call observers added by applications to notify when play announcement ends. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes 10.01 Declaration Public interface CiscoAnnouncementEndedEv extends CiscoCallEv. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 328 Cisco Unified JTAPI Extensions Inherited Methods

Methods Description Method Interface This interface returns whether or not the play announcement was successful. Returns true if there are no errors with the play announcement, or returns false indicating error. getSuccess() boolean This interface returns the error code indicating the cause of the failure/error with play announcment. This maps to one of the values defined in CiscoJtapiException. getErrorCode() int This interface returns the string corresponding to what the error code maps to. getErrorDescription() String CiscoAnnouncementErrorEv CiscoAnnouncementErrorEv is a new JTAPI event that is delivered to applications as a Call Event. This new event is delivered to call observers added by applications to notify when an error occurs during play announcement. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes 10.01 Declaration Public interface CiscoAnnouncementErrorEv extends CiscoCallEv. Methods Description Method Interface This interface returns the error code indicating the cause for the failure/error with play announcment. This maps to one of the values defined in CiscoJtapiException. getErrorCode() Int This interface returns the string corresponding to what the error code maps to. getErrorDescription() String CiscoBaseMediaTerminal The CiscoBaseMediaTerminal interface extends the CiscoTerminal interface. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 329 Cisco Unified JTAPI Extensions Methods

Interface History Description Cisco Unified Communications Manager Release Number New interface. 8.5(1) Declaration public interface CiscoBaseMediaTerminal extends CiscoTerminal Superinterfaces NA Fields Table 71: Fields in CiscoBaseMediaTerminal Field Interface NO_MEDIA_REGISTRATION Final static int DYNAMIC_MEDIA_REGISTRATION Final static int DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT Final static int STATIC_MEDIA_REGISTRATION Final static int STATIC_MEDIA_REGISTRATION_FOR_GET_PORT SUPPORT Final static int Inherited Fields NA Methods Table 72: Methods in CiscoBaseMediaTerminal Method Interface getRegistrationType() int register(java.net.InetAddress address, int port, CiscoMediaCapability[] capabilities, int registrationType), int[] algorithmIDs, java.net.InetAddress address_v6, int activeAddressingMode) throws CiscoRegistrationException, PrivilegeViolationException; void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 330 Cisco Unified JTAPI Extensions Declaration

Inherited Methods NA Parameters • register() • Java.net.InteAddress address • int port • CiscoMediaCapability[] capabilities • int[] algorithmIDs • Java.net.InteAddress address_v6 • int activeAddressingMode • int registrationType Data Types • Java.net.InteAddress address • int port • CiscoMediaCapability[] capabilities • int[] algorithmIDs • Java.net.InteAddress address v6 • int activeAddressingMode • int registrationType Range of Values • activeAddressingMode: • CiscoTerminal.IP_ADDRESSING_MODE_IPv4 or • CiscoTerminal.IP_ADDRESSING_MODE_IPv6 or • CiscoTerminal.IP_ADDRESSING_MODE_IPv4_v6 • registrationType: • CiscoTerminal.NO_MEDIA_REGISTATION (applicable only for route points) • CiscoTerminal.DYNAMIC_MEDIA_REGISTRATION • CiscoTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT • CiscoTerminal.STATIC_MEDIA_REGISTRATION Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 331 Cisco Unified JTAPI Extensions Inherited Methods

• CiscoTerminal.STATIC_MEIDA_TERMINAL_FOR_GET_PORT_SUPPORT CiscoCall The CiscoCall interface extends the CallControlCall interface with additional Cisco Unified Communications Manager specific capabilities. In Cisco Unified Communications Manager, every Call object comprises a set of call legs that share a common identifier: the global call handle. Connection objects represent call legs in JTAPI, and the Call object that relates a set of connections contains the global call handle that the underlying call legs share. The global call handle within a CiscoCall is accessible by using CallManagerID and CallID properties. Taken together, the CallManagerID and CallID form the global call handle that Cisco Unified Communications Manager maintains. Consider this pair of properties as guaranteed to be unique among all ACTIVE Call objects, but when an ACTIVE call becomes INACTIVE, its CallManagerID and CallID may be reused to identify a newly created Call object. Therefore, an INACTIVE Call can have identical CallManagerID and CallID properties to those of a currently ACTIVE Call object. Interface History Description Cisco Unified Communications Manager Release Number Two new APIs: CiscoMultiMediaCapabilityInfogetCallingTerminalMultiMediaCapabilityInfo() Returns the calling party terminal multimedia capability. CiscoMultiMediaCapabilityInfogetCalledTerminalMultiMediaCapabilityInfo() Returns the called party terminal multimedia capability. Three new constants: CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_NONE CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_G 10.0(1) Five new constants: CALL_RECORDING_TYPE_NONE CALL_RECORDING_TYPE_AUTOMATIC CALL_RECORDING_TYPE_APPLICATION_INITIATED_SILENT CALL_RECORDING_TYPE_USER_INITIATED_FROM_APPLICATION CALL_RECORDING_TYPE_USER_INITIATED_FROM_DEVICE 9.0(1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 332 Cisco Unified JTAPI Extensions CiscoCall

Description Cisco Unified Communications Manager Release Number Enhanced with the following: New methods that allow applications to get the Terminals associated with the current calling and current called parties on the call. New API to indicate whether the call is created due to CallFwdAll key press or not. Three new constants, CFWD_ALL_NONE, CFWD_ALL_SET, and CFWD_ALL_CLEAR, have been introduced for CiscoCall interface. 8.0(1) Added new method called isConference() for Drop Any Party feature. 7.1(1) Superinterfaces javax.telephony.Call, javax.telephony.callcontrol.CallControlCall, CiscoObjectContainer Subinterfaces CiscoConsultCall Declaration public interface CiscoCall extends javax.telephony.callcontrol.CallControlCall, CiscoObjectContainer Fields Table 73: Fields in CiscoCall Description Field Return Type This constant is used when silent is the recording invocation type. Silent recording is the default value in releases prior to Release 9.0. CALL_RECORDING_TYPE_APPLICATION_INITIATED_SILENT static int This constant is used when recording is invoked automatically by Unified CM, as a result of the line configuration. CALL_RECORDING_TYPE_AUTOMATIC static int This constant is used when a call is not recorded. CALL_RECORDING_TYPE_NONE static int This constant is used when user is the recording invocation type, and the request was invoked by an application. CALL_RECORDING_TYPE_USER_INITIATED_FROM_APPLICATION static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 333 Cisco Unified JTAPI Extensions Superinterfaces

Description Field Return Type This constant is used when recording was invoked on the Cisco IP device. CALL_RECORDING_TYPE_USER_INITIATED_FROM_DEVICE static int Call security status is authenticated. CALLSECURITY_AUTHENTICATED static int Call security status is encrypted. CALLSECURITY_ENCRYPTED static int Call security status is not authenticated. CALLSECURITY_NOTAUTHENTICATED static int Call security status is unknown. CALLSECURITY_UNKNOWN static int When call is not created due to CallFwdAll soft key press. Value is 0. CFWD_ALL_NONE public static final int When call is created due to CallFwdAll key press to set CFA. Value is 64. CFWD_ALL_SET public static final int When call is created to CallFwdAll key press to clear/cancel CFA. Value is 128. CFWD_ALL_CLEAR public static final int Feature priority is emergency FEATUREPRIORITY_EMERGENCY Static int Feature priority is normal FEATUREPRIORITY_NORMAL Static int Feature priority is urgent FEATUREPRIORITY_URGENT Static int This interface indicates if call is created due to callFWDAll Key press. It returns one of the following: • CiscoCall.CFWD_ALL_NONE • CiscoCall.CFWD_ALL_SET • CiscoCall.CFWD_ALL_CLEAR getCFwdAllKeyPressIndicator() int A tone plays to both the caller and the monitor target (agent) when this option gets used. PLAYTONE_BOTHLOCALANDREMOTE Static int A tone plays only to the monitor target (agent) when this option gets used. PLAYTONE_LOCALONLY Static int When this option is used no tone plays to the monitor target (agent) or the caller. PLAYTONE_NOLOCAL_OR_REMOTE Static int A tone plays only to the caller when this option gets used. PLAYTONE_REMOTEONLY Static int This option indicates that silent monitor is requested. SILENT_MONITOR Static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 334 Cisco Unified JTAPI Extensions Fields

Description Field Return Type This option indicates that there is no Media Forking Device for recording on this call. Range of value = 0 CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_NONE static final int This option indicates that the Media Forking Device type for recording on this call is Phone (BIB Recording). Range of value = 1 CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE static final int This option indicates that the Media Forking Device type for recording on this call is Gateway (GW Recording). Range of value = 2 CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW static final int Inherited Fields From Interface javax.telephony.Call ACTIVE, IDLE, INVALID Sample Code public class MyCallObserver implements implements CallObserver, CallControlCallObserver, MediaCallObserver { public void callChangedEvent (CallEv[] evlist) { for(int i = 0; evlist ! = null && i < evlist.length; i++){ … … If (evlisth[i] instance of TermConnActiveEv){ CiscoCall thisCall

(CiscoCall) ((TermConnActiveEv) evlist[i]).getCall(); int cfaStatus

thisCall.getCFWDAllKeyPressIndicator(); If (cfaStatus

= CiscoCall.CFWD_ALL_SET || cfaStatus

= CiscoCall.CFWD_ALL_CLEAR){ System.out.println(“Call is created due to CallFwdAll soft key press”); }else { System.out.println(“Call is NOT created due to CallFwdAll soft key press”); } } } … … } Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 335 Cisco Unified JTAPI Extensions Inherited Fields

Methods Table 74: Methods in CiscoCall Description Method Interface This interface conferences multiple calls together, resulting in the union of the participants of all the calls being placed on a single call. conference (javax. telephony. Call[]otherCalls) Void Returns True if it is a conference call, false or otherwise. isConference () java. lang. boolean This method overloads Call. connect (). It takes a new parameter featurePriority. The featurePriority parameter may be: CiscoCall. FEATUREPRIORITY_NORMAL CiscoCall. FEATUREPRIORITY_URGENT CiscoCall. FEATUREPRIORITY_EMERGENCY Throws: javax. telephony. ResourceUnavailableException, javax. telephony. PrivilegeViolationException, javax. telephony. InvalidPartyException, javax. telephony. InvalidArgumentException, javax. telephony. InvalidStateException, javax. telephony. MethodNotSupportedException connect (javax. telephony. Terminal origterm, javax. telephony. Addressorigaddr java. lang. String. dialedDigits int featurePriority) javax. telephony. Connection[] Returns the Presentation Indicator (PI) that is associated with getCalledAddressPI. getCalledAddressPI () boolean Returns the PartyInfo of the called party of the call. getCalledPartyInfo () CiscoPartyInfo CallID is a unique identifier among all ACTIVE calls with the same CallManagerID. getCallID () CiscoCallID Returns the Presentation Indicator (PI) that is associated with getCallingAddressPI. getCallingAddressPI () boolean This interface returns the SecurityStatus of the Call. getCallSecurityStatus () int This interface returns a CiscoConferenceChain object if this Call is a chained conference Call. getConferenceChain () CiscoConference Chain Returns the current called Address for the call. getCurrentCalledAddress () javax. telephony. Address Returns the Presentation Indicator (PI) that is associated with CurrentCalledAddress. getCurrentCalledAddressPI () boolean Returns the Presentation Indicator (PI) that is associated with getCurredCalledDisplayNamePI. getCurrentCalledDisplayNamePI () boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 336 Cisco Unified JTAPI Extensions Methods

Description Method Interface This interface returns the display name of the called party in the call. getCurrentCalledPartyDisplayName () java. lang. String Returns the PartyInfo of the current called party of the call. getCurrentCalledPartyInfo () CiscoPartyInfo Returns the Unicode display name of the called party in the call. getCurrentCalledPartyUnicodeDisplayName () java. lang. String Returns the locale of the current called party Unicode display name. getCurrentCalledPartyUnicodeDisplayNamelocale () int Returns the current calling Address for the call. getCurrentCallingAddress () javax. telephony. Address Returns the Presentation Indicator (PI) that is associated with getCurrentCallingAddressPI. getCurrentCallingAddressPI () boolean Returns the Presentation Indicator (PI) that is associated with getCurrentCalledDisplayNamePI. getCurrentCallingDisplayNamePI () boolean This interface returns the display name of the calling party. getCurrentCallingPartyDisplayName () java. lang. String Returns the PartyInfo of the current calling party of the call. getCurrentCallingPartyInfo () CiscoPartyInfo Returns the Unicode display name of the calling party in the call. getCurrentCallingPartyUnicodeDisplayName () java. lang. String Returns the locale of the current called party Unicode display name. getCurrentCallingPartyUnicodeDisplayNamelocale () int This method returns a Terminal object that represents the terminal of the calling party on the call. By default, if the terminal is not defined, these will return null. An example of when this would occur is when a phoen goes offhook, and a one-sided call is created. The CalledTerminal would be null in this scenario. The terminal for the called party is only set AFTER the called party answers a call. getCurrentCallingTerminal () Terminal This method returns a Terminal object that represents the terminal of the called party on the call. By default, if the terminal is not defined, these will return null. An example of when this would occur is when a phoen goes offhook, and a one-sided call is created. The CalledTerminal would be null in this scenario. The terminal for the called party is only set AFTER the called party answers a call. getCurrentCalledTerminal () Terminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 337 Cisco Unified JTAPI Extensions Methods

Description Method Interface This will return the globalizedCallingParty getGlobalizedCallingParty () java. lang. String Returns the PartyInfo of the last redirecting party of the call. getLastRedirectedPartyInfo () CiscoPartyInfo Returns the Presentation Indicator (PI) that is associated with getLastRedirectingAddressPI. getLastRedirectingAddressPI () boolean Deprecated. - use getLastRedirectedPartyInfo (); getLastRedirectingPartyInfo () CiscoPartyInfo This interface returns the modified called Address for the call if called party is modified by using called party transformation pattern or other means. getModifiedCalledAddress () javax. telephony. Address This interface returns the modified calling Address for the call if an application modifies its calling party by using the selectRoute API or other means. getModifiedCallingAddress () javax. telephony. Address This interface returns true if the call is a persistent call and false if the call is a normal call. isPersistentCall () boolean If the application has the information about the call at the monitor target, the application can use this interface to monitor calls. startMonitor (javax. telephony. TerminalMonitorInitiatorterminal, javax. telephony. AddressMonitorInitiatoraddress, intmonitorTargetcallid, java. lang. StringmonitorTargetDN, java. lang. StringmonitorTargetTerminalName, intmonitorType, intplayToneDirection) javax. telephony. Connection[] If the application is observing the monitor target (agent) Address, the application can use the Terminal connection of the monitor target (agent) to initiate a monitor request. startMonitor (javax. telephony. TerminalMonitorInitiatorterminal, javax. telephony. AddressMonitorInitiatoraddress, javax. telephony. TerminalConnectiontermConnofMonitorTarget, intmonitorType, intPlayToneDirection) javax. telephony. Connection[] This method is similar to the CallControlCall. transfer (String address) interface except that it also takes facCode (Forced Authorization Code) and cmcCode (Client Matter Code) if the transfer Address requires these codes to offer the call. transfer (java. lang. Stringaddress, java. lang. StringfacCode, java. lang. StringcmcCode) javax. telephony. Connection Returns the calling party terminal multimedia capability. getCallingTerminalMultiMediaCapabilityInfo () CiscoMultiMedia CapabilityInfo Returns the called party terminal multimedia capability. getCalledTerminalMultiMediaCapabilityInfo () CiscoMultiMedia CapabilityInfo In Cisco Unified JTAPI implementation, CallControlCall.getCalledAddress() returns the first called party of the call which is the original called party. Note Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 338 Cisco Unified JTAPI Extensions Methods

Inherited Methods From Interface javax.telephony.callcontrol.CallControlCall addParty, conference, consult, consult, drop, getCalledAddress, getCallingAddress, getCallingTerminal, getConferenceController, getConferenceEnable, getLastRedirectedAddress, getTransferController, getTransferEnable, offHook, setConferenceController, setConferenceEnable, setTransferController, setTransferEnable, transfer, transfer From Interface javax.telephony.Call addObserver, connect, getCallCapabilities, getCapabilities, getConnections, getObservers, getProvider, getState, removeObserver From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Parameters • origterm - • origaddr - • dialedDigits - • featurePriority - Conference Controller For the conferencing feature to happen, a common participant must belong to all the Calls, as represented TerminalConnection of common participants on controller Terminal. These TerminalConnections are known as the conference controllers. At the most, only one of TerminalConnection on the Calls at controller Terminal would be in CallControlTerminalConnection.TALKING state, and hence, the TerminalConnection on the secondary Call should be in the CallControlTerminalConnection.HELD state. As a result of invokation of this method, all the conference controller TerminalConnection merge into one TerminalConnection. Applications can set which Terminal would acts as the conference controller when a conference call gets set up by setting up Conference controller TerminalConnection via invoking CallControlCalll.setConferenceController() method. The CalControlCall.getConferenceController() method returns the current conference controller, or null if there is none. If no conference controller is set initially, the implementation chooses a suitable TerminalConnection when the conferencing feature is invoked. Telephone Call Argument All participants from the secondary Calls, passed as the argument to this method, move to the Call on which this method was invoked. That is, new Connections and TerminalConnections for the participant in the secondary Calls are created on this Call. The Connections and TerminalConnections on the secondary Calls get removed from the Call, and the Call moves to the Call.INVALID state. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 339 Cisco Unified JTAPI Extensions Inherited Methods

Other Shared Participants There may exist other Addresses and Terminals that are part of some calls in addition to the designated conference controller. In these instances, those participants that are shared between both Calls are merged into one. That is, the Connections and TerminalConnections on this Calls stay unchanged. The corresponding Connections and TerminalConnections on the secondary Calls get removed from that Call. Pre-Conditions 1. Let tc1 be the conference controller on this Call 2. Let connection1 = tc1.getConnection() 3. Let tc2 to tcN be the conference controllers on otherCalls 4. (this.getProvider()).getState() = = Provider.IN_SERVICE 5. this.getState() = = Call.ACTIVE 6. tc1.getTerminal() = = tc2.getTerminal()... = tcN.getTerminal 7. tc1.getCallControlState() = = CallControlTerminalConnection.TALKING/HELD 8. tc2-tcN.getCallControlState() = = CallControlTerminalConnection.HELD/TALKING 9. this ! = otherCalls Post-Conditions 1. (this.getProvider()).getState() = = Provider.IN_SERVICE 2. this.getState() = = Call.ACTIVE 3. otherCall.getState() = = INVALID 4. Let c[] be the Connections to be merged from otherCall 5. Let tc[] be the TerminalConnections to be merged from otherCall 6. Let new(c) be the set of new Connections created on this Call 7. Let new(tc) be the set of new TerminalConnections created on this Call 8. new(c) element of this.getConnections() 9. new(c).getCallState() = = c.getCallState() 10. new(tc) element of (this.getConnections()).getTerminalConnections() 11. new(tc).getCallState() = = tc.getCallState() 12. c[i].getCallControlState() = = CallControlConnection.DISCONNECTED for all i 13. tc[i].getCallControlState() = = CallControlTerminalConnection.DROPPED for all i 14. CallInvalidEv is delivered for otherCall 15. CallCtlConnDisconnectedEv/ConnDisconnectedEv is delivered for all c[i] 16. CallCtlTermConnDroppedEv/TermConnDroppedEv is delivered for all tc[i] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 340 Cisco Unified JTAPI Extensions Other Shared Participants

ConnCreatedEv is delivered for all new(c) 18. TermConnCreatedEv is delivered for all new(tc) 19. Appropriate events are delivered for all new(c) and new(tc) Parameters otherCalls - The Other Calls which are to be merged with this Call object. Throws javax.telephony.InvalidArgumentException - The Call object that is provided is not valid for the conference. javax.telephony.InvalidStateException - Thismeans that the Provider is not "in service, " the Call is not "active, " or the conference controllers are not in the proper state. javax.telephony.MethodNotSupportedException - The implementation does not support this method. javax.telephony.PrivilegeViolationException - The application does not have the proper authority to invoke this method. javax.telephony.ResourceUnavailableException - This means that an internal resource that is necessary for the successful invocation of this method is not available. See Also ConnCreatedEv, TermConnCreatedEv, ConnDisconnectedEv, TermConnDroppedEv, CallInvalidEv, CallCtlConnDisconnectedEv, CallCtlTermConnDroppedEv javax.telephony.Connection transfer(java.lang.Stringaddress java.lang.StringfacCode, java.lang.StringcmcCode) Throws for connect(Terminal, Address, String, CiscoRTPParams) javax.telephony.InvalidArgumentException, javax.telephony.InvalidStateException, javax.telephony.InvalidPartyException, javax.telephony.MethodNotSupportedException, javax.telephony.PrivilegeViolationException, javax.telephony.ResourceUnavailableExceptionThis method is similar to the CallControlCall.transfer(String address) interface except that it also takes facCode (Forced Authorization Code) and cmcCode (Client Matter Code) if the transfer Address requires these codes to offer the call. If only one of the codes is required, the other code may need to be a null value. If the user enters no codes, or invalid codes, the call may not be offered and platformException may contain the following error codes: CiscoJTAPIException.CTIERR_FAC_CMC_REASON_FAC_NEEDED CiscoJTAPIException.CTIERR_FAC_CMC_REASON_CMC_NEEDED CiscoJTAPIException.CTIERR_FAC_CMC_REASON_FAC_CMC_NEEDED CiscoJTAPIException.CTIERR_FAC_CMC_REASON_FAC_INVALID CiscoJTAPIException.CTIERR_FAC_CMC_REASON_CMC_INVALID This overloaded version of this method transfers all participants currently on this Call, with the exception of the transfer controller participant, to another Address. This is often called a "single-step transfer" because the transfer feature places another call and performs the transfer simultaneously. The Address string argument to this method must be valid and complete. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 341 Cisco Unified JTAPI Extensions Other Shared Participants

The Transfer Controller The transfer controller for this version of this method represents the participant on this Call around which the transfer is taking place and who drops off the Call after the transfer has completed. The transfer controller is a TerminalConnection that must be in the CallControlTerminalConnection.TALKING state. Applications may control which TerminalConnection acts as the transfer controller via the CallControlCall.setTransferController() method. The CallControlCall.getTransferController() method returns the current transfer controller, or null if there is none. If no transfer controller is set, the implementation chooses a suitable TerminalConnection when the transfer feature gets invoked. When the transfer feature gets invoked, the transfer controller moves into the CallControlTerminalConnection.DROPPED state. If it is the only TerminalConnection associated with its Connection, then its Connection moves into the CallControlConnection.DISCONNECTED state as well. The New Connection This method creates and returns a new Connection representing the party to which the Call was transferred. This Connection may be null if the Call has been transferred outside of the Provider domain and can no longer be tracked. This Connection must at least be in the CallControlConnection.IDLE state. The Connection state may have progressed beyond "idle" before this method returns, and should be reflected by an event. This new Connection will progress as any normal destination Connection on a call. Typical scenarios for this Connection are described by the Call.connect() method. Pre-Conditions 1. Let tc be the transfer controller on this Call 2. (this.getProvider()).getState() = = Provider.IN_SERVICE 3. this.getState() = = Call.ACTIVE 4. tc.getCallControlState() = = CallControlTerminalConnection.TALKING Post-Conditions 1. Let newconnection be the Connection created and returned 2. Let connection = = tc.getConnection() 3. (this.getProvider()).getState() = = Provider.IN_SERVICE 4. this.getState() = = Call.ACTIVE 5. tc.getCallControlState() = = CallControlTerminalConnection.DROPPED 6. If connection.getTerminalConnections().length = = 1, then connection.getCallControlState() = = CallControlConnection.DISCONNECTED 7. newconnection is an element of this.getConnections(), if not null. 8. newconnection.getCallControlState() at least CallControlConnection.IDLE, if not null. 9. ConnCreatedEv is delivered for newconnection 10. CallCtlTermConnDroppedEv/TermConnDroppedEv is delivered for tc Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 342 Cisco Unified JTAPI Extensions The Transfer Controller

CallCtlConnDisconnectedEv/ConnDisconnectedEv is delivered for connection if no other TerminalConnections Parameters • address - The destination Address string(dialedDigits) to which the Call is being transferred. • facCode - The Force Authorization Code • cmcCode - The Client Matter Code Returns The new Connection associated with the destination, or null. Throws javax.telephony.InvalidArgumentException - The TerminalConnection provided as controlling the transfer is not valid or not part of this Call. javax.telephony.InvalidStateException - This means that the Provider is not "in service, " the Call is not "active, " or the transfer controller is not "talking." javax.telephony.InvalidPartyException - The destination Address is not valid or complete. javax.telephony.MethodNotSupportedException - The implementation does not support this method. javax.telephony.PrivilegeViolationException - The application does not have the proper authority to invoke this method. javax.telephony.ResourceUnavailableException - An internal resource necessary for the successful invocation of this method is unavailable. See Also ConnCreatedEv, ConnDisconnectedEv, TermConnDroppedEv, CallCtlConnDisconnectedEv, CallCtlTermConnDroppedEv getCurrentCalledAddressPIboolean getCurrentCalledAddressPI()Returns the Presentation Indicator(PI) that is associated with CurrentCalledAddress. If it returns true, the application can display this Address name to the end users. If it returns false, the application should not display this Address name to end users. getCurrentCalledDisplayNamePIboolean getCurrentCalledDisplayNamePI()Returns the Presentation Indicator(PI) that is associated with getCurredCalledDisplayNamePI. If it returns true, the application can display this DisplayName to the end users. If it returns false, the application should not display this DisplayName to the end users. getCurrentCallingAddressPIboolean getCurrentCallingAddressPI()Returns the Presentation Indicator(PI) that is associated with getCurrentCallingAddressPI. If it returns true, the application can display this Address name to the end users. If it returns false, the application should not display this Address name to the end users. getCurrentCallingDisplayNamePIboolean getCurrentCallingDisplayNamePI()Returns the Presentation Indicator(PI) that is associated with getCurrentCalledDisplayNamePI. If it returns true, the application can display this DisplayName to the end users. If it returns false, the application should not display this DisplayName to the end users. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 343 Cisco Unified JTAPI Extensions The New Connection

getLastRedirectingAddressPIboolean getLastRedirectingAddressPI()Returns the Presentation Indicator(PI) that is associated with getLastRedirectingAddressPI. If it returns true, the application can display this Address name to the end users. If it returns false, the application should not display this Address name to the end users. getCalledAddressPIboolean getCalledAddressPI()Returns the Presentation Indicator(PI) that is associated with getCalledAddressPI. If it returns true, the application can display this Address name to the end users If it returns false, the application should not display this Address name to the end users. getCallingAddressPIboolean getCallingAddressPI()Returns the Presentation Indicator(PI) that is associated with getCallingAddressPI. If it returns true, the application can display this Address name to the end users. If it returns false, the application should not display this Address name to the end users. getCurrentCalledPartyUnicodeDisplayNamejava.lang.String getCurrentCalledPartyUnicodeDisplayName()Returns the Unicode display name of the called party in the call. It returns null if the display name is unknown. getCurrentCalledPartyUnicodeDisplayNamelocaleint getCurrentCalledPartyUnicodeDisplayNamelocale()Returns the locale of the current called party Unicode display name. CiscoLocale interface lists the supported locales. getCurrentCallingPartyUnicodeDisplayNamejava.lang.String getCurrentCallingPartyUnicodeDisplayName()Returns the Unicode display name of the calling party in the call. It returns null if the display name is unknown. getCurrentCallingPartyUnicodeDisplayNamelocaleint getCurrentCallingPartyUnicodeDisplayNamelocale()Returns the locale of the current called party Unicode display name. getCurrentCallingPartyInfoCiscoPartyInfo getCurrentCallingPartyInfo()Returns the PartyInfo of the current calling party of the call. getCurrentCalledPartyInfoCiscoPartyInfo getCurrentCalledPartyInfo()Returns the PartyInfo of the current called party of the call. getLastRedirectingPartyInfoCiscoPartyInfo getLastRedirectingPartyInfo()Deprecated.- use getLastRedirectedPartyInfo(); Returns the PartyInfo of the last redirecting party of the call. getLastRedirectedPartyInfoCiscoPartyInfo getLastRedirectedPartyInfo()Returns the PartyInfo of the last redirecting party of the call. getCalledPartyInfoCiscoPartyInfo getCalledPartyInfo()Returns the PartyInfo of the called party of the call. javax.telephony.Connection[]startMonitor(javax.telephony.TerminalMonitorInitiatorterminal, javax.telephony.AddressMonitorInitiatoraddress, javax.telephony.TerminalConnectiontermConnofMonitorTarget, intmonitorType, intPlayToneDirection) throws javax.telephony.ResourceUnavailableException, javax.telephony.PrivilegeViolationException, javax.telephony.InvalidPartyException, javax.telephony.InvalidArgumentException, javax.telephony.InvalidStateException, javax.telephony.MethodNotSupportedException If the application is observing the monitor target (agent) Address, the application can use the Terminal connection of the monitor target (agent) to initiate a monitor request. This interface places a call from an originating endpoint to monitor the call at the monitor target. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 344 Cisco Unified JTAPI Extensions The New Connection

Pre-Conditions 1. (this.getProvider()).getState() = = Provider.IN_SERVICE 2. this.getState() = = Call.IDLE 3. ((CiscoProviderCapabilities)(this.getTerminal().getProvider().getProviderCapabilities()).canMonitor() = = TRUE 4. TerminalConnection.getProvider() = = this.getProvider() Parameters • MonitorInitiatorterminal - - The originating Terminal • MonitorInitiatoraddress - - The originating Address • termConnofMonitorTarget - - The TerminalConnection of the target • monitorType - - The type of monitor. Use CiscoCall.SILENT_MONITOR. • PlayToneDirection - - Indicates whether the tone needs to be played to the target, the initiator, or both. This should be one of CiscoCall.PLAYTONE_NOLOCAL_OR_REMOTE, CiscoCall.PLAYTONE_LOCALONLY, CiscoCall.PLAYTONE_REMOTEONLY, or CiscoCall.PLAYTONE_BOTHLOCALANDREMOTE Throws javax.telephony.ResourceUnavailableException javax.telephony.PrivilegeViolationException javax.telephony.InvalidPartyException javax.telephony.InvalidArgumentException javax.telephony.InvalidStateException javax.telephony.MethodNotSupportedException Related Documentation See CallControlCall for more information. CiscoCallChangedEv The system delivers the CiscoCallChangedEv event to the call observer for all supported features whenever the Global Call ID (GCID) of the call changes. CiscoCallChangedEv gets delivered when the GCID of the call changes due to path replacement (QSIG_PR) and for other features, including transfer, conference, barge, cbarge, and unpark. In the case of shared lines, multiple CiscoCallChangedEv events get delivered. The system also delivers this event when two or more calls get merged into one. Transfer, conference, unpark, Barge, and CBarge will trigger this event. Application can invoke CiscoCallEv.getCiscoFeatureReason() to find the feature code that caused this event. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 345 Cisco Unified JTAPI Extensions Related Documentation

The system reports this event via the CallControlCallObserver interface. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoCallChangedEv extends CiscoCallEv Fields Table 75: Fields in CiscoCallChangedEv Field Interface ID static int Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCallEv CAUSE_ACCESSINFORMATIONDISCARDED, CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL, CAUSE_CHANUNACCEPTABLE, CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 346 Cisco Unified JTAPI Extensions Superinterfaces

CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 347 Cisco Unified JTAPI Extensions Inherited Fields

From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 76: Methods in CiscoCallChangedEv Description Method Interface Returns the CiscoConnection to the Address where the change occurred. getConnection() Interface Returns the call that will go to INVALID state. getOriginalCall() CiscoConnection Returns the call that will remain active after the callID change. getSurvivingCall() CiscoCall Returns the TerminalConnection where the change occurred. This value could be null if the call ID changes before the TerminalConnection gets created on the Address. getTerminalConnection() CiscoCall Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoCallEv getCiscoCause, getCiscoFeatureReason From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 348 Cisco Unified JTAPI Extensions Methods

CiscoCallConsultCancelledEv This event notifies applications that a cancel operation has been invoked. Interface History Description Cisco Unified Communications Manager Release Number New event for the Swap/Cancel - Transfer/Conference Behavior Change feature. 7.1(1 and 2) Superinterfaces None Declaration public interface CiscoCallConsultCancelledEv Fields None Inherited Fields None Methods Table 77: Methods in CiscoCallConsultCancelledEv Description Method Interface Returns the consult call for which consult operation is cancelled. If the consult call does not exist, it returns NULL. The getCall() API on this call event returns the parent call. getConsultCall() CiscoCall Inherited Methods None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 349 Cisco Unified JTAPI Extensions CiscoCallConsultCancelledEv

Related Documentation None. CiscoCallCtlConnOfferedEv The CiscoCallCtlConnOfferedEv interface extends the CallCtlConnOfferedEv interface to let applications obtain the IP Address of the calling party Terminal. The IP Address information might not be available for all calling party devices. A return value of 0 (or null) indicates that the information is not available. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.callcontrol.events.CallCtlCallEv, javax.telephony.callcontrol.events.CallCtlConnEv, javax.telephony.callcontrol.events.CallCtlConnOfferedEv, javax.telephony.callcontrol.events.CallCtlEv, javax.telephony.events.CallEv, javax.telephony.events.ConnEv, javax.telephony.events.Ev Declaration public interface CiscoCallCtlConnOfferedEv extends javax.telephony.callcontrol.events.CallCtlConnOfferedEv Fields None Inherited Fields From Interface javax.telephony.callcontrol.events.CallCtlConnOfferedEv None From Interface javax.telephony.callcontrol.events.CallCtlEv CAUSE_ALTERNATE, CAUSE_BUSY, CAUSE_CALL_BACK, CAUSE_CALL_NOT_ANSWERED, CAUSE_CALL_PICKUP, CAUSE_CONFERENCE, CAUSE_DO_NOT_DISTURB, CAUSE_PARK, CAUSE_REDIRECTED, CAUSE_REORDER_TONE, CAUSE_TRANSFER, CAUSE_TRUNKS_BUSY, CAUSE_UNHOLD From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 350 Cisco Unified JTAPI Extensions Related Documentation

CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 78: Methods in CiscoCallCtlConnOfferedEv Description Method Interface Returns the IP address of the calling party, or 0 (or null) if the IP Address is not available. getCallingPartyIpAddr() java.net.InetAddress Inherited Methods From Interface javax.telephony.callcontrol.events.CallCtlCallEv getCalledAddress, getCallingAddress, getCallingTerminal, getLastRedirectedAddress From Interface javax.telephony.callcontrol.events.CallCtlEv getCallControlCause From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 351 Cisco Unified JTAPI Extensions Methods

From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ConnEv getConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation None CiscoCallCtlTermConnHeldReversionEv The CiscoCallCtlTermConnHeldReversionEv event indicates that hold reversion notification has been received on the TerminalConnection from Cisco Unified Communications Manager. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.callcontrol.events.CallCtlCallEv, javax.telephony.callcontrol.events.CallCtlEv, javax.telephony.callcontrol.events.CallCtlTermConnEv, javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoCallCtlTermConnHeldReversionEv extends javax.telephony.callcontrol.events.CallCtlTermConnEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 352 Cisco Unified JTAPI Extensions Related Documentation

Fields Table 79: Fields in CiscoCallCtlTermConnHeldReversionEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.callcontrol.events.CallCtlEv CAUSE_ALTERNATE, CAUSE_BUSY, CAUSE_CALL_BACK, CAUSE_CALL_NOT_ANSWERED, CAUSE_CALL_PICKUP, CAUSE_CONFERENCE, CAUSE_DO_NOT_DISTURB, CAUSE_PARK, CAUSE_REDIRECTED, CAUSE_REORDER_TONE, CAUSE_TRANSFER, CAUSE_TRUNKS_BUSY, CAUSE_UNHOLD From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 353 Cisco Unified JTAPI Extensions Fields

Inherited Methods From Interface javax.telephony.callcontrol.events.CallCtlCallEv getCalledAddress, getCallingAddress, getCallingTerminal, getLastRedirectedAddress From Interface javax.telephony.callcontrol.events.CallCtlEv getCallControlCause From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermConnEv getTerminalConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. CiscoCallEv The CiscoCallEv interface, which extends the JTAPI core javax.telephony.events.CallEv interface, serves as the base interface for all Cisco-extended JTAPI Call events. Every Call-related event in this package extends this interface, directly or indirectly. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 354 Cisco Unified JTAPI Extensions Inherited Methods

Superinterfaces javax.telephony.events.CallEv, CiscoEv, javax.telephony.events.Ev Subinterfaces CiscoCallChangedEv, CiscoCallSecurityStatusChangedEv, CiscoConferenceChainAddedEv, CiscoConferenceChainRemovedEv, CiscoConferenceEndEv, CiscoConferenceStartEv, CiscoConsultCallActiveEv, CiscoToneChangedEv, CiscoTransferEndEv, CiscoTransferStartEv Declaration public interface CiscoCallEv extends CiscoEv, javax.telephony.events.CallEv Fields Table 80: Fields in CiscoCallEv Description Field Interface This cause indicates that the network could not deliver access information to the remote user as requested. CAUSE_ACCESSINFORMATIONDISCARDED Static int It indicates the call is a BARGE call. CAUSE_BARGE Static int This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but which is not available at this time. CAUSE_BCBPRESENTLYAVAIL staticint This cause indicates that the user has requested a bearer capability which is implemented by the equipment which generated this cause but the user is not authorized to use. CAUSE_BCNAUTHORIZED static int This cause indicates that the equipment sending this cause does not support the bearer capability requested. CAUSE_BEARERCAPNIMPL static int This cause indicates that the user has been awarded the incoming call and that the incoming call is being connected to a channel already established to that user for similar calls. CAUSE_CALLBEINGDELIVERED static int This cause indicates that the network has received a call suspended request containing a call identity (including the null call identity) which is already in use for a suspended call within the domain of interfaces over which the call might be resumed. CAUSE_CALLIDINUSE static int This cause indicates the failure due to CALL Manager Failure. CAUSE_CALLMANAGER_FAILURE static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 355 Cisco Unified JTAPI Extensions Superinterfaces

Description Field Interface This cause indicates that the equipment sending this cause does not wish to accept this call. CAUSE_CALLREJECTED static int This cause indicates the call split, it could mean conference or transfer. CAUSE_CALLSPLIT static int This cause indicates that the equipment sending this cause does not support the channel type requested. CAUSE_CHANTYPENIMPL static int This cause indicates that the channel most recently identified is not acceptable to the sending entity for use in this call. CAUSE_CHANUNACCEPTABLE static int This cause indicates the call is rejected due to bad request. CAUSE_CTICCMSIP400BADREQUEST static int This cause indicates the request is valid but is not authorized. CAUSE_CTICCMSIP401UNAUTHORIZED static int This cause indicates the payment is required for usage. CAUSE_CTICCMSIP402PAYMENTREQUIRED static int This cause indicates the server understood the request, but is refusing to fulfill it.. CAUSE_CTICCMSIP403FORBIDDEN static int This cause indicates the request URI cannot be located by the server. CAUSE_CTICCMSIP404NOTFOUND static int This cause indicates the method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. CAUSE_CTICCMSIP405METHODNOTALLOWED static int This cause indicates the request cannot be proccessed due to requirements in the request cannot be met. CAUSE_CTICCMSIP406NOTACCEPTABLE static int This cause indicates that requset is not authorized and proxy authentication is required for the operation. CAUSE_CTICCMSIP407PROXY AUTHENTICATIONREQUIRED static int This cause indicates the time out error for the request. CAUSE_CTICCMSIP408REQUESTTIMEOUT static int This cause indicates the requested resource is no longer available at the server and no forwarding address is known. CAUSE_CTICCMSIP410GONE static int This cause indicates that an interworking message length is required. CAUSE_CTICCMSIP411LENGTHREQUIRED static int This cause indicates that the server is refusing to process a request because the request entity-body is larger than the server is willing or able to process. CAUSE_CTICCMSIP413REQUESTENTITY TOOLONG static int This cause indicates that the server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. CAUSE_CTICCMSIP414REQUESTURI TOOLONG static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 356 Cisco Unified JTAPI Extensions Fields

Description Field Interface This cause indicates the server is refusing to service the request because the message body of the request indicates the Media Type which is not supported by the server for the requested method. CAUSE_CTICCMSIP415UNSUPPORTED MEDIATYPE static int This cause indicates the server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server. CAUSE_CTICCMSIP416UNSUPPORTED URISCHEME static int This cause indicates the server did not understand the protocol extension specified in a Proxy-Require or Require header field. CAUSE_CTICCMSIP420BADEXTENSION static int This cause indicates the UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request. CAUSE_CTICCMSIP421EXTENSTION REQUIRED static int This cause indicates that the server is rejecting the request because the expiration time of the resource refreshed by the request is too short. CAUSE_CTICCMSIP423INTERVALTOOBRIEF static int This cause indicates the callee's end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the "do not disturb" feature). CAUSE_CTICCMSIP480TEMPORARILY UNAVAILABLE static int This cause indicates the the UAS received a request that does not match any existing dialog or transaction. CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST static int This cause indicates that the server has detected a loop. CAUSE_CTICCMSIP482LOOPDETECTED static int This cause indicates the server received a request that contains a Max-Forwards header field with the value zero (or less than actual hops). CAUSE_CTICCMSIP483TOOMANYHOOPS static int This cause indicates that the server received a request with a Request-URI that was incomplete. CAUSE_CTICCMSIP484ADDRESS INCOMPLETE static int This cause indicates that the Request-URI was ambiguous. CAUSE_CTICCMSIP485AMBIGUOUS static int This indicates that the callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. CAUSE_CTICCMSIP486BUSYHERE static int This cause indicates the request was terminated by a BYE or CANCEL request. CAUSE_CTICCMSIP487REQUEST TERMINATED static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 357 Cisco Unified JTAPI Extensions Fields

Description Field Interface This cause indicates the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere. CAUSE_CTICCMSIP488NOTACCEPTABLE HERE static int This cause indicates the request was received by a UAS that had a pending request within the same dialog. CAUSE_CTICCMSIP491REQUESTPENDING static int This cause indicates that the request was received by a UAS that contained an encrypted MIME body for which the recipient does not possess or will not provide an appropriate decryption key. CAUSE_CTICCMSIP493UNDECIPHERABLE static int This cause indicates the server encountered an unexpected condition that prevented it from fulfilling the request. CAUSE_CTICCMSIP500SERVERINTERNALERROR static int This cause indicates the server does not support the functionality required to fulfill the request. CAUSE_CTICCMSIP501NOTIMPLEMENTED static int This cause indicates the server, while acting as a gateway or proxy, received an invalid response from the downstream server it accessed in attempting to fulfill the request. CAUSE_CTICCMSIP502BADGATEWAY static int This cause indicates the server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. CAUSE_CTICCMSIP503SERVICEUNAVAILABLE static int This cause indicates the server did not receive a timely response from an external server it accessed in attempting to process the request. CAUSE_CTICCMSIP504SERVERTIMEOUT static int This cause indicates the server does not support, or refuses to support, the SIP protocol version that was used in the request. CAUSE_CTICCMSIP505SIPVERSIONNOT SUPPORTED static int This cause indicates the server was unable to process the request since the message length exceeded its capabilities. CAUSE_CTICCMSIP513MESSAGETOOLARGE static int This cause indicates the callee's end system was contacted successfully but the callee is busy and does not wish to take the call at this time. CAUSE_CTICCMSIP600BUSYEVERYWHERE static int This cause indicates the callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. CAUSE_CTICCMSIP603DECLINE static int This cause indicates the server has authoritative information that the user indicated in the Request-URI does not exist anywhere. CAUSE_CTICCMSIP604DOESNOTEXIST ANYWHERE static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 358 Cisco Unified JTAPI Extensions Fields

Description Field Interface This cause indicates the user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable. CAUSE_CTICCMSIP606NOTACCEPTABLE static int This cause indicates the Conference Call is full and no more participants can be added to it. CAUSE_CTICONFERENCEFULL static int This cause indicates that the device cannot be preempted. CAUSE_CTIDEVICENOTPREEMPTABLE static int This cause indicates the disconnection because the party was dropped from conference. CAUSE_CTIDROPCONFEREE static int This cause indicates the failure due to CTI Manager Failure. CAUSE_CTIMANAGER_FAILURE static int This cause indicates that there are no predictable circuits or that the called user is busy with a call of equal or higher preventable level. CAUSE_CTIPRECEDENCECALLBLOCKED static int This cause indicates that the precedence level of the call has exceeded the authorized level. CAUSE_CTIPRECEDENCELEVELEXCEEDED static int This cause indicates the precedence call has hit low bandwidth and cannot proceed. CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH static int This cause indicates that the call is being preempted and the circuit is reserved for reuse by the preempting exchange. CAUSE_CTIPREEMPTFORREUSE static int This cause indicates the call is being preempted. CAUSE_CTIPREEMPTNOREUSE static int This cause indicates that the destination indicated by the user cannot be reached because the interface to the destination is not functioning correctly. CAUSE_DESTINATIONOUTOFORDER static int This cause indicates that the specified CUG does not exist. CAUSE_DESTNUMMISSANDDCNOTSUB static int It indicates the call is Directed-Parked call. CAUSE_DPARK static int It indicates the call is Directed Park Reminder call. CAUSE_DPARK_REMINDER static int It indicates that Directed Parked call is now unparked. CAUSE_DPARK_UNPARK static int This cause indicates that the exchange couldnt route the call to specified destination. CAUSE_EXCHANGEROUTINGERROR static int It indicates the FAC(Force Authorization Code) or CMC(Client Matter Code) is needed to route the call. CAUSE_FAC_CMC static int This cause is returned when a supplementary service requested by the user cannot be provided by the network. CAUSE_FACILITYREJECTED static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 359 Cisco Unified JTAPI Extensions Fields

Description Field Interface This cause indicates that the equipment sending this cause has received a request to use a channel not activated on the interface for a call. CAUSE_IDENTIFIEDCHANDOESNOTEXIST static int This cause indicates that the equipment sending this cause has received a message which includes information element(s)/parameter(s) not recognized because the information element(s)/parameter name(s) are not defined or are defined but not implemented by the equipment sending the cause. CAUSE_IENIMPL static int It indicates the call is IN bound Blind Transfer call. CAUSE_INBOUNDBLINDTRANSFER static int It indicates the call is IN bound Conference call. CAUSE_INBOUNDCONFERENCE static int It indicates the call is IN bound Transfer call. CAUSE_INBOUNDTRANSFER static int This cause indicates that the incoming calls for that number is barred. CAUSE_INCOMINGCALLBARRED static int This cause indicates that the equipment sending this cause has received a request to establish a call which has low layer compatibility. CAUSE_INCOMPATABLEDDESTINATION static int This cause indicates that an interworking call has ended. CAUSE_INTERWORKINGUNSPECIFIED static int This cause indicates that the equipment sending this cause has received a message with a call reference which is not currently in use on the user-network interface. CAUSE_INVALIDCALLREFVALUE static int This cause indicates that the equipment sending this cause has received and information element which it has implemented; however, one or more of the fields in the information element are coded in such a way which has not been implemented by the equipment sending this cause. CAUSE_INVALIDIECONTENTS static int This cause is used to report an invalid message event only when no other cause in the invalid message class applies. CAUSE_INVALIDMESSAGEUNSPECIFIED static int This cause indicates that the called party cannot be reached because the called party number is not in a valid format or is not complete. CAUSE_INVALIDNUMBERFORMAT static int This cause indicates that a transit network identification was received which is of an incorrect format. CAUSE_INVALIDTRANSITNETSEL static int This cause indicates that the equipment sending this cause has received a message which is missing an information element which must be present in the message before that message can be processed. CAUSE_MANDATORYIEMISSING static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 360 Cisco Unified JTAPI Extensions Fields

Description Field Interface This cause indicates that a message has been received which is incompatible with the call state. CAUSE_MSGNCOMPATABLEWCS static int This cause indicates that the equipment sending this cause has received a message such that the procedures do not indicate that this is a permissible message to receive while in the call state, or a STATUS message was received indicating an incompatible call state. CAUSE_MSGTYPENCOMPATWCS static int This cause indicates that the equipment sending this cause has received a message with a message type it does not recognize either because this is a message not defined or defined but not implemented by the equipment sending this cause. CAUSE_MSGTYPENIMPL static int This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time. CAUSE_NETOUTOFORDER static int This cause is used when the called party has been alerted but does not respond with a connect indication within a prescribed period of time. CAUSE_NOANSWERFROMUSER static int This cause indicates that the network has received a call resume request containing a call identity information element which presently does not indicate any suspended call within the domain of interfaces over which calls may be resumed. CAUSE_NOCALLSUSPENDED static int This cause indicates that there is no appropriate circuit/channel presently available to handle the call. CAUSE_NOCIRCAVAIL static int This is usually given when there is no error and operation completes successfuly. CAUSE_NOERROR static int This cause indicates that the user has not been awarded the incoming call. CAUSE_NONSELECTEDUSERCLEARING static int This cause indicates that the call is being cleared because one of the users involved in the call has requested that the call be cleared. CAUSE_NORMALCALLCLEARING static int This cause is used to report a normal event only when no other cause in the normal class applies. CAUSE_NORMALUNSPECIFIED static int This cause indicates that the called party cannot be reached because the network through which the call has been routed does not serve the destination desired. CAUSE_NOROUTETODDESTINATION static int This cause indicates that the equipment sending this cause has received a request to route the call through a particular transit network which it does not recognize. CAUSE_NOROUTETOTRANSITNET static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 361 Cisco Unified JTAPI Extensions Fields

Description Field Interface This cause is used when a called party does not respond to a call establishment message with either an alerting or connect indication within the prescribed period of time allocated. CAUSE_NOUSERRESPONDING static int This cause is returned to a calling party when the called party number indicated by the calling party is no longer assigned. CAUSE_NUMBERCHANGED static int This cause indicates that the calling party has requested an unrestricted bearer service but the equipment sending this cause only supports the restricted version of the requested bearer capability. CAUSE_ONLYRDIVEARERCAPAVAIL static int It indicates the call is OUT bound Conference call. CAUSE_OUTBOUNDCONFERENCE static int It indicates the call is OUT bound Transfer call CAUSE_OUTBOUNDTRANSFER static int This cause indicates that the call could not proceed because of Low Bandwidth. CAUSE_OUTOFBANDWIDTH static int This cause is used to report a protocol error event only when no other cause in the protocol error class applies. CAUSE_PROTOCOLERRORUNSPECIFIED static int It indicates the QSIG Path Replacement in the call. CAUSE_QSIG_PR static int This cause is used to report that the requested Quality of Service, as defined in Recommendation X.213. CAUSE_QUALOFSERVNAVAIL static int It indicates the Call is cleared as Call Manager has gone down, but media between endpoints remain connected. CAUSE_QUIET_CLEAR static int This cause indicates that a procedure has been initiated by the expiration of a timer in association with error handling procedures. CAUSE_RECOVERYONTIMEREXPIRY static int This cause indicates the call is being redirected to different party. CAUSE_REDIRECTED static int This cause indicates that the network has received a call resume request containing a call identity information element indicating a suspended call that has in the meantime been cleared while suspended (either by network time-out or by the remote user). CAUSE_REQCALLIDHASBEENCLEARED static int This cause is returned when the circuit or channel indicated by the requesting entity cannot be provided by the other side of the interface. CAUSE_REQCIRCNAVIL static int This cause indicates that the equipment sending this cause does not support the requested. CAUSE_REQFACILITYNIMPL static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 362 Cisco Unified JTAPI Extensions Fields

Description Field Interface This cause indicates that the user has requested a supplementary service which is implemented by the equipment which generated this cause but the user is not authorized to use. CAUSE_REQFACILITYNOTSUBSCRIBED static int This cause is used to report a resource unavailable event. CAUSE_RESOURCESNAVAIL static int This cause is included in the STATUS message when the reason for generating the STATUS message was the prior receipt of a STATUS INQUIRY. CAUSE_RESPONSETOSTATUSENQUIRY static int This cause is used to report a service or option not available event only when no other cause in the service or option not available class applies. CAUSE_SERVNOTAVAILUNSPECIFIED static int This cause indicates that although the calling party is a member of the CUG for the outgoing CUG call. CAUSE_SERVOPERATIONVIOLATED static int This cause is used to report a service or option not implemented event only when no other cause in the service or option not implemented class applies. CAUSE_SERVOROPTNAVAILORIMPL static int This cause value is used when a mobile station has logged off. CAUSE_SUBSCRIBERABSENT static int This cause indicates that a call resume has been attempted with a call identity which differs from that in use for any presently suspended call(s). CAUSE_SUSPCALLBUTNOTTHISONE static int This cause indicates that the switching equipment generating this cause is experiencing a period of high traffic. CAUSE_SWITCHINGEQUIPMENTCONGESTION static int This cause indicates that the network is not functioning correctly and that the condition is not likely to last a long period of time; e.g., the user may wish to try another call attempt almost immediately. CAUSE_TEMPORARYFAILURE static int This cause indicates that the destination requested by the calling user cannot be reached because, it is an invalid number. CAUSE_UNALLOCATEDNUMBER static int This cause is used to indicate that the called party is unable to accept another call because the user busy condition has been encountered. CAUSE_USERBUSY static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 363 Cisco Unified JTAPI Extensions Fields

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Methods Table 81: Methods in CiscoCallEv Description Method Interface Returns the Cisco Unified Communications Manager cause for this event. To function properly, some applications need to know the reason why an event happened at an endpoint that the application is observing. For example, a Connection may be disconnected because the call was not answered (CAUSE_NOANSWERFROMUSER), or whether the caller it was disconnected because it was rejected (CAUSE_CALLREJECTED). Returns: The Cisco Unified Communications Manager cause for this event getCiscoCause() Int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 364 Cisco Unified JTAPI Extensions Inherited Fields

Description Method Interface Returns the Cisco Unified Communications Manager Feature Reason for this event. To function properly, some applications need to know the reason why an event happened. This interface provides the CiscoFeatureReason in JTAPI Call events for current and new features. Existing features, such as transfer, continue to receive the CiscoCause provided by the older interface CiscoCallEv.getCiscoCause(), while this interface will provide REASON_TRANSFER for transfer. Caution: Applications should make sure to handle unrecognized reasons and provide default behavior, because new reasons could be added in the future and this interface may not be backward compatible. The possible values are defined in the CiscoFeatureReason interface. Returns: The Cisco Unified Communications Manager Feature Reason for this event getCiscoFeatureReason() Int Related Documentation See Constant Field Values, on page 1667 and CallEv for more information. CiscoCallFeatureCancelledEv This event notifies applications that the cancel operation has been invoked Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(2) Declaration public interface CiscoCallFeatureCancelledEv Methods Table 82: Methods in CiscoCallFeatureCancelledEv Description Method Interface Returns the Consult Call for which consult operation is cancelled, if the consult call doesn't exist it will return NULL. getConsultCall() CiscoCall Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 365 Cisco Unified JTAPI Extensions Related Documentation

Related Documentation See Constant Field Values, on page 1667. CiscoCallID The CiscoCallID object represents a unique object that is associated with each call. Applications may use the object itself or the integer representation of the object that the intValue() method returns. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces CiscoObjectContainer Declaration Public interface CiscoCallID extends CiscoObjectContainer Fields None Methods Table 83: Methods in CiscoCallID Description Method Interface Returns an integer representation of this object. Returns: Int An integer representation of this object intValue() Int Returns the CiscoCall corresponding to this CiscoCallID. getCall() CiscoCall Returns the Cisco Unified Communications Manager NodeID of the call associated with this CiscoCallID. getCallManagerID() int Returns the GlobalCallID of the call associated with this CiscoCallID. getGlobalCallID() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 366 Cisco Unified JTAPI Extensions Related Documentation

Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Related Documentation None CiscoMediaCallSecurityIndicator CiscoMediaCallSecurityIndicator lets you retrieve the security indicator for a call. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoMediaCallSecurityIndicator Fields None Methods Table 84: Methods in CiscoMediaCallSecurityIndicator Description Method Interface Returns the CiscoCallID. getCallID() CiscoCallID Returns the media security indicator, one of the following constants: CiscoMediaSecurityIndicator. MEDIA_ENCRYPT_USER_NOT_AUTHORIZED CiscoMediaSecurityIndicator. MEDIA_ENCRYPTED_KEYS_UNAVAILABLE CiscoMediaSecurityIndicator. MEDIA_NOT_ENCRYPTED getCiscoMediaSecurityIndicator() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 367 Cisco Unified JTAPI Extensions Inherited Methods

Description Method Interface Returns a CiscoRTPHandle object.Applications can get a call reference by using CiscoProvider.getCall. If there is no call observer or there was no call observer when this event was delivered, CiscoProvider.getCall may return null. getCiscoRTPHandle() CiscoRTPHandle Related Documentation See CiscoRTPParams. CiscoCallSecurityStatusChangedEv Applications receive CiscoCallSecurityStatusChangedEv when the overall Call security status changes. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoCallSecurityStatusChangedEv extends CiscoCallEv Fields Table 85: Fields in CiscoCallSecurityStatusChangedEv Field Interface ID Static int Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCallEv CAUSE_ACCESSINFORMATIONDISCARDED, CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 368 Cisco Unified JTAPI Extensions Related Documentation

CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL, CAUSE_CHANUNACCEPTABLE, CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 369 Cisco Unified JTAPI Extensions Inherited Fields

CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 86: Methods in CiscoCallSecurityStatusChangedEv Description Method Interface Specified by: getID in interface javax.telephony.events.Ev getID() javax.telephony.events.Ev Returns the call security status. This interface can return: CiscoCall.CALLSECURITY_UNKNOWN, CiscoCall.CALLSECURITY_NOTAUTHENTICATED, CiscoCall.CALLSECURITY_AUTHENTICATED, CiscoCall.CALLSECURITY_ENCRYPTED getCallSecurityStatus() getCallSecurityStatus Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoCallEv getCiscoCause, getCiscoFeatureReason From Interface javax.telephony.events.Ev getCause, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 370 Cisco Unified JTAPI Extensions Methods

From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getMetaCode, getObserved, isNewMetaEvent Related Documentation See also Constant Field Values, on page 1667 for more information. CiscoConferenceChain This interface provides links to conference chain connections for the conference calls that are linked together in a conference chain. You can obtain this object from CiscoConferenceChainAddedEv and CiscoConferenceChainRemovedEv. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Declaration public interface CiscoConferenceChain Fields None Methods Table 87: Methods in CiscoConferenceChain Description Method Interface Returns an array of Connections for Conference Calls that are chained together in a single conference. Applications can use this list to get all the Conference Calls that are linked together. To get the list of Connections for all the Calls that are chained together in the Conference, the provider must have an observer on at least one party in every conference call. getChainedConferenceConnections() javax.telephony.Connection[] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 371 Cisco Unified JTAPI Extensions Related Documentation

Description Method Interface Returns an array of Calls that are chained together in a single conference. This interface returns only the Calls in the conference chain that are observed in the provider. getChainedConferenceCalls() CiscoCall[] Related Documentation See CiscoConferenceChainAddedEv and CiscoConferenceChainRemovedEv for more information. CiscoConferenceChainAddedEv The system sends a CiscoConferenceChainAddedEv event when a conference chain connection gets added to a call. This event gets sent every time a new conference chain connection gets added. This event gets reported via theCallControlCallObserver interface. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) All Superinterfaces javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoConferenceChainAddedEv extends CiscoCallEv Fields Table 88: Fields in CiscoConferenceChainAddedEv Field Interface ID static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 372 Cisco Unified JTAPI Extensions Related Documentation

Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCallEv CAUSE_ACCESSINFORMATIONDISCARDED, CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL, CAUSE_CHANUNACCEPTABLE, CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 373 Cisco Unified JTAPI Extensions Inherited Fields

CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 89: Methods in CiscoConferenceChainAddedEv Description Method Interface Returns the conference chain Connection that was added to the call. getAddedConnection() javax.telephony.Connection Returns a CiscoConferenceChain that contains all of the conference connections for the calls that are chained together. getConferenceChain() CiscoConferenceChain Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoCallEv getCiscoCause, getCiscoFeatureReason Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 374 Cisco Unified JTAPI Extensions Methods

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. CiscoConferenceChainRemovedEv The system sends a CiscoConferenceChainRemovedEv event when a conference chain connection gets removed from a call. This event gets sent whenever a conference chain connection gets removed. This event gets reported via theCallControlCallObserver interface. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoConferenceChainRemovedEv extends CiscoCallEv Fields Table 90: Fields in CiscoConferenceChainRemovedEv Field Interface ID static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 375 Cisco Unified JTAPI Extensions Related Documentation

Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCallEv CAUSE_ACCESSINFORMATIONDISCARDED, CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL, CAUSE_CHANUNACCEPTABLE, CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 376 Cisco Unified JTAPI Extensions Inherited Fields

CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 91: Methods in CiscoConferenceChainRemovedEf Description Method Interface Returns a CiscoConferenceChain that contains all of the conference connections for the calls that are chained together. Returns: Connection. getConferenceChain() CiscoConferenceChain Returns the conference chain Connection that was removed from the call. Returns: CiscoConferenceChain. getRemovedConnection() javax.telephony.Connection Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoCallEv getCiscoCause, getCiscoFeatureReason Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 377 Cisco Unified JTAPI Extensions Methods

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. CiscoConferenceEndEv The CiscoConferenceEndEv event indicates that a Conference operation completed. The system reports this event via the CallControlCallObserver interface. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1) Superinterfaces javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoConferenceEndEv extends CiscoCallEv Fields Table 92: Fields in CiscoConferenceEndEv Field Interface ID static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 378 Cisco Unified JTAPI Extensions Related Documentation

Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCallEv CAUSE_ACCESSINFORMATIONDISCARDED, CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL, CAUSE_CHANUNACCEPTABLE, CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 379 Cisco Unified JTAPI Extensions Inherited Fields

CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 93: Methods in CiscoConferenceEndEv Description Method Interface Returns the Address that currently acts as the conference controller for this call, the initiating call. getConferenceControllerAddress() javax.telephony.Address Returns the call that merged. This call is in the Call.INVALID state. getConferencedCall() javax.telephony.Call Returns list of Calls that could not be Conferenced. getFailedCalls() javax.telephony.Call[] Returns the call that remains active after the conference completes. getFinalCall() javax.telephony.Call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 380 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns the TerminalConnection that currently acts as the conference controller for this call -- the final call. This is the TerminalConnection that was in HELD state when the conference got initiated. This method returns null or TerminalConnection if the conference controller is not being observed. getHeldConferenceController() javax.telephony.TerminalConnection Returns the TerminalConnection that currently acts as the conference controller for this call -- the initiating call.This is the TerminalConnection that was in TALKING state. This method returns null or TerminalConnection if the conference controller is not being observed. getTalkingConferenceController() javax.telephony.TerminalConnection Returns Boolean True or False depending on whether the conference succeeded or failed. The application can use this interface to determine whether a Conference is successful. Conferences will fail in these situations: • If the application issues the request Call.conference(otherCalls[]), the system considers the conference as failed if one or more than one Calls could not Join into Conference. Use getFailedCalls() to find the failed calls. • If no conference bridge is available, and the conference could not complete. Use getFailedCalls() to get a list of the calls that could not join the conference. • If the party being conferenced drops out before the conference could complete. isSuccess() boolean Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoCallEv getCiscoCause, getCiscoFeatureReason From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 381 Cisco Unified JTAPI Extensions Inherited Methods

From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 See also isSuccess() CiscoConferenceStartEv The CiscoConferenceStartEv event indicates that a conference operation started. The CallControlCallObserver interface reports this event. Interface History Description Cisco Unified Communications Manager Release Number Added getControllerTerminalName() method for Join Across Lines/Connected Conference feature. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoConferenceStartEv extends CiscoCallEv Fields Table 94: Fields in CiscoConferenceStartEv Field Interface ID static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 382 Cisco Unified JTAPI Extensions Related Documentation

Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCallEv CAUSE_ACCESSINFORMATIONDISCARDED, CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL, CAUSE_CHANUNACCEPTABLE, CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 383 Cisco Unified JTAPI Extensions Inherited Fields

CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 95: Methods in CiscoConferenceStartEv Description Method Interface Returns the Address that currently acts as the conference controller for this call, the initiating call. getConferenceControllerAddress() javax.telephony.Address Returns the call that will be conferenced. This is the call that will be merged into the initiating call. This interface returns the first call from the list of calls that are joining into conference. getConferencedCall() javax.telephony.Call Returns the list of the calls that will be conferenced. These calls are the ones that will be merged into the final call. getConferencedCalls() javax.telephony.Call[] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 384 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns the call that will remain active after the conference completes. This is the call into which all the calls will merge. getFinalCall() javax.telephony.Call Returns the TerminalConnection that currently acts as the conference controller for this call, the initiating call. This is the TerminalConnection that was in HELD state. This method returns null if the conference controller is not being observed. This method returns the first held controller for a multiple call join scenario. getHeldConferenceController() javax.telephony.TerminalConnection Returns all TerminalConnections on Conference Controller Terminal that are joining together and are in HELD State. getHeldConferenceControllers() javax.telephony.TerminalConnection[] Returns the Address of the participant that initiated the conference. getOriginalConferenceControllerAddress() javax.telephony.Address Returns the TerminalConnection that currently acts as the conference controller for this call, the initiating call. This is the TerminalConnection that was in TALKING state. This method returns null if the conference controller is not being observed. This method returns null if there is no controller in talking state. Calls can be joined into a conference without any talking controller. getTalkingConferenceController() javax.telephony.TerminalConnection Returns the terminal name of the controllers across which a conference is done. getControllerTerminalName() String Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoCallEv getCiscoCause, getCiscoFeatureReason From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 385 Cisco Unified JTAPI Extensions Inherited Methods

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoConnection The CiscoConnection interface extends the CallControlConnection interface with additional Cisco specific capabilities. Applications can use the getReason method to obtain the reason for the creation of a connection. Interface History Description Cisco Unified Communications Manager Release Number Added two new methods: getPartyInfo and disconnect(CiscoPartyInfopartyInfo for Drop Any Party feature. 7.1(1 and 2) Enhanced with the following: • New method to get the associated CiscoHuntConnection. If application is observing hunt list member, applications can use this method to find out if call is routed through HuntPilot. • New interface getUniqueID(Terminal term) is added which will return the uniqueID as string. • New method that allows an application to determine if the connection is associated with a chaperone device on a chaperone call. Chapone devices have a limited feature set, and knowing that a connection is associated with a chaperone device can allow the application to better handle the connections. 8.0(1) Added redirect method with deviceName. 11.5(1) All Superinterfaces javax.telephony.callcontrol.CallControlConnection, CiscoObjectContainer, javax.telephony.Connection Declaration public interface CiscoConnection extends javax.telephony.callcontrol.CallControlConnection, CiscoObjectContainer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 386 Cisco Unified JTAPI Extensions Related Documentation

Fields Table 96: Fields in CiscoConnection Description Field Interface The redirect should be done by using the redirect controller address search space. ADDRESS_SEARCH_SPACE static int The default behavior for Cisco JTAPI should apply. CALLED_ADDRESS_DEFAULT static int The original called Address should be set to the value present in preferredOriginalCalledParty field. CALLED_ADDRESS_SET_TO_PREFERREDCALLEDPARTY static int The called Address should be reset to the redirect destination. CALLED_ADDRESS_SET_TO_REDIRECT_ DESTINATION static int The called Address should remain unchanged after the redirect operation. CALLED_ADDRESS_UNCHANGED static int The redirect should be done by using the calling address search space. CALLINGADDRESS_SEARCH_SPACE static int The redirect should be done by using the default search space for the implementation. DEFAULT_SEARCH_SPACE static int This Connection results from a direct call. REASON_DIRECTCALL static int This Connection results from unconditional forwarding. REASON_FORWARDALL static int This Connection results from a forwarding on busy. REASON_FORWARDBUSY static int This Connection results from a forwarding on no answer. REASON_FORWARDNOANSWER static int This Connection is an originating Connection, not a destination Connection. REASON_OUTBOUND static int This Connection results from a redirection. REASON_REDIRECT static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 387 Cisco Unified JTAPI Extensions Fields

Description Field Interface This Connection results from a transfer. REASON_TRANSFERREDCALL static int This redirect mode instructs the implementation to perform redirect without checking the validity or availability of the destination. REDIRECT_DROP_ON_FAILURE static int This redirect mode instructs the implementation to perform redirect if the destination is valid and available. REDIRECT_NORMAL static int Inherited Fields From Interface javax.telephony.callcontrol.CallControlConnection ALERTING, DIALING, DISCONNECTED, ESTABLISHED, FAILED, IDLE, INITIATED, NETWORK_ALERTING, NETWORK_REACHED, OFFERED, OFFERING, QUEUED, UNKNOWN From Interface javax.telephony.Connection CONNECTED, INPROGRESS Methods Table 97: Methods in CiscoConnection Method and Descrption Interface getAddressPI() Boolean Returns Presentation Indicator (PI) associated with the Address on which the connection is created. getCiscoHuntConnection() CiscoHuntConnection This method returns the associated CiscoHuntConnection or null. getConnectionID() CiscoConnectionID Returns CiscoConnectionID for this CiscoConnection getDParkPrefixCode() java.lang.String Returns the prefix code that needs to be dialed with the DPark DN to retrieve the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 388 Cisco Unified JTAPI Extensions Inherited Fields

Method and Descrption Interface getReason() int Returns the reason for the creation of this Connection. To function properly, some applications need to know the reason for the creation of the connection is created at an endpoint. The reason for a Connection creation may be any of the following constants: • CiscoConnection. REASON_DIRECTCALL CiscoConnection. REASON_TRANSFERREDCALL • CiscoConnection. REASON_FORWARDNOANSWER • CiscoConnection. REASON_FORWARDBUSY • CiscoConnection. REASON_FORWARDALL • CiscoConnection. REASON_REDIRECT • CiscoConnection. REASON_NORMAL getRequestController() javax.telephony.TerminalConnection Returns the current request Controller for the Connection. getUniqueID(Terminal term) String This method returns the updated uniqueID of the connection. In case if there are no shared lines associated with this connection, application can just pass null object as parameter to this interface to get the Unique Identifier. Unique Identifier will be same for all the shared lines, but if it’s a barge scenario, different terminals would have different identifier.The returned Unique Identifier will be 32-character hex string. Please refer to End to End Call Tracing, on page 904End to End Call Tracing, on page 904, for more information. Throws: PrivilegeVoilationException , InvalidStateException Parameters: Terminal isChaperone() boolean This method returns true if the connection is associated with a Chaperone call, and false if not. park() java.lang.String This method parks the call at a system park DN and returns the address of the park DN. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 389 Cisco Unified JTAPI Extensions Methods

Method and Descrption Interface redirect(java.lang.String destinationAddress, int mode) javax.telephony.Connection This method overloads the CallControlConnection.redirect() method. Throws javax.telephony. InvalidStateException javax.telephony. InvalidPartyException javax.telephony. MethodNotSupportedException javax.telephony. PrivilegeViolationException javax.telephony. ResourceUnavailableException Parameter Mode - This parameter can take one of the following two values: • CiscoConnection. REDIRECT_DROP_ON_FAILURE: This mode instructs the implementation to perform a redirect without checking the validity or availability of the destination. The original call gets dropped if the destination is invalid or busy. • CiscoConnection. REDIRECT_NORMAL: This mode instructs the implementation to perform a redirect only after checking the validity or availability of the destination. This matches the behavior of the CallControlConnection.redirect() method. The system does not drop the original call on failure. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 390 Cisco Unified JTAPI Extensions Methods

Method and Descrption Interface redirect(java.lang.String destinationAddress, int mode, int callingSearchSpace) javax.telephony.Connection This method overloads the CallControlConnection.redirect() method. It takes two new parameters: redirectMode and callingSearchSpace. The redirectMode selects which type of redirect to perform. The callingSearchSpace tells the implementation to use either the calling party search space or the redirect controller search space. Parameters mode - One of the following: • CiscoConnection.REDIRECT_DROP_ON_FAILURE: This mode instructs the implementation to perform a redirect without checking the validity or availability of the destination. The original call gets dropped if the destination is invalid or busy. • CiscoConnection.REDIRECT_NORMAL: This mode instructs the implementation to perform a redirect only after checking the validity or availability of the destination. This matches the behavior of the CallControlConnection.redirect() method. The system does not drop the original call on failure. callingSearchSpace - One of the following: • CiscoConnection. DEFAULT_SEARCH_SPACE • CiscoConnection. CALLINGADDRESS_SEARCH_SPACE • CiscoConnection. ADDRESS_SEARCH_SPACE Throws javax.telephony. InvalidStateException javax.telephony. InvalidPartyException javax.telephony. MethodNotSupportedException javax.telephony. PrivilegeViolationException javax.telephony. ResourceUnavailableException Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 391 Cisco Unified JTAPI Extensions Methods

Method and Descrption Interface redirect(java.lang.String destinationAddress, int mode, int callingSearchSpace, int calledAddressOption) javax.telephony.Connection This method overloads the CallControlConnection.redirect() method. It takes three new parameters: mode, callingSearchSpace, and calledAddressOption. The redirectMode selects the type of redirect to perform. The callingSearchSpace tells the implementation to use either the calling party search space or the redirect controller search space. The calledAddressOption parameter controls whether to reset the original called fields. Parameters mode - One of the following: • CiscoConnection. REDIRECT_DROP_ON_FAILURE • CiscoConnection. REDIRECT_NORMAL callingSearchSpace - One of the following: • CiscoConnection. DEFAULT_SEARCH_SPACE • CiscoConnection. CALLINGADDRESS_SEARCH_SPACE • CiscoConnection. ADDRESS_SEARCH_SPACE calledAddressOption: One of the following: • CiscoConnection. CALLED_ADDRESS_DEFAULT • CiscoConnection. CALLED_ADDRESS_UNCHANGED • CiscoConnection. CALLED_ADDRESS_SET_TO_REDIRECT_DESTINATION Throws javax.telephony. InvalidStateException javax.telephony. InvalidPartyException javax.telephony. MethodNotSupportedException javax.telephony. PrivilegeViolationException javax.telephony. ResourceUnavailableException Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 392 Cisco Unified JTAPI Extensions Methods

Method and Descrption Interface redirect(java.lang.String destinationAddress, int mode, int callingSearchSpace, int calledAddressOption, java.lang.String preferredOriginalCalledParty, java.lang.String facCode, java.lang.String cmcCode) javax.telephony.Connection Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 393 Cisco Unified JTAPI Extensions Methods

Method and Descrption Interface This method overloads the CallControlConnection.redirect() method. It takes three new parameters: mode, callingSearchSpace, and calledAddressOption. The redirectMode selects the type of redirect to perform. The callingSearchSpace tells the implementation to use either the calling party search space or the redirect controller search space. The calledAddressOption parameter controls whether to reset the original called fields. If the FAC and CMC codes are missing or invalid, the call might not get offered and platformException may contain one of the following error codes: • CiscoJTAPIException. CTIERR_FAC_CMC _REASON_FAC_NEEDED • CiscoJTAPIException.CTIERR_FAC_CMC_REASON_CMC_NEEDED • CiscoJTAPIException. CTIERR_FAC_CMC _REASON_FAC_CMC_NEEDED • CiscoJTAPIException. CTIERR_FAC_CMC _REASON_FAC_INVALID • CiscoJTAPIException.CTIERR_FAC_CMC_REASON_CMC_INVALID Parameters mode - One of the following: • CiscoConnection.REDIRECT_DROP_ON_FAILURE • CiscoConnection. REDIRECT_NORMAL callingSearchSpace - One of the following: • CiscoConnection. DEFAULT_SEARCH_SPACE • CiscoConnection. CALLINGADDRESS_SEARCH_SPACE • CiscoConnection. ADDRESS_SEARCH_SPACE • preferredOriginalCalledParty - may be a DN that will be the originalCalledParty field when call is offered to destinationAddress. If this field * needs to be used, applications must set calledAddressOption as CALLED_ADDRESS_SET_TO_PREFERREDCALLEDPARTY. If applications are not interested in this field, you must pass the default value of null. calledAddressOption - One of the following: • CiscoConnection. CALLED_ADDRESS_DEFAULT • CiscoConnection. CALLED_ADDRESS_UNCHANGED • CiscoConnection. CALLED_ADDRESS_SET_TO_REDIRECT_DESTINATION preferredOriginalCalledParty - may be a DN that will be the originalCalledParty field when call is offered to destinationAddress. If this field * needs to be used, applications must set calledAddressOption as CALLED_ADDRESS_SET_TO_PREFERREDCALLEDPARTY. If applications are not interested in this field, you must pass the default value of null. facCode - required if the destinationAddress requires a forced authorization Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 394 Cisco Unified JTAPI Extensions Methods

Method and Descrption Interface code to offer the call. Pass the FAC in this parameter. Pass the default value of null if the destinationAddress does not require a FAC code. cmcCode - required if the destinationAddress requires a client matter code to offer the call. Pass the CMC in this parameter. Pass the default value of null if the destinationAddress does not require a CMC code. redirect(java.lang.String destinationAddress, int mode, int callingSearchSpace, int calledAddressOption, java.lang.String preferredOriginalCalledParty, java.lang.String facCode, java.lang.String cmcCode, int featurePriority) javax.telephony.Connection This method overloads CallControlConnection.redirect(). It takes a new parameter, featurePriority, that sets the call priority. The featurePriority parameter may be: • CiscoCall.FEATUREPRIORITY_NORMAL • CiscoCall.FEATUREPRIORITY_URGENT • CiscoCall.FEATUREPRIORITY_EMERGENCY Returns Connection Throws javax.telephony.InvalidStateException javax.telephony.InvalidPartyException javax.telephony.MethodNotSupportedException javax.telephony.PrivilegeViolationException javax.telephony.ResourceUnavailableException Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 395 Cisco Unified JTAPI Extensions Methods

Method and Descrption Interface redirect(java.lang.String destinationAddress, int mode, int callingSearchSpace, java.lang.String preferredOriginalCalledParty) javax.telephony.Connection This method overloads the CallControlConnection.redirect() method. It takes three new parameters: mode, callingSearchSpace, and preferredOriginalCalledParty. The redirectMode selects the type of redirect to perform. The callingSearchSpace tells the implementation to use either the calling party search space or the redirect controller search space. Parameters mode - One of the following: • CiscoConnection.REDIRECT_DROP_ON_FAILURE • CiscoConnection.REDIRECT_NORMAL callingSearchSpace - One of the following: • CiscoConnection.DEFAULT_SEARCH_SPACE • CiscoConnection.CALLINGADDRESS_SEARCH_SPACE • CiscoConnection.ADDRESS_SEARCH_SPACE preferredOriginalCalledParty - May be a DN that will be the originalCalledParty field when the call gets offered to the destinationAddress. Throws javax.telephony.InvalidStateException javax.telephony.InvalidPartyException javax.telephony.MethodNotSupportedException javax.telephony.PrivilegeViolationException javax.telephony.ResourceUnavailableException Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 396 Cisco Unified JTAPI Extensions Methods

Method and Descrption Interface redirect(String destinationAddress, int mode, int callingSearchSpace, int calledAddressOption, String preferredOriginalCalledParty, String facCode, String cmcCode, int featurePriority, byte[] applicationXMLData) javax.telephony.Connection This method is similar to the existing redirect method on the CiscoConnection object, except this one takes an additional parameter, applicationXMLData. Parameters applicationXMLData This parameter was added, and it allows an application to send message header point like SIP contact header info to the receiving end point. The parameter takes xml format as mentioned below. <data> <item> <type>contact</type> <operation>append</operation> <protocol>SIP</protocol> <value>;+sip.instance = "<urn:uuid = *guid*>"</value> </item> </data> Note This version only supports: contact, operation: append, protocol: SIP. It can be enhanced to support other protocols and operations in the future. If applications are not interested in this field, you must pass the default value of null. redirect(String destinationAddress, int mode, int callingSearchSpace, int calledAddressOption, String preferredOriginalCalledParty, String facCode, String cmcCode, int featurePriority, byte[] applicationXMLData, String deviceName) javax.telephony.Connection This method is similar to the above method, but it adds the deviceName parameter, which allows you to send the redirect to a specific device. Even in situations where the target device shares a line with another device, the redirected call goes only to the target device and not to the other device that shares the phone line. setRequestController(javax.telephony.TerminalConnection tc) void This interface gets provided to a requesting TerminalConnection. getPartyInfo() com.cisco.jtapi.extensions.CiscoPartyInfo[] Returns a list of participants. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 397 Cisco Unified JTAPI Extensions Methods

Method and Descrption Interface disconnect(CiscoPartyInfopartyInfo) java.lang.void Disconnects participant with whose CiscoPartyInfo matches the passed parameter value; throws exception otherwise. Throws PrivilegeViolationException InvalidStateException This method takes a Terminal connection object of the connection and returns the Local Universal Unique Identifier of the party associated with both connection and the terminal connection. getLocalUUID(TerminalConnection termConn) This method takes a Terminal connection object of the connection and returns the Local Universal Unique Identifier of the party on the other side of the call. It is a part of both connection and the terminal connection. getPeerUUID(TerminalConnection termConn) Inherited Methods From Interface javax.telephony.callcontrol.CallControlConnection accept, addToAddress, getCallControlState, park, redirect, reject From Interface javax.telephony.Connection disconnect, getAddress, getCall, getCapabilities, getConnectionCapabilities, getState, getTerminalConnections From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Documentation None CiscoConnectionID The CiscoConnectionID object represents a unique object that is associated with each connection. Applications may use the object itself or the integer representation of the object that the intValue() method returns. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 398 Cisco Unified JTAPI Extensions Inherited Methods

Superinterfaces CiscoObjectContainer Declaration public interface CiscoConnectionID extends CiscoObjectContainer Fields None Methods Table 98: Methods in CiscoConnectionID Description Method Interface Returns the CiscoConnection for the CiscoConnectionID. getConnection() CiscoConnection Returns an integer representation of this object. intValue() Int Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Related Documentation None CiscoConnectionUniqueIDChangedEv It’s a new event to highlight that uniqueID of the connection has changed. Interface History Description Cisco Unified Communications Manager Release Number New event 8.0(1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 399 Cisco Unified JTAPI Extensions Superinterfaces

Declaration public interface CiscoConnectionUniqueIDChangedEv extends ConnEv Methods Table 99: Methods in CiscoConnectionUniqueIDChangedEv Description Method Interface This method returns the old uniqueID of the connection which has just changed. The returned value is a Unique Identifier as 32-character hex string. getOldUniqueID() String This method returns the Terminal for which this ConnEv is delivered. getTerminal() Terminal This method returns the updated uniqueID of the connection. The returned value is a Unique Identifier as 32-character hex string. getUniqueID() String Related Documentation CiscoConsultCall The CiscoConsultCall interface extends the CiscoCall interface to expose certain properties of calls that have been created as part of a consultative transfer or consultative conference. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.Call, javax.telephony.callcontrol.CallControlCall, CiscoCall, CiscoObjectContainer Declaration public interface CiscoConsultCall extends CiscoCall Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 400 Cisco Unified JTAPI Extensions Declaration

Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCall CALLSECURITY_AUTHENTICATED, CALLSECURITY_ENCRYPTED, CALLSECURITY_NOTAUTHENTICATED, CALLSECURITY_UNKNOWN, FEATUREPRIORITY_EMERGENCY, FEATUREPRIORITY_NORMAL,FEATUREPRIORITY_URGENT, PLAYTONE_BOTHLOCALANDREMOTE, PLAYTONE_LOCALONLY, PLAYTONE_NOLOCAL_OR_REMOTE, PLAYTONE_REMOTEONLY, SILENT_MONITOR From Interface javax.telephony.Call ACTIVE, IDLE, INVALID Methods Table 100: Methods in CiscoConsultCall Description Method Interface Returns the consulting TerminalConnection that was used to create this CiscoConsultCall. If this Call was created as part of a consultative transfer or consultative conference, the getConsultingTerminalConnection method returns the TerminalConnection that was used to perform the consultation on the original call. This method lets you correlate a ConsultCall with its original call. The original call itself does not have any methods that you can use determine the ConsultCall, if any, to which it is related. Returns: Null if this Call does not result from a consultation, or the consulting TerminalConnection of the original Call if this call resulted from a consultation. getConsultingTerminalConnection() javax.telephony.TerminalConnection Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 401 Cisco Unified JTAPI Extensions Inherited Fields

Description Method Interface Provides applications ability to initiate a consultative call without setting up media for it. This interface may be invoked when application is creating a consult call and completing transfer before media establishes for consult call. Cisco Unified Communication Manager may some times run into erroneous race condition when consult call is answered, and application completes transfer in the middle of media setup for consult call. To avoid this problem, application that does not wait for media setup completion for consult call, may use this method to setup consult call. From CallEvent perspective, this method behaves similar to CallControlCall.consult(TerminalConnection tc, String dialedDigits). Creates a consultation between this Call and an active Call without establishing the media. This consult call may only be transferred, not conferenced. Cisco JTAPI does not support this method with CallControlCall.setConferenceEnable(). Cisco JTAPI only supports this method with CallControlCall.setTransferEnable(). Throws javax.telephony. InvalidStateException javax.telephony. InvalidArgumentException javax.telephony. MethodNotSupportedException javax.telephony. ResourceUnavailableException javax.telephony. PrivilegeViolationException javax.telephony. InvalidPartyException consultWithoutMedia(javax.telephony. TerminalConnection tc, java.lang.String dialedDigits) javax.telephony.Connection[] Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoCall conference, connect, getCalledAddressPI, getCalledPartyInfo, getCallID, getCallingAddressPI, getCallSecurityStatus, getConferenceChain, getCurrentCalledAddress, getCurrentCalledAddressPI, getCurrentCalledDisplayNamePI, getCurrentCalledPartyDisplayName, getCurrentCalledPartyInfo, getCurrentCalledPartyUnicodeDisplayName, getCurrentCalledPartyUnicodeDisplayNamelocale, getCurrentCallingAddress, getCurrentCallingAddressPI, getCurrentCallingDisplayNamePI, getCurrentCallingPartyDisplayName,getCurrentCallingPartyInfo,getCurrentCallingPartyUnicodeDisplayName, getCurrentCallingPartyUnicodeDisplayNamelocale, getGlobalizedCallingParty, getLastRedirectedPartyInfo, getLastRedirectingAddressPI, getLastRedirectingPartyInfo, getModifiedCalledAddress, getModifiedCallingAddress, startMonitor, startMonitor, transfer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 402 Cisco Unified JTAPI Extensions Inherited Methods

From Interface javax.telephony.callcontrol.CallControlCall addParty, conference, consult, consult, drop, getCalledAddress, getCallingAddress, getCallingTerminal, getConferenceController, getConferenceEnable, getLastRedirectedAddress, getTransferController, getTransferEnable, offHook, setConferenceController, setConferenceEnable, setTransferController, setTransferEnable, transfer, transfer From Interface javax.telephony.Call addObserver, connect, getCallCapabilities, getCapabilities, getConnections, getObservers, getProvider, getState, removeObserver From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Related Documentation See CiscoCall for more information. CiscoConsultCallActiveEv The CiscoConsultCallActiveEv event interface extends the JTAPI CallActiveEv event. This event indicates that the state of the call object changed to Call.ACTIVE and that the call was initiated as a result of a consultative transfer or consultative conference operation (manual or programmatic). Applications can obtain the consulting TerminalConnection on the original (consulting) call by using the CiscoConsultCall.getConsultingTerminalConnection method. The system reports this event to applications via the CallObserver interface. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallActiveEv, javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoConsultCallActiveEv extends CiscoCallEv, javax.telephony.events.CallActiveEv Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 403 Cisco Unified JTAPI Extensions Related Documentation

Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCallEv CAUSE_ACCESSINFORMATIONDISCARDED, CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL, CAUSE_CHANUNACCEPTABLE, CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 404 Cisco Unified JTAPI Extensions Inherited Fields

CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods javax.telephony.TerminalConnectiongetHeldTerminalConnection() Deprecated. Replaced by CiscoConsultCall.getConsultingTerminalConnection() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 405 Cisco Unified JTAPI Extensions Methods

Table 101: Methods in CiscoConsultCallActiveEv Description Method Interface Deprecated method. Replaced by CiscoConsultCall. GetConsultingTerminalConnection(). Returns the consulting TerminalConnection that was used to create this CiscoConsultCall. You can use this method to correlate a consultation call with its original call. The original call does not have any methods that you can use to determine the consultation call, if any, to which it is related. Returns: The consulting TerminalConnection of the call that created the call that is referenced by this event getHeldTerminalConnection() javax.telephony.TerminalConnection Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoCallEv getCiscoCause, getCiscoFeatureReason From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Call, CallObserver, CallActiveEv and Constant Field Values, on page 1667 for more information. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 406 Cisco Unified JTAPI Extensions Inherited Methods

CiscoEv The CiscoEv interface extends this code JTAPI javax.telephony.events.Ev interface and serves as the base interface for all Cisco-extended JTAPI events. Every event in this package extends this interface, directly or indirectly. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.Ev Subinterfaces CiscoAddrActivatedEv, CiscoAddrActivatedOnTerminalEv, CiscoAddrAddedToTerminalEv, CiscoAddrAutoAcceptStatusChangedEv, CiscoAddrCreatedEv, CiscoAddrEv, CiscoAddrInServiceEv, CiscoAddrIntercomInfoChangedEv, CiscoAddrIntercomInfoRestorationFailedEv, CiscoAddrOutOfServiceEv, CiscoAddrRecordingConfigChangedEv, CiscoAddrRemovedEv, CiscoAddrRemovedFromTerminalEv, CiscoAddrRestrictedEv, CiscoAddrRestrictedOnTerminalEv, CiscoCallChangedEv, CiscoCallEv, CiscoCallSecurityStatusChangedEv, CiscoConferenceChainAddedEv, CiscoConferenceChainRemovedEv, CiscoConferenceEndEv, CiscoConferenceStartEv, CiscoConsultCallActiveEv, CiscoMediaOpenLogicalChannelEv, CiscoOutOfServiceEv, CiscoProvCallParkEv, CiscoProvEv, CiscoProvFeatureEv, CiscoProvTerminalCapabilityChangedEv, CiscoRestrictedEv, CiscoRTPInputKeyEv, CiscoRTPInputStartedEv, CiscoRTPInputStoppedEv, CiscoRTPOutputKeyEv, CiscoRTPOutputStartedEv, CiscoRTPOutputStoppedEv, CiscoTermActivatedEv, CiscoTermButtonPressedEv, CiscoTermCreatedEv, CiscoTermDataEv, CiscoTermDeviceStateActiveEv, CiscoTermDeviceStateAlertingEv, CiscoTermDeviceStateHeldEv, CiscoTermDeviceStateIdleEv, CiscoTermDeviceStateWhisperEv, CiscoTermDNDOptionChangedEv, CiscoTermDNDStatusChangedEv, CiscoTermEv, CiscoTermInServiceEv, CiscoTermOutOfServiceEv, CiscoTermRegistrationFailedEv, CiscoTermRemovedEv, CiscoTermRestrictedEv, CiscoTermSnapshotCompletedEv, CiscoTermSnapshotEv, CiscoToneChangedEv, CiscoTransferEndEv, CiscoTransferStartEv Declaration public interface CiscoEv extends javax.telephony.events.Ev Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 407 Cisco Unified JTAPI Extensions CiscoEv

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Ev for more information. CiscoFeatureReason The CiscoFeatureReason interface specifies the feature reason that is associated with each delivered event. Interface History Description Cisco Unified Communications Manager Release Added new reason, FORWARD_NO_RETRIEVE, for the Park Monitoring and Assisted DPark feature. 7.1(1 and 2) A new reason code, REASON_SAF_CCD_PSTN_FAILOVER, has been added to convey the proper reason for a PSTN failover to the application. 8.0(1) A new feature reason, REASON_MEDIA_STREAMING, is added. 8.5(1) A new feature reason, REASON_PLAY_ANNOUNCEMENT, is added. 10.0.1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 408 Cisco Unified JTAPI Extensions Inherited Fields

Declaration public interface CiscoFeatureReason Fields Table 102: Fields in CiscoFeatureReason Description Field Interface Indicates that the reason for the event is BARGE feature. REASON_BARGE static int Indicates that reason is single step transfer REASON_BLINDTRANSFER static int Indicates that the reason for the events is PICKUP REASON_CALLPICKUP static int Indicates that the reason for the events is SIP 3xx feature. REASON_CCM_REDIRECTION static int Indicates that connections have been added or removed by using the Click to Conference feature REASON_CLICK_TO_CONFERENCE static int Indicates that the reason for the event is CONFERENCE REASON_CONFERENCE static int Indicates that the reason for events is DPARK feature REASON_DPARK_CALLPARK static int Indicates that the event is gererated because the call has got de-queued under the Native Queuing Feature. REASON_DEQUEUING public static final int Indicates that the event is generated because the call is de-queued under the Native Queuing Feature as the maximum queue timer expired. REASON_DEQUEUING_TIMER_EXPIRED public static final int Indicates that the event has been gererated because the call has got de-queued under the Native Queuing Feature as the agents were busy and the queue was full. REASON_DEQUEUING_AGENTS_BUSY public static final int Indicates that the event is gererated because the call has got de-queued under the Native Queuing Feature as the agents were either not logged-in or were unregistered. REASON_DEQUEUING_AGENTS_UNAVAILABLE public static final int Indicates that the reason for events in DPARK Reversion REASON_DPARK_REVERSION static int Indicates that the reason for events in DPARK UNPARK REASON_DPARK_UNPARK static int Indicates that the reason for the events is FAC, CMC feature REASON_FAC_CMC static int Indicates that reason for the event is FORWARD REASON_FORWARDALL static int Indicates that the reasons for the event is forward busy REASON_FORWARDBUSY static int Indicates that the reasons for the event is forward no answer REASON_FORWARDNOANSWER static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 409 Cisco Unified JTAPI Extensions Declaration

Description Field Interface Indications that the reason for the event is forward no retrieve REASON_FORWARD_NO_RETRIEVE static int Indicates that the reason for the events is imm divert REASON_IMMDIVERT static int Indicates that the event received is related to an Agent Greeting call REASON_MEDIA_STREAMING static int Indicates that the reason for events caused by Mobility Manager feature REASON_MOBILITY static int Indicates that the reason for events caused by Mobility Manager feature REASON_MOBILITY_CELLPICKUP static int Indicates that the reason for events caused by Mobility Manager feature REASON_MOBILITY_FOLLOWME static int Indicates that the reason for events caused by Mobility Manager feature REASON_MOBILITY_HANDIN static int Indicates that the reason for events caused by Mobility Manager feature REASON_MOBILITY_HANDOUT static int Indicates that the reason for events caused by Mobility Manager feature REASON_MOBILITY_IVR static int Indicates that the reason for the event is NORMAL REASON_NORMAL static int Indicates that the reason for the event is PARK feature REASON_PARK static int Indicates that the reasons for the event is park remainder REASON_PARKREMAINDER static int This interface indicates that the event was generated because of a play announcement. REASON_PLAY_ANNOUNCEMENT public static final int Indicates that the reason for the event is QSIG path replacement REASON_QSIG_PR static int Indicates that the event is generated due to the Native Queuing feature. REASON_QUEUING public static final int Indicates that the reason for event is REDIRECT REASON_REDIRECT static int Returned for events sent for REFER done at Cisco Unified Communications Manager REASON_REFER static int REASON_REPLACE : This reason will be returned for events send for REPLACE feature done at Cisco Unified Communications Manager REASON_REPLACE static int Indicates that the reason for events in SILENT MONITORING REASON_SILENTMONITORING static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 410 Cisco Unified JTAPI Extensions Fields

Description Field Interface Indicates that the reason for the event is TRANSFER REASON_TRANSFER static int Indicates that the reason for the event is unpark REASON_UNPARK static int Indicates the reason for PSTN failover to the application REASON_SAF_CCD_PSTN_FAILOVER static final int Related Documentation See Constant Field Values, on page 1667 for more information. CiscoHuntConnection A CiscoHuntConnection in a call indicates that the call is routed through a hunt pilot. Interface History Description Cisco Unified Communications Manager Release Number New interface 8.0(1) Declaration public interface CiscoHuntConnection extends CiscoConnection. Methods Table 103: Methods in CiscoHuntConnection Description Method Interface This method returns an array of connections to the hunt group member or null. getAgentConnections() Connection[] Related Documentation CiscoIntercomAddress The CiscoIntercomAddress interface extends the CiscoAddress interface with additional Cisco Unified Communications Manager-specific capabilities for intercom addresses. This interface lets applications initiate intercom calls and take advantage of other intercom-specific features. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 411 Cisco Unified JTAPI Extensions Related Documentation

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.Address, CiscoAddress, CiscoObjectContainer Declaration public interface CiscoIntercomAddress extends CiscoAddress Fields None Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoAddress APPLICATION_CONTROLLED_RECORDING, AUTO_RECORDING, AUTOACCEPT_OFF, AUTOACCEPT_ON, AUTOANSWER_OFF, AUTOANSWER_UNKNOWN, AUTOANSWER_WITHHEADSET, AUTOANSWER_WITHSPEAKERSET, EXTERNAL, EXTERNAL_UNKNOWN, IN_SERVICE, INTERNAL, MONITORING_TARGET, NO_RECORDING, OUT_OF_SERVICE, RINGER_DEFAULT, RINGER_DISABLE, RINGER_ENABLE, UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 412 Cisco Unified JTAPI Extensions Superinterfaces

Methods Table 104: Methods in CiscoIntercomAddress Description Method Interface Sets the intercom target DN, intercom target label, and intercom target Unicode label that appears next to the intercom line on the phone. The phone displays the Unicode label if the phone has that capability; otherwise, the phone displays the ASCII target label. Throws javax. telephony. InvalidPartyException means that the target DN is invalid. javax. telephony. InvalidStateException means that the address, terminal, or provider are not in service. Parameters • targetDN—Destination DN for the intercom call • targetAsciiLabel—ASCII display label shown next to the intercom line on the phone target • UnicodeLabel—Unicode display label shown on the phone setIntercomTarget(java. lang. String targetDNjava. lang. String targetAsciiLabel, java. lang. String targetUnicodeLabel) void Returns true if an application has overridden the current value, or false if the current value matches the default value configured in the database. isIntercomTargetSet() Boolean Resets the intercom target DN, intercom target label, and intercom target Unicode label to their default values. Throws javax. telephony. InvalidPartyException javax. telephony. InvalidStateException resetIntercomTarget() void Returns the current intercom target DN that the application set. If the application has not set the intercom target DN, this interface returns the default intercom target DN that is configured in Cisco Unified Communications Manager Administration. Returns: The intercom target DN number, as a string. getIntercomTargetNumber() java. lang. String Returns the current intercom target label that the application set. If the application has not set the intercom target label, this interface returns the default intercom target label that is configured in Cisco Unified Communications Manager Administration. Returns: The intercom target label string. getIntercomTargetAsciiLabel() java. lang. String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 413 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns the current intercom target Unicode label that the application set. If the application has not set the Unicode label, this interface returns the default intercom target Unicode label that is configured in Cisco Unified Communications Manager Administration. Returns: The intercom Unicode target label string. getIntercomTargetUnicodeLabel() java. lang. String Returns the default intercom target DN that is configured through Cisco Unified Communications Manager Administration. Returns: The default intercom target DN number, as a string. getDefaultIntercomTargetNumber() java. lang. String Returns the default intercom target label that is configured through Cisco Unified Communications Manager Administration. Returns: The default intercom target label string. getDefaultIntercomTargetAsciiLabel() java. lang. String Returns the default intercom target label that is configured through Cisco Unified Communications Manager Administration. Returns: The default unicode intercom target label string. getDefaultIntercomTargetUnicodeLabel() java. lang. String Places an intercom call from an originating intercom address to a destination intercom address. Returns:A connection list for the calling and called intercom addresses. Throws javax. telephony. InvalidPartyException—The target DN is not a valid number. javax. telephony. InvalidArgumentException—The address is not a CiscoIntercomAddress or the terminal is not a Terminal. javax. telephony. InvalidStateException—The address, terminal, or provider is not in service. javax. telephony. ResourceUnavailableException—A resource is not available to complete the operation. javax. telephony. PrivilegeViolationException—The application does not have sufficient privileges to execute this operation. connectIntercom(javax. telephony. Terminal terminal, java. lang. String targetNumber) javax. telephony. Connection[] Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoAddress clearCallConnections, getAddressCallInfo, getAutoAcceptStatus, getAutoAnswerStatus, getInServiceAddrTerminals, getPartition, getRecordingConfig, getRegistrationState, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 414 Cisco Unified JTAPI Extensions Inherited Methods

getRestrictedAddrTerminals, getState, getType, isRestricted, setAutoAcceptStatus, setMessageWaiting, setRingerStatus From Interface javax.telephony.Address addCallObserver, addObserver, getAddressCapabilities, getCallObservers, getCapabilities, getConnections, getName, getObservers, getProvider, getTerminals, removeCallObserver, removeObserver From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Related Documentation See CiscoAddress for additional information. CiscoIsacMediaCapability The CiscoIsacMediaCapability object specifies the properties for a iSAC encoded RTP stream. Applications that support iSAC media termination use this object when registering a CiscoMediaTerminal. The packet size and bit rate are variable. Interface History Description Cisco Unified Communications Manager Release Number Interface added in this release for iSac codec which can be used by application to register a CiscoMediaTerminal or CiscoRouteTerminal if they want to use this new MediaCapability. 8.0(1) Superinterfaces None Declaration public class CiscoIsacMediaCapabilityextends CiscoMediaCapability Constuctors Table 105: Constructor in CiscoIsacMediaCapability Description Constructor Interface Constructs a CiscoIsacMediaCapability CiscoIsacMediaCapability() public Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 415 Cisco Unified JTAPI Extensions Related Documentation

Fields None Inherited Fields From Class com.cisco.jtapi.extensions.CiscoMediaCapability G711_64K_30_MILLISECONDS, G723_6K_30_MILLISECONDS, G729_30_MILLISECONDS, GSM_80_MILLISECONDS, ISAC, WIDEBAND_256K_10_MILLISECONDS Methods None Inherited Methods Inherited From Class com.cisco.jtapi.extensions.CiscoMediaCapability getMaxFramesPerPacket, getPayloadType, isSupported, toString Inherited From Class java.lang.Object clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait CiscoJtapiException The CiscoJtapiException interface defines error codes that CTI requests may return. Cisco JTAPI extends all of the JTAPI exceptions to implement this interface. You can get the error codes by casting the exception to CiscoJtapiException and calling the method getErrorCode(). For example, if “e” is any exception caught by an application, the following code checks whether the exception is an instance of CiscoJtapiException. try { // some code here } catch ( Exception e ) { if( e instanceof CiscoJtapiException){ CiscoJtapiException ce

com.cisco.cti.client.CTIFAILURE.(CiscoJtapiException) e int errorCode

com.cisco.cti.client.CTIFAILURE.ce.getErrorCode() //returns the ErrorCode. } } Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 416 Cisco Unified JTAPI Extensions Fields

Interface History Description Cisco Unified Communications Manager Release Number Added this interface. 7.0 Added new error codes for the Logical Partition feature called: CiscoJtapiException.CTIERR_REDIRECT_CALL_PARTITIONING_POLICY and CiscoJtapiException.CTIERR_FEATURE_NOT_AVAILABLE. 7.1(1 and 2) A new error code is added which will be exposed when the monitoring/recording request is rejected when the supervisor/recorder does not meet the security capabilities of the agent. New error code, OPERATION_NOT_AVAILABLE_IN_CURRENT_STATE, has also been added. 8.0(1) The following new error codes are added:CTIERR_MEDIA_CONNECTION_FAILED, CTIERR_REQUEST_ALREADY_PENDING, CTIERR_START_STREAM_MEDIA_FAILED, CTIERR_STOP_STREAM_MEDIA_FAILED, CTIERR_NO_STREAMING_MEDIA_SESSION, CTIERR_EXISTING_STREAMING_MEDIA_SESSIONCTIERR_ MEDIA_ALREADY_TERMINATED_STATIC_GETPORT_SUPPORT, CTIERR_MEDIA_ALREADY_TERMINATED_DYNAMIC_GETPORT_SUPPORT, CTIERR_SSO_DISABLED, CTIERR_SSO_AUTH_SERVER_DOWN. 8.5(1) The following new error codes are added:CTIERR_INVALID_REMOTE_DESTINATION_NUMBER CTIERR_DUPLICATE_REMOTE_DESTINATION_NUMBER CTIERR_REMOTEDESTINATION_LIMIT_EXCEEDED CTIERR_REMOTE_DEVICE_REQUEST_FAILED_ACTIVE_RD_NOT_SET CTIERR_ENDUSER_NOT_ASSOCIATED_WITH_DEVICE CTIERR_DEVICE_ALREADY_REGISTERED_NONEXTEND CTIERR_MEDIA_ALREADY_TERMINATED_EXTEND CTIERR_INVALID_REMOTE_DESTINATION_NAME CTIERR_RECORDING_INVOCATION_TYPE_NOT_MATCHING 9.0(1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 417 Cisco Unified JTAPI Extensions CiscoJtapiException

Description Cisco Unified Communications Manager Release Number The following new error codes are added: CTIERR_AUTHENTICATION_TYPE_ON_UNSUPPORTED_PORT CTIERR_NO_PERSISTENT_CALL_EXISTS CTIERR_ANNOUNCEMENT_ALREADY_IN_PROGRESS CTIERR_ERROR_PLAYING_ANNOUNCEMENT CTIERR_PLAY_ANNOUNCEMENT_FAILED CTIERR_EXTEND_AND_CONNECT_DESTINATION_NOT_REACHABLE CTIERR_CREATE_PERSISTENT_CALL_FAILED CTIERR_PERSISTENT_CALL_EXISTS CTIERR_OPERATION_NOT_ALLOWED_ON_PERSISTENT_CALL CTIERR_DISCONNECT_PERSISTENT_CALL_FAILED_CALL_ACTIVE CTIERR_PERSISTENT_CALL_BEING_SETUP CTIERR_INVALID_SSO_TOKEN_SIZE 10.0(1) Declaration public interface CiscoJtapiException Fields Table 106: Fields in CiscoJtapiException Description Field Interface This error indicates that the request is issued on a line, which is not open ASSOCIATED_LINE_NOT_OPEN static int This error indicates that another call already exists on the line CALL_ALREADY_EXISTS static int The call dropped after the feature request (hold, unhold, transfer, or conference) but before the request was completed. CALL_DROPPED static int This error indicates that an attempt is made to answer a call that either does not exist or is not in the correct state CALLHANDLE_NOTINCOMINGCALL static int This error indicates that attempt to redirect call that was unknown to line control CALLHANDLE_UNKNOWN_TO_ LINECONTROL static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 418 Cisco Unified JTAPI Extensions Declaration

Description Field Interface This error indicates that device open failed because the associated device is unregistering CANNOT_OPEN_DEVICE static int This error indicates that media cannot be terminated by an application when the device is a physical phone (the phone always terminates the media) CANNOT_TERMINATE_MEDIA_ON_PHONE static int This error indicates that attempt to set CFWALL while it is already set CFWDALL_ALREADY_SET static int This error indicates that attempt to CFWALL to an invalid destination CFWDALL_DESTN_INVALID static int This error indicates that link to one of the cisco unified communications managers failed in the cluster (network error) CLUSTER_LINK_FAILURE static int This error indicates that device does not support the command. COMMAND_NOT_IMPLEMENTED_ON_DEVICE static int This error indicates that attempt to conference a party that is already in conference CONFERENCE_ALREADY_PRESENT static int This error indicates that conference completion was not successful. CONFERENCE_FAILED static int This error indicates that all conference bridges are busy. CONFERENCE_FULL static int This error indicates that attempt to complete conference while consult conference is not active CONFERENCE_INACTIVE static int This error indicates that an attempt to conference to self or an invalid participant CONFERENCE_INVALID_PARTICIPANT static int This error indicates that the access to device is denied. CTIERR_ACCESS_TO_DEVICE_DENIED static int This error indicates that the announcement is already in progress. CTIERR_ANNOUNCEMENT_ALREADY_ IN_PROGRESS public static final int This error indicates that the application softkeys are already controlled by another application CTIERR_APP_SOFTKEYS_ALREADY_ CONTROLLED static int This error indicates that application data size has exceeded limit CTIERR_APPLICATION_DATA_SIZE_ EXCEEDED static int This error indicates that the port does not support the authentication type that is used to create the provider. CTIERR_AUTHENTICATION_TYPE_ ON_UNSUPPORTED_PORT static int This error indicates built in bridge is not configured CTIERR_BIB_NOT_CONFIGURED static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 419 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates that built in bridge resource not available CTIERR_BIB_RESOURCE_NOT_ AVAILABLE static int This error indicates that Communications Manager is not available currently CTIERR_CALL_MANAGER_NOT_AVAILABLE static int This error indicates that call does not exist CTIERR_CALL_NOT_EXISTED static int This error indicates no call park DN CTIERR_CALL_PARK_NO_DN static int This error indicates call request already outstanding CTIERR_CALL_REQUEST_ALREADY_ OUTSTANDING static int This error indicates that call unpark did not succeed CTIERR_CALL_UNPARK_FAILED static int This error indicates that capabilities do not match CTIERR_CAPABILITIES_DO_NOT_MATCH static int This error indicates that the close delay is not supported with this registration type CTIERR_CLOSE_DELAY_NOT_ SUPPORTED_WITH_REG_TYPE static int This error indicates that conference already exists CTIERR_CONFERENCE_ALREADY_EXISTED static int This error indicates that conference does not exist CTIERR_CONFERENCE_NOT_EXISTED static int This error indicates application is trying to connect to invalid port CTIERR_CONNECTION_ON_INVALID_PORT static int This error indicates consult call failure CTIERR_CONSULT_CALL_FAILURE static int This error indicates that consult call already outstanding CTIERR_CONSULTCALL_ALREADY_ OUTSTANDING static int This error indicates that device registration failed as device crypto algorithms does not match with current device registration CTIERR_CRYPTO_CAPABILITY_MISMATCH static int This error indicates that CTIHandler process creation failed CTIERR_CTIHANDLER_PROCESS_ CREATION_FAILED static int This error indicates DB initialization error CTIERR_DB_INITIALIZATION_ERROR static int This error indicates that device is already opened CTIERR_DEVICE_ALREADY_OPENED static int This error indicates that device is not yet opened CTIERR_DEVICE_NOT_OPENED_YET static int This error indicates that there is a device registration failure CTIERR_DEVICE_OWNER_ALIVE_ TIMER_STARTED static int This error indicates an invalid media type, CTIPort need to be registered with Dynamic media port registation if it has an intercom line CTIERR_DEVICE_REGISTRATION_FAILED_ NOT_SUPPORTED_ MEDIATYPE static int This error indicates that the device is restricted CTIERR_DEVICE_RESTRICTED static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 420 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates that device is shutting down CTIERR_DEVICE_SHUTTING_DOWN static int This error indicates that there is a directory login time out CTIERR_DIRECTORY_LOGIN_TIMEOUT static int This error indicates duplicate call reference CTIERR_DUPLICATE_CALL_REFERENCE static int This indicates registration failure when Cisco Media/Route Terminal is already registered with different Addressing mode. CTIERR_DYNREG_IPADDRMODE_ MISMATCH static int This error indicates that there was an error playing the announcement. CTIERR_ERROR_PLAYING_ public static final int This error occurs if an application attempts to invoke an Agent Greeting API while another request is made and accepted. JTAPI throws InvalidStateException with a description as “There is an existing streaming media session”. CTIERR_EXISTING_STREAMING_ MEDIA_SESSION static int This error occurs if the extend and connect destination is not reachable. CTIERR_EXTEND_AND_CONNECT_ DESTINATION_NOT_REACHABLE public static final int Client Matter Code (CMC) entered is invalid CTIERR_FAC_CMC_REASON_CMC_ INVALID static int CMC is required to offer the call CTIERR_FAC_CMC_REASON_CMC_ NEEDED static int Forced Authorization Code (FAC) and CMC are required to offer call CTIERR_FAC_CMC_REASON_FAC_ CMC_NEEDED static int FAC entered is invalid CTIERR_FAC_CMC_REASON_FAC_INVALID static int FAC is required to offer the call CTIERR_FAC_CMC_REASON_FAC_ NEEDED static int This error indicates feature already registered CTIERR_FEATURE_ALREADY_REGISTERED static int This error indicates feature data reject CTIERR_FEATURE_DATA_REJECT static int This error indicates that feature select failed CTIERR_FEATURE_SELECT_FAILED static int This error indicates that the device type is illegal CTIERR_ILLEGAL_DEVICE_TYPE static int This error indicates that auto install protocol version is incompatible CTIERR_INCOMPATIBLE_AUTOINSTALL_ PROTOCOL_VERSION static int Device registration failed due to incorrect media capability. CTIERR_INCORRECT_MEDIA_CAPABILITY static int This error indicates that information is not available CTIERR_INFORMATION_NOT_AVAILABLE static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 421 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates that intercom target value is already configured, application is trying to make call with Intercom target DN CTIERR_INTERCOM_SPEEDDIAL_ ALREADY_CONFIGURED static int This error indicates that intercom request failed as intercom target value is already set, application is trying to set again CTIERR_INTERCOM_SPEEDDIAL_ ALREADY_SET static int This error indicates that intercomm request failed as intercom target value in not in the intercom group CTIERR_INTERCOM_SPEEDDIAL_ DESTN_INVALID static int This error indicates that intercom talk back request is already pending CTIERR_INTERCOM_TALKBACK_ ALREADY_PENDING static int This error indicates that talkback request failed for some reason. CTIERR_INTERCOM_TALKBACK_FAILURE static int This error indicates there is a CTI internal failure CTIERR_INTERNAL_FAILURE static int This error indicates the call ID is invalid CTIERR_INVALID_CALLID static int This error indicates that the device name is not valid CTIERR_INVALID_DEVICE_NAME static int Play DTMF request failed because it is an invalid DTMF digit. CTIERR_INVALID_DTMFDIGITS static int This error indicates that filter size is invalid CTIERR_INVALID_FILTER_SIZE static int This error indicates that the media device is not valid CTIERR_INVALID_MEDIA_DEVICE static int This error indicates media parameter is inavlid CTIERR_INVALID_MEDIA_PARAMETER static int This error indicates that there is an invalid media process CTIERR_INVALID_MEDIA_PROCESS static int This error indicates media resource ID is not valid CTIERR_INVALID_MEDIA_RESOURCE_ID static int This error indicates that the header info is not valid CTIERR_INVALID_MESSAGE_HEADER_INFO static int This error indicates that message length is invalid CTIERR_INVALID_MESSAGE_LENGTH static int This error indicates monitoring request failed due to invalid monitoring destination CTIERR_INVALID_MONITOR_DESTN static int This error indicates an invalid monitor DN type CTIERR_INVALID_MONITOR_DN_TYPE static int This error indicates monitor request failed due to an invalid monitor mode CTIERR_INVALID_MONITORMODE static int This error indicates that the parameter is not valid CTIERR_INVALID_PARAMETER static int This error indicates that the DN is an invalid park DN CTIERR_INVALID_PARK_DN static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 422 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates that the handle is an invalid park registration handle CTIERR_INVALID_PARK_REGISTRATION_ HANDLE static int This error indicates an invalid resource type CTIERR_INVALID_RESOURCE_TYPE static int This indicates the registration failure due to IP Addressing Mode mismatch. CTIERR_IPADDRMODE_MISMATCH static int This error indicates that line is out of service. CTIERR_LINE_OUT_OF_SERVICE static int This error indicates that the line is restricted CTIERR_LINE_RESTRICTED static int This error indicates that maximum call limit has reached CTIERR_MAXCALL_LIMIT_REACHED static int This error indicates that device registration failed as device is registered with Dynamic media termination CTIERR_MEDIA_ALREADY_TERMINATED_ DYNAMIC static int This error indicates that the application tries to register a terminal, which is already registered with get port support, with a different registration type. CTIERR_MEDIA_ALREADY_TERMINATED_ DYNAMIC_GETPORT_SUPPORT Final static int This error indicates that device registration failed as device is already registered with media termination none CTIERR_MEDIA_ALREADY_TERMINATED_ NONE static int This error indicates that device registration failed as device is registered with Static media termination CTIERR_MEDIA_ALREADY_TERMINATED_ STATIC static int This error indicates that the application tries to register a terminal, which is already registered with get port support, with a different registration type. CTIERR_MEDIA_ALREADY_TERMINATED_ STATIC_GETPORT_SUPPORT Final static int This error indicates that device registration failed as media capability of device does not match with current device registration CTIERR_MEDIA_CAPABILITY_MISMATCH static int This error indicates that there is a general failure with the Agent Greeting feature. JTAPI throws InvalidStateException with a description as “The connection to the media has failed”. CTIERR_MEDIA_CONNECTION_FAILED static int This error indicates that media resource name size has exceeded limit CTIERR_MEDIA_RESOURCE_NAME_ SIZE_EXCEEDED static int This error indicates that media registration types do not match CTIERR_MEDIAREGISTRATIONTYPE_ DO_NOT_MATCH static int This error indicates that message is too big CTIERR_MESSAGE_TOO_BIG static int This error indicates that there are more active calls than reserved CTIERR_MORE_ACTIVE_CALLS_THAN_ RESERVED static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 423 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates there are no existing calls CTIERR_NO_EXISTING_CALLS static int This error indicates that there is no existing conference CTIERR_NO_EXISTING_CONFERENCE static int This error indicates that no persistent call exists. CTIERR_NO_PERSISTENT_CALL_EXISTS public static final int This error indicates recording request failed as there is no recording session CTIERR_NO_RECORDING_SESSION static int This error indicates no response from media resource CTIERR_NO_RESPONSE_FROM_MP static int This error occurs if an application attempts to invoke a stop request while there is no existing media stream to stop. JTAPI throws InvalidStateException with a description as “There is no streaming media session active”. CTIERR_NO_STREAMING_MEDIA_SESSION static int This error indicates that the call is not preserved CTIERR_NOT_PRESERVED_CALL static int This error indicates that feature unavailable for this call due to temporary failure CTIERR_OPERATION_FAILED_QUIETCLEAR static int This error indicates that this operation is not allowed CTIERR_OPERATION_NOT_ALLOWED static int This error indicates out of bandwidth error CTIERR_OUT_OF_BANDWIDTH static int This error indicates a failure during registering the device CTIERR_OWNER_NOT_ALIVE static int This error indicates that there is a pending accept or answer request CTIERR_PENDING_ACCEPT_OR_ ANSWER_REQUEST static int This error indicates there is a pending start monitoring request CTIERR_PENDING_START _MONITORING_REQUEST static int This error indicates there is a pending start recording request CTIERR_PENDING_START_RECORDING_ REQUEST static int This error indicates there is a pending stop recording request CTIERR_PENDING_STOP_RECORDING_ REQUEST static int This error indicates that the play announcement failed. CTIERR_PLAY_ANNOUNCEMENT_FAILED public static final int This error indicates that primary call in monitoring request in invalid or gone idle CTIERR_PRIMARY_CALL_INVALID static int This error indicates that primary call in monitoring request is in invalid state CTIERR_PRIMARY_CALL_STATE_INVALID static int This error indicates recording request failed that recording is already in progress CTIERR_RECORDING_ALREADY_ INPROGRESS static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 424 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates recording configuration does not match CTIERR_RECORDING_CONFIG_NOT_ MATCHING static int This error indicates recording request failed because recording session is inactive CTIERR_RECORDING_SESSION_INACTIVE static int This error indicates a redirect unauthorized command usage CTIERR_REDIRECT_UNAUTHORIZED_ COMMAND_USAGE static int This error indicates that register feature activation failed CTIERR_REGISTER_FEATURE_ ACTIVATION_FAILED static int Register feature application was already registered CTIERR_REGISTER_FEATURE_APP_ ALREADY_REGISTERED static int Register feature provider was not registered. CTIERR_REGISTER_FEATURE_PROVIDER_ NOT_REGISTERED static int This error occurs if an application attempts to invoke an Agent Greeting API while another request is made. JTAPI throws InvalidStateException with a description as “The request was rejected because there is a similar request already pending”. CTIERR_REQUEST_ALREADY_PENDING static int This error indicates that resource is not available to fulfil the request CTIERR_RESOURCE_NOT_AVAILABLE static int This error code is exposed when the monitoring/recording request is rejected when the supervisor/recorder does not meet the security capabilities of the agent. CTIERR_SECURITY_CAPABILITY_MISMATCH public static final int This error code is returned if authorization server is down. CTIERR_SSO_AUTH_SERVER_DOWN int This error code is returned if the Single Sign-On feature is not enabled on Cisco Unified Communications Manager. CTIERR_SSO_DISABLED int This error indicates that start monitoring request failed CTIERR_START_MONITORING_FAILED static int This error indicates that start recording request failed CTIERR_START_RECORDING_FAILED static int This error occurs if there is a general failure with the Agent Greeting feature, that is not covered by any of the other error codes.JTAPI throws InvalidStateException with a description as “Start streaming media request failed”. CTIERR_START_STREAM_MEDIA_FAILED static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 425 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error occurs if there is a general failure with the Agent Greeting feature, that is not covered by any of the other error codes. JTAPI throws InvalidStateException with a description as “Stop streaming media request failed”. CTIERR_STOP_STREAM_MEDIA_FAILED static int This error indicates that there is a station shutdown CTIERR_STATION_SHUT_DOWN static int This error indicates CTI system error CTIERR_SYSTEM_ERROR static int This error indicates UDP data passthrough not supported CTIERR_UDP_PASS_THROUGH_NOT_ SUPPORTED static int This error indicates an unknown exception occured CTIERR_UNKNOWN_EXCEPTION static int This error indicates that call park type is not supported CTIERR_UNSUPPORTED_CALL_PARK_ TYPE static int This error indicates that the call forward type is unsupported CTIERR_UNSUPPORTED_CFWD_TYPE static int This error indicates user is not authorized for secure connection CTIERR_USER_NOT_AUTH_FOR_SECURITY static int This error indicates redirect is not authorized CTIERR_REDIRECT_CALL_PARTITIONING_ POLICY static int This error indicates that the feature is unavailable CTIERR_FEATURE_NOT_AVAILABLE static int This error indicates that there is an internal call processing error: DaRes invalid request type DARES_INVALID_REQ_TYPE static int This error indicates that XML data object size is bigger than allowed. DATA_SIZE_LIMIT_EXCEEDED static int This error indicates that the device query contained an illegal device type DB_ERROR static int This error indicates illegal device type in DB DB_ILLEGAL_DEVICE_TYPE static int This error is no longer used. DB_NO_MORE_DEVICES static int This error indicates that destination is busy DESTINATION_BUSY static int This error indicates that destination is not found DESTINATION_UNKNOWN static int This error indicates that device registration attempt failed, because the device is already registered DEVICE_ALREADY_REGISTERED static int This error indicates that an attempt to open a line failed, as the device is not opened or the device is not registered. DEVICE_NOT_OPEN static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 426 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates that device is out of service. DEVICE_OUT_OF_SERVICE static int This error indicates that digit generation is already in progress. DIGIT_GENERATION_ALREADY_IN_ PROGRESS static int This error indicates that call state is invalid to continue. DIGIT_GENERATION_CALLSTATE_ CHANGED static int This error indicates that call handle is invalid and call may be gone. DIGIT_GENERATION_WRONG_CALL_ HANDLE static int This error indicates that call state is not valid to generate digits. DIGIT_GENERATION_WRONG_CALL_ STATE static int This error indicates that directory login failed: directory not initialized DIRECTORY_LOGIN_FAILED static int This error indicates that directory login failed DIRECTORY_LOGIN_NOT_ALLOWED static int This error indicates that directory is temporarily unavailable. DIRECTORY_TEMPORARY_UNAVAILABLE static int This error indicates that there is already a device controlling media. EXISTING_FIRSTPARTY static int This error indicates that the hold was rejected by line control or call control layers HOLDFAILED static int This error indicates that an attempt was made to originate call using a calling party that is not on the device ILLEGAL_CALLINGPARTY static int This error indicates line is not in a legal state to invoke the request ILLEGAL_CALLSTATE static int This error indicates the handle is not valid ILLEGAL_HANDLE static int This error indicates that there is a QBE protocol error ILLEGAL_MESSAGE_FORMAT static int This error indicates that JTAPI and CTI versions are not compatible : CTI Error Protocol version not supported INCOMPATIBLE_PROTOCOL_VERSION static int This error indicates that attempt to perform a line operation on an invalid line handle. INVALID_LINE_HANDLE static int This error indicates that the ring option is invalid INVALID_RING_OPTION static int This error indicates that line is greater than the maximum available lines on this device LINE_GREATER_THAN_MAX_LINE static int This error indicates that line information does not exist in the database. LINE_INFO_DOES_NOT_EXIST static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 427 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates that internal error returned from call control. LINE_NOT_PRIMARY static int This error indicates line control refuses to allow a new call to be initiated because of its current state. LINECONTROL_FAILURE static int The maximum number of CTI connections was reached. MAX_NUMBER_OF_CTI_CONNECTIONS_ REACHED static int This error indicates that attempt to set message waiting lamp for an invalid DN; Message Waiting Destination not found. MSGWAITING_DESTN_INVALID static int This error indicates there is no active device for thirdparty NO_ACTIVE_DEVICE_FOR_THIRDPARTY static int This error indicates that no conference bridge available NO_CONFERENCE_BRIDGE static int This error indicates that attempt is made to open a provider before CTI initialization completes NOT_INITIALIZED static int This error indicates that the operation is not available in Current state. OPERATION_NOT_AVAILABLE_IN_ CURRENT_STATE static int Internal error returned from call control PROTOCOL_TIMEOUT static int This error indicates that an attempt is made to reopen provider PROVIDER_ALREADY_OPEN static int Attempt to close provider while it is already closed PROVIDER_CLOSED static int This error indicates that device list incomplete or device list query timeout or query aborted PROVIDER_NOT_OPEN static int This error indicates that internal error is returned from call control REDIRECT_CALL_CALL_TABLE_FULL static int This error indicates that the redirect destination is busy REDIRECT_CALL_DESTINATION_BUSY static int This error indicates that redirect destination is out of order REDIRECT_CALL_DESTINATION_OUT_ OF_ORDER static int This error indicates a digit analyss time out, this is an internal error returned from call control REDIRECT_CALL_DIGIT_ANALYSIS_ TIMEOUT static int This error indicates that an attempt is made to redirect a call that does not exist or is not longer active REDIRECT_CALL_DOES_NOT_EXIST static int This error indicates that internal error is returned from call control REDIRECT_CALL_INCOMPATIBLE_STATE static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 428 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates media connection failure, this is an internal error returned from call control REDIRECT_CALL_MEDIA_CONNECTION_ FAILED static int This error indicates that redirect failed because of normal call clearing REDIRECT_CALL_NORMAL_CLEARING static int This error indicates that far end hung up on the call being redirected REDIRECT_CALL_ORIGINATOR_ ABANDONED static int This error indicates that internal error is returned from call control REDIRECT_CALL_PARTY_TABLE_ FULL static int This error indicates that internal error is returned from call control REDIRECT_CALL_PENDING_REDIRECT_ TRANSACTION static int This error indicates a protocol error, this is an internal error returned from call control REDIRECT_CALL_PROTOCOL_ERROR static int This error indicates that an attempt is made to redirect to an unknown destination REDIRECT_CALL_UNKNOWN_DESTINATION static int This error indicates that internal error is returned from call control REDIRECT_CALL_UNKNOWN_ERROR static int This error indicates an unknown party is detected, this is an internal error returned from call control REDIRECT_CALL_UNKNOWN_PARTY static int This error indicates that internal error is returned from call control REDIRECT_CALL_UNRECOGNIZED_ MANAGER static int This error indicates that internal error is returned from call control REDIRECT_CALLINFO_ERR static int This error indicates that internal error is returned from call control REDIRECT_ERR static int This error indicates that retrieval of call was rejected by line control or call control RETRIEVEFAILED static int This error indicates that error occurred in retrieving held call; because there is already another active call on the line RETRIEVEFAILED_ACTIVE_CALL_ON_LINE static int This error indicates that the redirect command was issued when the internal supporting interface was not initialized; either CTI has not yet finished its initialization or an internal error occurred SSAPI_NOT_REGISTERED static int This error indicates that the request has timed out. TIMEOUT static int This error indicates that attempt to complete transfer, while consult tranfer is not there TRANSFER_INACTIVE static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 429 Cisco Unified JTAPI Extensions Fields

Description Field Interface This error indicates that the transfer failed probably because one of the call legs was hung up or disconnected from the far end TRANSFERFAILED static int This error indicates that expected response from call control not received during a transfer TRANSFERFAILED_CALLCONTROL_ TIMEOUT static int This error indicates that an attempt is made to transfer call to a busy destination TRANSFERFAILED_DESTINATION_BUSY static int This error indicates an attempt is made to to transfer call to a directory number that is not registered TRANSFERFAILED_DESTINATION_ UNALLOCATED static int This error indicates that existing transfer is still in progress TRANSFERFAILED_OUTSTANDING_ TRANSFER static int This error indicates that the line that was specified, is not found on the device UNDEFINED_LINE static int This error indicates that the global call handle is unknown UNKNOWN_GLOBAL_CALL_HANDLE static int This error indicates that there is a QBE protocol error UNRECOGNIZABLE_PDU static int This error indicates that an unspecified error has occured. UNSPECIFIED static int Inherited Fields None Methods Table 107: Methods in CiscoJtapiException Description Method Interface Returns the errorCode as an integer for this exception. getErrorCode() int Returns the detailed description of the errorCode getErrorDescription() java.lang.String Deprecated Use String getErrorDescription (); instead. Returns the detailed description of the errorCode. getErrorDescription(int errorCode) java.lang.String Returns an exception in string format. getErrorName() java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 430 Cisco Unified JTAPI Extensions Inherited Fields

Description Method Interface Deprecated Use String getErrorName (); instead. Returns an exception in string format. getErrorName(int errorCode) java.lang.String Inherited Methods None Related Documentation See Constant Field Values, on page 1667 for more information. CiscoMediaStreamStartedEv Applications receive the event when they observe a device that is the target of a “addMediaStream()” invocation. This is the Agent device. This event is sent when the media begins to play on the call. This event is only deliviered to the device that invokes the original request. Multiple observers on the same address receive the events. Shared lines of the invoking device will not receive this event. Declaration public interface CiscoMediaStreamStartedEv extends CiscoCallEv Fields None Inherited Fields None Methods None Inherited Methods None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 431 Cisco Unified JTAPI Extensions Inherited Methods

CiscoMediaStreamEndedEv Applications receive the event when they observe a device that is the target of a “addMediaStream()” invocation. This is the Agent device. This event is sent when the media has finished playing on the call. It contains a field that it exposes if the media is played successfully, or if the end event is the result of an error. This event is only delivered to the device that invokes the original request. Shared lines of the invoking device will not receive this event. Declaration public interface CiscoMediaStreamEndedEv extends CiscoCallEv Fields Table 108: Fields in CiscoMediaStreamEndedEv Description Field Interface This result code indicates that the CiscoMediaStreamEndedEv is received due to some failure with the request that caused it to end early. RESULT_FAILED static int This result code indicates that the CiscoMediaStreamEndedEv is received as a result of successful media streaming. RESULT_SUCCESS static int This result code indicates that the CiscoMediaStreamEndedEv is received due to the primary call. RESULT_PRIMARY_CALL_DROPPED static int Inherited Fields None Methods Table 109: Fields in CiscoMediaStreamEndedEv Description Method Interface Returns one of the above result codes, which allows the applications to figure out if the CiscoMediaStreamEndedEv is received due to an error, or upon a successful request. getResult() boloean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 432 Cisco Unified JTAPI Extensions CiscoMediaStreamEndedEv

Inherited Methods None CiscoJtapiPeer By extending the com.cisco.services.tracing.TraceModule interface, CiscoJtapiPeer exposes trace information to applications. All instances of JtapiPeer objects that the Cisco JTAPI implementation creates implement this interface. Applications that want to manipulate the trace settings of the Cisco JTAPI implementation may use the CiscoJtapiPeer.getTraceManager method to obtain its TraceManager object. Applications can then manipulate the TraceManager object as described in the com.cisco.services.tracing package. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Added a new API getprovider(). 8.5(1) Superinterfaces CiscoObjectContainer, javax.telephony.JtapiPeer, TraceModule Declaration public interface CiscoJtapiPeer extends TraceModule, javax.telephony.JtapiPeer, CiscoObjectContainer Fields None Methods Table 110: Methods in CiscoJtapiPeer Description Method Interface Defines the various methods that applications can use to modify the parameters that the JTAPI layer will use. getJtapiProperties () CiscoJtapiProperties Provides applications ability to save changes made to CiscoJtapiProperties in jtapi.ini file and activate these changes in properties for the providers in JTAPIPeer. setJtapiProperties (CiscoJtapiProperties jtapiproperties) void Enhanced to read the singlesignon ticket as ssoticket = "ssoticketfromAD". getprovider () Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 433 Cisco Unified JTAPI Extensions Inherited Methods

Inherited Methods From Interface com.cisco.services.tracing.TraceModule getTraceManager, getTraceModuleName From Interface javax.telephony.JtapiPeer getName, getProvider, getServices From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Related Documentation See CiscoJtapiProperties and TraceModule for more information. CiscoJtapiPeerImpl This interface has a method called “getProvider(), ” which is the primary way for applications to open a JTAPI provider. This method takes a “provider string, ” and it was enhanced to take a new argument. Declaration public interface CiscoJtapiPeerImpl extends ObjectContainerImpl implements CiscoJtapiPeer Fields Methods Table 111: Methods in CiscoJtapiPeerImpl Description Method Interface The provider string argument is a string of key or value pairs . A new key was added to this method to allow applications to specify whether to run in FIPS compliant mode. The new argument is “FIPSCompliant, ” and applications should specify “true” or “false.” Specifying any value for the FIPSCompliant parameter in the Provider String will have no affect if the provider is not configured as a secured connection. getProvider(String providerString) provider Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 434 Cisco Unified JTAPI Extensions Inherited Methods

CiscoJtapiProperties Cisco Unified JTAPI behavior and functionality is tailored by many parameters which are read in from the jtapi.ini file when an instance of CiscoJtapiPeer is instantiated. These parameters are now exposed to applications for control via this CiscoJtapiproperties interface. Applications can query the CiscoJtapiproperties properties object and change these parameters to better suit the application functionality. Exposing these properties via the CiscoJtapiproperties interface also allows applications to have a single point of administration (at the application end) for these parameters. The most visible parameters are those describing the tracing levels and tracing destinations. Usage JtapiPeer peer

JtapiPeerFactory.getJtapiPeer ( null ); if(peer instanceof CiscoJtapiPeer) { CiscoJtapiProperties jProps

((CiscoJtapiPeer)peer).getJtapiProperties(); jProps.setTracePath("\D:\Traces\WorkFlow"); jProps.setUseJavaConsoleTrace(false); MyProviderObserver providerObserver

new MyProviderObserver (); provider

peer.getProvider ( providerName ); } In the above example an application has set the Java console tracing to off and set the trace path to D:\Traces\WorkFlowApp1.When the peer is obtained an object implementing CiscoJtapiProperties is created by reading parameters set in the jtapi.ini file. If no jtapi.ini file exists in the classpath default settings are used to create this object. The parameters used by Cisco Jtapi are read in and frozen when the first getProvider () call is made. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Enhanced with methods to enable/disable the HuntList feature. 8.0(1) Enhanced with methods for applications to specify a desired level of FIPS compliance when they download certificates. 8.6(1) Enhanced with methods for applications to specify the minimum TLS version desired when communicating to CAPF or CTI Manager. Four new fields have been introduced: TLS_V1_0 TLS_V1_1 TLS_V1_2 TLS_V1_3 15SU3 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 435 Cisco Unified JTAPI Extensions CiscoJtapiProperties

Sample Code try { JtapiPeer peer

JtapiPeerFactory.getJtapiPeer ( null ); MyProviderObserver providerObserver

new MyProviderObserver (); provider

peer.getProvider ( ipaddress;login = useid;passwd = password ); if ( provider ! = null ) { provider.addObserver ( providerObserver ); provInService.waitTrue(); boolean hlenabled

((CiscoJtapiPeer)peer).getJtapiProperties().getHuntListEnabled(); System.out.Println(“Initial state of HuntList

“ + hlenabled); CiscoJtapiProperties cjp

((CiscoJtapiPeer)peer).getJtapiProperties(); cjp.setHuntListEnabled(true); ((CiscoJtapiPeer)peer).setJtapiProperties(cjp); boolean hlenabled

((CiscoJtapiPeer)peer).getJtapiProperties().getHuntListEnabled(); System.out.Println(“Final state of HuntList

“ + hlenabled); } Declaration public interface CiscoJtapiProperties Fields Table 112: Fields in CiscoJtapiProperties Description Field Return Type TLS protocol version 1.0 TLS_V1_0 static int TLS protocol version 1.1 TLS_V1_1 static int TLS protocol version 1.2 TLS_V1_2 static int TLS protocol version 1.3 TLS_V1_3 static int Methods Table 113: Methods in CiscoJtapiProperties Description Method Interface Deletes X.509 client certificate installed for USER Instance in certificate store. deleteCertificates(java.lang.String username, java.lang.String instanceID, java.lang.String ccmCAPFAddress, java.lang.String certificatePath) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 436 Cisco Unified JTAPI Extensions Declaration

Description Method Interface Deletes security properly from jtapi.ini file and also delete certificate previously installed for username/instanceId. deleteSecurityPropertyForInstance(java.lang.String username, java.lang.String instanceID, java.lang.String capfIp, java.lang.String certPath) void Gets the alarm service host name. getAlarmServiceHostname() java.lang.String Gets the port number for the alarm service. getAlarmServicePort() int Advises the application if it would receive the event CallSecurityStatusChangedEv when applicable. getCallSecurityStatusChangedEv() boolean Gets the timeout for CTI requests, other than the provider open (seconds). getCtiRequestTimeout() int Get names of supported debugging level jtapi traces. getDebuggingNames() java.lang.String[] Get the enabled or disabled state of a debugging level trace. getDebuggingValue(java.lang.String debuggingName) boolean Get the desired interval at which the CTI Manager must send heartbeats to JTAPI (seconds). getDesiredServerHeartbeatInterval() int Controls the event order for the scenario when only the redirected party in observed by Application This interface returns True if ConnDisconnectedEv is send before ConnCreatedEv, False otherwise. getDiscConnBeforeCreatingInCPIC() boolean Gets the filename for individual log files. getFileNameBase() java.lang.String Gets the filename extension for log files. getFileNameExtension() java.lang.String Returns true if HuntList is enabled else false. getHuntListEnabled() Boolean Returns the value of service parameter for SOCKET CONNECT TIMEOUT in seconds. getJavaSocketConnectTimeout() int Gets the minimum TLS version to be used for secure communication to CTIManager and CAPF services. The values returned are as defined in Constant Field Values. getMinimumTLSVersion() int Gets the number of trace files before rollover. getNumTraceFiles() int Gets the enabled state of periodic wake up. getPeriodicWakeupEnabled() boolean Gets the interval for periodic wakeup (milliseconds). getPeriodicWakeupInterval() int Retrieves the boolean value for the jtapi.ini parameter ProcessOfferringAfterNewcallEvent'. By default this interface returns false. getProcessOfferingAfterNewcallevent() boolean Gets the timeout for a provider open request (seconds). getProviderOpenRequestTimeout() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 437 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns the value of the service parameter for the maximum number of reconnect attempts to CTI Manager. getProviderOpenRetryAttempts() int Gets the interval at which the connection to the CTI Manager will ge retried (seconds). getProviderRetryInterval() int Gets the threshold for the event queue size to trigger alarms. getQueueSizeThreshold() int Gets the enabled state of event queue stats. getQueueStatsEnabled() boolean Gets the route select timeout (milliseconds). getRouteSelectTimeout() int Returns a Hash table with all the parameters set for users and InstanceIDs. See User/InstanceID Hash Table, on page 442 for key and value pairs. getSecurityPropertyForInstance() java.util.Hashtable Returns a Hash table with all the parameters set for users and InstanceIDs. See User/InstanceID Hash Table, on page 442 for key and value pairs. getSecurityPropertyForInstance(java.lang.String user, java.lang.String instanceID) java.util.Hashtable Returns the services that this implementation supports. getServices() java.lang.String[] Gets the syslog collector hostname. getSyslogCollector() java.lang.String Gets the syslog collector UDP port. getSyslogCollectorUDPPort() int Path directory where trace files will be written. getTraceDirectory() java.lang.String Trace file size before rollover. getTraceFileSize() int Gets the names of supported jtapi traces. getTraceNames() java.lang.String[] Gets the path where the trace files will be located. getTracePath() java.lang.String Gets the enabled or disabled state of a trace. getTraceValue(java.lang.String traceName) boolean Queries the parameter setting that changes Jtapi behavior on updating called address. getUpdateJtapiCalledWithOriginalCalled() boolean gets the enabled/disabled state of the alarm service. getUseAlarmService() boolean Gets the enabled or disabled state of jtapi log file tracing. getUseFileTrace() boolean Gets the enabled or disabled state of jtapi console tracing. getUseJavaConsoleTrace() boolean Causes the traces to go to a single directory if UseSameDir is true. getUseSameDir() boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 438 Cisco Unified JTAPI Extensions Methods

Description Method Interface Gets the enabled or disabled state of syslog tracing. getUseSyslog() boolean Provides information about where Client and Server certificates are updated for a given user/instanceID or if the Client and Server certificates are not updated. IsCertificateUpdated(java.lang.String user, java.lang.String instanceID) boolean Sets the alarm service host name. setAlarmServiceHostname(java.lang.String hostname) void Sets the port number the alarm service is listening on. setAlarmServicePort(int portNumber) void Enables applications to set the filter to receive CallSecurityStatusChangedEv to true or false. setCallSecurityStatusChangedEv(boolean val) void Sets the time out for CTI requests other than provider open (seconds). setCtiRequestTimeout(int seconds) void Enables or disables a particular debugging level trace. setDebuggingValue(java.lang.String debuggingName, boolean value) void Sets the desired interval at which the CTI Manager must send heartbeats to JTAPI (seconds). setDesiredServerHeartbeatInterval(int seconds) void Sets event order, sent Disconnect before Connection created during redirect at redirted party. setDiscConnBeforeCreatingInCPIC(boolean val) void Sets the filename for log files. setFileNameBase(java.lang.String base) void Sets the filename extension for log files. setFileNameExtension(java.lang.String extn) void Enables the Hunt List Feature in Cisco Unified JTAPI. setHuntListEnabled (boolean) void Allows application to set the SOCKET CONNECT TIMEOUT in seconds. setJavaSocketConnectTimeout(int timeout) void Sets the minimum TLS version to be used for secure communication to CTIManager and CAPF services. The values returned are as defined in Constant Field Values. setMinimumTLSVersion(int protocol) void Sets the number of trace files before rollover. setNumTraceFiles(int val) void Sets the enable/disable state for periodic wake up. setPeriodicWakeupEnabled(boolean enabled) void Sets the periodic wake up interval (milliseconds). setPeriodicWakeupInterval(int milliseconds) void Controls the event order for the transfer scenario when only transfer destination observed by Application and transfer is completed in offering state. setProcessOfferingAfterNewcallevent(boolean val) void Sets the timeout for a provider open request (seconds). setProviderOpenRequestTimeout(int seconds) void Allows application to set the JTAPI Reconnect Attempts to CTI Manager. setProviderOpenRetryAttempts(int retryAttempts) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 439 Cisco Unified JTAPI Extensions Methods

Description Method Interface Sets the interval at which the connection to the CTI Manager will ge retried (seconds). setProviderRetryInterval(int seconds) void Sets the threshold for the event queue size to trigger alarms. setQueueSizeThreshold(int size) void Enables and disables event queue statistics. setQueueStatsEnabled(boolean enabled) void Sets the route select timeout milliseconds. setRouteSelectTimeout(int milliseconds) void Deprecated This method is replaced by overloaded method setSecurityPropertyForInstance which takes an extra parameter certStorePassphrase, a passphrase for java key store. This method might have some security vulnerability. setSecurityPropertyForInstance(java.lang.String user, java.lang.String instanceID, java.lang.String authCode, java.lang.String tftp, java.lang.String tftpPort, java.lang.String capf, java.lang.String capfPort, java.lang.String certPath, boolean securityOption) void Provides the application ability to downloading server/client cerfiticate and set security property for application instance in jtapi.ini file of JTAPI. setSecurityPropertyForInstance(java.lang.String user, java.lang.String instanceID, java.lang.String authCode, java.lang.String tftp, java.lang.String tftpPort, java.lang.String capf, java.lang.String capfPort, java.lang.String certPath, boolean securityOption, java.lang.String certstorePassphrase) void This method provides applications the ability to download server/client certificate and set the security property for this application instance in the jtapi.ini file. Specifying any value of fipsCompliant for this method will have no effect unless the securityOption is set to true. It should be noted that this method will call updateCertificate() and updateServerCertificate(). This is the preferred way to acquire certificates. setSecurityPropertyForInstance(String user, String instanceID, String authCode, String tftp, String tftpPort, String capf, String capfPort, String certPath, boolean securityOption, String certstorePassphrase, boolean fipsCompliant) void Sets a list of available services. setServices(java.lang.String[] services) void Sets the syslog collector hostname. setSyslogCollector(java.lang.String value) void Sets the syslog collector UDP port. setSyslogCollectorUDPPort(int port) void Sets the directory where jtapi trace files should be written. setTraceDirectory(java.lang.String dir) void Sets the size of the trace file. setTraceFileSize(int val) void Sets the directory root where jtapi traces will be written. setTracePath(java.lang.String path) void Enables or disables a particular trace. setTraceValue(java.lang.String traceName, boolean value) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 440 Cisco Unified JTAPI Extensions Methods

Description Method Interface Updates Jtapi Called information with original called once the parameter is set to true always. setUpdateJtapiCalledWithOriginalCalled(boolean val) void Enables or disables the alarm service. setUseAlarmService(boolean value) void Enables or disables jtapi log file tracing. setUseFileTrace(boolean value) void Enables or disables jtapi console tracing. setUseJavaConsoleTrace(boolean value) void Causes the traces to go to a single directory if UseSameDir is true. setUseSameDir(boolean value) void Enables or disables syslog tracing. setUseSyslog(boolean value) void Deprecated This method is replaced by overloaded method updateCertifcate which takes an extra parameter certStorePassphrase, a passphrase for java key store. This method might have some security vulnerability. updateCertificate(java.lang.String user, java.lang.String intanceID, java.lang.String authcode, java.lang.String ccmTFTPAddress, java.lang.String ccmTFTPPort, java.lang.String ccmCAPFAddress, java.lang.String ccmCAPFPort, java.lang.String certificatePath) void Installs an X.509 client certificate for USER Instance in cerfiticate store. updateCertificate(java.lang.String user, java.lang.String intanceID, java.lang.String authcode, java.lang.String ccmTFTPAddress, java.lang.String ccmTFTPPort, java.lang.String ccmCAPFAddress, java.lang.String ccmCAPFPort, java.lang.String certificatePath, java.lang.String certStorePassphrase) void This method downloads the client and server certificates for the specified parameters. updateCertificate(String user, String intanceID, String authcode, String ccmTFTPAddress, String ccmTFTPPort, String ccmCAPFAddress, String ccmCAPFPort, String certificatePath, String certStorePassphrase, boolean fipsCompliant) throws Exception, IOException, UnknownHostException; void Deprecated This method is replaced by overloaded method updateServerCertifcate which takes an extra parameter certStorePassphrase, a passphrase for java key store. This method might have some security vulnerability. updateServerCertificate(java.lang.String ccmTFTPAddress, java.lang.String ccmTFTPPort, java.lang.String ccmCAPFAddress, java.lang.String ccmCAPFPort, java.lang.String certificatePath) void Installs an X.509 server certificate given certificate path. updateServerCertificate(java.lang.String userName, java.lang.String instanceID, java.lang.String ccmTFTPAddress, java.lang.String ccmTFTPPort, java.lang.String ccmCAPFAddress, java.lang.String ccmCAPFPort, java.lang.String certificatePath, java.lang.String certStorePassphrase) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 441 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method downloads the server certificates for the specified parameters. It is called by updateCertificate(). updateServerCertificate(String userName, String instanceID, String ccmTFTPAddress, String ccmTFTPPort, String ccmCAPFAddress, String ccmCAPFPort, String certificatePath, String certStorePassphrase, boolean fipsCompliant) throws Exception, IOException, UnknownHostException; void User/InstanceID Hash Table Table 114: User/InstanceID Hash Table Value Key userName “user” InstanceID String "instanceID" authCode String"AuthCode" capfServerIP-Address String "CAPF" capfServer IP-Address port String "CAPFPort" tftpServer IP-Address String "TFTP" tftpServer IP-Address port String "TFTPPort" certificate Path String "CertPath" Boolean security option (true for enable/ false for disabled) String "securityOption" Boolean certificate status (true for updated/ false for not updated) String "certificateStatus" Related Documentation CiscoLocales This interface lists all the locales that Cisco Unified JTAPI supports. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 442 Cisco Unified JTAPI Extensions User/InstanceID Hash Table

Declaration public interface CiscoLocales Fields Table 115: Fields in CiscoLocales Field Interface LOCALE_ARABIC_ALGERIA static int LOCALE_ARABIC_BAHRAIN static int LOCALE_ARABIC_EGYPT static int LOCALE_ARABIC_IRAQ static int LOCALE_ARABIC_JORDAN static int LOCALE_ARABIC_KUWAIT static int LOCALE_ARABIC_LEBANON static int LOCALE_ARABIC_MOROCCO static int LOCALE_ARABIC_OMAN static int LOCALE_ARABIC_QATAR static int LOCALE_ARABIC_SAUDI_ARABIA static int LOCALE_ARABIC_TUNISIA static int LOCALE_ARABIC_UNITED_ARAB_EMIRATES static int LOCALE_ARABIC_YEMEN static int LOCALE_BULGARIAN_BULGARIA static int LOCALE_CATALAN_SPAIN static int LOCALE_CHINESE_HONG_KONG static int LOCALE_CROATIAN_CROATIA static int LOCALE_CZECH_CZECH_REPUBLIC static int LOCALE_DANISH_DENMARK static int LOCALE_DUTCH_NETHERLAND static int LOCALE_ENGLISH_UNITED_KINGDOM static int LOCALE_ENGLISH_UNITED_STATES static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 443 Cisco Unified JTAPI Extensions Declaration

Field Interface LOCALE_FINNISH_FINLAND static int LOCALE_FRENCH_FRANCE static int LOCALE_GERMAN_GERMANY static int LOCALE_GREEK_GREECE static int LOCALE_HEBREW_ISRAEL static int LOCALE_HUNGARIAN_HUNGARY static int LOCALE_ITALIAN_ITALY static int LOCALE_JAPANESE_JAPAN static int LOCALE_KOREAN_KOREA static int LOCALE_NORWEGIAN_NORWAY static int LOCALE_POLISH_POLAND static int LOCALE_PORTUGUESE_BRAZIL static int LOCALE_PORTUGUESE_PORTUGAL static int LOCALE_ROMANIAN_ROMANIA static int LOCALE_RUSSIAN_RUSSIA static int LOCALE_SERBIAN_REPUBLIC_OF_MONTENEGRO static int LOCALE_SERBIAN_REPUBLIC_OF_SERBIA static int LOCALE_SIMPLIFIED_CHINESE_CHINA static int LOCALE_SLOVAK_SLOVAKIA static int LOCALE_SLOVENIAN_SLOVENIA static int LOCALE_SPANISH_SPAIN static int LOCALE_SWEDISH_SWEDEN static int LOCALE_THAI_THAILAND static int LOCALE_TRADITIONAL_CHINESE_CHINA static int Methods None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 444 Cisco Unified JTAPI Extensions Methods

Related Documentation See Constant Field Values, on page 1667. CiscoMasterKeyIndicator This interface lists the constants for Master Key Indicator. Table 116: Interface History Description Cisco Unified Communications Manager Release Number New interface. 10.0(1) Declaration public interface CiscoMasterKeyIndicator Methods Table 117: Methods in CiscoMonitorInitiatorInfo Description Method Interface Indicates that MKI (Master Key Indicator) is not present. NOT_AVAILABLE static final int Indicates that MKI (Master Key Indicator) is present. AVAILABLE static final int CiscoMediaConnectionMode The CiscoMediaConnectionMode interface lists all of the media connection modes. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoMediaConnectionMode Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 445 Cisco Unified JTAPI Extensions Related Documentation

Fields Table 118: Fields in CiscoMediaConnectionMode Description Field Interface There is no active transmit or receive channel. NONE static int Only the receive channel is active. RECEIVE_ONLY static int Both the transmit and the receive channels are active. TRANSMIT_AND_RECEIVE static int Only the transmit channel is active. TRANSMIT_ONLY static int Methods None Related Documentation See Constant Field Values, on page 1667. CiscoMediaEncryptionAlgorithmType The CiscoMediaEncryptionAlgorithmType interface indicates the SRTP algorithm type used for encryption. This interface lists all of the security indicator values that an application can get in CiscoRTPInputKeyEv and CiscoRTPOutputKeyEv. If an application is terminating its own media on CTIPorts and Media Terminated RPs, only one of the following algorithms needs to be provided in the register API. Interface History Description Cisco Unified Communications Manager Release Added the extension. 3.x Superinterfaces public interface CiscoMediaEncryptionAlgorithmType Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 446 Cisco Unified JTAPI Extensions Fields

Fields Table 119: Fields in CiscoMediaEncryptionAlgorithmType Description Field Inteface The algorithm used is based on Advanced Encryption Standard (AES), which is a computer security standard. The cryptography scheme is a symmetric block cipher that encrypts and decrypts 128-bit blocks of data. AES_128_COUNTER staticint Related Documentation See Constant Field Values, on page 1667 for additional information. CiscoMediaEncryptionKeyInfo The CiscoMediaEncryptionKeyInfo interface lets applications get information about SRTP keys. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoMediaEncryptionKeyInfo Fields None Methods Table 120: Methods in CiscoMediaEncryptionKeyInfo Description Method Interface Returns the media encryption algorithm ID for the current stream. getAlgorithmID() int Indicates whether MKI is present. getIsMKIPresent() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 447 Cisco Unified JTAPI Extensions Fields

Description Method Interface Returns the master key for the stream. getKey() byte[] Returns the keyLength of the key. getKeyLength() int Returns the salt key for the stream. getSalt() byte[] Returns the saltLength of the salt. getSaltLength() int Indicates the SRTP key derivation rate for this session. keyDerivationRate() int Related Documentation See CiscoRTPInputKeyEv, CiscoRTPOutputKeyEv. CiscoMediaOpenIPPortEv CiscoMediaOpenIPPortEv event is delivered only if the terminal is registered with registration type as CiscoBaseTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT or CiscoBaseTerminal.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT. Interface History Description Cisco Unified Communications Manager Release Number New interface. 8.5(1) Sample Code public class MyTermObserver implements implements TerminalObserver, CallControlTerminalObserver, AgentTerminalObserver, PhoneTerminalObserver { public void termChangedEvent (TermEv[] evlist) { for(int i = 0; evlist ! = null && i < evlist.length; i++) { … … If ( evlisth[i] instanceof CiscoMediaOpenIPPortEv) { CiscoMediaOpenIPPortEv ev

(CiscoMediaOpenIPPortEv)evlist[i]; if(((CiscoBaseMediaTerminal)(ev.getTerminal()))).getRegistrationType

= CiscoTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT) { System.out.println("Set RTP parameters"); System.out.println("open the port"); } else { System.out.println("Open port"); } } Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 448 Cisco Unified JTAPI Extensions Related Documentation

} … … } Declaration public interface CiscoMediaOpenIPPortEv Superinterfaces NA Fields NA Inherited Fields NA Methods Table 121: Methods in CiscoMediaOpenIPPortEv Method Interface getMediaIPAddressingMode() int getCiscoRTPHandle() CiscoRTPHandle Inherited Methods NA CiscoMediaOpenLogicalChannelEv The system sends a CiscoMediaOpenLogicalChannelEv event each time that media gets established for a dynamically registered CiscoMediaTerminal or CiscoRouteTerminal. Upon receiving this event, applications must invoke setRTPParams on CiscoMediaTerminal or CiscoRouteTerminal and pass in the IP address and port number where they want to terminate the media, along with the rtpHandle that this event delivers. Applications can get a call reference by using CiscoProvider.getCall(CiscoRTPHandle). Applications must be aware that the far end and local end may not be able to invoke features unless the setRTPParams method is invoked. If applications fail to respond to this event within the specified time, the call may get disconnected. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 449 Cisco Unified JTAPI Extensions Declaration

Interface History Description Cisco Unified Communications Manager Release Number Added the getAddressingModeForMedia() method. 7.0(1) Added the isRTPRequired() method. 8.5(1) Sample Code public class MyTermObserver implements implements TerminalObserver, CallControlTerminalObserver, AgentTerminalObserver, PhoneTerminalObserver { public void termChangedEvent (TermEv[] evlist) { for(int i = 0; evlist ! = null && i < evlist.length; i++){ … … If ( evlisth[i] instanceof CiscoMediaOpenLogicalChannelEv) { CiscoMediaOpenLogicalChannelEv ev

(CiscoMediaOpenLogicalChannelEv)evlist[i]; if(ev.isRTPRequired()) { System.out.println("Set RTP parameters"); } else { System.out.println("Do not set RTP parameters"); } } } … … } Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoMediaOpenLogicalChannelEv extends CiscoTermEv Fields Table 122: Fields in CiscoMediaOpenLogicalChannelEv Field Interface ID staticint Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 450 Cisco Unified JTAPI Extensions Superinterfaces

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 123: Methods in CiscoMediaOpenLogicalChannelEv Description Method Interface Returns int Application and could get following value for required IP Addressing Mode: • CiscoTerminal.IP_ADDRESSING_IPv4—Means application needs to provide IPv4 format for the IP Address in setRTPParams request. • CiscoTerminal.IP_ADDRESSING_IPv6: Means application need to provide IPv6 format IP Address in set RTP Params request. getAddressingModeForMedia() int Returns CiscoRTPHandle object. Applications should pass this handle along with RTPParameters to CiscoMediaTerminal or CiscoRouteTerminal. Applications can get call reference using CiscoProvider.getCall If there is no callobserver or there was no callobserver when this event is delivered, then CiscoProvider.getCall may return null getCiscoRTPHandle() CiscoRTPHandle Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 451 Cisco Unified JTAPI Extensions Inherited Fields

Description Method Interface Returns a CiscoMediaConnectionMode. Applications could get one of the following values: • CiscoMediaConnectionMode.RECEIVE_ONLY— Means one-way media receive only. • CiscoMediaConnectionMode. TRANSMIT_AND_RECEIVE—Means two-way media. Applications should never see a value of NONE; however, if that happens, applications should ignore the event and log an error. getMediaConnectionMode() int Returns the packet size of the far end, in milliseconds. getPacketSize getPacketSize() int Returns the payload format of the far end, one of the following constants: • CiscoRTPPayload.NONSTANDARD • CiscoRTPPayload.G711ALAW64K • CiscoRTPPayload.G711ALAW56K • CiscoRTPPayload.G711ULAW64K • CiscoRTPPayload.G711ULAW56K • CiscoRTPPayload.G722_64K • CiscoRTPPayload.G722_56K • CiscoRTPPayload.G722_48K • CiscoRTPPayload.G7231 • CiscoRTPPayload.G728 • CiscoRTPPayload.G729 • CiscoRTPPayload.G729ANNEXA • CiscoRTPPayload.IS11172AUDIOCAP • CiscoRTPPayload.IS13818AUDIOCAP • CiscoRTPPayload.ACY_G729AASSN • CiscoRTPPayload.DATA64 • CiscoRTPPayload.DATA56 • CiscoRTPPayload.GSM • CiscoRTPPayload.ACTIVEVOICE getPayLoadType() int Indicates if the application must set the RTP parameters upon receiving this event. isRTPRequired() boolean Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 452 Cisco Unified JTAPI Extensions Inherited Methods

From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 and CiscoRTPParams CiscoMediaSecurityIndicator CiscoMediaSecurityIndicator gets sent in CiscoRTPInputKeyEv, CiscoRTPOutputKeyEv, and CiscoSnapShotRTPEv. It shows the call security status. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoMediaSecurityIndicator Fields Table 124: Fields in CiscoMediaSecurityIndicator Description Field Interface Terminates the media in secure mode, and keys are available. MEDIA_ENCRYPT_KEYS_AVAILABLE staticint Terminates the media in secure mode, but keys are not available because SRTP is not enabled in Cisco Unified Communications Manager Administration. MEDIA_ENCRYPT_KEYS_UNAVAILABLE staticint Terminates the media in secure mode, but keys are not available because the user is not authorized to get the keys. MEDIA_ENCRYPT_USER_NOT_AUTHORIZED staticint Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 453 Cisco Unified JTAPI Extensions Related Documentation

Description Field Interface The media is not encrypted for this call. MEDIA_NOT_ENCRYPTED staticint Related Documentation See Constant Field Values, on page 1667. CiscoMediaTerminal A CiscoMediaTerminal is a special kind of CiscoTerminal that allows applications to terminate RTP media streams. Unlike a CiscoTerminal, a CiscoMediaTerminal does not represent a physical telephony endpoint, which is observable and controllable in a third-party manner. Instead, a CiscoMediaTerminal is a logical telephony endpoint, which may be associated with any application that wants to terminate media. Such applications include voice messaging systems, interactive voice response (IVR), and softphones. Only CTIPorts appear as CiscoMediaTerminals through Cisco Unified JTAPI. Note Terminating media is a two-step process. To terminate media for a particular terminal, an application first adds an observer that implements the CiscoTerminalObserver interface using the Terminal.addObserver method. Finally, the application registers the IP address and port number to which incoming RTP streams for the terminal should be directed, by using the CiscoMediaTerminal.register method. To supply an IP address and port number dynamically on a per-call basis, applications must register by only providing the capabilities that they support. Applications must react to the CiscoMediaOpenLogicalChannelEv that gets sent whenever media gets established. Applications registering with this type must be aware that, when this event is received, the far end and the local end may not be able to perform any feature operation unless media is established. If applications fail to respond to this event within the specified time, the call may get dropped. Interface History Description Cisco Unified Communications Manager Release Number Support added for IPv6. 7.1x Superinterfaces CiscoObjectContainer, CiscoTerminal, javax.telephony.Terminal Declaration public interface CiscoMediaTerminal extends CiscoTerminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 454 Cisco Unified JTAPI Extensions Related Documentation

Fields None Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoTerminal ASCII_ENCODING, DEVICESTATE_ACTIVE, DEVICESTATE_ALERTING, DEVICESTATE_HELD, DEVICESTATE_IDLE, DEVICESTATE_UNKNOWN, DEVICESTATE_WHISPER, DND_OPTION_CALL_REJECT, DND_OPTION_NONE, DND_OPTION_RINGER_OFF, IN_SERVICE, IP_ADDRESSING_MODE_IPV4, IP_ADDRESSING_MODE_IPV4_V6, IP_ADDRESSING_MODE_IPV6, IP_ADDRESSING_MODE_UNKNOWN, IP_ADDRESSING_MODE_UNKNOWN_ANATRED, NOT_APPLICABLE, OUT_OF_SERVICE, UCS2UNICODE_ENCODING, UNKNOWN_ENCODING Methods Table 125: Methods in CiscoMediaTerminal Description Method Interface This method registers the MediaTerminal and returns successfully when the MediaTerminal is registered. The CiscoMediaTerminal must be in the CiscoTerminal.UNREGISTERED state and its Provider must be in the Provider.IN_SERVICE state. This method has three arguments: • The first argument specifies the internet address at which the RTP media stream for this Terminal will terminate. • The second indicates the UDP port at which RTP packets will be directed. • The final argument indicates the type of RTP encodings that the application is willing to support for this Terminal. Parameters • address—The internet address at which inbound IPv4 RTP streams on this terminal will terminate • port—The UDP port for inbound RTP streams on this terminal • capabilities—The list of the types of RTP encodings that the application supports for this terminal. Throws CiscoRegistrationException register(java.net.InetAddressaddress, intport, CiscoMediaCapability[]capabilities) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 455 Cisco Unified JTAPI Extensions Fields

Description Method Interface Deprecated Registers a Terminal with the specified address and port, defaulting to G.711 64 kHz u-law encoding with a thirty-millisecond packet size. Parameters • address—The internet address for inbound IPv4 RTP streams on this terminal • port—The UDP port for inbound RTP streams on this terminal Throws CiscoRegistrationException register(java.net.InetAddressaddress, intport) void This method registers the MediaTerminal. Ensure that the CiscoMediaTerminal is in the CiscoTerminal.UNREGISTERED state and its Provider is in the Provider.IN_SERVICE state. This method returns successfully when the MediaTerminal gets registered. This method requires that the application have a TLS link established with CTIManager and have the SRTP Enabled flag enabled in Cisco Unified Communications Manager Administration for the user; otherwise, the system throws a PrivilegeViolationException. Parameters • address—The internet address for inbound IPv4 RTP streams on this terminal • port—The UDP port for inbound RTP streams on this terminal • capabilities—The list of RTP encodings that this terminal supports • algorithmIDs—The SRTP algorithms that this CTIPort supports. AlgorithmIDs must be one of CiscoMediaEncryptionAlgorithmType. Throws CiscoRegistrationException javax.telephony.PrivilegeViolationException register(java.net.InetAddressaddress, intport, CiscoMediaCapability[]capabilities, int[]algorithmIDs) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 456 Cisco Unified JTAPI Extensions Methods

Description Method Interface register(java.net.InetAddressaddress, intport, CiscoMediaCapability[]capabilities, int[]algorithmIDs, java.net.InetAddressaddress_v6, intactiveAddressingMode) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 457 Cisco Unified JTAPI Extensions Methods

Description Method Interface The CiscoMediaTerminal must be in the CiscoTerminal.UNREGISTERED state and its Provider must be in the Provider.IN_SERVICE state. The successful effect of this method is to register the MediaTerminal. The activeAddressingMode indicates the application IP addressing capabilities. If application specifies activeAddressingMode as CiscoTerminal.IP_ADDRESSING_MODE_IPv4, then it must also specify address. If application specifies activeAddressingMode as CiscoTerminal.IP_ADDRESSING_MODE_IPv6, then it must also specify address_v6. If application specifies activeAddressingMode as CiscoTerminal.IP_ADDRESSING_MODE_IPv4_6, then it must also specify address and address_v6. Method Arguments This method has four arguments: • The first argument specifies the internet address at which the RTP media stream for this Terminal will be terminated. • The second indicates the UDP port at which RTP packets will be directed. • The third argument indicates the type of RTP encodings that the application is willing to support for this Terminal • The final argument indicates SRTP algorithm that application supports. This method can be used only if application has TLS link established with CTIManager and if application has SRTP Enabled flag enabled in CM Admin pages for the user, otherwise PrivilegeViolationException is thrown. Method Post-conditions This method returns successfully when the MediaTerminal is registered. Parameters • address—The internet address for inbound IPv4 RTP streams on this terminal, it can be null depending on application Addressing Mode. • port—The UDP port for inbound RTP streams on this terminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 458 Cisco Unified JTAPI Extensions Methods

Description Method Interface • capabilities—The list of RTP encodings supported by this terminal • algorithmIDs—Indicates SRTP algorithms that this CTIPort supports. AlgorithmIDs may only be one of CiscoMediaEncryptionAlgorithmType • address_v6—The IPv6 internet address for inbound IPv6 RTP streams on this terminal, it can be null depending upon activeAddressingMode • activeAddressingMode—IP Addressing mode in which application intends to register this CiscoMediaTerminal. It can be: CiscoTerminal.IP_ADDRESSING_MODE_IPv4 CiscoTerminal.IP_ADDRESSING_MODE_IPv6 CiscoTerminal.IP_ADDRESSING_MODE_IPv4z_v6 Since: 7.0 Throws CiscoRegistrationException, javax.telephony.PrivilegeViolationException Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 459 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method registers the MediaTerminal with the specified CiscoMediaCapabilities. Applications should use this method when they want to supply the IP address and port dynamically for each call. Applications that register with this method will receive a CiscoMediaOpenLogicalChannelEv for each call and must supply an IP address and port number by using the setRTPParams method on this object. Ensure the CiscoMediaTerminal is in the CiscoTerminal.UNREGISTERED state and its Provider is in the Provider.IN_SERVICE state. Method Arguments Arguments indicate the type of RTP encodings that the application is willing to support for this Terminal. Method Post-conditions This method returns successfully when the CiscoMediaTerminal is registered. Parameters capabilities—The list of RTP encodings that this terminal supports. Throws CiscoRegistrationException register(CiscoMediaCapability[]capabilities) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 460 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method registers a MediaTerminal with the specified CiscoMediaCapabilities and supported SRTP algorithms. Applications should use this method when they want to supply the IP address and port dynamically for each call and also want to specify the SRTP algorithm. Applications that register with this method will receive a CiscoMediaOpenLogicalChannelEv for each call and must supply the IP address and port number by using the setRTPParams method on this object. This form of register() also requires a second parameter that indicates which SRTP algorithm that the application supports. This method requires that the application have a TLS link established with CTIManager and have the SRTP Enabled flag enabled in Cisco Unified Communications Manager Administration for the user; otherwise, the system throws a PrivilegeViolationException. This method returns successfully when the CiscoMediaTerminal gets registered. Ensure the CiscoMediaTerminal is in the CiscoTerminal.UNREGISTERED state and its Provider is in the Provider.IN_SERVICE state. Parameters • capabilities—The list of RTP encodings that this terminal supports • algorithmIDs—The list of SRTP algorithms that this terminal supports. AlgorithmIDs must be one of CiscoMediaEncryptionAlgorithmType. Throws CiscoRegistrationException javax.telephony.PrivilegeViolationException register(CiscoMediaCapability[]capabilities, int[]algorithmIDs) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 461 Cisco Unified JTAPI Extensions Methods

Description Method Interface register(CiscoMediaCapability[]capabilities, int[]algorithmIDs, intactiveAddressingMode) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 462 Cisco Unified JTAPI Extensions Methods

Description Method Interface The CiscoMediaTerminal must be in the CiscoTerminal.UNREGISTERED state and its Provider must be in the Provider.IN_SERVICE state. The successful effect of this method is to register the MediaTerminal. It registers a Terminal with specified CiscoMediaCapabilities and supported SRTP algorithms. It also indicates that application is interested in supplying ipAddress and port dynamically for each call. Applications registering with this method receive CiscoMediaOpenLogicalChannelEv for each call and have to supply ipAddress and port number using setRTPParams method on this object. The second parameter indicates SRTP algorithm that application supports. This method can be used only if application has TLS link established with CTIManager and if application has SRTP Enabled flag enabled in Cisco Unified Communications Manager Administration for the user, otherwise PrivilegeViolationException is thrown. Method Arguments Arguments indicate the type of RTP encodings that the application is willing to support for this Terminal and the application or CTIManager failure persistence delay. Method Post-conditions This method returns successfully when the CiscoMediaTerminal is registered. Parameters • capabilities—The list of RTP encodings supported by this terminal • algorithmIDs—Indicates the list of SRTP algorithms supported by this terminal. AlgorithmIDs may only be one of CiscoMediaEncryptionAlgorithmType • activeAddressingMode—Is the IP Addressing mode in which application intends to register this CiscoMediaTerminal. The activeAddressingMode can be: CiscoTerminal.IP_ADDRESSING_MODE_IPv4 CiscoTerminal.IP_ADDRESSING_MODE_IPv6 CiscoTerminal.IP_ADDRESSING_MODE_IPv4_v6 Throws Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 463 Cisco Unified JTAPI Extensions Methods

Description Method Interface CiscoRegistrationException javax.telephony.PrivilegeViolationException Applications must use this method when they want to set the IP address and RTP port number to dynamically stream media for a call. In this situation, the application will have registered the MediaTerminal or CiscoRouteTeminal by providing only capabilities. Applications must invoke this method upon receiving the CiscoCallOpenLogicalChannel on terminalObserver. Applications must pass in the rtpHandle that they receive in CiscoCallOpenLogicalChannelEv. Applications can get a CiscoCall reference by calling the CiscoProvider.getRTPHandle(rtpHandle) method. This method may return null if no call observer is added on the terminal, or there was no callobserver at the time when this event got sent sent, or or there is no call associated with this handle. Parameters • rtpHandle—is obtained from. CiscoMediaCallOpenLogicalChannelEv • rtpParams—is of type CiscoRTPParams, which is used to specify the dynamic RTP address and port number for a media terminal on a per-call basis. Throws javax.telephony.InvalidStateException javax.telephony.InvalidArgumentException javax.telephony.PrivilegeViolationException setRTPParams(CiscoRTPHandlertpHandle, CiscoRTPParamsrtpParams) void This method unregisters the MediaTerminal and returns successfully when the MediaTerminal gets unregistered. The CiscoMediaTerminal must be registered and its Provider must be in the Provider.IN_SERVICE state. Throws CiscoUnregistrationException unregister() void This method returns true if the CiscoMediaTerminal is registered and false otherwise. For a MediaTerminal, this method returns true if the MediaTerminal is InService and false if it is OutOfService. For CTIManager failure cases, this method returns false. isRegistered() boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 464 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method returns true if this application issued a successful registration request. The registration remains valid even if the device is out-of-service because of a CTIManager failure. This will get set to true until this application unregisters the device. isRegisteredByThisApp() boolean An application can invoke this API to query the IP Addressing Mode of the CiscoMediaTerminal Addressing mode may be any of the following constants: • CiscoTerminal.IP_ADDRESSING_IPv4 • CiscoTerminal.IP_ADDRESSING_IPv6 • CiscoTerminal.IP_ADDRESSING_IPv4_v6 getIPAddressingMode() int Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoTerminal createSnapshot, getAltScript, getDeviceState, getDNDOption, getDNDStatus, getEMLoginUsername, getFilter, getLocale, getProtocol, getRegistrationState, getRTPInputProperties, getRTPOutputProperties, getState, getSupportedEncoding, isRestricted, sendData, sendData, setDNDStatus, setFilter, unPark From Interface javax.telephony.Terminal addCallObserver, addObserver, getAddresses, getCallObservers, getCapabilities, getName, getObservers, getProvider, getTerminalCapabilities, getTerminalConnections, removeCallObserver, removeObserver From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Related Documentation See CiscoTerminal and CiscoMediaOpenLogicalChannelEv.CiscoRTPParams CiscoMonitorInitiatorInfo This interface defines provides information about the monitor initiator. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 465 Cisco Unified JTAPI Extensions Inherited Methods

Declaration public interface CiscoMonitorInitiatorInfo Fields None Methods Table 126: Methods in CiscoMonitorInitiatorInfo Description Method Interface Returns the monitor initiator address. getAddress() CiscoAddress Returns the call leg hanlde at the monitor initiator. JTAPI gets the call at the monitor target by using provider.getCall(int monitorInitiatorCallLegHandle). This method returns null if the call at the monitor initiator is not active in this provider. getMonitorInitiatorCallLegHandle() Int Returns the terminal name of the monitor initiator. getTerminalName() java.lang.String Related Documentation None CiscoMonitorTargetInfo This interface provides information about the monitor target. Declaration public interface CiscoMonitorTargetInfo Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 466 Cisco Unified JTAPI Extensions Declaration

Methods Table 127: Methods in CiscoMonitorTargetInfo Description Method Interface Returns the monitor target address. getAddress() CiscoAddress Returns the call leg handle at the monitor target. getMonitorTargetCallLegHandle() Int Returns the terminal name of monitor target. getTerminalName() java.lang.String Related Documentation None CiscoMultiForkingRecorderInfo The CiscoMultiForkingRecorderInfo interface contains the information related to the recorders. Interface History Description Cisco Unified Communications Manager Release Number A new API which returns recorders details during Multi Forking Recording. CiscoMultiForkingRecorderInfo() New constants: CALL_RECORDING_MULTI_FORKING _RECORDER_TYPE_UNKNOWN CALL_RECORDING_MULTI_FORKING _RECORDER_TYPE_OPTIONAL_RECORDER CALL_RECORDING_MULTI_FORKING _RECORDER_TYPE_MANDATORY_RECORDER CALL_RECORDING_MULTI_FORKING_RECORDER_STATUS_UNKNOWN CALL_RECORDING_MULTI_FORKING_RECORDER_STATUS_SUCCESS CALL_RECORDING_MULTI_FORKING_RECORDER_STATUS_FAILURE 12.5(1) Declaration public interface CiscoMultiForkingRecorderInfo Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 467 Cisco Unified JTAPI Extensions Methods

Methods Methods in CiscoMultiForkingRecorderInfo Description Method Interface This interface returns URI of the MultiForking recorder. getRecorderURI() java.lang.String This interface returns the error message of the MultiForking recorder. getRecorderErrorMsg() java.lang.String This interface returns the integer which denotes the type of recorder. The recorder type can be: CALL_RECORDING_MULTI_FORKING _RECORDER_TYPE_UNKNOWN CALL_RECORDING_MULTI_FORKING _RECORDER_TYPE_OPTIONAL_RECORDER CALL_RECORDING_MULTI_FORKING _RECORDER_TYPE_MANDATORY_RECORDER getRecorderType() public int This interface returns the integer which denotes the status of the recorder. The recorder status can be: CALL_RECORDING_MULTI_FORKING _RECORDER_STATUS_UNKNOWN CALL_RECORDING_MULTI_FORKING _RECORDER_STATUS_SUCCESS CALL_RECORDING_MULTI_FORKING _RECORDER_STATUS_FAILURE get RecorderStatus() public int CiscoMultiMediaCapabilityInfo CiscoMultiMediaCapabilityInfo interface contains the multimedia capabilities of a terminal. Applications can get the video capability, telepresence interopability, and number of screens information of the terminal using this API. Declaration public interface CiscoMultiMediaCapabilityInfo com.cisco.jtapi.extensions.CiscoMultiMediaCapabilityInfo Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 468 Cisco Unified JTAPI Extensions Methods

Fields Table 128: Fields in CiscoMultiMediaCapabilityInfo Description Field Interface Indicates that the CiscoMultiMediaCapabilityInfo. getVideoCapability () for this terminal is CiscoMultiMediaCapabilityInfo.ENABLED. VIDEO_DISABLED static final int Indicates that the CiscoMultiMediaCapabilityInfo. getVideoCapability () for this terminal is CiscoMultiMediaCapabilityInfo.ENABLED. VIDEO_ENABLED static final int Indicates that the CiscoMultiMediaCapabilityInfo. getTelepresenceInfo() for this terminal is TELEPRESENCEINTEROP_NONE. TELEPRESENCEINTEROP_NONE static final int Indicates that the CiscoMultiMediaCapabilityInfo. getTelepresenceInfo () for this terminal is CiscoMultiMediaCapabilityInfo. TELEPRESENCEINTEROP_ENABLED. TELEPRESENCEINTEROP_ENABLED static final int This field will return -1 to indicate that the video capability and telepresence interopability is screen count is Unknown. UNKNOWN static final int Methods Table 129: Methods in MultiMediaCapabilityInfo Description Method Interface Returns the video capability of the Terminal. The video capability can be CiscoMultiMediaCapabilityInfo. DISABLED or CiscoMultiMediaCapabilityInfo. ENABLED. getVideoCapability() int Returns the telepresence interoperability of the Terminal. The telepresence interoperability can be CiscoMultiMediaCapabilityInfo. TELEPRESENCEINTEROP_DISABLED or CiscoMultiMediaCapabilityInfo. TELEPRESENCEINTEROP_ENABLED. getTelepresenceInfo() int Returns the number of screens present on the Terminal. getScreenCount() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 469 Cisco Unified JTAPI Extensions Fields

CiscoMultiMediaConnectionMode This interface specifies the connection mode associated with the multimedia stream. Table 130: Interface History Description Cisco Unified Communications Manager Release Number New interface. 10.0(1) Declaration public interface CiscoMultiMediaConnectionMode Methods Table 131: Methods in CiscoProvTerminalMultiMediaConnectionMode Description Field Interface Indicates that only the receive channel is active. RECEIVE_ONLY static final int Indicates that only the transmit channel is active. TRANSMIT_ONLY static final int CiscoMultiMediaEncryptionKeyInfo This interface contains the multi media streams encryption key information of a Terminal. Table 132: Interface History Description Cisco Unified Communications Manager Release Number New interface. 10.0(1) Declaration public interface CiscoMultiMediaEncryptionKeyInfo Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 470 Cisco Unified JTAPI Extensions CiscoMultiMediaConnectionMode

Methods Table 133: Methods in CiscoProvTerminalMultiMediaEncryptionKeyInfo Description Method Interface Returns the master key for the input stream. getRxKey() byte[] Returns the salt key for the input stream. getRxSalt() byte[] Returns the master key for the output stream. getTxKey() byte[] Returns the salt key for the output stream. getTxSalt() byte[] Returns the media encryption algorithm ID for the current stream. getAlgorithmID() int Indicates whether MKI is present for the input stream. getRxMKIPresent() int Indicates whether MKI is present for the output stream. getTxMKIPresent() int CiscoMultiMediaProperties This interface contains the multi media stream information of the video-capabilities on a Terminal. Table 134: Interface History Description Cisco Unified Communications Manager Release Number New interface. 10.0(1) Declaration public interface CiscoMultiMediaProperties Methods Table 135: Methods in CiscoProvTerminalMultiMediaProperties Description Method Interface Returns the rtp properties for the multimedia stream. CiscoRTPProperties CiscoRTPProperties Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 471 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns the connection mode for the multimedia stream. The multimedia connection mode can be: • CiscoMultiMediaConnectionMode. INACTIVE = 3 • CiscoMultiMediaConnectionMode. RECEIVE_ONLY = 1; • CiscoMultiMediaConnectionMode. TRANSMIT_ONLY = 2 • CiscoMultiMediaConnectionMode. TRANSMIT_AND_RECEIVE = 0 getMultiMediaConnection Mode() int Returns the multimedia type for the multimedia stream. The media type can be • CiscoMultiMediaType. INVALID = 0 • CiscoMultiMediaType. AUDIO = 1 • CiscoMultiMediaType. MAIN_VIDEO = 2 • CiscoMultiMediaType. PRESENTATION_VIDEO = 3 getMultiMediaType() int Returns whether key information is present for the multimedia stream. isKeyInfoPresent() boolean Returns the multimedia encryption data for the multimedia stream. getMultiMediaEncryption KeyInfo() CiscoMultiMediaEncryptionKeyInfo Indicates security indicator for the multimedia stream. The security indicator can be: • CiscoMasterKeyIndicator. NOT_AVAILABLE = 0 • CiscoMasterKeyIndicator. AVAILABLE = 1 getMultiMediaSecurity Indicator() int CiscoMultiMediaStreamsInfoEv CiscoMultiMediaStreamsInfoEv is a new interface that is being notified to applications as a Terminal Event. This interface will be delivered to terminal observers added by applications to indicate the multimedia streams information. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 472 Cisco Unified JTAPI Extensions CiscoMultiMediaStreamsInfoEv

Table 136: Interface History Description Cisco Unified Communications Manager Release Number New interface. 10.0(1) Declaration public interface CiscoMultiMediaStreamsInfoEv extends CiscoTermEv Methods Table 137: Methods in CiscoProvTerminalMultiMediaStreamsInfoEv Description Field Interface Returns an array of CiscoMultiMediaProperties, one for each stream. getProperties() CiscoMultiMediaProperties[] Returns CiscoCallID. getCallID() CiscoCallID CiscoMultiMediaType This interface specifies the multimedia type associated with the multimedia stream. Table 138: Interface History Description Cisco Unified Communications Manager Release Number New interface. 10.0(1) Declaration public interface CiscoMultiMediaType Methods Table 139: Methods in CiscoProvTerminalMultiMediaType Description Field Interface The multimedia stream type is unknown. INVALID static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 473 Cisco Unified JTAPI Extensions Declaration

Description Field Interface The multimedia stream contains audio information. AUDIO static final int The multimedia stream contains video information. MAIN_VIDEO static final int The multimedia stream contains presentation information. PRESENTATION_VIDEO static final int CiscoObjectContainer The ApplicationObject interface allows applications to associate an application-defined object to objects that implement this interface. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Subinterfaces CiscoAddress, CiscoCall, CiscoCallID, CiscoConnection, CiscoConnectionID, CiscoConsultCall, CiscoIntercomAddress, CiscoJtapiPeer, CiscoMediaTerminal, CiscoProvider, CiscoRouteTerminal, CiscoTerminal, CiscoTerminalConnection Declaration public interface CiscoObjectContainer Fields None Methods Table 140: Methods in CiscoObjectContainer Description Method Interface Gets the application-defined object. getObject() java.lang.Object Sets an application-defined object. setObject(java.lang.Objectreference) java.lang.Object Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 474 Cisco Unified JTAPI Extensions CiscoObjectContainer

Related Documentation None CiscoOutOfServiceEv The CiscoOutOfServiceEv event is the super class for the out-of-service events CiscoAddrOutOfServiceEv and CiscoTermOutOfServiceEv. This class defines the causes for out-of-service events. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, javax.telephony.events.Ev Subinterfaces CiscoAddrOutOfServiceEv, CiscoTermOutOfServiceEv Declaration public interface CiscoOutOfServiceEv extends CiscoEv Fields Table 141: Fields in CiscoOutOfServiceEv Description Field Interface The cause for this event is due a Cisco Unified Communications Manager failure. CAUSE_CALLMANAGER_FAILURE staticint The cause for this event is due to a failure from CTIManager. CAUSE_CTIMANAGER_FAILURE staticint The cause for this event is a device failure. CAUSE_DEVICE_FAILURE staticint The cause for this event is that the device is restricted. CAUSE_DEVICE_RESTRICTED staticint The cause for this event is that the device is in an unregistered state. CAUSE_DEVICE_UNREGISTERED staticint Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 475 Cisco Unified JTAPI Extensions Related Documentation

Description Field Interface The cause for this event is that the line is restricted. CAUSE_LINE_RESTRICTED staticint The cause for this event is the unavailability of any Cisco Unified Communications Manager. CAUSE_NOCALLMANAGER_AVAILABLE staticint The cause for this event is an to error in failback to a higher-priority Cisco Unified Communications Manager node. CAUSE_REHOME_TO_HIGHER_PRIORITY_CM staticint The cause for this event is a failure while attempting to rehome. CAUSE_REHOMING_FAILURE staticint — ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Methods None Related Documentation See Constant Field Values, on page 1667 CiscoPartyInfo This interface defines the party info of the call. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 476 Cisco Unified JTAPI Extensions Inherited Fields

Declaration public interface CiscoPartyInfo Fields Table 142: Fields in CiscoPartyInfo Description Field Interface This NumberType is same as 4; it represents caller is from same Cisco Unified Communications Manager server. ABBREVIATED_NUMBER Static int This NumberType is same as 0; it represents nothing is configured INTERNATIONAL_NUMBER Static int This NumberType is same as 1; it represents caller is INTERNATIONAL NATIONAL_NUMBER Static int This NumberType is same as 2; it represents caller is NATIONAL NET_SPECIFIC_NUMBER Static int This NumberType is same as 6; it represents its a fast dial call - not being used currently RESERVED_FOR_EXTENSION Static int This NumberType is same as 3; it represents call is from MGCP/H.323 gateway SUBSCRIBER_NUMBER Static int — UNKNOWN_NUMBER Static int Methods Table 143: Methods in CiscoPartyInfo Description Method Interface Returns the address. getAddress() javax.telephony.Address Returns Presentation Indicator (PI) associated with Address. If it returns true, Application can display this Address name to end users. If it returns false, Applications should not display this Address name to end user. getAddressPI() boolean Returns display name of the party. getDisplayName() java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 477 Cisco Unified JTAPI Extensions Declaration

Description Method Interface Returns the PI associated with DisplayName. If it returns true, Application can display this DisplayName to end users. If it returns false, Applications should not display this DisplayName to end user. getDisplayNamePI() boolean Returns the locale of the party unicode display name. getlocale() int Returns number type of the party. getNumberType() int Returns unicode display name of the party. getUnicodeDisplayName() java.lang.String Returns URL Info. getUrlInfo() CiscoUrlInfo Returns voice mail box of the party. getVoiceMailbox() java.lang.String Related Documentation See Constant Field Values, on page 1667. CiscoPickupGroup CiscoPickupGroup is a new interface that represents a Pickup Group at the JTAPI layer. Currently, all a PickupGroup is a pair of String objects representing the Pickup Group’s DN, and the Pickup Group’s Partition. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Following APIs are added: • getPickupGroupDN() • getPickupGroupPartition() 8.0(1) Declaration public interface CiscoPickupGroup Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 478 Cisco Unified JTAPI Extensions Related Documentation

Methods Table 144: Methods in CiscoPickup Group Description Method Interface Returns a String object that represents the number of the Pickup Group. getPickupGroupDN() String Returns a String object that represents the partition of the Pickup Group. It returns an empty String object if this pickup group does not belong to a partition. getPickupGroupPartition() String Related Documentation None CiscoProvCallParkEv CiscoProvCallParkEv event is delivered to providerobserver when a call is parked/unparked from any device in the cluster. To receive this event application should register using CiscoProvider.registerFeature() and CiscoProvFeatureID.MONITOR_CALLPARK_DN. User profile used by the application should have the Call Park Retrieval Allowed flag enabled to receive this event. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoProvEv, CiscoProvFeatureEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoProvCallParkEv extends CiscoProvFeatureEv Fields Table 145: Fields in CiscoProvCallParkEv Description Field Interface — ID Static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 479 Cisco Unified JTAPI Extensions Methods

Description Field Interface Indicates that a call is parked. PARK_STATE_ACTIVE Static int Indicates that a call is unparked. PARK_STATE_IDLE staticint Indicates that this event is due to call park. REASON_CALLPARK staticint Deprecated This interface is deprecated due to a spelling error. Use the new interface REASON_CALLPARKREMINDER. REASON_CALLPARKREMAINDER staticint Indicates that the call is offered back to the parking party after call park reminder. REASON_CALLPARKREMINDER staticint Indicates that the call is unparked. REASON_CALLUNPARK staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 146: Methods in CiscoProvCallParkEv Description Method Interface Returns an integer representation of this object. getintCallIDValue() int Returns where the call is parked. getParkDN() java.lang.String Returns the DN of the parked party. getParkedParty() java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 480 Cisco Unified JTAPI Extensions Inherited Fields

Description Method Interface Returns the partition of the Parked Party. getParkedPartyPartition() java.lang.String Returns the DN of the parking party. getParkingParty() java.lang.String Returns the partition of the Parking party. getParkingPartyPartition() java.lang.String Returns the partition of park DN. getParkPartyPartition() java.lang.String Returns the reason of the event. getReason() int Returns the state of the call. Possible states are CiscoProvCallParkEv.PARK_STATE_IDLE CiscoProvCallParkEv.PARK_STATE_ACTIVE. getState() int Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoProvFeatureEv getFeatureID From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoProvEv The CiscoProvEv interface, which extends JTAPI's core javax.telephony.events.ProvEv interface, serves as the base interface for all Cisco-extended JTAPI Provider events. Every Provider-related event in this package extends this interface, directly or indirectly. Interface History Description Cisco Unified Communications Manager Release Number Added new API getCiscoCause() which returns the CiscoCause for delivering the provider events. 8.0(1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 481 Cisco Unified JTAPI Extensions Inherited Methods

Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Subinterfaces CiscoAddrActivatedEv, CiscoAddrActivatedOnTerminalEv, CiscoAddrAddedToTerminalEv, CiscoAddrCreatedEv, CiscoAddrRemovedEv, CiscoAddrRemovedFromTerminalEv, CiscoAddrRestrictedEv, CiscoAddrRestrictedOnTerminalEv, CiscoProvCallParkEv, CiscoProvConnToLeastPriorCtiServerEv, CiscoProvFallbackToPrimNwCompltdEv, CiscoProvFeatureEv, CiscoProvPrimNwReachableEv, CiscoProvTerminalCapabilityChangedEv, CiscoRestrictedEv, CiscoTermActivatedEv, CiscoTermCreatedEv, CiscoTermRemovedEv, CiscoTermRestrictedEv, Declaration public interface CiscoProvEv extends CiscoEv, javax.telephony.events.ProvEv Fields None Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 482 Cisco Unified JTAPI Extensions Superinterfaces

Methods Description Method Interface This method returns the cause to let application know why the event has been delivered. getCiscoCause () int This indicates the cause for non - EM login/logout scenarios. It will have an integer value of 0. CiscoProvEv.CAUSE_NORMAL Static final int This cause indicates an EM login on a terminal with a profile that is in the application’s control list and/or with a user id that matches with the user id with which application has been started. It will have an integer value of 1. CiscoProvEv.CAUSE_EM_LOGIN Static final int This cause indicates an EM logout from a terminal with the profile that is in the application’s control list and/or with a user id that matches with the user id with which application has been started. It will have an integer value of 2. CiscoProvEv. CAUSE_EM_LOGOUT Static final int This cause indicates a case where profile is added to the control list when it is already logged into a terminal. It will have an integer value of 3. CiscoProvEv. CAUSE_EM_LOGIN_PROFILE_ADD Static final int This cause indicates a case where profile is removed from the control list when it is already logged into a terminal. It will have an integer value of 4. CiscoProvEv. CAUSE_EM_LOGIN_PROFILE_REMOVE Static final int Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent CiscoProvFeatureEv The CiscoProvFeatureEv interface extends the com.cisco.jtapi.extensions.CiscoProvEv interface for provider events. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 483 Cisco Unified JTAPI Extensions Methods

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Subinterfaces CiscoProvCallParkEv Declaration public interface CiscoProvFeatureEv extends CiscoProvEv Fields None Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 484 Cisco Unified JTAPI Extensions Superinterfaces

Methods Table 147: Methods in CiscoProvFeatureEv Description Method Interface The feature ID for which the application wants to receive events. getFeatureID() int Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See CiscoProvEv. ProvEv. CiscoProvFeatureID This interface lists the features that registerFeature supports. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Interface is enhanced to allow application register to get CiscoProvTerminalRegisteredEv and CiscoProvTerminalUnRegisteredEv events when terminal register and unregister respectively. CiscoProvTerminalRegisteredEv and CiscoProvTerminalUnRegisteredEv will be delivered to Provider observer when application registers for this feature 7.1(3) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 485 Cisco Unified JTAPI Extensions Methods

Declaration public interface CiscoProvFeatureID Fields Table 148: Fields in CiscoProvFeatureID Description Field Interface Used in the registerFeature interface in CiscoProvider to receive CiscoProvCallParkEv when a call gets parked or unparked from any device in the cluster. MONITOR_CALLPARK_DN static int Application can use to this to receive CiscoProvTerminalRegisteredEv and CiscoProvTerminalUnRegisteredEv TERMINAL_REGISTER_UNREGISTER_EVENT_NOTIFY public static final int Sample Code To register for Terminal Register and Unregister event notification: try{JtapiPeer peer

JtapiPeerFactory.getJtapiPeer ( null ); } catch (JtapiPeerUnavailableException e){ } MyProviderObserver providerObserver

new MyProviderObserver (); Try{ provider

peer.getProvider ( ipaddress;login = useid;passwd = password ); } catch (ProviderUnavailableException exp){ } if ( provider ! = null ) { provider.addObserver ( providerObserver ); provInService.waitTrue(); System.out.Println("Enabling Register and Unregister events "); try{ ((CiscoProvider)provider).registerFeature(CiscoProvFeatureID. TERMINAL_REGISTER_UNREGISTER_EVENT_NOTIFY); } catch (InvalidStateException ec){ } } // CiscoProvTerminalRegisteredEv and CiscoProvTerminalUnRegisteredEv are delivered to Provider Observer. class MyProviderObserver implements ProviderObserver { public synchronized void providerChangedEvent ( ProvEv [] eventList ) { Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 486 Cisco Unified JTAPI Extensions Declaration

try { if ( eventList ! = null ) { for ( int i

0; i < eventList.length; i++ ) { if ( eventList[i] instanceof CiscoProvTerminalRegisteredEv ){ CiscoProvTerminalRegisteredEv ev

(CiscoProvTerminalRegisteredEv) eventList[i]; System.out.Println( ev.getTerminal().getName() + " registered with CUCM" ); } } } catch (Exception eee){ } Methods None Related Documentation See Constant Field Values, on page 1667. CiscoProvPickupCallAlertEv CiscoProvPickupCallAlertEvent is a new interface being added with Call Pickup feature development. This event is fired whenever there is a call to be picked up in a pickup group that the provider is observing. See previous changes to CiscoProvider for information about how to register to observe a pickup group. Description Cisco Unified Communications Manager Release Number New interface. 8.0(1) Declaration public interface CiscoProvPickupCallAlertEvent extends CiscoProvEv Methods Table 149: Methods of CiscoProvPickupCallAlertEv Description Method Interface This method returns the Pickup Group Number for which this event is being fired. getPickupGroupNumber() String This method returns the Pickup Group Number for which this event is being fired. getPickupGroupPartition() String This method returns the Call ID for the ringing call. getCallID() CiscoCallID Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 487 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method returns a CiscoPartyInfo representing the calling party.CAVEAT: Currently, if the calling party is from out of cluster (External), it will still report as being Internal on the Address object inside of the CiscoPartyInfo. getCallingPartyInfo() CiscoPartyInfo This method returns a CiscoPartyInfo representing the called party. getCalledPartyInfo() CiscoPartyInfo CiscoProvTerminalIPAddressChangedEv This interface will be delivered to provider observers added by applications whenever the IP address of a terminal changes without the terminal getting unregistered. Interface History Description Cisco Unified Communications Manager Release Number New interface. 9.0(1) Declaration public interface CiscoProvTerminalIPAddressChangedEv extends CiscoProvEv Fields Table 150: Fields in CiscoProvTerminalIPAddressChangedEv Description Field Interface Returns the Terminal that registered with Cisco Unified Communication Manager. getTerminal() public Terminal Returns the active IP Addressing mode of the terminal after the change. Based on this value, applications can query either the Ipv4 or the Ipv6 address of the terminal. Addressing mode may be any of the following constants: CiscoTerminal.IP_ADDRESSING_MODE_IPv4 CiscoTerminal.IP_ADDRESSING_MODE_IPv6 CiscoTerminal.IP_ADDRESSING_MODE_IPv4_v6 getIPAddressingMode() public int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 488 Cisco Unified JTAPI Extensions CiscoProvTerminalIPAddressChangedEv

Description Field Interface Returns the IPv4 address of the terminal. If the addressing mode is CiscoTerminal.IP_ADDRESSING_MODE_IPv6, this method will return null. getIPV4Address() public InetAddress Returns the IPv6 address of the terminal. If the addressing mode is CiscoTerminal.IP_ADDRESSING_MODE_IPv4, this method will return null. getIPV6Address() public InetAddress Methods None Related Documentation None CiscoProvTerminalMultiMediaCapabilityChangedEv CiscoProvTerminalMultiMediaCapabilityChangedEv is a new interface that is notified to application as a Provider Event. when the video capability of the terminal changes, this interface is delivered to the provider observers added by applications. Table 151: Interface History Description Cisco Unified Communications Manager Release Number New interface. 10.0(1) Declaration public interface CiscoProvTerminalMultiMediaCapabilityChangedEv com.cisco.jtapi.extensions.CiscoProvTerminalMultiMediaCapabilityChangedEv Methods Table 152: Methods in CiscoProvTerminalMultiMediaCapabilityChangedEv Description Method Interface This API returns the Terminal that is registered with Cisco UCM. getTerminal() Terminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 489 Cisco Unified JTAPI Extensions Methods

Description Method Interface This returns the video capability of the Terminal. The video capability can be: • CiscoMultiMediaCapabilityInfo.NONE • CiscoMultiMediaCapabilityInfo.VIDEO_ENABLED getVideoCapability() int CiscoProvTerminalRegisteredEv This event is delivered to provider observer whenever a terminal registers with Cisco Unified Communication Manager. To receive this event, the application must use registerFeature API with CiscoFeatureID. TERMINAL_REGISTER_UNREGISTER_EVENT_NOTIFY. This event is delivered if a Terminal registers to Cisco Unified Communication Manager after the application registers for the feature using registerFeature API. During initialization time and JTAPI failover time the application can see this event for some the Terminals in the control list. Interface History Description Cisco Unified Communications Manager Release Number New interface. 7.1(3) Declaration public interface CiscoProvTerminalRegisteredEv extends CiscoProvEv. Fields Table 153: Fields in CiscoProvTerminalRegisteredEv Description Field Interface Returns the terminal that registered with Cisco Unified Communications Manager. getTerminal() Terminal Methods None Related Documentation None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 490 Cisco Unified JTAPI Extensions CiscoProvTerminalRegisteredEv

CiscoProvTerminalUnRegisteredEv This event is delivered to provider observer when ever a terminal unregisters from Cisco Unified Communication Manager. To receive this event, the application must use the registerFeature API with CiscoFeatureID. TERMINAL_REGISTER_UNREGISTER_EVENT_NOTIFY. Interface History Description Cisco Unified Communications Manager Release Number New interface. 7.1(3) Declaration public interface CiscoProvTerminalUnRegisteredEv extends CiscoProvEv. Fields Table 154: Fields in CiscoProvTerminalRegisteredEv Description Field Interface Returns the terminal that un-registered with Cisco Unified Communications Manager. getTerminal() Terminal • Indicates Terminal un-registered for unknown reason • Indicates Terminal un-registered due to rest • Indicates Terminal un-registered due to login • Indicates Terminal un-registered due to logout • REASON_UNKNOWN • REASON_RESET • REASON_LOGIN • REASON_LOGOUT public final static int public final static int public final static int public final static int Returns the reason of un-register. The return value is one of the above defined reasons. getReason() Int Methods None Related Documentation None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 491 Cisco Unified JTAPI Extensions CiscoProvTerminalUnRegisteredEv

CiscoProvider The CiscoProvider interface extends the Provider interface with additional Cisco capabilities. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Enhanced to have the following: • New API registerPickupAlert(String pickupDn, String pickupPartition) • unregisterPickupAlert(String pickupDn, String pickupPartition) which allow the application to register and unregister for the reception of Call Pickup events. • CiscoProvPickupCallAlertEvent, which is a provider event what the application receives when they register for events using the previously mentioned API • ProviderCallPickupRegistrationClosedEv, which is a provider event used to alert the application if something happens that would close the registration event, such as the pickup group being removed from the Unified CM admin panel. 8.0(1) A new method is added: getClusterID() this returns the clusterID enterprise parameter configured for the cluster as a string. 10.0(1) Enhanced to have the following: • New APIs setLeastPriorityCtiServer(String leastPriorityCtiServer) • setLeastPriorityCtiServer(String leastPriorityCtiServer, int fallbackInitiationTime) • getLeastPriorityCtiServer() • isCtiServerAvailable(String server) • initiateFallback() • initiateFallback(String server) 14SU3 Superinterfaces CiscoObjectContainer, javax.telephony.Provider. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 492 Cisco Unified JTAPI Extensions CiscoProvider

Declaration public interface CiscoProvider extends javax.telephony.Provider, CiscoObjectContainer Fields None Inherited Fields From Interface javax.telephony.Provider IN_SERVICE, OUT_OF_SERVICE, SHUTDOWN New Error Codes CTIERR_ALREADY_REGISTERED This error code indicates that the Pickup Group attempting to be registerred for has already been registerred by this provider. CTIERR_REGISTRATION_NOT_FOUND This error code indicates that an unregister attempt failed because the Pickup Group specified was not registerred for previously. CTIERR_INVALID_PICKUPGROUP This error code indicates that the Pickup Group specified in the register or unregister event is not valid. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 493 Cisco Unified JTAPI Extensions Declaration

Methods Table 155: Methods in CiscoProvider Description Method Interface Returns an instance of the CiscoTerminal class which corresponds to the given name. Application must have sufficient capability otherwise PrivilegeViolationException gets thrown CiscoProvider.createTerminal(). Pre-conditions this.getState() = = Provider.IN_SERVICE Post-conditions Create CiscoTerminal corresponding to name; terminal is an element of this.getTerminals(). Parameters • name—The name of desired CiscoTerminal object. Throws javax.telephony.InvalidArgumentException—The name provided does not correspond to a name of any CiscoMediaTerminal known to the Provider or within the Provider's domain. javax.telephony.InvalidStateException—The provider is not inService. PreviledgeVoilationException—The provider does not have sufficient capbilitly i.e. CiscoProviderCapabilities.canObserveAnyTerminal() returns false call.getState() = = Call.INVALID createTerminal (java.lang.Stringname) CiscoTerminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 494 Cisco Unified JTAPI Extensions Methods

Description Method Interface Removes the CiscoTerminal Object from providers control. Application must have created this terminal using Provider.createTerminal() interface otherwise PreviledgeVoilationException gets thrown. CiscoProvider.deleteTerminal(). Pre-conditions this.getState() = = Provider.IN_SERVICE Post-conditions CiscoTerminal Object deleted from providers list of terminal. Terminal is not element of this.getTerminals() any more and Addresses belonging to terminal get deleted. Parameters • terminal—The referece to the desired CiscoTerminal object to be deleted. Throws javax.telephony.InvalidArgumentException—The terminal provided is not element of this.getTerminals() or terminal is not provider domain. PrivilegeViolationException—The terminal given in the argument is not a terminal created using Provider.createTerminal() method. Applications can delete only those terminal which are created using Provider.createTerminal() interface. deleteTerminal (CiscoTerminalterminal) void Returns an address object corresponding to the number and partition that is passed in the method. The address object will be unique for a particular number, partition combination. Throws javax.telephony.InvalidArgumentException getAddress (java.lang.Stringnumber, java.lang.Stringpartition) javax.telephony.Address Gets the DSCP value from the provider by using CiscoProvider.getAppDSCPValue(). Pre-conditions this.getState() = = Provider.IN_SERVICE Post-conditions The method will return the integer value of the DSCP value for applications set by CTI. getAppDSCPValue () int Returns call object with the RTPHandle associated with a specific terminal. getCall (CiscoRTPHandlertpHandle) CiscoCall Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 495 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns CiscoCall present in provider domain and the call object with the RTPHandle associated with a specific terminal. This method may return null if this RTPHandle is no longer associated with any call or if there was no callObserver added on the terminal at the time when CiscoCallOpenLogicalChannelEv which contained this handle is sent to applications. Throws javax.telephony.InvalidStateException getCall (intcallleg) CiscoCall None getCallbackGuardEnabled () boolean Returns true if JTAPI is running in FIPS Compliance mode. This means that the application has explicitly requested FIPS compliance, and that the libraries are running properly. isFIPSCompliantJTAPI () boolean Returns true if the Unified CM server is running in FIPS Compliance mode. isFIPSCompliantCUCM () boolean Returns array of CiscoInterComAddress present in provider domain. getIntercomAddresses () CiscoIntercomAddress[] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 496 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns an instance of the CiscoMediaTerminal class which corresponds to the given name. Each CiscoMediaTerminal has a unique name associated with it, which is assigned to it by the JTAPI implementation. If no CiscoMediaTerminal is available for the given name within the Provider domain, this method throws the InvalidArgumentException. This CiscoMediaTerminal is contained in the arrays generated by Provider.getTerminals() and CiscoProvider.getMediaTerminals(). Pre-conditions Let CiscoMediaTerminal terminal = this.getMediaTerminal(name); terminal is an element of this.getTerminals(); terminal is an element of this.getMediaTerminals(); Post-conditions Let CiscoMediaTerminal terminal = this.getMediaTerminal(name); terminal is an element of this.getTerminals(); terminal is an element of this.getMediaTerminals(); Parameters • name—The name of desired CiscoMediaTerminal object. Throws javax.telephony.InvalidArgumentException—The name provided does not correspond to a name of any CiscoMediaTerminal known to the Provider or within the Provider domain. getMediaTerminal (java.lang.Stringname) CiscoMediaTerminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 497 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns an array of CiscoMediaTerminals associated with the Provider and within the Provider local domain. Each CiscoMediaTerminal possesses a unique name, which is assigned to it by the JTAPI implementation. If there are no CiscoMediaTerminals associated with this Provider, then this method returns null. This array is a subset of the array returned by Provider.getTerminals(). Post-conditions Let CiscoMediaTerminal[] terminals = this.getMediaTerminals() terminals = = null or terminals.length > = 1 if terminals ! = null, terminals is a subset of this.getTerminals () Throws javax.telephony.ResourceUnavailableException—Indicates the number of media terminals present in the Provider is too great to return as a static array. getMediaTerminals () CiscoMediaTerminal[] This method returns an array of CiscoPickupGroup objects that represents all of the Pickup Groups that this provider is currently registerred to observe. Parameters A String object that represents the number of the Pickup Group to be registerred for, and another String object that represents the partition that the Call Pickup Group is in. getRegisteredPickupGroups () CiscoPickupGroup[] None getVersion () java.lang.String Registers a particular feature for which application gets Provider events. Applications should pass in the featureID of the softkey. Current supported features are listed in CiscoProvFeatureID interface. Throws javax.telephony.InvalidStateException javax.telephony.PrivilegeViolationException javax.telephony.InvalidArgumentException registerFeature (intfeatureID) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 498 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method tells the Provider to register for receiving Call Pickup events. After this method is called, Call Pickup events for the specified Call Pickup Group will be sent to all JTAPI observers under this provider. Parameters • A String object that represents the number of the Pickup Group to be registerred for, and another String object that represents the partition that the Call Pickup Group is in. • The pickupPartition can be passed in as an empty String (“”) or null if the pickup group does is not in any partition. • An application can use the new CiscoPickupGroup object in place of the pair of Strings for either method. registerPickupAlert (String pickupDN, String pickupPartition) void This method tells the Provider to register for receiving Call Pickup events. After this is called, Call Pickup events for the specified Call Pickup Group will be sent to all JTAPI observers under this provider. Parameters • A String object that represents the number of the Pickup Group to be registerred for, and another String object that represents the partition that the Call Pickup Group is in. • The pickupPartition can be passed in as an empty String (“”) or null if the pickup group does is not in any partition. • An application can use the new CiscoPickupGroup object in place of the pair of Strings for either method. registerPickupAlert (CiscoPickupGroup pickupGroup) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 499 Cisco Unified JTAPI Extensions Methods

Description Method Interface Enables or disables try/catch logic for observer callbacks. In order to protect itself from application exceptions in observer callbacks, the Provider normally guards all invocations of application interfaces (e.g. observers) with the following code: try {observer.callStateChanged ( ... ); } catch ( Throwable t ) { // log the exception here } This isolates application errors from the JTAPI implementation, allowing easier troubleshooting, since the JTAPI implementation can note the unhandled exception and continue operating. Some errors are considered non-recoverable and will be re-thrown by JTAPI, generally resulting in application exit. Such errors include ThreadDeath, OutOfMemoryError, and StackOverflowError. Applications wishing to trap errors within JTAPI threads should create a subclass of ThreadGroup and initialize JTAPI from a thread within that ThreadGroup. By overriding the ThreadGroup.uncaughtException () method, the application can be made aware of all unrecoverable errors thrown on JTAPI threads. In some cases, JTAPI's aggressive error-catching approach may make it more difficult to troubleshoot applications within a java debugger. Microsoft Visual J++ version 6.0, for example, does not handle breakpoints within application observer callbacks properly if JTAPI catches Throwable. In such cases, JTAPI application developers may choose to disable the internal JTAPI try/catch logic. Note Disabling callback guards in this manner is only intended for use while troubleshooting applications, and never for use in production environments. By default, callback guards are always enabled. Parameters • enabled—if true, callback guard will be enabled; if false, callback guard will be disabled. setCallbackGuardEnabled (booleanenabled) Void Unregisters a particular feature. unregisterFeature (intfeatureID) Void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 500 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method will tell the Provider to unregister for receiving Call Pickup events. After this is called, Call Pickup events for the specified Call Pickup Group will no longer be sent to all JTAPI observers under this provider. Parameters • A String object that represents the number of the Pickup Group to be registerred for, and another String object that represents the partition that the Call Pickup Group is in. • The pickupPartition can be passed in as an empty String (“”) or null if the pickup group does is not in any partition. • An application can use the new CiscoPickupGroup object in place of the pair of Strings for either method. unregisterPickupAlert (String pickupDN, String pickupPartition) Void This method will tell the Provider to unregister for receiving Call Pickup events. After this is called, Call Pickup events for the specified Call Pickup Group will no longer be sent to all JTAPI observers under this provider. Parameters • A String object that represents the number of the Pickup Group to be registerred for, and another String object that represents the partition that the Call Pickup Group is in. • The pickupPartition can be passed in as an empty String (“”) or null if the pickup group does is not in any partition. • An application can use the new CiscoPickupGroup object in place of the pair of Strings for either method. unregisterPickupAlert (CiscoPickupGroup pickupGroup) Void This method returns an array of CiscoRemoteTerminal associated with the Provider and within the Provider's domain. Each CiscoRemoteTerminal possesses an unique name, which is assigned to it by the JTAPI implementation. If there is no CiscoRemoteTerminals associated with this Provider, this API will return null. This array is a subset of the array returned by Provider.getTerminals(). getRemoteTerminals () CiscoRemoteTerminal[] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 501 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method returns an instance of the CiscoRemoteTerminal class which corresponds to the given name. Each CiscoRemoteTerminal has an unique name associated to it, which is assigned by the JTAPI implementation. If no CiscoRemoteTerminal is available for the given name within the Provider's domain, this API throws the InvalidArgumentException. This CiscoRemoteTerminal is contained in the arrays generated by Provider.getTerminals() and CiscoProvider.getRemoteTerminals(). getRemoteTerminal (String name) CiscoRemoteTerminal This method returns the clusterID enterprise parameter configured for the cluster as a string. If this enterprise parameter is changed CTIManager service and other Cisco Communication Manager services need to be restarted. Pre-conditions Provider.getState() = = Provider.IN_SERVICE If pre-condition is not met, InvalidStateException is thrown. Default value is StandAloneCluster. getClusterID () String This method allows application to mark a CTI server as least priority. Least Priority indicates, JTAPI would connect to the CTI server only in the case when no other CTI Server configured by application is reachable. JTAPI would also initiate a forceful fallback once one of the CTI servers are reachable again (600 seconds post this event). Basically, all other CTI servers configured and not marked as least priority have equal weightage. Application can only configure one CTI server as least priority. setLeastPriorityCtiServer(String leastPriorityCtiServer) Void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 502 Cisco Unified JTAPI Extensions Methods

Description Method Interface This API allows application to mark a CTI server as least priority. Least Priority indicates, JTAPI would connect to the CTI server only in the case when no other CTI Server configured by application is reachable. JTAPI would also initiate a forceful fallback once one of the CTI servers arereachable again. Basically, all other CTI servers configured and not marked as least priority have equal weightage. Application can only configure one CTI server as least priority. This method is overloaded to take additional parameter to specify time (in seconds) after which a forceful fallback is to be initiated once primary network becomes reachable. Fallback initiation time is defined as below: • Default value : 300 seconds • Min value : 120 seconds • Max value: 600 seconds • Default value would be taken if specified value is out of the range. setLeastPriorityCtiServer(String leastPriorityCtiServer, int fallbackInitiationTime) void This API returns the least priority CTI server as configured by application by invoking <CODE>CiscoProvider.setLeastPriorityCtiServer((server)</CODE>. getLeastPriorityCtiServer() String This API allows application to query if one of the configured CTI servers is reachable. isCtiServerAvailable(String server) boolean This API allows application to invoke a fallback when connected to CTI server which was previously identified as least priority by invoking <CODE>CiscoProvider.setLeastPriorityCtiServer(server)</CODE>. Application can invoke this in case one of the primary network CTI Server becomes available and application is ready to do a fallback before the configured/default fallback timer expires. initiateFallback() void This API allows application to invoke a fallback when connected to CTI server which was previously identifie as least priority by invoking <CODE>CiscoProvider.setLeastPriorityCtiServer(server)</CODE>. Application can invoke this in case one of the primary network CTI Server becomes available and application is ready to do a fallback before the configured/default fallback timer expires. This method is overloaded to take additional parameter to specify the server to which application needs to fallback to. initiateFallback(String server) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 503 Cisco Unified JTAPI Extensions Methods

Inherited Methods From Interface javax.telephony.Provider addObserver, createCall, getAddress, getAddressCapabilities, getAddressCapabilities, getAddresses, getCallCapabilities, getCallCapabilities, getCalls, getCapabilities, getConnectionCapabilities, getConnectionCapabilities, getName, getObservers, getProviderCapabilities, getProviderCapabilities, getState, getTerminal, getTerminalCapabilities, getTerminalCapabilities, getTerminalConnectionCapabilities, getTerminalConnectionCapabilities, getTerminals, removeObserver, shutdown From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Related Documentation None CiscoProviderCapabilities This interface defines the Cisco-specific provider capabilities that Cisco Unified JTAPI offers. Interface History Description Cisco Unified Communications Manager Release Number Added support for the method canSupportIPv6()T. 7.1(1 and 2) Enhanced by adding new API canAutoPickup(), which lets the application determine whether or not the CUCM service parameter “Auto Call Pickup Enabled” is set to true or false. This service parameter has an impact on the events and behavior of Call Pickup, and applications can use this new API to determine if it’s enabled or not, and act accordingly. 8.0(1) Superinterfaces javax.telephony.capabilities.ProviderCapabilities Declaration public interface CiscoProviderCapabilities extends javax.telephony.capabilities.ProviderCapabilities Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 504 Cisco Unified JTAPI Extensions Inherited Methods

Methods Table 156: Methods in CiscoProviderCapabilities Description Method Interface This method returns a boolean value representing whether or CUCM service parameter “Auto Call Pickup Enabled” is set ot true or false. canAutoPickup() boolean This method checks whether the user has been provisioned in the Cisco Unified Communications Manager with the privilege to observe any Terminal (and its addresses) in the system. Such Terminals and Addresses do not get returned as part of the list that JTAPI initializes at startup. The provider obtained with the login for a user with such privileges can be determined from the canObserverAnyTerminal method call in ProviderCapabilities. Returns True if the user can observe any Terminal in the system, or false if the user can only observe Terminals and Addresses in the control list. canObserveAnyTerminal() boolean Example Provider p

peer.getProvider( loginString ); ProviderCapabilities caps

p.getCapabilities (); if ( caps instanceof CiscoProviderCapabilities ) { boolean canObserveAnyTerminal

((CiscoProviderCapabilities)caps).canObserveAnyTerminal (); boolean canMonitorParkDN

((CiscoProviderCapabilities)caps).canMonitorParkDNs (); boolean canModifyCallingPN

((CiscoProviderCapabilities)caps).canModifyCallingParty (); boolean canRecordCalls

((CiscoProviderCapabilities)caps).canRecord(); boolean canMonitorCalls

((CiscoProviderCapabilities)caps).canMonitor(); } This method checks whether the user has been provisioned in the Cisco Unified Communications Manager to monitor park DNs. Returns True if the user can monitor park DNs, or false otherwise. canMonitorParkDNs() boolean This method checks whether the user has been provisioned in the Cisco Unified Communications Manager to modify the calling party number of a call. Returns True if the user can modify the calling party number, or false otherwise. canModifyCallingParty() boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 505 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method checks whether the user has been provisioned in the Cisco Unified Communications Manager to record calls. Only users in 'Standard CTI Allow Call Recording' user group can record calls. Returns True if the user belongs to the group. canRecord() boolean This method checks whether a user has been provisioned in the Cisco Unified Communications Manager to monitor calls. Only users in 'Standard CTI Allow Call Monitoring' user group can initiate call monitoring request. Returns True if the user belongs to the group. canMonitor() boolean This interface returns true if Enterprise Parameter “Enable IPv6” is enabled and false otherwise. canSupportIPv6() boolean Inherited Methods From Interface javax.telephony.capabilities.ProviderCapabilities isObservable Related Documentation See canObserveAnyTerminal(). CiscoProviderCapabilityChangedEv Application provider observers receive this event when a user gets added or removed from user groups (capabilitied) in Cisco Unified Communications Manager. The methods for this event let you check which capabilities changed. Interface History Description Cisco Unified Communications Manager Release Number Added hasIPv6CapabilityChanged() method. 7.1(1 and 2) Declaration public interface CiscoProviderCapabilityChangedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 506 Cisco Unified JTAPI Extensions Inherited Methods

Fields Table 157: Fields in CiscoProviderCapabilityChangedEv Description Field Interface None ID staticint Deprecated This constant is not returned by any interface, should not be used by application. MODIFY_CGPN staticint Deprecated This constant is not returned by any interface, should not be used by application. MONITOR_PARKDN staticint Deprecated This constant is not returned by any interface, should not be used by application. SUPERPROVIDER staticint Methods Table 158: Methods in CiscoProviderCapabilityChangedEv Description Method Interface This method returns the current CiscoProviderCapabilities object for the user. getCapability() CiscoProviderCapabilities This method can be used by applications to determine whether Enable IPv6 Enterprise Parameter has changed. Pre-conditions this.getState() = = Provider.IN_SERVICE Post-conditions The method returns True when the Enable IPv6 Enterprise parameter gets changed; otherwise it returns False. hasIPv6CapabilityChanged() boolean This method checks whether the “modify Calling Party" privilege has changed. Pre-conditions provider.getState() = = Provider.IN_SERVICE hasModifyCallingPartyChanged() boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 507 Cisco Unified JTAPI Extensions Fields

Description Method Interface This method checks whether the monitor capability of a user has changed. Pre-conditions provider.getState() = = Provider.IN_SERVICE hasMonitorCapabilityChanged() boolean This method checks whether the "monitor Park DN" privilege has changed. Pre-conditions provider.getState() = = Provider.IN_SERVICE hasMonitorParkDNChanged() boolean This method checks whether the "can control any terminal" privilege has changed Pre-conditions provider.getState() = = Provider.IN_SERVICE hasObserveAnyTerminalChanged() boolean This method checks whether the recording capability of the has changed. Pre-conditions provider.getState() = = Provider.IN_SERVICE hasRecordingCapabilityChanged() boolean Related Documentation See Constant Field Values, on page 1667. CiscoProviderObserver Implement this interface to receive CiscoProvEv events such as CiscoAddrCreatedEv and CiscoTermCreatedEv when observing a Provider via the Provider.addObserver method. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.ProviderObserver Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 508 Cisco Unified JTAPI Extensions Related Documentation

Declaration public interface CiscoProviderObserver extends javax.telephony.ProviderObserver Methods None Inherited Methods From Interface javax.telephony.ProviderObserver providerChangedEvent Related Documentation See CiscoAddrCreatedEv and CiscoTermCreatedEv. CiscoProvTerminalCapabilityChangedEv This event is delivered to the Provider when Terminal Capability is changed. This event is provided on application observer . Interface History Description Cisco Unified Communications Manager Release Number Added event. 7.0(1) Modified the CiscoTerminal[] interface so that only CiscoMediaTerminals or CiscoRouteTerminals gets returned. 7.0(1) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoProvTerminalCapabilityChangedEv extends CiscoProvEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 509 Cisco Unified JTAPI Extensions Declaration

Fields Table 159: Fields in CiscoProvTerminalCapabilityChangedEv Description Field Interface None ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 160: Methods in CiscoProvTerminalCapabilityChangedEv Description Method Interface Returns an array of CiscoTerminals whose capabilities have changed. In Cisco Unified Communications Manager Release 7.0(1), CiscoTerminal[] interface was modified so that only CiscoMediaTerminals or CiscoRouteTerminals get returned. getTerminals() CiscoTerminal[] Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 510 Cisco Unified JTAPI Extensions Fields

From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation None CiscoProvTerminalRemoteDestinationChangedEv CiscoProvTerminalRemoteDestinationChangedEv is a new interface exposed to the applications as a Provider Event. JTAPI sends this event to the application's provider observer when any of Remote Destination information is changed on a CiscoRemoteTerminal in the provider domain. This event contains the latest list of Remote Destinations at a given time. And depending on the request or operation done on these remote destinations, single or multiple CiscoProvTerminalRemoteDestinationChangedEv event(s) can be generated from the change notification(s). Methods Description Method Interface This method returns the CiscoRemoteTerminal object for which its remote destination has changed. getTerminal() CiscoRemoteTerminal This method returns an array of CiscoRemoteDestinationInfo objects representing the latest/current list of remote destinations associated to the CiscoRemoteTerminal at the time when this change notification event took place. getRemoteDestinations() CiscoRemoteDestinationInfo[] This method can be used by application to determine whether it is the last application to set active remote destination for the CiscoRemoteTerminal. isMyAppLastToSetActiveRD() boolean CiscoRecorderInfo This interface provides information about the recorder in a recording session. When a recording session is active, this interface gives information about the recording device. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 511 Cisco Unified JTAPI Extensions Related Documentation

Interface History Description Cisco Unified Communications Manager Release Number A new method getMultiForkingRecorderInfo() is added which returns an array (maximum size 5) of CiscoMultiForkingRecorderInfo[]. The following are the four new methods inside getMultiForkingRecorderInfo() that provide the information about each recorder. • getRecorderURI() • getRecorderErrorMsg() • getRecorderType() • getRecorderStatus() 12.5(1) Four new methods are added: • getMediaForkingDeviceType() • getMediaForkingDeviceName() • getProtocolReferenceGUID() • getMediaForkingClusterID() 10.0(1) A new method, getRecordingType(), is added. 9.0(1) Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoRecorderInfo Fields None Methods Table 161: Methods in CiscoRecorderInfo Description Method Interface Returns the recorder address. getAddress() CiscoAddress This method returns the recording type that was used to start the recording. getRecordingType() public int Returns the terminal name of the recording device. getTerminalName() java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 512 Cisco Unified JTAPI Extensions Declaration

Description Method Interface This interface returns the Media Forking Device Type for Gateway Recording. The forking device type can be: CiscoCall.CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_NONE = 0 CiscoCall.CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE = 1 CiscoCall.CALL_RECORDING_MEDIA_FORKING _DEVICE_TYPE_GW = 2 getMediaForkingDeviceType() public int This interface returns the Forking Device Name for Gateway Recording. getMediaForkingDeviceName() java.lang.String This interface returns the Protocol Call Reference GUID for Gateway Recording. getProtocolReferenceGUID() java.lang.String This interface returns the Forking Cluster ID for Gateway Recording. getMediaForkingClusterID() java.lang.String Range of Values The range of values returned by the getRecordingType() method is defined on the CiscoCall object: CiscoCall.CALL_RECORDING_TYPE_NONE CiscoCall.CALL_RECORDING_TYPE_APPLICATION_INITIATED_SILENT CiscoCall.CALL_RECORDING_TYPE_AUTOMATIC CiscoCall.CALL_RECORDING_TYPE_USER_INITIATED_FROM_APPLICATION CiscoCall.CALL_RECORDING_TYPE_USER_INITIATED_FROM Related Documentation None CiscoRemoteDestinationInfo CiscoRemoteDestinationInfo is a new interface that contains the information about a remote destination on a CiscoRemoteTerminal. Applications can get a list of all associated remote destinations from the return array of CiscoRemoteTerminal.getAllRemoteDestinations(). Methods Description Method Interface This method returns the remote destination name. getRemoteDestinationName() String This method returns the remote destination number. getRemoteDestinationNumber() String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 513 Cisco Unified JTAPI Extensions Range of Values

Description Method Interface This method returns whether the remote destination is an active remote destination or not. getIsActiveRD() boolean CiscoRemoteTerminal CiscoRemoteTerminal is a new interface that extends the interface of CiscoTerminal. A CiscoRemoteTerminal is a special kind of CiscoTerminal representing the CTI Remote Device and Jabber/CUCSF (Cisco Unified Client Services Framework) Device in extend mode. It allows applications to monitor remote destinated devices such as PSTN, PBSX, and Mobiles phones. Interface History Description Cisco Unified Communications Manager Release Number A new interface, CiscoRemoteTerminal, is added. 9.0(1) Declaration public interface CiscoRemoteTerminal Methods Description Method Interface This method will return an array of CiscoRemoteDestinationInfo representing all remote destinations of the CiscoRemoteTerminal, or null if none. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. getAllRemoteDestinations () CiscoRemoteDestinationInfo[] This method will return an array CiscoRemoteDestinationInfo representing all active remote destinations of the CiscoRemoteTerminal, or null if none. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. getActiveRemoteDestinations () CiscoRemoteDestinationInfo[] This method will set/unset an active remote destination of the CiscoRemoteTerminal based on the remote destination number. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. Also note that the Remote Destination Number must be of a valid associated remote destination, and if the remoteDestinationNumber parameter is null, it will throw InvalidArgumentException. setActiveRemoteDestination (String remoteDestinationNumber, boolean isActiveRD) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 514 Cisco Unified JTAPI Extensions CiscoRemoteTerminal

Description Method Interface This method will add a new remote destination to the CiscoRemoteTerminal. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. And if either the remoteDestinationNumber or remoteDestinationName parameter is null, it will throw InvalidArgumentException. addRemoteDestination (String remoteDestinationName, String remoteDestinationNumber, boolean isActiveRD) void This method will remove a remote destination from the CiscoRemoteTerminal based on the remote destination number. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. Also note that the Remote Destination Number must be of a valid associated remote destination, and if the remoteDestinationNumber parameter is null, it will throw InvalidArgumentException. removeRemoteDestination (String remoteDestinationNumber) void This API will remove all associated remote destinations from the CiscoRemoteTerminal. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. removeAllRemoteDestinations () void This method will update the name of a remote destination of the CiscoRemoteTerminal based on the remote destination number. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. Also note that the Remote Destination Number must be of a valid associated remote destination, and if the remoteDestinationNumber parameter is null, it will throw InvalidArgumentException. updateRemoteDestinationName (String remoteDestinationNumber, String remoteDestinationName) void This method will update the number of a remote destination of the CiscoRemoteTerminal based on the remote destination number. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. Also note that the Remote Destination Number must be of a valid associated remote destination, and if either the remoteDestinationNumber or newRemoteDestinationNumber parameter is null, it will throw InvalidArgumentException. updateRemoteDestinationNumber (String remoteDestinationNumber, StringnewRemoteDestinationNumber) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 515 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method will update a remote destination of the CiscoRemoteTerminal based on the remote destination number. It can update any or all of its remote destination name, remote destination number, and isActiveRD at the same time. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. Also note that the Remote Destination Number must be of a valid associated remote destination, and if the remoteDestinationNumber parameter is null, it will throw InvalidArgumentException. updateRemoteDestination (String remoteDestinationNumber, String remoteDestinationName, String newRemoteDestinationNumber, boolean isActiveRD) void This method will return true if this application issued a successful registration request to register this terminal's device in Extend mode; return false otherwise. It will get set to true until this application unregisters the device. isRegisteredByThisApp () boolean This method will return the registration type with which this terminal's device has been registered in. The registration type returned can be one of the following: • CiscoRemoteTerminal. EXTEND_MEDIA_REGISTRATION • CiscoRemoteTerminal. NO_EXTEND_MEDIA_REGISTRATION getRegistrationType () int This method will return true if this application is the last application to set active remote destination for the CiscoRemoteTerminal; return false otherwise. Note that CiscoProvider must be in IN_SERVICE state, otherwise InvalidStateException will be thrown. isMyAppLastToSetActiveRD () boolean Parameters String remoteDestinationName The name of the specified remote destination. String remoteDestinationNumber The number of the specified remote destination. boolean isActiveRD The flag to indicate whether the specified remote destination is an active remote destination or not. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 516 Cisco Unified JTAPI Extensions Parameters

Data Type public static final int EXTEND_MEDIA_REGISTRATION = 8 This registration type applies to CUCSF device that is registered in Extend mode, which as a result is representing as a CiscoRemoteTerminal. NO_EXTEND_MEDIA_REGISTRATION = 0 This registration type applies to non-CUCSF device that is static registered and is representing as CiscoRemoteTerminal, such as CTI Remote Device. New Error Codes CiscoJtapiException.CTIERR_INVALID_REMOTE_DESTINATION_NUMBER (0x8CCC0121) CiscoJtapiException.CTIERR_DUPLICATE_REMOTE_DESTINATION_NUMBER (0x8CCC0122) CiscoJtapiException.CTIERR_REMOTEDESTINATION_LIMIT_EXCEEDED (0x8CCC0123) CiscoJtapiException. CTIERR_REMOTE_DEVICE_REQUEST_FAILED_ACTIVE_RD_NOT_SET (0x 8CCC0124) CiscoJtapiException.CTIERR_ENDUSER_NOT_ASSOCIATED_WITH_DEVICE (0x 8CCC0126) CiscoJtapiException.CTIERR_DEVICE_ALREADY_REGISTERED_NONEXTEND (0x 8CCC0127) CiscoJtapiException.CTIERR_MEDIA_ALREADY_TERMINATED_EXTEND (0x 8CCC0128) CiscoJtapiException.CTIERR_INVALID_REMOTE_DESTINATION_NAME (0x8CCC0130) Sample Code Sample Code: public static void main(String[] args) { try { JtapiPeer peer

JtapiPeerFactory.getJtapiPeer(null); String provStr

provName + ";login = " + login + ";passwd = " + passwd; Provider myProvider

peer.getProvider(provStr); MyProviderObserver providerObserver

new MyProviderObserver(); String myDevName

"CTIRD-A"; String temp

“”; if (myProvider ! = null) { myProvider.addObserver(providerObserver); provInService.waitTrue(); CiscoRemoteTerminal rTerm

(CiscoRemoteTerminal)(myProvider.getTerminal(myDevName)); if (rTerm ! = null) { CiscoRemoteDestinationInfo[] remoteDestinations

rTerm.getAllRemoteDestinations(); CiscoRemoteDestinationInfo[] activeRemoteDestinations

rTerm.getActiveRemoteDestinations(); Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 517 Cisco Unified JTAPI Extensions Data Type

System.out.println("CTI Remote Device Name: " + rTerm.getName()); if (remoteDestinations ! = null && remoteDestinations.length ! = 0) { System.out.println("Number of associated Remote Destinations (RD): " + remoteDestinations.length); for (int i

0; i < remoteDestinations.length; i++) { System.out.println("RD["+i+"] Name: " + remoteDestinations[i].getRemoteDestinationName()); System.out.println("RD["+i+"] Number: " + remoteDestinations[i].getRemoteDestinationNumber()); System.out.println("RD["+i+"] IsActiveRD: " + remoteDestinations[i].getIsActiveRD()); temp

remoteDestinations[i].getRemoteDestinationName(); if (temp ! = null && temp.equalsIgnoreCase(“MyOffice”)) { temp

remoteDestinations[i].getRemoteDestinationNumber(); rTerm.updateRemoteDestinationNumber(temp, “9498231202”); rTerm.setActiveRemoteDestination(“9498231202”, true); } } rTerm.addRemoteDestination(“MyHome”, “6267978244”, false); } else { System.out.println("There is no associated Remote Destinations (RD)"); } } else { System.out.println("There is no CTI Remote Device of " + myDevName + " in this provider"); } } else { System.out.println("Cannot create provider"); } } catch (Exception e) { System.out.println("Exception caught for getting CTI Remote Device RD info! " + e); if (e instanceof PlatformException) { switch (((CiscoJtapiException) e).getErrorCode()) { case CiscoJtapiException.CTIERR_INVALID_REMOTE_DESTINATION_NUMBER: System.out.println("Invalid RD Number"); break; case CiscoJtapiException. CTIERR_DUPLICATE_REMOTE_DESTINATION_NUMBER: System.out.println("Duplicated RD Number"); break; } } } } ... Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 518 Cisco Unified JTAPI Extensions Sample Code

CiscoRestrictedEv The CiscoRestrictedEv event is the parent class for the CiscoAddrRestrictedEv and CiscoAddrRestrictedOnTerminalEv events. This is the base class for restricted events and defines the cause codes for all restricted events. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Subinterfaces CiscoAddrRestrictedEv, CiscoAddrRestrictedOnTerminalEv Declaration public interface CiscoRestrictedEv extends CiscoProvEv Fields Table 162: Fields in CiscoRestrictedEv Description Field Interface The Terminal is restricted for an unknown reason. CAUSE_UNKNOWN staticint The Terminal is restricted due to an unsupported configuration (for example, configuring the rollover option). CAUSE_UNSUPPORTED_DEVICE_CONFIGURATION staticint The Terminal in the control list is using a protocol that Cisco Unified JTAPI does not support. CAUSE_UNSUPPORTED_PROTOCOL staticint The Terminal or Address is marked as restricted. CAUSE_USER_RESTRICTED staticint Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 519 Cisco Unified JTAPI Extensions CiscoRestrictedEv

Description Field Interface None ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE,CAUSE_SNAPSHOT, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE,CAUSE_SNAPSHOT, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 520 Cisco Unified JTAPI Extensions Inherited Fields

CiscoRouteAddress This interface is deprecated and has not been implemented. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.Address, javax.telephony.callcenter.RouteAddress Declaration public interface CiscoRouteAddress extends javax.telephony.callcenter.RouteAddress Fields None Inherited Fields From Interface javax.telephony.callcenter.RouteAddress ALL_ROUTE_ADDRESS Methods Table 163: Methods in CiscoRouteAddress Description Method Interface Deprecated Throws javax.telephony.ResourceUnavailableException javax, telephony.MethodNotSupportedException registerRouteCallback (javax.telephony.callcenter.RouteCallbackrouteCallback, booleandisableAutoRehoming) void Inherited Methods From Interface javax.telephony.callcenter.RouteAddress cancelRouteCallback, getActiveRouteSessions, getRouteCallback, registerRouteCallback Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 521 Cisco Unified JTAPI Extensions CiscoRouteAddress

From Interface javax.telephony.Address addCallObserver, addObserver, getAddressCapabilities, getCallObservers, getCapabilities, getConnections, getName, getObservers, getProvider, getTerminals, removeCallObserver, removeObserver Related Documentation None CiscoRouteEvent The CiscoRouteEvent interface extends the RouteEvent interface with additional Cisco-specific capabilities. Applications can use the getCallingPartyIpAddr method to obtain the IP address of the calling party device. Interface History Description Cisco Unified Communications Manager Release Number Added the method getCallingPartyIpAddr_v6(). 7.1(1 and 2) Superinterfaces javax.telephony.callcenter.events.RouteEvent, javax.telephony.callcenter.events.RouteSessionEvent Declaration public interface CiscoRouteEvent extends javax.telephony.callcenter.events.RouteEvent Fields None Inherited Fields From Interface javax.telephony.callcenter.events.RouteEvent SELECT_ACD, SELECT_EMERGENCY, SELECT_LEAST_COST, SELECT_NORMAL, SELECT_USER_DEFINED Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 522 Cisco Unified JTAPI Extensions Related Documentation

Methods Table 164: Methods in CiscoRouteEvent Description Method Interface Returns the IPv6 address of the calling party. If the IP address is not available, this method returns an InetAddress with the IP address 0::0 and a null host name. Printing this object yields a string representation of “null/0::0”. Returns: InetAddress. getCallingPartyIpAddr_v6() java.net.InetAddress Returns the IP address of the calling party. If the IP address is not available, this method returns an InetAddress with the IP address 0.0.0.0 and a null host name. Printing this object yields a string representation of “null/0.0.0.0”. getCallingPartyIpAddr() java.net.InetAddress Inherited Methods From Interface javax.telephony.callcenter.events.RouteEvent getCallingAddress, getCallingTerminal, getCurrentRouteAddress, getRouteSelectAlgorithm, getSetupInformation From Interface javax.telephony.callcenter.events.RouteSessionEvent getRouteSession Related Documentation None CiscoRouteSession The CiscoRouteSession interface supports application access to the underlying call that is associated with a RouteSession. Also, this interface exposes various internal ERRORs for RouteEndEvent. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Added route selection with deviceName 11.5(1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 523 Cisco Unified JTAPI Extensions Methods

Superinterfaces javax.telephony.callcenter.RouteSession Declaration public interface CiscoRouteSession extends javax.telephony.callcenter.RouteSession Fields Table 165: Fields in CiscoRouteSession Description Field Interface Each routeEvent() or reRouteEvent() that is sent starts a timer for the application to respond with a routeSelect() or endRoute(). The default value of this timer is 5 seconds. Should the application not respond within this time, the system calls an endRoute with this error. ERROR_ROUTESELECT_TIMEOUT static final int Because there is no default route mechanism in place, if there is no callback registered for this application, the system calls an endRoute with this error. ERROR_NO_CALLBACK static final int If an internal InvalidStateException occurred, or some preconditions or postconditions were not met during routing, the system calls endRoute with this error. ERROR_INVALID_STATE static final int This indicates that the redirect should be done by using the search space that is the default for the implementation. The default is to use the caller search space. DEFAULT_SEARCH_SPACE static final int This indicates that the redirect should be done by using the search space of the calling address. CALLINGADDRESS_SEARCH_SPACE static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 524 Cisco Unified JTAPI Extensions Superinterfaces

Description Field Interface This indicates that the redirect should be done by using the search space of the route point address. ROUTEADDRESS_SEARCH_SPACE static final int This is a parameter value for the PreferedOriginalCalled option; it specifies not to reset OriginalCalled. DONOT_RESET_ORIGINALCALLED static final int This is a parameter value for PreferedOriginalCalled Option; if the value of preferedOriginalCalledOption is set to this, it will reset the OriginalCalled to preferedOriginalCalledNumber. RESET_ORIGINALCALLED static final int This constant returned by RouteSession.getCause() indicates that the routeSelectedElement in the selectRoute does not contain the required FAC code. CAUSE_CTIERR_FAC_CMC_REASON_FAC_NEEDED static final int This constant returned by RouteSession.getCause() indicates that the routeSelectedElement in the selectRoute does not contain the required CMC code. CAUSE_CTIERR_FAC_CMC_REASON_CMC_NEEDED static final int This constant returned by RouteSession.getCause() indicates that the routeSelectedElement in the selectRoute does not contain the required FAC and CMC codes. CAUSE_CTIERR_FAC_CMC_REASON_FAC_CMC_NEEDED static final int This constant returned by RouteSession.getCause() indicates that the routeSelectedElement in the selectRoute contains an invalid FAC code. CAUSE_CTIERR_FAC_CMC_REASON_FAC_INVALID static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 525 Cisco Unified JTAPI Extensions Fields

Description Field Interface This constant returned by RouteSession.getCause() indicates that the routeSelectedElement in the selectRoute contains an invalid CMC code. CAUSE_CTIERR_FAC_CMC_REASON_CMC_INVALID static final int Inherited Fields From Interface javax.telephony.callcenter.RouteSession CAUSE_INVALID_DESTINATION, CAUSE_NO_ERROR, CAUSE_PARAMETER_NOT_SUPPORTED, CAUSE_ROUTING_TIMER_EXPIRED, CAUSE_STATE_INCOMPATIBLE, CAUSE_UNSPECIFIED_ERROR, ERROR_RESOURCE_BUSY, ERROR_RESOURCE_OUT_OF_SERVICE, ERROR_UNKNOWN, RE_ROUTE, ROUTE, ROUTE_CALLBACK_ENDED, ROUTE_END, ROUTE_USED Methods Table 166: Methods in CiscoRouteSession Description Method Interface Returns the call associated with this RouteSession. getCall() javax.telephony.Call Overloads the selectRoute method in the RouteSession interface to allow applications to specify a calling search space to use when the call is redirected to the route destination. Parameters javax.telephony. MethodNotSupportedException Throws • callingSearchSpace—One of CiscoRouteSession. DEFAULT_SEARCH_SPACE; CiscoRouteSession. CALLINGADDRESS_SEARCH_SPACE; or CiscoRouteSession. ROUTEADDRESS_SEARCH_SPACE. • routeSelected—A list of possible destinations for the call. selectRoute(java.lang. String[]routeSelected, intcallingSearchSpace) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 526 Cisco Unified JTAPI Extensions Inherited Fields

Description Method Interface selectRoute(java.lang. String[]routeSelected, intcallingSearchSpace, java.lang. String[]modifyingCallingNumber) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 527 Cisco Unified JTAPI Extensions Methods

Description Method Interface Selects one or more possible routing destinations for a call with a modified calling number. This method takes as an argument that is a string array of destination telephone address names, modifyingCallingNumber, arranged in priority order. The highest-priority destination is the first element in the specified array and routing is attempted with this destination first with the corresponding element of modifying calling number. If modifiedCallingNumber is null for an element, the calling number is not modified if a call is routed to that particular routeSelected element. The system attempts to use the specified destination addresses in order until the system successfully selects a destination. The system delivers a RouteUsedEvent to the application when it routes the call to that destination. Pre-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = RouteSession.ROUTE or RouteSession.RE_ROUTE Post-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = • RouteSession.ROUTE_USED (if the Call was successfully routed.) A RouteUsedEvent gets delivered for this RouteSession if a successful destination was selected. Parameters • routeSelected—Possible destinations for callcallingSearchSpace can be CiscoRouteSession.DEFAULT_SEARCH_SPACE; CiscoRouteSession. CALLINGADDRESS_SEARCH_SPACE; or CiscoRouteSession. ROUTEADDRESS_SEARCH_SPACE. • modifyingCallingNumber—An array of elements for which the application wants to modify the calling number when the call reaches the routeSelected element. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 528 Cisco Unified JTAPI Extensions Methods

Description Method Interface Throws • com.cisco.jtapi. MethodNotSupportedExceptionImpl (The implementation does not support routing.) • javax.telephony. PrivilegeViolationException (The user does not have the necessary privileges to use this method.) • javax.telephony.MethodNotSupportedException selectRoute Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 529 Cisco Unified JTAPI Extensions Methods

Description Method Interface selectRoute(java.lang. String[]routeSelected, intcallingSearchSpace, java.lang. String[]preferedOriginalCalledNumber, int[]preferedOriginalCalledOption void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 530 Cisco Unified JTAPI Extensions Methods

Description Method Interface Selects one or more possible destinations for routing the Call. This method takes as an argument a string array of destination telephone address names, in prioritized order, and a string array for the PreferredOriginalCalled number. PreferedOriginalCalled number gets selected based on the index of the destination telephone names array. If the index corresponding to the destination array is not found in the PreferedOriginalCalled number array, preferedOriginalCalled gets set to the destination. The highest-priority destination is the first element in the given array, and the system attempts to route with this destination first. The system attempts each given destination address in succession until the call gets successfully routed. The system delivers a RouteUsedEvent event to the application when a successful routing destination has been selected and the Call has been routed to that destination. Pre-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = RouteSession.ROUTE or • RouteSession.RE_ROUTE Post-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = • RouteSession.ROUTE_USED (if the Call was successfully routed.) A RouteUsedEvent gets delivered for this RouteSession if a successful destination was selected. Parameters • routeSelected—Possible destinations for the call. • preferedOriginalCalledNumber—List with each item corresponding to a route at the matching array index in the routeSelected list. • preferedOriginalCalledOption—List of options, each corresponding to routeSelected list. The option specifies whether to set OriginalCalled to preferedOriginalCalledNumber. The option values Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 531 Cisco Unified JTAPI Extensions Methods

Description Method Interface are CiscoRouteSession. DONOT_RESET_ORIGINALCALLED and CiscoRouteSession.RESET_ORIGINALCALLED. If the value is unspecified or null, the default is CiscoRouteSession. DONOT_RESET_ORIGINALCALLED. Throws com.cisco.jtapi. MethodNotSupportedExceptionImpl (The implementation does not support routing.) javax.telephony. PrivilegeViolationException (The user does not have the necessary privileges to use this method.) javax.telephony. MethodNotSupportedException selectRoute Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 532 Cisco Unified JTAPI Extensions Methods

Description Method Interface selectRoute(java.lang. String[]routeSelected, intcallingSearchSpace, java.lang. String[]modifyingCallingNumber, java.lang. String[]preferedOriginalCalledNumber, int[]preferedOriginalCalledOption, java.lang. String[]facCode, java.lang. String[]cmcCode) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 533 Cisco Unified JTAPI Extensions Methods

Description Method Interface Selects one or more possible routing destinations. It takes as arguments a string array of: • destination telephone address names, in prioritized order • PreferredOriginalCalled numbers • FACs • CMCs The system selects the PreferedOriginalCalled number corresponding to the index of the destination telephone name array. If the index is not found in the PreferedOriginalCalled number array, the preferedOriginalCalled gets set to the destination. The highest priority destination is the first element in the specified array, and the system attempts to route the call to that destination first. The system attempts the specified destination addresses in order, until the call gets routed successfully. The system delivers a RouteUsedEvent event to the application when the system has selected a successful routing destination and routed the call to that destination. Pre-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = RouteSession.ROUTE • RouteSession.RE_ROUTE Post-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = • RouteSession.ROUTE_USED (if the call was successfully routed). A RouteUsedEvent gets delivered for this RouteSession if a successful destination was selected. Parameters • routeSelected—List of possible destinations. • preferedOriginalCalledNumber—List with each member of corresponding to the route at the same array index in the routeSelected. • list.preferedOriginalCalledOption—List of options, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 534 Cisco Unified JTAPI Extensions Methods

Description Method Interface each corresponding to RouteList. The option specifies whether to set OriginalCalled to preferedOriginalCalledNumber. The option values are CiscoRouteSession. DONOT_RESET_ORIGINALCALLED and CiscoRouteSession. RESET_ORIGINALCALLED.If the value is unspecified or null, the default is CiscoRouteSession. DONOT_RESET_ORIGINALCALLED. • modifyingCallingNumber—Array of elements for which the application wants modify the calling number when the call reaches the routeSelected element. If applications do not want to modify the number, a null value for this parameter must be passed by the application. • facCode (Forced Authorization Code [FAC])—If a routeSelected element requires a FAC, the corresponding facCode element must contain that code. If no code is required for a routeSelected element, the application must pass a null value for this parameter. • cmcCode - (Client Matter Code [CMC]) If a routeSelected element requires a CMC, the corresponding cmcCode element must contain that code. If no code is required for a routeSelected element, the application must pass a null value for this parameter. Throws • com.cisco.jtapi. MethodNotSupportedExceptionImpl (The implementation does not support routing.) • javax.telephony. PrivilegeViolationException (The user does not have the necessary privileges to use this method.) • javax.telephony. MethodNotSupportedException selectRoute Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 535 Cisco Unified JTAPI Extensions Methods

Description Method Interface selectRoute(java.lang. String[]routeSelected, intcallingSearchSpace, java.lang. String[]modifyingCallingNumber, java.lang. String[]preferedOriginalCalledNumber, int[]preferedOriginalCalledOption, java.lang. String[]facCode, java.lang. String[]cmcCode, intfeaturePriority) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 536 Cisco Unified JTAPI Extensions Methods

Description Method Interface Selects one or more possible routing destinations. It takes a string array of: • Destination telephone address names, in prioritized order • PreferredOriginalCalled numbers • FACs • CMCs • Integer priorities The PreferedOriginalCalled number gets selected based on the index of the destination telephone name array. If the index tis not found in the PreferedOriginalCalled number array, preferedOriginalCalled gets set to the destination. The highest-priority destination is the first element in the given array, and the system attempts to route with this destination first. The system tries the successive specified destination addresses until the call gets routed successfully. The system delivers a RouteUsedEvent event to the application when a successful routing destination has been selected and the call has been routed to that destination. Pre-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = RouteSession.ROUTE • RouteSession.RE_ROUTE Post-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = • RouteSession.ROUTE_USED (if the Call was successfully routed.) Parameters routeSelected—Possible destinations for the call. preferedOriginalCalledNumber—List with each element corresponding to the route at the same array index in the routeSelected list. preferedOriginalCalledOption—Options list, each corresponding to RouteList. The option specifies whether Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 537 Cisco Unified JTAPI Extensions Methods

Description Method Interface to set OriginalCalled to preferedOriginalCalledNumber. The option values are CiscoRouteSession. DONOT_RESET_ORIGINALCALLED and CiscoRouteSession. RESET_ORIGINALCALLED. If the value is unspecified or null, the default is CiscoRouteSession. DONOT_RESET_ORIGINALCALLED. • modifyingCallingNumber—Array of elements for which the application would like to modify the calling number when the call reaches the routeselected element. If applications do not want to modify the number, they must pass a null value for this parameter. • facCode (Forced Authorization Code [FAC])—If a routeSelected element requires a FAC, the corresponding facCode element must contain that code. If no code is required for a routeSelected element, the application must pass a null value for this parameter. • cmcCode (Client Matter Code [CMC])—If a routeSelected element requires a CMC, the corresponding cmcCode element must contain that code. If no code is required for a routeSelected element, the application must pass a null value for this parameter. • featurePriority—Sets the feature priority of the call. The application may set CiscoCall. FEATUREPRIORITY_NORMAL if the application does not want to set any specific priority. The featurePriority parameter may be: • CiscoCall. FEATUREPRIORITY_NORMAL • CiscoCall. FEATUREPRIORITY_URGENT • CiscoCall. FEATUREPRIORITY_EMERGENCY Throws • javax.telephony. PrivilegeViolationException (The user does not have the necessary privileges to use this method.) • com.cisco.jtapi. MethodNotSupportedExceptionImpl (The implementation does not support routing.) • javax.telephony. MethodNotSupportedException Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 538 Cisco Unified JTAPI Extensions Methods

Description Method Interface selectRoute(java.lang. String[]routeSelected, int[]callingSearchSpace, java.lang. String[]modifyingCallingNumber, java.lang. String[]preferedOriginalCalledNumber, int[]preferedOriginalCalledOption, java.lang. String[]facCode, java.lang. String[]cmcCode, int[]featurePriority) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 539 Cisco Unified JTAPI Extensions Methods

Description Method Interface Selects one or more possible routing destinations. It takes a string array of: • destination telephone address names, in prioritized order • calling search spaces • modifyingCallingNumbers • PreferredOriginalCalled numbers • FACs • CMCs • feature priorities The PreferedOriginalCalled number gets selected based on the index of the destination telephone name array. If the index tis not found in the PreferedOriginalCalled number array, preferedOriginalCalled gets set to the destination. The highest-priority destination is the first element in the given array, and the system attempts to route with this destination first. The system tries the successive specified destination addresses until the call gets routed successfully. The system delivers a RouteUsedEvent event to the application when a successful routing destination has been selected and the call has been routed to that destination. Pre-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = RouteSession.ROUTE • RouteSession.RE_ROUTE Post-conditions • this.getRouteAddress().getProvider().getState() =

• Provider.IN_SERVICE this.getState() = = • RouteSession.ROUTE_USED (if the call was successfully routed.) Parameters • routeSelected—List of possible destinations for the call. • callingSearchSpace—For each route selected; can Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 540 Cisco Unified JTAPI Extensions Methods

Description Method Interface be CiscoRouteSession. DEFAULT_SEARCH_SPACE, CiscoRouteSession. CALLINGADDRESS_SEARCH_SPACE, or CiscoRouteSession. ROUTEADDRESS_SEARCH_SPACE. • preferedOriginalCalledNumber—List with each element corresponding to the route at the same array index in the routeSelected list. • preferedOriginalCalledOption—Options list, each corresponding to RouteList. The option specifies whether to set OriginalCalled to preferedOriginalCalledNumber. The option values are CiscoRouteSession. DONOT_RESET_ORIGINALCALLED and CiscoRouteSession.RESET_ORIGINALCALLED. If the value is unspecified or null, the default is CiscoRouteSession. DONOT_RESET_ORIGINALCALLED. • modifyingCallingNumber—Elements array for which the application would like to modify the calling number when the call reaches the routeselected element. If applications do not want to modify the number, they must pass a null value for this parameter. • facCode (Forced Authorization Code [FAC])—If a routeSelected element requires a FAC, the corresponding facCode element must contain that code. If no code is required for a routeSelected element, the application must pass a null value for this parameter. • cmcCode (Client Matter Code [CMC])—If a routeSelected element requires a CMC, the corresponding cmcCode element must contain that code. If no code is required for a routeSelected element, the application must pass a null value for this parameter. • featurePriority—For each route selected, the feature priority can be set. The application may set CiscoCall. FEATUREPRIORITY_NORMAL if the application does not want to set any specific priority. The featurePriority parameter may be CiscoCall. FEATUREPRIORITY_NORMAL, CiscoCall. FEATUREPRIORITY_URGENT, or CiscoCall.FEATUREPRIORITY_EMERGENCY Throws Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 541 Cisco Unified JTAPI Extensions Methods

Description Method Interface • javax.telephony. PrivilegeViolationException (The user does not have the necessary privileges to use this method.) • com.cisco.jtapi. MethodNotSupportedExceptionImpl (The implementation does not support routing.) • javax.telephony. MethodNotSupportedException This method is similar to the above method, but takes an array of destination device names, in a prioritized order. This order of device names corresponds to the order of destinations provided in route selected. This method takes a string array of: • destination telephone address names, in prioritized order • calling search spaces • modifyingCallingNumbers • PreferredOriginalCalled numbers • FACs • CMCs • feature priorities • Application XML • device Names selectRoute(String[] routeSelected, int[] callingSearchSpace, String[] modifyingCallingNumber,String[] preferedOriginalCalledNumber, int[] preferedOriginalCalledOption, String[] facCode, String[] cmcCode,int[] featurePriority, byte[][] applicationXMLData, String[] deviceName void Inherited Methods From Interface javax.telephony.callcenter.RouteSession endRoute, getCause, getRouteAddress, getState, selectRoute Related Documentation See Constant Field Values, on page 1667. CiscoRouteTerminal A CiscoRouteTerminal is a special kind of CiscoTerminal that allows applications to terminate RTP media streams. Unlike a CiscoTerminal, a CiscoRouteTerminal does not represent a physical telephony endpoint, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 542 Cisco Unified JTAPI Extensions Inherited Methods

which is observable and controllable in a third-party manner. Instead, a CiscoRouteTerminal is a logical telephony endpoint that may be associated with any application that wants to route calls and terminate media. Unlike a CiscoMediaTerminal, a CiscoRouteTerminal can have multiple active calls at the same time. Typically, applications use CiscoRouteTerminals to queue calls until an agent is available to service them. CiscoRouteTerminals are CTI Route Points on Cisco Unified Communications Manager. Note Terminating media is a three-step process as follows: 1. The application registers its media capabilities with this Terminal by using the CiscoRouteTerminal.register method. 2. The application adds an observer that implements the CiscoTerminalObserver interface by using the Terminal.addObserver method. 3. The application must call addCallObserver on the CiscoRouteTerminal or the CiscoRouteAddress to receive and answer calls. Applications will receive a CiscoMediaOpenLogicalChannelEv for each call or whenever media is stopped and needs to be reestablished. Applications must supply an IP address and port number by using the setRTPParams method on CiscoRouteTerminal. Important—All applications written for or prior to CiscoJtapiClient Release 1.4 must be modified to register with CiscoRouteTerminal.NO_MEDIA_TERMINATION type if the applications are not interested in media termination. Note Multiple applications can register with same RoutePoint as long as they are registered with the same media capabilities and registration type. All applications, if registered with CiscoRouteTerminal.DYNAMIC_MEDIA_REGISTRATION, will receive CiscoMediaOpenLogicalChannelEv when they add a callObserver, but only one application will be able to invoke setRTPParams. Applications that are interested in media termination must add a CallObserver on the RouteAddress or on the CiscoRouteTerminals. Applications must not register with Dynamic type and add a registerRouteCallBack. Applications should only use registerRouteCallBack if they are not interested in media termination. Applications must not add a registerRouteCallBack and a callObserver at the same time. Interface History Description Cisco Unified Communications Manager Release Number Added these modes to the activeAddressingMode: • CiscoTerminal.IP_ADDRESSING_MODE_IPv6 • CiscoTerminal.IP_ADDRESSING_MODE_IPv4_v6 7.1(1 and 2) Superinterfaces CiscoObjectContainer, CiscoTerminal, javax.telephony.Terminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 543 Cisco Unified JTAPI Extensions Superinterfaces

Declaration public interface CiscoRouteTerminal extends CiscoTerminal Fields Table 167: Fields in CiscoRouteTerminal Description Field Interface Applications that are interested in media termination need to register with this type and pass in the capabilities that the application supports in the registration request. DYNAMIC_MEDIA_REGISTRATION staticint Applications that are not interested in media termination need to register with this type and pass in a null value for CiscoMediaCapability in the registration request. If registrationType is CiscoRouteTerminal. NO_MEDIA_REGISTRATION, the application cannot terminate media and can use the CiscoRouteTerminal for call routing. NO_MEDIA_REGISTRATION staticint Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoTerminal ASCII_ENCODING, DEVICESTATE_ACTIVE, DEVICESTATE_ALERTING, DEVICESTATE_HELD, DEVICESTATE_IDLE, DEVICESTATE_UNKNOWN, DEVICESTATE_WHISPER, DND_OPTION_CALL_REJECT, DND_OPTION_NONE, DND_OPTION_RINGER_OFF, IN_SERVICE, IP_ADDRESSING_MODE_IPV4, IP_ADDRESSING_MODE_IPV4_V6, IP_ADDRESSING_MODE_IPV6, IP_ADDRESSING_MODE_UNKNOWN, IP_ADDRESSING_MODE_UNKNOWN_ANATRED, NOT_APPLICABLE, OUT_OF_SERVICE, UCS2UNICODE_ENCODING, UNKNOWN_ENCODING Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 544 Cisco Unified JTAPI Extensions Declaration

Methods Table 168: Methods in CiscoRouteTerminal Description Method Interface Registers a Terminal with specified CiscoMediaCapabilities and register type. The Provider must be in the Provider.IN_SERVICE state. Returns successfully when the CiscoRouteTerminal is registered. Parameters • capabilities—List of RTP encodings that the application supports for this Terminal. If the application is not interested in media termination, you may pass in a null value. • registrationType—Either CiscoRouteTerminal .DYNAMIC_MEDIA_REGISTRATION or CiscoRouteTerminal .NO_MEDIA_REGISTRATION. If registrationType is CiscoRouteTerminal .NO_MEDIA_REGISTRATION, the application cannot terminate media and can use the CiscoRouteTerminal for call routing. If registrationType is CiscoRouteTerminal .DYNAMIC_MEDIA_REGISTRATION, the application can terminate media and can have multiple active calls. This registrationType indicates that the application will supply the IP address and port dynamically for each call. Applications registering with this type receive a CiscoMediaOpenLogicalChannelEv for each call and must supply the IP address and port number by using the setRTPParams method on the CiscoRouteTerminal . Throws • CiscoRegistrationException register(CiscoMediaCapability[]capabilities, intregistrationType) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 545 Cisco Unified JTAPI Extensions Methods

Description Method Interface Registers a Terminal with the specified CiscoMediaCapabilities, registrationType, and supported SRTP algorithms. The Provider must be in the Provider.IN_SERVICE state. This method returns successfully when the CiscoRouteTerminal is registered. Parameters • capabilities—List of RTP encodings that the application supports for this Terminal. If the application is not interested in media termination, you may pass in a null value. • registrationType—Either CiscoRouteTerminal .DYNAMIC_MEDIA_REGISTRATION or CiscoRouteTerminal .NO_MEDIA_REGISTRATION. If registrationType is CiscoRouteTerminal .NO_MEDIA_REGISTRATION, the application cannot terminate media and can use the CiscoRouteTerminal for call routing. Other parameters in the method are ignored. If registrationType is CiscoRouteTerminal .DYNAMIC_MEDIA_REGISTRATION, the application can terminate media and can have multiple active calls. This registrationType indicates that the application will supply the IP address and port dynamically for each call. Applications registering with this type receive a CiscoMediaOpenLogicalChannelEv for each call and must supply the IP address and port number by using the setRTPParams method. • algorithmIDs—List of SRTP algorithms that the application supports for this Terminal. To use this, the application must have the TLS Link and SRTP Enabled flag enabled. AlgorithmIDs must be one of CiscoMediaEncryptionSupportedAlgorithms. Throws • javax.telephony.PrivilegeViolationException (The application tried to use the method, but is not authorized to use it.) • CiscoRegistrationException register(CiscoMediaCapability[]capabilities, intregistrationType, int[]algorithmIDs) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 546 Cisco Unified JTAPI Extensions Methods

Description Method Interface register(CiscoMediaCapability[]capabilities, intregistrationType, int[]algorithmIDs, intactiveAddressingMode) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 547 Cisco Unified JTAPI Extensions Methods

Description Method Interface The CiscoRouteTerminal must be in the CiscoTerminal.UNREGISTERED state and its Provider must be in the Provider.IN_SERVICE state. The successful effect of this method is to register the RouteTerminal. Registers a Terminal with specified CiscoMediaCapabilities and register type and supported SRTP Algorithms. If registrationType is CiscoRouteTerminal .NO_MEDIA_REGISTRATION, application cannot terminate media and can use route point for call routing purpose. Other parameters in the method are ignored. If registration Type is CiscoRouteTerminal .DYNAMIC_MEDIA_REGISTRATION, then app can terminate media and can have multiple active calls. This Indicates that application is interested in supplying ipAddress and port dynamically for each call. Applications registering with this type will receive CiscoMediaOpenLogicalChannelEv for each call and will have to supply ipAddress and port number using setRTPParams method on CiscoRouteTerminal . Method arguments Capabilities indicates the type of RTP encodings that the application is willing to support for this Terminal. If application is not intersted in media termination, it may pass in null value registrationType may be CiscoRouteTerminal .NO_MEDIA_REGISTRATION or CiscoRouteTerminal .DYNAMIC_MEDIA_REGISTRATION. Supported Algorithms may be the SRTP Algorithms that application supports for this terminal. In order to use this, application need to have TLS Link and SRTP Enabled flag enabled. PrivilegeViolationException is thrown if app is not authorized to use this method. Post-condition This method returns successfully when the CiscoRouteTerminal is registered. Parameters • capabilities—List of RTP encodings supported by this terminal. • registrationType—CiscoRouteTerminal .DYNAMIC_MEDIA_REGISTRATION or CiscoRouteTerminal .NO_MEDIA_REGISTRATION Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 548 Cisco Unified JTAPI Extensions Methods

Description Method Interface • algorithmIDs—List of supported SRTP algorithms. AlgorithmIDs may only be one of CiscoMediaEncryptionSupportedAlgorithms. • activeAddressingMode—IP Addressing mode in which application intends to register this CiscoRouteTerminal . The modes can be: • CiscoTerminal.IP_ ADDRESSING_MODE_IPv4 • CiscoTerminal.IP_ ADDRESSING_MODE_IPv6 • CiscoTerminal.IP_ ADDRESSING_MODE_IPv4_v6 Throws • CiscoRegistrationException • javax.telephony.PrivilegeViolationException The CiscoRouteTerminal must be registered and its Provider must be in the Provider.IN_SERVICE state. The successful effect of this method is to unregister the CiscoRouteTerminal . Post-condition • This method returns successfully when the MediaTerminal is unregistered. Throws • CiscoUnregistrationException unregister() void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 549 Cisco Unified JTAPI Extensions Methods

Description Method Interface Applications can set the IP address and RTP Port number to dynamically stream media for a call. To do this, applications must register MediaTerminal or CiscoRouteTeminal by providing only capabilities. Applications must then invoke this method upon receiving CiscoCallOpenLogicalChannelEv on the TerminalObserver. Parameters rtpHandle—The handle the application receives in CiscoCallOpenLogicalChannelEvrtpParams. Refer to CiscoRTPParams. Throws • javax.telephony.InvalidStateException • javax.telephony.InvalidArgumentException • javax.telephony.PrivilegeViolationException setRTPParams(CiscoRTPHandlertpHandle, CiscoRTPParamsrtpParams) void This method returns true if the CiscoMediaTerminal is registered and false otherwise. If the CiscoRouteTerminal is OutOfService, this method returns false; if it is InService, this method returns true. For CTIManager failure cases, this method returns false. isRegistered() boolean This method returns true if this application issued a successful registration request. The registration remains valid even if the device is out-of-service because of a CTIManager failure. This returns true until this application unregisters the device. isRegisteredByThisApp() boolean Application can invoke this API to query the IP Addressing Mode of the CiscoRouteTerminal . Addressing mode may be any of the following constants: • CiscoTerminal.IP_ ADDRESSING_IPv4 • CiscoTerminal.IP_ ADDRESSING_IPv6 • CiscoTerminal.IP_ ADDRESSING_IPv4_v6 getIPAddressingMode() int Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoTerminal createSnapshot, getAltScript, getDeviceState, getDNDOption, getDNDStatus, getEMLoginUsername, getFilter, getLocale, getProtocol, getRegistrationState, getRTPInputProperties, getRTPOutputProperties, getState, getSupportedEncoding, isRestricted, sendData, sendData, setDNDStatus, setFilter, unPark Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 550 Cisco Unified JTAPI Extensions Inherited Methods

From Interface javax.telephony.Terminal addCallObserver, addObserver, getAddresses, getCallObservers, getCapabilities, getName, getObservers, getProvider, getTerminalCapabilities, getTerminalConnections, removeCallObserver, removeObserver From Interface com.cisco.jtapi.extensions.CiscoObjectContainer getObject, setObject Related Documentation See CiscoTerminal and Constant Field Values, on page 1667 CiscoMediaOpenLogicalChannelEv CiscoRouteUsedEvent The CiscoRouteUsedEvent event indicates that the RouteSession moved into the RouteSession.ROUTE_USED state and the call terminated at a destination as a result of application routing. This interface extends the RouteUsedEvent interface and gets reported via the RouteCallback interface. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.callcenter.events.RouteSessionEvent, javax.telephony.callcenter.events.RouteUsedEvent Declaration public interface CiscoRouteUsedEvent extends javax.telephony.callcenter.events.RouteUsedEvent Fields None Methods Table 169: Methods in CiscoRouteUsedEvent Description Method Interface Returns an array index of the route where the call got routed. getRouteSelectedIndex() Int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 551 Cisco Unified JTAPI Extensions Related Documentation

Inherited Methods From Interface javax.telephony.callcenter.events.RouteUsedEvent getCallingAddress, getCallingTerminal, getDomain, getRouteUsed From Interface javax.telephony.callcenter.events.RouteSessionEvent getRouteSession Related Documentation See RouteSession, RouteCallback, and RouteSessionEvent. CiscoRTPBitRate The RTPBitRate interface contains constants describing G.723 RTP bit rates. CiscoRTPInputProperties.getBitRate and CiscoRTPOutputProperties.getBitRate return these constants. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoRTPBitRate Fields Table 170: Fields in CiscoRTPBitRate Description Fields Interface This constant is the 5.3k G.723 bit rate. R5_3 staticint This constant is the 6.4k G.723 bit rate. R6_4 staticint Methods None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 552 Cisco Unified JTAPI Extensions Inherited Methods

Related Documentation See CiscoRTPInputProperties.getBitRate(), CiscoRTPOutputProperties.getBitRate() CiscoRTPHandle Use the CiscoRTPHandle object to get a call reference with CiscoProvider.getCall(CiscoRTPHandle). This object gets returned in CiscoMediaCallOpenLogicalChannelEv. Pass this handle in the setRTPParams parameter of CiscoMediaTerminal or CiscoRouteTerminal, depending on where the CiscoMediaCallOpenLogicalChannelEv event gets received. If no call observer was added, or there was no call observer added at the time CiscoMediaCallOpen LogicalChannelEv got sent, CiscoProvider.getCall(CiscoRTPHandle) may return null. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoRTPHandle Fields None Methods Table 171: Methods in CiscoRTPHandle Description Method Interface Returns the Cisco Unified Communications Manager CallLeg ID of the call, in integer format. getHandle() Int Related Documentation None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 553 Cisco Unified JTAPI Extensions Related Documentation

CiscoRTPInputKeyEv The CiscoRTPInputKeyEv event interface gives the key information for the encrypted incoming media stream. Applications should set the filter by using CiscoTermEvFilter.setRTPKeyEventsEnabled(true) to get this event via the TerminalObserver.terminalChangedEvent(). Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoRTPInputKeyEv extends CiscoTermEv Fields Table 172: Fields in CiscoRTPInputKeyEv Description Field Interface None ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 554 Cisco Unified JTAPI Extensions CiscoRTPInputKeyEv

META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 173: Methods in CiscoRTPInputKeyEv Description Method Interface Returns CiscoMediaEncryptionKeyInfo only if the provider is opened with the TLS link and SRTP enabled options set for the application in the Cisco Unified Communications Manager administration. Otherwise, it returns null. getCiscoMediaEncryptionKeyInfo() int Returns the media security indicator, one of the following constants: CiscoMediaSecurityIndicator. MEDIA_ENCRYPTED_KEYS_AVAILABLE CiscoMediaSecurityIndicator. MEDIA_ENCRYPT_USER_NOT_AUTHORIZED CiscoMediaSecurityIndicator. MEDIA_ENCRYPTED_KEYS_UNAVAILABLE getCiscoMediaSecurityIndicator() int Returns a CiscoCallID object if there is already a CiscoCall present when this event is sent. If there is no CiscoCall present, this method returns null. getCallID().getCall() gives the call for which this key applies. getCallID() CiscoCallID Returns a CiscoRTPHandle object. Applications can get a call reference by using CiscoProvider.getCall. If there is no call observer or there was no call observer when this event got delivered, CiscoProvider.getCall returns null. Returns:CiscoRTPHandle. getCiscoRTPHandle() int Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 555 Cisco Unified JTAPI Extensions Methods

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See CiscoRTPParams, CiscoMediaSecurityIndicator. CiscoRTPInputProperties The CiscoRTPInputProperties interface returns the properties of the media received by the Terminal (the inbound media stream). CiscoRTPInputStartedEv indicates that the media started. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoRTPInputProperties Fields None Methods Table 174: Methods in CiscoRTPInputProperties Description Method Interface Returns the media bit rate and can CiscoRTPBitRate.R5_3 or CiscoRTPBitRate.R6_4. getBitRate() int Returns True if the application needs to use echo cancellation. getEchoCancellation() boolean Returns the address to which media will be directed. getLocalAddress() java.net.InetAddress Returns the port to which media will be directed. getLocalPort() int Returns the packet size, in milliseconds. getPacketSize() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 556 Cisco Unified JTAPI Extensions Related Documentation

Description Method Interface Returns the payload format, which is one of the following constants: • CiscoRTPPayload.G711ALAW64K • CiscoRTPPayload.G711ALAW56K • CiscoRTPPayload.G711ULAW64K • CiscoRTPPayload.G711ULAW56K • CiscoRTPPayload.G722_64K • CiscoRTPPayload.G722_56K • CiscoRTPPayload.G722_48K • CiscoRTPPayload.G7231 • CiscoRTPPayload.G728 • CiscoRTPPayload.G729 • CiscoRTPPayload.G729ANNEXA • CiscoRTPPayload.ACY_G729AASSN • CiscoRTPPayload.DATA64 • CiscoRTPPayload.DATA56 • CiscoRTPPayload.GSM • CiscoRTPPayload.WIDEBAND_256K getPayloadType() int Related Documentation See CiscoRTPPayload and CiscoRTPBitRate. CiscoRTPInputStartedEv The CiscoRTPInputStartedEv event indicates the start of incoming media. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoRTPInputStartedEv extends CiscoTermEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 557 Cisco Unified JTAPI Extensions Related Documentation

Fields Table 175: Fields in CiscoRTPInputStartedEv Description Field Interface None ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 176: Methods in CiscoRTPInputStartedEv Description Method Interface Returns CiscoCallID. getCallID() CiscoCallID Returns a CiscoRTPHandle object. getCiscoRTPHandle() CiscoRTPHandle Returns a CiscoMediaConnectionMode. getMediaConnectionMode() int Returns CiscoRTPInputProperties, which gives the characteristics of the incoming media. getRTPInputProperties() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 558 Cisco Unified JTAPI Extensions Fields

Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667, CiscoRTPInputProperties, CiscoCallID, CiscoRTPParams, and CiscoMediaConnectionMode. CiscoRTPInputStoppedEv The CiscoRTPInputStoppedEv event indicates that the incoming media stream has stopped. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoRTPInputStoppedEv extends CiscoTermEv Fields Table 177: Fields in CiscoRTPInputStoppedEv Description Field Interface None ID staticint Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 559 Cisco Unified JTAPI Extensions Inherited Methods

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 178: Methods in CiscoRTPInputStoppedEv Description Method Interface Returns CiscoCallID. CiscoRTPInputStartedEv applies to CiscoCallID.getCall(). getCallID() CiscoCallID Returns CiscoRTPHandle object. Applications can get call reference using CiscoProvider.getCall If there is no callobserver or there was no callobserver when this event is delivered, then CiscoProvider.getCall may return null. getCiscoRTPHandle() CiscoRTPHandle Returns a CiscoMediaConnectionMode with one of the following values for mediaMode: • CiscoMediaConnectionMode. RECEIVE_ONLY (one-way media, receive only) • CiscoMediaConnectionMode. TRANSMIT_AND_RECEIVE: (two-way media) In general, you should never get an event with mode NONE; however, if that happens, applications should ignore the event and log an error. getMediaConnectionMode() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 560 Cisco Unified JTAPI Extensions Inherited Fields

Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667, CiscoMediaConnectionMode, CiscoCallID, and CiscoRTPParams. CiscoRTPOutputKeyEv The CiscoRTPOutputKeyEv event gives the key information for the encrypted outgoing (transmitted) media stream. Applications set the filter by using CiscoTermEvFilter.setRTPKeyEventsEnabled(true) to get this event via the TerminalObserver.terminalChangedEvent(). Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoRTPOutputKeyEv extends CiscoTermEv Fields Table 179: Fields in CiscoRTPOutputKeyEv Description Field Interface None ID staticint Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 561 Cisco Unified JTAPI Extensions Inherited Methods

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 180: Methods in CisctoRTPOutputKeyEv Description Method Interface Returns a CiscoCallID object if there is already a CiscoCall present when this event is sent. If there is no CiscoCall present, this method returns null. getCallID() CiscoCallID Returns CiscoMediaEncryptionKeyInfo only if the provider is opened with the TLS link and SRTP enabled options set for the application in Cisco Unified Communications Manager administration. Otherwise, it will return null. getCiscoMediaEncryptionKeyInfo() CiscoMediaEncryptionKeyInfo Returns media security indicator, one of the following constants: • CiscoMediaSecurityIndicator. MEDIA_ENCRYPTED_KEYS_AVAILABLE • CiscoMediaSecurityIndicator. MEDIA_ENCRYPT_USER_NOT_AUTHORIZED • CiscoMediaSecurityIndicator. MEDIA_ENCRYPTED_KEYS_UNAVAILABLE getCiscoMediaSecurityIndicator() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 562 Cisco Unified JTAPI Extensions Inherited Fields

Description Method Interface Returns a CiscoRTPHandle object. Applications can get a call reference by using CiscoProvider.getCall. If there is no call observer or there was no call observer when this event is delivered, CiscoProvider.getCall may return null. getCiscoRTPHandle() CiscoRTPHandle Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667, CiscoRTPParams, and CiscoMediaSecurityIndicator. CiscoRTPOutputProperties The CiscoRTPOutputProperties interface gives the properties of the media transmitted by the terminal. CiscoRTPOutputStartedEv indicates that the media has started. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoRTPOutputProperties Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 563 Cisco Unified JTAPI Extensions Inherited Methods

Methods Table 181: Methods in CiscoRTPOutputProperties Description Method Interface Returns the media bit rate, one of the following constants: • CiscoRTPBitRate.R5_3 • CiscoRTPBitRate.R6_4 getBitRate() int Returns the maximum number of frames to send per packet. getMaxFramesPerPacket() int Returns the packet size, in milliseconds. getPacketSize() int Returns the payload format, which is one of the following constants: • CiscoRTPPayload.NONSTANDARD • CiscoRTPPayload.G711ALAW64K • CiscoRTPPayload.G711ALAW56K • CiscoRTPPayload.G711ULAW64K • CiscoRTPPayload.G711ULAW56K • CiscoRTPPayload.G722_64K • CiscoRTPPayload.G722_56K • CiscoRTPPayload.G722_48K • CiscoRTPPayload.G7231 • CiscoRTPPayload.G728 • CiscoRTPPayload.G729 • CiscoRTPPayload.G729ANNEXA • CiscoRTPPayload.IS11172AUDIOCAP • CiscoRTPPayload.IS13818AUDIOCAP • CiscoRTPPayload.ACY_G729AASSN • CiscoRTPPayload.DATA64 • CiscoRTPPayload.DATA56 • CiscoRTPPayload.GSM • CiscoRTPPayload.ACTIVEVOICE • CiscoRTPPayload.WIDEBAND_256K getPayloadType() int Returns the precedence value. getPrecedenceValue() int Returns the address to which media is to be transmitted. getRemoteAddress() java.net. InetAddress Returns the port to which media is to be transmitted. getRemotePort() int Returns false if Cisco Unified Communication Manager service parameter “Silence Suppression” is set to False or True otherwise. getSilenceSuppression() boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 564 Cisco Unified JTAPI Extensions Methods

Related Documentation See CiscoRTPBitRate. CiscoRTPOutputStartedEv The CiscoRTPOutputStartedEv event interface indicates the start of media transmission. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoRTPOutputStartedEv extends CiscoTermEv Fields Table 182: Fields in CiscoRTPOutputStartedEv Description Field Interface None ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 565 Cisco Unified JTAPI Extensions Related Documentation

CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 183: Methods in CiscoRTPOutputStartedEv Description Method Interface Returns the RTP output properties. getRTPOutputProperties() CiscoRTPOutputProperties Returns CiscoCallID. CiscoRTPOutputStartedEv applies to CiscoCallID.getCall(). getCallID() CiscoCallID Returns a CiscoRTPHandle object. Applications can get a call reference by using CiscoProvider.getCall. If there is no call observer or there was no call observer when this event is delivered, CiscoProvider.getCall may return null. getCiscoRTPHandle() CiscoRTPHandle Returns a CiscoMediaConnectionMode with one of the following values for mediaMode: • CiscoMediaConnectionMode.TRANSMIT_ONLY (one-way media; transmit only) • CiscoMediaConnectionMode. TRANSMIT_AND_RECEIVE (two-way media) Note In general, you should never get an event with mode NONE; however, if that happens, applications should ignore the event and log an error. getMediaConnectionMode() int Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 566 Cisco Unified JTAPI Extensions Methods

Related Documentation See Constant Field Values, on page 1667, CiscoCallID, and CiscoRTPParams. CiscoRTPOutputStoppedEv The CiscoRTPOutputStoppedEv event indicates that the media transmission stopped. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoRTPOutputStoppedEv extends CiscoTermEv Fields Table 184: Fields in CiscoRTPOutputStoppedEv Description Field Interface None ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 567 Cisco Unified JTAPI Extensions Related Documentation

CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 185: Methods in CiscoRTPOutputStoppedEv Description Method Interface Returns CiscoCallID. CiscoRTPOutputStoppedEv applies to CiscoCallID.getCall(). getCallID() CiscoCallID Returns a CiscoRTPHandle object. Applications can get a call reference by using CiscoProvider.getCall. If there is no call observer or there was no call observer when this event is delivered, CiscoProvider.getCall may return null. getCiscoRTPHandle() CiscoRTPHandle • Returns CiscoMediaConnectionMode with one of the following values: • CiscoMediaConnectionMode.TRANSMIT_ONLY (one-way media; transmit) • onlyCiscoMediaConnectionMode. TRANSMIT_AND_RECEIVE (two-way media) Note In general, you should never get an event with mode NONE; however, if that happens, applications should ignore the event and log an error. getMediaConnectionMode() int Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667, CiscoCallID, CiscoRTPParams, and CiscoMediaConnectionMode. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 568 Cisco Unified JTAPI Extensions Methods

CiscoRTPOutputKeyEv The CiscoRTPOutputKeyEv event gives the key information for the encrypted outgoing (transmitted) media stream. Applications set the filter by using CiscoTermEvFilter.setRTPKeyEventsEnabled(true) to get this event via the TerminalObserver.terminalChangedEvent(). Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoRTPOutputKeyEv extends CiscoTermEv Fields Table 186: Fields in CiscoRTPOutputKeyEv Description Field Interface None ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 569 Cisco Unified JTAPI Extensions CiscoRTPOutputKeyEv

META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 187: Methods in CisctoRTPOutputKeyEv Description Method Interface Returns a CiscoCallID object if there is already a CiscoCall present when this event is sent. If there is no CiscoCall present, this method returns null. getCallID() CiscoCallID Returns CiscoMediaEncryptionKeyInfo only if the provider is opened with the TLS link and SRTP enabled options set for the application in Cisco Unified Communications Manager administration. Otherwise, it will return null. getCiscoMediaEncryptionKeyInfo() CiscoMediaEncryptionKeyInfo Returns media security indicator, one of the following constants: • CiscoMediaSecurityIndicator. MEDIA_ENCRYPTED_KEYS_AVAILABLE • CiscoMediaSecurityIndicator. MEDIA_ENCRYPT_USER_NOT_AUTHORIZED • CiscoMediaSecurityIndicator. MEDIA_ENCRYPTED_KEYS_UNAVAILABLE getCiscoMediaSecurityIndicator() int Returns a CiscoRTPHandle object. Applications can get a call reference by using CiscoProvider.getCall. If there is no call observer or there was no call observer when this event is delivered, CiscoProvider.getCall may return null. getCiscoRTPHandle() CiscoRTPHandle Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 570 Cisco Unified JTAPI Extensions Methods

Related Documentation See Constant Field Values, on page 1667, CiscoRTPParams, and CiscoMediaSecurityIndicator. CiscoRTPOutputProperties The CiscoRTPPutputProperties interface gives the properties of the media transmitted by the terminal. CiscoRTPOutPutStartedEv indicates that the media has started. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoRTPOutputProperties Fields None Methods Table 188: Methods in CiscoRTPOutputProperties Description Method Interface Returns the media bit rate, one of the following constants: • CiscoRTPBitRate.R5_3 • CiscoRTPBitRate.R6_4 getBitRate() int Returns the maximum number of frames to send per packet. getMaxFramesPerPacket() int Returns the packet size, in milliseconds. getPacketSize() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 571 Cisco Unified JTAPI Extensions Related Documentation

Description Method Interface Returns the payload format, which is one of the following constants: • CiscoRTPPayload.NONSTANDARD • CiscoRTPPayload.G711ALAW64K • CiscoRTPPayload.G711ALAW56K • CiscoRTPPayload.G711ULAW64K • CiscoRTPPayload.G711ULAW56K • CiscoRTPPayload.G722_64K • CiscoRTPPayload.G722_56K • CiscoRTPPayload.G722_48K • CiscoRTPPayload.G7231 • CiscoRTPPayload.G728 • CiscoRTPPayload.G729 • CiscoRTPPayload.G729ANNEXA • CiscoRTPPayload.IS11172AUDIOCAP • CiscoRTPPayload.IS13818AUDIOCAP • CiscoRTPPayload.ACY_G729AASSN • CiscoRTPPayload.DATA64 • CiscoRTPPayload.DATA56 • CiscoRTPPayload.GSM • CiscoRTPPayload.ACTIVEVOICE • CiscoRTPPayload.WIDEBAND_256K getPayloadType() int Returns the precedence value. getPrecedenceValue() int Returns the address to which media is to be transmitted. getRemoteAddress() java.net.InetAddress Returns the port to which media is to be transmitted. getRemotePort() int Returns false if Cisco Unified Communication Manager service parameter “Silence Suppression” is set to False or True otherwise. getSilenceSuppression() boolean Related Documentation See CiscoRTPBitRate. CiscoRTPOutputStartedEv The CiscoRTPOutputStartedEv event interface indicates the start of media transmission. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 572 Cisco Unified JTAPI Extensions Related Documentation

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoRTPOutputStartedEv extends CiscoTermEv Fields Table 189: Fields in CiscoRTPOutputStartedEv Description Field Interface None ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 573 Cisco Unified JTAPI Extensions Superinterfaces

Methods Table 190: Methods in CiscoRTPOutputStartedEv Description Method Interface Returns the RTP output properties. getRTPOutputProperties() CiscoRTPOutputProperties Returns CiscoCallID. CiscoRTPOutputStartedEv applies to CiscoCallID.getCall(). getCallID() CiscoCallID Returns a CiscoRTPHandle object. Applications can get a call reference by using CiscoProvider.getCall. If there is no call observer or there was no call observer when this event is delivered, CiscoProvider.getCall may return null. getCiscoRTPHandle() CiscoRTPHandle Returns a CiscoMediaConnectionMode with one of the following values for mediaMode: • CiscoMediaConnectionMode.TRANSMIT_ONLY (one-way media; transmit only) • CiscoMediaConnectionMode. TRANSMIT_AND_RECEIVE (two-way media) Note In general, you should never get an event with mode NONE; however, if that happens, applications should ignore the event and log an error. getMediaConnectionMode() int Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667, CiscoCallID, and CiscoRTPParams. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 574 Cisco Unified JTAPI Extensions Methods

CiscoRTPOutputStoppedEv The CiscoRTPOutputStoppedEv event indicates that the media transmission stopped. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoRTPOutputStoppedEv extends CiscoTermEv Fields Table 191: Fields in CiscoRTPOutputStoppedEv Description Field Interface None ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 575 Cisco Unified JTAPI Extensions CiscoRTPOutputStoppedEv

META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 192: Methods in CiscoRTPOutputStoppedEv Description Method Interface Returns CiscoCallID. CiscoRTPOutputStoppedEv applies to CiscoCallID.getCall(). getCallID() CiscoCallID Returns a CiscoRTPHandle object. Applications can get a call reference by using CiscoProvider.getCall. If there is no call observer or there was no call observer when this event is delivered, CiscoProvider.getCall may return null. getCiscoRTPHandle() CiscoRTPHandle • Returns CiscoMediaConnectionMode with one of the following values: • CiscoMediaConnectionMode.TRANSMIT_ONLY (one-way media; transmit) • onlyCiscoMediaConnectionMode. TRANSMIT_AND_RECEIVE (two-way media) Note In general, you should never get an event with mode NONE; however, if that happens, applications should ignore the event and log an error. getMediaConnectionMode() int Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667, CiscoCallID, CiscoRTPParams, and CiscoMediaConnectionMode. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 576 Cisco Unified JTAPI Extensions Methods

CiscoRTPPayload The RTPPayload interface contains constants that describe RTP formats. The CiscoRTPInputProperties.getPayloadType and CiscoRTPOutputProperties.getPayloadType methods return these constants. Interface History Description Cisco Unified Communications Manager Release Number Added H261, H263, H264, H264_SVC, T120, and H224 Methods. 10.0(1) Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoRTPPayload Fields Table 193: Fields in CiscoRTPPayload Description Fields Interface A nonstandard RTP payload NONSTANDARD static final int G.711 64K a-law payload G711ALAW64K static final int G.711 56K a-law payload G711ALAW56K static final int G.711 64K u-law payload G711ULAW64K static final int G.711 56K u-law payload G711ULAW56K static final int G.722 64K payload G722_64K static final int G.722 56K payload G722_56K static final int G.722 48K payload G722_48K static final int G.723.1 payload G7231 static final int G.728 payload G728 static final int G.729 payload G729 static final int G.729a payload G729ANNEXA static final int IS11172AUDIOCAP payload IS11172AUDIOCAP static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 577 Cisco Unified JTAPI Extensions CiscoRTPPayload

Description Fields Interface IS13818AUDIOCAP payload IS13818AUDIOCAP static final int ACY_G729AASSN payload ACY_G729AASSN static final int DATA64 payload DATA64 static final int DATA56 payload DATA56 static final int GSM payload GSM static final int ACTIVEVOICE payload ACTIVEVOICE static final int Wide_Band_256k payload WIDEBAND_256K static final int Methods Table 194: Methods in CiscoRTPPayload Description Method Interface The rtp payload type associated with the multimedia stream is H261. H261 static final int The rtp payload type associated with the multimedia stream is H263. H263 static final int The rtp payload type associated with the multimedia stream is H264. H264 static final int The rtp payload type associated with the multimedia stream is H264_SVC. H264_SVC static final int The rtp payload type associated with the multimedia stream is T120. T120 static final int The rtp payload type associated with the multimedia stream is H224. H224 static final int Related Documentation See CiscoRTPInputProperties.getPayloadType(), CiscoRTPOutputProperties.getPayloadType(), and Constant Field Values, on page 1667. CiscoRTPProperties This interface contains the rtp properties of the multi media streams information. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 578 Cisco Unified JTAPI Extensions Methods

Table 195: Interface History Description Cisco Unified Communications Manager Release Number New interface. 10.0(1) Declaration public interface CiscoRTPProperties Methods Table 196: Methods in CiscoRTPProperties Description Method Interface Specifies the receiving IP address. getReceptionAddress() InetAddress Specifies the receiving port number. getReceptionPort() int Specifies the transmitting IP address. getTransmissionAddress() InetAddress Specifies the transmitting port number. getTransmissionPort() boolean Returns the payload format. The payload type can be: • CiscoRTPPayload.H261 = 100 • CiscoRTPPayload.H263_VIDEO = 101 • CiscoRTPPayload.VIDEO = 102 • CiscoRTPPayload.H264 = 103 • CiscoRTPPayload.H264_SVC = 104 • CiscoRTPPayload.T120 = 105 • CiscoRTPPayload.H224 = 106 getPayloadType() int Returns the maximum bit rate (bits per second), which is the max allowed video bit rate as negotiated by media layer. The value is the smaller of the region BW(Bandwidth) setting and BW requested by the endpoints. getMaxBitRate() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 579 Cisco Unified JTAPI Extensions Declaration

CiscoSynchronousObserver The Cisco JTAPI implementation is designed to allow applications to invoke blocking JTAPI methods such as Call.connect() and TerminalConnection.answer() from within their observer callbacks. This means that applications are not subject to the restrictions imposed by the JTAPI specification, which cautions applications against using JTAPI methods from within observer callbacks. Normally, when an application adds a new observer to a JTAPI object, the Cisco JTAPI implementation creates an event queue and an accompanying worker thread to service the new observer. If the same observer is added to another object, its queue and thread are reused; in effect, every unique observer object has a single queue and worker thread. As noted, the advantage of this arrangement is that an application may invoke blocking JTAPI methods from within its observer callback. A subtle disadvantage, however, is that accessor methods such as Call.getConnections() and Connection.getState() may not return results that are consistent with events when invoked from within the observer callback. For example, suppose that an application creates and connects a call from address "A" to address "B." If the application is observing address "A", it might reasonably expect that when it receives the CallActiveEv, the state of the call will be Call.ACTIVE. This is not necessarily true, because the worker thread that delivers events to the application is decoupled from the internal JTAPI thread that updates object states. In fact, if "B" rejects the call from "A, " the call object might be in either the Call.ACTIVE state or the Call.INVALID state, depending on the exact moment at which the worker thread delivers the CallActiveEv. Many applications will not be adversely affected by this asychronous behavior. Applications that would benefit from a coherent call model during observer callbacks, however, can selectively disable the queueing logic of the Cisco JTAPI implementation. Applications that implement the CiscoSynchronousObserver interface on their observer objects declare that they want events to be delivered synchronously to its observers. Events delivered to synchronous observers will match the states of the call model objects 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 accessor 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. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoSynchronousObserver Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 580 Cisco Unified JTAPI Extensions CiscoSynchronousObserver

Methods None Related Documentation None CiscoTermActivatedEv If a Terminal is observed and the restriction status changes to active, the system sends this event to the application. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoTermActivatedEv extends CiscoProvEv Fields Table 197: Fields in CiscoTermActivatedEv Description Field Interface None ID static int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 581 Cisco Unified JTAPI Extensions Methods

META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 198: Methods in CiscoTermActivatedEv Description Method Interface Returns the Terminal that is activated. getTerminal() javax.telephony.Terminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermButtonPressedEv CiscoTermButtonPressedEv event is delivered on the TerminalObserver when a button is pressed on the Terminal. To receive this event, an application must set the filter using ciscoTermEvFilter.setButtonPressedEnabled(true). The button pressed events respond only to the numeric keypad button presses on the Terminal as listed in the constants in this interface: 0-9, *, #, A, B, C, and D. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 582 Cisco Unified JTAPI Extensions Methods

Declaration public interface CiscoTermButtonPressedEv extends CiscoTermEv Fields Table 199: Fields in CiscoTermButtonPressedEv Field Interface CHARA staticint CHARB staticint CHARC staticint CHARD staticint EIGHT staticint FIVE staticint FOUR staticint ID staticint NINE staticint ONE staticint POUND staticint SEVEN staticint SIX staticint STAR staticint THREE staticint TWO staticint ZERO staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 583 Cisco Unified JTAPI Extensions Declaration

META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 200: Methods in CiscoTermButtonPressedEv Description Method Interface The button pressed on the Terminal. getButtonPressed() int Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See CiscoTermEvFilter and Constant Field Values, on page 1667. CiscoTermConnMonitoringEndEv The system delivers the CiscoTermConnMonitoringEndEv event to the call observer when monitoring stops on the call or when call is disconnected. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 584 Cisco Unified JTAPI Extensions Methods

Interface History Description Cisco Unified Communications Manager Release Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoTermConnMonitoringEndEv extends javax.telephony.events.TermConnEv Fields Table 201: Fields in CiscoTermConnMonitoringEndEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 202: CiscoTermConnMonitoringEndEv Methods Description Method Interface Returns the type of monitoring. The return value is always CiscoCall.SILENT_MONITOR. getMonitorType() Int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 585 Cisco Unified JTAPI Extensions Superinterfaces

Inherited Methods From Interface javax.telephony.events.TermConnEv getTerminalConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. CiscoTermConnMonitoringStartEv The system delivers the CiscoTermConnMonitoringStartEv event to the call observer when monitoring starts on the call. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoTermConnMonitoringStartEv extends javax.telephony.events.TermConnEv Fields Table 203: Fields in CiscoTermConnMonitoringStartEv Field Interface ID staticfinal int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 586 Cisco Unified JTAPI Extensions Inherited Methods

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 204: CiscoTermConnMonitoringStartEv Methods Description Method Interface Returns the type of monitoring. The return value is always CiscoCall.Silent_Monitor. getMonitorType() int Inherited Methods From Interface javax.telephony.events.TermConnEv getTerminalConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 for more information. CiscoTermConnMonitorInitiatorInfoEv The CiscoTermConnMonitorInitiatorInfoEv event interface extends the TermConnEv interface and gets reported via the CallObserver on the monitor target (agent). This interface gives information about the monitor initiator (supervisor) when a monitor session gets established. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 587 Cisco Unified JTAPI Extensions Inherited Fields

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) A new API getTransactionID() will be exposed to retrieve the transaction ID. 8.0(1) Superinterfaces javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoTermConnMonitorInitiatorInfoEv extends javax.telephony.events.TermConnEv Fields Table 205: Fields in CiscoTermConnMonitorInitiatorInfoEv Fields Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 206: Methods in CiscoTermConnMonitorInitiatorInfoEv Description Method Interface Returns the Terminal name and Address of the monitor initiator. getCiscoMonitorInitiatorInfo() CiscoMonitorInitiatorInfo Returns the transaction ID. getTransactionID() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 588 Cisco Unified JTAPI Extensions Superinterfaces

Inherited Methods From Interface javax.telephony.events.TermConnEv getTerminalConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermConnMonitorTargetInfoEv The CiscoTermConnMonitorTargetInfoEv event interface extends the TermConnEv interface and gets reported via the CallObserver on monitor initiator. This interface provides information about the monitor target (agent) when a monitor session gets established. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) A new getTransactionID() will be exposed to retrieve the transaction ID. 8.0(1) Superinterfaces javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoTermConnMonitorTargetInfoEv extends javax.telephony.events.TermConnEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 589 Cisco Unified JTAPI Extensions Inherited Methods

Fields Table 207: Fields in CiscoTermConnMonitorTargetInfoEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 208: Methods in CiscoTermConnMonitorTargetInfoEv Description Method Interface Returns the Terminal name and Address of the monitor target. getCiscoMonitorTargetInfo() CiscoMonitorTargetInfo Returns the transaction ID. getTransactionID() int Inherited Methods From Interface javax.telephony.events.TermConnEv getTerminalConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 590 Cisco Unified JTAPI Extensions Fields

CiscoTermConnPrivacyChangedEv The system sends the CiscoTermConnPrivacyChangedEv event when the privacy status of a TeminalConnection changes. If privacy is active, the user cannot Barge into the Call. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoTermConnPrivacyChangedEv Fields Table 209: Fields in CiscoTermConnPrivacyChangedEv Field Interface ID staticint Methods Table 210: Methods in CiscoTermConnPrivacyChangedEv Description Method Interface Returns the TerminalConnection where privacy changed. You can call getPrivacyStatus on the TerminalConnection to check its privacy status. getTerminalConnection() javax.telephony. TerminalConnection Related Documentation See Constant Field Values, on page 1667 and CiscoTerminalConnection.getPrivacyStatus(). CiscoTermConnRecordingEndEv The JTAPI delivers CiscoTermConnRecordingEndEv to the call observer when call recording stops. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 591 Cisco Unified JTAPI Extensions CiscoTermConnPrivacyChangedEv

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoTermConnRecordingEndEv extends javax.telephony.events.TermConnEv Fields staticintID Inherited Fields Fields inherited from interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.TermConnEv getTerminalConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 592 Cisco Unified JTAPI Extensions Superinterfaces

Related Documentation See Constant Field Values, on page 1667. CiscoTermConnRecordingStartEv The JTAPI delivers CiscoTermConnRecordingStartEv to the call observer when call recording starts. Superinterfaces javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoTermConnRecordingStartEv extends javax.telephony.events.TermConnEv Fields Table 211: Fields in CiscoTermConnRecordingStartEv Field Interface ID static int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.TermConnEv getTerminalConnection Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 593 Cisco Unified JTAPI Extensions Related Documentation

From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermConnRecordingTargetInfoEv The JTAPI delivers CiscoTermConnRecordingTargetInfoEv to the call observer of the recording initiator. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoTermConnRecordingTargetInfoEv extends javax.telephony.events.TermConnEv Fields Table 212: Fields in CiscoTermConnRecordingTargetInfoEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 594 Cisco Unified JTAPI Extensions Related Documentation

META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 213: Methods in CiscoTermConnRecordingTargetInfoEv Description Method Interface Returns CiscoRecorderInfo, which provides the terminal name and address of the recording device. getCiscoRecorderInfo() CiscoRecorderInfo From Interface javax.telephony.events.TermConnEv getTerminalConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 and CiscoRecorderInfo. CiscoTermConnRecordingFailedEv The JTAPI delivers CiscoTermConnRecordingFailedEv to the call observer when call recording failed. Superinterfaces javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoTermConnRecordingFailedEv extends TermConnEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 595 Cisco Unified JTAPI Extensions Methods

Fields Table 214: Fields in CiscoTermConnRecordingStartEv Field Interface ID static int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.TermConnEv getTerminalConnection From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermConnSelectChangedEv The JTAPI sends CiscoTermConnSelectChangedEv when the call select status of a TerminalConnection changes, either by feature invocation or manually. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 596 Cisco Unified JTAPI Extensions Fields

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallEv, javax.telephony.events.Ev, javax.telephony.events.TermConnEv Declaration public interface CiscoTermConnSelectChangedEv extends javax.telephony.events.TermConnEv Fields Table 215: Fields in CiscoTermConnSelectChangedEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.TermConnEv getTerminalConnection From Interface javax.telephony.events.CallEv getCall Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 597 Cisco Unified JTAPI Extensions Superinterfaces

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermCreatedEv The JTAPI sends the CiscoTermCreatedEv event to the provider observer of the application when a CiscoTerminal gets added to the provider domain. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoTermCreatedEv extends CiscoProvEv Fields Table 216: Fields in CiscoTermEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 598 Cisco Unified JTAPI Extensions Related Documentation

From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 217: Methods in CiscoTermCreatedEv Description Method Interface Returns the Terminal object for which this event was sent. getTerminal() javax.telephony.Terminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermDataEv The JTAPI sends the CiscoTermDataEv event to the terminal observer when the phone receives XSI data (XML object). Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 599 Cisco Unified JTAPI Extensions Methods

Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermDataEv extends CiscoTermEv Fields Table 218: Fields in CiscoTermDataEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 219: Methods in CiscoTermDataEv Description Method Interface Deprecated.Use byte[] getTermData getData() java.lang.String Returns an XML-encoded byte array corresponding to the XSI data that the phone received. getTermData() byte[] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 600 Cisco Unified JTAPI Extensions Superinterfaces

Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermDeviceStateActiveEv The CiscoTermDeviceStateActiveEv event gets sent to the Terminal Observer if any of the addresses on the terminal have an outgoing call in any state or an incoming call with TerminalConnection and CallCtlTerminalConnection in ACTIVE and TALKING state respectively. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermDeviceStateActiveEv extends CiscoTermEv Fields Table 220: Fields in CiscoTermDeviceStateActiveEv Field Interface ID staticint Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 601 Cisco Unified JTAPI Extensions Inherited Methods

Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermDeviceStateAlertingEv The CiscoTermDeviceStateAlertingEv event gets sent to the Terminal Observer if none of the Addresses on the Terminal have an outgoing call or an incoming call with Connection in CallCtlConnection.Established Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 602 Cisco Unified JTAPI Extensions Inherited Fields

state, and at least one of the addresses on the Terminal has an incoming Call with Connection in CallCtlConnection.OFFERED or CallCtlConnection.ALERTING State. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermDeviceStateAlertingEv extends CiscoTermEv Fields Table 221: Fields in CiscoTermDeviceStateAlertingEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 603 Cisco Unified JTAPI Extensions Superinterfaces

Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermDeviceStateHeldEv The CiscoTermDeviceStateHeldEv event gets sent to the Terminal Observer if all of the calls on the addresses of the Terminal have TerminalConnection in CallCtlTerminalConnection.HELD state. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermDeviceStateHeldEv extends CiscoTermEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 604 Cisco Unified JTAPI Extensions Methods

Fields Table 222: Fields in CiscoTermDeviceStateHeldEv Field Interface ID staticint Inherited Fields Fields Inherited From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 605 Cisco Unified JTAPI Extensions Fields

Related Documentation See Constant Field Values, on page 1667. CiscoTermDeviceStateIdleEv The CiscoTermDeviceStateIdleEv event gets sent to the Terminal Observer if there are no calls on any of the Addresses of the Terminal. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermDeviceStateIdleEv extends CiscoTermEv Fields Table 223: Fields in CiscoTermDeviceStateIdleEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 606 Cisco Unified JTAPI Extensions Related Documentation

From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermDeviceStateWhisperEv The CiscoTermDeviceStateActiveEv event gets sent to Terminal Observer if atleast one of the Addresses on the Terminal is an intercom target and has an intercom call with the TerminalConnection/CallCtlTerminalConneciton in State Passive/Bridged state. In this state, the user can initiate new outgoing calls and receive new incoming calls. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 607 Cisco Unified JTAPI Extensions Methods

Declaration public interface CiscoTermDeviceStateWhisperEv extends CiscoTermEv Fields Table 224: Fields in CiscoTermDeviceStateWhisperEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 608 Cisco Unified JTAPI Extensions Declaration

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermDNDOptionChangedEv The CiscoTermDNDOptionChangedEv event is delivered to the terminal observer if DND option is changed. This event is delivered only if the filter to receive events is enabled by the application. This event is provided on application observer History Description Cisco Unified Communications Manager Release Added the extension. 7.0(1) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv public interface CiscoTermDNDOptionChangedEv extends CiscoTermEv Fields Table 225: CiscoTermDNDOptionChangedEv Fields Field Interface ID static final int Table 226: Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION,CAUSE_NETWORK_NOT_OBTAINABLE,CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 609 Cisco Unified JTAPI Extensions Related Documentation

Table 227: Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION,CAUSE_NETWORK_NOT_OBTAINABLE,CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 228: CiscoTermDNDOptionChangedEv Methods Description Method Interface This interface returns the current DND option to the application. It returns int dndOption. getDNDOption() Int Table 229: Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Table 230: Inherited Methods From Interface javax.telephony.events.TermEv getTerminal Table 231: Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent See also Constant Field Values, on page 1667. and CiscoTermEv. CiscoTermDNDStatusChangedEv The CiscoTermDNDStatusChangedEv event gets delivered to the Terminal Observer if the DND status changes, provided that the application has enabled the filter to receive events. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 610 Cisco Unified JTAPI Extensions Methods

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermDNDStatusChangedEv extends CiscoTermEv Fields Table 232: Fields in CiscoTermDNDStatusChangedEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 611 Cisco Unified JTAPI Extensions Superinterfaces

Methods Table 233: Methods in CiscoTermDNDStatusChangedEv Description Method Interface Returns the current DND status to the application. getDNDStatus() boolean Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See CiscoTermEvFilter, CiscoTermEv, and Constant Field Values, on page 1667. CiscoTermEv The CiscoTermEv interface, which extends the JTAPI core javax.telephony.events.TermEv interface, serves as the base interface for all Cisco-extended JTAPI Terminal events. Every Call-related event in this package extends this interface, directly or indirectly. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Subinterfaces CiscoMediaOpenLogicalChannelEv, CiscoRTPInputKeyEv, CiscoRTPInputStartedEv, CiscoRTPInputStoppedEv, CiscoRTPOutputKeyEv, CiscoRTPOutputStartedEv, CiscoRTPOutputStoppedEv, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 612 Cisco Unified JTAPI Extensions Methods

CiscoTermButtonPressedEv, CiscoTermDataEv, CiscoTermDeviceStateActiveEv, CiscoTermDeviceStateAlertingEv, CiscoTermDeviceStateHeldEv, CiscoTermDeviceStateIdleEv, CiscoTermDeviceStateWhisperEv, CiscoTermDNDOptionChangedEv, CiscoTermDNDStatusChangedEv, CiscoTermInServiceEv, CiscoTermOutOfServiceEv, CiscoTermRegistrationFailedEv, CiscoTermSnapshotCompletedEv, CiscoTermSnapshotEv Declaration public interface CiscoTermEv extends CiscoEv, javax.telephony.events.TermEv Fields None Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 613 Cisco Unified JTAPI Extensions Declaration

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See CallEv. CiscoTermEvFilter An application can use the CiscoTermEvFilter interface to selectively restrict those Terminal events that are not of interest. Interface History Description Cisco Unified Communications Manager Release Number Added getHuntLogStatusChangedEvFilter() and setHuntLogStatusChangedEvFilter(boolean filterValue) methods. 11.5(1) Added getMultiMediaStreamsInfoEvFilter() and setMultiMediaStreamsInfoEvFilter(boolean filterValue) methods. 10.0(1) Created history table to track changes. 7.1(1 and 2) Declaration public interface CiscoTermEvFilter Fields None Methods Table 234: Methods in CiscoTermEvFilter Description Method Interface Returns the event filter status of the CiscoTermDataEv event for the Terminal. The default value is disabled. Returns True if the event filter is enabled, or false if the event filter is disabled. getDeviceDataEnabled() boolean Enables or disables the CiscoTermDataEv events for the Terminal. setDeviceDataEnabled(booleanenabled) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 614 Cisco Unified JTAPI Extensions Related Documentation

Description Method Interface Returns the event filter status of the CiscoTermButtonPressedEv event for the Terminal. The default value is disabled. Returns:True if the event filter is enabled, or false if the event filter is disabled. getButtonPressedEnabled() boolean Enables or disables CiscoTermButtonPressedEv events for the Terminal. setButtonPressedEnabled(booleanenabled) void Returns the event filter status of the CiscoRTPInputStartedEv, CiscoRTPOutputStartedEv, CiscoRTPInputStoppedEv, and CiscoRTPOutputStoppedEv events for the Terminal. The Default value is disabled. Returns:True if the event filter is enabled, or false if the event filter is disabled. getRTPEventsEnabled() boolean Enables or disables CiscoRTPInputStartedEv, CiscoRTPOutputStartedEv, CiscoRTPInputStoppedEv and CiscoRTPOutputStoppedEv events for the Terminal. setRTPEventsEnabled(booleanenabled) void Returns the event filter status of the CiscoTermSnapshotEv and CiscoTermSnapshotCompletedEv events for the Terminal. If disabled, neither event gets sent to applications. Returns:True if the event filter is enabled, or false if the event filter is disabled. getSnapshotEnabled() boolean Enable or disables CiscoTermSnapshotEv and CiscoTermSnapshotCompletedEv for the Terminal. setSnapshotEnabled(booleanenabled) void Returns the event filter status of the CiscoRTPInputKeyEv and CiscoRTPOutputKeyEv events for the Terminal. Returns:True if the event filter is enabled, or false if the event filter is disabled. getRTPKeyEventsEnabled() boolean Enables or disables the CiscoRTPInputKeyEv and CiscoRTPOutputKeyEv events for the Terminal. setRTPKeyEventsEnabled(booleanenabled) void Returns the event filter status of the CiscoTermDeviceStateActiveEv event for the Terminal. Returns:True if the event filter is enabled, or false if the event filter is disabled. getDeviceStateActiveEvFilter() boolean Returns the event filter status of the CiscoTermDeviceStateHeldEv event for the Terminal. Returns: True if the event filter is enabled, or false if the event filter is disabled. getDeviceStateHeldEvFilter() boolean Returns the event filter status of the CiscoTermDeviceStateAlerting event for the Terminal. Returns:True if the event filter is enabled, or false if the event filter is disabled. getDeviceStateAlertingEvFilter() boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 615 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns the CiscoTermDeviceStateIdleEv filter status. Returns:True if the event filter is enabled, or false if the event filter is disabled. getDeviceStateIdleEvFilter() boolean Enables or disables the CiscoTermDeviceStateActiveEv filter for the Terminal. Default value is disable. setDeviceStateActiveEvFilter(booleanfilterValue) void Enables or disables the CiscoTermDeviceStateHeldEv filter for the Terminal. Default value is disable setDeviceStateHeldEvFilter(booleanfilterValue) void Enables or disables the CiscoTermDeviceStateAlertingEv filter for the Terminal. Default value is disable setDeviceStateAlertingEvFilter(booleanfilterValue) void Enables or disables the CiscoTermDeviceStateIdleEv filter for the Terminal. Default value is disable setDeviceStateIdleEvFilter(booleanfilterValue) void Returns the CiscoTermDeviceStateWhisperEv filter status on the Terminal. getDeviceStateWhisperEvFilter() boolean Returns the CiscoTermDNDStatusChangedEv filter status Returns:the CiscoTermDNDStatusChangedEv Filter status on the Terminal. getDNDChangedEvFilter() boolean Enables or disables the CiscoTermDNDStatusChangedEv filter for the Terminal. Parameters:filterValue - void setDeviceStateWhisperEvFilter(booleanfilterValue) Enables or disables the CiscoTermDeviceStateWhisperEv filter for the Terminal. The default value is disable. setDNDChangedEvFilter(booleanfilterValue) void This interface can be used to get CiscoTermDNDOptionChangedEv filter status . Returns:the CiscoTermDNDOptionChangedEv Filter status on the Terminal. getDNDOptionChangedEvFilter() boolean This interface is provided for enabling/disabling the CiscoTermDNDOptionChangedEv filter for the Terminal Parameters:filterValue. setDNDOptionChangedEvFilter(booleanfilterValue) void This interface can be used to get CiscoMultiMediaStreamsInfoEv filter status. getMultiMediaStreamsInfoEvFilter() boolean This interface is provided for enabling/disabling the CiscoMultiMediaStreamsInfoEv filter for the Terminal. setMultiMediaStreamsInfoEvFilter(boolean filterValue) void This method is used get the value of filter, the value of filter is false by default. getHuntLogStatusChangedEvFilter() boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 616 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method is used to set the filter, if filter value is true, the event CiscoTermHuntLogStatusChangedEv is received by the application when the value of huntLogStatus is changed. setHuntLogStatusChangedEvFilter(boolean filterValue) void Related Documentation None CiscoTerminal Standard JTAPI does not support the notion of dynamic terminal registration. The CiscoTerminal interface extends the standard terminal interface to do so. All Cisco Unified Communications Manager devices are represented by CiscoTerminals, and you can query all CiscoTerminals to determine whether they are currently IN_SERVICE or OUT_OF_SERVICE. If the Cisco Unified Communications Manager device represented by the CiscoTerminal is an IP telephone, for instance, it goes OUT_OF_SERVICE if it loses its network connection. Other types of devices, such as CiscoMediaTerminal, get registered on demand by applications, and may be IN_SERVICE or OUT_OF_SERVICE accordingly. CiscoTerminal includes an API getIPAddressingMode(). This interface returns the configured IP Addressing Mode of the CiscoTerminal. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) This interface is enhanced to: • Get the IP addresses of the terminal • Get the outbound call roll over configuration of the terminal. New interfaces expose consult call roll over, out bound call rollover, Join across lines (JAL) and Direct Transfer Across Lines (DTAL) capability of the terminal. A terminal can have different capability when feature is invoked on the phone and when feature is invoked by application. It does not indicate if the entire configuration required for the feature is enabled (for example, Join softkey must be configured in the template for the feature). • Get registered state of the terminal 7.1.(3) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 617 Cisco Unified JTAPI Extensions Related Documentation

Description Cisco Unified Communications Manager Release Number Added the following new APIs: • APIs pickup(Address pickingAddress) groupPickup(Address pickingAddress • String pickupGroupNumber) • directedPickup(Address pickingAddress, String pickupGroupNumber), • Pickup(Address pickingAddress) for picking up calls from different flavors of Call Pickup Groups. • API getLoginType () which returns the LoginType on the terminal. 8.0(1) A new API, isBuiltInBridgeEnabled(). is added. 8.5(1) A new interface, public interface CiscoTerminal, is added on CiscoTerminal to determine the multimedia capabilities of the terminal. 10.0(1) Added getHuntLogStatus() throwsInvalidStateException and setHuntLogStatus(int huntLogStatus)throws InvalidStateException,MethodNotSupportedException, methods. 11.5(1) Sample Code public class MyTerminalObserver implements TerminalObserver { public void terminalChangedEvent (TermEv[] evlist) { for(int i = 0; evlist ! = null && i < evlist.length; i++) { … if ( evlist[i] instance of TermInServiceEv) { CiscoTerminal term

(CiscoTerminal) (((CiscoTermEv)evlist[i] ).getTerminal()); if(!term instanceof CiscoMediaTerminal && ! term instanmceof CiscoRouteterminal) { try { if ( term. isBuiltInBridgeEnabled()) { System.out.println("Build in Bridge is enabled for terminal" + tern.getName()); else { System.out.println("Build in Bridge is disabled for terminal" + tern.getName()); } } catch(Exception) { System.out.println("Exception caught"); } } Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 618 Cisco Unified JTAPI Extensions CiscoTerminal

} } } } Superinterfaces CiscoObjectContainer, javax.telephony.Terminal Subinterfaces CiscoMediaTerminal, CiscoRouteTerminal Declaration public interface CiscoTerminal extends javax.telephony.Terminal, CiscoObjectContainer Fields Table 235: Fields in CiscoTerminal Description Field Interface This constant depicts that the terminal is logged into the hunt group. DEVICE_HUNT_LOGGED_IN static final int This constant depicts that the terminal is logged out of the hunt group. DEVICE_HUNT_LOGGED_OUT static final int This constant depicts that the terminal does not have the capability either to log in or log out of the hunt group. DEVICE_HUNT_NOT_APPLICABLE static final int This Constant Field Values, on page 1667 returned by the getState() interface on CiscoTerminal indicates that the CiscoTerminal is out of service. OUT_OF_SERVICE static final int This constant value returned by the getState() interface on CiscoTerminal indicates that the CiscoTerminal is in service. IN_SERVICE static final int This constant value returned by the getDeviceState() interface on CiscoTerminal indicates that the CiscoTerminal currently has no calls on any Addresses. DEVICESTATE_IDLE static final int This constant value returned by the getDeviceState() interface on CiscoTerminal indicates that the CiscoTerminal has at least one active call on an Address. DEVICESTATE_ACTIVE static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 619 Cisco Unified JTAPI Extensions Superinterfaces

Description Field Interface This constant value returned by the getDeviceState() interface on CiscoTerminal indicates that the CiscoTerminal has at least one alerting call, but no active call, on an Address. DEVICESTATE_ALERTING static final int This constant value returned by the getDeviceState() interface on CiscoTerminal indicates that the CiscoTerminal has at least one held call, but no alerting or active calls, on an Address. DEVICESTATE_HELD static final int This constant value returned by the getDeviceState() interface on CiscoTerminal indicates that the CiscoTerminal DeviceState is Unknown. This state may get returned if the device state filters are disabled. DEVICESTATE_UNKNOWN static final int This constant value returned by the getDeviceState() interface on CiscoTerminal indicates that the CiscoTerminal has at least one intercom call with one-way media, but has no held, alerting, or active calls on an Address. DEVICESTATE_WHISPER static final int Indicates that the CiscoTerminal.getSupportedEncoding () for this terminal is UNKNOWN. UNKNOWN_ENCODING static final int Indicates that the CiscoTerminal.getSupportedEncoding () for this CiscoMediaTerminal or RoutePoint is NOT_APPLICABLE. NOT_APPLICABLE static final int Indicates that the CiscoTerminal.getSupportedEncoding () for this terminal is ASCII and that this terminal supports only ASCII_ENCODING. ASCII_ENCODING static final int Indicates that the CiscoTerminal.getSupportedEncoding () for this terminal is UCS2UNICODE_ENCODING. UCS2UNICODE_ENCODING static final int This constant value returned by the getDNDOption() interface on CiscoTerminal indicates that the DND option configured is None. DND_OPTION_NONE static final int This constant value returned by the getDNDOption() interface on CiscoTerminal indicates that the DND option configured is Ringer Off. If DND is enabled on the phone, the phone would not ring if a call lands there. DND_OPTION_RINGER_OFF static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 620 Cisco Unified JTAPI Extensions Fields

Description Field Interface This constant value returned by the getDNDOptions() interface on CiscoTerminal indicates that the DND option configured is Call Reject. If DND is enabled on the phone, all calls to the phone will get rejected, except for shared lines. DND_OPTION_CALL_REJECT static final int This indicates that IPAddressing mode is Unknown. IP_ADDRESSING_MODE_UNKNOWN static final int This indicates that IPAddressing mode is IPv4 IP_ADDRESSING_MODE_IPV4 static final int This indicates that IPAddressing mode is IPv6 IP_ADDRESSING_MODE_IPV6 static final int This indicates that IPAddressing mode is both IPv4 and IPv6 IP_ADDRESSING_MODE_IPV4_V6 static final int This is reserved IP Addressing constant for ANAT in Cisco Unified Communications Manager. It is not used in JTAPI IP_ADDRESSING_MODE_UNKNOWN_ANATRED static final int Methods Table 236: Methods in CiscoTerminal Description Method Inteface This method returns the value NO_EM_LOGIN, NATIVE_LOGIN or VISITOR_LOGIN to indicate whether the terminal is local to the cluster or not when the EM login is done. getLoginType() int This indicates that there has been no EM login done into the terminal. It will have an integer value of 0. CiscoTerminal.NO_LOGIN Static final int This indicates that the terminal is part of the local cluster when an EM login is done into it with a profile that belongs to the same cluster. It will have an inteher value of 1. CiscoTerminal.NATIVE_LOGIN This indicates that the terminal is part of the visiting cluster when an EM login is done into it with a profile that is not local to the cluster. It will have an integer value of 2. CiscoTerminal.VISITOR_LOGIN Deprecated This method has been replaced by the getState() method. Returns the state of this terminal. The state may be any of the following constants: • CiscoTerminal.OUT_OF_SERVICE • CiscoTerminal.IN_SERVICE getRegistrationState() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 621 Cisco Unified JTAPI Extensions Methods

Description Method Inteface Returns the state of this terminal. The state may be any of the following constants: • CiscoTerminal.OUT_OF_SERVICE • CiscoTerminal.IN_SERVICE getState() int Returns the properties to be used for the RTP input stream associated with the ACTIVE TerminalConnection on this terminal. The CiscoTerminal must be in the CiscoTerminal.REGISTERED state, its Provider must be in the Provider.IN_SERVICE state, and Terminal.getTerminalConnections () must return at least one terminal connection in the TerminalConnection.ACTIVE state. Throws javax.telephony.InvalidStateException getRTPInputProperties() CiscoRTPInputProperties Returns the properties to be used for the RTP output stream associated with the ACTIVE TerminalConnection on this terminal. The CiscoTerminal must be in the CiscoTerminal.REGISTERED state, its Provider must be in the Provider.IN_SERVICE state, and Terminal.getTerminalConnections () must return at least one terminal connection in the TerminalConnection.ACTIVE state. Throws javax.telephony.InvalidStateException getRTPOutputProperties() CiscoRTPOutputProperties Deprecated Use CiscoTerminal.sendData ( byte[] ). Throws javax.telephony.InvalidStateException javax.telephony.MethodNotSupportedException sendData(java.lang. StringterminalData) java.lang.String The CiscoTerminal must be in the CiscoTerminal.IN_SERVICE state, and its Provider must be in the Provider.IN_SERVICE state. Applications can push the XSI object in the byte format to the phone with this interface. If the phone receives the data, this method returns successfully. Applications may only send 2000 bytes of data with this interface. Requests carrying excess data get rejected. Throws PlatformException (The data did not get sent successfully), javax.telephony.InvalidStateException, and javax.telephony.MethodNotSupportedException sendData(byte[]terminalData) byte[] Retrieves the filter object associated with the terminal. getFilter() CiscoTermEvFilter Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 622 Cisco Unified JTAPI Extensions Methods

Description Method Inteface Filters the events that get delivered to the TerminalObserver. You can call this method at any time, but the typical usage is to set up the terminal events as part of initialization or when a CiscTermCreatedEv indicates that the system created a new terminal. • Example 1—One use might be to turn on the button-pressed events that normally do not get not delivered. Terminal term = provider.getTerminal ( name ); if ( term instanceof CiscoTerm ) { CiscoTerm ciscoTerm = (CiscoTerm)term; CiscoTermEvFilter filter = ciscoTerm.getFilter (); filter.setButtonPressedEnabled ( true ); } term.addObserver ( terminalObserver ) • Example 2—Another use might be turning off events that are not of interest to an application. For example, an application doing pure call control could turn off the media (RTP) events as follows: Terminal term = provider.getTerminal ( name ); if ( term instanceof CiscoTerm ) { CiscoTerm ciscoTerm = (CiscoTerm)term; CiscoTermEvFilter filter = ciscoTerm.getFilter (); filter.setRTPEventsEnabled ( false ); ciscoTerm.setFilter ( filter ); } term.addObserver ( terminalObserver ); term.getAddresses () [0].addCallObserver ( callObserver ) Note Adding a CallObserver (without explicitly setting a filter) turns the RTP events on. This behavior of Cisco JTAPI Release 1.4 and earlier is still preserved. If an explicit setFilter call gets made, the filter settings will take effect. The RTP events will not get delivered for the previous code snippet, but will get delivered for the following example: Terminal term = provider.getTerminal ( name ); term.addObserver ( terminalObserver ); term.getAddresses () [0].addCallObserver ( callObserver ). setFilter(CiscoTermEvFilter terminalEvFilter) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 623 Cisco Unified JTAPI Extensions Methods

Description Method Inteface Returns a terminalConnection. The CiscoTerminal must be in the CiscoTerminal.IN_SERVICE state and its Provider must be in the Provider.IN_SERVICE state. This method takes an address and string as input. Parameters • UnParkAddress - Any address on the terminal • ParkedAt - A string identifying is system park port where a call was previously parked. The system returns this string when the call gets parked. Throws • javax.telephony.InvalidStateException (The CiscoTerminal.getState() is not IN_SERVICE) • PlatformException - Any other error occurred while unparking (for example, the Unpark number is not valid). • javax.telephony.InvalidArgumentException • javax.telephony.ResourceUnavailableException unPark(javax.telephony.Address UnParkAddress, java.lang.StringParkedAt) javax.telephony.TerminalConnection • Returns the DeviceState of this terminal. The DeviceState is the accumulative call state of all the addresses on the terminal. The state may be any of the following constants: • CiscoTerminal.DEVICESTATE_ILDE • CiscoTerminal.DEVICESTATE_ACTIVE • CiscoTerminal.DEVICESTATE_ALERTING • CiscoTerminal.DEVICESTATE_HELD • CiscoTerminal.DEVICESTATE_UNKNOWN • CiscoTerminal.DEVICESTATE_WHISPER Throws • javax.telephony.InvalidStateException —CiscoTerminal.getState() is not IN_SERVICE. getDeviceState() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 624 Cisco Unified JTAPI Extensions Methods

Description Method Inteface Returns the supported encoding types for this terminal. Use this method to check whether a terminal supports Unicode. To access this information, the terminal must be in the CiscoTerminal.IN_SERVICE state. The supportedEncoding is one of the following constants: • CiscoTerminal.UNKNOWN_ENCODING • CiscoTerminal.ASCII_ENCODING • CiscoTerminal.UCS2UNICODE_ENCODING • CiscoTerminal.NOT_APPLICABLE Throws • javax.telephony.InvalidStateException getSupportedEncoding() int Returns the locale that this terminal supports. To access this method, the terminal must be in the CiscoTerminal.IN_SERVICE state. Throws • javax.telephony.InvalidStateException —CiscoTerminal.getState() is not IN_SERVICE. getLocale() int Returns the restriction status of this terminal. If a terminal is restricted, all associated addresses on the terminal are also restricted. Returns:True if terminal is restricted; otherwise false. isRestricted() boolean Generates a CiscoTermSnapshotEv event, which contains the security status of the current active call on the terminal. To access this method, the terminal must be in the CiscoTerminal.IN_SERVICE state and CiscoTermEvFilter.setSnapshotEnabled () must be set to true. Throws • javax.telephony.InvalidStateException —CiscoTerminal.getState() is not IN_SERVICE. createSnapshot() void Returns the locale alternate script that this terminal supports. An empty return value indicates that this terminal does not support or is not configured with an alternate script. To access this method, the terminal must be in the CiscoTerminal.IN_SERVICE state. Throws • javax.telephony.InvalidStateException —CiscoTerminal.getState() is not IN_SERVICE. getAltScript() java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 625 Cisco Unified JTAPI Extensions Methods

Description Method Inteface Reports the terminal protocol (SCCP, SIP, or none) and returns the protocol of this terminal as one of the following constants: • CiscoTerminalProtocol.PROTOCOL_NONE • CiscoTerminalProtocol.PROTOCOL_SCCP • CiscoTerminalProtocol.PROTOCOL_SIP getProtocol() int Sets the DND status, which enables or disables the DND feature. This feature does not apply to route points. Parameters • dndStatus Throws • javax.telephony.InvalidStateException —CiscoTerminal.getState() is not IN_SERVICE. setDNDStatus(booleandndStatus) void Reports the DND status and returns dndStatus. Throws • javax.telephony.InvalidStateException —CiscoTerminal.getState() is not IN_SERVICE. getDNDStatus() boolean Returns the value of the DND option. This value is not significant for a CiscoMediaTerminal or CiscoRouteTerminal because the DND feature applies only to physical phones. The DND option can be any of the following constants: • CiscoTerminal.DND_OPTION_NONE • CiscoTerminal.DND_OPTION_RINGER_OFF • CiscoTerminal.DND_OPTION_CALL_REJECT Throws • javax.telephony.InvalidStateException —CiscoTerminal.getState() is not IN_SERVICE. getDNDOption() int Returns extension mobility (EM) login user name. If no EM user has logged into Terminal, this interface will return null/empty string Throws • javax.telephony.InvalidStateException —if CiscoTerminal.getState() is not IN_SERVICE. Note You must use this API with CiscoTerminal.getLoginType() to determine if an EM login is done. getEMLoginUsername() java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 626 Cisco Unified JTAPI Extensions Methods

Description Method Inteface Returns IPV4 ip address of the terminal Throws • InvalidStateException • MethodNotSupportedException getIPV4Address() InetAddress Returns IPV6 ip address of the terminal Throws • InvalidStateException • MethodNotSupportedException getIPV6Address() InetAddress This method picks up the longest ringing call from the Pickup Group to which pickingAddress belongs to. pickingAddress is the Address on the Terminal where the Call is picked up. Parameters pickingAddress that specifies which Address the Terminal object should do the pickup on. pickup (Address pickingAddress) Call This method picks up the longest ringing call from the specified pickupGroupNumber at the pickingAddress. Parameters • pickingAddress that specifies which Address the Terminal object should do the pickup on. • Additional String object that respresents the number of the pickup group you wish to answer a call from, as set in the CUCM. groupPickup(Address pickingAddress, String pickupGroupNumber) Call This method picks up the call from the specified ringingDN at the pickingAddress. The ringingDN must be in the same Pickup Group as the pickingAddress. Parameters • pickingAddress that specifies which Address the Terminal object should do the pickup on. • Additional String object that respresents the specific DN the application wishes to pick up for a directed call pickup request. directedPickup(Address pickingAddress, String ringingDN) Call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 627 Cisco Unified JTAPI Extensions Methods

Description Method Inteface This method picks up a call based upon the priority of the associated pickupgroups. Within the group, if there are more than one call, the longest ringing call will be picked up. pickingAddress is the Address on the Terminal where the Call is picked up. Parameters pickingAddress that specifies which Address the Terminal object should do the pickup on. otherPickup(Address pickingAddress) Call Returns the roll over configuration of the terminal. Throws • InvalidStateException. getRollOverConfig() int This indicates that the terminal is configured with no roll over. NO_ROLLOVER public final static int This indicates that calls can roll over to any address on the terminal. ROLLOVER_ANY_DN public final static int This indicates that calls can roll over to address that match the name(DN). ROLLOVER_SAME_DN public final static int Application can use this to find the capability of the terminal when used manually by user. PHONE_USER public static final int Application can use to this to find the capability of the terminal to invoke the feature from application. APPLICATION publis static final int Which user can be CiscoTerminal. PHONE_USER or CiscoTerminal.APPLICATION Throws • InvalidStateException. canConsultCallRollOver(int which_user) boolean • InvalidStateException. canOutBoundCallRollOver(int which_user) boolean This interface returns True if calls on different addresses of this terminal can be conferenced. This interface returns True for terminals that support Connected Transfer or Conference Across Lines. Throws • InvalidStateException. canJoinAcrossLines(int which_user) boolean Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 628 Cisco Unified JTAPI Extensions Methods

Description Method Inteface This interface returns True if calls on different addresses of this terminal can be transferred. This interface returns True for terminals that support Connected Transfer or Conference Across Lines. Throws • InvalidStateException. canDirectTransferAcrossLines(int which_user) boolean Throws • InvalidStateException. canJoinOnSameLine (int which_user) boolean Throws • InvalidStateException. canDirectTransferOnSameLine(int which_user) boolean Returns true if terminal is registered with Cisco Unified Communications Manager else false. isRegistered() boolean Returns true if Built-In-Bridge is enabled on the terminal, else returns false. isBuiltInBridgeEnabled() public boolean This method registers Cisco Unified Client Services Framework device to Extend mode, which will be represented as a CiscoRemoteTerminal. This is intended to be used by application monitoring Cisco Unified Client Services Framework device to enable its Extend mode from its softphone (SIP)/deskphone mode. The successful effect of this method is to register the device and present as a CiscoRemoteTerminal terminal type (if it is not already a CiscoRemoteTerminal), and be able to use Cisco Extend & Connect (CTI Remote Device) supported features with remote destinations. In any case when it switches in between Softphone/Deskphone & Extend modes that results in a terminal switching (e.g. CiscoTerminal->CiscoRemoteTerminal), there will be provider events sent to application: CiscoAddrRemovedEv, CiscoTermRemovedEv, CiscoAddrCreatedEv, CiscoTermCreatedEv. Any observers on the terminal and address will be removed, application needs to de-reference the old terminal object and re-add any desired observers. Note that CiscoProvider must be in IN_SERVICE state, otherwise CiscoRegistrationException about InvalidStateException will be thrown; or if terminal is already registered by this application in Extend mode or the registration fails for any reason, CiscoRegistrationException will be thrown. And if terminal type is not CiscoTerminal or CiscoRemoteTerminal and if terminal is not a Cisco Unified Client Services Framework device, then MethodNotSupportedException will be thrown. register() void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 629 Cisco Unified JTAPI Extensions Methods

Description Method Inteface This method unregisters Cisco Unified Client Services Framework device from Extend mode. Its terminal type will remain as CiscoRemoteTerminal, and application can explicitly register to CUCM to switch back to its softphone/deskphone mode. This is intended to be used by application monitoring Cisco Unified Client Services Framework device in Cisco Extend Connect mode to disable its Cisco Extend Connect mode. The successful effect of this method is to unregister the device but retains as a CiscoRemoteTerminal. Note that CiscoProvider must be in IN_SERVICE state, otherwise CiscoUnregistrationException about InvalidStateException will be thrown; or if terminal is not registered in Extend mode by this application or the unregistration fails for any reason, CiscoUnregistrationException will be thrown. And if terminal type is not CiscoRemoteTerminal and if terminal is not a Cisco Unified Client Services Framework device, then MethodNotSupportedException will be thrown. unregister() void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 630 Cisco Unified JTAPI Extensions Methods

Description Method Inteface This method returns the device type of Terminal, which can be one of the following contants. It will return CiscoTerminal.DEVICETYPE_UNKNOWN if type of device cannot be found or device is invalid. CiscoTerminal.DEVICETYPE_UNKNOWN CiscoTerminal.DEVICETYPE_ANALOG_PHONE CiscoTerminal.DEVICETYPE_CISCO_6901 CiscoTerminal.DEVICETYPE_CISCO_6911 CiscoTerminal.DEVICETYPE_CISCO_6921 CiscoTerminal.DEVICETYPE_CISCO_6941 CiscoTerminal.DEVICETYPE_CISCO_6945 CiscoTerminal.DEVICETYPE_CISCO_6961 CiscoTerminal.DEVICETYPE_CISCO_7906 CiscoTerminal.DEVICETYPE_TELECASTER_BID CiscoTerminal.DEVICETYPE_CISCO_7911 CiscoTerminal.DEVICETYPE_14 _BUTTON_SIDECAR CiscoTerminal.DEVICETYPE_7915_12 _BUTTON_SIDECAR CiscoTerminal.DEVICETYPE_7915_24 _BUTTON_SIDECAR CiscoTerminal.DEVICETYPE_7916_12 _BUTTON_SIDECAR CiscoTerminal.DEVICETYPE_7916_24 _BUTTON_SIDECAR CiscoTerminal.DEVICETYPE_CKEM_36_BUTTON CiscoTerminal.DEVICETYPE_CP7921 CiscoTerminal.DEVICETYPE_CISCO_7925 CiscoTerminal.DEVICETYPE_CISCO_7926 CiscoTerminal.DEVICETYPE_7931 getType() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 631 Cisco Unified JTAPI Extensions Methods

Description Method Inteface CiscoTerminal.DEVICETYPE_IP_ CONFERENCE_PHONE CiscoTerminal.DEVICETYPE_CISCO_7936 CiscoTerminal.DEVICETYPE_CISCO_7937 CiscoTerminal.DEVICETYPE _TELECASTER_BUSINESS CiscoTerminal.DEVICETYPE_CISCO_7941 CiscoTerminal.DEVICETYPE_CISCO_7941G_GE CiscoTerminal.DEVICETYPE_CISCO_7942 CiscoTerminal.DEVICETYPE_CISCO_7945 CiscoTerminal.DEVICETYPE_TELECASTER_MGR CiscoTerminal.DEVICETYPE_CISCO_7961 CiscoTerminal.DEVICETYPE_CISCO_7961G_GE CiscoTerminal.DEVICETYPE_CISCO_7962 CiscoTerminal.DEVICETYPE_CISCO_7965 CiscoTerminal.DEVICETYPE_CISCO_7970 CiscoTerminal.DEVICETYPE_CISCO_7971 CiscoTerminal.DEVICETYPE_CISCO_7975 CiscoTerminal.DEVICETYPE_CISCO_7989 CiscoTerminal.DEVICETYPE_CISCO_8941 CiscoTerminal.DEVICETYPE_CISCO_8945 CiscoTerminal.DEVICETYPE_CISCO_8961 CiscoTerminal.DEVICETYPE_9951 CiscoTerminal.DEVICETYPE_CISCO_9971 CiscoTerminal.DEVICETYPE_ATA_186 CiscoTerminal.DEVICETYPE_CISCO_ATA_187 CiscoTerminal.DEVICETYPE_CISCO_CIUS CiscoTerminal.DEVICETYPE_CISCO_CIUS_SP CiscoTerminal.DEVICETYPE_CISCO _SOFTPHONE_SE_M CiscoTerminal.DEVICETYPE_CISCO_UNIFIED _COMMUNICATOR CiscoTerminal.DEVICETYPE_CISCO_UNIFIED _MOBILE_COMMUNICATOR CiscoTerminal.DEVICETYPE_CISCO_UNIFIED _COMMUNICATIONS_FOR_RTX Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 632 Cisco Unified JTAPI Extensions Methods

Description Method Inteface CiscoTerminal.DEVICETYPE_CLIENT _SERVICES_FRAMEWORK CiscoTerminal.DEVICETYPE_VGC_PHONE CiscoTerminal.DEVICETYPE_CTI_PORT CiscoTerminal.DEVICETYPE_CTI_ROUTE_POINT CiscoTerminal.DEVICETYPE_DEVICE_PILOT CiscoTerminal.DEVICETYPE_ISDN_BRI_PHONE CiscoTerminal.DEVICETYPE_CTI_REMOTE_DEVICE This method returns the device type name of Terminal (i.e. The display name of the device type). It will return an empty string if device type name cannot be found, or return null if device is invalid. getTypeName() String Returns CiscoMultiMediaCapabilityInfo, to indicate the multimedia capabilities of the terminal. getCiscoMultiMediaCapabilityInfo() CiscoTerminal This method is used get the value of huntlogstatus of the terminal, it returns either CiscoTerminal.DEVICE_HUNT_LOGGED_IN,CiscoTerminal.DEVICE_HUNT_LOGGED_OUT or CiscoTerminal. DEVICE_HUNT_NOT_APPLICABLE This method throws InvalidStateException if it is invoked on the terminal which is out of service getHuntLogStatus() throws InvalidStateException int This method is used set the value of huntLogStatus of the device, it can take CiscoTerminal.DEVICE_HUNT_LOGGED_IN,CiscoTerminal.DEVICE_HUNT_LOGGED_OUT values as parameters. This method throws InvalidStateException if it is invoked on the terminal which is out of service. It throws MethodNotSupportedException when it is invoked on unsupported devices like CTI Route Points, CTI Remote Device and Spark Remote Device and InvalidArgumentException when the arguments are other than 1(loggen_in) and 2(logged_out) setHuntLogStatus(int huntLogStatus) throws InvalidStateException, MethodNotSupportedException, InvalidArgumentException void Inherited Fields From Interface javax.telephony.Terminal addCallObserver, addObserver, getAddresses, getCallObservers, getCapabilities, getName, getObservers, getProvider, getTerminalCapabilities, getTerminalConnections, removeCallObserver, removeObserver Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 633 Cisco Unified JTAPI Extensions Inherited Fields

From Interface com.cisco.jtapi.extensions.CiscoObjectContainer Data Type public static final int CiscoTerminal.DEVICETYPE_UNKNOWN = 0 CiscoTerminal.DEVICETYPE_ANALOG_PHONE = 30027 CiscoTerminal.DEVICETYPE_12S = 4 CiscoTerminal.DEVICETYPE_CISCO_6901 = 547 CiscoTerminal.DEVICETYPE_CISCO_6911 = 548 CiscoTerminal.DEVICETYPE_CISCO_6921 = 495 CiscoTerminal.DEVICETYPE_CISCO_6941 = 496 CiscoTerminal.DEVICETYPE_CISCO_6945 = 564 CiscoTerminal.DEVICETYPE_CISCO_6961 = 497 CiscoTerminal.DEVICETYPE_CISCO_7906 = 369 CiscoTerminal.DEVICETYPE_TELECASTER_BID = 6 CiscoTerminal.DEVICETYPE_CISCO_7911 = 307 CiscoTerminal.DEVICETYPE_14_BUTTON_SIDECAR = 124 CiscoTerminal.DEVICETYPE_7915_12_BUTTON_SIDECAR = 227 CiscoTerminal.DEVICETYPE_7915_24_BUTTON_SIDECAR = 228 CiscoTerminal.DEVICETYPE_7916_12_BUTTON_SIDECAR = 229 CiscoTerminal.DEVICETYPE_7916_24_BUTTON_SIDECAR = 230 CiscoTerminal.DEVICETYPE_CKEM_36_BUTTON = 232 CiscoTerminal.DEVICETYPE_CP7921 = 365 CiscoTerminal.DEVICETYPE_CISCO_7925 = 484 CiscoTerminal.DEVICETYPE_CISCO_7926 = 577 CiscoTerminal.DEVICETYPE_7931 = 348 CiscoTerminal.DEVICETYPE_IP_CONFERENCE_PHONE = 9 CiscoTerminal.DEVICETYPE_CISCO_7936 = 30019 CiscoTerminal.DEVICETYPE_CISCO_7937 = 431 CiscoTerminal.DEVICETYPE_TELECASTER_BUSINESS = 8 CiscoTerminal.DEVICETYPE_CISCO_7941 = 115 CiscoTerminal.DEVICETYPE_CISCO_7941G_GE = 309 CiscoTerminal.DEVICETYPE_CISCO_7942 = 434 CiscoTerminal.DEVICETYPE_CISCO_7945 = 435 CiscoTerminal.DEVICETYPE_TELECASTER_MGR = 7 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 634 Cisco Unified JTAPI Extensions Data Type

CiscoTerminal.DEVICETYPE_CISCO_7961 = 30018 CiscoTerminal.DEVICETYPE_CISCO_7961G_GE = 308 CiscoTerminal.DEVICETYPE_CISCO_7962 = 404 CiscoTerminal.DEVICETYPE_CISCO_7965 = 436 CiscoTerminal.DEVICETYPE_CISCO_7970 = 30006 CiscoTerminal.DEVICETYPE_CISCO_7971 = 119 CiscoTerminal.DEVICETYPE_CISCO_7975 = 437 CiscoTerminal.DEVICETYPE_CISCO_7989 = 302 CiscoTerminal.DEVICETYPE_CISCO_8941 = 586 CiscoTerminal.DEVICETYPE_CISCO_8945 = 585 CiscoTerminal.DEVICETYPE_CISCO_8961 = 540 CiscoTerminal.DEVICETYPE_9951 = 537 CiscoTerminal.DEVICETYPE_CISCO_9971 = 493 CiscoTerminal.DEVICETYPE_ATA_186 = 12 CiscoTerminal.DEVICETYPE_CISCO_ATA_187 = 550 CiscoTerminal.DEVICETYPE_CISCO_CIUS = 593 CiscoTerminal.DEVICETYPE_CISCO_CIUS_SP = 632 CiscoTerminal.DEVICETYPE_CISCO_SOFTPHONE_SE_M = 30016 CiscoTerminal.DEVICETYPE_CISCO_UNIFIED_COMMUNICATOR = 358 CiscoTerminal.DEVICETYPE_CISCO_UNIFIED_MOBILE_COMMUNICATOR = 468 CiscoTerminal.DEVICETYPE_CISCO_UNIFIED_COMMUNICATIONS_FOR_RTX = 648 CiscoTerminal.DEVICETYPE_CLIENT_SERVICES_FRAMEWORK = 503 CiscoTerminal.DEVICETYPE_VGC_PHONE = 10 CiscoTerminal.DEVICETYPE_CTI_PORT = 72 CiscoTerminal.DEVICETYPE_CTI_ROUTE_POINT = 73 CiscoTerminal.DEVICETYPE_DEVICE_PILOT = 71 CiscoTerminal.DEVICETYPE_ISDN_BRI_PHONE = 30028 CiscoTerminal.DEVICETYPE_CTI_REMOTE_DEVICE = 635 Related Documentation See Terminal, CiscoMediaTerminal, Constant Field Values, on page 1667, and CiscoTermEvFilter. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 635 Cisco Unified JTAPI Extensions Related Documentation

CiscoTerminalConnection The CiscoTerminalConnection interface extends the CallControlTerminalConnection interface with additional capabilities. Applications can use the getReason method to obtain the reason for the creation of this Connection. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Two new methods, addMediaStream(String streamDN, String callingPartyNumber) and removeMediaStream(), are added. 8.5(1) A new API, playtone(int toneType, int playToneDirection) is added. A new method, startRecording(int playToneDirection, int recordingInvocationType), is added. Two new constants, RECORDING_INVOCATION_TYPE_SILENT, and RECORDING_INVOCATION_TYPE_USER, are added. 9.0(1) A new method, hold (String contentID) is added. 10.0(1) Superinterfaces javax.telephony.callcontrol.CallControlTerminalConnection, CiscoObjectContainer, javax.telephony.TerminalConnection Declaration public interface CiscoTerminalConnection extends javax.telephony.callcontrol.CallControlTerminalConnection, CiscoObjectContainer Fields Table 237: Fields in CiscoTerminalConnection Description Field Interface The the call is not selected. CISCO_SELECTEDNONE static final int The call is selected. CISCO_SELECTEDLOCAL static final int A passive TerminalConnection receives this select status if the call is selected by its shared line. CISCO_SELECTEDREMOTE static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 636 Cisco Unified JTAPI Extensions CiscoTerminalConnection

Description Field Interface This constant is used when the application invokes silent recording invocation type. The call recording status is not reflected on the Cisco IP device display. Silent recording is the default behavior in releases prior to Release 9.0. If an application uses the startRecording(int playToneDirection) method that was introduced prior to Release 9.0, it will default to the RECORDING_INVOCATION_TYPE_SILENT invocation type. RECORDING_INVOCATION_TYPE_SILENT static int This constant is used when the application invokes user recording invocation type. The call recording status is reflected on the Cisco IP device display. Applications can query the device for this recording type. RECORDING_INVOCATION_TYPE_USER static int Inherited Fields From Interface javax.telephony.callcontrol.CallControlTerminalConnection BRIDGED, DROPPED, HELD, IDLE, INUSE, RINGING, TALKING, UNKNOWN From Interface javax.telephony.TerminalConnection ACTIVE, PASSIVE Parameters invocationType The invocationType parameter allows an application to specify a recording invocation type. The parameter is passed as one of the constants RECORDING_INVOCATION_TYPE_SILENT or RECORDING_INVOCATION_TYPE_USER. String contentID A String representing a specific video. Max 128 characters. New Error Codes CTIERR_ILLEGAL_CALLSTATE Occurs if the request is made on a TerminalConnection associated with an invalid call. The only valid state to invoke this request is ‘Connected’. JTAPI throws InvalidStateException with description as “Line is not in a legal state to invoke command.” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 637 Cisco Unified JTAPI Extensions Inherited Fields

CTIERR _CALL_DROPPED Occurs if the request is made on a TerminalConnection associated with an invalid call. JTAPI throws InvalidStateException with description as “Call is dropped”. CTIERR_BIB_NOT_CONFIGURED Occurs if the Built-In-Bridge (BIB) is not configured on the agent device. JTAPI throws ResourceUnavailableException with a description as “Built in bridge not configured”. CTIERR_RESOURCE_NOT_AVAILABLE Occurs if the Bulit-In-Bridge (BIB) cannot be allocated for the request. JTAPI throws ResourceUnavailableException with a description as “Resource Not Available”. CTIERR_MEDIA_CONNECTION_FAILED Occurs if the Bulit-In-Bridge (BIB) call fails to connect to the media. JTAPI throws InvalidStateException with a description as “The connection to the media has failed”. CTIERR_START_STREAM_MEDIA_FAILED Occurs if there is a general failure with the Agent Greeting feature, that is not covered by any of the other error codes. JTAPI throws InvalidStateException with a description as “Start streaming media request failed”. CTIERR_STOP_STREAM_MEDIA_FAILED Occurs if there is a general failure with the Agent Greeting feature, that is not covered by any of the other error codes. JTAPI throws InvalidStateException with a description as “Stop streaming media request failed”. CTIERR_REQUEST_ALREADY_PENDING Occurs if an application attempts to invoke an Agent Greeting API while another request is made. JTAPI throws InvalidStateException with a description as “The request was rejected because there is a similar request already pending”. CTIERR_NO_STREAMING_MEDIA_SESSION Occurs if an application attempts to invoke a stop request while there is no existing media stream to stop. JTAPI throws InvalidStateException with a description as “There is no streaming media session active”. CTIERR_EXISTING_STREAMING_MEDIA_SESSION Occurs if an application attempts to invoke an Agent Greeting API while another request is made and accepted. JTAPI throws InvalidStateException with a description as “There is an existing streaming media session”. CTIERR_RECORDING_INVOCATION_TYPE_NOT_MATCHING Occurs if an application attempts to stop an active recording, but specifies a recording type other than the recording type that was used to invoke the recording. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 638 Cisco Unified JTAPI Extensions New Error Codes

Methods Table 238: Methods in CiscoTerminalConnection Description Method Interface Returns the privacy status of the call on the terminal. This interface returns True if Privacy is on and False otherwise. Always check the TerminalConnection privacy status before displaying any information about the call at an applcation Terminal implementation. getPrivacyStatus() boolean Returns the select status of the call on the terminal. Always check the select status of the TerminalConnection before performing any call-process operation for the call. Can be one of: • CiscoTerminalConnection.CISCO_SELECTEDNONE • CiscoTerminalConnection.CISCO_SELECTEDLOCAL • CiscoTerminalConnection.CISCO_SELECTEDREMOTE getSelectStatus() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 639 Cisco Unified JTAPI Extensions Methods

Description Method Interface Starts recording a call. The system delivers CiscoTermConnRecordingStartEv and CiscoTermConnRecordingTargetInfoEv to the call observer when this method is successful. Pre-conditions • ((this.getTerminal()).getProvider()).getState() = = Provider.IN_SERVICE • this.getCallControlState() = = CallControlTerminalConnection.TALKING • ((CiscoProviderCapabilities) (this.getTerminal().getProvider(). getProviderCapabilities()).canRecord() = = TRUE • this.getConnection().getAddress(). getRecordingConfig(this.getTerminal()) = = CiscoAddress. APPLICATION_CONTROLLED__RECORDING Parameters • playToneDirection—Specifies whether to play a tone. Valid values are: • CiscoCall. PLAYTONE_NOLOCAL_OR_REMOTE • CiscoCall. PLAYTONE_LOCALONLY • CiscoCall. PLAYTONE_REMOTEONLY • CiscoCall.PLAYTONE_BOTHLOCALANDREMOTE Throws • javax.telephony. InvalidStateException—Either the Provider was not "in service" or the TerminalConnection is not in the "TALKING" state. • javax.telephony. PrivilegeViolationException—The application does not have the proper authority to invoke this method. • javax.telephony. ResourceUnavailableException—An internal resource that this method requires is not available. • javax.telephony. InvalidArgumentException—The value for playToneDirection is not valid. startRecording(intplayToneDirection) void This method is similar to the startRecording(int playToneDirection) method. startRecording(int playToneDirection, int invocationType) void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 640 Cisco Unified JTAPI Extensions Methods

Description Method Interface This method is similar to the stopRecording() method. If an application attempts to stop an active recording, but specifies a recording type other than the recording type that the recording was invoked with, the request fails and an exception with error code CTIERR_RECORDING_INVOCATION _TYPE_NOT_MATCHING is thrown. stopRecording(int invocationType) void Returns CiscoRecorderInfo, which exposes the terminal name and address of the recorder or null if the call is not being recorded. The call control terminal connection must be in the talking state. getCiscoRecorderInfo() CiscoRecorderInfo Returns CiscoMonitorInitiatorInfo or null if the call is not being monitored. The application can use this method on the terminal connection of the monitor target to get information about the monitor initiator or determine that there is no monitor session. getCiscoMonitorInitiatorInfo() CiscoMonitor InitiatorInfo Returns CiscoMonitorTargetInfo or null. The application can use this method on the terminal connection of the monitor initiator to get information about the monitor target. This method returns null when called on a terminal connection of the monitor target or if there is no monitor session. getCiscoMonitorTargetInfo() CiscoMonitor TargetInfo Sends a request to begin sending media to the TerminalConnection's associated Built-in-bridge (BIB). Parameters • String streamDN—Dialed Number (DN) for the IVR, CTI Port, or the device streaming the media to the call. • String callingPartyNumber—A string object that applications use to provide information to the IVR. This is subject to all the constraints of a DN, and is used to store the agent's DN. This is presented to the IVR as the calling party in the new call event. The IVR must have some application running that understands this information, and can only be retrieved from the new call event on the IVR. addMediaStream(String streamDN, String callingPartyNumber) void Sends a request to cease the playing of media to the TerminalConnection's associated BIB. removeMediaStream() void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 641 Cisco Unified JTAPI Extensions Methods

Description Method Interface Plays tones at local or remote ends of the call. Parameters • int tonetype—One of the tones defined in CiscoTone interface. • int playToneDirection—Can be CiscoCall.PLAYTONE_LOCALONLY or CiscoCall.PLAYTONE_REMOTEONLY. Throws • InvalidStateException • InvalidArgumentException • PlatformException playTone(int toneType, int playToneDirection) void This interface puts a call on hold, and specifies a contentID that can be used to play video on hold, or other related features. Note that CiscoProvider must be in IN_SERVICE state. Also, the call control state needs to be in TALKING state. If not, InvalidStateException will be thrown. If the hold request fails, ResourceUnavailableException will be thrown. All other errors encountered will result in PlatformException to be thrown. Parameters String contentID—A String representing a specific video. Max 128 characters. hold (String contentID) void Inherited Methods From Interface javax.telephony.callcontrol.CallControlTerminalConnection getCallControlState, hold, join, leave, unhold From Interface javax.telephony.TerminalConnection answer, getCapabilities, getConnection, getState, getTerminal, getTerminalConnectionCapabilities, getObject, setObject From Interface com.cisco.jtapi.extensions.CiscoObjectContainer Related Documentation See Constant Field Values, on page 1667. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 642 Cisco Unified JTAPI Extensions Inherited Methods

CiscoTerminalObserver Applications implement this interface to receive CiscoTermEv events such as CiscoRTPInputStartedEv and CiscoRTPInputStoppedEv when observing Terminals via the Terminal.addObserver method. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.TerminalObserver Declaration public interface CiscoTerminalObserver extends javax.telephony.TerminalObserver Fields None Methods None Inherited Methods From Interface javax.telephony.TerminalObserver terminalChangedEvent Related Documentation See CiscoTermInServiceEv, CiscoTermOutOfServiceEv, CiscoRTPInputStartedEv, CiscoRTPInputStoppedEv, CiscoRTPOutputStartedEv, and CiscoRTPOutputStoppedEv. CiscoTerminalProtocol The CiscoTerminalProtocol event is a container for the constants that define protocol types. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 643 Cisco Unified JTAPI Extensions CiscoTerminalObserver

Interface History Description Cisco Unified Communications Manager Release Added the extension. 3.x Superinterfaces public interface CiscoTerminalProtocol Fields Table 239: Fields in CiscoTerminalProtocol Description Field Interface This constant value returned by the getProtocol() interface on CiscoTerminal indicates that the protocol type for the CiscoTerminal is not known or not available. PROTOCOL_NONE static int This constant value returned by the getProtocol() interface on CiscoTerminal indicates that the protocol type for the CiscoTerminal is SCCP. PROTOCOL_SCCP static int This constant value returned by the getProtocol() interface on CiscoTerminal indicates that the protocol type for the CiscoTerminal is SIP. PROTOCOL_SIP static int This constant value returned by the getProtocol() interface on CiscoTerminal indicates that the protocol type for the CiscoTerminal is CTI Remote Device. PROTOCOL_CTI_REMOTE_DEVICE static int Related Documentation See also CiscoTerminal, Constant Field Values, on page 1667 for more information. CiscoTermInServiceEv The CiscoTermInServiceEv event gets sent to the application's TerminalObservers to indicate that the CiscoTerminal is ready for operation. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 644 Cisco Unified JTAPI Extensions Superinterfaces

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermInServiceEv extends CiscoTermEv Fields Table 240: Fields in CiscoTermInServiceEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 645 Cisco Unified JTAPI Extensions Superinterfaces

Methods Table 241: Methods in CiscoTermInServiceEv Description Method Interface Reports whether a terminal is UNICODE-capable by returning the supported encoding. The value of supported encoding may be any of the following constants: • CiscoTerminal.UNKNOWN_ENCODING • CiscoTerminal.ASCII_ENCODING • CiscoTerminal.UCS2UNICODE_ENCODING • CiscoTerminal.NOT_APPLICABLE Returns: An integer value for the supported encoding of this terminal. getSupportedEncoding() int Returns the locale that this Terminal supports. Returns int values defined in the CiscoLocales interface. getLocale() int Returns the current DND status to the application.Returns boolean dndStatus. getDNDStatus() boolean Returns the current DND option to the application. The DND option can be any of the following constants: • CiscoTerminal.DND_OPTION_NONE • CiscoTerminal.DND_OPTION_RINGER_OFF • CiscoTerminal.DND_OPTION_CALL_REJECT Returns int dndOption. getDNDOption() int Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667 and CiscoLocales Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 646 Cisco Unified JTAPI Extensions Methods

CiscoTermOutOfServiceEv The CiscoTermOutOfServiceEv event gets sent to the TerminalObservers of an application to indicate that the CiscoTerminal is out-of-service. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoOutOfServiceEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermOutOfServiceEv extends CiscoTermEv, CiscoOutOfServiceEv Fields Table 242: Fields in CiscoTermOutOfServiceEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 647 Cisco Unified JTAPI Extensions CiscoTermOutOfServiceEv

META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN, CAUSE_CALLMANAGER_FAILURE,CAUSE_CTIMANAGER_FAILURE,CAUSE_DEVICE_FAILURE, CAUSE_DEVICE_RESTRICTED, CAUSE_DEVICE_UNREGISTERED, CAUSE_LINE_RESTRICTED, CAUSE_NOCALLMANAGER_AVAILABLE, CAUSE_REHOME_TO_HIGHER_PRIORITY_CM, CAUSE_REHOMING_FAILURE From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface com.cisco.jtapi.extensions.CiscoOutOfServiceEv Methods None Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermRegistrationFailedEv Applications receive this event when TerminalRegistration fails at the provider. The error that getErrorCode() returns explains the problem. On receiving this event, the application should try to reregister the terminal. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 648 Cisco Unified JTAPI Extensions Methods

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) A new error code, CTI_SECURITY_NOT_ALLOWED, is added. 8.5(1) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermRegistrationFailedEv extends CiscoTermEv Fields Table 243: Fields in CiscoTermRegistrationFailedEv Description Field Interface None ID static final int Registration failed because the Terminal is already registered with a different media capability. Try reregistering with the same capability. MEDIA_CAPABILITY_MISMATCH static final int Registration failed because the Terminal is already registered with media termination type none. Try reregistering with Media termination type none. MEDIA_ALREADY_TERMINATED_NONE static final int Registration failed because the Terminal is already registered with static media termination. Static registration does not allow a second registration. Wait until the terminal unregisters. MEDIA_ALREADY_TERMINATED_STATIC static final int Registration failed because the Terminal is already registered with dynamic media termination. Try reregistering with dynamic media termination. MEDIA_ALREADY_TERMINATED_DYNAMIC static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 649 Cisco Unified JTAPI Extensions Superinterfaces

Description Field Interface Registration encountered a race condition while attempting to register the Terminal. Try registering the Terminal. OWNER_NOT_ALIVE static final int A database initialization error occurred while registering a Terminal. Try registering the Terminal. DB_INITIALIZATION_ERROR static final int Registration failed for an unknown internal reason. Try to reregister the Terminal. UNKNOWN static final int Registration failed due to unsupported IP Addressing mode Try to register the Terminal with correct IP Addressing Mode. IP_ADDRESSING_MODE_MISMATCH static final int The application registers a device in secured mode but eventually is rejected with the error code. CTI_SECURITY_NOT_ALLOWED public static Inherited Fields From Inteface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Inteface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 650 Cisco Unified JTAPI Extensions Inherited Fields

Methods Table 244: Methods in CiscoTermRegistrationFailedEv Description Method Interface Returns the error code for this exception, as an integer. getErrorCode() int Inherited Methods From Inteface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Inteface javax.telephony.events.TermEv getTerminal From Inteface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermRemovedEv The CiscoTermRemovedEv event gets sent to the provider observer of the application when a CiscoTerminal gets removed from the provider domain. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoTermRemovedEv extends CiscoProvEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 651 Cisco Unified JTAPI Extensions Methods

Fields Table 245: Fields in CiscoTermRemovedEv Field Interface ID static final int Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 246: Methods in CiscoTermRemovedEv Description Method Interface Returns the Terminal that was removed from the provider domain. getTerminal() javax.telephony.Terminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 652 Cisco Unified JTAPI Extensions Fields

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermRestrictedEv Applications see the CiscoTermRestrictedEv event when a user restricts a Terminal from Cisco Unified Communications Manager administration after the application starts running. Applications will not be able to see events for restricted Terminals, or for addresses on those terminals. If a Terminal gets restricted while it is in the in-service state, applications receive this event, and the Terminal and the corresponding addresses move to the out-of-service state. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoProvEv, javax.telephony.events.Ev, javax.telephony.events.ProvEv Declaration public interface CiscoTermRestrictedEv extends CiscoProvEv Fields Table 247: Fields in CiscoTermRestrictedEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 653 Cisco Unified JTAPI Extensions Related Documentation

META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 248: Methods in CiscoTermRestrictedEv Description Method Interface Returns the Terminal that has become restricted. getTerminal javax.telephony.Terminal Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.ProvEv getProvider From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See Constant Field Values, on page 1667. CiscoTermSnapshotCompletedEv If an application comes up after a call is established between two endpoints, for mid-call monitoring the application needs to query Terminal.createSnapshot(). After the call events for all of the Addresses on the Terminal get delivered, the application will get CiscoTermSnapshotCompletedEv. To maintain backward compatibility, these events get generated only when the application enables the snapShotRTPEnabled filter in CiscoTermEvFilter. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 654 Cisco Unified JTAPI Extensions Methods

Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermSnapshotCompletedEv extends CiscoTermEv Fields Table 249: Fields in CiscoTermSnapshotCompletedEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 655 Cisco Unified JTAPI Extensions Superinterfaces

Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See CiscoTermEvFilter and Constant Field Values, on page 1667. CiscoTermSnapshotEv If an application comes up after a call is established between two endpoints, for mid-call monitoring the application needs to query Terminal.createSnapshot(). The snapshot event, CiscoTermSnapshotEv, gets sent and indicates whether the current media between the endpoints is secure. Applications could also query CiscoMediaCallSecurityIndicator to get the security indicator for a call; however, this event does not contain any KeyMaterial. If there are no calls on any of the lines on the Terminal, applications will only get CiscoTermSnapshotCompletedEv. To maintain backward compatibility, these events get generated only when the application enables the snapShotRTPEnabled filter in CiscoTermEvFilter. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces CiscoEv, CiscoTermEv, javax.telephony.events.Ev, javax.telephony.events.TermEv Declaration public interface CiscoTermSnapshotEv extends CiscoTermEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 656 Cisco Unified JTAPI Extensions Inherited Methods

Fields Table 250: Fields in CiscoTermSnapshotEv Field Interface ID staticint Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 251: Methods in CiscoTermSnapshotEv Description Method Interface Returns the media security status for each active call on this device. getCiscoMediaCallSecurityIndicator() CiscoMediaCallSecurity Indicator[] Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.TermEv getTerminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 657 Cisco Unified JTAPI Extensions Fields

From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Related Documentation See CiscoTermEvFilter and Constant Field Values, on page 1667. CiscoTone The CiscoTone interface defines CTI Tone constant codes. CiscoToneChangedEv provides the getTone() method to return one of these constants. Only the ZIPZIP tone type is exposed to applications. Interface History Description Cisco Unified Communications Manager Release Number Added a new extension. 7.0(1) Enhanced to include the supported tones that are used as parameters for playTone() method. 8.5(1) Superinterfaces public interface CiscoTone Fields Table 252: Fields in CiscoTone Description Field Interface This interface defines the integer value for the ZIPZIP tone. The CiscoToneChangedEv.getTone() interface returns an integer value for tone. ZIPZIP Static int

ZIP public static final int

CALLWAITINGTONE public static final int See also CiscoToneChangedEv, Constant Field Values, on page 1667. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 658 Cisco Unified JTAPI Extensions Related Documentation

CiscoToneChangedEv The CiscoToneChangedEv event indicates that a tone has been generated for this call. The CallControlCallObserver interface reports this event. Currently, this tone gets generated only because of the Forced Authorization Code (FAC) or Client Matter Code (CMC) features. CiscoToneChangedEv.getCiscoCause() returns CiscoCallEv.CAUSE_FAC_CMC_FEATURE if the tone gets generated because of FAC_CMC. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoToneChangedEv extends CiscoCallEv Fields Table 253: Fields in CiscoToneChangedEv Description Field Interface None ID static final int Indicates that a FAC must be entered using Connection.addToAddress(String) to extend the call. This applies only for FAC_CMC_FEATURE_ID. FAC_REQUIRED static final int Indicates that a CMC must be entered using Connection.addToAddress(String) to extend the call. This applies only for FAC_CMC_FEATURE_ID. CMC_REQUIRED static final int Indicates that both a FAC and a CMC must be entered using Connection.addToAddress(String) to extend the call. The application can enter either one String code at a time or both at same time, separated by a # (pound sign) character. This applies only for FAC_CMC_FEATURE_ID. FAC_CMC_REQUIRED static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 659 Cisco Unified JTAPI Extensions CiscoToneChangedEv

CAUSE_ACCESSINFORMATIONDISCARDED , CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL,CAUSE_CHANUNACCEPTABLE,CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 660 Cisco Unified JTAPI Extensions Fields

CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY Inherited Fields From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface com.cisco.jtapi.extensions.CiscoCallEv Methods Table 254: Methods in CiscoToneChangedEv Description Method Interface Returns the generated tone type from CiscoTone. getTone() int Returns which codes are required for the dialed DN. The codeRequired may be one of the following: • CiscoToneChangedEv.FAC_REQUIRED • CiscoToneChangedEv.CMC_REQUIRED • CiscoToneChangedEv.FAC_CMC_REQUIRED getWhichCodeRequired() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 661 Cisco Unified JTAPI Extensions Inherited Fields

Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface com.cisco.jtapi.extensions.CiscoCallEv Related Documentation See Constant Field Values, on page 1667. CiscoTransferEndEv The CiscoTransferEndEv event indicates that a transfer operation has completed. This event gets reported via the CallControlCallObserver interface. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Superinterfaces javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoTransferEndEv extends CiscoCallEv Fields None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 662 Cisco Unified JTAPI Extensions Inherited Methods

Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCallEv CAUSE_ACCESSINFORMATIONDISCARDED, CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL, CAUSE_CHANUNACCEPTABLE, CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 663 Cisco Unified JTAPI Extensions Inherited Fields

CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Methods Table 255: Methods in CiscoTransferEndEv Description Method Interface Returns the call that has been transferred. This call is in the Call.INVALID state. getTransferredCall() javax.telephony.Call Returns the call that remains active after the transfer completes. getFinalCall() javax.telephony.Call Returns the ACTIVE TerminalConnection that currently acts as the transfer controller for the final call. When the transferController is a SharedLine, there will be multiple TerminalConnection objects. This method returns the ACTIVE TerminalConnection; however, if the application is not observing the ACTIVE TerminalConnection, this method will return one of the PASSIVE TerminalConnection objects. getTransferController() javax.telephony.TerminalConnection Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 664 Cisco Unified JTAPI Extensions Methods

Description Method Interface Returns the list of TerminalConnection objects that currently act as the transfer controller for the final call. When the transferController is not a SharedLine, there will be only one TerminalConnection in the list. This method returns null if there is no observer on the transfer controller. getTransferControllers() javax.telephony.TerminalConnection[] Returns the address that currently acts as the transfer controller for the final call. getTransferControllerAddress() javax.telephony.Address Returns true if the transfer is successful, or false otherwise. isSuccess() boolean Inherited Methods From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface com.cisco.jtapi.extensions.CiscoCallEv getCiscoCause, getCiscoFeatureReason Related Documentation See Constant Field Values, on page 1667 and getTransferControllers(). CiscoTransferStartEv The CiscoTransferStartEv event indicates that a transfer operation has started. This event gets reported via the CallControlCallObserver interface. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 665 Cisco Unified JTAPI Extensions Inherited Methods

Superinterfaces javax.telephony.events.CallEv, CiscoCallEv, CiscoEv, javax.telephony.events.Ev Declaration public interface CiscoTransferStartEv extends CiscoCallEv Fields Table 256: Fields in CiscoTransferStartEv Field Interface ID static final int Inherited Fields From Interface com.cisco.jtapi.extensions.CiscoCallEv CAUSE_ACCESSINFORMATIONDISCARDED, CAUSE_BARGE, CAUSE_BCBPRESENTLYAVAIL, CAUSE_BCNAUTHORIZED, CAUSE_BEARERCAPNIMPL, CAUSE_CALLBEINGDELIVERED, CAUSE_CALLIDINUSE, CAUSE_CALLMANAGER_FAILURE, CAUSE_CALLREJECTED, CAUSE_CALLSPLIT, CAUSE_CHANTYPENIMPL, CAUSE_CHANUNACCEPTABLE, CAUSE_CTICCMSIP400BADREQUEST, CAUSE_CTICCMSIP401UNAUTHORIZED, CAUSE_CTICCMSIP402PAYMENTREQUIRED, CAUSE_CTICCMSIP403FORBIDDEN, CAUSE_CTICCMSIP404NOTFOUND, CAUSE_CTICCMSIP405METHODNOTALLOWED, CAUSE_CTICCMSIP406NOTACCEPTABLE, CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED, CAUSE_CTICCMSIP408REQUESTTIMEOUT, CAUSE_CTICCMSIP410GONE, CAUSE_CTICCMSIP411LENGTHREQUIRED, CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG, CAUSE_CTICCMSIP414REQUESTURITOOLONG, CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE, CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME, CAUSE_CTICCMSIP420BADEXTENSION, CAUSE_CTICCMSIP421EXTENSTIONREQUIRED, CAUSE_CTICCMSIP423INTERVALTOOBRIEF, CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE, CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST, CAUSE_CTICCMSIP482LOOPDETECTED, CAUSE_CTICCMSIP483TOOMANYHOOPS, CAUSE_CTICCMSIP484ADDRESSINCOMPLETE, CAUSE_CTICCMSIP485AMBIGUOUS, CAUSE_CTICCMSIP486BUSYHERE, CAUSE_CTICCMSIP487REQUESTTERMINATED, CAUSE_CTICCMSIP488NOTACCEPTABLEHERE, CAUSE_CTICCMSIP491REQUESTPENDING, CAUSE_CTICCMSIP493UNDECIPHERABLE, CAUSE_CTICCMSIP500SERVERINTERNALERROR, CAUSE_CTICCMSIP501NOTIMPLEMENTED, CAUSE_CTICCMSIP502BADGATEWAY, CAUSE_CTICCMSIP503SERVICEUNAVAILABLE, CAUSE_CTICCMSIP504SERVERTIMEOUT, CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED, CAUSE_CTICCMSIP513MESSAGETOOLARGE, CAUSE_CTICCMSIP600BUSYEVERYWHERE, CAUSE_CTICCMSIP603DECLINE, CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE, CAUSE_CTICCMSIP606NOTACCEPTABLE, CAUSE_CTICONFERENCEFULL, CAUSE_CTIDEVICENOTPREEMPTABLE, CAUSE_CTIDROPCONFEREE, CAUSE_CTIMANAGER_FAILURE, CAUSE_CTIPRECEDENCECALLBLOCKED, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 666 Cisco Unified JTAPI Extensions Superinterfaces

CAUSE_CTIPRECEDENCELEVELEXCEEDED, CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH, CAUSE_CTIPREEMPTFORREUSE, CAUSE_CTIPREEMPTNOREUSE, CAUSE_DESTINATIONOUTOFORDER, CAUSE_DESTNUMMISSANDDCNOTSUB, CAUSE_DPARK, CAUSE_DPARK_REMINDER, CAUSE_DPARK_UNPARK, CAUSE_EXCHANGEROUTINGERROR, CAUSE_FAC_CMC, CAUSE_FACILITYREJECTED, CAUSE_IDENTIFIEDCHANDOESNOTEXIST, CAUSE_IENIMPL, CAUSE_INBOUNDBLINDTRANSFER, CAUSE_INBOUNDCONFERENCE, CAUSE_INBOUNDTRANSFER, CAUSE_INCOMINGCALLBARRED, CAUSE_INCOMPATABLEDDESTINATION, CAUSE_INTERWORKINGUNSPECIFIED, CAUSE_INVALIDCALLREFVALUE, CAUSE_INVALIDIECONTENTS, CAUSE_INVALIDMESSAGEUNSPECIFIED, CAUSE_INVALIDNUMBERFORMAT, CAUSE_INVALIDTRANSITNETSEL, CAUSE_MANDATORYIEMISSING, CAUSE_MSGNCOMPATABLEWCS, CAUSE_MSGTYPENCOMPATWCS, CAUSE_MSGTYPENIMPL, CAUSE_NETOUTOFORDER, CAUSE_NOANSWERFROMUSER, CAUSE_NOCALLSUSPENDED, CAUSE_NOCIRCAVAIL, CAUSE_NOERROR, CAUSE_NONSELECTEDUSERCLEARING, CAUSE_NORMALCALLCLEARING, CAUSE_NORMALUNSPECIFIED, CAUSE_NOROUTETODDESTINATION, CAUSE_NOROUTETOTRANSITNET, CAUSE_NOUSERRESPONDING, CAUSE_NUMBERCHANGED, CAUSE_ONLYRDIVEARERCAPAVAIL, CAUSE_OUTBOUNDCONFERENCE, CAUSE_OUTBOUNDTRANSFER, CAUSE_OUTOFBANDWIDTH, CAUSE_PROTOCOLERRORUNSPECIFIED, CAUSE_QSIG_PR, CAUSE_QUALOFSERVNAVAIL, CAUSE_QUIET_CLEAR, CAUSE_RECOVERYONTIMEREXPIRY, CAUSE_REDIRECTED, CAUSE_REQCALLIDHASBEENCLEARED,CAUSE_REQCIRCNAVIL,CAUSE_REQFACILITYNIMPL, CAUSE_REQFACILITYNOTSUBSCRIBED, CAUSE_RESOURCESNAVAIL, CAUSE_RESPONSETOSTATUSENQUIRY, CAUSE_SERVNOTAVAILUNSPECIFIED, CAUSE_SERVOPERATIONVIOLATED, CAUSE_SERVOROPTNAVAILORIMPL, CAUSE_SUBSCRIBERABSENT, CAUSE_SUSPCALLBUTNOTTHISONE, CAUSE_SWITCHINGEQUIPMENTCONGESTION, CAUSE_TEMPORARYFAILURE, CAUSE_UNALLOCATEDNUMBER, CAUSE_USERBUSY From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN From Interface javax.telephony.events.Ev CAUSE_CALL_CANCELLED, CAUSE_DEST_NOT_OBTAINABLE, CAUSE_INCOMPATIBLE_DESTINATION, CAUSE_LOCKOUT, CAUSE_NETWORK_CONGESTION, CAUSE_NETWORK_NOT_OBTAINABLE, CAUSE_NEW_CALL, CAUSE_NORMAL, CAUSE_RESOURCES_NOT_AVAILABLE, CAUSE_SNAPSHOT, CAUSE_UNKNOWN, META_CALL_ADDITIONAL_PARTY, META_CALL_ENDING, META_CALL_MERGING, META_CALL_PROGRESS, META_CALL_REMOVING_PARTY, META_CALL_STARTING, META_CALL_TRANSFERRING, META_SNAPSHOT, META_UNKNOWN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 667 Cisco Unified JTAPI Extensions Inherited Fields

Methods Table 257: Methods in CiscoTransferStartEv Description Method Interface Returns the call that will be transferred. getTransferredCall() javax.telephony. Call Returns the call that will remain active after the transfer completes. getFinalCall() javax.telephony. Call Returns the ACTIVE TerminalConnection that currently acts as the transfer controller for the final call. When the transferController is a SharedLine, there will be multiple TerminalConnection objects. This method returns the ACTIVE TerminalConnection; however, if the application is not observing the ACTIVE TerminalConnection, this method will return one of the PASSIVE TerminalConnection objects. getTransferController() javax.telephony. Terminal Connection Returns a list of TerminalConnection objects that currently act as the transfer controller for the final call. When the transferController is not a SharedLine, there will be only TerminalConnection in the list. This method returns null if there is no observer on the transfer controller. getTransferControllers() javax.telephony. Terminal Connection[] Returns the address that currently acts as the transfer controller for the final call. getTransferControllerAddress() javax.telephony. Address Returns the terminal names of the controllers across which transfer is done. getControllerTerminalName() String Inherited Methods From Interface com.cisco.jtapi.extensions.CiscoCallEv getCiscoCause, getCiscoFeatureReason From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent From Interface javax.telephony.events.CallEv getCall From Interface javax.telephony.events.Ev getCause, getID, getMetaCode, getObserved, isNewMetaEvent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 668 Cisco Unified JTAPI Extensions Methods

Related Documentation See Constant Field Values, on page 1667 and getTransferControllers(). CiscoUrlInfo The CiscoUrlInfo object specifies the properties of the Uniform Resources Locator (URL) associated with a SIP endpoint. Interface History Description Cisco Unified Communications Manager Release Number Created history table to track changes. 7.1(1 and 2) Two new fields, TRANSPORT_TYPE_UNKNOWN and TRANSPORT_TYPE_TLS, are added. 9.0(1) Declaration public interface CiscoUrlInfo Fields Table 258: Fields in CiscoUrlInfo Description Field Interface The endpoint is using an unknown transport type. TRANSPORT_TYPE_UNKNOWN static final int The endpoint is using UDP. TRANSPORT_TYPE_UDP static final int The endpoint is using TCP. TRANSPORT_TYPE_TCP static final int The endpoint is using TLS. TRANSPORT_TYPE_TLS static final int The URL is of unknown type. URL_TYPE_UNKNOWN static final int The URL is of type telephony. URL_TYPE_TEL static final int The URL is of type SIP. URL_TYPE_SIP static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 669 Cisco Unified JTAPI Extensions Related Documentation

Methods Table 259: Methods in CiscoUrlInfro Description Method Interface Returns the user name associated with the SIP endpoint as a string getUser() java.lang.String Returns the host name associated with the SIP endpoint. getHost() java.lang.String Returns the port associated with the SIP endpoint. getPort() int Returns the Transport Layer Protocol type that the SIP endpoint uses. The type is either CiscoUrlInfo.TRANSPORT_TYPE_UDP or CiscoUrlInfo.TRANSPORT_TYPE_TCP. getTransportType() int This method returns the endpoint URL type. CiscoUrlInfo.URL_TYPE_UNKNOWN, CiscoUrlInfo.URL_TYPE_TEL, and CiscoUrlInfo.URL_TYPE_SIP are the possible return values. getUrlType() int Related Documentation See Constant Field Values, on page 1667. ComponentUpdater The overloaded method is introduced which creates an updater log in the directory that is specified. Interface History Description Cisco Unified Communications Manager Release Number Added in 7.1(2) 7.1(2) Declaration public interface ComponentUpdater Methods The overloaded method is introduced which creates updater log in the directory specified. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 670 Cisco Unified JTAPI Extensions Methods

Table 260: Methods in ComponentUpdater Description Method Interface Returns the Consult Call for which consult operation is cancelled, if the consult call doesn't exist it will return NULL. String tracePath ComponentUpdater Related Documentation See Constant Field Values, on page 1667. ProviderPickupNotificationRegistrationClosedEv ProviderPickupNotificationRegistrationClosedEvent is a new interface being added with Call Pickup feature development. This event is fired whenever something happens on the CUCM that results in a previous registration to observe a pickup group being made invalid. For example, removal of pickup group from the CUCM, or change in Pickup Number etc. Applications should look for these events and handle them accodringly. Interface History Description Cisco Unified Communications Manager Release Number New interface 8.0(1) Declaration public interface ProviderPickupNotificationRegistrationClosedEvent extends CiscoProvEvMethods Methods Table 261: Methods in ProviderPickupNotificationRegistrationClosedEv Description Method Interface This method returns the Pickup Group Number for the Pickup Group that is invalidated by the event. getPickupGroupNumber() String This method returns the Pickup Group Partition for the Pickup Group that is invalidated by the event. getPickupGroupPartition() String This method returns the reason code explaining why this Pickup Group was invalidated. getReason() int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 671 Cisco Unified JTAPI Extensions Related Documentation

New Reason Code CTIERR_PICKUPGROUP_CHANGED CTIERR_PICKUPGROUP_DELETED Related Documentation None CiscoTermHuntLogStatusChangedEv This is a new interface that has been introduced in Cisco JTAPI. The intention of this new interface is to notify the applications with event CiscoTermHuntLogStatusChangedEv whenever the value of hunt log status is changed, provided the filter is set to true on that particular terminal. Declaration Methods Description Method Inteface This method is used get the value of huntlogstatus of the terminal, it returns either CiscoTerminal.DEVICE_HUNT_LOGGED_IN, CiscoTerminal.DEVICE_HUNT_LOGGED_OUT, or CiscoTerminal. DEVICE_HUNT_NOT_APPLICABLE getHuntLogStatus() int CiscoProvConnToLeastPriorCtiServerEv Interface History Description Cisco Unified Communications Manager Release Number New interface. 14SU3 Declaration public interface CiscoProvConnToLeastPriorCtiServerEv extends CiscoProvEv. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 672 Cisco Unified JTAPI Extensions New Reason Code

Fields Table 262: Fields in CiscoProvConnToLeastPriorCtiServerEv Description Field Interface ID Static int Methods Related Documentation None CiscoProvFallbackToPrimNwCompltdEv Interface History Description Cisco Unified Communications Manager Release Number New interface. 14SU3 Declaration public interface CiscoProvFallbackToPrimNwCompltdEv extends CiscoProvEv. Fields Table 263: Fields in CiscoProvFallbackToPrimNwCompltdEv Description Field Interface ID Static int Methods Related Documentation None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 673 Cisco Unified JTAPI Extensions CiscoProvFallbackToPrimNwCompltdEv

CiscoProvPrimNwReachableEv Interface History Description Cisco Unified Communications Manager Release Number New interface. 14SU3 Declaration public interface CiscoProvPrimNwReachableEv extends CiscoProvEv. Fields None Methods Table 264: Methods in CiscoProvPrimNwReachableEv Description Method Interface Returns a list of CTI Servers that are reachable after application fails over to the least priority CTI Server. getReachableCtiServers() String[] Related Documentation None Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 674 Cisco Unified JTAPI Extensions CiscoProvPrimNwReachableEv

C H A P T E R 6 Cisco Unified JTAPI Alarms and Services The Cisco Unified JTAPI alarms and services consists of a set of classes and interfaces that expose the additional functionality not readily exposed in JTAPI 1.2 specification but are available in Cisco Unified Communications Manager. Developers can use the classes and interfaces to create new applications or modify existing classes and interfaces to create new methods. This chapter describes the alarms and services that are available for implementation in a Cisco Unified Communications Manager. For information about Cisco Unified JTAPI extensions, see Cisco Unified JTAPI Extensions, on page 249 • Alarm Class Hierarchy, on page 676 • AlarmManager, on page 676 • AlarmWriter, on page 678 • DefaultAlarm, on page 680 • DefaultAlarmWriter, on page 682 • ParameterList, on page 686 • Alarm Interface Hierarchy, on page 688 • Alarm, on page 688 • AlarmWriter, on page 693 • Services Tracing Class Hierarchy, on page 695 • BaseTraceWriter, on page 695 • ConsoleTraceWriter, on page 699 • LogFileTraceWriter, on page 701 • OutputStreamTraceWriter, on page 707 • SyslogTraceWriter, on page 710 • TraceManagerFactory, on page 712 • Services Tracing Interface Hierarchy, on page 714 • Trace, on page 714 • ConditionalTrace, on page 721 • UnconditionalTrace, on page 722 • TraceManager, on page 723 • TraceModule, on page 727 • TraceWriter, on page 728 • TraceWriterManager, on page 731 • Tracing Implementation Class Hierarchy, on page 732 • TraceImpl, on page 733 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 675

• ConditionalTraceImpl, on page 735 • UnconditionalTraceImpl, on page 736 • TraceManagerImpl, on page 737 • TraceWriterManagerImpl, on page 741 Alarm Class Hierarchy The following class hierarchy is contained in the com.cisco.services.alarm package. java.lang.Object com.cisco.services.alarm.AlarmManager, on page 676 com.cisco.services.alarm.DefaultAlarm, on page 680 (implements com.cisco.services.alarm.Alarm) com.cisco.services.alarm.DefaultAlarmWriter, on page 682 (implements com.cisco.services.alarm.AlarmWriter, on page 693) com.cisco.services.alarm.ParameterList, on page 686 AlarmManager The AlarmManager is used to create Alarm objects. The AlarmManager is created with a facility and AlarmService hostname and port. All alarms created by the factory will be associated with this facility. This class also maintains a reference to a single AlarmWriter that can be used system wide. An application can make use of this AlarmWriter. AlarmManager exposes a default implementation of an AlarmWriter. Applications can override this with a user defined implementation of their own AlarmWriter. Usage AlarmManager AlarmManager = new AlarmManager(facilityName, alarmServiceHost, alarmServicePort, debugTrace, errorTrace); Alarms are created by the factory by supplying the alarmName (mnemonic), subfacility and severity Alarms can be cached for use in different parts of the application. During a send alarm applications can specify the variable parameters that offer specific information to the AlarmService. Usage Typically applications will maintain their own AlarmManager instance. Applications will also have to set a debug and error trace to enable the alarm tracing to also be sent to the existing trace destinations. Setup the manager and writer classes: AlarmWriter alarmWriter = new DefaultAlarmWriter(port, alarmServiceHost); AlarmManager alarmManager = new AlarmManager(“AA_IVR”, alarmWriter, debugTrace, errorTrace); Generating the Alarms: create an alarm for the subfacility and a default severity. Alarm alarm = alarmManager.createAlarm(“HTTPSS”, Alarm.INFORMATIONAL); alarm.send(“090T”) sends the alarm with the mnemonic alarm.send(“090T”, “Port is stuck”, “CTIPort01”) or with a mnemonic and parameter Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 676 Cisco Unified JTAPI Alarms and Services Alarm Class Hierarchy

Declaration public class AlarmManager java.lang.Object | +--com.cisco.services.alarm.AlarmManager More than one parameter can be sent by specifying a ParameterList Note Member summary Constructors AlarmManager(String, AlarmWriter, Trace, UnconditionalTrace), on page 677 Create an instance of the AlarmManager for the facility. Methods createAlarm(String, int), on page 678 Creates an Alarm of required severity for the subFacility Alarm getAlarmWriter(), on page 678 AlarmWriter setAlarmWriter(AlarmWriter), on page 678 Allows applications to override the AlarmWriter to be used by this AlarmManager, with a user defined AlarmWriter void Inherited member summary Methods inherited from class Object clone(), equals(Object), finalize(), getClass(), hashCode(), notify(), notifyAll(), toString(), wait(), wait(), wait() Constructors AlarmManager(String, AlarmWriter, Trace, UnconditionalTrace) public AlarmManager(java.lang.String facility, com.cisco.services.alarm.AlarmWriterwriter, com.cisco.services.tracing.TracedebugTrace_, com.cisco.services.tracing.UnconditionalTraceerrorTrace_) Create an instance of the AlarmManager for the facility. Applications specify an AlarmWriter to be used by this AlarmManager to send the Alarms to the AlarmService. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 677 Cisco Unified JTAPI Alarms and Services Declaration

Methods createAlarm(String, int) public com.cisco.services.alarm.Alarm createAlarm (java.lang.String subfacility, intseverity) Creates an Alarm of required severity for the subFacility Returns: an object implementing the alarm interface getAlarmWriter() public com.cisco.services.alarm.AlarmWriter getAlarmWriter() Returns: an AlarmWriter object setAlarmWriter(AlarmWriter) public void setAlarmWriter(com.cisco.services.alarm.AlarmWriter writer) Allows applications to override the AlarmWriter to be used by this AlarmManager, with a user defined AlarmWriter AlarmWriter An AlarmWriter receives alarm messages and transmits it to the receiving AlarmService on a TCP link. This interface can be used to implement other AlarmWriters to be used with this implementation of com.cisco.service.alarm A DefaultAlarmWriter is provided with this implementation and can be obtained from the AlarmManager. Declaration public interface AlarmWriter All Known Implementing Classes DefaultAlarmWriter, on page 682 Member Summary Member summary Methods close(), on page 679 close the AlarmWriter void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 678 Cisco Unified JTAPI Alarms and Services Methods

Member summary getDescription(), on page 679 java.lang.String getEnabled(), on page 679 boolean getName(), on page 679 java.lang.String send(String), on page 679 Send out the alarm message to the AlarmService. void setEnabled(boolean), on page 680 Enable or disable the AlarmWriter void Methods close() public void close() close the AlarmWriter getDescription() public java.lang.String getDescription() Returns: the AlarmWriter description getEnabled() public boolean getEnabled() Returns: the current enabled or disabled state of the AlarmWriter getName() public java.lang.String getName() Returns: the AlarmWriter name send(String) public void send(java.lang.String alarmMessage) Send out the alarm message to the AlarmService. Parameters: the - Alarm to be sent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 679 Cisco Unified JTAPI Alarms and Services Methods

setEnabled(boolean) public void setEnabled(boolean enable) Enable or disable the AlarmWriter Parameters: enable or disable the AlarmWriter DefaultAlarm An Implementation of the Alarm interface. The AlarmManager creates these Alarms when the createAlarm() method is called. Declaration public class DefaultAlarm implements Alarm, on page 688 java.lang.Object | +--com.cisco.services.alarm.DefaultAlarm All Implemented Interfaces Alarm, on page 688 Member Summary Member summary Constructors DefaultAlarm(String, String, int, AlarmWriter), on page 681 Methods getFacility(), on page 681 java.lang.String getSeverity(), on page 681 int getSubFacility(), on page 681 java.lang.String send(String), on page 681 Send the alarm with the specified mnemonic void send(String, ParameterList), on page 682 Send the alarm with the specified name and list of parameters. void send(String, String, String), on page 682 Send the alarm with the specified name and parameter void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 680 Cisco Unified JTAPI Alarms and Services DefaultAlarm

Inherited member summary Fields inherited from interface Alarm, on page 688 ALERTS, on page 691, CRITICAL, on page 691, DEBUGGING, on page 691, EMERGENCIES, on page 691, ERROR, on page 691, HIGHEST_LEVEL, on page 691, INFORMATIONAL, on page 692, LOWEST_LEVEL, on page 692, NOTIFICATION, on page 692, NO_SEVERITY, on page 692, UNKNOWN_MNEMONIC, on page 692, WARNING, on page 692 Methods inherited from class Object clone(), equals(Object), finalize(), getClass(), hashCode(), notify(), notifyAll(), toString(), wait(), wait(), wait() Constructors DefaultAlarm(String, String, int, AlarmWriter) public DefaultAlarm(java.lang.String facility, java.lang.StringsubFacility, intseverity, com.cisco.services.alarm.AlarmWriteralarmWriter) Methods getFacility() public java.lang.String getFacility() Specified By: getFacility(), on page 692 in interface Alarm, on page 688 getSeverity() public int getSeverity() Specified By: getSeverity(), on page 692 in interface Alarm, on page 688 getSubFacility() public java.lang.String getSubFacility() Specified By: getSubFacility(), on page 693 in interface Alarm, on page 688 send(String) public void send(java.lang.String mnemonic) Send the alarm with the specified mnemonic Specified By: send(String), on page 693 in interface Alarm, on page 688 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 681 Cisco Unified JTAPI Alarms and Services Constructors

send(String, ParameterList) public void send(java.lang.String mnemonic, com.cisco.services.alarm.ParameterListparamList) Send the alarm with the specified name and list of parameters. Specified By: send(String, ParameterList), on page 693 in interface Alarm, on page 688 send(String, String, String) public void send(java.lang.String mnemonic, java.lang.StringparamName, java.lang.StringparamValue) Send the alarm with the specified name and parameter Specified By: send(String, String, String), on page 693 in interface Alarm, on page 688 DefaultAlarmWriter DefaultAlarmWriter implementation of the AlarmWriter interface. DefaultAlarmWriter maintains a queue of a fixed size to which the alarms are written. The sending of the alarms to the alarm service takes place on a separate thread. The queue is fixed size. Declaration public class DefaultAlarmWriter implements AlarmWriter, on page 678 java.lang.Object | +--com.cisco.services.alarm.DefaultAlarmWriter All Implemented Interfaces AlarmWriter, on page 678 Member Summary Member summary Constructors DefaultAlarmWriter(int, String), on page 683 Constructor for the DefaultAlarmWriter which takes the AlarmService hostname, port and a queue size of fifty (50). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 682 Cisco Unified JTAPI Alarms and Services DefaultAlarmWriter

Member summary DefaultAlarmWriter(int, String, int), on page 684 Constructor for the DefaultAlarmWriter which takes the AlarmService hostname, port and queue size. DefaultAlarmWriter(int, String, int, ConditionalTrace, UnconditionalTrace), on page 684 Constructor for the DefaultAlarmWriter which takes the AlarmService hostname, port and queue size. Methods close(), on page 684 Shutdown the send thread and close the socket void getDescription(), on page 685 java.lang.String getEnabled(), on page 685 boolean getName(), on page 685 java.lang.String main(String[]), on page 685 static void send(String), on page 685 send the Alarm to the alarm service void setEnabled(boolean), on page 685 Applications can dynamically enable or disable the AlarmWriter void Inherited member summary Methods inherited from class Object clone(), equals(Object), finalize(), getClass(), hashCode(), notify(), notifyAll(), toString(), wait(), wait(), wait() Constructors DefaultAlarmWriter(int, String) public DefaultAlarmWriter(int port, java.lang.StringalarmServiceName) throwsUnknownHostException Constructor for the DefaultAlarmWriter which takes the AlarmService hostname, port and a queue size of fifty (50). The AlarmService is listening on this port for Alarm messages. Parameters: port: port on which the alarm service is listening alarmServiceName: The host name of the machine with the Alarm service Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 683 Cisco Unified JTAPI Alarms and Services Constructors

Throws: java.net.UnknownHostException DefaultAlarmWriter(int, String, int) public DefaultAlarmWriter(int port, java.lang.StringalarmServiceName, intqueueSize) throwsUnknownHostException Constructor for the DefaultAlarmWriter which takes the AlarmService hostname, port and queue size. The AlarmService is listening on this port for Alarm messages. Parameters: port—port on which the alarm service is listening alarmServiceName—The host name of the machine with the Alarm service queueSize - the size of the queue to be maintained in the alarm writer Throws: java.net.UnknownHostException DefaultAlarmWriter(int, String, int, ConditionalTrace, UnconditionalTrace) public DefaultAlarmWriter(int port, java.lang.StringalarmServiceName, intqueueSize, com.cisco.services.tracing.ConditionalTracedebugTrace_, com.cisco.services.tracing.UnconditionalTraceerrorTrace_) throwsUnknownHostException Constructor for the DefaultAlarmWriter which takes the AlarmService hostname, port and queue size. The AlarmService is listening on this port for Alarm messages. Parameters: port—port on which the alarm service is listening alarmServiceName—The host name of the machine with the Alarm service queueSize - the size of the queue to be maintained in the alarm writer Throws: java.net.UnknownHostException Methods close() public void close() Shutdown the send thread and close the socket Specified By: close in interface AlarmWriter, on page 678 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 684 Cisco Unified JTAPI Alarms and Services Methods

getDescription() public java.lang.String getDescription() Specified By: getDescription in interface AlarmWriter, on page 678 Returns: a short description of the AlarmWriter getEnabled() public boolean getEnabled() Specified By: getEnabled in interface AlarmWriter, on page 678 Returns: the enabled state of the AlarmWriter getName() public java.lang.String getName() Specified By: getName in interface AlarmWriter, on page 678 Returns: the name of the AlarmWriter main(String[]) public static void main(java.lang.String[] args) send(String) public void send(java.lang.String alarmMessage) send the Alarm to the alarm service Specified By: send in interface AlarmWriter, on page 678 setEnabled(boolean) public void setEnabled(boolean enable) Applications can dynamically enable or disable the AlarmWriter Specified By: setEnabled in interface AlarmWriter, on page 678 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 685 Cisco Unified JTAPI Alarms and Services Methods

ParameterList ParameterList is a list of name value pairs that is used to send additional (and optional) user defined parameters to the AlarmService. These parameters can contain the specifics of an Alarm. As an example, a LowResourceAlarm can have a parameter that informs the service which particular resource is low: name = “CPUUsage” value = “0.9” These parameters are user definable but must, however, also be pre-defined in the AlarmService catalog. Declaration public class ParameterList java.lang.Object | +--com.cisco.services.alarm.ParameterList Member Summary Member summary Constructors ParameterList(), on page 687 Default constructor for the ParameterList ParameterList(String, String), on page 687 Constructor that takes a name value pair. Methods addParameter(String, String), on page 687 method used to add additional name value pairs (parameters) to the list void addParameter(String, String), on page 687 getParameterNames(), on page 687 Get the parameter names in the list java.lang.String[] getParameterValue(String), on page 687 get the value for a parameter java.lang.String removeAllParameters(), on page 688 remove all the parameters in the list void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 686 Cisco Unified JTAPI Alarms and Services ParameterList

Member summary removeParameter(String), on page 688 remove a particular parameter if it is in the list void toString(), on page 688 java.lang.String Inherited member summary Methods inherited from class Object clone(), equals(Object), finalize(), getClass(), hashCode(), notify(), notifyAll(), wait(), wait(), wait() Constructors ParameterList() public ParameterList() Default constructor for the ParameterList ParameterList(String, String) public ParameterList(java.lang.String name, java.lang.Stringvalue) Constructor that takes a name value pair. Methods addParameter(String, String) public void addParameter(java.lang.String name, java.lang.Stringvalue) method used to add additional name value pairs (parameters) to the list getParameterNames() public java.lang.String[] getParameterNames() Get the parameter names in the list Returns: array of parameters getParameterValue(String) public java.lang.String getParameterValue(java.lang.String parameterName) get the value for a parameter Returns: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 687 Cisco Unified JTAPI Alarms and Services Constructors

value of a parameter removeAllParameters() public void removeAllParameters() remove all the parameters in the list removeParameter(String) public void removeParameter(java.lang.String parameterName) remove a particular parameter if it is in the list toString() public java.lang.String toString() Overrides: toString in class Object Alarm Interface Hierarchy The following interface hierarchy is contained in the com.cisco.services.alarm package. com.cisco.services.alarm.Alarm, on page 688 com.cisco.services.alarm.AlarmWriter, on page 693 Alarm The Alarm interface is used to define Alarms in. An Alarm has an XML representation that it must adhere to in order to be recognized by the Alarm Service, with a DTD as shown below. An application can implement this interface or use the AlarmFactory to generate Alarms of the correct format. The Alarm is the a specification that needs to be sent to an AlarmService that will take some action based on the Alarm. Using this specification the AlarmService will access definitions available in a catalog. This catalog is maintained by the user requiring the Alarm function to effect the appropriate action for the Alarm. The severity specified the Alarm can over-ride the severity associated with this Alarm in the catalog. If no severity is specified in the Alarm the catalog severity is used. Alarm severities are derived from Syslog and are defined as follows: 0 = EMERGENCIES System unusable 1 = ALERTS Immediate action needed 2 = CRITICAL Critical conditions 3 = ERROR Error conditions 4 = WARNING Warning conditions 5 = NOTIFICATION Normal but significant condition Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 688 Cisco Unified JTAPI Alarms and Services Alarm Interface Hierarchy

6 = INFORMATIONAL Informational messages only 7 = DEBUGGING Debugging messages Declaration public interface Alarm All Known Implementing Classes DefaultAlarm, on page 680 Member Summary Member summary Fields ALERTS, on page 691 The application will continue working on the tasks but all functions may not be operational (one or more devices in the list are not accessible but others in the list can be accessed) Syslog severity level = 1 static int CRITICAL, on page 691 A critical failure, the application cannot accomplish the tasks required due to this failure, for example, the application cannot open the database to read the device list Syslog severity level = 2 static int DEBUGGING, on page 691 Very detailed information regarding errors or processing status that is only generated when DEBUG mode has been enabled Syslog severity level = 7 static int EMERGENCIES, on page 691 Emergency situation, a system shutdown is necessary Syslog severity level = 0 static int ERROR, on page 691 An error condition of some kind has occurred and the user needs to understand the nature of that failure Syslog severity level = 3 static int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 689 Cisco Unified JTAPI Alarms and Services Declaration

Member summary HIGHEST_LEVEL, on page 691 The highest trace level, currently this is DEBUGGING with a trace level of 7 static int INFORMATIONAL, on page 692 Information of some form not relating to errors, warnings, audit, or debug Syslog severity level = 6 static int LOWEST_LEVEL, on page 692 The lowest trace level, currently this is EMERGENCIES with a trace level of 0 static int NO_SEVERITY, on page 692 Applications can set this level to generate Alarms without a severity. static int NOTIFICATION, on page 692 Notification denotes a normal but significant condition Syslog severity level = 5 static int UNKNOWN_MNEMONIC, on page 692 String used when a mnemonic is not specified during an Alarm send static java.lang.String WARNING, on page 692 Warning that a problem of some form exists but is not keeping the application from completing its tasks Syslog severity level = 4 static int Methods getFacility(), on page 692 java.lang.String getSeverity(), on page 692 int getSubFacility(), on page 693 java.lang.String send(String), on page 693 send the Alarm with the specified mnemonic. void send(String, ParameterList), on page 693 send an Alarm with the specified mnemonic and supplied parameter list void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 690 Cisco Unified JTAPI Alarms and Services Member Summary

Member summary send(String, String, String), on page 693 send an Alarm with the specified mnemonic and with one parameter void Fields ALERTS public static final int ALERTS The application will continue working on the tasks but all functions may not be operational (one or more devices in the list are not accessible but others in the list can be accessed) Syslog severity level = 1 CRITICAL public static final int CRITICAL A critical failure, the application cannot accomplish the tasks required due to this failure, for example, the application cannot open the database to read the device list Syslog severity level = 2 DEBUGGING public static final int DEBUGGING Very detailed information regarding errors or processing status that is only generated when DEBUG mode has been enabled (Syslog severity level = 7). EMERGENCIES public static final int EMERGENCIES Emergency situation, a system shutdown is necessary Syslog severity level = 0 ERROR public static final int ERROR An error condition of some kind has occurred and the user needs to understand the nature of that failure Syslog severity level = 3 HIGHEST_LEVEL public static final int HIGHEST_LEVEL The highest trace level, currently this is DEBUGGING with a trace level of 7 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 691 Cisco Unified JTAPI Alarms and Services Fields

INFORMATIONAL public static final int INFORMATIONAL Information of some form not relating to errors, warnings, audit, or debug Syslog severity level = 6 LOWEST_LEVEL public static final int LOWEST_LEVEL The lowest trace level, currently this is EMERGENCIES with a trace level of 0 NO_SEVERITY public static final int NO_SEVERITY Applications can set this level to generate Alarms without a severity. NOTE: This is only intended for cases where an application wants the AlarmService to use the severity associated with the Alarm in the catalog NOTIFICATION public static final int NOTIFICATION Notification denotes a normal but significant condition (Syslog severity level = 5). UNKNOWN_MNEMONIC public static final java.lang.String UNKNOWN_MNEMONIC String used when a mnemonic is not specified during an Alarm send WARNING public static final int WARNING Warning that a problem of some form exists but is not keeping the application from completing its tasks (Syslog severity level = 4). Methods getFacility() public java.lang.String getFacility() Returns: the facility name of this Alarm getSeverity() public int getSeverity() Returns: severity of the alarm, an integer in the range [0-7] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 692 Cisco Unified JTAPI Alarms and Services Methods

getSubFacility() public java.lang.String getSubFacility() Returns: the subfacility of this Alarm send(String) public void send(java.lang.String mnemonic) send the Alarm with the specified mnemonic. If a null or empty String is passed a mnemonic UNK is sent send(String, ParameterList) public void send(java.lang.String mnemonic, com.cisco.services.alarm.ParameterListparameterList) send an Alarm with the specified mnemonic and supplied parameter list send(String, String, String) public void send(java.lang.String mnemonic, java.lang.StringparameterName, java.lang.StringparameterValue) send an Alarm with the specified mnemonic and with one parameter. AlarmWriter An AlarmWriter receives alarm messages and transmits it to the receiving AlarmService on a TCP link. This interface can be used to implement other AlarmWriters to be used with this implementation of com.cisco.service.alarm A DefaultAlarmWriter is provided with this implementation and can be obtained from the AlarmManager. Declaration public interface AlarmWriter All Known Implementing Classes DefaultAlarmWriter, on page 682 Member Summary Member summary Methods close(), on page 679 close the AlarmWriter void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 693 Cisco Unified JTAPI Alarms and Services AlarmWriter

Member summary getDescription(), on page 679 java.lang.String getEnabled(), on page 679 boolean getName(), on page 679 java.lang.String send(String), on page 679 Send out the alarm message to the AlarmService. void setEnabled(boolean), on page 680 Enable or disable the AlarmWriter void Methods close() public void close() close the AlarmWriter getDescription() public java.lang.String getDescription() Returns: the AlarmWriter description getEnabled() public boolean getEnabled() Returns: the current enabled or disabled state of the AlarmWriter getName() public java.lang.String getName() Returns: the AlarmWriter name send(String) public void send(java.lang.String alarmMessage) Send out the alarm message to the AlarmService. Parameters: the Alarm to be sent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 694 Cisco Unified JTAPI Alarms and Services Methods

setEnabled(boolean) public void setEnabled(boolean enable) Enable or disable the AlarmWriter Parameters: enable or disable the AlarmWriter Services Tracing Class Hierarchy The following class hierarchy is contained in the com.cisco.services.tracing package. java.lang.Object com.cisco.services.tracing.BaseTraceWriter, on page 695 (implements com.cisco.services.tracing.TraceWriter) com.cisco.services.tracing.ConsoleTraceWriter, on page 699 com.cisco.services.tracing.LogFileTraceWriter, on page 701 com.cisco.services.tracing.OutputStreamTraceWriter, on page 707 com.cisco.services.tracing.SyslogTraceWriter, on page 710 com.cisco.services.tracing.TraceManagerFactory, on page 712 BaseTraceWriter This abstract class is useful for supplying a default, non-printing TraceWriter to a TraceWriterManager This class must be extended to provide the functionality to trace to different streams. The doPrintln() method must be implemented by the extending class. Declaration public abstract class BaseTraceWriter implements TraceWriter, on page 728 java.lang.Object | +--com.cisco.services.tracing.BaseTraceWriter All Implemented Interfaces TraceWriter, on page 728 Direct Known Subclasses ConsoleTraceWriter, on page 699, LogFileTraceWriter, on page 701, OutputStreamTraceWriter, on page 707, SyslogTraceWriter, on page 710 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 695 Cisco Unified JTAPI Alarms and Services Services Tracing Class Hierarchy

Member Summary Member summary Constructors BaseTraceWriter(int[], String, String), on page 697 BaseTraceWriter with trace levels as passed in traceLevels in the array falling outside the range Trace.LOWEST_LEVEL and Trace.HIGHEST_LEVEl are ignored protected BaseTraceWriter(int, String, String), on page 697 BaseTraceWriter that traces all levels up to the maxTraceLevel The trace level is maintained in the range [Trace.HIGHEST_LEVEL, Trace.LOWEST_LEVEL ] protected BaseTraceWriter(String, String), on page 697 BaseTraceWriter which only traces the lowest level i.e. severity level, Trace.LOWEST_LEVEL messages protected Methods close(), on page 697 void doClose(), on page 698 protected void doFlush(), on page 698 protected void doPrintln(String, int), on page 698 Must be implemented by the various TraceWriters extending BaseTraceWriter to provide the specific tracing functionality protected abstract void flush(), on page 698 void getDescription(), on page 698 java.lang.String getEnabled(), on page 698 boolean getName(), on page 698 java.lang.String getTraceLevels(), on page 698 int[] println(String, int), on page 699 void setTraceLevels(int[]), on page 699 void toString(), on page 699 java.lang.String Inherited member summary Methods inherited from class Object clone() , equals(Object), finalize(), getClass(), hashCode(), notify(), notifyAll(), wait(), wait(), wait() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 696 Cisco Unified JTAPI Alarms and Services Member Summary

Constructors BaseTraceWriter(int[], String, String) protected BaseTraceWriter(int[] traceLevels, java.lang.Stringname, java.lang.Stringdescription) BaseTraceWriter with trace levels as passed in traceLevels in the array falling outside the range Trace.LOWEST_LEVEL and Trace.HIGHEST_LEVEl are ignored Parameters: traceLevels - array of trace levels See Also: Trace, on page 714 BaseTraceWriter(int, String, String) protected BaseTraceWriter(int maxTraceLevel, java.lang.Stringname, java.lang.Stringdescription) BaseTraceWriter that traces all levels up to the maxTraceLevel The trace level is maintained in the range [Trace.HIGHEST_LEVEL, Trace.LOWEST_LEVEL] See Also: Trace, on page 714 BaseTraceWriter(String, String) protected BaseTraceWriter(java.lang.String name, java.lang.Stringdescription) BaseTraceWriter which only traces the lowest level i.e. severity level, Trace.LOWEST_LEVEL messages See Also: Trace, on page 714 Methods close() public final void close() Description copied from interface: com.cisco.services.tracing.TraceWriter Releases any resources associated by this TraceWriter. Specified By: close in interface TraceWriter, on page 728 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 697 Cisco Unified JTAPI Alarms and Services Constructors

doClose() protected void doClose() doFlush() protected void doFlush() doPrintln(String, int) protected abstract void doPrintln(java.lang.String message, intmessageNumber) Must be implemented by the various TraceWriters extending BaseTraceWriter to provide the specific tracing functionality flush() public final void flush() Description copied from interface: com.cisco.services.tracing.TraceWriter Forces output of any messages that have been printed using the println method Specified By: flush in interface TraceWriter, on page 728 getDescription() public final java.lang.String getDescription() Specified By: getDescription in interface TraceWriter, on page 728 getEnabled() public boolean getEnabled() Description copied from interface: com.cisco.services.tracing.TraceWriter Returns whether the println method will print anything or not. A closed TraceWriter will always return false from this method. Specified By: getEnabled in interface TraceWriter, on page 728 getName() public final java.lang.String getName() Specified By: getName in interface TraceWriter, on page 728 getTraceLevels() public final int[] getTraceLevels() Specified By: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 698 Cisco Unified JTAPI Alarms and Services Methods

getTraceLevels in interface TraceWriter, on page 728 println(String, int) public final void println(java.lang.String message, intseverity) Description copied from interface: com.cisco.services.tracing.TraceWriter Prints the specified string followed by a carriage return The concrete TraceWriter class will use the severity to block out messages from a particular stream. Each trace writer has a notion of the highest level trace it traces. Specified By: println in interface TraceWriter, on page 728 setTraceLevels(int[]) public final void setTraceLevels(int[] levels) Description copied from interface: com.cisco.services.tracing.TraceWriter set the trace levels that will be traced by this TraceWriter Specified By: setTraceLevels in interface TraceWriter, on page 728 toString() public final java.lang.String toString() Overrides: toString in class Object ConsoleTraceWriter Supplies a console TraceWriter to trace to System.out. See Also: Trace, on page 714 Declaration public final class ConsoleTraceWriter extends BaseTraceWriter java.lang.Object | +--com.cisco.services.tracing.BaseTraceWriter | +--com.cisco.services.tracing.ConsoleTraceWriter Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 699 Cisco Unified JTAPI Alarms and Services ConsoleTraceWriter

All Implemented Interfaces TraceWriter, on page 728 Member Summary Member summary Constructors ConsoleTraceWriter(), on page 700 Default constructor, traces all severity levels ConsoleTraceWriter(int), on page 701 Constructor that sets the maximum level to be traced. ConsoleTraceWriter(int[]), on page 701 Construct a ConsoleTraceWriter with an array of trace levels Only traces with the severity in the tracelevel array are traced Methods doFlush(), on page 701 protected void doPrintln(String, int), on page 701 protected void main(String[]), on page 701 static void Inherited member summary Methods inherited from class BaseTraceWriter, on page 695 close(), on page 697, doClose(), on page 698, flush(), on page 698, getDescription(), on page 698, getEnabled(), on page 698, getName(), on page 698, getTraceLevels(), on page 698, println(String, int), on page 699, setTraceLevels(int[]), on page 699, toString(), on page 699 Methods inherited from class Object clone(), equals(Object), finalize(), getClass(), hashCode(), notify(), notifyAll(), wait(), wait(), wait() Constructors ConsoleTraceWriter() public ConsoleTraceWriter() Default constructor, traces all severity levels Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 700 Cisco Unified JTAPI Alarms and Services All Implemented Interfaces