Jtapi Dev Guide

Cisco cucm v15 on shelf · 1773 chunks · 1796 pages

Text view

Document Metadata

Format: PDF 1.4 Title: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs Author: Unknown Creator: DITA Open Toolkit Producer: XEP 4.30.961; modified using iText 2.1.7 by 1T3XT Creation Date: D:20250729112038Z Mod Date: D:20250731123907-07'00'

Page 1

Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs First Published: 2023-12-18 Last Modified: 2025-07-31 Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883

Image 2 from page 1

Page 2

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version. Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R) © 2023–2025 Cisco Systems, Inc. All rights reserved.

Page 3

C O N T E N T S New and Changed Information 1 C H A P T E R 1 Cisco Unified Communications Manager Release 15SU3 1 Cisco Unified Communications Manager Release 15SU2 2 Cisco Unified Communications Manager Release 15 2 Cisco Unified Communications Manager Release 14SU2 2 Cisco Unified Communications Manager Release 12.5(1) 2 Cisco Unified Communications Manager, Release 11.5(1) 2 Cisco Unified Communications Manager, Release 11.0(1) 3 Cisco Unified Communications Manager Release 10.5(2) 3 Cisco Unified Communications Manager Release 10.0(1) 3 Cisco Unified Communications Manager Release 9.0(1) 4 Cisco Unified Communications Manager Release 8.6(1) 4 Cisco Unified Communications Manager Release 8.5(1) 4 Cisco Unified Communications Manager Release 8.0(1) 5 Cisco Unified Communications Manager Release 7.1(3) 5 Cisco Unified Communications Manager Release 7.1(2) 5 Cisco Unified Communications Manager Release 7.0(1) 6 Cisco Unified Communications Manager Release 6.1 7 Cisco Unified Communications Manager Release 6.0 8 Cisco Unified Communications Manager Release 5.1 8 Cisco Unified Communications Manager Release 5.0 9 Overview 11 C H A P T E R 2 Cisco Unified Communications Manager Interfaces 11 Provisioning Interfaces 12 Administrative XML 12 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs iii

Image 1 from page 3

Page 3 content

Page 4

Cisco Extension Mobility 12 Device Monitoring and Call Control Interfaces 12 Cisco TAPI and Media Driver 12 Cisco JTAPI 13 Cisco Web Dialer 13 Serviceability Interfaces 13 Serviceability XML 13 SNMP/MIBs 14 Routing Rules Interface 14 Cisco Connection Interface 14 JTAPI Overview 15 Cisco Unified JTAPI and Contact Centers 15 Cisco Unified JTAPI and Enterprises 15 Cisco Unified JTAPI Applications 16 Jtprefs Application 17 Cisco Unified JTAPI Concepts 17 CiscoObjectContainer Interface 18 JtapiPeer and Provider 18 Initialization 19 Shutdown 19 Provider.getTerminals() 19 Provider.getAddresses() 19 Changes to the User Control List in the Directory 19 Address and Terminal Relationships 20 Unobserved Addresses and Terminals 21 Connections 21 Terminal Connections 21 Terminal and Address Restrictions 21 CiscoConnectionID 24 Threaded Callbacks 24 CiscoSynchronousObserver Interface 25 Querying Dynamic Objects 25 callChangeEvent() 25 CiscoConsultCall 25 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs iv Contents

Page 4 content

Page 5

CiscoTransferStartEv 26 Alarm Services 26 Software Requirements 26 Development Guidelines 26 Features Supported by Cisco Unified JTAPI 29 C H A P T E R 3 Account Lockout 33 Agent Greeting 33 AES 256 Algorithm IDs 34 Alternate Script Support 35 API for Exposing Built-In-Bridge Status 35 Arabic and Hebrew Language Support 36 Auto Updater for Linux 36 AutoAccept Support for CTI Ports and Route Points 37 Autoupdate of API 38 Barge and Privacy Event Notification 40 Call Control Discovery 41 Call Forward 41 Call Forward Override 41 Call Park 42 Call Pickup 42 Call Recording for SIP or TLS Authenticated Calls 43 Call Select Status 43 Calling Party Display Name 44 Calling Party IP Address 44 Calling Party IP Address 45 Calling Party Normalization 46 CallFwdAll Key Press Notification 46 CallSelect and UnSelect Event Notification 47 Certificate Download API Enhancement 47 Changes in DeviceType Name Handling 47 Cisco MediaTerminal 48 Provisioning 48 Registration 49 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs v Contents

Page 5 content

Page 6

Adding Observers 50 Accepting Calls 50 Cisco Unified Communications Manager Media Endpoint Model 51 Payload and Parameter Negotiation 51 Initialization 51 Payload Selection 52 Receive Channel Allocation 52 Starting Transmission and Reception 52 Stopping Transmission and Reception 53 Cisco Unified Communications Manager Server Failure 53 Cisco Unified IP 7931G Phone Interaction 54 Cisco Unified JTAPI Install Internationalization 55 Cisco VG248 and ATA 186 Analog Phone Gateways 55 CiscoJtapiExceptions 55 Errors 55 CiscoProvAuthenticationInfoEv 56 CiscoRTPHandle Interface on Cisco RTP Events 57 Cisco Terminal Filter and ButtonPressedEvents 57 CiscoTermRegistrationfailed Event 58 Errors 58 Cius Persistency 59 Clear Calls 60 Click to Conference 60 Cluster Abstraction 61 Command Line Invocation 62 Component Updater 62 Conference 63 Cisco Extensions 63 Conference Scenarios 64 Conference Events 65 Transfer and Conference Enhancement 65 Conference and Join 66 Conference Chaining 67 Consult Without Media 68 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs vi Contents

Page 6 content

Page 7

CTI Ports 69 CTI RoutePoints 69 CTI Remote Device for JTAPI 69 Play Announcement 70 Verify Remote Destination Support 71 NuRD (Number Matching for Remote Destination) Support 71 Mobility Interaction Support 72 CTI RD Call Forward 72 CTI Video Support 73 Default CTI IP Addressing for Devices 75 DeleteCall 75 Device Recovery 75 Device Recovery for Phones 75 Device State Server 76 Direct Transfer Across Lines 77 Usage Guidelines 77 Event Flow Comparison and Sample Code 78 Directed Call Park 82 Directory Change Notification 83 Do Not Disturb 83 Do Not Disturb-Reject 84 Drop Any Party 85 Dynamic CTI Port Registration 86 E911 Teleworker 88 Enable or Disable Ringer 88 Encryption Enhancement 89 End to End Call Tracing 89 EnergyWise Deep Sleep Mode 90 Extension Mobility Cross Cluster 92 Extension Mobility Username Login 93 External Call Control 93 End to End Session ID for Calls 94 FIPS Compliance 95 Forced Authorization and Client Matter Codes 98 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs vii Contents

Page 7 content

Page 8

Supported Interfaces 98 Call.Connect() and Call.Consult() 98 Call.transfer(String) and Connection.redirect() 100 RouteSession.selectRoute() 100 Forwarding on No Bandwidth and Unregistered DN 100 GetCallID in RTP Events 100 GetCallInfo 101 GetGlobalCallID 101 Hairpin Support 101 Half-Duplex Media Support 102 Hold Reversion 103 Hunt List 103 Hunt List Connected Number 105 Hunt Log Status 105 Intercom 106 Intercom Support for Extension Mobility 108 IPv6 Support 108 iSac Codec 109 Java Socket Connect Timeout 110 Join Across Lines 110 Join Across Lines (Only SCCP) 111 Join Across Lines or Connected Conference Across Lines 112 Usage Guidelines 112 Event Flow Comparison and Sample Code 112 Join Across Lines with Conference Enhancements (SCCP and SIP) 116 JRE 1.2 and JRE 1.3 Support Removal 117 JTAPI Version Information 118 Locale Infrastructure Development 118 Logical Partitioning 119 Media Termination at Route Point 119 Media Termination Extensions 122 Message Waiting Indicator Enhancement 122 Modifying Calling Number 123 Multi-fork Recording using CUBE Media Proxy Server 125 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs viii Contents

Page 8 content

Page 9

Multilevel Precedence and Preemption Support 125 Multiple Calls Per DN 125 Native Queuing 125 Network Alerting 127 Network Events 128 New Error Code in CiscoTermRegistrationFailedEv 128 Noncontroller Adding of Parties to Conferences 129 Park DN Monitor 129 Park Monitoring and Assisted DPark Support 129 Park Reminder 131 Park Retrieval 131 Partition Support 132 Password Expiry 135 Persistent Connection 135 Play Zip Tone 137 Presentation Indicator for Calls 138 Privacy On Hold 139 Progress State Converted to Disconnect State 140 Q.Signaling (QSIG) Path Replacement 140 QoS Support 140 QoS Setup on Windows 2000 141 QoS Setup on Windows XP Server 2003 141 Quiet Clear 142 Receiving and Responding to Media Flow Events 142 Inbound Call Media Flow Event Diagram 143 Cisco Unified Communications Solutions RTP Implementation 144 Recording 144 Redirect 147 Redirect Set Original Called ID 148 Redirect to Device 149 Redundancy 150 Redundancy in CTI Managers 150 Invoking CTIManager Redundancy 150 CTIManager Failure 152 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs ix Contents

Page 9 content

Page 10

Heartbeats 152 Ringback on SIP 183 for Transferred Calls 153 Routing 153 Cisco Route Session Implementation 154 Select Route Timer 154 Forwarding Timer 154 Route Session Extension 154 Caller Options Summary 155 Fault Tolerance When Using Route Points 155 Secure Conferencing 155 Secure Real-Time Protocol Key Material 156 Secured Monitoring and Recording 162 SelectRoute Interface Enhancement 163 selectRoute() with Calling Search Space and Feature Priority 164 Set MessageWaiting 164 Shared Line Support 165 Silent Monitoring 167 Single Sign-On 170 Single Step Transfer 171 SIP 3XX Redirection 172 SIP Phone Support 173 SIP REFER or REPLACE 176 SIP Trunk Early Offer 177 Star (*) 50 Update 180 Super Provider (Disable Device Validation) 180 Superprovider and Change Notification 181 Support for Cisco Unified IP Phone 6901 183 Support for Cisco Unified IP Phone 6900 Series 184 Support for 100+ Directory Numbers 185 Support for VMware 186 Swap or Cancel and Transfer or Conference Behavior 187 Terminal and Address Capability Settings 188 Terminal and Address Restrictions 189 SHA-512 Support for Digital Signatures 193 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs x Contents

Page 10 content

Page 11

Transfer 193 CiscoTransferStartEv 193 CiscoTransferEndEv 194 Transfer Scenarios 194 Transfer and Conference Extensions 196 Transfer and DirectTransfer 196 Translation Pattern Support 197 Transport Layer Security (TLS) 198 Unicode Support 205 Unrestricted Unified CM 207 URI Dialing 208 Version Format Change 209 Verification Involving PSTN Reachability 209 Video Capabilities and Multi-Media Information 209 Exposing Multimedia Capability on CiscoTerminal 210 Exposing Changes in Multimedia Capability Via a New Provider Event 210 Exposing Multimedia Capability on a CiscoCall 210 Exposing Multimedia Streams Information on CiscoTerminal 211 Supported Features (Within the Same Cluster) 211 Supported Features (Across Clusters) 212 Limitations 212 Video On Hold Support 213 Voice MailBox Support 214 XSI Object Pass Through 214 CiscoTerminal Method 215 Authentication and Mechanism 215 Cisco Unified JTAPI Installation 217 C H A P T E R 4 Overview 217 Required Software 218 Supported Platforms 218 Installing the Cisco Unified JTAPI Software 218 Installation Procedures 218 Linux Platforms 222 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xi Contents

Page 11 content

Page 12

Verifying Linux Installation 223 Windows Platforms 224 Verifying Windows Installation 225 Linux and Windows Installation 226 Using Cisco Unified CM JTAPI 227 Program Group and Program Elements 227 Cisco Unified JTAPI Configuration Settings 227 JTAPI Tracing Tab 228 Log Destination Tab 229 Cisco Unified CM Tab 232 Advanced Tab 233 Security Tab 236 Language Tab 238 Managing the Cisco Unified CM JTAPI 240 Reinstalling, Upgrading or Downgrading the Cisco JTAPI 240 Uninstalling the Cisco JTAPI 240 Administering User Information for JTAPI Applications 241 Fields in the jtapi.ini File 241 Sample jtapi.ini File with Default Values 247 Cisco Unified JTAPI Extensions 249 C H A P T E R 5 Class Hierarchy 253 CiscoAddressCallInfo 253 Declaration 253 Constructors 254 Fields 254 Methods 254 Inherited Methods 254 Related Documentation 254 CiscoG711MediaCapability 255 Declaration 255 Constructors 255 Fields 255 Inherited Fields 256 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xii Contents

Page 12 content

Page 13

Methods 256 Inherited Methods 256 Related Documentation 256 CiscoG723MediaCapability 256 Declaration 256 Constructors 257 Fields 257 Inherited Fields 257 Methods 257 Inherited Methods 258 Related Documentation 258 CiscoG729MediaCapability 258 Declaration 258 Constructors 258 Fields 259 Inherited Fields 259 Methods 259 Inherited Methods 259 Related Documentation 259 CiscoGSMMediaCapability 259 Declaration 260 Constructors 260 Fields 260 Inherited Fields 260 Methods 260 Inherited Methods 261 Related Documentation 261 CiscoJtapiVersion 261 Declaration 261 Constructors 261 Fields 261 Methods 262 Inherited Methods 262 Related Documentation 262 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xiii Contents

Page 13 content

Page 14

CiscoMediaCapability 262 Declaration 263 Subclasses 263 Constructors 263 Fields 263 Methods 264 Inherited Methods 264 Related Documentation 264 CiscoMultiMediaCapabilityInfo 264 Declaration 264 Fields 265 Methods 265 CiscoRegistrationException 265 Declaration 266 Implemented Interfaces 266 Constructors 266 Methods 266 Inherited Methods 266 Related Documentation 266 CiscoRTPParams 267 Declaration 267 Constructors 267 Fields 267 Methods 267 Inherited Methods 268 Related Documentation 268 CiscoUnregistrationException 268 Declaration 268 Implemented Interfaces 268 Constructors 268 Fields 269 Methods 269 Inherited Methods 269 Related Documentation 269 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xiv Contents

Page 14 content

Page 15

CiscoWideBandMediaCapability 269 Declaration 269 Constructors 270 Fields 270 Inherited Fields 270 Methods 270 Inherited Methods 270 Related Documentation 270 Interface Hierarchy 271 CiscoAddrActivatedEv 277 Superinterfaces 278 Declaration 278 Fields 278 Inherited Fields 278 Methods 278 Inherited Methods 279 Related Documentation 279 Superinterfaces 279 Declaration 279 Fields 279 Inherited Fields 279 Methods 280 Inherited Methods 280 Related Documentation 281 CiscoAddrActivatedOnTerminalEv 281 Superinterfaces 281 Declaration 281 Fields 281 Inherited Fields 282 Methods 282 Inherited Methods 282 Related Documentation 283 CiscoAddrAddedToTerminalEv 283 Superinterfaces 283 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xv Contents

Page 15 content

Page 16

Declaration 283 Fields 283 Inherited Fields 283 Methods 284 Inherited Methods 284 Related Documentation 284 CiscoAddrAutoAcceptStatusChangedEv 284 Superinterfaces 285 Declaration 285 Fields 285 Inherited Fields 285 Methods 286 Inherited Methods 286 Related Documentation 286 CiscoAddrCreatedEv 286 Superinterfaces 286 Declaration 287 Fields 287 Inherited Fields 287 Methods 287 Inherited Methods 288 Related Documentation 288 CiscoAddrMonitorTerminatedEv 288 Declaration 288 Methods 288 Related Documentation 289 CiscoAddress 289 Superinterfaces 290 Subinterfaces 290 Fields 290 Methods 291 Inherited Methods 303 Parameters 303 Related Documentation 303 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xvi Contents

Page 16 content

Page 17

CiscoAddressObserver 303 Superinterfaces 303 Declaration 303 Fields 303 Methods 304 Inherited Methods 304 Related Documentation 304 CiscoAddrEv 304 Superinterfaces 304 Subinterfaces 304 Declaration 304 Fields 304 Inherited Fields 305 Methods 305 Inherited Methods 305 Related Documentation 305 CiscoAddrEvFilter 305 Fields 306 Methods 306 Inherited Methods 308 Parameters 308 Value Range 308 Related Documentation 308 CiscoAddrInServiceEv 308 Superinterfaces 308 Declaration 308 Fields 308 Inherited Fields 309 Methods 309 Inherited Methods 309 Related Documentation 309 CiscoAddrIntercomInfoChangedEv 310 Superinterfaces 310 Declaration 310 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xvii Contents

Page 17 content

Page 18

Fields 310 Inherited Fields 310 Methods 311 Inherited Methods 311 Related Documentation 311 CiscoAddrIntercomInfoRestorationFailedEv 311 Superinterfaces 312 Declaration 312 Fields 312 Inherited Fields 312 Methods 312 Inherited Methods 313 Related Documentation 313 CiscoAddrPickupGroupChangedEv 313 Declaration 313 Methods 313 New Error Code 314 CiscoAddrOutOfServiceEv 314 Superinterfaces 314 Declaration 314 Fields 314 Inherited Fields 314 Methods 315 Inherited Methods 315 Related Documentation 316 CiscoAddrParkStatusEv 316 Declaration 316 Fields 316 Inherited Fields 317 Methods 317 Value Ranges 317 Related Documentation 317 CiscoAddrRecordingConfigChangedEv 318 Superinterfaces 318 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xviii Contents

Page 18 content

Page 19

Declaration 318 Fields 318 Inherited Fields 318 Methods 319 Inherited Methods 319 Related Documentation 319 CiscoAddrRemovedEv 319 Superinterfaces 320 Declaration 320 Fields 320 Inherited Fields 320 Methods 320 Inherited Methods 321 Related Documentation 321 CiscoAddrRemovedFromTerminalEv 321 Superinterfaces 321 Declaration 321 Fields 322 Inherited Fields 322 Methods 322 Inherited Methods 322 Related Documentation 323 CiscoAddrRestrictedEv 323 Superinterfaces 323 Declaration 323 Fields 323 Inherited Fields 324 Methods 324 Inherited Methods 324 Related Documentation 325 CiscoAddrRestrictedOnTerminalEv 325 Superinterfaces 325 Declaration 325 Fields 325 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xix Contents

Page 19 content

Page 20

Inherited Fields 325 Methods 326 Inherited Methods 326 Related Documentation 326 CiscoAddrVoiceMailPilotChangedEv 326 Superinterfaces 327 Declaration 327 Fields 327 Inherited Fields 327 Methods 327 Inherited Methods 328 Related Documentation 328 CiscoAnnouncementStartedEv 328 Declaration 328 Methods 328 CiscoAnnouncementEndedEv 328 Declaration 328 Methods 329 CiscoAnnouncementErrorEv 329 Declaration 329 Methods 329 CiscoBaseMediaTerminal 329 Declaration 330 Superinterfaces 330 Fields 330 Inherited Fields 330 Methods 330 Inherited Methods 331 Parameters 331 Data Types 331 Range of Values 331 CiscoCall 332 Superinterfaces 333 Subinterfaces 333 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xx Contents

Page 20 content

Page 21

Declaration 333 Fields 333 Inherited Fields 335 Methods 336 Inherited Methods 339 Parameters 339 Conference Controller 339 Telephone Call Argument 339 Other Shared Participants 340 The Transfer Controller 342 The New Connection 342 Related Documentation 345 CiscoCallChangedEv 345 Superinterfaces 346 Declaration 346 Fields 346 Inherited Fields 346 Methods 348 Inherited Methods 348 Related Documentation 348 CiscoCallConsultCancelledEv 349 Superinterfaces 349 Declaration 349 Fields 349 Inherited Fields 349 Methods 349 Inherited Methods 349 Related Documentation 350 CiscoCallCtlConnOfferedEv 350 Superinterfaces 350 Declaration 350 Fields 350 Inherited Fields 350 Methods 351 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxi Contents

Page 21 content

Page 22

Inherited Methods 351 Related Documentation 352 CiscoCallCtlTermConnHeldReversionEv 352 Superinterfaces 352 Declaration 352 Fields 353 Inherited Fields 353 Methods 353 Inherited Methods 354 Related Documentation 354 CiscoCallEv 354 Superinterfaces 355 Subinterfaces 355 Declaration 355 Fields 355 Inherited Fields 364 Methods 364 Related Documentation 365 CiscoCallFeatureCancelledEv 365 Declaration 365 Methods 365 Related Documentation 366 CiscoCallID 366 Superinterfaces 366 Declaration 366 Fields 366 Methods 366 Inherited Methods 367 Related Documentation 367 CiscoMediaCallSecurityIndicator 367 Declaration 367 Fields 367 Methods 367 Related Documentation 368 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxii Contents

Page 22 content

Page 23

CiscoCallSecurityStatusChangedEv 368 Superinterfaces 368 Declaration 368 Fields 368 Inherited Fields 368 Methods 370 Inherited Methods 370 Related Documentation 371 CiscoConferenceChain 371 Declaration 371 Fields 371 Methods 371 Related Documentation 372 CiscoConferenceChainAddedEv 372 All Superinterfaces 372 Declaration 372 Fields 372 Inherited Fields 373 Methods 374 Inherited Methods 374 Related Documentation 375 CiscoConferenceChainRemovedEv 375 Superinterfaces 375 Declaration 375 Fields 375 Inherited Fields 376 Methods 377 Inherited Methods 377 Related Documentation 378 CiscoConferenceEndEv 378 Superinterfaces 378 Declaration 378 Fields 378 Inherited Fields 379 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxiii Contents

Page 23 content

Page 24

Methods 380 Inherited Methods 381 Related Documentation 382 CiscoConferenceStartEv 382 Superinterfaces 382 Declaration 382 Fields 382 Inherited Fields 383 Methods 384 Inherited Methods 385 Related Documentation 386 CiscoConnection 386 All Superinterfaces 386 Declaration 386 Fields 387 Inherited Fields 388 Methods 388 Inherited Methods 398 Documentation 398 CiscoConnectionID 398 Superinterfaces 399 Declaration 399 Fields 399 Methods 399 Inherited Methods 399 Related Documentation 399 CiscoConnectionUniqueIDChangedEv 399 Declaration 400 Methods 400 Related Documentation 400 CiscoConsultCall 400 Superinterfaces 400 Declaration 400 Fields 400 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxiv Contents

Page 24 content

Page 25

Inherited Fields 401 Methods 401 Inherited Methods 402 Related Documentation 403 CiscoConsultCallActiveEv 403 Superinterfaces 403 Declaration 403 Fields 403 Inherited Fields 404 Methods 405 Inherited Methods 406 Related Documentation 406 CiscoEv 407 Superinterfaces 407 Subinterfaces 407 Declaration 407 Fields 407 Inherited Fields 408 Methods 408 Inherited Methods 408 Related Documentation 408 CiscoFeatureReason 408 Declaration 409 Fields 409 Related Documentation 411 CiscoHuntConnection 411 Declaration 411 Methods 411 Related Documentation 411 CiscoIntercomAddress 411 Superinterfaces 412 Declaration 412 Fields 412 Inherited Fields 412 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxv Contents

Page 25 content

Page 26

Methods 413 Inherited Methods 414 Related Documentation 415 CiscoIsacMediaCapability 415 Superinterfaces 415 Declaration 415 Constuctors 415 Fields 416 Inherited Fields 416 Methods 416 Inherited Methods 416 CiscoJtapiException 416 Declaration 418 Fields 418 Inherited Fields 430 Methods 430 Inherited Methods 431 Related Documentation 431 CiscoMediaStreamStartedEv 431 Declaration 431 Fields 431 Inherited Fields 431 Methods 431 Inherited Methods 431 CiscoMediaStreamEndedEv 432 Declaration 432 Fields 432 Inherited Fields 432 Methods 432 Inherited Methods 433 CiscoJtapiPeer 433 Superinterfaces 433 Declaration 433 Fields 433 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxvi Contents

Page 26 content

Page 27

Methods 433 Inherited Methods 434 Related Documentation 434 CiscoJtapiPeerImpl 434 Declaration 434 Fields 434 Methods 434 CiscoJtapiProperties 435 Declaration 436 Fields 436 Methods 436 User/InstanceID Hash Table 442 Related Documentation 442 CiscoLocales 442 Declaration 443 Fields 443 Methods 444 Related Documentation 445 CiscoMasterKeyIndicator 445 Declaration 445 Methods 445 CiscoMediaConnectionMode 445 Declaration 445 Fields 446 Methods 446 Related Documentation 446 CiscoMediaEncryptionAlgorithmType 446 Superinterfaces 446 Fields 447 Related Documentation 447 CiscoMediaEncryptionKeyInfo 447 Declaration 447 Fields 447 Methods 447 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxvii Contents

Page 27 content

Page 28

Related Documentation 448 CiscoMediaOpenIPPortEv 448 Declaration 449 Superinterfaces 449 Fields 449 Inherited Fields 449 Methods 449 Inherited Methods 449 CiscoMediaOpenLogicalChannelEv 449 Superinterfaces 450 Declaration 450 Fields 450 Inherited Fields 451 Methods 451 Inherited Methods 452 Related Documentation 453 CiscoMediaSecurityIndicator 453 Declaration 453 Fields 453 Related Documentation 454 CiscoMediaTerminal 454 Superinterfaces 454 Declaration 454 Fields 455 Inherited Fields 455 Methods 455 Inherited Methods 465 Related Documentation 465 CiscoMonitorInitiatorInfo 465 Declaration 466 Fields 466 Methods 466 Related Documentation 466 CiscoMonitorTargetInfo 466 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxviii Contents

Page 28 content

Page 29

Declaration 466 Fields 466 Methods 467 Related Documentation 467 CiscoMultiForkingRecorderInfo 467 Declaration 467 Methods 468 CiscoMultiMediaCapabilityInfo 468 Declaration 468 Fields 469 Methods 469 CiscoMultiMediaConnectionMode 470 Declaration 470 Methods 470 CiscoMultiMediaEncryptionKeyInfo 470 Declaration 470 Methods 471 CiscoMultiMediaProperties 471 Declaration 471 Methods 471 CiscoMultiMediaStreamsInfoEv 472 Declaration 473 Methods 473 CiscoMultiMediaType 473 Declaration 473 Methods 473 CiscoObjectContainer 474 Subinterfaces 474 Declaration 474 Fields 474 Methods 474 Related Documentation 475 CiscoOutOfServiceEv 475 Superinterfaces 475 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxix Contents

Page 29 content

Page 30

Subinterfaces 475 Declaration 475 Fields 475 Inherited Fields 476 Methods 476 Related Documentation 476 CiscoPartyInfo 476 Declaration 477 Fields 477 Methods 477 Related Documentation 478 CiscoPickupGroup 478 Declaration 478 Methods 479 Related Documentation 479 CiscoProvCallParkEv 479 Superinterfaces 479 Declaration 479 Fields 479 Inherited Fields 480 Methods 480 Inherited Methods 481 Related Documentation 481 CiscoProvEv 481 Superinterfaces 482 Subinterfaces 482 Declaration 482 Fields 482 Inherited Fields 482 Methods 483 Inherited Methods 483 CiscoProvFeatureEv 483 Superinterfaces 484 Subinterfaces 484 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxx Contents

Page 30 content

Page 31

Declaration 484 Fields 484 Inherited Fields 484 Methods 485 Inherited Methods 485 Related Documentation 485 CiscoProvFeatureID 485 Declaration 486 Fields 486 Methods 487 Related Documentation 487 CiscoProvPickupCallAlertEv 487 Declaration 487 Methods 487 CiscoProvTerminalIPAddressChangedEv 488 Declaration 488 Fields 488 Methods 489 Related Documentation 489 CiscoProvTerminalMultiMediaCapabilityChangedEv 489 Declaration 489 Methods 489 CiscoProvTerminalRegisteredEv 490 Declaration 490 Fields 490 Methods 490 Related Documentation 490 CiscoProvTerminalUnRegisteredEv 491 Declaration 491 Fields 491 Methods 491 Related Documentation 491 CiscoProvider 492 Superinterfaces 492 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxxi Contents

Page 31 content

Page 32

Declaration 493 Fields 493 Inherited Fields 493 New Error Codes 493 Methods 494 Inherited Methods 504 Related Documentation 504 CiscoProviderCapabilities 504 Superinterfaces 504 Declaration 504 Methods 505 Inherited Methods 506 Related Documentation 506 CiscoProviderCapabilityChangedEv 506 Declaration 506 Fields 507 Methods 507 Related Documentation 508 CiscoProviderObserver 508 Superinterfaces 508 Declaration 509 Methods 509 Inherited Methods 509 Related Documentation 509 CiscoProvTerminalCapabilityChangedEv 509 Superinterfaces 509 Declaration 509 Fields 510 Inherited Fields 510 Methods 510 Inherited Methods 510 Related Documentation 511 CiscoProvTerminalRemoteDestinationChangedEv 511 Methods 511 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxxii Contents

Page 32 content

Page 33

CiscoRecorderInfo 511 Declaration 512 Fields 512 Methods 512 Range of Values 513 Related Documentation 513 CiscoRemoteDestinationInfo 513 Methods 513 CiscoRemoteTerminal 514 Declaration 514 Methods 514 Parameters 516 Data Type 517 New Error Codes 517 Sample Code 517 CiscoRestrictedEv 519 Superinterfaces 519 Subinterfaces 519 Declaration 519 Fields 519 Inherited Fields 520 Methods 520 Inherited Methods 520 Related Documentation 520 CiscoRouteAddress 521 Superinterfaces 521 Declaration 521 Fields 521 Inherited Fields 521 Methods 521 Inherited Methods 521 Related Documentation 522 CiscoRouteEvent 522 Superinterfaces 522 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxxiii Contents

Page 33 content

Page 34

Declaration 522 Fields 522 Inherited Fields 522 Methods 523 Inherited Methods 523 Related Documentation 523 CiscoRouteSession 523 Superinterfaces 524 Declaration 524 Fields 524 Inherited Fields 526 Methods 526 Inherited Methods 542 Related Documentation 542 CiscoRouteTerminal 542 Superinterfaces 543 Declaration 544 Fields 544 Inherited Fields 544 Methods 545 Inherited Methods 550 Related Documentation 551 CiscoRouteUsedEvent 551 Superinterfaces 551 Declaration 551 Fields 551 Methods 551 Inherited Methods 552 Related Documentation 552 CiscoRTPBitRate 552 Declaration 552 Fields 552 Methods 552 Related Documentation 553 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxxiv Contents

Page 34 content

Page 35

CiscoRTPHandle 553 Declaration 553 Fields 553 Methods 553 Related Documentation 553 CiscoRTPInputKeyEv 554 Superinterfaces 554 Declaration 554 Fields 554 Inherited Fields 554 Methods 555 Inherited Methods 555 Related Documentation 556 CiscoRTPInputProperties 556 Declaration 556 Fields 556 Methods 556 Related Documentation 557 CiscoRTPInputStartedEv 557 Superinterfaces 557 Declaration 557 Fields 558 Inherited Fields 558 Methods 558 Inherited Methods 559 Related Documentation 559 CiscoRTPInputStoppedEv 559 Superinterfaces 559 Declaration 559 Fields 559 Inherited Fields 560 Methods 560 Inherited Methods 561 Related Documentation 561 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxxv Contents

Page 35 content

Page 36

CiscoRTPOutputKeyEv 561 Superinterfaces 561 Declaration 561 Fields 561 Inherited Fields 562 Methods 562 Inherited Methods 563 Related Documentation 563 CiscoRTPOutputProperties 563 Declaration 563 Fields 563 Methods 564 Related Documentation 565 CiscoRTPOutputStartedEv 565 Superinterfaces 565 Declaration 565 Fields 565 Inherited Fields 565 Methods 566 Inherited Methods 566 Related Documentation 567 CiscoRTPOutputStoppedEv 567 Superinterfaces 567 Declaration 567 Fields 567 Inherited Fields 567 Methods 568 Inherited Methods 568 Related Documentation 568 CiscoRTPOutputKeyEv 569 Superinterfaces 569 Declaration 569 Fields 569 Inherited Fields 569 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxxvi Contents

Page 36 content

Page 37

Methods 570 Inherited Methods 570 Related Documentation 571 CiscoRTPOutputProperties 571 Declaration 571 Fields 571 Methods 571 Related Documentation 572 CiscoRTPOutputStartedEv 572 Superinterfaces 573 Declaration 573 Fields 573 Inherited Fields 573 Methods 574 Inherited Methods 574 Related Documentation 574 CiscoRTPOutputStoppedEv 575 Superinterfaces 575 Declaration 575 Fields 575 Inherited Fields 575 Methods 576 Inherited Methods 576 Related Documentation 576 CiscoRTPPayload 577 Declaration 577 Fields 577 Methods 578 Related Documentation 578 CiscoRTPProperties 578 Declaration 579 Methods 579 CiscoSynchronousObserver 580 Declaration 580 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxxvii Contents

Page 37 content

Page 38

Fields 580 Methods 581 Related Documentation 581 CiscoTermActivatedEv 581 Superinterfaces 581 Declaration 581 Fields 581 Inherited Fields 581 Methods 582 Inherited Methods 582 Related Documentation 582 CiscoTermButtonPressedEv 582 Superinterfaces 582 Declaration 583 Fields 583 Inherited Fields 583 Methods 584 Inherited Methods 584 Related Documentation 584 CiscoTermConnMonitoringEndEv 584 Superinterfaces 585 Declaration 585 Fields 585 Inherited Fields 585 Methods 585 Inherited Methods 586 Related Documentation 586 CiscoTermConnMonitoringStartEv 586 Superinterfaces 586 Declaration 586 Fields 586 Inherited Fields 587 Methods 587 Inherited Methods 587 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxxviii Contents

Page 38 content

Page 39

Related Documentation 587 CiscoTermConnMonitorInitiatorInfoEv 587 Superinterfaces 588 Declaration 588 Fields 588 Inherited Fields 588 Methods 588 Inherited Methods 589 Related Documentation 589 CiscoTermConnMonitorTargetInfoEv 589 Superinterfaces 589 Declaration 589 Fields 590 Inherited Fields 590 Methods 590 Inherited Methods 590 Related Documentation 590 CiscoTermConnPrivacyChangedEv 591 Declaration 591 Fields 591 Methods 591 Related Documentation 591 CiscoTermConnRecordingEndEv 591 Superinterfaces 592 Declaration 592 Fields 592 Inherited Fields 592 Methods 592 Inherited Methods 592 Related Documentation 593 CiscoTermConnRecordingStartEv 593 Superinterfaces 593 Declaration 593 Fields 593 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xxxix Contents

Page 39 content

Page 40

Inherited Fields 593 Methods 593 Inherited Methods 593 Related Documentation 594 CiscoTermConnRecordingTargetInfoEv 594 Superinterfaces 594 Declaration 594 Fields 594 Inherited Fields 594 Methods 595 Related Documentation 595 CiscoTermConnRecordingFailedEv 595 Superinterfaces 595 Declaration 595 Fields 596 Inherited Fields 596 Methods 596 Inherited Methods 596 Related Documentation 596 CiscoTermConnSelectChangedEv 596 Superinterfaces 597 Declaration 597 Fields 597 Inherited Fields 597 Methods 597 Inherited Methods 597 Related Documentation 598 CiscoTermCreatedEv 598 Superinterfaces 598 Declaration 598 Fields 598 Inherited Fields 598 Methods 599 Inherited Methods 599 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xl Contents

Page 40 content

Page 41

Related Documentation 599 CiscoTermDataEv 599 Superinterfaces 600 Declaration 600 Fields 600 Inherited Fields 600 Methods 600 Inherited Methods 601 Related Documentation 601 CiscoTermDeviceStateActiveEv 601 Superinterfaces 601 Declaration 601 Fields 601 Inherited Fields 602 Methods 602 Inherited Methods 602 Related Documentation 602 CiscoTermDeviceStateAlertingEv 602 Superinterfaces 603 Declaration 603 Fields 603 Inherited Fields 603 Methods 604 Inherited Methods 604 Related Documentation 604 CiscoTermDeviceStateHeldEv 604 Superinterfaces 604 Declaration 604 Fields 605 Inherited Fields 605 Methods 605 Inherited Methods 605 Related Documentation 606 CiscoTermDeviceStateIdleEv 606 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xli Contents

Page 41 content

Page 42

Superinterfaces 606 Declaration 606 Fields 606 Inherited Fields 606 Methods 607 Inherited Methods 607 Related Documentation 607 CiscoTermDeviceStateWhisperEv 607 Superinterfaces 607 Declaration 608 Fields 608 Inherited Fields 608 Methods 608 Inherited Methods 608 Related Documentation 609 CiscoTermDNDOptionChangedEv 609 Superinterfaces 609 Fields 609 Methods 610 CiscoTermDNDStatusChangedEv 610 Superinterfaces 611 Declaration 611 Fields 611 Inherited Fields 611 Methods 612 Inherited Methods 612 Related Documentation 612 CiscoTermEv 612 Superinterfaces 612 Subinterfaces 612 Declaration 613 Fields 613 Inherited Fields 613 Methods 613 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xlii Contents

Page 42 content

Page 43

Inherited Methods 613 Related Documentation 614 CiscoTermEvFilter 614 Declaration 614 Fields 614 Methods 614 Related Documentation 617 CiscoTerminal 617 Superinterfaces 619 Subinterfaces 619 Declaration 619 Fields 619 Methods 621 Inherited Fields 633 Data Type 634 Related Documentation 635 CiscoTerminalConnection 636 Superinterfaces 636 Declaration 636 Fields 636 Inherited Fields 637 Parameters 637 New Error Codes 637 Methods 639 Inherited Methods 642 Related Documentation 642 CiscoTerminalObserver 643 Superinterfaces 643 Declaration 643 Fields 643 Methods 643 Inherited Methods 643 Related Documentation 643 CiscoTerminalProtocol 643 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xliii Contents

Page 43 content

Page 44

Superinterfaces 644 Fields 644 Related Documentation 644 CiscoTermInServiceEv 644 Superinterfaces 645 Declaration 645 Fields 645 Inherited Fields 645 Methods 646 Inherited Methods 646 Related Documentation 646 CiscoTermOutOfServiceEv 647 Superinterfaces 647 Declaration 647 Fields 647 Inherited Fields 647 Methods 648 Inherited Methods 648 Related Documentation 648 CiscoTermRegistrationFailedEv 648 Superinterfaces 649 Declaration 649 Fields 649 Inherited Fields 650 Methods 651 Inherited Methods 651 Related Documentation 651 CiscoTermRemovedEv 651 Superinterfaces 651 Declaration 651 Fields 652 Inherited Fields 652 Methods 652 Inherited Methods 652 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xliv Contents

Page 44 content

Page 45

Related Documentation 653 CiscoTermRestrictedEv 653 Superinterfaces 653 Declaration 653 Fields 653 Inherited Fields 653 Methods 654 Inherited Methods 654 Related Documentation 654 CiscoTermSnapshotCompletedEv 654 Superinterfaces 655 Declaration 655 Fields 655 Inherited Fields 655 Methods 655 Inherited Methods 656 Related Documentation 656 CiscoTermSnapshotEv 656 Superinterfaces 656 Declaration 656 Fields 657 Inherited Fields 657 Methods 657 Inherited Methods 657 Related Documentation 658 CiscoTone 658 Superinterfaces 658 Fields 658 CiscoToneChangedEv 659 Superinterfaces 659 Declaration 659 Fields 659 Inherited Fields 661 Methods 661 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xlv Contents

Page 45 content

Page 46

Inherited Methods 662 Related Documentation 662 CiscoTransferEndEv 662 Superinterfaces 662 Declaration 662 Fields 662 Inherited Fields 663 Methods 664 Inherited Methods 665 Related Documentation 665 CiscoTransferStartEv 665 Superinterfaces 666 Declaration 666 Fields 666 Inherited Fields 666 Methods 668 Inherited Methods 668 Related Documentation 669 CiscoUrlInfo 669 Declaration 669 Fields 669 Methods 670 Related Documentation 670 ComponentUpdater 670 Declaration 670 Methods 670 Related Documentation 671 ProviderPickupNotificationRegistrationClosedEv 671 Declaration 671 Methods 671 New Reason Code 672 Related Documentation 672 CiscoTermHuntLogStatusChangedEv 672 Declaration 672 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xlvi Contents

Page 46 content

Page 47

Methods 672 CiscoProvConnToLeastPriorCtiServerEv 672 CiscoProvFallbackToPrimNwCompltdEv 673 CiscoProvPrimNwReachableEv 674 Cisco Unified JTAPI Alarms and Services 675 C H A P T E R 6 Alarm Class Hierarchy 676 AlarmManager 676 Declaration 677 Constructors 677 Methods 678 AlarmWriter 678 Declaration 678 All Known Implementing Classes 678 Member Summary 678 Methods 679 DefaultAlarm 680 Declaration 680 All Implemented Interfaces 680 Member Summary 680 Constructors 681 Methods 681 DefaultAlarmWriter 682 Declaration 682 All Implemented Interfaces 682 Member Summary 682 Constructors 683 Methods 684 ParameterList 686 Declaration 686 Member Summary 686 Constructors 687 Methods 687 Alarm Interface Hierarchy 688 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xlvii Contents

Page 47 content

Page 48

Alarm 688 Declaration 689 All Known Implementing Classes 689 Member Summary 689 Fields 691 Methods 692 AlarmWriter 693 Declaration 693 All Known Implementing Classes 693 Member Summary 693 Methods 694 Services Tracing Class Hierarchy 695 BaseTraceWriter 695 Declaration 695 All Implemented Interfaces 695 Direct Known Subclasses 695 Member Summary 696 Constructors 697 Methods 697 ConsoleTraceWriter 699 Declaration 699 All Implemented Interfaces 700 Member Summary 700 Constructors 700 Methods 701 LogFileTraceWriter 701 Declaration 703 All Implemented Interfaces 703 Member Summary 703 Fields 704 Constructors 705 Methods 706 OutputStreamTraceWriter 707 Declaration 708 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xlviii Contents

Page 48 content

Page 49

All Implemented Interfaces 708 Member Summary 708 Constructors 709 Methods 709 SyslogTraceWriter 710 Declaration 710 All Implemented Interfaces 710 Member Summary 710 Constructors 711 Methods 712 TraceManagerFactory 712 Declaration 712 Member Summary 712 Methods 713 Services Tracing Interface Hierarchy 714 Trace 714 Declaration 714 All Known Subinterfaces 715 Member Summary 715 Fields 717 Methods 719 ConditionalTrace 721 Declaration 721 All Superinterfaces 721 Member Summary 721 Methods 722 UnconditionalTrace 722 Declaration 722 All Superinterfaces 722 Member Summary 723 TraceManager 723 Declaration 724 Member Summary 724 Methods 725 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs xlix Contents

Page 49 content

Page 50

TraceModule 727 Declaration 727 All Known Subinterfaces 727 Member Summary 728 Methods 728 TraceWriter 728 Declaration 728 All Known Subinterfaces 728 All Known Implementing Classes 728 Member Summary 729 Methods 729 TraceWriterManager 731 Declaration 731 All Superinterfaces 731 Member Summary 731 Methods 732 Tracing Implementation Class Hierarchy 732 TraceImpl 733 Declaration 733 All Implemented Interfaces 733 Methods 733 Inherited Methods 735 ConditionalTraceImpl 735 Declaration 735 All Implemented Interfaces 735 Methods 735 Inherited Methods 736 UnconditionalTraceImpl 736 Declaration 736 All Implemented Interfaces 737 Methods 737 Inherited Methods 737 TraceManagerImpl 737 Declaration 737 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs l Contents

Page 50 content

Page 51

All Implemented Interfaces 737 Constructors 738 Methods 738 Deprecated 741 Inherited Methods 741 TraceWriterManagerImpl 741 Declaration 741 All Implemented Interfaces 741 Constructors 742 Methods 742 Cisco Unified JTAPI Examples 745 C H A P T E R 7 MakeCall.java 745 Actor.java 747 Originator.java 751 Receiver.java 755 StopSignal.java 756 Trace.java 757 TraceWindow.java 758 Running makecall 759 Message Sequence Charts 761 A P P E N D I X A Agent Greeting 762 API for Exposing Built-in-Bridge Status 766 Backward Compatibility Enhancements 768 Barge and Privacy 782 Barge 783 CBarge 784 Privacy 785 Call Control Discovery 785 CallFwdAll Keys Press Notification 793 Call Recording for SIP or TLS Authenticated calls 796 CallSelect and UnSelect 797 Cius Persistency 798 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs li Contents

Page 51 content

Page 52

Conference and Join 799 Join/Arbitrary Conference 799 Consult Conference 800 Join Across Lines with Enhancements 800 CTI Manager Redundancy Handling with Least Priority CTIManager Configured 805 CTI Manager Redundancy Handling with Least Priority CTI Server Set 806 CTI Remote Device 807 CTI Remote Device Use Cases Group 1 807 CTI Remote Device Use Cases Group 2 821 CTI Remote Device Use Cases Group 3 856 CTI Remote Device Use Cases Group 4 858 CTI Remote Device Use Cases Group 5 860 CTI Remote Device Use Cases Group 6 873 CTI RD Call Forward 876 CTI Video Support 885 Device and Line Restriction 892 Device State Server 895 Do Not Disturb 895 DND-R 899 Dynamic CTIPort Registration Per Call 901 E911 Teleworker 902 Encryption Enhancement 903 End to End Call Tracing 904 Hunt Log Status for Phone Devices 920 Energywise Deep Sleep Mode 923 External Call Control 929 Use Cases for BasicCall 929 Use Cases for Calls Going Through Translation Pattern with CEPN Info in Cc Signals 931 WildCard Routepoint Interaction (Behavior Change) 952 WildCard Routepoint Interaction (Original Behavior) 954 External Call Control Use Cases 956 Chaperone Use Cases 971 Extension Mobility Cross Cluster 978 End to End Session ID for Calls 981 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lii Contents

Page 52 content

Page 53

Forced Authorization and Customer Matter Codes 991 Hairpin Support 998 Half Duplex Media 1000 Hunt List 1000 Hunt List Connected Number 1043 Intercom 1051 iSac Codec 1057 JTAPI Cisco Unified IP 7931G Phone Interaction 1062 Locale Infrastructure Development Scenarios 1084 Calling Party Normalization 1085 Click to Conference 1092 Call Pickup 1109 selectRoute() with Calling Search Space and Feature Priority 1124 Extension Mobility Login Username 1126 Calling Party IP Address 1127 CiscoJtapiProperties 1128 IPv6 Support 1129 Provider Open Scenario 1150 Calling Party IP Address Scenarios 1151 RTP Addresses 1152 CTI Port/Route Point Registration Scenarios 1154 Advance Test Cases 1156 Direct Transfer Across Lines Use Cases 1157 Connected Conference or Join Across Lines Use Cases - New Phones Behavior 1165 Enhanced MWI Use Cases 1166 Join Across Lines Enhancements 1167 Swap or Cancel and Transfer or Conference Behavior Change 1174 Drop Any Party Use Cases 1184 Park Monitoring Support 1206 Use Case 1: Park Monitoring States 1206 Use Case 2: Shared Line Scenario - Cisco Unified IP Phone Does Park 1209 Use Case 3: Shared Line Scenario - Cisco Unified IP Phone 7900 Series with SIP Does Park 1210 Use Case 4: Use Case for Snap Shot Scenario 1211 Use Case 5: Park DN Is Monitored 1214 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs liii Contents

Page 53 content

Page 54

Use Case 6: Query Number of Parked Calls 1214 Use Case 7: Filter Enabling or Disabling 1215 Use Case 8: Filter Enabling or Disabling 1216 Use Case 9: Filter Enabling or Disabling 1216 Use Case 10: Filter Enabling or Disabling 1217 Additional Use Cases for Park Monitoring 1218 Use Cases Related to DPark 1231 Logical Partitioning Feature Use Cases 1233 Shared Lines 1235 Call Park Reversion with Shared Lines in Different Geographic Locations 1235 ComponentUpdater Enhancement Use Cases 1236 IPv6 Support 1236 Support for Cisco Unified IP Phone 6900 Series 1236 Terminal and Address Capability Settings Use Cases 1240 Media Termination at Route Point 1263 Mobility Interaction Support 1265 Modifying Calling Number 1271 AutoAccept for CTIPort and RoutePoint 1274 Silent Monitoring Use Cases 1274 Secured Monitoring Use Cases 1282 Native Queuing 1287 Queuing of Call 1288 Maximum In-Queue Timer Expires 1293 Maximum In-Queue Timer Expires with Destination as Another HP Whose Member E Is Free 1294 Maximum In-Queue Timer Expires with Destination as Another HP Whose Members Are Busy 1295 Queue Is Full 1298 When Disconnect Is Selected for Queue Full 1300 No Agents Are Logged In 1302 Caller Redirects While in Queue 1302 Caller (Observed) Conferences While in Queue 1304 Use Cases for NuRD (Number Matching for Remote Destination) 1307 Basic Calls Initiated From Remote Destination 1307 Basic Calls to Remote Destination 1310 CTIRD/RDP Interaction 1313 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs liv Contents

Page 54 content

Page 55

Multiple Calls 1323 Partition Support 1337 Using getPartition() API 1337 Using getAddress (String Number String Partition) 1337 Park DN 1339 Partition Change 1340 JTAPI Partition Support 1341 Persistent Connection Use Cases 1343 Play Announcement 1356 Basic Play Announcement Use Cases 1357 Play Announcement Feature Interaction Use Cases 1384 Play Zip Tone 1390 QoS Support 1391 JTAPI QoS 1391 QSIG Path Replacement 1392 Recording Use Cases 1394 Recording IP Phones 1396 CTI Remote Devices Use Cases 1405 Feature Interaction: Recording Use Cases 1410 Recording Fail Event 1439 Secured Recording 1446 Redirect Set OriginalCalledID 1447 Redirect to a Device 1449 Verify Remote Destination Support 1452 Secure Conferencing 1455 Secure Connection Enhancements 1459 Secure Icon Enhancements 1459 Shared Line Support 1471 AddressInService/AddressOutofService Events 1471 Incoming Call to Shared Address 1472 Outgoing Call From Shared Address 1473 Shared Address Calling Itself 1474 Single Sign-On 1474 Single Step Transfer 1475 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lv Contents

Page 55 content

Page 56

SIP REPLACE 1478 SIP REFER 1484 IN-Dialog REFER Scenario 1484 OutOfDialog Refer 1491 SIP 3XX Redirection 1493 SIP Support 1497 SIP Trunk Early Offer 1498 SRTP Key Material 1509 Super Provider Message Flow 1510 SuperProvider and Change Notification Enhancements Use Cases 1510 Support for Cisco Unified IP Phone 6901 1512 SHA Support for Digital Signatures 1535 TLS Security 1536 Transfer and Direct Transfer 1538 DirectTransfer/Arbitrary Transfer Scenario 1539 Direct Transfer/Arbitrary Transfer-Page 2 1540 Consult Transfer 1540 Unicode Support 1541 Unrestricted Unified CM 1541 Video Capabilities and Multi-Media Information 1542 Scenario One 1542 Scenario Two 1543 Scenario Three 1543 Scenario Four 1544 Scenario Five 1545 Scenario Six 1545 Scenario Seven 1546 Scenario Eight 1546 Scenario Nine 1549 Scenario Ten 1551 Scenario Eleven 1553 Scenario Twelve 1556 Scenario Thirteen 1560 Scenario Fourteen 1563 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lvi Contents

Page 56 content

Page 57

Scenario Fifteen 1566 Scenario Sixteen 1568 Scenario Seventeen 1570 Scenario Eighteen 1572 Scenario Nineteen 1574 Scenario Twenty 1578 Video On Hold 1581 Verification Involving PSTN Reachability 1583 Whisper Coaching 1588 Cisco Unified JTAPI Classes and Interfaces 1605 A P P E N D I X B Cisco Unified JTAPI Version 1.2 Classes and Interfaces 1605 Core Package 1606 Call Center Package 1609 Call Center Capabilities Package 1611 Call Center Events Package 1612 Call Control Package 1614 Call Control Capabilities Package 1616 Call Control Events Package 1618 Capabilities Package 1619 Events Package 1620 Media Package 1621 Media Capabilities Package 1622 Media Events Package 1622 Unsupported Packages 1622 Cisco Unified JTAPI Extension Classes and Interfaces 1623 Cisco Unified JTAPI Extension Classes 1623 Cisco Unified JTAPI Extension Interfaces 1623 Cisco Trace Logging Classes and Interfaces 1628 Cisco Trace Logging Classes 1628 Cisco Trace Logging Interfaces 1629 Troubleshooting Cisco Unified JTAPI 1631 A P P E N D I X C CTI Error Codes 1631 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lvii Contents

Page 57 content

Page 58

CiscoEventIDs 1641 Provider Events 1641 Terminal Events 1642 Address Events 1642 Call Events 1643 RTP Events 1644 TermConn Events 1644 Conn Events 1645 Reason Codes 1645 Cause Codes 1646 Additional Troubleshooting Information 1651 Viewing JTAPI Debug Output 1651 Log Files for JTAPI Client Installer 1652 Troubleshooting Tips for ISMP Installer 1652 Unable to Create Provider Directory Login Timeout 1653 Cisco Unified JTAPI Operations by Release 1655 A P P E N D I X D JTAPI Operations-by-Release 1655 CTI Supported Devices 1661 A P P E N D I X E CTI Supported Devices Table 1661 Constant Field Values 1667 A P P E N D I X F com.cisco.* 1667 CiscoAddrActivatedEv 1667 CiscoAddrActivatedOnTerminalEv 1667 CiscoAddrAddedToTerminalEv 1667 CiscoAddrAutoAcceptStatusChangedEv 1667 CiscoAddrCreatedEv 1668 CiscoAddress 1668 CiscoAddrInServiceEv 1669 CiscoAddrIntercomInfoChangedEv 1669 CiscoAddrIntercomInfoRestorationFailedEv 1669 CiscoAddrOutOfServiceEv 1669 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lviii Contents

Page 58 content

Page 59

CiscoAddrRecordingConfigChangedEv 1669 CiscoAddrRemovedEv 1669 CiscoAddrRemovedFromTerminalEv 1669 CiscoAddrRestrictedEv 1670 CiscoAddrRestrictedOnTerminalEv 1670 CiscoCall 1670 CiscoCallChangedEv 1671 CiscoCallCtlTermConnHeldReversionEv 1671 CiscoCallEv 1671 CiscoCallSecurityStatusChangedEv 1676 CiscoConferenceChainAddedEv 1676 CiscoConferenceChainRemovedEv 1676 CiscoConferenceEndEv 1676 CiscoConferenceStartEv 1676 CiscoConnection 1676 CiscoConnectionUniqueIDChangedEv 1677 CiscoConsultCallActiveEv 1677 CiscoFeatureReason 1677 CiscoG711MediaCapability 1679 CiscoG723MediaCapability 1679 CiscoG729MediaCapability 1679 CiscoGSMMediaCapability 1679 CiscoJtapiException 1679 CiscoJtapiProperties 1687 CiscoLocales 1687 CiscoMediaConnectionMode 1689 CiscoMediaEncryptionAlgorithmType 1689 CiscoMediaOpenLogicalChannelEv 1689 CiscoMediaSecurityIndicator 1689 CiscoOutOfServiceEv 1690 CiscoPartyInfo 1690 CiscoProvCallParkEv 1691 CiscoProvFeatureID 1691 CiscoProviderCapabilityChangedEv 1691 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lix Contents

Page 59 content

Page 60

CiscoProvTerminalCapabilityChangedEv 1691 CiscoRemoteTerminal 1692 CiscoRestrictedEv 1692 CiscoRouteSession 1692 CiscoRouteTerminal 1693 CiscoRTPBitRate 1693 CiscoRTPInputKeyEv 1693 CiscoRTPInputStartedEv 1693 CiscoRTPInputStoppedEv 1693 CiscoRTPOutputKeyEv 1694 CiscoRTPOutputStartedEv 1694 CiscoRTPOutputStoppedEv 1694 CiscoRTPPayload 1694 CiscoTermActivatedEv 1695 CiscoTermButtonPressedEv 1695 CiscoTermConnMonitoringEndEv 1696 CiscoTermConnMonitoringStartEv 1696 CiscoTermConnMonitorInitiatorInfoEv 1696 CiscoTermConnMonitorTargetInfoEv 1696 CiscoTermConnPrivacyChangedEv 1696 CiscoTermConnRecordingEndEv 1697 CiscoTermConnRecordingStartEv 1697 CiscoTermConnRecordingTargetInfoEv 1697 CiscoTermConnSelectChangedEv 1697 CiscoTermCreatedEv 1697 CiscoTermDataEv 1697 CiscoTermDeviceStateActiveEv 1697 CiscoTermDeviceStateAlertingEv 1698 CiscoTermDeviceStateHeldEv 1698 CiscoTermDeviceStateIdleEv 1698 CiscoTermDeviceStateWhisperEv 1698 CiscoTermDNDOptionChangedEv 1698 CiscoTermDNDStatusChangedEv 1698 CiscoTerminal 1698 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lx Contents

Page 60 content

Page 61

CiscoTerminalConnection 1701 CiscoTerminalProtocol 1702 CiscoTermInServiceEv 1702 CiscoTermOutOfServiceEv 1702 CiscoTermRegistrationFailedEv 1702 CiscoTermRemovedEv 1703 CiscoTermRestrictedEv 1703 CiscoTermSnapshotCompletedEv 1703 CiscoTermSnapshotEv 1703 CiscoTone 1703 CiscoToneChangedEv 1704 CiscoTransferEndEv 1704 CiscoTransferStartEv 1704 CiscoUrlInfo 1704 CiscoWideBandMediaCapability 1704 Alarm 1705 LogFileTraceWriter 1705 Trace 1705 Caveats 1707 A P P E N D I X G Caveats for All Releases 1707 Single Versus Multiple CallObserver Clarification 1708 SIP and SCCP Dialing Differences with Overlapping Directory Number Patterns 1708 Translation Pattern Support 1709 DT24+ Limitation with PRI NI2 Trunk 1709 Connection for Park Number Not Created 1710 Inconsistency Between SIP and SCCP Phone 1710 Failure to Route Calls Across Destinations 1710 Incorrect Return Value for getCallingAddress() 1710 Call Fails to Disconnect Held Shared Line 1711 Limitation with sendData() API on CiscoTerminal 1711 Limitation in Using ; (Semi-Colon) and = (Equal) in User ID and Password 1711 Connection to Unknown Address When Unparking a Conference Call 1711 CTI Redirect to Voice Mail Wont Work with QSIG 1712 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lxi Contents

Page 61 content

Page 62

CiscoAddress.getForwarding() Returns Correct Value Only for In-Service Addresses 1712 Unsupported CTI Events for SIP Phones 1712 Caveats for Release 9.1(1) 1712 Connection for Park DN While UnPark 1713 Caveats for Release 8.6(1) 1714 Limitation While Using a Cisco Telepresense MCU 1714 Caveats for Release 8.5(1) 1714 Discouraged Use of JTAPIProperties.updateCertificate() 1714 Delete SecurityProperties Before Re-Use 1715 No ConnDisconnectedEv Event When Call Is Rejected 1715 Caveats for Release 8.0(1) 1716 Globalized Calling Party Number 1716 Conference Interaction with Chaperone Results in Unsupported Conference Chaining 1716 Wildcard Routepoint Interaction 1717 Inconsistent Address Type of ModifiedCalledAddress When a Call Is Made to a Hunt Pilot 1717 Caveats for Release 7.0.1 1717 Inconsistency in getModifiedCallingAddress() 1717 Conference Behavior for Selected and Active Calls 1717 Change in GlobalizedCallingParty Behavior 1718 Caveats for Release 6.0.1 1719 Call History Might Get Lost When AAR Routes Over QSIG Trunk 1719 Different Event Order If Consult Call Initiated on SIP Device 1719 Caveats for Release 5.0 1719 SRTP Support 1720 Partition Support 1720 TLS Security 1720 CiscoFeatureReason 1720 Unicode Issue in Calls Involving SIP Trunks 1720 Join Across Lines: Conference Two or More Addresses on Same Terminal 1721 JTAPI Exposes Incorrect Information with getCallingAddress() and getCalledAddress() 1722 Caveats for Release 4.1 1723 FAC-CMC 1723 setConferenceController 1723 Interval During DTMF Digits 1724 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lxii Contents

Page 62 content

Page 63

Shared Lines Support 1724 CP Requires Previous Calls on the Device to Be in Connected Call State 1724 CallInfo for Calls on QSIG Trunk 1724 Caveats for 4.0 1724 Extra Connection with Wild Card DN 1725 CallInfo in Barge Scenario 1725 CallInfo Issues When Caller Redirects Call 1725 Translation Pattern and Presentation Indication Interaction 1725 Extra TermConnHeld Events 1725 Transfer and Conference Interaction 1725 Dropping a Call on Shared Lines 1726 Barge Call 1726 Null lastRedirectingAddress 1726 Devices Configured with Same CLI 1726 Current Called Address 1727 Deprecated API 1729 A P P E N D I X H Deprecated Interfaces 1729 Deprecated Fields 1729 Deprecated Methods 1730 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs lxiii Contents

Page 63 content

Page 64

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

Page 64 content

Page 65

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

Image 1 from page 65

Page 65 content

Page 66

• 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

Page 66 content

Page 67

• 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)

Image 1 from page 67

Page 67 content

Page 68

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)

Page 68 content

Page 69

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)

Page 69 content

Page 70

• 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)

Page 70 content

Page 71

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

Image 1 from page 71

Page 71 content

Page 72

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

Page 72 content

Page 73

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

Page 73 content

Page 74

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

Page 74 content

Page 75

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

Image 1 from page 75

Page 75 content

Page 76

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

Page 76 content

Page 77

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

Page 77 content

Page 78

• 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

Page 78 content

Page 79

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

Page 79 content

Page 80

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

Image 1 from page 80

Page 80 content

Page 81

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

Page 81 content

Page 82

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

Page 82 content

Page 83

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

Image 1 from page 83

Page 83 content

Page 84

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

Image 1 from page 84

Image 2 from page 84

Page 84 content

Page 85

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

Image 1 from page 85

Page 85 content

Page 86

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

Page 86 diagram

Page 87

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

Page 87 diagram

Page 88

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

Page 88 diagram

Page 89

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

Image 1 from page 89

Page 89 content

Page 90

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

Page 90 diagram

Page 91

• 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

Page 91 content

Page 92

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

Page 92 content

Page 93

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

Image 1 from page 93

Page 93 content

Page 94

• 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

Page 94 content

Page 95

• 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

Page 95 content

Page 96

• 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

Page 96 content

Page 97

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

Page 97 content

Page 98

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

Page 98 content

Page 99

• 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

Image 1 from page 99

Page 99 diagram

Page 100

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

Page 100 content

Page 101

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

Image 1 from page 101

Page 101 content

Page 102

• 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

Image 1 from page 102

Page 102 diagram

Page 103

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

Page 103 diagram

Page 104

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

Image 1 from page 104

Page 104 content

Page 105

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

Page 105 content

Page 106

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

Image 1 from page 106

Page 106 content

Page 107

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

Page 107 content

Page 108

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

Image 1 from page 108

Page 108 content

Page 109

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

Image 1 from page 109

Page 109 content

Page 110

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

Page 110 content

Page 111

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

Page 111 content

Page 112

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

Page 112 content

Page 113

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

Page 113 content

Page 114

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

Image 1 from page 114

Page 114 content

Page 115

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

Page 115 content

Page 116

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

Page 116 content

Page 117

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

Image 1 from page 117

Page 117 content

Page 118

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

Page 118 content

Page 119

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

Page 119 content

Page 120

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

Page 120 content

Page 121

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

Page 121 diagram

Page 122

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

Page 122 diagram

Page 123

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

Page 123 content

Page 124

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

Page 124 content

Page 125

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

Image 1 from page 125

Page 125 content

Page 126

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

Image 1 from page 126

Image 2 from page 126

Page 126 content

Page 127

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

Image 1 from page 127

Page 127 content

Page 128

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

Image 1 from page 128

Page 128 content

Page 129

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

Page 129 diagram

Page 130

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

Image 1 from page 130

Page 130 content

Page 131

• 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

Page 131 content

Page 132

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

Image 1 from page 132

Image 3 from page 132

Page 132 content

Page 133

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

Image 1 from page 133

Page 133 content

Page 134

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

Page 134 content

Page 135

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

Page 135 content

Page 136

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

Page 136 content

Page 137

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

Page 137 content

Page 138

• 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

Image 1 from page 138

Page 138 content

Page 139

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

Image 1 from page 139

Page 139 content

Page 140

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

Page 140 diagram

Page 141

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

Page 141 diagram

Page 142

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

Page 142 diagram

Page 143

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

Image 1 from page 143

Page 143 diagram

Page 144

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

Image 1 from page 144

Page 144 content

Page 145

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

Image 1 from page 145

Page 145 content

Page 146

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

Page 146 content

Page 147

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

Image 1 from page 147

Page 147 content

Page 148

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

Image 1 from page 148

Page 148 content

Page 149

• 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

Page 149 content

Page 150

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

Image 1 from page 150

Page 150 content

Page 151

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

Image 1 from page 151

Page 151 diagram

Page 152

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

Page 152 content

Page 153

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

Image 1 from page 153

Page 153 content

Page 154

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

Image 1 from page 154

Page 154 content

Page 155

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

Page 155 diagram

Page 156

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

Page 156 content

Page 157

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

Page 157 content

Page 158

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

Page 158 content

Page 159

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

Page 159 content

Page 160

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

Image 1 from page 160

Page 160 content

Page 161

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

Image 1 from page 161

Page 161 content

Page 162

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

Page 162 content

Page 163

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()

Page 163 content

Page 164

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()

Image 1 from page 164

Page 164 content

Page 165

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

Page 165 content

Page 166

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

Page 166 diagram

Page 167

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

Page 167 diagram

Page 168

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

Page 168 content

Page 169

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

Page 169 content

Page 170

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

Image 1 from page 170

Page 170 content

Page 171

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

Image 1 from page 171

Image 2 from page 171

Page 171 content

Page 172

• 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

Page 172 content

Page 173

• 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

Image 1 from page 173

Page 173 content

Page 174

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

Page 174 content

Page 175

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)

Image 1 from page 175

Page 175 content

Page 176

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

Page 176 diagram

Page 177

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

Page 177 diagram

Page 178

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

Image 1 from page 178

Page 178 content

Page 179

} } 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

Page 179 content

Page 180

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)

Image 1 from page 180

Page 180 content

Page 181

• 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

Page 181 content

Page 182

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

Image 1 from page 182

Page 182 content

Page 183

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

Page 183 content

Page 184

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

Image 1 from page 184

Page 184 diagram

Page 185

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

Page 185 diagram

Page 186

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

Image 1 from page 186

Page 186 content

Page 187

• 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

Page 187 content

Page 188

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

Page 188 diagram

Page 189

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

Image 1 from page 189

Page 189 content

Page 190

• 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

Page 190 content

Page 191

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

Image 1 from page 191

Page 191 content

Page 192

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

Image 1 from page 192

Page 192 content

Page 193

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

Page 193 content

Page 194

• 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

Page 194 content

Page 195

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

Page 195 content

Page 196

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

Page 196 content

Page 197

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

Image 1 from page 197

Page 197 diagram

Page 198

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

Image 1 from page 198

Image 2 from page 198

Page 198 content

Page 199

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

Page 199 content

Page 200

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

Page 200 diagram

Page 201

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

Page 201 diagram

Page 202

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

Page 202 diagram

Page 203

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

Page 203 diagram

Page 204

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

Page 204 content

Page 205

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

Page 205 diagram

Page 206

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

Image 1 from page 206

Page 206 content

Page 207

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

Page 207 diagram

Page 208

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

Image 1 from page 208

Page 208 content

Page 209

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

Image 1 from page 209

Page 209 content

Page 210

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

Page 210 content

Page 211

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

Page 211 content

Page 212

• 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

Image 1 from page 212

Page 212 diagram

Page 213

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

Page 213 diagram

Page 214

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

Image 1 from page 214

Image 2 from page 214

Page 214 content

Page 215

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

Image 1 from page 215

Page 215 content

Page 216

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

Page 216 content

Page 217

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

Image 1 from page 217

Image 2 from page 217

Page 217 content

Page 218

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

Page 218 content

Page 219

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

Page 219 content

Page 220

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

Page 220 content

Page 221

• 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

Page 221 diagram

Page 222

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

Page 222 diagram

Page 223

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

Page 223 diagram

Page 224

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

Page 224 diagram

Page 225

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

Page 225 diagram

Page 226

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

Page 226 diagram

Page 227

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

Image 1 from page 227

Page 227 content

Page 228

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

Image 1 from page 228

Page 228 diagram

Page 229

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

Page 229 content

Page 230

• 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

Page 230 content

Page 231

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

Page 231 content

Page 232

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

Page 232 content

Page 233

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

Page 233 content

Page 234

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

Page 234 content

Page 235

{ 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

Page 235 content

Page 236

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

Image 1 from page 236

Page 236 diagram

Page 237

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

Image 1 from page 237

Page 237 diagram

Page 238

• 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

Page 238 diagram

Page 239

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

Page 239 diagram

Page 240

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

Image 1 from page 240

Page 240 diagram

Page 241

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

Page 241 diagram

Page 242

• 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

Image 1 from page 242

Page 242 content

Page 243

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

Image 1 from page 243

Page 243 content

Page 244

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

Page 244 content

Page 245

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

Page 245 content

Page 246

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

Page 246 content

Page 247

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

Page 247 diagram

Page 248

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

Page 248 diagram

Page 249

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

Page 249 content

Page 250

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

Page 250 diagram

Page 251

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

Page 251 diagram

Page 252

• 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

Page 252 content

Page 253

• 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

Page 253 content

Page 254

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

Page 254 diagram

Page 255

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

Page 255 diagram

Page 256

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

Page 256 diagram

Page 257

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

Page 257 diagram

Page 258

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

Image 1 from page 258

Page 258 diagram

Page 259

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

Page 259 diagram

Page 260

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

Page 260 diagram

Page 261

• 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

Page 261 content

Page 262

• 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)

Image 1 from page 262

Page 262 content

Page 263

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)

Image 1 from page 263

Page 263 content

Page 264

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)

Page 264 content

Page 265

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)

Page 265 diagram

Page 266

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)

Page 266 diagram

Page 267

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)

Page 267 content

Page 268

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)

Page 268 content

Page 269

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

Page 269 content

Page 270

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

Image 1 from page 270

Page 270 diagram

Page 271

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

Image 1 from page 271

Page 271 diagram

Page 272

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

Page 272 content

Page 273

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

Page 273 content

Page 274

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

Image 1 from page 274

Page 274 content

Page 275

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

Page 275 diagram

Page 276

• 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)

Page 276 content

Page 277

• 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

Page 277 content

Page 278

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

Page 278 content

Page 279

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

Page 279 content

Page 280

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

Page 280 content

Page 281

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

Image 1 from page 281

Page 281 content

Page 282

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

Image 1 from page 282

Page 282 content

Page 283

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

Page 283 diagram

Page 284

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

Page 284 diagram

Page 285

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

Page 285 diagram

Page 286

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

Page 286 content

Page 287

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

Page 287 content

Page 288

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

Page 288 content

Page 289

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

Page 289 content

Page 290

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

Page 290 content

Page 291

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

Image 1 from page 291

Page 291 content

Page 292

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

Image 1 from page 292

Page 292 diagram

Page 293

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

Page 293 diagram

Page 294

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

Image 1 from page 294

Page 294 diagram

Page 295

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

Page 295 diagram

Page 296

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

Page 296 diagram

Page 297

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

Image 1 from page 297

Page 297 content

Page 298

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

Image 1 from page 298

Image 2 from page 298

Page 298 diagram

Page 299

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

Page 299 diagram

Page 300

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

Image 1 from page 300

Page 300 content

Page 301

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

Page 301 diagram

Page 302

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

Page 302 diagram

Page 303

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

Image 1 from page 303

Image 2 from page 303

Page 303 diagram

Page 304

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

Image 1 from page 304

Page 304 content

Page 305

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

Page 305 diagram

Page 306

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

Page 306 diagram

Page 307

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

Page 307 diagram

Page 308

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

Page 308 diagram

Page 309

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

Page 309 diagram

Page 310

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

Page 310 diagram

Page 311

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

Page 311 diagram

Page 312

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

Page 312 content

Page 313

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

Image 1 from page 313

Page 313 content

Page 314

• 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

Page 314 content

Page 315

• 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

Page 315 content

Page 316

• 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

Page 316 content

Page 317

• 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

Page 317 diagram

Page 318

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

Page 318 diagram

Page 319

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

Page 319 diagram

Page 320

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

Page 320 diagram

Page 321

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

Page 321 diagram

Page 322

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

Page 322 diagram

Page 323

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

Page 323 diagram

Page 324

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

Page 324 diagram

Page 325

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

Page 325 diagram

Page 326

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

Page 326 diagram

Page 327

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

Page 327 diagram

Page 328

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

Page 328 diagram

Page 329

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

Page 329 diagram

Page 330

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

Page 330 diagram

Page 331

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

Page 331 diagram

Page 332

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

Page 332 diagram

Page 333

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

Page 333 diagram

Page 334

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

Page 334 diagram

Page 335

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

Page 335 content

Page 336

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

Page 336 content

Page 337

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

Page 337 content

Page 338

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

Page 338 content

Page 339

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

Page 339 content

Page 340

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

Page 340 content

Page 341

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

Page 341 diagram

Page 342

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

Page 342 diagram

Page 343

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

Page 343 content

Page 344

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

Page 344 diagram

Page 345

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

Page 345 diagram

Page 346

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

Page 346 diagram

Page 347

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

Page 347 diagram

Page 348

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

Page 348 diagram

Page 349

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

Page 349 diagram

Page 350

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

Page 350 diagram

Page 351

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

Page 351 diagram

Page 352

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

Page 352 diagram

Page 353

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

Page 353 diagram

Page 354

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

Page 354 diagram

Page 355

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

Page 355 diagram

Page 356

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

Page 356 diagram

Page 357

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

Page 357 diagram

Page 358

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

Page 358 diagram

Page 359

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

Page 359 diagram

Page 360

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

Page 360 diagram

Page 361

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

Page 361 diagram

Page 362

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

Page 362 diagram

Page 363

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

Page 363 diagram

Page 364

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

Page 364 diagram

Page 365

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

Page 365 diagram

Page 366

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

Page 366 diagram

Page 367

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

Page 367 diagram

Page 368

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

Page 368 diagram

Page 369

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

Page 369 content

Page 370

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

Page 370 diagram

Page 371

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

Page 371 diagram

Page 372

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

Page 372 diagram

Page 373

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

Page 373 diagram

Page 374

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

Page 374 diagram

Page 375

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

Page 375 diagram

Page 376

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

Page 376 diagram

Page 377

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

Page 377 diagram

Page 378

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

Page 378 diagram

Page 379

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

Page 379 diagram

Page 380

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

Page 380 diagram

Page 381

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

Page 381 diagram

Page 382

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

Page 382 diagram

Page 383

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

Page 383 diagram

Page 384

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

Page 384 diagram

Page 385

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

Page 385 diagram

Page 386

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

Page 386 diagram

Page 387

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

Page 387 diagram

Page 388

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

Page 388 diagram

Page 389

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

Page 389 diagram

Page 390

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

Page 390 diagram

Page 391

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

Page 391 diagram

Page 392

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

Page 392 diagram

Page 393

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

Page 393 diagram

Page 394

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

Page 394 diagram

Page 395

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

Page 395 content

Page 396

• 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

Page 396 diagram

Page 397

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

Page 397 diagram

Page 398

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

Page 398 diagram

Page 399

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

Page 399 diagram

Page 400

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

Page 400 diagram

Page 401

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

Page 401 diagram

Page 402

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

Image 1 from page 402

Page 402 diagram

Page 403

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

Page 403 content

Page 404

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

Page 404 content

Page 405

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

Page 405 content

Page 406

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

Page 406 content

Page 407

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

Page 407 content

Page 408

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

Page 408 content

Page 409

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

Page 409 content

Page 410

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

Page 410 diagram

Page 411

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

Page 411 content

Page 412

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

Page 412 diagram

Page 413

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

Page 413 diagram

Page 414

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

Page 414 diagram

Page 415

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

Page 415 diagram

Page 416

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

Page 416 diagram

Page 417

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

Page 417 diagram

Page 418

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

Page 418 diagram

Page 419

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

Page 419 diagram

Page 420

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

Page 420 diagram

Page 421

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

Page 421 diagram

Page 422

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

Page 422 diagram

Page 423

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

Page 423 diagram

Page 424

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

Page 424 diagram

Page 425

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

Page 425 diagram

Page 426

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

Page 426 diagram

Page 427

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

Page 427 diagram

Page 428

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

Page 428 diagram

Page 429

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

Page 429 diagram

Page 430

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

Page 430 diagram

Page 431

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

Page 431 diagram

Page 432

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

Page 432 diagram

Page 433

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

Page 433 content

Page 434

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

Page 434 diagram

Page 435

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

Page 435 diagram

Page 436

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

Page 436 diagram

Page 437

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

Page 437 content

Page 438

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

Page 438 diagram

Page 439

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

Page 439 diagram

Page 440

Page 440 content

Page 441

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

Page 441 diagram

Page 442

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

Page 442 diagram

Page 443

Page 443 content

Page 444

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

Page 444 diagram

Page 445

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

Page 445 diagram

Page 446

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

Page 446 diagram

Page 447

Page 447 content

Page 448

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

Page 448 diagram

Page 449

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

Page 449 diagram

Page 450

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

Page 450 diagram

Page 451

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

Page 451 diagram

Page 452

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

Page 452 diagram

Page 453

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

Page 453 diagram

Page 454

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

Page 454 diagram

Page 455

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

Page 455 diagram

Page 456

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

Page 456 diagram

Page 457

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

Page 457 diagram

Page 458

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

Page 458 diagram

Page 459

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

Page 459 diagram

Page 460

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

Page 460 diagram

Page 461

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

Page 461 diagram

Page 462

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

Page 462 diagram

Page 463

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

Page 463 diagram

Page 464

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

Page 464 diagram

Page 465

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

Page 465 diagram

Page 466

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

Page 466 diagram

Page 467

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

Page 467 diagram

Page 468

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

Page 468 content

Page 469

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

Page 469 content

Page 470

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

Page 470 diagram

Page 471

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

Page 471 diagram

Page 472

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

Page 472 diagram

Page 473

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

Page 473 diagram

Page 474

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

Page 474 diagram

Page 475

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

Page 475 diagram

Page 476

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

Page 476 diagram

Page 477

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

Page 477 diagram

Page 478

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

Page 478 diagram

Page 479

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

Page 479 diagram

Page 480

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

Page 480 content

Page 481

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

Page 481 diagram

Page 482

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

Page 482 diagram

Page 483

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

Page 483 diagram

Page 484

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

Page 484 diagram

Page 485

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

Page 485 diagram

Page 486

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

Page 486 diagram

Page 487

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

Page 487 diagram

Page 488

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

Page 488 diagram

Page 489

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

Page 489 diagram

Page 490

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

Page 490 diagram

Page 491

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

Page 491 diagram

Page 492

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

Page 492 diagram

Page 493

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

Page 493 diagram

Page 494

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

Page 494 diagram

Page 495

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

Page 495 diagram

Page 496

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

Page 496 diagram

Page 497

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

Page 497 diagram

Page 498

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

Page 498 diagram

Page 499

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

Page 499 diagram

Page 500

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

Page 500 diagram

Page 501

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

Page 501 diagram

Page 502

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

Page 502 diagram

Page 503

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

Page 503 diagram

Page 504

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

Page 504 diagram

Page 505

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

Page 505 diagram

Page 506

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

Page 506 diagram

Page 507

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

Page 507 diagram

Page 508

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

Page 508 diagram

Page 509

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

Page 509 diagram

Page 510

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

Page 510 diagram

Page 511

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

Page 511 diagram

Page 512

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

Page 512 diagram

Page 513

} … … } 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

Page 513 diagram

Page 514

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

Page 514 diagram

Page 515

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

Page 515 diagram

Page 516

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

Page 516 diagram

Page 517

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

Page 517 diagram

Page 518

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

Image 1 from page 518

Page 518 diagram

Page 519

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

Page 519 diagram

Page 520

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

Page 520 diagram

Page 521

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

Page 521 diagram

Page 522

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

Page 522 diagram

Page 523

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

Page 523 diagram

Page 524

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

Page 524 diagram

Page 525

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

Page 525 diagram

Page 526

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

Page 526 diagram

Page 527

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

Page 527 diagram

Page 528

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

Page 528 diagram

Page 529

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

Page 529 diagram

Page 530

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

Page 530 diagram

Page 531

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

Page 531 diagram

Page 532

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

Page 532 diagram

Page 533

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

Page 533 diagram

Page 534

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

Page 534 diagram

Page 535

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

Page 535 diagram

Page 536

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

Page 536 diagram

Page 537

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

Page 537 diagram

Page 538

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

Page 538 diagram

Page 539

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

Page 539 diagram

Page 540

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

Page 540 diagram

Page 541

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

Page 541 diagram

Page 542

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

Page 542 diagram

Page 543

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

Page 543 diagram

Page 544

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

Page 544 diagram

Page 545

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

Page 545 diagram

Page 546

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

Page 546 diagram

Page 547

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

Page 547 diagram

Page 548

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

Page 548 diagram

Page 549

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

Page 549 diagram

Page 550

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

Page 550 diagram

Page 551

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

Page 551 diagram

Page 552

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

Page 552 diagram

Page 553

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

Page 553 diagram

Page 554

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

Page 554 diagram

Page 555

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

Page 555 diagram

Page 556

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

Page 556 diagram

Page 557

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

Page 557 content

Page 558

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

Page 558 diagram

Page 559

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

Page 559 diagram

Page 560

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

Page 560 diagram

Page 561

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

Page 561 diagram

Page 562

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

Page 562 diagram

Page 563

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

Page 563 diagram

Page 564

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

Page 564 diagram

Page 565

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

Page 565 diagram

Page 566

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

Page 566 diagram

Page 567

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

Page 567 diagram

Page 568

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

Page 568 diagram

Page 569

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

Page 569 diagram

Page 570

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

Page 570 diagram

Page 571

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

Page 571 diagram

Page 572

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

Page 572 diagram

Page 573

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

Page 573 diagram

Page 574

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

Page 574 diagram

Page 575

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

Page 575 diagram

Page 576

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

Page 576 diagram

Page 577

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

Page 577 diagram

Page 578

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

Page 578 diagram

Page 579

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

Page 579 diagram

Page 580

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

Page 580 diagram

Page 581

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

Page 581 content

Page 582

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

Page 582 content

Page 583

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

Page 583 diagram

Page 584

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

Page 584 diagram

Page 585

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

Page 585 diagram

Page 586

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

Page 586 diagram

Page 587

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

Page 587 diagram

Page 588

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

Page 588 diagram

Page 589

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

Page 589 diagram

Page 590

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

Page 590 diagram

Page 591

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

Page 591 diagram

Page 592

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

Page 592 diagram

Page 593

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

Page 593 diagram

Page 594

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

Page 594 diagram

Page 595

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

Page 595 diagram

Page 596

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

Page 596 diagram

Page 597

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

Page 597 diagram

Page 598

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

Page 598 diagram

Page 599

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

Page 599 diagram

Page 600

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

Page 600 diagram

Page 601

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

Page 601 diagram

Page 602

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

Page 602 diagram

Page 603

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

Page 603 diagram

Page 604

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

Page 604 diagram

Page 605

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

Page 605 diagram

Page 606

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

Page 606 diagram

Page 607

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

Image 1 from page 607

Page 607 diagram

Page 608

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

Page 608 diagram

Page 609

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

Page 609 diagram

Page 610

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

Page 610 diagram

Page 611

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

Page 611 diagram

Page 612

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

Page 612 diagram

Page 613

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

Page 613 diagram

Page 614

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

Page 614 diagram

Page 615

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

Page 615 diagram

Page 616

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

Page 616 diagram

Page 617

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

Page 617 diagram

Page 618

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

Page 618 diagram

Page 619

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

Page 619 diagram

Page 620

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

Page 620 diagram

Page 621

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

Page 621 diagram

Page 622

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

Page 622 diagram

Page 623

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

Page 623 diagram

Page 624

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

Page 624 diagram

Page 625

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

Page 625 diagram

Page 626

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

Page 626 diagram

Page 627

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

Page 627 diagram

Page 628

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

Page 628 diagram

Page 629

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

Page 629 diagram

Page 630

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

Page 630 diagram

Page 631

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

Page 631 diagram

Page 632

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

Page 632 diagram

Page 633

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

Page 633 diagram

Page 634

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

Page 634 diagram

Page 635

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

Page 635 diagram

Page 636

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

Page 636 diagram

Page 637

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

Page 637 diagram

Page 638

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

Page 638 diagram

Page 639

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

Page 639 diagram

Page 640

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

Page 640 diagram

Page 641

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

Page 641 diagram

Page 642

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

Page 642 diagram

Page 643

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

Page 643 diagram

Page 644

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

Page 644 diagram

Page 645

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

Page 645 diagram

Page 646

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

Page 646 diagram

Page 647

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

Page 647 diagram

Page 648

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

Page 648 diagram

Page 649

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

Page 649 diagram

Page 650

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

Page 650 diagram

Page 651

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

Page 651 diagram

Page 652

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

Page 652 diagram

Page 653

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

Page 653 diagram

Page 654

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

Page 654 diagram

Page 655

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

Page 655 diagram

Page 656

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

Page 656 diagram

Page 657

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

Page 657 diagram

Page 658

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

Page 658 diagram

Page 659

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

Page 659 diagram

Page 660

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

Page 660 diagram

Page 661

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

Page 661 diagram

Page 662

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

Page 662 diagram

Page 663

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

Page 663 diagram

Page 664

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

Page 664 diagram

Page 665

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

Page 665 diagram

Page 666

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

Page 666 content

Page 667

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

Page 667 diagram

Page 668

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

Page 668 diagram

Page 669

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

Page 669 diagram

Page 670

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

Page 670 diagram

Page 671

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

Page 671 diagram

Page 672

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

Page 672 diagram

Page 673

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

Page 673 diagram

Page 674

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

Page 674 diagram

Page 675

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

Page 675 diagram

Page 676

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

Page 676 diagram

Page 677

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

Page 677 content

Page 678

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

Page 678 diagram

Page 679

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

Page 679 diagram

Page 680

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

Page 680 diagram

Page 681

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

Page 681 diagram

Page 682

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

Page 682 diagram

Page 683

} } } } 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

Page 683 diagram

Page 684

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

Page 684 diagram

Page 685

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

Page 685 diagram

Page 686

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

Page 686 diagram

Page 687

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

Page 687 diagram

Page 688

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

Page 688 diagram

Page 689

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

Page 689 diagram

Page 690

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

Page 690 diagram

Page 691

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

Page 691 diagram

Page 692

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

Page 692 diagram

Page 693

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

Page 693 diagram

Page 694

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

Page 694 diagram

Page 695

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

Page 695 diagram

Page 696

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

Page 696 diagram

Page 697

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

Page 697 diagram

Page 698

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

Page 698 content

Page 699

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

Page 699 content

Page 700

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

Page 700 diagram

Page 701

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

Page 701 diagram

Page 702

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

Page 702 content

Page 703

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

Page 703 diagram

Page 704

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

Page 704 diagram

Page 705

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

Page 705 diagram

Page 706

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

Page 706 diagram

Page 707

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

Page 707 diagram

Page 708

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

Page 708 diagram

Page 709

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

Page 709 diagram

Page 710

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

Page 710 diagram

Page 711

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

Page 711 diagram

Page 712

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

Page 712 content

Page 713

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

Page 713 diagram

Page 714

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

Page 714 diagram

Page 715

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

Page 715 diagram

Page 716

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

Page 716 diagram

Page 717

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

Page 717 diagram

Page 718

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

Page 718 diagram

Page 719

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

Page 719 diagram

Page 720

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

Page 720 diagram

Page 721

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

Page 721 diagram

Page 722

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

Page 722 diagram

Page 723

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

Page 723 diagram

Page 724

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

Page 724 content

Page 725

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

Page 725 diagram

Page 726

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

Page 726 diagram

Page 727

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

Page 727 content

Page 728

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

Page 728 diagram

Page 729

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

Page 729 diagram

Page 730

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

Page 730 diagram

Page 731

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

Page 731 content

Page 732

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

Page 732 diagram

Page 733

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

Page 733 diagram

Page 734

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

Page 734 diagram

Page 735

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

Page 735 diagram

Page 736

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

Page 736 diagram

Page 737

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

Page 737 diagram

Page 738

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

Page 738 diagram

Page 739

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

Image 1 from page 739

Page 739 content

Page 740

• 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

Page 740 content

Page 741

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

Image 1 from page 741

Page 741 diagram

Page 742

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

Page 742 diagram

Page 743

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

Page 743 diagram

Page 744

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

Page 744 diagram

Page 745

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

Page 745 diagram

Page 746

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

Page 746 diagram

Page 747

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

Page 747 diagram

Page 748

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

Page 748 content

Page 749

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

Page 749 content

Page 750

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

Page 750 diagram

Page 751

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

Page 751 diagram

Page 752

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

Page 752 content

Page 753

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

Page 753 diagram

Page 754

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

Page 754 diagram

Page 755

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

Page 755 diagram

Page 756

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

Page 756 content

Page 757

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

Page 757 diagram

Page 758

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

Page 758 diagram

Page 759

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

Page 759 content

Page 760

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

Page 760 diagram

Page 761

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

Page 761 content

Page 762

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

Page 762 content

Page 763

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

Page 763 content

Page 764

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

Page 764 diagram

Page 765

ConsoleTraceWriter(int) public ConsoleTraceWriter(int maxTraceLevel) Constructor that sets the maximum level to be traced. See Also: Trace, on page 714 ConsoleTraceWriter(int[]) public ConsoleTraceWriter(int[] traceLevels) Construct a ConsoleTraceWriter with an array of trace levels Only traces with the severity in the tracelevel array are traced Parameters: int - [] traceLevels See Also: Trace, on page 714 Methods doFlush() protected final void doFlush() Overrides: doFlush in class BaseTraceWriter, on page 695 doPrintln(String, int) protected final void doPrintln(java.lang.String message, intmessageNumber) Description copied from class: com.cisco.services.tracing.BaseTraceWriter Must be implemented by the various TraceWriters extending BaseTraceWriter to provide the specific tracing functionality Overrides: doPrintln in class BaseTraceWriter, on page 695 main(String[]) public static void main(java.lang.String[] args) LogFileTraceWriter This class extends the BaseTraceWriter class to implement a TraceWriter that writes to a set of log files, rotating among them as each becomes filled to a specified capacity and stores them in a specified directory. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 701 Cisco Unified JTAPI Alarms and Services Methods

Page 765 content

Page 766

Each of the log files is named according to a pattern controlled by three properties, CurrentFile, FileNameBase, and FileExtension. The CurrentFile property determines which log file, by ordinal number, is being written at present, the FileNameBase property determines the prefix of each log file name, and the FileExtension property determines the suffix, e.g. “txt”. From these properties, log files are named FileNameBase LeadingZeroPadding CurrentFile.FileExtension. The CurrentFile property takes on a value from 1 to the value of the MaxFiles property. Note that the CurrentFile property, when converted to a String, is padded with leading zeroes depending on the values of the MaxFiles and CurrentFile properties. An index file tracks the index of the last file written. If the logFileWriter is recreated (for example if an application is restarted) new files will continue from the last written index. Where the log files are stored is determined by the path, dirNameBase, useSameDir. If a path is not specified, the current path is used as default. If a dirNameBase is not specified, it write log files in the path. Depending upon whether useSameDir is true or false, files are written to the same directory or a new directory, each time an instance of LogFileTraceWriter is created. In case new directories are being made each time, the directory name will consist of the dirNameBase and a number, separated by an ’_’. The number is one more than the greatest number associated with directories with the same dirNameBame in the path. While specifying the path, you may use either a “/” or “\”, but not “\” The LogFileTraceWriter keeps track of how many bytes have been written to the current log file. When that number grows within approximately LogFileTraceWriter.ROLLOVER_THRESHOLD bytes, tracing continues to the next file, which is either CurrentFile + 1 if CurrentFile is not equal to MaxFiles, or 1 if CurrentFile is equal to MaxFiles. All properties of this class are specified in the constructor; there is no way to change them dynamically. Caveat: If two instances of LogFileTraceWriter are created with the same path and dirNameBase, and useSameDir is true, they may write to the same file. Note Example The following code instantiates a LogFileTraceWriter that will create log files called “MyLog01.log” through “MyLog12.log”. Each file will grow to approximately 100K bytes in size before the next file is created: LogFileTraceWriter out = new LogFileTraceWriter ( “MyLog”, “log”, 12, 100 * 1024 ); will create a log file TraceWriter which will rotate traces to 12 files from Mylog01.log and Mylog12.log with a file size of 100 KBytes. By default the tracing is set to the HIGHEST_LEVEL. The following code constructs a LogFileTraceWriter which stores the log files in the path “c:/LogFiles” in a sub directory, “Run”. The files will be named MyLogXX.log. The number of rotating files will be 12 with a size of 100 KB. The same directory gets used for each instance of the application. LogFileTraceWriter out = new LogFileTraceWriter (“c:/logFiles”, “Run”, “MyLog”, “log”, 12, 100*1024, true); See Also Trace, on page 714 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 702 Cisco Unified JTAPI Alarms and Services LogFileTraceWriter

Image 1 from page 766

Page 766 content

Page 767

Declaration public final class LogFileTraceWriter extends BaseTraceWriter, on page 695 java.lang.Object | +--com.cisco.services.tracing.BaseTraceWriter | +--com.cisco.services.tracing.LogFileTraceWriter All Implemented Interfaces TraceWriter, on page 728 Member Summary Member summary Fields DEFAULT_FILE_NAME_BASE, on page 704 static java.lang.String DEFAULT_FILE_NAME_EXTENSION, on page 705 static java.lang.String DIR_BASE_NAME_NUM_SEPERATOR, on page 705 static char MIN_FILE_SIZE, on page 705 static int MIN_FILES, on page 705 static int ROLLOVER_THRESHOLD, on page 705 static int Constructors LogFileTraceWriter(String, String, int, int), on page 705 Default constructor for LogFileTraceWriter that rotates among an arbitrary number of files with tracing for all levels. LogFileTraceWriter(String, String, String, String, int, int, boolean), on page 705 Default constructor for LogFileTraceWriter that rotates among an arbitrary number of files with tracing for all levels. LogFileTraceWriter(String, String, String, String, int, int, int, boolean), on page 705 Constructs a LogFileTraceWriter that rotates among an arbitrary number of files storing them in a specified directory. Methods doClose(), on page 706 Closes this OutputStream. protected void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 703 Cisco Unified JTAPI Alarms and Services Declaration

Page 767 diagram

Page 768

Member summary doFlush(), on page 706 protected void doPrintln(String, int), on page 706 protected void getCurrentFile(), on page 706 Returns the CurrentFile property int getFileExtension(), on page 706 Returns the FileExtension property java.lang.String getFileNameBase(), on page 707 Returns the FileNameBase property java.lang.String getHeader(), on page 707 Get the header string that will be written at the beginning of each log file. java.lang.String getMaxFiles(), on page 707 Returns the MaxFiles property int getMaxFileSize(), on page 707 Returns the MaxFileSize property int setHeader(String), on page 707 Set the constant header string that will be written at the beginning of every file, trace writing continues from the next line after the header is written. 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() Fields DEFAULT_FILE_NAME_BASE public static final java.lang.String DEFAULT_FILE_NAME_BASE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 704 Cisco Unified JTAPI Alarms and Services Fields

Page 768 diagram

Page 769

DEFAULT_FILE_NAME_EXTENSION public static final java.lang.String DEFAULT_FILE_NAME_EXTENSION DIR_BASE_NAME_NUM_SEPERATOR public static final char DIR_BASE_NAME_NUM_SEPERATOR MIN_FILE_SIZE public static final int MIN_FILE_SIZE MIN_FILES public static final int MIN_FILES ROLLOVER_THRESHOLD public static final int ROLLOVER_THRESHOLD Constructors LogFileTraceWriter(String, String, int, int) public LogFileTraceWriter(java.lang.String fileNameBase, java.lang.StringfileNameExtension, intmaxFiles, intmaxFileSize) throwsIOException Default constructor for LogFileTraceWriter that rotates among an arbitrary number of files with tracing for all levels. Since a path and Directory Base name is not specified, it writes the files to the current directory without any sub directories. Throws: java.io.IOException LogFileTraceWriter(String, String, String, String, int, int, boolean) public LogFileTraceWriter(java.lang.String path, java.lang.StringdirNameBase, java.lang.StringfileNameBase, java.lang.StringfileNameExtension, intmaxFiles, intmaxFileSize, booleanuseSameDir) throwsIOException Default constructor for LogFileTraceWriter that rotates among an arbitrary number of files with tracing for all levels. Throws: java.io.IOException LogFileTraceWriter(String, String, String, String, int, int, int, boolean) public LogFileTraceWriter(java.lang.String path, java.lang.StringdirNameBase, java.lang.StringfileNameBase, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 705 Cisco Unified JTAPI Alarms and Services Constructors

Page 769 content

Page 770

java.lang.StringfileNameExtension, intmaxFiles, intmaxFileSize, intmaxTraceLevel, booleanuseSameDir) throwsIOException Constructs a LogFileTraceWriter that rotates among an arbitrary number of files storing them in a specified directory. Throws: java.io.IOException Methods doClose() protected void doClose() Closes this OutputStream. Any log file that is currently open will be closed as well. Overrides: doClose in class BaseTraceWriter, on page 695 doFlush() protected void doFlush() Overrides: doFlush in class BaseTraceWriter, on page 695 doPrintln(String, int) protected void doPrintln(java.lang.String message, intmessageNumber) Description copied from class: com.cisco.services.tracing.BaseTraceWriter Must be implemented by the various TraceWriters extending BaseTraceWriter to provide the specific tracing functionality Overrides: doPrintln in class BaseTraceWriter, on page 695 getCurrentFile() public int getCurrentFile() Returns: the CurrentFile property getFileExtension() public java.lang.String getFileExtension() Returns: the FileExtension property Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 706 Cisco Unified JTAPI Alarms and Services Methods

Page 770 content

Page 771

getFileNameBase() public java.lang.String getFileNameBase() Returns: the FileNameBase property getHeader() public java.lang.String getHeader() Get the header string that will be written at the beginning of each log file. Returns: the Header Property getMaxFiles() public int getMaxFiles() Returns: the MaxFiles property getMaxFileSize() public int getMaxFileSize() Returns: the MaxFileSize property setHeader(String) public void setHeader(java.lang.String header) Set the constant header string that will be written at the beginning of every file, trace writing continues from the next line after the header is written. If setHeader is called after a file output has started, it will take effect from the next file to be written. Usage: tm = TraceManagerFactory.registerModule(this); tw = newLogFileTraceWriter(“trace”, “log”, 10, 1024*1024); tw.setHeader(header); tm.getTraceWriterManager().addTraceWriter(tw); OutputStreamTraceWriter OutputStreamTraceWriter wraps an output stream in a TraceWriter. This simplifies adding custom tracing classes that can co-exist with other TraceWriters. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 707 Cisco Unified JTAPI Alarms and Services OutputStreamTraceWriter

Page 771 content

Page 772

Declaration public final class OutputStreamTraceWriter extends BaseTraceWriter, on page 695 java.lang.Object | +--com.cisco.services.tracing.BaseTraceWriter | +--com.cisco.services.tracing.OutputStreamTraceWriter All Implemented Interfaces TraceWriter, on page 728 Member Summary Member summary Constructors OutputStreamTraceWriter(int, OutputStream), on page 709 Default constructor which is auto-flushing OutputStreamTraceWriter(int, OutputStream, boolean), on page 709 Create an OutputStreamTraceWriter Methods doClose(), on page 709 protected void doFlush(), on page 709 protected void doPrintln(String, int), on page 709 protected void getOutputStream(), on page 710 java.io.OutputStream 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() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 708 Cisco Unified JTAPI Alarms and Services Declaration

Page 772 diagram

Page 773

Constructors OutputStreamTraceWriter(int, OutputStream) public OutputStreamTraceWriter(int maxTraceLevel, java.io.OutputStreamoutputStream) Default constructor which is auto-flushing See Also: Trace, on page 714 OutputStreamTraceWriter(int, OutputStream, boolean) public OutputStreamTraceWriter(int maxTraceLevel, java.io.OutputStreamoutputStream, booleanautoFlush) Create an OutputStreamTraceWriter See Also: Trace, on page 714 Methods doClose() protected void doClose() Overrides: doClose in class BaseTraceWriter, on page 695 doFlush() protected void doFlush() Overrides: doFlush in class BaseTraceWriter, on page 695 doPrintln(String, int) protected void doPrintln(java.lang.String message, intmessageNumber) Description copied from class: com.cisco.services.tracing.BaseTraceWriter Must be implemented by the various TraceWriters extending BaseTraceWriter to provide the specific tracing functionality Overrides: doPrintln in class BaseTraceWriter, on page 695 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 709 Cisco Unified JTAPI Alarms and Services Constructors

Page 773 content

Page 774

getOutputStream() public java.io.OutputStream getOutputStream() Returns: the output stream associated with the TraceWriter SyslogTraceWriter SyslogTraceWriter refines the BaseTraceWriter to allow tracing to syslog. Cisco syslog specification calls for sending low level traces to a syslog collector in the form of UDP messages. No buffering is done in this TraceWriter. The SyslogTraceWriter makes an exception to the println() method in that it places a ’\0’ instead of a System specified line separator to terminate the message packet. Declaration public final class SyslogTraceWriter extends BaseTraceWriter, on page 695 java.lang.Object | +--com.cisco.services.tracing.BaseTraceWriter | +--com.cisco.services.tracing.SyslogTraceWriter All Implemented Interfaces TraceWriter, on page 728 Member Summary Member summary Constructors SyslogTraceWriter(int, String), on page 711 Default SyslogTraceWriter with a max trace level of INFORMATIONAL SyslogTraceWriter(int, String, int), on page 711 SyslogTraceWriter with max trace level specified SyslogTraceWriter(int, String, int[]), on page 711 SyslogTraceWriter which takes an array of trace levels. Methods doClose(), on page 712 Closes the socket void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 710 Cisco Unified JTAPI Alarms and Services SyslogTraceWriter

Page 774 diagram

Page 775

Member summary doPrintln(String, int), on page 712 The SyslogTraceWriter makes an exception to the println() method in that it places a ’\0’ instead of a System specified line separator to terminate the message packet. protected void main(String[]), on page 712 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 SyslogTraceWriter(int, String) public SyslogTraceWriter(int port, java.lang.Stringcollector) Default SyslogTraceWriter with a max trace level of INFORMATIONAL See Also: Trace, on page 714 SyslogTraceWriter(int, String, int) public SyslogTraceWriter(int port, java.lang.Stringcollector, intmaxTraceLevel) SyslogTraceWriter with max trace level specified See Also: Trace, on page 714 SyslogTraceWriter(int, String, int[]) public SyslogTraceWriter(int port, java.lang.Stringcollector, int[]traceLevels) SyslogTraceWriter which takes an array of trace levels. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 711 Cisco Unified JTAPI Alarms and Services Constructors

Page 775 diagram

Page 776

See Also: Trace, on page 714 Methods doClose() public void doClose() Closes the socket Overrides: doClose in class BaseTraceWriter, on page 695 doPrintln(String, int) protected void doPrintln(java.lang.String message, intmessageNumber) The SyslogTraceWriter makes an exception to the println() method in that it places a ’\0’ instead of a System specified line separator to terminate the message packet. The portion of the message after a ’\r’ or ’\n’ is ignored Overrides: doPrintln in class BaseTraceWriter, on page 695 main(String[]) public static void main(java.lang.String[] args) TraceManagerFactory The TraceManagerFactory class is a class by which applications obtain a TraceManager object. The TraceModule passed in the constructor is registered in a list. The list can be enumerated using the getModules() method. Declaration public class TraceManagerFactory java.lang.Object | +--com.cisco.services.tracing.TraceManagerFactory Member Summary Member summary Methods Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 712 Cisco Unified JTAPI Alarms and Services Methods

Page 776 diagram

Page 777

Member summary getModules(), on page 713 Returns an enumeration of the TraceModules registered with this factory. static java.util.Enumeration registerModule(TraceModule), on page 713 Returns an instance of a TraceManager object. static TraceManager registerModule(TraceModule, String[], TraceWriterManager), on page 713 Returns an instance of a TraceManager object. static TraceManager registerModule(TraceModule, TraceWriterManager), on page 714 Returns an instance of a TraceManager object. static TraceManager Inherited member summary Methods inherited from class Object clone(), equals(Object), finalize(), getClass(), hashCode(), notify(), notifyAll(), toString(), wait(), wait(), wait() Methods getModules() public static java.util.Enumeration getModules() Returns an enumeration of the TraceModules registered with this factory. registerModule(TraceModule) public static com.cisco.services.tracing.TraceManager registerModule(com.cisco.services.tracing.TraceModule module) Returns an instance of a TraceManager object. The contained TraceWriterManager will not have any default TraceWriters. registerModule(TraceModule, String[], TraceWriterManager) public static com.cisco.services.tracing.TraceManager registerModule(com.cisco.services.tracing.TraceModule module, java.lang.String[]subFacilities, com.cisco.services.tracing.TraceWriterManagertraceWriterManager) Returns an instance of a TraceManager object. Trace output will be redirected to the TraceWriterManager object specified. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 713 Cisco Unified JTAPI Alarms and Services Methods

Page 777 diagram

Page 778

registerModule(TraceModule, TraceWriterManager) public static com.cisco.services.tracing.TraceManager registerModule(com.cisco.services.tracing.TraceModule module, com.cisco.services.tracing.TraceWriterManagertraceWriterManager) Returns an instance of a TraceManager object. Trace output will be redirected to the TraceWriterManager object specified. Services Tracing Interface Hierarchy The following interface hierarchy is contained in the com.cisco.services.tracing package. com.cisco.services.tracing.Trace, on page 714 com.cisco.services.tracing.ConditionalTrace, on page 721 com.cisco.services.tracing.UnconditionalTrace, on page 722 com.cisco.services.tracing.TraceManager, on page 723 com.cisco.services.tracing.TraceModule, on page 727 com.cisco.services.tracing.TraceWriter, on page 728 com.cisco.services.tracing.TraceWriterManager, on page 731 Trace The Trace interface defines the methods that allow application tracing. Trace also defines the standard trace types as specified by Syslog Trace Logging.Syslog currently defines 8 levels of trace. The severity of the message is indicated in the trace as a number ranging between [0-7] (0 and 7 included). Currently 7 is HIGHEST_LEVEL and 0 is the LOWEST_LEVEL trace. All 8 levels are predefined here as static int types for reference in tracing sub-system implementations. The severities traced are 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 6 = INFORMATIONAL Informational messages only 7 = DEBUGGING Debugging messages Declaration public interface Trace Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 714 Cisco Unified JTAPI Alarms and Services Services Tracing Interface Hierarchy

Page 778 content

Page 779

All Known Subinterfaces ConditionalTrace, on page 721UnconditionalTrace, on page 722 Member Summary Member summary Fields ALERTS, on page 717 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 ALERTS_TRACE_NAME, on page 717 String descriptor for ALERTS trace level static java.lang.String CRITICAL, on page 691 A critical failure, the application cannot accomplish the tasks required due to this failure, e.g.: the application cant open the database to read the device list Syslog severity level = 2 static int CRITICAL_TRACE_NAME, on page 718 String descriptor for CRITICAL trace level static java.lang.String DEBUGGING, on page 718 Very detailed information regarding errors or processing status that is only generated when DEBUG mode has been enabled Syslog severity level = 7 static int DEBUGGING_TRACE_NAME, on page 718 String descriptor for the DEBUGGING trace level static java.lang.DEBUGGING_TRACE_NAME, on page 718String EMERGENCIES, on page 718 Emergency situation, a system shutdown is necessary Syslog severity level = 0 static int EMERGENCIES_TRACE_NAME, on page 718 String descriptor for EMERGENCIES trace level static java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 715 Cisco Unified JTAPI Alarms and Services All Known Subinterfaces

Page 779 diagram

Page 780

Member summary ERROR, on page 718 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 ERROR_TRACE_NAME, on page 718 String descriptor for ERROR trace level static java.lang.String HIGHEST_LEVEL, on page 718 The highest trace level, currently this is DEBUGGING with a trace level of 7 static int INFORMATIONAL, on page 719 Information of some form not relating to errors, warnings, audit, or debug Syslog severity level = 6 static int INFORMATIONAL_TRACE_NAME, on page 719 String descriptor for INFORMATIONAL trace level static java.lang.String LOWEST_LEVEL, on page 719 The lowest trace level, currently this is EMERGENCIES with a trace level of 0 static int NOTIFICATION, on page 719 Notification denotes a normal but significant condition Syslog severity level = 5 static int NOTIFICATION_TRACE_NAME, on page 719 String descriptor for NOTIFICATION trace level static java.lang.String WARNING, on page 719 Warning that a problem of some form exists but is not keeping the application from completing its tasks Syslog severity level = 4 static int WARNING_TRACE_NAME, on page 719 String descriptor for WARNING trace level static java.lang.String Methods getName(), on page 719 Returns the name of this Trace object. java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 716 Cisco Unified JTAPI Alarms and Services Member Summary

Page 780 diagram

Page 781

Member summary getSubFacility(), on page 720 Returns the subFacility of trace java.lang.String getType(), on page 720 Returns the type of trace. int isEnabled(), on page 720 Returns the state of this Trace object. boolean println(Object), on page 720 Prints the string returned by the Object.toString() method and terminates the line as defined by the system. void println(String), on page 720 Prints a message in the same format as Trace.print() and terminates the line as defined by the system. void println(String, Object), on page 720 Prints the string returned by the Object.toString() method and terminates the line as defined by the system. void println(String, String), on page 721 Prints a message in the same format as Trace.print() and terminates the line as defined by the system. void setDefaultMnemonic(String), on page 721 Sets a default mnemonic for all messages printed out to this trace. 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 ALERTS_TRACE_NAME public static final java.lang.String ALERTS_TRACE_NAME String descriptor for ALERTS trace level Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 717 Cisco Unified JTAPI Alarms and Services Fields

Page 781 diagram

Page 782

CRITICAL public static final int CRITICAL A critical failure, the application cannot accomplish the tasks required due to this failure, e.g.: the application cant open the database to read the device list Syslog severity level = 2 CRITICAL_TRACE_NAME public static final java.lang.String CRITICAL_TRACE_NAME String descriptor for CRITICAL trace level 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 DEBUGGING_TRACE_NAME public static final java.lang.String DEBUGGING_TRACE_NAME String descriptor for the DEBUGGING trace level EMERGENCIES public static final int EMERGENCIES Emergency situation, a system shutdown is necessary Syslog severity level = 0 EMERGENCIES_TRACE_NAME public static final java.lang.String EMERGENCIES_TRACE_NAME String descriptor for EMERGENCIES trace level 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 ERROR_TRACE_NAME public static final java.lang.String ERROR_TRACE_NAME String descriptor for ERROR trace level HIGHEST_LEVEL public static final int HIGHEST_LEVEL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 718 Cisco Unified JTAPI Alarms and Services Fields

Page 782 content

Page 783

The highest trace level, currently this is DEBUGGING with a trace level of 7 INFORMATIONAL public static final int INFORMATIONAL Information of some form not relating to errors, warnings, audit, or debug Syslog severity level = 6 INFORMATIONAL_TRACE_NAME public static final java.lang.String INFORMATIONAL_TRACE_NAME String descriptor for INFORMATIONAL trace level LOWEST_LEVEL public static final int LOWEST_LEVEL The lowest trace level, currently this is EMERGENCIES with a trace level of 0 NOTIFICATION public static final int NOTIFICATION Notification denotes a normal but significant condition Syslog severity level = 5 NOTIFICATION_TRACE_NAME public static final java.lang.String NOTIFICATION_TRACE_NAME String descriptor for NOTIFICATION trace level 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 WARNING_TRACE_NAME public static final java.lang.String WARNING_TRACE_NAME String descriptor for WARNING trace level Methods getName() public java.lang.String getName() Returns: the name of this Trace object Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 719 Cisco Unified JTAPI Alarms and Services Methods

Page 783 content

Page 784

getSubFacility() public java.lang.String getSubFacility() Returns: the trace subFacility type getType() public int getType() Returns: the type of trace as specified in Syslog. DEBUGGING, INFORMATIONAL, WARNING, etc. isEnabled() public boolean isEnabled() Returns the state of this Trace object. By default, Trace objects are enabled, that is, println() method will always trace. The state may not be changed through this interface, however, this object may implement additional interfaces that allow the state to be changed. Returns: true if tracing is enabled, false otherwise See Also ConditionalTrace, on page 721 println(Object) public void println(java.lang.Object object) Prints the string returned by the Object.toString() method and terminates the line as defined by the system. Parameters: object - the object to be printed println(String) public void println(java.lang.String message) Prints a message in the same format as Trace.print() and terminates the line as defined by the system. Parameters: message - the message to be printed println(String, Object) public void println(java.lang.String mnemonic, java.lang.Objectobject) Prints the string returned by the Object.toString() method and terminates the line as defined by the system. Parameters: object - the object to be printed Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 720 Cisco Unified JTAPI Alarms and Services Methods

Page 784 content

Page 785

mnemonic - the mnemonic mapped to message to be printed println(String, String) public void println(java.lang.String mnemonic, java.lang.Stringmessage) Prints a message in the same format as Trace.print() and terminates the line as defined by the system. Parameters: message - the message to be printed mnemonic - the mnemonic mapped to message to be printed setDefaultMnemonic(String) public void setDefaultMnemonic(java.lang.String mnemonic) Sets a default mnemonic for all messages printed out to this trace. Parameters: mnemonic, - a mnemonic string ConditionalTrace The ConditionalTrace interface extends the Trace interface and defines the methods that allow enabling and disabling of tracing for this particular condition. Typically, applications obtain one ConditionalTrace object for each condition that they need to trace under certain circumstances but not always (for example, AUDIT, INFO, and so on). Declaration public interface ConditionalTrace extends Trace, on page 714 All Superinterfaces Trace, on page 714 Member Summary Member summary Methods disable(), on page 722 Disables this condition for tracing. void enable(), on page 722 Enables this condition for tracing. void Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 721 Cisco Unified JTAPI Alarms and Services ConditionalTrace

Page 785 diagram

Page 786

Inherited member summary Fields inherited from interface Trace, on page 714 ALERTS, on page 717, ALERTS_TRACE_NAME, on page 717, CRITICAL, on page 691, CRITICAL_TRACE_NAME, on page 718, DEBUGGING, on page 718, DEBUGGING_TRACE_NAME, on page 718, EMERGENCIES, on page 718, EMERGENCIES_TRACE_NAME, on page 718, ERROR, on page 718, ERROR_TRACE_NAME, on page 718, HIGHEST_LEVEL, on page 718, INFORMATIONAL, on page 719, INFORMATIONAL_TRACE_NAME, on page 719, LOWEST_LEVEL, on page 719, NOTIFICATION, on page 719, NOTIFICATION_TRACE_NAME, on page 719, WARNING, on page 719, WARNING_TRACE_NAME, on page 719 Methods inherited from interface Trace, on page 714 getName(), on page 719, getSubFacility(), on page 720, getType(), on page 720, isEnabled(), on page 720, println(Object), on page 720, println(String), on page 720, println(String, Object), on page 720, println(String, String), on page 721, setDefaultMnemonic(String), on page 721 Methods disable() public void disable() Disables this condition for tracing. enable() public void enable() Enables this condition for tracing. UnconditionalTrace The UnconditionalTrace interface extends the Trace interface. Note that because this object extends Trace, its state is enabled by default and it may not be changed. Typically, applications would obtain one UnconditionalTrace object per each condition that they need to trace always under any circumstances (such as, ERROR, FATAL, and so on). Declaration public interface UnconditionalTrace extends Trace, on page 714 All Superinterfaces Trace, on page 714 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 722 Cisco Unified JTAPI Alarms and Services Methods

Page 786 diagram

Page 787

Member Summary Inherited Member summary Fields inherited from interface Trace, on page 714 ALERTS, on page 717, ALERTS_TRACE_NAME, on page 717, CRITICAL, on page 691, CRITICAL_TRACE_NAME, on page 718, DEBUGGING, on page 718, DEBUGGING_TRACE_NAME, on page 718, EMERGENCIES, on page 718, EMERGENCIES_TRACE_NAME, on page 718, ERROR, on page 718, ERROR_TRACE_NAME, on page 718, HIGHEST_LEVEL, on page 718, INFORMATIONAL, on page 719, INFORMATIONAL_TRACE_NAME, on page 719, LOWEST_LEVEL, on page 719, NOTIFICATION, on page 719, NOTIFICATION_TRACE_NAME, on page 719, WARNING, on page 719, WARNING_TRACE_NAME, on page 719 Methods inherited from interface Trace, on page 714 getName(), on page 719, getSubFacility(), on page 720, getType(), on page 720, isEnabled(), on page 720, println(Object), on page 720, println(String), on page 720, println(String, Object), on page 720, println(String, String), on page 721, setDefaultMnemonic(String), on page 721 TraceManager The TraceManager interface defines the methods that allow applications trace management. Typically, an application obtains only one TraceManager object. All Trace objects are created by default: Predefined Trace in accordance with Syslog definitions are: ConditionalTraces:INFORMATIONAL, DEBUGGING, NOTIFICATION, WARNING UnconditionalTraces:ERROR, CRITICAL, ALERTS, EMERGENCIES Facilities/Sub-Facilities: • Facility—A code consisting of two or more uppercase letters that indicate the facility to which the message refers. A facility can be a hardware device, a protocol, or a module of the system software. • SubFacility—A code consisting of two or more uppercase letters that indicate the sub-facility to which the message refers. A sub-facility can be a hardware device component, a protocol unit, or a sub-module of the system software. By default all 8 Conditional and UnConditional Traces are created for the Facility and 8 for each of the subFacilities In order to use the DEBUGGING trace for the parent FACILITY, for example, the application needs to use the getConditionalTrace( “DEBUGGING” ) method of this object. In order to use the DEBUGGING trace for the SUBFACILITY, for example, the application needs to use the getConditionalTrace( SUBFACILITY + “_” + “DEBUGGING” ) method of this object or use the getConditionalTrace( SUBFACILITY, “DEBUGGING” ) method. System wide TraceWriterManager is set through the setTraceWriterManager method provided by this interface. The Trace Manager object also allows the application to enable or disable tracing for all trace through the enableAll() and disableAll() methods. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 723 Cisco Unified JTAPI Alarms and Services Member Summary

Page 787 diagram

Page 788

Declaration public interface TraceManager Member Summary Member summary Methods addSubFacilities(String[]), on page 725 Sets a set of subFacilities for this TraceManager/Facility. void addSubFacility(String), on page 725 Adds a single subFacility for this TraceManager/Facility. void disableAll(), on page 725 Disables tracing for all Trace objects managed by this TraceManager. void disableTimeStamp(), on page 726 Disables prefixing a time stamp for every message printed by this TraceManager. void enableAll(), on page 726 Enables tracing for all Trace objects managed by this TraceManager. void enableTimeStamp(), on page 726 Enables prefixing a time stamp for every message printed by this TraceManager. void getConditionalTrace(int), on page 726 Creates a new ConditionalTrace object or obtains an existing ConditionalTrace object for this condition. ConditionalTrace getConditionalTrace(String, int), on page 726 Creates a new ConditionalTrace object or obtains an existing ConditionalTrace object for this condition and subFacility ConditionalTrace getName(), on page 726 Returns the Facility name for this TraceManager. java.lang.String getSubFacilities(), on page 726 Returns the subFacility names for this TraceManager/Facility. java.lang.String[] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 724 Cisco Unified JTAPI Alarms and Services Declaration

Page 788 diagram

Page 789

Member summary getTraces(), on page 726 Returns an enumeration of the Trace objects managed by this TraceManager. java.util.Enumeration getTraceWriterManager(), on page 726 Returns the TraceWriter used by this TraceManager. TraceWriterManager getUnconditionalTrace(int), on page 726 Creates a new UnconditionalTrace object or obtains an existing UnconditionalTrace object for this condition. UnconditionalTrace getUnconditionalTrace(String, int), on page 727 Creates a new UnconditionalTrace object or obtains an existing UnconditionalTrace object for this condition and subFacility UnconditionalTrace removeTrace(Trace), on page 727 Removes a Trace object given an object. void setSubFacilities(String[]), on page 727 Sets a set of subFacilities for this TraceManager/Facility. void setSubFacility(String), on page 727 Adds a single subFacility for this TraceManager/Facility. void setTraceWriterManager(TraceWriterManager), on page 727 Sets the TraceWriter to be used by this TraceManager. void Methods addSubFacilities(String[]) public void addSubFacilities(java.lang.String[] names) Sets a set of subFacilities for this TraceManager/Facility. addSubFacility(String) public void addSubFacility(java.lang.String name) Adds a single subFacility for this TraceManager/Facility. disableAll() public void disableAll() Disables tracing for all Trace objects managed by this TraceManager. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 725 Cisco Unified JTAPI Alarms and Services Methods

Page 789 diagram

Page 790

disableTimeStamp() public void disableTimeStamp() Disables prefixing a time stamp for every message printed by this TraceManager. enableAll() public void enableAll() Enables tracing for all Trace objects managed by this TraceManager. enableTimeStamp() public void enableTimeStamp() Enables prefixing a time stamp for every message printed by this TraceManager. getConditionalTrace(int) public com.cisco.services.tracing.ConditionalTrace getConditionalTrace(int severity) Creates a new ConditionalTrace object or obtains an existing ConditionalTrace object for this condition. getConditionalTrace(String, int) public com.cisco.services.tracing.ConditionalTrace getConditionalTrace(java.lang.String subFacility, intseverity) Creates a new ConditionalTrace object or obtains an existing ConditionalTrace object for this condition and subFacility getName() public java.lang.String getName() Returns the Facility name for this TraceManager. getSubFacilities() public java.lang.String[] getSubFacilities() Returns the subFacility names for this TraceManager/Facility. getTraces() public java.util.Enumeration getTraces() Returns an enumeration of the Trace objects managed by this TraceManager. getTraceWriterManager() public com.cisco.services.tracing.TraceWriterManager getTraceWriterManager() Returns the TraceWriter used by this TraceManager. getUnconditionalTrace(int) public com.cisco.services.tracing.UnconditionalTrace getUnconditionalTrace(int severity) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 726 Cisco Unified JTAPI Alarms and Services Methods

Page 790 content

Page 791

Creates a new UnconditionalTrace object or obtains an existing UnconditionalTrace object for this condition. getUnconditionalTrace(String, int) public com.cisco.services.tracing.UnconditionalTrace getUnconditionalTrace(java.lang.String subFacility, intseverity) Creates a new UnconditionalTrace object or obtains an existing UnconditionalTrace object for this condition and subFacility removeTrace(Trace) public void removeTrace(com.cisco.services.tracing.Trace tc) Removes a Trace object given an object. setSubFacilities(String[]) public void setSubFacilities(java.lang.String[] names) Deprecated and replaced with TraceManager.addSubFacilities method Sets a set of subFacilities for this TraceManager/Facility. setSubFacility(String) public void setSubFacility(java.lang.String name) Deprecated and replaced with TraceManager.addSubFacility method Adds a single subFacility for this TraceManager/Facility. setTraceWriterManager(TraceWriterManager) public void setTraceWriterManager(com.cisco.services.tracing.TraceWriterManager twm) Sets the TraceWriter to be used by this TraceManager. TraceModule The TraceModule interface serves two purposes. First, it allows applications to discover the TraceManager object used by other packages that they use. Second, applications that register with the TraceManagerFactory must identify themselves by implementing this interface. Declaration public interface TraceModule All Known Subinterfaces com.cisco.jtapi.extensions.CiscoJtapiPeer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 727 Cisco Unified JTAPI Alarms and Services TraceModule

Page 791 content

Page 792

Member Summary Member summary Methods getTraceManager(), on page 728 Returns the TraceManager that an object is using for tracing. TraceManager getTraceModuleName(), on page 728 Returns the module name. java.lang.String Methods getTraceManager() public com.cisco.services.tracing.TraceManager getTraceManager() Returns the TraceManager that an object is using for tracing. getTraceModuleName() public java.lang.String getTraceModuleName() Returns the module name. TraceWriter The TraceWriter interface abstracts the details of trace message output. The TraceWriter uses its enabled method to advertise whether or not the print and println methods will have any effect. Users of TraceWriter should use the value returned by the getEnabled method as an indication of whether they should invoke the print and println methods at all. Declaration public interface TraceWriter All Known Subinterfaces TraceWriterManager, on page 731 All Known Implementing Classes BaseTraceWriter, on page 695 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 728 Cisco Unified JTAPI Alarms and Services Member Summary

Page 792 diagram

Page 793

Member Summary Member summary Methods close(), on page 729 Releases any resources associated by this TraceWriter . void flush(), on page 729 Forces output of any messages that have been printed using the println method void getDescription(), on page 729 java.lang.String getEnabled(), on page 730 Returns whether the println method will print anything or not. boolean getName(), on page 730 java.lang.String getTraceLevels(), on page 730 int[] println(String, int), on page 730 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. void setTraceLevels(int[]), on page 730 set the trace levels that will be traced by this TraceWriter void Methods close() public void close() Releases any resources associated by this TraceWriter. flush() public void flush() Forces output of any messages that have been printed using the println method getDescription() public java.lang.String getDescription() Returns: a short description of this TraceWriter Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 729 Cisco Unified JTAPI Alarms and Services Member Summary

Page 793 diagram

Page 794

getEnabled() public boolean getEnabled() Returns whether the println method will print anything or not. A closed TraceWriter will always return false from this method. Returns: true if this TraceWriter is enabled, false if not getName() public java.lang.String getName() Returns: the name of this TraceWriter getTraceLevels() public int[] getTraceLevels() Returns: the array of trace levels that will be traced by this TraceWriter println(String, int) public void println(java.lang.String message, intseverity) 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 Parameters: message - the string to print severity - of the trace. See Also Trace, on page 714 setTraceLevels(int[]) public void setTraceLevels(int[] levels) set the trace levels that will be traced by this TraceWriter Parameters: int[] - levels See Also Trace, on page 714 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 730 Cisco Unified JTAPI Alarms and Services Methods

Page 794 content

Page 795

TraceWriterManager TraceWriterManager contains the list of TraceWriter objects that are used to implement the tracing. The list is populated at startup from the switches in a .ini file. A LogFileTraceWriter, a ConsoleTraceWriter, and a SyslogTraceWriter are available. Users can override the existing TraceWriters by setting a user implemented TraceWriter[] or adding to the existing TraceWriters. This makes it possible to add other TraceWriters that can function along with existing trace writers. Declaration public interface TraceWriterManager extends TraceWriter, on page 728 All Superinterfaces TraceWriter, on page 728 Member Summary Member summary Methods addTraceWriter(TraceWriter), on page 732 Add another TraceWriter to the array void getTraceWriters(), on page 732 TraceWriter[] removeTraceWriter(TraceWriter), on page 732 Remove the TraceWriter from the array in the manager void setTraceWriters(TraceWriter[]), on page 732 Implementations can use this method to override or enhance the provided TraceWriters void Inherited member summary Methods inherited from interface TraceWriter, on page 728 close(), on page 729, flush(), on page 729, getDescription(), on page 729, getEnabled(), on page 730, getName(), on page 730, getTraceLevels(), on page 730, println(String, int), on page 730, setTraceLevels(int[]), on page 730 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 731 Cisco Unified JTAPI Alarms and Services TraceWriterManager

Page 795 diagram

Page 796

Methods addTraceWriter(TraceWriter) public voidaddTraceWriter(com.cisco.services.tracing.TraceWriter traceWriter) Add another TraceWriter to the array Parameters: TraceWriter - to be added to the list getTraceWriters() public com.cisco.services.tracing.TraceWriter[] getTraceWriters() Returns: the array of TraceWriters in the manager removeTraceWriter(TraceWriter) public voidremoveTraceWriter(com.cisco.services.tracing.TraceWriter traceWriter) Remove the TraceWriter from the array in the manager setTraceWriters(TraceWriter[]) public voidsetTraceWriters(com.cisco.services.tracing.TraceWriter[] traceWriters) Implementations can use this method to override or enhance the provided TraceWriters Parameters: set - the array of TraceWriters. Tracing Implementation Class Hierarchy The following tracing implementation class hierarchy is contained in the com.cisco.services.tracing.implementation package. java.lang.Object com.cisco.services.tracing.implementation.TraceImpl, on page 733 (implements com.cisco.services.tracing.Trace) com.cisco.services.tracing.implementation.ConditionalTraceImpl, on page 735 (implements com.cisco.services.tracing.ConditionalTrace) com.cisco.services.tracing.implementation.UnconditionalTraceImpl, on page 736 (implements com.cisco.services.tracing.UnconditionalTrace) com.cisco.services.tracing.implementation.TraceManagerImpl, on page 737 (implements com.cisco.services.tracing.TraceManager) com.cisco.services.tracing.implementation.TraceWriterManagerImpl, on page 741 (implements com.cisco.services.tracing.TraceWriterManager) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 732 Cisco Unified JTAPI Alarms and Services Methods

Page 796 content

Page 797

TraceImpl Declaration public abstract class TraceImpl extends java.lang.Object implements Trace All Implemented Interfaces Trace, on page 714 Methods println public final void println(java.lang.String message) Description copied from interface: Trace Prints a message in the same format as Trace.print() and terminates the line as defined by the system. Specified by: println in interface Trace Parameters: message - the message to be printed println public final void println(java.lang.String mnemonic, java.lang.String message) Description copied from interface: Trace Prints a message in the same format as Trace.print() and terminates the line as defined by the system. Specified by: println in interface Trace Parameters: mnemonic - the mnemonic mapped to message to be printed message - the message to be printed println public final void println(java.lang.Object object) Description copied from interface: Trace Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 733 Cisco Unified JTAPI Alarms and Services TraceImpl

Page 797 content

Page 798

Prints the string returned by the Object.toString() method and terminates the line as defined by the system. Specified by: println in interface Trace Parameters: object - the object to be printed println public final void println(java.lang.String mnemonic, java.lang.Object object) Description copied from interface: Trace Prints the string returned by the Object.toString() method and terminates the line as defined by the system. Specified by: println in interface Trace Parameters: mnemonic - the mnemonic mapped to message to be printed object - the object to be printed getName public final java.lang.String getName() Description copied from interface: Trace Returns the name of this Trace object. Specified by: getName in interface Trace Returns: the name of this Trace object setDefaultMnemonic public final void setDefaultMnemonic(java.lang.String mnemonic) Description copied from interface: Trace Sets a default mnemonic for all messages printed out to this trace. Specified by: setDefaultMnemonic in interface Trace Parameters: mnemonic - a mnemonic string getType public int getType() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 734 Cisco Unified JTAPI Alarms and Services Methods

Page 798 content

Page 799

Description copied from interface: Trace Returns the type of trace. Specified by: getType in interface Trace Returns: the trace severity as specified in Syslog. DEBUGGING, INFORMATIONAL, WARNING, etc. getSubFacility public java.lang.String getSubFacility() Description copied from interface: Trace Returns the subFacility of trace Specified by: getSubFacility in interface Trace Returns: the trace subFacility type Inherited Methods isEnabled ConditionalTraceImpl Declaration public final class ConditionalTraceImpl extends TraceImpl implements ConditionalTrace All Implemented Interfaces ConditionalTrace, Trace Methods enable public void enable() Description copied from interface: ConditionalTrace Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 735 Cisco Unified JTAPI Alarms and Services Inherited Methods

Page 799 content

Page 800

Enables this condition for tracing. Specified by: enable in interface ConditionalTrace disable public void disable() Description copied from interface: ConditionalTrace Disables this condition for tracing. Specified by: disable in interface ConditionalTrace isEnabled public boolean isEnabled() Description copied from interface: Trace Returns the state of this Trace object. By default, Trace objects are enabled, that is, println() method will always trace. The state may not be changed through this interface, however, this object may implement additional interfaces that allow the state to be changed. Specified by: isEnabled in interface Trace Returns: true if tracing is enabled, false otherwise See Also: ConditionalTrace Inherited Methods Inherited methods from class java.lang.Object are: clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait. UnconditionalTraceImpl Declaration public final class UnconditionalTraceImpl extends TraceImpl implements UnconditionalTrace Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 736 Cisco Unified JTAPI Alarms and Services Inherited Methods

Page 800 content

Page 801

All Implemented Interfaces Trace, UnconditionalTrace Methods isEnabled public boolean isEnabled() Description copied from interface: Trace Returns the state of this Trace object. By default, Trace objects are enabled, that is, println() method will always trace. The state may not be changed through this interface, however, this object may implement additional interfaces that allow the state to be changed. Specified by: isEnabled in interface Trace Returns: true if tracing is enabled, false otherwise See Also: ConditionalTrace Inherited Methods Inherited methods from class java.lang.Object are: clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait. TraceManagerImpl The TraceManagerImpl class implements the TraceManager interface. Declaration public class TraceManagerImpl extends java.lang.Object java.lang.Object | +--com.cisco.services.tracing.implementation.TraceManagerImpl All Implemented Interfaces TraceManager, on page 723 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 737 Cisco Unified JTAPI Alarms and Services All Implemented Interfaces

Page 801 content

Page 802

Constructors public TraceManagerImpl(java.lang.StringmoduleName, java.lang.String[]subFacilities, TraceWriterManagertraceWriterManager) public TraceManagerImpl(java.lang.StringmoduleName, TraceWriterManagertraceWriterManager) Methods getConditionalTrace public ConditionalTrace getConditionalTrace(intseverity) Description copied from interface: TraceManager Creates a new ConditionalTrace object or obtains an existing ConditionalTrace object for this condition. Specified by: getConditionalTrace in interface TraceManager getConditionalTrace public ConditionalTrace getConditionalTrace(java.lang.StringsubFacility, intseverity) Description copied from interface: TraceManager Creates a new ConditionalTrace object or obtains an existing ConditionalTrace object for this condition and subFacility Specified by: getConditionalTrace in interface TraceManager getUnconditionalTrace public UnconditionalTrace getUnconditionalTrace(intseverity) Description copied from interface: TraceManager Creates a new UnconditionalTrace object or obtains an existing UnconditionalTrace object for this condition. Specified by: getUnconditionalTrace in interface TraceManager getUnconditionalTrace public UnconditionalTrace getUnconditionalTrace(java.lang.StringsubFacility, intseverity) Description copied from interface: TraceManager Creates a new UnconditionalTrace object or obtains an existing UnconditionalTrace object for this condition and subFacility Specified by: getUnconditionalTrace in interface TraceManager Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 738 Cisco Unified JTAPI Alarms and Services Constructors

Page 802 content

Page 803

getTraceWriterManager public TraceWriterManager getTraceWriterManager() Description copied from interface: TraceManager Returns the TraceWriter used by this TraceManager. Specified by: getTraceWriterManager in interface TraceManager setTraceWriterManager public void setTraceWriterManager(TraceWriterManagerout) Description copied from interface: TraceManager Sets the TraceWriter to be used by this TraceManager. Specified by: setTraceWriterManager in interface TraceManager removeTrace public void removeTrace(Tracetc) Description copied from interface: TraceManager Removes a Trace object given an object. Specified by: removeTrace in interface TraceManager getTraces public java.util.Enumeration getTraces() Description copied from interface: TraceManager Returns an enumeration of the Trace objects managed by this TraceManager. Specified by: getTraces in interface TraceManager enableAll public void enableAll() Description copied from interface: TraceManager Enables tracing for all Trace objects managed by this TraceManager. Specified by: enableAll in interface TraceManager disableAll public void disableAll() Description copied from interface: TraceManager Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 739 Cisco Unified JTAPI Alarms and Services Methods

Page 803 content

Page 804

Disables tracing for all Trace objects managed by this TraceManager. Specified by: disableAll in interface TraceManager getName public java.lang.String getName() Description copied from interface: TraceManager Returns the Facility name for this TraceManager. Specified by: getName in interface TraceManager enableTimeStamp public void enableTimeStamp() Description copied from interface: TraceManager Enables prefixing a time stamp for every message printed by this TraceManager. Specified by: enableTimeStamp in interface TraceManager disableTimeStamp public void disableTimeStamp() Description copied from interface: TraceManager Disables prefixing a time stamp for every message printed by this TraceManager. Specified by: disableTimeStamp in interface TraceManager getSubFacilities public java.lang.String[] getSubFacilities() Returns the subFacility names for this TraceManager/Facility. Specified by: getSubFacilities in interface TraceManager addSubFacilities public void addSubFacilities(java.lang.String[]names) Adds subFacilities for this TraceManager/Facility. Specified by: addSubFacilities in interface TraceManager Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 740 Cisco Unified JTAPI Alarms and Services Methods

Page 804 content

Page 805

addSubFacility public void addSubFacility(java.lang.Stringname) Adds a subFacility for this TraceManager/Facility. Specified by: addSubFacility in interface TraceManager Deprecated getSubFacilities(java.lang.String[]names) Replaced by addSubFacilties(String[]). setSubFacility(java.lang.Stringname) Replaced by addSubFacility(String). Inherited Methods Inherited methods from class java.lang.Object are: clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait. TraceWriterManagerImpl TraceWriterManager contains the list of TraceWriter objects that are used to implement the tracing. The list is populated at startup from the switches in a .ini file. A LogFileTraceWriter, a ConsoleTraceWriter, and a SyslogTraceWriter are available. Users can override the existing TraceWriters by setting a user implemented TraceWriter[] or adding to the existing TraceWriters. This makes it possible to add other traceWriters that can function along with exisiting trace writers. Methods inherited from class java.lang.Object are clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait. Note Declaration public class TraceWriterManagerImpl extends java.lang.Object implements TraceWriterManager java.lang.Object com.cisco.services.tracing.implementation.TraceWriterManagerImpl All Implemented Interfaces TraceWriter, TraceWriterManager Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 741 Cisco Unified JTAPI Alarms and Services Deprecated

Image 1 from page 805

Page 805 content

Page 806

Constructors TraceWriterManagerImpl public TraceWriterManagerImpl() Creates a TraceWriterManagerImpl with a zero length TraceWriter array . Methods setTraceWriters public void setTraceWriters(TraceWriter[]traceWriters) Overrides the existing TraceWriters with a new user supplied set . Specified by: setTraceWriters in interface TraceWriterManager Parameters: traceWriters - An array of TraceWriters. getTraceWriters public TraceWriter[] getTraceWriters() Returns the array of TraceWriters currently in use . Specified by: getTraceWriters in interface TraceWriterManager Returns: The array of TraceWriters in the manager. addTraceWriter public void addTraceWriter(TraceWritertw) Add this TraceWriter to the array of trace writers Specified by: addTraceWriter in interface TraceWriterManager Parameters: tw - TraceWriter to be added to the list removeTraceWriter public void removeTraceWriter(TraceWritertw) Remove the Tracewriter from the array of trace writers. Specified by: removeTraceWriter in interface TraceWriterManager Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 742 Cisco Unified JTAPI Alarms and Services Constructors

Page 806 content

Page 807

println public void println(java.lang.Stringmessage, intseverity) All traces invoke this method. A trace supplies its severity along with the message. Traces below the threshold severity of the TraceWriter are allowed. Eg. If the Threshhold severity is set to INFORMATIONAL (level = 6) DEBUG traces will not be passed by the TraceWriter. The severity level is set in the constructor of the TraceWriter Specified by: println in interface TraceWriter Parameters: message - The string to print severity - The severity of the trace. See Also: Trace Flush public void flush() Description copied from interface: TraceWriter Forces output of any messages that have been printed using the println method Specified by: flush in interface TraceWriter close public void close() Description copied from interface: TraceWriter Releases any resources associated by this TraceWriter. Specified by: close in interface TraceWriter getEnabled public boolean getEnabled() Returns true if any one of the underlying TraceWriter is enabled, else returns false. Specified by: getEnabled in interface TraceWriter Returns: True if this TraceWriter is enabled, false if not. getName public java.lang.String getName() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 743 Cisco Unified JTAPI Alarms and Services Methods

Page 807 content

Page 808

Specified by: getName in interface TraceWriter Returns: The name of this TraceWriter. getDescription public java.lang.String getDescription() Specified by: getDescription in interface TraceWriter Returns: A short description of this TraceWriter. setTraceLevels public void setTraceLevels(int[]levels) The TraceWriterManager does nothing for this method . Specified by: setTraceLevels in interface TraceWriter Parameters: Levels - Array of trace levels. See Also: Trace getTraceLevels public int[] getTraceLevels() The TraceWriterManager returns a null, as the traceLevel is maintained at the individual TraceWriter . Specified by: getTraceLevels in interface TraceWriter Returns: null Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 744 Cisco Unified JTAPI Alarms and Services Methods

Page 808 content

Page 809

C H A P T E R 7 Cisco Unified JTAPI Examples This chapter provides the source code for makecall, the Cisco Unified JTAPI program that is used to test the JTAPI installation. The makecall program comprises a series of programs that were written in Java by using the Cisco Unified JTAPI implementation. For instructions on how to invoke makecall, see Running makecall, on page 759. The Cisco Unified JTAPI Test tool can also be used to review message examples and test JTAPI features and functions. For details, refer http://developer.cisco.com/web/jtapi/docs. • MakeCall.java, on page 745 • Actor.java, on page 747 • Originator.java, on page 751 • Receiver.java, on page 755 • StopSignal.java, on page 756 • Trace.java, on page 757 • TraceWindow.java, on page 758 • Running makecall, on page 759 MakeCall.java /** * makecall.java *

Copyright Cisco Systems, Inc. *
Performance-testing application (first pass) for Cisco JTAPI
implementation. *
Known problems: *
Due to synchronization problems between Actors, calls may
not be cleared when this application shuts down. * */ //import com.ms.wfc.app.*; import java.util.*; import javax.telephony.*; import javax.telephony.events.*; import com.cisco.cti.util.Condition; Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 745

Image 1 from page 809

Page 809 content

Page 810

public class makecall extends TraceWindow implements ProviderObserver { Vectoractors

new Vector (); ConditionconditionInService

new Condition (); Providerprovider; public makecall ( String [] args ) { super ( "makecall" + ": "+ new CiscoJtapiVersion()); try { println ( "Initializing Jtapi" ); int curArg

0; String providerName

args[curArg++]; String login

args[curArg++]; String passwd

args[curArg++]; int actionDelayMillis

Integer.parseInt ( args[curArg++] ); String src

null; String dest

null; JtapiPeer peer

JtapiPeerFactory.getJtapiPeer ( null ); if ( curArg < args.length ) { String providerString

providerName + ";login = " + login + ";passwd = " + passwd; println ( "Opening " + providerString + "...\n" ); provider

peer.getProvider ( providerString ); provider.addObserver ( this ); conditionInService.waitTrue (); println ( "Constructing actors" ); for ( ; curArg < args.length; curArg++ ) { if ( src

= null ) { src

args[curArg]; } else { dest

args[curArg]; Originator originator

new Originator ( provider.getAddress ( src ), dest, this, actionDelayMillis ); actors.addElement ( originator ); actors.addElement ( new Receiver ( provider.getAddress ( dest ), this, actionDelayMillis, originator ) ); src

null; dest

null; } } if ( src ! = null ) { println ( "Skipping last originating address "" + src + ""; no destination specified" ); } } Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 746 Cisco Unified JTAPI Examples MakeCall.java

Page 810 content

Page 811

Enumeration e

actors.elements (); while ( e.hasMoreElements () ) { Actor actor

(Actor) e.nextElement (); actor.initialize (); } Enumeration en

actors.elements (); while ( en.hasMoreElements () ) { Actor actor

(Actor) en.nextElement (); actor.start (); } } catch ( Exception e ) { println ( "Caught exception " + e ); } } public void dispose () { println ( "Stopping actors" ); Enumeration e

actors.elements (); while ( e.hasMoreElements () ) { Actor actor

(Actor) e.nextElement (); actor.dispose (); } } public static void main ( String [] args ) { if ( args.length < 6 ) { System.out.println ( "Usage: makecall <server> <login> <password> <delay> <origin> <destination> ..." ); System.exit ( 1 ); } new makecall ( args ); } public void providerChangedEvent ( ProvEv [] eventList ) { if ( eventList ! = null ) { for ( int i

0; i < eventList.length; i++ ) { if ( eventList[i] instanceof ProvInServiceEv ) { conditionInService.set (); } } } } } Actor.java /** * Actor.java * Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 747 Cisco Unified JTAPI Examples Actor.java

Page 811 content

Page 812

Copyright Cisco Systems, Inc. * */ import javax.telephony.*; import javax.telephony.events.*; import javax.telephony.callcontrol.*; import javax.telephony.callcontrol.events.*; import com.cisco.jtapi.extensions.*; public abstract class Actor implements AddressObserver, TerminalObserver, CallControlCallObserver, Trace { public static final int ACTOR_OUT_OF_SERVICE = 0; public static final int ACTOR_IN_SERVICE = 1; private Tracetrace; protected intactionDelayMillis; private AddressobservedAddress; private Terminal observedTerminal; private boolean addressInService; private boolean terminalInService; protected int state = Actor.ACTOR_OUT_OF_SERVICE; public Actor ( Trace trace, Address observed, int actionDelayMillis ) { this.trace = trace; this.observedAddress = observed; this.observedTerminal = observed.getTerminals ()[0]; this.actionDelayMillis = actionDelayMillis; } public void initialize () { try { if ( observedAddress ! = null ) { bufPrintln ( "Adding Call observer to address "

observedAddress.getName () ); observedAddress.addCallObserver ( this ); //Now add observer on Address and Terminal bufPrintln ( "Adding Adddress Observer to address "
observedAddress.getName () ); observedAddress.addObserver ( this ); bufPrintln ( "Adding Terminal Observer to Terminal" + observedTerminal.getName () ); observedTerminal.addObserver ( this ); } } catch ( Exception e ) { } finally { flush (); Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 748 Cisco Unified JTAPI Examples Actor.java

Page 812 content

Page 813

} } public final void start () { onStart (); } public final void dispose () { try { onStop (); if ( observedAddress ! = null ) { bufPrintln ( "Removing observer from Address "

observedAddress.getName () ); observedAddress.removeObserver ( this ); bufPrintln ( "Removing call observer from Address "
observedAddress.getName () ); observedAddress.removeCallObserver ( this ); } if ( observedTerminal ! = null ) { bufPrintln ( "Removing observer from terminal "
observedTerminal.getName () ); observedTerminal.removeObserver ( this ); } } catch ( Exception e ) { println ( "Caught exception " + e ); } finally { flush (); } } public final void stop () { onStop (); } public final void callChangedEvent ( CallEv [] events ) { // // for now, all metaevents are delivered in the // same package... // metaEvent ( events ); } public void addressChangedEvent ( AddrEv [] events ) { Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 749 Cisco Unified JTAPI Examples Actor.java

Page 813 content

Page 814

for ( int i = 0; i<events.length; i++ ) { Address address

events[i].getAddress (); switch ( events[i].getID () ) { case CiscoAddrInServiceEv.ID: bufPrintln ( "Received " + events[i] + "for "+ address.getName ()); addressInService

true; if ( terminalInService ) { if ( state ! = Actor.ACTOR_IN_SERVICE ) { state

Actor.ACTOR_IN_SERVICE ; fireStateChanged (); } } break; case CiscoAddrOutOfServiceEv.ID: bufPrintln ( "Received " + events[i] + "for "+ address.getName ()); addressInService

false; if ( state ! = Actor.ACTOR_OUT_OF_SERVICE ) { // you only want to notify when you had notified earlier that you are IN_SERVICE state

Actor.ACTOR_OUT_OF_SERVICE; fireStateChanged (); } break; } } flush (); } public void terminalChangedEvent ( TermEv [] events ) { for ( int i = 0; i<events.length; i++ ) { Terminal terminal

events[i].getTerminal (); switch ( events[i].getID () ) { case CiscoTermInServiceEv.ID: bufPrintln ( "Received " + events[i] + "for " + terminal.getName ()); terminalInService

true; if ( addressInService ) { if ( state ! = Actor.ACTOR_IN_SERVICE ) { state

Actor.ACTOR_IN_SERVICE; fireStateChanged (); } } break; case CiscoTermOutOfServiceEv.ID: bufPrintln ( "Received " + events[i] + "for " + terminal.getName () ); terminalInService

false; if ( state ! = Actor.ACTOR_OUT_OF_SERVICE ) { // you only want to notify when you had notified earlier that you are IN_SERVICE state

Actor.ACTOR_OUT_OF_SERVICE; fireStateChanged (); } break; } } flush(); Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 750 Cisco Unified JTAPI Examples Actor.java

Page 814 content

Page 815

} final void delay ( String action ) { if ( actionDelayMillis ! = 0 ) { println ( "Pausing " + actionDelayMillis + " milliseconds before " + action ); try { Thread.sleep ( actionDelayMillis ); } catch ( InterruptedException e ) { } } } protected abstract void metaEvent ( CallEv [] events ); protected abstract void onStart (); protected abstract void onStop (); protected abstract void fireStateChanged (); public final void bufPrint ( String string ) { trace.bufPrint ( string ); } public final void bufPrintln ( String string ) { trace.bufPrint ( string ); trace.bufPrint ("\n"); } public final void print ( String string ) { trace.print ( string ); } public final void print ( char character ) { trace.print ( character ); } public final void print ( int integer ) { trace.print ( integer ); } public final void println ( String string ) { trace.println ( string ); } public final void println ( char character ) { trace.println ( character ); } public final void println ( int integer ) { trace.println ( integer ); } public final void flush () { trace.flush (); } } Originator.java /** * originator.java *

Copyright Cisco Systems, Inc. * Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 751 Cisco Unified JTAPI Examples Originator.java

Page 815 content

Page 816

/ import javax.telephony.; import javax.telephony.events.; import javax.telephony.callcontrol.; import javax.telephony.callcontrol.events.; import com.ms.com.; import com.cisco.jtapi.extensions.*; public class Originator extends Actor { AddresssrcAddress; StringdestAddress; intiteration; StopSignalstopSignal; booleanready

false; intreceiverState

Actor.ACTOR_OUT_OF_SERVICE; boolean callInIdle

true; public Originator ( Address srcAddress, String destAddress, Trace trace, int actionDelayMillis ) { super ( trace, srcAddress, actionDelayMillis );// observe srcAddress this.srcAddress

srcAddress; this.destAddress

destAddress; this.iteration

0; } protected final void metaEvent ( CallEv [] eventList ) { for ( int i

0; i < eventList.length; i++ ) { try { CallEv curEv

eventList[i]; if ( curEv instanceof CallCtlTermConnTalkingEv ) { TerminalConnection tc

((CallCtlTermConnTalkingEv)curEv).getTerminalConnection (); Connection conn

tc.getConnection (); if ( conn.getAddress ().getName ().equals ( destAddress ) ) { delay ( "disconnecting" ); bufPrintln ( "Disconnecting Connection " + conn ); conn.disconnect (); } } else if ( curEv instanceof CallCtlConnDisconnectedEv ) { Connection conn

((CallCtlConnDisconnectedEv)curEv).getConnection (); if ( conn.getAddress ().equals ( srcAddress ) ) { stopSignal.canStop (); setCallProgressState ( true ); } } } catch ( Exception e ) { println ( "Caught exception " + e ); } finally { Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 752 Cisco Unified JTAPI Examples Originator.java

Page 816 content

Page 817

flush (); } } } protected void makecall () throws ResourceUnavailableException, InvalidStateException, PrivilegeViolationException, MethodNotSupportedException, InvalidPartyException, InvalidArgumentException { println ( "Making call #" + ++iteration + " from " + srcAddress + " to " + destAddress + " " + Thread.currentThread ().getName () ); Call call

srcAddress.getProvider ().createCall (); call.connect ( srcAddress.getTerminals ()[0], srcAddress, destAddress ); setCallProgressState ( false ); println ( "Done making call" ); } protected final void onStart () { stopSignal

new StopSignal (); new ActionThread ().start (); } protected final void fireStateChanged () { checkReadyState (); } protected final void onStop () { stopSignal.stop (); Connection[] connections

srcAddress.getConnections (); try { if ( connections ! = null ) { for (int i = 0; i< connections.length; i++ ) { connections[i].disconnect (); } } } catch ( Exception e ) { println (" Caught Exception " + e); } } public int getReceiverState () { return receiverState; } public void setReceiverState ( int state ) { if ( receiverState ! = state ) { receiverState

state; checkReadyState (); } } public synchronized void checkReadyState () { if ( receiverState

= Actor.ACTOR_IN_SERVICE && state

= Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 753 Cisco Unified JTAPI Examples Originator.java

Page 817 content

Page 818

Actor.ACTOR_IN_SERVICE ) { ready

true; } else { ready

false; } notifyAll (); } public synchronized void setCallProgressState ( boolean isCallInIdle ) { callInIdle

isCallInIdle; notifyAll (); } public synchronized void doAction () { if ( !ready || !callInIdle ) { try { wait (); } catch ( Exception e ) { println (" Caught Exception from wait state" + e ); } } else { if ( actionDelayMillis ! = 0 ) { println ( "Pausing " + actionDelayMillis + " milliseconds before making call " ); flush (); try { wait ( actionDelayMillis ); } catch ( Exception ex ) { } } //make call after waking up, recheck the flags before making the call if ( ready && callInIdle ) { try { makecall (); } catch ( Exception e ) { println (" Caught Exception in MakeCall " + e + " Thread = " + Thread.currentThread ().getName ()); } } } } class ActionThread extends Thread { Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 754 Cisco Unified JTAPI Examples Originator.java

Page 818 content

Page 819

ActionThread ( ) { super ( "ActionThread"); } public void run () { while ( true ) { doAction (); } } } } Receiver.java /** * Receiver.java *

Copyright Cisco Systems, Inc. * */ import javax.telephony.*; import javax.telephony.events.*; import javax.telephony.callcontrol.*; import javax.telephony.callcontrol.events.*; public class Receiver extends Actor { Addressaddress; StopSignalstopSignal; Originatororiginator; public Receiver ( Address address, Trace trace, int actionDelayMillis, Originator originator ) { super ( trace, address, actionDelayMillis ); this.address = address; this.originator = originator; } protected final void metaEvent ( CallEv [] eventList ) { for ( int i = 0; i < eventList.length; i++ ) { TerminalConnection tc = null; try { CallEv curEv = eventList[i]; if ( curEv instanceof CallCtlTermConnRingingEv ) { tc = ((CallCtlTermConnRingingEv)curEv).getTerminalConnection (); delay ( "answering" ); bufPrintln ( "Answering TerminalConnection " + tc ); tc.answer (); stopSignal.canStop (); } } catch ( Exception e ) { Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 755 Cisco Unified JTAPI Examples Receiver.java

Page 819 content

Page 820

bufPrintln ( "Caught exception " + e ); bufPrintln ( "tc

" + tc ); } finally { flush (); } } } protected final void onStart () { stopSignal

new StopSignal (); } protected final void onStop () { stopSignal.stop (); Connection[] connections

address.getConnections (); try { if ( connections ! = null ) { for (int i = 0; i< connections.length; i++ ) { connections[i].disconnect (); } } } catch ( Exception e ) { println (" Caught Exception " + e); } } protected final void fireStateChanged () { originator.setReceiverState ( state ); } } StopSignal.java /** * StopSignal.java *

Copyright Cisco Systems, Inc. * */ class StopSignal { boolean stopping = false; boolean stopped = false; synchronized boolean isStopped () { return stopped; } synchronized boolean isStopping () { return stopping; } synchronized void stop () { Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 756 Cisco Unified JTAPI Examples StopSignal.java

Page 820 content

Page 821

if ( !stopped ) { stopping

true; try { wait (); } catch ( InterruptedException e ) { } } } synchronized void canStop () { if ( stopping

true ) { stopping

false; stopped

true; notify (); } } } Trace.java /** * Trace.java *

Copyright Cisco Systems, Inc. * */ public interface Trace { /**
bufPrint (str) puts str in buffer only. */ public void bufPrint ( String string ); /**
print () println () bufPrint and invoke flush (); */ public void print ( String string ); public void print ( char character ); public void print ( int integer ); public void println ( String string ); public void println ( char character ); public void println ( int integer ); /**
flush out the buffer. */ public void flush (); } Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 757 Cisco Unified JTAPI Examples Trace.java

Page 821 content

Page 822

TraceWindow.java /** * TraceWindow.java *

Copyright Cisco Systems, Inc. * */ import java.awt.*; import java.awt.event.*; public class TraceWindow extends Frame implements Trace { TextArea textArea; booleantraceEnabled = true; StringBuffer buffer = new StringBuffer (); public TraceWindow (String name ) { super ( name ); initWindow (); } public TraceWindow(){ this(""); } private void initWindow() { this.addWindowListener(new WindowAdapter () { public void windowClosing(WindowEvent e){dispose ();} } ); textArea = new TextArea(); setSize(400, 400); add(textArea); setEnabled(true); this.show(); } public final void bufPrint ( String str ) { if ( traceEnabled ) { buffer.append ( str ); } } public final void print ( String str ) { if ( traceEnabled ) { buffer.append ( str ); flush (); } } public final void print ( char character ) { if ( traceEnabled ) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 758 Cisco Unified JTAPI Examples TraceWindow.java

Page 822 content

Page 823

{ buffer.append ( character ); flush (); } } public final void print ( int integer ) { if ( traceEnabled ) { buffer.append ( integer ); flush (); } } public final void println ( String str ) { if ( traceEnabled ) { print ( str ); print ( '\n' ); flush (); } } public final void println ( char character ) { if ( traceEnabled ) { print ( character ); print ( '\n' ); flush (); } } public final void println ( int integer ) { if ( traceEnabled ) { print ( integer ); print ( '\n' ); flush (); } } public final void setTrace ( boolean traceEnabled ) { this.traceEnabled

traceEnabled; } public final void flush () { if ( traceEnabled ) { textArea.append ( buffer.toString()); buffer

new StringBuffer (); } } public final void clear () { textArea.setText(""); } } Running makecall To Invoke makecall on the client workstation, from the Windows NT command line, navigate to the makecall directory where JTAPI Tools directory was installed and execute the following command: jview makecall <server name> <login> <password> 1000 <device 1> <device2> Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 759 Cisco Unified JTAPI Examples Running makecall

Page 823 content

Page 824

<server name> specifies the hostname or IP address of your Cisco Unified Communications Manager. <device1> and <device2> are directory numbers of IP phones. Make sure that the phones are part of the associated devices of a given user as administered in the Cisco Unified Communications Manager’s directory administration. <login> and <password> apply similarly as administered in the directory. This will test that you have installed and configured everything correctly. The application will make calls between the two devices with an action delay of 1000 msecs until terminated. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 760 Cisco Unified JTAPI Examples Running makecall

Page 824 content

Page 825

A P P E N D I X A Message Sequence Charts This appendix contains message sequence charts illustrating the message flows for several scenarios. • Agent Greeting, on page 762 • API for Exposing Built-in-Bridge Status, on page 766 • Backward Compatibility Enhancements, on page 768 • Barge and Privacy, on page 782 • Call Control Discovery, on page 785 • CallFwdAll Keys Press Notification, on page 793 • Call Recording for SIP or TLS Authenticated calls , on page 796 • CallSelect and UnSelect, on page 797 • Cius Persistency, on page 798 • Conference and Join, on page 799 • CTI Manager Redundancy Handling with Least Priority CTIManager Configured, on page 805 • CTI Manager Redundancy Handling with Least Priority CTI Server Set, on page 806 • CTI Remote Device, on page 807 • CTI RD Call Forward, on page 876 • CTI Video Support, on page 885 • Device and Line Restriction, on page 892 • Device State Server, on page 895 • Do Not Disturb, on page 895 • Dynamic CTIPort Registration Per Call, on page 901 • E911 Teleworker, on page 902 • Encryption Enhancement, on page 903 • End to End Call Tracing, on page 904 • Hunt Log Status for Phone Devices, on page 920 • Energywise Deep Sleep Mode, on page 923 • External Call Control, on page 929 • Extension Mobility Cross Cluster, on page 978 • End to End Session ID for Calls, on page 981 • Forced Authorization and Customer Matter Codes, on page 991 • Hairpin Support, on page 998 • Half Duplex Media, on page 1000 • Hunt List, on page 1000 • Hunt List Connected Number, on page 1043 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 761

Image 1 from page 825

Page 825 content

Page 826

• Intercom, on page 1051 • iSac Codec, on page 1057 • JTAPI Cisco Unified IP 7931G Phone Interaction, on page 1062 • Call Pickup, on page 1109 • Media Termination at Route Point, on page 1263 • Mobility Interaction Support, on page 1265 • Modifying Calling Number, on page 1271 • Silent Monitoring Use Cases, on page 1274 • Native Queuing, on page 1287 • Use Cases for NuRD (Number Matching for Remote Destination), on page 1307 • Partition Support, on page 1337 • Persistent Connection Use Cases, on page 1343 • Play Announcement, on page 1356 • Play Zip Tone, on page 1390 • QoS Support, on page 1391 • QSIG Path Replacement, on page 1392 • Recording Use Cases, on page 1394 • Redirect Set OriginalCalledID, on page 1447 • Redirect to a Device, on page 1449 • Verify Remote Destination Support, on page 1452 • Secure Conferencing, on page 1455 • Secure Connection Enhancements, on page 1459 • Secure Icon Enhancements, on page 1459 • Shared Line Support, on page 1471 • Single Sign-On, on page 1474 • Single Step Transfer, on page 1475 • SIP REPLACE, on page 1478 • SIP Support, on page 1497 • SIP Trunk Early Offer, on page 1498 • SRTP Key Material, on page 1509 • Super Provider Message Flow, on page 1510 • Support for Cisco Unified IP Phone 6901, on page 1512 • SHA Support for Digital Signatures, on page 1535 • TLS Security, on page 1536 • Transfer and Direct Transfer, on page 1538 • Unicode Support, on page 1541 • Unrestricted Unified CM, on page 1541 • Video Capabilities and Multi-Media Information, on page 1542 • Video On Hold, on page 1581 • Verification Involving PSTN Reachability, on page 1583 • Whisper Coaching, on page 1588 Agent Greeting The basic Agent Greeting use cases assume a common setup. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 762 Message Sequence Charts Agent Greeting

Page 826 content

Page 827

In the real-world scenario, an external customer calls a number and is routed through an IVR until the call is eventually offered to an agent. IP Phones: • Customer (1000) • Agents (2000, 2001, 2002) • IVRs (5000, 5001) Scenario One Agent Greeting Start Success Call information / Notes Events Action This is a basic call. Calling = 1000 (Customer) Called = 2000 (Agent) GC1 - CallActiveEvent GC1 - ConnCreatedEvent (1000) GC1 - ConnConnectedEvent (1000) GC1 - CallCtlConnInitiatedEv (1000) GC1 - TermConnCreatedEvent (Term of 1000) GC1 - TermConnActiveEvent (Term of 1000) GC1 - CallCtlTermConnTalkingEv (Term of 1000) GC1 - CallCtlConnDialingEv (1000) GC1 - CallCtlConnEstablishedEv (1000) GC1 - ConnCreatedEvent (2000) GC1 - ConnInprogressEvent (2000) GC1 - CallCtlConnOfferedEv (2000) GC1 - ConnAlertingEvent (2000) GC1 - CallCtlConnAlertingEv (2000) GC1 - TermConnCreatedEvent (Term of 2000) GC1 - TermConnRingingEvent (Term of 2000) GC1 - CallCtlTermConnRingingEv (Term of 2000) GC1 - ConnConnectedEvent (2000) GC1 - CallCtlConnEstablishedEv (2000) GC1 - TermConnActiveEvent (Term of 2000) GC1 - CallCtlTermConnTalkingEv (Term of 2000)

Customer dials the agent. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 763 Message Sequence Charts Message Sequence Charts

Page 827 diagram

Page 828

Call information / Notes Events Action This is a server call. Calling = 2000 (Agent) Called = 5000 (IVR) The Calling Party number is as specified in the addMediaStream() method ("2000" in this case), and is available immediately from the CallActiveEvent. Note No connection for 2000 is created, as 2000 is "spoofed". Agent Greeting is complete. GC2 - CallActiveEvent GC2 - ConnCreatedEvent (5000) GC2 - ConnInprogressEvent (5000) GC2 - CallCtlConnOfferedEv (5000) GC2 - ConnAlertingEvent (5000) GC2 - CallCtlConnAlertingEv (5000) GC2 - TermConnCreatedEvent (Term of 5000) GC2 - TermConnRingingEvent (Term of 5000) GC2 - CallCtlTermConnRingingEv (Term of 5000) GC2 - ConnConnectedEvent (5000) GC2 - CallCtlConnEstablishedEv (5000) GC2 - TermConnActiveEvent (Term of 5000) GC2 - CallCtlTermConnTalkingEv (Term of 5000) GC1 - CiscoMediaStreamStartedEv (2000) 2. Application gets the TerminalConnection for 2000 on GC1 and invokes addMediaStream( "5000", "2000" ) BIB call is cleaned up. Ev.isSuccessful() = true. The call continues as normal. GC2 - CallCtlTermConnDroppedEv (Term of 5000) GC2 - ConnDisconnectedEvent (5000) GC2 - CallCtlConnDisconnectedEv (5000) GC2 - CallInvalidEvent (5000) GC2 - CallObservationEndedEv GC1 - CiscoMediaStreamEndedEv (2000) 3. Application disconnects IVR, or tester manually hangs up the IVR device. Primary call is cleaned up. GC1 - TermConnDroppedEv (Term of 2000) GC1 - CallCtlTermConnDroppedEv (Term of 2000) GC1 - ConnDisconnectedEvent (2000) GC1 - CallCtlConnDisconnectedEv (2000) GC1 - TermConnDroppedEv (Term of 1000) GC1 - CallCtlTermConnDroppedEv (Term of 1000) GC1 - ConnDisconnectedEvent (1000) GC1 - CallCtlConnDisconnectedEv (1000) GC1 - CallInvalidEvent GC1 - CallObservationEndedEv 4. Agent finishes the conversation and ends the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 764 Message Sequence Charts Message Sequence Charts

Page 828 diagram

Page 829

Scenario Two Agent Greeting Stop Success Call information / Notes Events Agent Ev.getIVRCall() = Call for CG2. GC1 - CiscoMediaStreamStartedEv (2000)

Customer calls the agent and the agent answers. Application invokes addMediaStream(). The Agent Greeting is cut short. The BIB call is cleaned up. Ev.isSuccessful() = true. The call continues as normal. GC2 - CallCtlTermConnDroppedEv (Term of 5000) GC2 - ConnDisconnectedEvent (5000) GC2 - CallCtlConnDisconnectedEv (5000) GC2 - CallInvalidEvent (5000) GC2 - CallObservationEndedEv GC1 - CiscoMediaStreamEndedEv (2000)
While the greeting is played, the application invokes removeMediaStream(). The primary call is cleaned up. GC1 - TermConnDroppedEv (Term of 2000) GC1 - CallCtlTermConnDroppedEv (Term of 2000) GC1 - ConnDisconnectedEvent (2000) GC1 - CallCtlConnDisconnectedEv (2000) GC1 - TermConnDroppedEv (Term of 1000) GC1 - CallCtlTermConnDroppedEv (Term of 1000) GC1 - ConnDisconnectedEvent (1000) GC1 - CallCtlConnDisconnectedEv (1000) GC1 - CallInvalidEvent GC1 - CallObservationEndedEv
The agent finishes the conversation and ends the call. Scenario Three Agent Greeting Start Failure: Resource Unavailable Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 765 Message Sequence Charts Message Sequence Charts

Page 829 diagram

Page 830

Call information / Notes Event Agent This is a basic call Calling = 1000 (Customer) Called = 2000 (Agent) GC1 - CallActiveEvent GC1 - ConnCreatedEvent (1000) GC1 - ConnConnectedEvent (1000) GC1 - CallCtlConnInitiatedEv (1000) GC1 - TermConnCreatedEvent (Term of 1000) GC1 - TermConnActiveEvent (Term of 1000) GC1 - CallCtlTermConnTalkingEv (Term of 1000) GC1 - CallCtlConnDialingEv (1000) GC1 - CallCtlConnEstablishedEv (1000) GC1 - ConnCreatedEvent (2000) GC1 - ConnInprogressEvent (2000) GC1 - CallCtlConnOfferedEv (2000) GC1 - ConnAlertingEvent (2000) GC1 - CallCtlConnAlertingEv (2000) GC1 - TermConnCreatedEvent (Term of 2000) GC1 - TermConnRingingEvent (Term of 2000) GC1 - CallCtlTermConnRingingEv (Term of 2000) GC1 - ConnConnectedEvent (2000) GC1 - CallCtlConnEstablishedEv (2000) GC1 - TermConnActiveEvent (Term of 2000) GC1 - CallCtlTermConnTalkingEv (Term of 2000)

Customer dials the Agent No BIB call is created. JTAPI throws a ResourceUnavailableException with text as "Unable to allocate built in bridge resource". The call continues as normal.
The application gets the TerminalConnection for 2000 on GC1and invokes addMediaStream( "5000", "2000" ). The primary call is cleaned up. GC1 - TermConnDroppedEv (Term of 2000) GC1 - CallCtlTermConnDroppedEv (Term of 2000) GC1 - ConnDisconnectedEvent (2000)
The agent finishes the conversation and ends the call. API for Exposing Built-in-Bridge Status Phone TermA, CTI port TermB, and RoutePoint TermC are in application’s control list. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 766 Message Sequence Charts API for Exposing Built-in-Bridge Status

Page 830 diagram

Page 831

Use Case One BIB is disabled on service parameters and device page of TermA. Call information Result Action False TermA.isBuiltInBridgeEnabled() MethodNotSupportedException TermB.isBuiltInBridgeEnabled() MethodNotSupportedException TermC.isBuiltInBridgeEnabled() Use Case Two BIB is disabled on service parameters page and enabled on device page of TermA.. Call information Result Action True TermA.isBuiltInBridgeEnabled() MethodNotSupportedException TermB.isBuiltInBridgeEnabled() MethodNotSupportedException TermC.isBuiltInBridgeEnabled() Use Case Three BIB is enabled on service parameters page and disabled on device page of TermA. Call information Result Action False TermA.isBuiltInBridgeEnabled() MethodNotSupportedException TermB.isBuiltInBridgeEnabled() MethodNotSupportedException TermC.isBuiltInBridgeEnabled() Use Case Four BIB is enabled on service parameters page and set to default on device page of TermA. Call information Result Action True TermA.isBuiltInBridgeEnabled() MethodNotSupportedException TermB.isBuiltInBridgeEnabled() MethodNotSupportedException TermC.isBuiltInBridgeEnabled() Use Case Five Phone TermA is not registered. BIB is enabled on device page of TermA. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 767 Message Sequence Charts Message Sequence Charts

Page 831 diagram

Page 832

Call information Result Action InvalidStateException TermA.isBuiltInBridgeEnabled() Add observers and register TermB and TermC. MethodNotSupportedException TermB.isBuiltInBridgeEnabled() MethodNotSupportedException TermC.isBuiltInBridgeEnabled() Backward Compatibility Enhancements This feature is not expected to change the performance or scalability of Cisco Unified Communications Manager JTAPI. There is no change in the number of events between JTAPI and CTI. For features involving GCID changes this feature introduces one extra event which should not cause any performance issues. In all cases events listed below are delivered to call observers when only one party is in control list. TERMA indicates terminal of A. Scenario One A calls B, B transfers the call to C. GC1 is the call between A and B, GC2 is the consult call between B and C. Similar events are delivered for Conference and other features. Events Action GC2 CiscoTransferStartEv Cause: CAUSE_NORMAL Reason = REASON_TRANSFER CallActiveEv GC1 Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED Reason = REASON_TRANSFER ConnCreatedEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED Reason = REASON_TRANSFER ConnCreatedEv B Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED Reason = REASON_TRANSFER CiscoCallChangedEv SurvingCall = GC1, original call = GC2 CiscoCause: NORMAL Reason: REASON_TRANSFER B completes the transfer. Events to call observer on C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 768 Message Sequence Charts Backward Compatibility Enhancements

Page 832 diagram

Page 833

Events Action Events delivered to CallObserver of B (transfer controller) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 769 Message Sequence Charts Message Sequence Charts

Page 833 diagram

Page 834

Events Action ConnConnectedEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED Reason = REASON_TRANSFER CallCtlConnEstablishedEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER CiscoCause: CAUSE_NORMALUNSPECIFIED Reason = REASON_TRANSFER TermConnCreatedEv TERM C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED Reason = REASON_TRANSFER TermConnActiveEv TERM C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED Reason = REASON_TRANSFER CallCtlTermConnTalkingEv TERM C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER CiscoCause: CAUSE_NORMALUNSPECIFIED Reason = REASON_TRANSFER ConnConnectedEv B Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED Reason = REASON_TRANSFER GC2: ConnDisconnectedEv B REASON = REASON_TRANSFER Cause: CAUSE_NORMAL GC2: ConnDisconnectedEv C REASON = REASON_TRANSFER Cause: CAUSE_NORMAL GC2: TermConnDropped TERMB REASON = REASON_TRANSFER Cause: CAUSE_NORMAL GC2: CalInvalid REASON = REASON_TRANSFER Cause:CAUSE_NORMAL GC1: CallCtlTermConnHeldEv TERMB REASON = REASON_TRANSFER Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 770 Message Sequence Charts Message Sequence Charts

Page 834 diagram

Page 835

Events Action GC2: ConsultCallActive REASON = NORMAL Cause:CAUSE_NEW_CALL GC2: ConnCreatedEv B REASON = NORMAL Cause:CAUSE_NORMAL GC2: ConnConnectedEv B REASON = NORMAL Cause:CAUSE_NORMAL GC1: ConnDisconnectedEv B REASON = REASON_TRANSFER Cause: CAUSE_UNKNOWN GC1: CallCtlConnDisconnectedEv B REASON = REASON_TRANSFER Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER GC1: TermConnDroppedEv TERMB REASON = REASON_TRANSFER Cause: CAUSE_UNKNOWN GC1: CallCtlTermConnDroppedEv TERMB REASON = REASON_TRANSFER CallControlCause: CAUSE_TRANSFER GC1: ConnDisconnectedEv A REASON = REASON_TRANSFER GC1: CallCtlConnDisconnectedEv A REASON = REASON_TRANSFER CallControlCause: CAUSE_TRANSFER GC1: CallInvalidEv REASON = REASON_TRANSFER GC2: ConnDisconnectedEv C REASON = REASON_TRANSFER GC2: CallCtlConnDisconnectedEv C REASON = REASON_TRANSFER CallControlCause: CAUSE_TRANSFER GC2: TermConnDroppedEv TERMB REASON = REASON_TRANSFER GC2: CallCtlTermConnDroppedEv TERMB REASON = REASON_TRANSFER CallControlCause: CAUSE_TRANSFER Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 771 Message Sequence Charts Message Sequence Charts

Page 835 diagram

Page 836

Events Action GC2: ConnDisconnectedEv B REASON = REASON_TRANSFER GC2: CallCtlConnDisconnectedEv B REASON = REASON_TRANSFER CallControlCause: CAUSE_TRANSFER GC2: CallInvalidEv REASON = REASON_TRANSFER GC2: CallObservationEndedEv REASON = NORMAL Cause:CAUSE_NORMAL GC1 CiscoTransferEndEv REASON = REASON_TRANSFER Cause: CAUSE_NORMAL GC2 CallObservationEndedEv REASON = NORMAL Cause:CAUSE_NORMAL Scenario Two A calls B, call = GC1. B parks the call at 99999. C unparks the call using call GC2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 772 Message Sequence Charts Message Sequence Charts

Page 836 diagram

Page 837

Events Action Events delivered to call observer on A when call is parked. When call is unparked using GC2 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 773 Message Sequence Charts Message Sequence Charts

Page 837 diagram

Page 838

Events Action GC1: ConnDisconnectedEv B REASON = REASON_PARK Cause: CAUSE_NORMAL GC1: CallCtlConnDisconnectedEv B REASON = REASON_PARK Cause: CAUSE_NORMAL CallControlCause: CAUSE_PARK GC1: ConnCreatedEv 9999 REASON = REASON_PARK Cause: CAUSE_NORMAL GC1: ConnInProgressEv 9999 REASON = REASON_PARK Cause: CAUSE_NORMAL GC1: CallCtlConnQueuedEv 9999 REASON = REASON_PARK Cause: CAUSE_NORMAL CallControlCause: CAUSE_PARK GC2: CiscoCallChangedEv Surviving = GC2 origcall = GC1 address = A REASON = REASON_UNPARK CallActiveEv REASON = REASON_UNPARK Cause: CAUSE_NEW_CALL GC2: ConnCreatedEv A REASON = REASON_UNPARK Cause: CAUSE_NORMAL GC2: ConnConnectedEv A REASON = REASON_UNPARK Cause: CAUSE_NORMAL GC2: CallCtlConnEstablishedEv A REASON = REASON_UNPARK Cause: CAUSE_NORMAL CallControlCause: CAUSE_PARK GC2: TermConnCreatedEv TERMA REASON = REASON_UNPARK GC2: TermConnActiveEv TERMA REASON = REASON_UNPARK Cause: CAUSE_NORMAL GC2: CallCtlTermConnTalkingEv TERMA REASON = REASON_UNPARK Cause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 774 Message Sequence Charts Message Sequence Charts

Page 838 diagram

Page 839

Events Action CallControlCause: CAUSE_PARK GC1: ConnDisconnectedEv 9999 REASON = REASON_UNPARK Cause: CAUSE_NORMAL GC1: CallCtlConnDisconnectedEv 9995 REASON = REASON_UNPARK Cause: CAUSE_NORMAL CallControlCause: CAUSE_PARK GC1: TermConnDroppedEv TERMA REASON = REASON_UNPARK Cause: CAUSE_NORMAL GC1: CallCtlTermConnDroppedEv TERMA REASON = REASON_UNPARK Cause: CAUSE_NORMAL CallControlCause: CAUSE_PARK GC1: ConnDisconnectedEv A REASON = REASON_UNPARK Cause: CAUSE_NORMAL GC1: CallCtlConnDisconnectedEv A REASON = REASON_UNPARK Cause: CAUSE_NORMAL CallControlCause: CAUSE_PARK GC1: CallInvalidEv REASON = REASON_UNPARK Cause: CAUSE_NORMAL GC1: CallObservationEndedEv REASON = NORMAL Cause: CAUSE_NORMAL GC2: ConnCreatedEv C REASON = REASON_UNPARK Cause: CAUSE_NORMAL GC2: ConnConnectedEv C REASON = UNPARK Cause: CAUSE_NORMAL GC2: CallCtlConnEstablishedEv C REASON = UNPARK Cause: CAUSE_NORMAL CallControlCause: CAUSE_PARK Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 775 Message Sequence Charts Message Sequence Charts

Page 839 diagram

Page 840

Scenario Three A calls B, B has forward no answer to C. B does not answer and call is offered to C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 776 Message Sequence Charts Message Sequence Charts

Page 840 content

Page 841

Events Action Events delivered to call observer on A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 777 Message Sequence Charts Message Sequence Charts

Page 841 diagram

Page 842

Events Action GC1: CallActiveEv REASON = NORMAL Cause: CAUSE_NEW_CALL GC1: ConnCreatedEv A REASON = NORMAL Cause: CAUSE_NORMAL GC1: ConnConnectedEv A REASON = NORMAL Cause: CAUSE_NORMAL GC1: CallCtlConnInitiatedEv A REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: TermConnCreatedEv TERMA REASON = NORMAL GC1: TermConnActiveEv TERMA REASON = NORMAL Cause: CAUSE_NORMAL GC1: CallCtlTermConnTalkingEv TERMA REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: CallCtlConnDialingEv A REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: CallCtlConnEstablishedEv A REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: ConnCreatedEv B REASON = NORMAL Cause: CAUSE_NORMAL GC1: ConnInProgressEv B REASON = NORMAL Cause: CAUSE_NORMAL GC1: CallCtlConnOfferedEv B REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: ConnAlertingEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 778 Message Sequence Charts Message Sequence Charts

Page 842 diagram

Page 843

Events Action REASON = NORMAL Cause: CAUSE_NORMAL GC1: CallCtlConnAlertingEv B REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: ConnCreatedEv C REASON = REASON_FORWARDNOANSWER Cause: CAUSE_NORMAL GC1: ConnInProgressEv C REASON = REASON_FORWARDNOANSWER Cause: CAUSE_NORMAL GC1: CallCtlConnOfferedEv C REASON = REASON_FORWARDNOANSWER Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED GC1: ConnAlertingEv C REASON = REASON_FORWARDNOANSWER Cause: CAUSE_NORMAL GC1: CallCtlConnAlertingEv C REASON = REASON_FORWARDNOANSWER Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: ConnDisconnectedEv B REASON = REASON_FORWARDNOANSWER Cause: CAUSE_NORMAL GC1: CallCtlConnDisconnectedEv B REASON = REASON_FORWARDNOANSWER Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED GC1: ConnConnectedEv C REASON = NORMAL Cause: CAUSE_NORMAL GC1: CallCtlConnEstablishedEv C REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL Scenario Four A calls B, B redirects the call to C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 779 Message Sequence Charts Message Sequence Charts

Page 843 diagram

Page 844

Events Action Events delivered to call observer on B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 780 Message Sequence Charts Message Sequence Charts

Page 844 diagram

Page 845

Events Action GC1: CallActiveEv REASON = NORMAL Cause: CAUSE_NEW_CALL GC1: ConnCreatedEv B REASON = NORMAL Cause: CAUSE_NORMAL GC1: ConnInProgressEv REASON = NORMAL Cause: CAUSE_NORMAL GC1: CallCtlConnOfferedEv B REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: ConnCreatedEv A REASON = NORMAL Cause: CAUSE_NORMAL GC1: ConnConnectedEv A REASON = NORMAL Cause: CAUSE_NORMAL GC1: CallCtlConnEstablishedEv A REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: ConnAlertingEv B REASON = NORMAL Cause: CAUSE_NORMAL GC1: CallCtlConnAlertingEv B REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: TermConnCreatedEv TERMB REASON = NORMAL Cause: Other: 0 GC1: TermConnRingingEv TERMB REASON = NORMAL Cause: CAUSE_NORMAL GC1: CallCtlTermConnRingingEvImpl TERMB REASON = NORMAL Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL GC1: ConnDisconnectedEv A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 781 Message Sequence Charts Message Sequence Charts

Page 845 diagram

Page 846

Events Action REASON = REDIRECT Cause: CAUSE_NORMAL GC1: CallCtlConnDisconnectedEv A REASON = REDIRECT Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED GC1: TermConnDroppedEv TERMB REASON = REDIRECT Cause: CAUSE_NORMAL GC1: CallCtlTermConnDroppedEv TERMB REASON = REDIRECT Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED GC1: ConnDisconnectedEv B REASON = REDIRECT Cause: CAUSE_NORMAL GC1: CallCtlConnDisconnectedEv B REASON = REDIRECT Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED GC1: CallInvalidEv REASON = REDIRECT Cause: CAUSE_NORMAL Barge and Privacy The following diagrams illustrate the message flows for Barge and Privacy. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 782 Message Sequence Charts Barge and Privacy

Page 846 diagram

Page 847

Barge Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 783 Message Sequence Charts Barge

Image 1 from page 847

Page 847 content

Page 848

CBarge Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 784 Message Sequence Charts CBarge

Image 1 from page 848

Page 848 content

Page 849

Privacy Call Control Discovery Scenario 1: A Calls 1000 in Other Cluster (SAF ICT) Call info Result Action CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnDialingEv - ATermConnCreatedEv - TA TermConnActiveEv –TA CallCtlTermConnTalkingEv - TA A dials 1000, this call is first be intercepted by CCD Requesting Feature, and CCD Requesting feature extends this call to SIP trunk getCurrentCallingAddress() = A getCurrentCalledAddress() = 1000 getCalledAddress() = 1000 ConnCreatedEv 1000 ConnInProgressEv 1000 CallCtlConnOfferedEv 1000 Called Party is 1000 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 785 Message Sequence Charts Privacy

Image 1 from page 849

Page 849 diagram

Page 850

Scenario 2: A Calls B, Within Same Cluster. B Redirects the Call to 1000, Which Is in Another Cluster (SAF ICT) Call info Result Action CallActiveEv ConnCreatedEv A ConnConnectedEv A CallCtlConnInitiatedEv A TermConnCreatedEv TA TermConnActiveEv TA CallCtlTermConnTalkingEv TA CallCtlConnEstablishedEv A ConnCreatedEv B ConnCreatedEv B CallCtlConnOfferedEv B ConnAlertingEv B CallCtlConnAlertingEv B TermConnCreatedEv TB TermConnRingingEv TB CallCtlTermConnRingingEvImpl TB A calls B within the same cluster getCurrentCallingAddress() = A getCurrentCalledAddress() = 1000 getCalledAddress() = B getLastRedirectedAddress() = B TermConnDroppedEv TB CallCtlTermConnDroppedEv TB ConnDisconnectedEv B CallCtlConnDisconnectedEv B ConnCreatedEv 1000 B redirects the call to 1000 Scenario 3: A Calls 1000 Which Is in the Other Cluster (SAF ICT Bandwidth Is Low) Call info Result Action CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnDialingEv - ATermConnCreatedEv - TA TermConnActiveEv –TA CallCtlTermConnTalkingEv - TA A dials 1000, this call is first intercepted by CCD Requesting Feature, and CCD Requesting feature extends this call to SIP trunk Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 786 Message Sequence Charts Message Sequence Charts

Page 850 diagram

Page 851

Call info Result Action getCallingAddress() = A getCalledAddress() = 1000 getCurrentCallingAddress() = A getCurrentCalledAddress() = 1000 getLastRedirectedAddress() = “” CallCtlConnEstablishedEv –A ConnCreatedEv 1000 ConnConnectedEv 1000 CallCtlConnOfferedEv 1000 SIP trunk rejects this as bandwidth is not available CiscoFeatureReason = NORMAL CallCtlCause = CAUSE_NORMAL getCallingAddress() = A getCalledAddress() = 1000 getCurrentCallingAddress() = A getCurrentCalledAddress() = 1000 getLastRedirectedAddress() = 1000 CallCtlConnNetworkReachedEv 1000 CallCtlConnNetworkAlertingEv 1000 CCD Requesting feature starts PSTN failover by directing this caller to 1000’s PSTN failover number. Call is sent out to a PSTN gateway, and calling side moves to Ringback state. Scenario 4: A Calls B Within the Cluster. B Redirects the Call to 1000 (Low Bandwidth SAF ICT) Call info Result Action CallActiveEv ConnCreatedEv A ConnConnectedEv A CallCtlConnInitiatedEv A TermConnCreatedEv TA TermConnActiveEv TA CallCtlTermConnTalkingEv TA CallCtlConnEstablishedEv A ConnCreatedEv B ConnCreatedEv B CallCtlConnOfferedEv B ConnAlertingEv B CallCtlConnAlertingEv B TermConnCreatedEv TB TermConnRingingEv TB CallCtlTermConnRingingEvImpl TB A calls B within the same cluster Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 787 Message Sequence Charts Message Sequence Charts

Page 851 diagram

Page 852

Call info Result Action TermConnDroppedEv TB CallCtlTermConnDroppedEv TB ConnDisconnectedEv B CallCtlConnDisconnectedEv B B redirects the call to 1000. This call is first intercepted by CCD Requesting Feature, and CCD Requesting feature extends this call to SIP trunk getCallingAddress() = A getCurrentCallingAddress() = A getCurrentCalledAddress() = 1000 getCalledAddress() = B getLastRedirectedAddress() = 1000 Reason = REASON_SAF_CCD_PSTN_FAILOVER ConnCreatedEv 1000 ConnConnectedEv 1000 CCD Requesting feature starts PSTN failover by directing this caller to 1000’s PSTN failover number. Call is sent out to a PSTN gateway Scenario 5: A Calls B, B Transfers the Call to 1000 (Low Bandwidth SAF ICT) Call info Result Action GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TA GC1 TermConnActiveEv TA GC1 CallCtlTermConnTalkingEv TA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnCreatedEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TB GC1 TermConnRingingEv TB GC1 CallCtlTermConnRingingEvImpl TB A calls B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 788 Message Sequence Charts Message Sequence Charts

Page 852 diagram

Page 853

Call info Result Action GC2 CallActiveEv GC2 ConnCreatedEv B GC2 ConnConnectedEv B GC2 CallCtlConnInitiatedEv B GC2 TermConnCreatedEv TB GC2 TermConnActiveEv TB GC2 CallCtlTermConnTalkingEv TB GC2 CallCtlConnEstablishedEv B GC2 ConnCreatedEv 1000 GC2 ConnCreatedEv 1000 GC2 CallCtlConnOfferedEv 1000 B makes a consult call to 1000. This call is first intercepted by CCD Requesting Feature, and CCD Requesting feature extends this call to SIP trunk. CiscofeatureReason = NORMAL CallCtlCause = CAUSE_NORMAL getCurrentCallingAddress() = A getCurrentCalledAddress() = 1000 getCalledAddress() = B getLastRedirectedAddress() = 1000 GC2 CallCtlConnNetworkReachedEv 1000 GC2 CallCtlConnNetworkAlertingEv 1000 SIP trunk rejects this call as bandwidth is not available CCD Requesting feature starts PSTN failover by directing this caller to 1000’s PSTN failover number (or as configured on the server). Call is sent out to a PSTN gateway. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 789 Message Sequence Charts Message Sequence Charts

Page 853 diagram

Page 854

Call info Result Action Reason=REASON_TRANSFEREDCALL GC1 CiscoTermConnSelectChangedEv B GC2 CiscoTermConnSelectChangedEv B GC1 CiscoTransferStartedEv GC2 CiscoCallChangedEv GC2 CiscoCallChangedEv GC1 ConnCreatedEv 1000 GC1 ConnAlertingEv 1000 GC1 CallCtlConnAlertingEv 1000 GC1 TermConnCreatedEv 1000 GC1 TermConnRingingEv 1000 GC1 CallCtlTermConnRingingEvImpl 1000 GC2 TermConnDroppedEv 1000 GC2 CallCtlTermConnDroppedEv 1000 GC2 ConnDisconnectedEv1408972 1000 GC2 CallCtlConnDisconnectedEv 1000 GC1 TermConnDroppedEv B GC1 CallCtlTermConnDroppedEv B GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectecEv B GC2 TermConnDroppedEv B GC2 CallCtlTermConnDroppedEv B GC2 ConnDisconnectedEv B GC2 CallCtlConnDisconnectecEv B GC2 CallInvalidEv GC1 CiscoTransferEndEv B completes the transfer GC1 ConnConnectedEv 1000 GC1 CallCtlConnEstablishedEv 1000 GC1 termConnActiveEv 1000 GC1 CallCtlTermConnTalkingEv 1000 A and 1000 come in direct call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 790 Message Sequence Charts Message Sequence Charts

Page 854 diagram

Page 855

Scenario 6: A Calls B, B Consults 1000 and Adds It to Conference (Low Bandwidth SAF ICT) Call info Result Action GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TA GC1 TermConnActiveEv TA GC1 CallCtlTermConnTalkingEv TA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnCreatedEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TB GC1 TermConnRingingEv TB GC1 CallCtlTermConnRingingEvImpl TB A calls B GC2 CallActiveEv GC2 ConnCreatedEv B GC2 ConnConnectedEv B GC2 CallCtlConnInitiatedEv B GC2 TermConnCreatedEv TB GC2 TermConnActiveEv TB GC2 CallCtlTermConnTalkingEv TB GC2 CallCtlConnEstablishedEv B GC2 ConnCreatedEv 1000 GC2 ConnCreatedEv 1000 GC2 CallCtlConnOfferedEv 1000 B makes a consult call to 1000 for conference. This call is first intercepted by CCD Requesting Feature, and CCD Requesting feature extends this call to SIP trunk. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 791 Message Sequence Charts Message Sequence Charts

Page 855 diagram

Page 856

Call info Result Action CiscofeatureReason = NORMAL CallCtlCause = CAUSE_NORMAL getCurrentCallingAddress() = A getCurrentCalledAddress() = 1000 getCalledAddress() = B getLastRedirectedAddress() = 1000 GC2 CallCtlConnNetworkReachedEv 1000 GC2 CallCtlConnNetworkAlertingEv 1000 SIP trunk rejects this call as no more bandwidth is available CCD Requesting feature starts PSTN failover by directing this caller to 1000’s PSTN failover number; call is sent out to a PSTN gateway. Reason = REASON_CONFERENCE GC1 CiscoTermConnSelectChangedEv B GC2 CiscoTermConnSelectChangedEv B GC1 CiscoConferenceStartedEv GC2 termConnDroppedEv B GC2 CallCtlTermConnDroppedEv B Gc2 ConnDisconnectedEv B GC2 CallCtlConnDisConnectedEv B GC1 CallCtlTermConnTalkingEv B GC2 CiscoCallChangedEv GC1 ConnCreatedEv 1000 GC1 ConConnectedEv 1000 GC1 CallCtlConnEstablishedEv 1000 GC1 TermConnCreatedEv 1000 GC1 TermConnActiveEv 1000 GC1 CallCtlTermConnTalkingEv 1000 GC2 TermConnDroppedEv 1000 GC2 CallCtlTermConnDroppedEv 1000 GC2 ConnDisconnectedEv 1000 GC2 CallCtlConnDisconnectedEv 1000 GC2 CallInvalidEv GC1 CiscoTermConnSelectChangedEv B GC1 CiscoTermConnSelectChangedEv B B completes the conference Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 792 Message Sequence Charts Message Sequence Charts

Page 856 diagram

Page 857

CallFwdAll Keys Press Notification (Scenario 1): Application Is Observing A; A Goes Off-Hook Call info Result Action CiscoAddrInServiceEv – A Application observes A. TermConnActiveEv-TA. getCall().getCFWDAllKeyPressIndicator() returns CiscoCall.CFWD_ALL_NONE currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - A TermConnCreatedEv - TA TermConnActiveEv –TA CallCtlTermConnTalkingEv –TA A goes off-hook. (Scenario 2): A Goes Off-Hook; Application Starts Observing A Call info Result Action No Event is delivered A goes off-hook TermConnActiveEv-TA. getCall().getCFWDAllKeyPressIndicator() returns CiscoCall.CFWD_ALL_NONE currentCalling = A currentCalled = null CAUSE = CAUSE_SNAPSHOT CiscoAddrInServiceEv – A GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - A TermConnCreatedEv - TA TermConnActiveEv –TA CallCtlTermConnTalkingEv –TA Application starts observing A (Scenario 3): Application Is Observing A; User Presses CFwdAll Soft Key on Phone A in On-Hook State Call info Result Action CiscoAddrInServiceEv – A Application observes A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 793 Message Sequence Charts CallFwdAll Keys Press Notification

Page 857 diagram

Page 858

Call info Result Action TermConnActiveEv-TA. getCall().getCFWDAllKeyPressIndicator() returns CiscoCall.CFWD_ALL_SET currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - A TermConnCreatedEv - TA TermConnActiveEv –TA CallCtlTermConnTalkingEv –TA User presses CFwdAll soft key on phone A (Scenario 4): User Presses CFwdAll Soft Key on Phone A Goes in On-Hook State; Application Starts Observing A Call info Result Action No event is delivered User presses CFwdAll soft key on phone A TermConnActiveEv-TA. getCall().getCFWDAllKeyPressIndicator() returns CiscoCall.CFWD_ALL_SET currentCalling = A currentCalled = null CAUSE = CAUSE_SNAPSHOT GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - A TermConnCreatedEv - TA TermConnActiveEv –TA CallCtlTermConnTalkingEv –TA Application starts observing A (Scenario 5): Application Is Observing A; A Goes Off-Hook and Presses CFwdAll Soft Key Call info Result Action CiscoAddrInServiceEv – A Application observes A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 794 Message Sequence Charts Message Sequence Charts

Page 858 diagram

Page 859

Call info Result Action TermConnActiveEv-TA. getCall().getCFWDAllKeyPressIndicator() returns CiscoCall_CFWD_ALL_NONE currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - A TermConnCreatedEv - TA TermConnActiveEv –TA CallCtlTermConnTalkingEv –TA A goes off-hook. No Event is delivered A presses CFwdAll soft key (Scenario 6): Application Is Observing A; User Presses CFwdAll Key on Phone A and Dial 9999(B) to Set the CFA Destination as B; User Then Presses CFwdAll Soft Key Again to Cancel the CallFwdAll Call info Result Action CiscoAddrInServiceEv – A Application observes A. TermConnActiveEv-TA. getCall().getCFWDAllKeyPressIndicator() returns CiscoCall.CFWD_ALL_SET currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv – A TermConnCreatedEv – TA TermConnActiveEv –TA CallCtlTermConnTalkingEv –TA User presses CFwdAll soft key on phone A currentCalling = A currentCalled = null currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: CallCtlConnDialingEv – A CallCtlConnEstablishedEv – A TermConnDroppedEv – TA CallCtlTermConnDroppedEv – TA ConnDisconnectedEv – A CallCtlConnDisconnectedEv – A CallInvalidEv User dials B to set CFA destination as B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 795 Message Sequence Charts Message Sequence Charts

Page 859 diagram

Page 860

Call info Result Action (GC2)TermConnActiveEv-TA. getCall().getCFWDAllKeyPressIndicator() returns CiscoCall.CFWD_ALL_CLEAR currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC2: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - A TermConnCreatedEv - TA TermConnActiveEv –TA CallCtlTermConnTalkingEv –TA TermConnDroppedEv – TA CallCtlTermConnDroppedEv – TA ConnDisconnectedEv – A CallCtlConnDisconnectedEv – A CallInvalidEv User presses CFwdAll soft key on phone A to cancel CFA Call Recording for SIP or TLS Authenticated calls Scenario One Recording behavior for an authenticated Phone when Service Parameter Authenticated Phone Recording set to Do not Allow Recording. B is an Authenticated Phone having selective recording configured and Recording Profile assigned to it. Caller A calls B. B answers the call. Call information Events Action PlatformException.getErrorCode= CiscoJtapiException.CTIERR_SECURITY_CAPABLITY_MISMATCH Recording fails with PlatformException termConnB.startRecording() Scenario Two Recording behavior for an authenticated Phone when Service Parameter Authenticated Phone Recording set to Allow Recording. B is an Authenticated Phone having selective recording configured and Recording Profile assigned to it. Caller A calls B. B answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 796 Message Sequence Charts Call Recording for SIP or TLS Authenticated calls

Page 860 diagram

Page 861

Call information Events Action Calling: A Called: B Along with the regular events for call answer, the following events will also be delivered to the call observer: CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL CiscoTermConnRecordingTargetInfoEv CiscoTermConnRecordingEndEv Cause: CAUSE_NORMAL CallCtlTermConnDroppedEv TA Cause: CAUSE_NORMAL termConnB.startRecording() B is an Authenticated Phone having auto recording configured and Recording Profile assigned to it. Caller A calls B. B answers the call. Call Information Events Action Calling: A Called: B Along with the regular events for call answer, the following events will also be delivered to the call observer: CiscoTermConnRecordingStartEv Cause: CAUSE_NORMAL CiscoTermConnRecordingTargetInfoEv CiscoTermConnRecordingEndEv Cause: CAUSE_NORMAL CallCtlTermConnDroppedEv TA Cause: CAUSE_NORMAL When B answers CallSelect and UnSelect The following diagram illustrates the message flows for CallSelect and UnSelect. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 797 Message Sequence Charts CallSelect and UnSelect

Page 861 diagram

Page 862

Cius Persistency Use Cases for Cius Persistency Info Events on Provider observer Usecase ((CiscoTerminal)(Provider.getTerminal(TermA))).getIPV4Address() = 1.1.1.1 ProvInServiceEv Application has a wireless device TermA in its control list which is registered with IPv4 address 1.1.1.1 Ev.getIPAddressingMode() = CiscoTerminal.IP_ADDRESSING_MODE_IPV4 Ev.getIPV4Address() = 2.2.2.2 ((CiscoTerminal)(Ev.getTerminal()).getIP4Address() = 2.2.2.2 CiscoProvTerminalIPAddressChangedEv TermA The device moves from one WiFi N/W to another resulting in the change in the IPv4 address from 1.1.1.1 to 2.2.2.2 Ev.getIPAddressingMode() = CiscoTerminal.IP_ADDRESSING_MODE_IPV6 Ev.getIPV6Address() = 1::1 ((CiscoTerminal)(Ev.getTerminal()).getIP6Address() = 1::1 CiscoProvTerminalIPAddressChangedEv TermA The deivce moves from a IPv4 n/w to a Ipv6 n/w With new ip as 1::1 Ev.getIPAddressingMode() = CiscoTerminal.IP_ADDRESSING_MODE_IPV4 Ev.getIPV4Address() = 3.3.3.3 Ev.getTerminal() = TermA ((CiscoTerminal)(Ev.getTerminal()).getIP4Address() = 3.3.3.3 CiscoProvTerminalIPAddressChangedEv TermA The Device is docked on a base station connected to the ethernet resulting in a change in IP address to 3.3.3.3 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 798 Message Sequence Charts Cius Persistency

Image 1 from page 862

Page 862 diagram

Page 863

Conference and Join The following diagrams illustrate the message flows for Conference and Join. Join/Arbitrary Conference Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 799 Message Sequence Charts Conference and Join

Image 1 from page 863

Page 863 content

Page 864

Join/Arbitrary Conference—Page 2 Consult Conference The message flow for Consult Conference acts the same as the flow for Arbitrary Conference. Join Across Lines with Enhancements The message flows for Join Across Lines with Enhancements are described in following tables. A, C, D, E and F are addresses on different terminals. B1 and B2 are addresses on the same terminal, TermB. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 800 Message Sequence Charts Consult Conference

Image 1 from page 864

Page 864 content

Page 865

Events Action Events to CallObserver of A, C and B1: TermConnActiveEv TermB GC1 CallCtlTermConnTalkingEv TermB GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-2 GC1 ConnConnectedEv Conference-2 GC1 CallCtlConnEstablishedEvConference-2 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv GC1 Ev.getAddedConnection will return connection for Conference-2 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2 Ev.getConferenceChain().getChainedConferenceCalls()will return GC1 Application conferences the two calls on B1 and B2 by invoking GC1.conference(GC2) to chain two conference calls. Event for CallObserver at B2, D & E: ConnDisconnectedEv B2 GC2 Cause = NORMAL CallCtlConnDisconnectedEv B2 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE TermConnDroppedEv TermB GC2 Cause = NORMAL CallCtlTermConnDroppedEv TermB GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-1 GC2 ConnConnectedEv Conference-1 GC2 CallCtlConnEstablishedEvConference-1 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC2 Ev.getAddedConnection will return connection of Conference-1 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1 & Conference-2 Ev.getConferenceChain().getChainedConferenceCalls()will return GC1 & GC2 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 801 Message Sequence Charts Message Sequence Charts

Page 865 diagram

Page 866

Events Action Event for CallObserver at B2, D & E: TermConnActiveEv TermB GC2 CallCtlTermConnTalkingEv TermB GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-1 GC2 ConnConnectedEv Conference-1 GC2 CallCtlConnEstablishedEvConference-1 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC2 Ev.getAddedConnection will return connection for Conference-1 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1 Ev.getConferenceChain().getChainedConferenceCalls()will return GC2 Application invokes GC2.conference (GC1) to chain two conference calls. Events for CallObservers at A, B1 & C: ConnDisconnectedEv B1 GC1 Cause = NORMAL CallCtlConnDisconnectedEv B1 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE TermConnDroppedEv TermB GC1 Cause = NORMAL CallCtlTermConnDroppedEv TermB GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-2 GC1 ConnConnectedEv Conference-2 GC1 CallCtlConnEstablishedEvConference-2 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC1 Ev.getAddedConnection will return connection for Conference-2 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2 Ev.getConferenceChain().getChainedConferenceCalls()will return GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 802 Message Sequence Charts Message Sequence Charts

Page 866 diagram

Page 867

Events Action Event for CallObserver at A, B1 & C: TermConnActiveEv TermB GC1 CallCtlTermConnTalkingEv TermB GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-2 GC1 ConnConnectedEv Conference-2 GC1 CallCtlConnEstablishedEvConference-2 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv - GC1 Ev.getAddedConnection will return connection for Conference-2 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2 Ev.getConferenceChain().getChainedConferenceCalls()will return GC1 TermConnDroppedEv TermB GC2 CallCtlTermConnDroppedEv TermB GC2 ConnCreatedEv Conference-3 GC1 ConnConnectedEv Conference-3 GC1 CallCtlConnEstablishedEvConference-3 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv - GC1 Ev.getAddedConnection will return connection for Conference-3 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2 & Conference-3 Ev.getConferenceChain().getChainedConferenceCalls()will return GC2 & GC3 A, B1, C are in conference-1 (GC1), B1, D, E are in conference-2 (GC2), B2, F, G are in conference-3 (GC-3) Application completes conference at C by initiating GC1.conference(GC2, GC3) setting B1 as controller. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 803 Message Sequence Charts Message Sequence Charts

Page 867 diagram

Page 868

Events Action Event for CallObserver at B1, D & E: ConnDisconnectedEv B1 GC2 Cause = NORMAL CallCtlConnDisconnectedEv B1 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE TermConnDroppedEv TermB GC2 Cause = NORMAL CallCtlTermConnDroppedEv TermB GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-1 GC2 ConnConnectedEv Conference-1 GC2 CallCtlConnEstablishedEvConference-1 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC2 Ev.getAddedConnection will return connection for Conference-1 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1-GC2 Ev.getConferenceChain().getChainedConferenceCalls()will return GC2 Event for CallObserver at B2, F & G: ConnDisconnectedEv B2 GC3 Cause = NORMAL CallCtlConnDisconnectedEv B2 GC3 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE TermConnDroppedEv TermB GC3 Cause = NORMAL CallCtlTermConnDroppedEv TermB GC3 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-1 GC3 ConnConnectedEv Conference-1 GC3 CallCtlConnEstablishedEvConference-1 GC3 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv - GC3 Ev.getAddedConnection will return connection for Conference-1 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1 Ev.getConferenceChain().getChainedConferenceCalls()will return GC3 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 804 Message Sequence Charts Message Sequence Charts

Page 868 diagram

Page 869

Events Action A CiscoConferenceStartEv CallCtlTermConnTalkingEv TermB GC1 ConnCreatedEv D GC1 ConnConnectedEv D GC1 CallCtlTermConnDroppedEv TermB GC2 CiscoConferenceEndEv B1 CallCtlTermConnHeldEv TermB GC1 CiscoConferenceStartEv CallCtlTermConnTalkingEv TermB GC1 ConnCreatedEv D ConnConnectedEv CiscoConferenceEndEv B2 ConnDisconnectedEv B GC2 CallCtlTermConnHeldEv TermB GC2 D CallActiveEv GC2 ConnAlertingEv D GC2 ConnConnectedEv D GC2 CiscoConferenceStartEv TermConnDroppedEv TermB GC2 CallActiveEv GC1 CiscoCallChangedEv TermConnTalkingEv TermB GC1 TermConnDroppedEv TermD GC2 CallObservationEndedEv GC2 CiscoConferenceEndEv Application sets the requestor as B2 and calls GC2.conference(GC1) getControllerAddress() returns B2. getOriginalControllerAddress() returns B1. Events are same as above If application uses B1 as request controller in the above setup getControllerAddress() returns B1. getOriginalControllerAddress() returns B1. CTI Manager Redundancy Handling with Least Priority CTIManager Configured Identify a CTIManager as least priority: Application can mark one of the CTIManagers in the initial CTIManager redundancy group or configure a new one (not part of the initial group) by invoking setLeastPriorityCtiServer(). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 805 Message Sequence Charts CTI Manager Redundancy Handling with Least Priority CTIManager Configured

Page 869 diagram

Page 870

CTI Manager Redundancy Handling with Least Priority CTI Server Set Scenario 1: Set least priority without specifying fallback Initiation time 1. Start application and set a CTIManager as least priority. Assume CTIManager redunancy list is CT1,CTI2,CTI3. 2. Application loses connectivity to CTI1. 3. Application loses connectivity to CTI3. 4. CTI1 is reachable now. 5. Fallback is started 5 min from now if a CTI server is reachable post it. 6. Post 5 min, CTI1 is still reachable. Events Action Application invokes CiscoProvider.setLeastPriorityCtiServer(CTI2). Application connects to CTI3. CiscoProvConnToLeastPriorCtiServerEv Application connects to CTI2. CiscoProvPrimNwReachableEv JTAPI is able to identify CTI1 reachability. Once connected to CTI1, JTAPI delivers CiscoProvFallbackToPrimNwCompltdEv event JTAPI initiates application fallback to CTI1 Scenario 2: Application initiates a forced fallback 1. Start application and set a CTIManager as least priority. Assume CTIManager redunancy list is CT1,CTI2,CTI3. 2. Application loses connectivity to CTI1. 3. Application loses connectivity to CTI3. 4. CTI1 is reachable now. 5. Application monitors if CTI2 is reachable now. Result Events Action Application invokes CiscoProvider.setLeastPriorityCtiServer(CTI2,600) where 600 is the fallback initiation time. Application connects to CTI3. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 806 Message Sequence Charts CTI Manager Redundancy Handling with Least Priority CTI Server Set

Page 870 diagram

Page 871

Result Events Action CiscoProvConnToLeastPriorCtiServerEv Application connects to CTI2. CiscoProvPrimNwReachableEv delivered Application queries CiscoProvPrimNwReachableEv. getReachableCtiServers() returns CTI1 JTAPI is able to identify CTI1 reachability. JTAPI return true if CTI2 was reachable now. Application invokes CiscoProvider.isCtiServerAvailable(CTI2) JTAPI initiates fallback to CTI2 if reachable. CiscoProvFallbackTo PrimNwCompltdEv event is returned if fallback was successful. Application invokes CiscoProvider.initiateFallback(CTI2) CTI Remote Device Use Cases • Group 1: Get/Add/Remove/Update on Remote Destinations • Group 2: CTIRD Incoming/Outgoing/Disconnect/Redirect/Hold/Resume and shared-line call scenarios) • Group 3 (CUCSF registration and unregistration, for Normal SIP mode <-> Extend mode, and terminal switching scenarios • Group 4: Set/Reset Active Remote Destination scenarios • Group 5: CTIRD Transfer/Conference/Multiple-Calls call scenarios • Group 6: CTIRD URI-Dialing basic Incoming & Outgoing DVO call scenarios CTI Remote Device Use Cases Group 1 Scenario 1-1 (Expose All RDs Information on a CTI Remote Device to Application) User1 has "CTI Remote Device A" in the control list. User invokes CiscoRemoteTerminal.getAllRemoteDestinations() on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 807 Message Sequence Charts CTI Remote Device

Page 871 diagram

Page 872

Call info Events Action TermA.getAllRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true CiscoRemoteDestinationInfo[1].getRemoteDestinationName() = "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false User1 invokes CiscoRemoteTerminal. getAllRemoteDestinations() on TermA. Use Cases Group 1: Get/Add/Remove/Update on Remote Destinations Pre-conditions on Use Cases group 1 below with default jtapi.ini settings, unless specified explicitly: • Provider is IN_SERVICE state. • Device A (CTI Remote Device - Name: "CTIRD-A", Line A (DN: 1000)) • Remote Destination 1 (Name: "RD1-A", Number: "4081001111", Active RD: true) • Remote Destination 2 (Name: "RD2-A", Number: "4081002222", Active RD: false) • Device B (IP Phone - Name: "SEP000DED47D023", Line B (DN: 2000) • Device C (CTI Remote Device - Name: "CTIRD-C", Line C (DN: 3000)) • No Remote Destination configured. Scenario 1-2 (Expose Active RDs Information on a CTI Remote Device to Application) User1 has "CTI Remote Device A" in the control list. User invokes CiscoRemoteTerminal.getActiveRemoteDestinations() on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. TermA.getActiveRemoteDestinations() = CiscoRemoteDestinationInfo[1]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true User1 invokes CiscoRemoteTerminal. getActiveRemoteDestinations() on TermA. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 808 Message Sequence Charts Message Sequence Charts

Page 872 diagram

Page 873

Scenario 1-3 (Fetch RD Information on a CTI Remote Device That Has No RD Configured) User1 has "CTI Remote Device C" in the control list. User invokes CiscoRemoteTerminal.getAllRemoteDestinations() on terminal C. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. TermC.getAllRemoteDestinations() = null. User1 invokes CiscoRemoteTerminal. getAllRemoteDestinations() on TermC. Scenario 1-4 (Fetch RD Information on a 'Non-CTI Remote Device') User1 has "Device B" IP Phone in the control list. User invokes CiscoRemoteTerminal.getAllRemoteDestinations() on terminal B. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. TermB.getAllRemoteDestinations() = null. User1 invokes CiscoRemoteTerminal. getAllRemoteDestinations() on TermB. Scenario 1-5 (Fetch Active RD Information on a CTI Remote Device That Has No Active RD Configured) User1 has "CTI Remote Device C" in the control list. User invokes CiscoRemoteTerminal.getActiveRemoteDestinations() on terminal C. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. TermC.getActiveRemoteDestinations() = null. User1 invokes CiscoRemoteTerminal. getAllRemoteDestinations() on TermC. Scenario 1-6 (Set a Non-Active RD as a New Active RD on a 'CTI Remote Device', Where There Is Already an Existing Active RD for This Device) User1 has "CTI Remote Device A" in the control list. User invokes CiscoRemoteTerminal.setActiveRemoteDestination("4081002222", true) on terminal A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 809 Message Sequence Charts Message Sequence Charts

Page 873 diagram

Page 874

Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoProvTerminalRemoteDestinationChangedEv. getRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName() = "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoProvTerminal RemoteDestination ChangedEv User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("4081002222", true) on TermA. CiscoProvTerminalRemoteDestinationChangedEv. getRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName() = "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = true CiscoProvTerminal RemoteDestinationChangedEv Scenario 1-7 (Add a New Non-Active RD on a 'CTI Remote Device') User1 has "CTI Remote Device A" in the control list. User invokes addRemoteDestination("RD3-A", "4081003333", false) on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 810 Message Sequence Charts Message Sequence Charts

Page 874 diagram

Page 875

Call info Events Action CiscoProvTerminalRemoteDestinationChangedEv. getRemoteDestinations() = CiscoRemoteDestinationInfo[3]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true CiscoRemoteDestinationInfo[1].getRemoteDestinationName() = "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoRemoteDestinationInfo[2].getRemoteDestinationName() = "RD3-A" CiscoRemoteDestinationInfo[2].getRemoteDestinationNumber() = "4081003333" CiscoRemoteDestinationInfo[2].getIsActiveRD() = false CiscoProvTerminal RemoteDestination ChangedEv User1 invokes CiscoRemoteTerminal. addRemoteDestination ("RD3-A", "4081003333", false) on TermA. Scenario 1-8 (Add a New Active RD on a 'CTI Remote Device', with Another Existing Active RD) User1 has "CTI Remote Device A" in the control list. User invokes addRemoteDestination("RD3-A", "4081003333", true) on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoProvTerminalRemoteDestinationChangedEv. getRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName() = "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoProvTermina lRemoteDestination ChangedEv User1 invokes CiscoRemoteTerminal. addRemoteDestination ("RD3-A", "4081003333", true) on TermA. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 811 Message Sequence Charts Message Sequence Charts

Page 875 diagram

Page 876

Page 876 diagram

Page 877

Call info Events Action Let 'ex' be an instanceof PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_DUPLICATED_REMOTE_DESTINATION_NUMBER. TermA.getAllRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true CiscoRemoteDestinationInfo[1].getRemoteDestinationName() = "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false Caught exception: com.cisco.jtapi. PlatformException Impl: Duplicated Remote Destination Number User1 invokes CiscoRemoteTerminal. addRemoteDestination ("AnyName", "4081002222", false) on TermA. Scenario 1-10 (Remove a RD From a 'CTI Remote Device') User1 has "CTI Remote Device A" in the control list. User invokes removeRemoteDestination("4081002222") on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[1]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. removeRemoteDestination ("4081002222") on TermA. Scenario 1-11 (Remove All RD(s) From a 'CTI Remote Device') User1 has "CTI Remote Device A" in the control list. User invokes removeAllRemoteDestinations() on terminal A. JTAPI will loop through the terminal/device's existing remote destinations one by one, so the total number of CiscoProvTerminalRemoteDestinationChangedEv sent to an application should be the same number of available remote destinations being removed. And the order and content of each event can vary, depending on how each remote destination is stored in JTAPI's local cache RD list. Note Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 813 Message Sequence Charts Message Sequence Charts

Image 1 from page 877

Page 877 diagram

Page 878

Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[1]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD2-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. removeAllRemote Destinations() on TermA. CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = null. CiscoProvTerminalRemote DestinationChangedEv Scenario 1-12 (Update a RD Name on a 'CTI Remote Device') User1 has "CTI Remote Device A" in the control list. User invokes updateRemoteDestinationName ("4081001111", "MyHome") on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "MyHome" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. updateRemoteDestination Name ("4081001111", "MyHome") on TermA. Scenario 1-13 (Update a RD Number on a 'CTI Remote Device') User1 has "CTI Remote Device A" in the control list. User invokes updateRemoteDestinationNumber ("4081001111", "6268210080") on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 814 Message Sequence Charts Message Sequence Charts

Page 878 diagram

Page 879

Call info Events Action CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "6268210080" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. updateRemoteDestination Name ("4081001111", "6268210080") on TermA. Scenario 1-14 (Add a New RD with an Invalid RD Number on a 'CTI Remote Device') User1 has "CTI Remote Device A" in the control list. User invokes addRemoteDestination ("iPhone5", "IAmNotANumber", true) on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Let 'ex' be an instanceof PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_INVALID_REMOTE_DESTINATION_NUMBER. TermA.getAllRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false Caught exception: com.cisco.jtapi. PlatformExceptionImpl: Invalid Remote Destination Number User1 invokes CiscoRemoteTerminal. addRemoteDestination ("iPhone5", "IAmNotANumber", true) on TermA. Scenario 1-15 (Update RD Name with an Invalid/Not-Associated RD Number on a 'CTI Remote Device') User1 has "CTI Remote Device A" in the control list. User invokes updateRemoteDestinationName ("4085268222", "MyBossOffice") on terminal A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 815 Message Sequence Charts Message Sequence Charts

Page 879 diagram

Page 880

Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Let 'ex' be an instanceof PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_INVALID_REMOTE_DESTINATION_NUMBER. TermA.getAllRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false Caught exception: com.cisco.jtapi. PlatformExceptionImpl: Invalid Remote Destination Number User1 invokes CiscoRemoteTerminal. updateRemoteDestination Name ("4085268222", "MyBossOffice") on TermA. Scenario 1-16 (Update RD Name with a Null RD Number on a 'CTI Remote Device') User1 has "CTI Remote Device A" in the control list. User invokes updateRemoteDestinationName (null, "MyBossOffice") on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. TermA.getAllRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = true CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false Caught exception: com.cisco.jtapi. InvalidArgument ExceptionImpl: Invalid Remote Destination Number/Name (updateRemoteDestination Name parameter). User1 invokes CiscoRemoteTerminal. updateRemoteDestination Name (null, "MyBossOffice") on TermA. Scenario 1-17 (Clear an Existing Active RD as a Non-Active RD on a 'CTI Remote Device') Explicit Pre-condition: (RD1-A: "4081001111", True; RD2-A: "4081002222", False; RD3-A: "4081003333", False) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 816 Message Sequence Charts Message Sequence Charts

Page 880 diagram

Page 881

User1 has "CTI Remote Device A" in the control list. User invokes CiscoRemoteTerminal.setActiveRemoteDestination("4081001111", false) on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[3]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD1-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoRemoteDestinationInfo[2].getRemoteDestinationName()= "RD3-A" CiscoRemoteDestinationInfo[2].getRemoteDestinationNumber() = "4081003333" CiscoRemoteDestinationInfo[2].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("4081001111", false) on TermA. Scenario 1-18 (Remove All RD(s) From a 'CTI Remote Device') User1 Has "CTI Remote Device C" in the Control List. User Invokes removeAllRemoteDestinations() on Terminal C. Call info5 Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Note Nothing is removed as there is no RD on this device. JTAPI won't be sending any request to CTI. No CiscoJtapiException will be thrown either. User1 invokes CiscoRemoteTerminal. removeAllRemoteDestinations() on TermC. Scenario 1-19 (Remove All 5 RD(s) From a 'CTI Remote Device') Explicit Pre-condition: RD1-A: "4081001111", true; RD2-A: "4081002222", false; RD3-A: "4081003333", false; RD4-A: "4081004444", false; RD5-A: "4081005555", false. User1 has "CTI Remote Device A" in the control list. User invokes removeAllRemoteDestinations() on terminal A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 817 Message Sequence Charts Message Sequence Charts

Page 881 diagram

Page 882

Note that JTAPI will loop through the terminal/device's existing remote destinations one by one, so the total number of CiscoProvTerminalRemoteDestinationChangedEv sent to an application should be the same number of available remote destinations being removed. And the order and content of each event can vary, depending on how each remote destination is stored in JTAPI's local cache RD list. Also note currently there is no checking in JTAPI to limit only up to 5 RDs per CTI Remote Device. If application tries to add a new RD to an existing CTI Remote Device that already has 5 RDs, JTAPI will simply send the add request to CTI and let it decide on pass/fail. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[4]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD2-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD3-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081003333" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoRemoteDestinationInfo[2].getRemoteDestinationName()= "RD4-A" CiscoRemoteDestinationInfo[2].getRemoteDestinationNumber() = "4081004444" CiscoRemoteDestinationInfo[2].getIsActiveRD() = false CiscoRemoteDestinationInfo[3].getRemoteDestinationName()= "RD5-A" CiscoRemoteDestinationInfo[3].getRemoteDestinationNumber() = "4081005555" CiscoRemoteDestinationInfo[3].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. removeAllRemote Destinations() on TermA. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 818 Message Sequence Charts Message Sequence Charts

Page 882 diagram

Page 883

Call info Events Action CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[3]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD3-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081003333" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD4-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081004444" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoRemoteDestinationInfo[2].getRemoteDestinationName()= "RD5-A" CiscoRemoteDestinationInfo[2].getRemoteDestinationNumber() = "4081005555" CiscoRemoteDestinationInfo[2].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD4-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081004444" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD5-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081005555" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[1]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName()= "RD5-A" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081005555" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = null. CiscoProvTerminalRemote DestinationChangedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 819 Message Sequence Charts Message Sequence Charts

Page 883 diagram

Page 884

Scenario 1-20 (Update a RD's Name and Number and Set It as ActiveRD on a 'CTI Remote Device' at the Same Time) User1 has "CTI Remote Device A" in the control list. User invokes updateRemoteDestination ("4081002222", "MyVacationHome", "4081009999", true) on terminal A. Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "MyHome" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName()= "RD2-A" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. updateRemoteDestination ("4081002222", "MyVacationHome", "4081009999", true) on TermA. CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "MyHome" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName() = "MyVacationHome" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081002222" CiscoRemoteDestinationInfo[1].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 820 Message Sequence Charts Message Sequence Charts

Page 884 diagram

Page 885

Call info Events Action CiscoProvTerminalRemoteDestinationChangedEv.getRemoteDestinations() = CiscoRemoteDestinationInfo[2]. CiscoRemoteDestinationInfo[0].getRemoteDestinationName() = "MyHome" CiscoRemoteDestinationInfo[0].getRemoteDestinationNumber() = "4081001111" CiscoRemoteDestinationInfo[0].getIsActiveRD() = false CiscoRemoteDestinationInfo[1].getRemoteDestinationName() = "MyVacationHome" CiscoRemoteDestinationInfo[1].getRemoteDestinationNumber() = "4081009999" CiscoRemoteDestinationInfo[1].getIsActiveRD() = true CiscoProvTerminalRemote DestinationChangedEv CTI Remote Device Use Cases Group 2 Use Cases Group 2: CTIRD Incoming/Outgoing/Disconnect/Redirect/Hold/Resume and Shared-Line Call Scenarios Pre-conditions on Use Cases group 2 below with default jtapi.ini settings, unless specified explicitly. Note that the CTI Ports have Auto-Accept enabled: • Provider is IN_SERVICE state. • Device A (CTI Remote Device - Name: "irvCTIRD1", Line A (DN: 8881000)) • Remote Destination 1 (Name: "IRVOffice", Number: "919498231202", Active RD: true) • Device B (CTI Port - Name: "irvCTIPort1", Line B (DN: 8881000)) • Device C (CTI Port - Name: "irvCTIPort6", Line C (DN: 8886000)) • Device D (CTI Port - Name: "irvCTIPort7", Line C (DN: 8887000)) • Device E (CTI Remote Device - Name: "irvCTIRD2", Line E (DN: 8889000)) • Remote Destination 1 (Name: "IRVCell1", Number: "916267829523", Active RD: true) • Device F (CTI Remote Device - Name: "irvCTIRD3", Line E (DN: 8889001)) • Remote Destination 1 (Name: "IRVCell2", Number: "916267829526", Active RD: true) Scenario 2-1 (Incoming Call From CTI Port to CTI Remote Device) C calls E, Application is observing both C and E on addresses and terminals. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 821 Message Sequence Charts CTI Remote Device Use Cases Group 2

Page 885 diagram

Page 886

Call info Events Action CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8886000 GC1: ConnConnectedEvent 8886000 GC1: CallCtlConnInitiatedEv 8886000 GC1: TermConnCreatedEvent irvCTIPort6 GC1: TermConnActiveEvent irvCTIPort6 GC1: CallCtlTermConnTalkingEv irvCTIPort6 GC1: CallCtlConnDialingEv 8886000 GC1: CallCtlConnEstablishedEv 8886000 GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 GC1: ConnAlertingEvent 8889000 GC1: CallCtlConnAlertingEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnRingingEvent irvCTIRD2 GC1: CallCtlTermConnRingingEv irvCTIRD2 User1 invokes call.connect(irvCTIPort6, 8886000, 8889000). CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. Scenario 2-2 (Incoming Call From CTI Port to Non-Observed CTI Remote Device) C calls E, Application is observing C only on address and terminal. No observer on E. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 822 Message Sequence Charts Message Sequence Charts

Page 886 diagram

Page 887

Page 887 diagram

Page 888

Call info Events Action CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8886000 GC1: ConnConnectedEvent 8886000 GC1: CallCtlConnInitiatedEv 8886000 GC1: TermConnCreatedEvent irvCTIPort6 GC1: TermConnActiveEvent irvCTIPort6 GC1: CallCtlTermConnTalkingEv irvCTIPort6 GC1: CallCtlConnDialingEv 8886000 GC1: CallCtlConnEstablishedEv 8886000 GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 GC1: ConnAlertingEvent 8889000 GC1: CallCtlConnAlertingEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnRingingEvent irvCTIRD2 GC1: CallCtlTermConnRingingEv irvCTIRD2 User1 invokes call.connect(irvCTIPort6, 8886000, 8889000). CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: TermConnDroppedEv irvCTIPort6 GC1: CallCtlTermConnDroppedEv irvCTIPort6 GC1: ConnDisconnectedEvent 8886000 GC1: CallCtlConnDisconnectedEv 8886000 GC1: CallInvalidEv 8889000 GC1: CallObservationEndedEv irvCTIRD2's Active remote destination of 916267829523 does not answers the call and time out. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 824 Message Sequence Charts Message Sequence Charts

Page 888 diagram

Page 889

Scenario 2-4 (Incoming Call From CTI Port to CTI Remote Device, and Redirect to Another CTI Port) C calls E, and E redirects the call to D, Application is observing all C, D, E on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8886000 GC1: ConnConnectedEvent 8886000 GC1: CallCtlConnInitiatedEv 8886000 GC1: TermConnCreatedEvent irvCTIPort6 GC1: TermConnActiveEvent irvCTIPort6 GC1: CallCtlTermConnTalkingEv irvCTIPort6 GC1: CallCtlConnDialingEv 8886000 GC1: CallCtlConnEstablishedEv 8886000 GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 GC1: ConnAlertingEvent 8889000 GC1: CallCtlConnAlertingEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnRingingEvent irvCTIRD2 GC1: CallCtlTermConnRingingEv irvCTIRD2 User1 invokes call.connect(irvCTIPort6, 8886000, 8889000). CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 825 Message Sequence Charts Message Sequence Charts

Page 889 diagram

Page 890

Call info Events Action CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8886000 :: LastRedirectedPartyAddress: 8889000 GC1: ConnCreatedEvent 8887000 GC1: ConnInprogressEvent 8887000 GC1: CallCtlConnOfferedEv 8887000 GC1: ConnAlertingEvent 8887000 GC1: CallCtlConnAlertingEv 8887000 GC1: TermConnCreatedEvent irvCTIPort7 GC1: TermConnRingingEvent irvCTIPort7 GC1: CallCtlTermConnRingingEv irvCTIPort7 GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 User1 invokes connection on irvCTIRD2.redirect (8887000, REDIRECT_NORMAL, DEFAULT_SEARCH_SPACE, CALLED_ADDRESS_UNCHANGED, REDIRECT, 8887000, null, REDIRECT_WITHOUT_ MODIFIED_CALLING_PARTY, 1) CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8886000 :: LastRedirectedPartyAddress: 8889000 GC1: ConnConnectedEvent 8887000 GC1: CallCtlConnEstablishedEv 8887000 GC1: TermConnActiveEvent irvCTIPort7 GC1: CallCtlTermConnTalkingEv irvCTIPort7 irvCTIPort7 answers the call. Scenario 2-5 (Incoming Call From CTI Port to CTI Remote Device, and Redirect to Another CTI Remote Device) C calls E, and E redirects the call to F, and C redirect the call to E. Application is observing all C, E, F on addresses and terminals. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 826 Message Sequence Charts Message Sequence Charts

Page 890 diagram

Page 891

Page 891 diagram

Page 892

Call info Events Action CurrentCalledAddress: 8889001 :: CurrentCallingAddress: 8886000 :: LastRedirectedPartyAddress: 8889000 GC1: ConnCreatedEvent 8889001 GC1: ConnInprogressEvent 8889001 GC1: CallCtlConnOfferedEv 8889001 GC1: ConnAlertingEvent 8889001 GC1: CallCtlConnAlertingEv 8889001 GC1: TermConnCreatedEvent irvCTIRD3 GC1: TermConnRingingEvent irvCTIRD3 GC1: CallCtlTermConnRingingEv irvCTIRD3 GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 User1 invokes connection on irvCTIRD2.redirect(8889001, REDIRECT_NORMAL, DEFAULT_SEARCH_SPACE, CALLED_ADDRESS_UNCHANGED, REDIRECT, 8889001, null, REDIRECT_WITHOUT_MODIFIED_ CALLING_PARTY, 1) CurrentCalledAddress: 8889001 :: CurrentCallingAddress: 8886000 :: LastRedirectedPartyAddress: 8889000 GC1: ConnConnectedEvent 8889001 GC1: CallCtlConnEstablishedEv 8889001 GC1: TermConnActiveEvent irvCTIRD3 GC1: CallCtlTermConnTalkingEv irvCTIRD3 irvCTIRD3's Active remote destination of 916267829526 answers the call. CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8889001 :: LastRedirectedPartyAddress: 8886000 GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 GC1: ConnAlertingEvent 8889000 GC1: CallCtlConnAlertingEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnRingingEvent irvCTIRD2 GC1: CallCtlTermConnRingingEv irvCTIRD2 GC1: TermConnDroppedEv irvCTIPort6 GC1: CallCtlTermConnDroppedEv irvCTIPort6 GC1: ConnDisconnectedEvent 8886000 GC1: CallCtlConnDisconnectedEv 8886000 User1 invokes connection on irvCTIPort6.redirect(8889000, REDIRECT_NORMAL, DEFAULT_SEARCH_SPACE, CALLED_ADDRESS_UNCHANGED, REDIRECT, 8889000, null, REDIRECT_WITHOUT_MODIFIED_ CALLING_PARTY, 1) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 828 Message Sequence Charts Message Sequence Charts

Page 892 diagram

Page 893

Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8889001 :: LastRedirectedPartyAddress: 8886000 GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 GC1: TermConnDroppedEv irvCTIRD3 GC1: CallCtlTermConnDroppedEv irvCTIRD3 GC1: ConnDisconnectedEvent 8889001 GC1: CallCtlConnDisconnectedEv 8889001 GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: CallInvalidEvent GC1: CallObservationEndedEv irvCTIRD2's Active remote destination of 916267829523 answers the call. Scenario 2-6 (Incoming Call From CTI Port to CTI Remote Device with a Shared-Line of Another CTI Port) C calls A (with a shared line with B), Application is observing A, B, and C on addresses and terminals. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 829 Message Sequence Charts Message Sequence Charts

Page 893 diagram

Page 894

Call info Events Action CallingAddress = 8886000, CalledAddress = 8881000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8881000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8881000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8886000 GC1: ConnConnectedEvent 8886000 GC1: CallCtlConnInitiatedEv 8886000 GC1: TermConnCreatedEvent irvCTIPort6 GC1: TermConnActiveEvent irvCTIPort6 GC1: CallCtlTermConnTalkingEv irvCTIPort6 GC1: CallCtlConnDialingEv 8886000 GC1: CallCtlConnEstablishedEv 8886000 GC1: ConnCreatedEvent 8881000 GC1: ConnInprogressEvent 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnAlertingEvent 8881000 GC1: CallCtlConnAlertingEv 8881000 GC1: TermConnCreatedEvent irvCTIPort1 GC1: TermConnRingingEvent irvCTIPort1 GC1: CallCtlTermConnRingingEv irvCTIPort1 GC1: TermConnCreatedEvent irvCTIRD1 GC1: TermConnRingingEvent irvCTIRD1 GC1: CallCtlTermConnRingingEv irvCTIRD1 User1 invokes call.connect(irvCTIPort6, 8886000, 8881000). CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnActiveEvent irvCTIRD1 GC1: CallCtlTermConnTalkingEv irvCTIRD1 GC1: TermConnPassiveEvent irvCTIPort1 GC1: CallCtlTermConnBridgedEv irvCTIPort1 irvCTIRD1's Active remote destination of 919498231202 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 830 Message Sequence Charts Message Sequence Charts

Page 894 diagram

Page 895

Page 895 diagram

Page 896

Call info Events Action CallingAddress = 8886000, CalledAddress = 8881000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8881000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8881000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8886000 GC1: ConnConnectedEvent 8886000 GC1: CallCtlConnInitiatedEv 8886000 GC1: TermConnCreatedEvent irvCTIPort6 GC1: TermConnActiveEvent irvCTIPort6 GC1: CallCtlTermConnTalkingEv irvCTIPort6 GC1: CallCtlConnDialingEv 8886000 GC1: CallCtlConnEstablishedEv 8886000 GC1: ConnCreatedEvent 8881000 GC1: ConnInprogressEvent 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnAlertingEvent 8881000 GC1: CallCtlConnAlertingEv 8881000 GC1: TermConnCreatedEvent irvCTIPort1 GC1: TermConnRingingEvent irvCTIPort1 GC1: CallCtlTermConnRingingEv irvCTIPort1 GC1: TermConnCreatedEvent irvCTIRD1 GC1: TermConnRingingEvent irvCTIRD1 GC1: CallCtlTermConnRingingEv irvCTIRD1 User1 invokes call.connect(irvCTIPort6, 8886000, 8881000). CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIRD1 GC1: CallCtlTermConnDroppedEv irvCTIRD1 GC1: ConnConnectedEvent 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnActiveEvent irvCTIPort1 GC1: CallCtlTermConnTalkingEv irvCTIPort1 irvCTIPort1 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 832 Message Sequence Charts Message Sequence Charts

Page 896 diagram

Page 897

Call info Events Action CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIPort6 GC1: CallCtlTermConnDroppedEv irvCTIPort6 GC1: ConnDisconnectedEvent 8886000 GC1: CallCtlConnDisconnectedEv8886000 GC1: TermConnDroppedEv irvCTIPort1 GC1: CallCtlTermConnDroppedEv irvCTIPort1 GC1: ConnDisconnectedEvent 8881000 GC1: CallCtlConnDisconnectedEv 8881000 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect the call from irvCTIPort6. Scenario 2-8 (Outgoing Call From CTI Remote Device to CTI Port) E calls D, Application is observing both D and E on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 User1 invokes call.connect(irvCTIRD2, 8889000, 8887000). CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 833 Message Sequence Charts Message Sequence Charts

Page 897 diagram

Page 898

Call info Events Action CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = 8889000, CurrentCalledAddress = 8887000, ModifiedCallingAddress = 8889000, ModifiedCalledAddress = 8887000, No LastRedirectedPartyAddress GC1: ConnCreatedEvent 8887000 GC1: ConnInprogressEvent 8887000 GC1: CallCtlConnOfferedEv 8887000 GC1: ConnAlertingEvent 8887000 GC1: CallCtlConnAlertingEv 8887000 GC1: TermConnCreatedEvent irvCTIPort7 GC1: TermConnRingingEvent irvCTIPort7 GC1: CallCtlTermConnRingingEv irvCTIPort7 GC1: ConnConnectedEvent 8887000 GC1: CallCtlConnEstablishedEv 8887000 GC1: TermConnActiveEvent irvCTIPort7 GC1: CallCtlTermConnTalkingEv irvCTIPort7 irvCTIPort7 rings and answers the call. CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8889000 :: No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: TermConnDroppedEv irvCTIPort7 GC1: CallCtlTermConnDroppedEv irvCTIPort7 GC1: ConnDisconnectedEvent 8887000 GC1: CallCtlConnDisconnectedEv 8887000 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect the call from 8889000 connection. Scenario 2-9 (Outgoing Call From CTI Remote Device (with a Shared Line of CTI Port) to Another CTI Port) A (with a shared line of B) calls D, Application is observing both A, B, and D on addresses and terminals. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 834 Message Sequence Charts Message Sequence Charts

Page 898 diagram

Page 899

Call info Events Action CallingAddress = Unknown, CalledAddress = 8881000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8881000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8881000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8881000 GC1: ConnInprogressEvent 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnAlertingEvent 8881000 GC1: CallCtlConnAlertingEv 8881000 User1 invokes call.connect(irvCTIRD1, 8881000, 8887000). GC1: TermConnCreatedEvent irvCTIPort1 GC1: TermConnRingingEvent irvCTIPort1 GC1: CallCtlTermConnRingingEv irvCTIPort1 irvCTIPort7 rings CallingAddress = Unknown, CalledAddress = 8881000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8881000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8881000, No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnCreatedEvent irvCTIRD1 GC1: TermConnActiveEvent irvCTIRD1 GC1: CallCtlTermConnTalkingEv irvCTIRD1 irvCTIRD1's Active remote destination of 919498231202 answers the call. CallingAddress = Unknown, CalledAddress = 8887000, CurrentCallingAddress = 8881000, CurrentCalledAddress = 8887000, ModifiedCallingAddress = 8881000, ModifiedCalledAddress = 8887000, No LastRedirectedPartyAddress GC1: TermConnPassiveEvent irvCTIPort1 GC1: CallCtlTermConnBridgedEv irvCTIPort1 irvCTIPort7 rings Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 835 Message Sequence Charts Message Sequence Charts

Page 899 diagram

Page 900

Call info Events Action CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8881000:: No LastRedirectedPartyAddress GC1: ConnCreatedEvent 8887000 GC1: ConnInprogressEvent 8887000 GC1: CallCtlConnOfferedEv 8887000 GC1: ConnAlertingEvent 8887000 GC1: CallCtlConnAlertingEv 8887000 GC1: TermConnCreatedEvent irvCTIPort7 GC1: TermConnRingingEvent irvCTIPort7 GC1: CallCtlTermConnRingingEv irvCTIPort7 GC1: ConnConnectedEvent 8887000 GC1: CallCtlConnEstablishedEv 8887000 GC1: TermConnActiveEvent irvCTIPort7 GC1: CallCtlTermConnTalkingEv irvCTIPort7 irvCTIPort7 answers the call. CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8881000:: No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIRD1 GC1: CallCtlTermConnDroppedEv irvCTIRD1 GC1: TermConnDroppedEv irvCTIPort1 GC1: CallCtlTermConnDroppedEv irvCTIPort1 GC1: ConnDisconnectedEvent 8881000 GC1: CallCtlConnDisconnectedEv 8881000 GC1: TermConnDroppedEv irvCTIPort7 GC1: CallCtlTermConnDroppedEv irvCTIPort7 GC1: ConnDisconnectedEvent 8887000 GC1: CallCtlConnDisconnectedEv 8887000 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect the call from 8881000 connection. Scenario 2-10 (Outgoing Call From CTI Remote Device to CTI Port, but No Answer on Active Remote Destination) E calls D, Application is observing both E and D on addresses and terminals. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 836 Message Sequence Charts Message Sequence Charts

Page 900 diagram

Page 901

Call info Events Action CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 User1 invokes call.connect(irvCTIRD2, 8889000, 8887000). CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: CallInvalidEvent GC1: CallObservationEndedEv irvCTIRD2's Active remote destination of 916267829523 does not answer the call and time out. Scenario 2-11 (Outgoing Call From CTI Remote Device to CTI Port, but No Answer on CTI Port) E calls D, Application is observing both D and E on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 User1 invokes call.connect(irvCTIRD2, 8889000, 8887000). CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 837 Message Sequence Charts Message Sequence Charts

Page 901 diagram

Page 902

Call info Events Action CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = 8889000, CurrentCalledAddress = 8887000, ModifiedCallingAddress = 8889000, ModifiedCalledAddress = 8887000, No LastRedirectedPartyAddress GC1: ConnCreatedEvent 8887000 GC1: ConnInprogressEvent 8887000 GC1: CallCtlConnOfferedEv 8887000 GC1: ConnAlertingEvent 8887000 GC1: CallCtlConnAlertingEv 8887000 GC1: TermConnCreatedEvent irvCTIPort7 GC1: TermConnRingingEvent irvCTIPort7 GC1: CallCtlTermConnRingingEv irvCTIPort7 irvCTIPort7 rings. CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8889000 :: No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIPort7 GC1: CallCtlTermConnDroppedEv irvCTIPort7 GC1: ConnDisconnectedEvent 8887000 GC1: CallCtlConnDisconnectedEv 8887000 GC1: ConnFailedEvent 8889000 GC1: CallCtlConnFailedEv 8889000 GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: CallInvalidEvent GC1: CallObservationEndedEv irvCTIPort7 does not answer the call, time out. Scenario 2-12 (Outgoing Call From Non-Observed CTI Remote Device to CTI Port) E calls D, Application is observing only on D on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CurrentCalledAddress: 8887000 :: CurrentCallingAddress: Unknown :: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8887000 GC1: ConnInprogressEvent 8887000 GC1: CallCtlConnOfferedEv 8887000 From another provider, User1 invokes call.connect(irvCTIRD2, 8889000, 8887000). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 838 Message Sequence Charts Message Sequence Charts

Page 902 diagram

Page 903

Call info Events Action CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8889000 :: No LastRedirectedPartyAddress GC1: ConnCreatedEvent 8889000 GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: ConnAlertingEvent 8887000 GC1: CallCtlConnAlertingEv 8887000 GC1: TermConnCreatedEvent irvCTIPort7 GC1: TermConnRingingEvent irvCTIPort7 GC1: CallCtlTermConnRingingEv irvCTIPort7 irvCTIRD2's Active remote destination of 916267829523 answers the call. CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8887000 GC1: ConnConnectedEvent 8887000 GC1: CallCtlConnEstablishedEv 8887000 GC1: TermConnActiveEvent irvCTIPort7 GC1: CallCtlTermConnTalkingEv irvCTIPort7 irvCTIPort7 answers the call. Scenario 2-13 (Outgoing Call From CTI Remote Device to Non-Observed CTI Port) E calls D, Application is observing only on E on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: Unknown :: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 From another provider, User1 invokes call.connect(irvCTIRD2, 8889000, 8887000). CurrentCalledAddress: 8889000 :: CurrentCallingAddress: Unknown:: No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 839 Message Sequence Charts Message Sequence Charts

Page 903 diagram

Page 904

Call info Events Action CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8887000 GC1: ConnCreatedEvent 8887000 GC1: ConnInprogressEvent 8887000 GC1: CallCtlConnOfferedEv 8887000 GC1: ConnAlertingEvent 8887000 GC1: CallCtlConnAlertingEv 8887000 GC1: ConnConnectedEvent 8887000 GC1: CallCtlConnEstablishedEv 8887000 irvCTIPort7 rings and answers the call from another provider. Scenario 2-14 (Outgoing Call From CTI Remote Device to Another CTI Remote Device) E calls F, Application is observing both E and F on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 User1 invokes call.connect(irvCTIRD2, 8889000, 8889001). CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 840 Message Sequence Charts Message Sequence Charts

Page 904 diagram

Page 905

Call info Events Action CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: ConnCreatedEvent 8889001 GC1: ConnInprogressEvent 8889001 GC1: CallCtlConnOfferedEv 8889001 GC1: ConnAlertingEvent 8889001 GC1: CallCtlConnAlertingEv 8889001 GC1: TermConnCreatedEvent irvCTIRD3 GC1: TermConnRingingEvent irvCTIRD3 GC1: CallCtlTermConnRingingEv irvCTIRD3 GC1: ConnConnectedEvent 8889001 GC1: CallCtlConnEstablishedEv 8889001 GC1: TermConnActiveEvent irvCTIRD3 GC1: CallCtlTermConnTalkingEv irvCTIRD3 irvCTIRD3's Active remote destination of 916267829526 answers the call. CallingAddress = Unknown, CalledAddress = 8889000, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889000, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: TermConnDroppedEv irvCTIRD3 GC1: CallCtlTermConnDroppedEv irvCTIRD3 GC1: ConnDisconnectedEvent 8889001 GC1: CallCtlConnDisconnectedEv 8889001 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect the call from 8889000 connection. Scenario 2-15 (Outgoing Call From CTI Remote Device to Another CTI Remote Device, Then Redirect Again to a Third CTI Remote Device with a Shared-Line) E calls F, then F redirect to A (with a shared-line with B), Application is observing all A, B, E and F on addresses and terminals. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 841 Message Sequence Charts Message Sequence Charts

Page 905 diagram

Page 906

Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: Unknown:: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 User1 invokes call.connect(irvCTIRD2, 8889000, 8889001). CurrentCalledAddress: 8889000 :: CurrentCallingAddress: Unknown:: No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. CurrentCalledAddress: 8889001 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8889001 GC1: ConnCreatedEvent 8889001 GC1: ConnInprogressEvent 8889001 GC1: CallCtlConnOfferedEv 8889001 GC1: ConnAlertingEvent 8889001 GC1: CallCtlConnAlertingEv 8889001 GC1: TermConnCreatedEvent irvCTIRD3 GC1: TermConnRingingEvent irvCTIRD3 GC1: CallCtlTermConnRingingEv irvCTIRD3 GC1: ConnConnectedEvent 8889001 GC1: CallCtlConnEstablishedEv 8889001 GC1: TermConnActiveEvent irvCTIRD3 GC1: CallCtlTermConnTalkingEv irvCTIRD3 irvCTIRD3's Active remote destination of 916267829526 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 842 Message Sequence Charts Message Sequence Charts

Page 906 diagram

Page 907

Call info Events Action CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8889001 GC1: ConnCreatedEvent 8881000 GC1: ConnInprogressEvent 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnAlertingEvent 8881000 GC1: CallCtlConnAlertingEv 8881000 GC1: TermConnCreatedEvent irvCTIPort1 GC1: TermConnRingingEvent irvCTIPort1 GC1: CallCtlTermConnRingingEv irvCTIPort1 GC1: TermConnDroppedEv irvCTIRD3 GC1: CallCtlTermConnDroppedEv irvCTIRD3 GC1: ConnDisconnectedEvent 8889001 GC1: CallCtlConnDisconnectedEv 8889001 GC1: TermConnCreatedEvent irvCTIRD1 GC1: TermConnRingingEvent irvCTIRD1 GC1: CallCtlTermConnRingingEv irvCTIRD1 User invokes connection on irvCTIRD3.redirect(8881000, REDIRECT_NORMAL, DEFAULT_SEARCH_SPACE, CALLED_ADDRESS_UNCHANGED, REDIRECT, 8881000, null, REDIRECT_WITHOUT_MODIFIED_ CALLING_PARTY, 1). Both irvCTIRD1 and irvCTIPort1 are ringing. CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8889001 GC1: ConnConnectedEvent 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnActiveEvent irvCTIRD1 GC1: CallCtlTermConnTalkingEv irvCTIRD1 GC1: TermConnPassiveEvent irvCTIPort1 GC1: CallCtlTermConnBridgedEv irvCTIPort1 irvCTIRD1's Active remote destination of 919498231202 answers the call. Terminal connection of irvCTIRD1 goes to 'talking' and irvCTIPort1 goes to 'bridged'. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 843 Message Sequence Charts Message Sequence Charts

Page 907 diagram

Page 908

Call info Events Action CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8889001 GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: TermConnDroppedEv irvCTIRD1 GC1: CallCtlTermConnDroppedEv irvCTIRD1 GC1: TermConnDroppedEv irvCTIPort1 GC1: CallCtlTermConnDroppedEv irvCTIPort1 GC1: ConnDisconnectedEvent 8881000 GC1: CallCtlConnDisconnectedEv 8881000 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect the call from 8889000 connection. Scenario 2-16 (Disconnect an Incoming Call on CTI Remote Device After Answer While Talking) C calls E, Application is observing both C and E on addresses and terminals. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 844 Message Sequence Charts Message Sequence Charts

Page 908 diagram

Page 909

Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8886000 GC1: ConnConnectedEvent 8886000 GC1: CallCtlConnInitiatedEv 8886000 GC1: TermConnCreatedEvent irvCTIPort6 GC1: TermConnActiveEvent irvCTIPort6 GC1: CallCtlTermConnTalkingEv irvCTIPort6 GC1: CallCtlConnDialingEv 8886000 GC1: CallCtlConnEstablishedEv 8886000 GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 GC1: ConnAlertingEvent 8889000 GC1: CallCtlConnAlertingEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnRingingEvent irvCTIRD2 GC1: CallCtlTermConnRingingEv irvCTIRD2 User1 invokes call.connect(irvCTIPort6, 8886000, 8889000). CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 845 Message Sequence Charts Message Sequence Charts

Page 909 diagram

Page 910

Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: TermConnDroppedEv irvCTIPort6 GC1: CallCtlTermConnDroppedEv irvCTIPort6 GC1: ConnDisconnectedEvent 8886000 GC1: CallCtlConnDisconnectedEv 8886000 GC1: CallInvalidEvent GC1: CallObservationEndedEv User invokes connection.disconnect on irvCTIRD2 while talking. Scenario 2-17 (Disconnect an Incoming Call on CTI Remote Device After Answer While Talking) C calls E, Application is observing both C and E on addresses and terminals. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 846 Message Sequence Charts Message Sequence Charts

Page 910 diagram

Page 911

Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8886000 GC1: ConnConnectedEvent 8886000 GC1: CallCtlConnInitiatedEv 8886000 GC1: TermConnCreatedEvent irvCTIPort6 GC1: TermConnActiveEvent irvCTIPort6 GC1: CallCtlTermConnTalkingEv irvCTIPort6 GC1: CallCtlConnDialingEv 8886000 GC1: CallCtlConnEstablishedEv 8886000 GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 GC1: ConnAlertingEvent 8889000 GC1: CallCtlConnAlertingEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnRingingEvent irvCTIRD2 GC1: CallCtlTermConnRingingEv irvCTIRD2 User1 invokes call.connect(irvCTIPort6, 8886000, 8889000). CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: ConnFailedEvent 8886000 GC1: CallCtlConnFailedEv 8886000 GC1: TermConnDroppedEv irvCTIPort6 GC1: CallCtlTermConnDroppedEv irvCTIPort6 GC1: ConnDisconnectedEvent 8886000 GC1: CallCtlConnDisconnectedEv 8886000 GC1: CallInvalidEvent GC1: CallObservationEndedEv User invokes connection.disconnect on irvCTIRD2 while it's still ringing on Active remote destination of 16267829523. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 847 Message Sequence Charts Message Sequence Charts

Page 911 diagram

Page 912

Scenario 2-18 (Disconnect an Outgoing Call From CTI Remote Device to CTI Port; Disconnect After Answering on Remote Destination and Answering on Called CTI Port) E calls D, Application is observing both D and E on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8889000 :: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 User1 invokes call.connect(irvCTIRD2, 8889000, 8887000). CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8889000 :: No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8887000 GC1: ConnCreatedEvent 8887000 GC1: ConnInprogressEvent 8887000 GC1: CallCtlConnOfferedEv 8887000 GC1: ConnAlertingEvent 8887000 GC1: CallCtlConnAlertingEv 8887000 GC1: TermConnCreatedEvent irvCTIPort7 GC1: TermConnRingingEvent irvCTIPort7 GC1: CallCtlTermConnRingingEv irvCTIPort7 GC1: ConnConnectedEvent 8887000 GC1: CallCtlConnEstablishedEv 8887000 GC1: TermConnActiveEvent irvCTIPort7 GC1: CallCtlTermConnTalkingEv irvCTIPort7 irvCTIPort7 rings and answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 848 Message Sequence Charts Message Sequence Charts

Page 912 diagram

Page 913

Call info Events Action CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8887000 GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: TermConnDroppedEv irvCTIPort7 GC1: CallCtlTermConnDroppedEv irvCTIPort7 GC1: ConnDisconnectedEvent 8887000 GC1: CallCtlConnDisconnectedEv 8887000 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect the call from 8889000 connection. Scenario 2-19 (disconnect an Outgoing Call From CTI Remote Device to CTI Port; Disconnect After Answering on Remote Destination but Before Answering on Called CTI Port) E calls D, Application is observing both D and E on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8889000 :: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 User1 invokes call.connect(irvCTIRD2, 8889000, 8887000). CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8889000 :: No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889000 GC1: CallCtlConnEstablishedEv 8889000 GC1: TermConnCreatedEvent irvCTIRD2 GC1: TermConnActiveEvent irvCTIRD2 GC1: CallCtlTermConnTalkingEv irvCTIRD2 irvCTIRD2's Active remote destination of 916267829523 answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 849 Message Sequence Charts Message Sequence Charts

Page 913 diagram

Page 914

Call info Events Action CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8887000 GC1: ConnCreatedEvent 8887000 GC1: ConnInprogressEvent 8887000 GC1: CallCtlConnOfferedEv 8887000 GC1: ConnAlertingEvent 8887000 GC1: CallCtlConnAlertingEv 8887000 GC1: TermConnCreatedEvent irvCTIPort7 GC1: TermConnRingingEvent irvCTIPort7 GC1: CallCtlTermConnRingingEv irvCTIPort7 irvCTIPort7 rings CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8889000 :: LastRedirectedPartyAddress: 8887000 GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv irvCTIRD2 GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: TermConnDroppedEv irvCTIPort7 GC1: CallCtlTermConnDroppedEv irvCTIPort7 GC1: ConnDisconnectedEvent 8887000 GC1: CallCtlConnDisconnectedEv 8887000 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect the call from 8889000 connection. Scenario 2-20 (Disconnect an Outgoing Call From CTI Remote Device to CTI Port; Drop the Call Before Even Answering on Remote Destination. Note That Only One Connection on CTI Remote Device Which Is in Offering State) E calls D, Application is observing both D and E on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8889000 :: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889000 GC1: ConnInprogressEvent 8889000 GC1: CallCtlConnOfferedEv 8889000 User1 invokes call.connect(irvCTIRD2, 8889000, 8887000). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 850 Message Sequence Charts Message Sequence Charts

Page 914 diagram

Page 915

Call info Events Action CurrentCalledAddress: 8889000 :: CurrentCallingAddress: 8889000 :: No LastRedirectedPartyAddress GC1: ConnDisconnectedEvent 8889000 GC1: CallCtlConnDisconnectedEv 8889000 GC1: CallInvalidEvent GC1: CallObservationEndedEv irvCTIRD2's Active remote destination of 916267829523 rings, User1 drops the call to disconnect from 8889000 connection. Scenario 2-21 (Incoming Call From CTI Port to CTI Remote Device with a Shared-line of Another CTI Port). Note That irvCTIRD1 Remote Destination Answers the Call; Hold irvCTIRD1, Unhold irvCTIRD1; Then Hold irvCTIRD1, Unhold irvCTIPort1 Which Results irvCTIRD1 Got Disconnected; Then Hold irvCTIPort6, Unhold irvCTIPort6, Then Disconnect 8886000) C calls A (with a shared line with B) with several hold/resume operations on different terminals. Application is observing A, B, and C on addresses and terminals. GC1 is the GCID of the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 851 Message Sequence Charts Message Sequence Charts

Page 915 diagram

Page 916

Call info Events Action CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8886000 GC1: ConnConnectedEvent 8886000 GC1: CallCtlConnInitiatedEv 8886000 GC1: TermConnCreatedEvent irvCTIPort6 GC1: TermConnActiveEvent irvCTIPort6 GC1: CallCtlTermConnTalkingEv irvCTIPort6 GC1: CallCtlConnDialingEv 8886000 GC1: CallCtlConnEstablishedEv 8886000 GC1: ConnCreatedEvent 8881000 GC1: ConnInprogressEvent 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnAlertingEvent 8881000 GC1: CallCtlConnAlertingEv 8881000 GC1: TermConnCreatedEvent irvCTIPort1 GC1: TermConnRingingEvent irvCTIPort1 GC1: CallCtlTermConnRingingEv irvCTIPort1 GC1: TermConnCreatedEvent irvCTIRD1 GC1: TermConnRingingEvent irvCTIRD1 GC1: CallCtlTermConnRingingEv irvCTIRD1 User1 invokes call.connect(irvCTIPort6, 8886000, 881000). CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnActiveEvent irvCTIRD1 GC1: CallCtlTermConnTalkingEv irvCTIRD1 GC1: TermConnPassiveEvent irvCTIPort1 GC1: CallCtlTermConnBridgedEv irvCTIPort1 irvCTIRD1's Active remote destination of 919498231202 answers the call. CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: CallCtlTermConnHeldEv irvCTIRD1 GC1: TermConnActiveEvent irvCTIPort1 GC1: CallCtlTermConnHeldEv irvCTIPort1 User invoke hold on terminalconnection of irvCTIRD1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 852 Message Sequence Charts Message Sequence Charts

Page 916 diagram

Page 917

Call info Events Action CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: CallCtlTermConnTalkingEv irvCTIRD1 GC1: TermConnPassiveEvent irvCTIPort1 GC1: CallCtlTermConnBridgedEv irvCTIPort1 User invoke unhold on terminalconnection of irvCTIRD1 CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: CallCtlTermConnHeldEv irvCTIRD1 GC1: TermConnActiveEvent irvCTIPort1 GC1: CallCtlTermConnHeldEv irvCTIPort1 User invoke hold on terminalconnection of irvCTIRD1 CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: CallCtlTermConnTalkingEv irvCTIPort1 GC1: TermConnDroppedEv irvCTIRD1 GC1: CallCtlTermConnDroppedEv irvCTIRD1 User invoke unhold on terminalconnection of irvCTIPort1 (while it's in Bridged state). This results in irvCTIRD1 being dropped. CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: CallCtlTermConnHeldEv irvCTIPort6 User invoke hold on terminalconnection of irvCTIPort6 GC1: CallCtlTermConnTalkingEv irvCTIPort6 User invoke unhold on terminalconnection of irvCTIPort6 CurrentCalledAddress: 8881000 :: CurrentCallingAddress: 8886000 :: No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIPort6 GC1: CallCtlTermConnDroppedEv irvCTIPort6 GC1: ConnDisconnectedEvent 8886000 GC1: CallCtlConnDisconnectedEv8886000 GC1: TermConnDroppedEv irvCTIPort1 GC1: CallCtlTermConnDroppedEv irvCTIPort1 GC1: ConnDisconnectedEvent 8881000 GC1: CallCtlConnDisconnectedEv 8881000 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect the call from connection of irvCTIPort6. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 853 Message Sequence Charts Message Sequence Charts

Page 917 diagram

Page 918

Scenario 2-22 (Outgoing Call From CTI Remote Device (with a Shared Line of CTI Port) to Another CTI Port). Note That irvCTIPort1 Rings and Remote Destination on irvCTIRD1 Rings, Remote Destination Answers the Call, Call Is Then Offered on irvCTIPort7. After Answer on irvCTIPort7, Disconnect From 8881000 Connection) A (with a shared line of B) calls D, then with several hold/unhold operations at different terminals. Application is observing both A, B, and D on addresses and terminals. GC1 is the GCID of the call. Call info Events Action CurrentCalledAddress: 8881000:: CurrentCallingAddress: 8881000:: No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8881000 GC1: ConnInprogressEvent 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnAlertingEvent 8881000 GC1: CallCtlConnAlertingEv 8881000 User1 invokes call.connect(irvCTIRD1, 8881000, 8887000). GC1: TermConnCreatedEvent irvCTIPort1 GC1: TermConnRingingEvent irvCTIPort1 GC1: CallCtlTermConnRingingEv irvCTIPort1 irvCTIPort7 rings CurrentCalledAddress: 8881000:: CurrentCallingAddress: 8881000:: No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnCreatedEvent irvCTIRD1 GC1: TermConnActiveEvent irvCTIRD1 GC1: CallCtlTermConnTalkingEv irvCTIRD1 irvCTIRD1's Active remote destination of 919498231202 answers the call. CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8881000 :: No LastRedirectedPartyAddress GC1: TermConnPassiveEvent irvCTIPort1 GC1: CallCtlTermConnBridgedEv irvCTIPort1 irvCTIPort7 rings Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 854 Message Sequence Charts Message Sequence Charts

Page 918 diagram

Page 919

Call info Events Action CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8881000:: LastRedirectedPartyAddress: 8887000 GC1: ConnCreatedEvent 8887000 GC1: ConnInprogressEvent 8887000 GC1: CallCtlConnOfferedEv 8887000 GC1: ConnAlertingEvent 8887000 GC1: CallCtlConnAlertingEv 8887000 GC1: TermConnCreatedEvent irvCTIPort7 GC1: TermConnRingingEvent irvCTIPort7 GC1: CallCtlTermConnRingingEv irvCTIPort7 GC1: ConnConnectedEvent 8887000 GC1: CallCtlConnEstablishedEv 8887000 GC1: TermConnActiveEvent irvCTIPort7 GC1: CallCtlTermConnTalkingEv irvCTIPort7 irvCTIPort7 answers the call. CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8881000 :: LastRedirectedPartyAddress: 8887000 GC1: CallCtlTermConnHeldEv irvCTIRD1 GC1: TermConnActiveEvent irvCTIPort1 User invoke hold on terminalconnection of irvCTIRD1 CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8881000 :: LastRedirectedPartyAddress: 8887000 GC1: CallCtlTermConnHeldEv irvCTIPort1 GC1: CallCtlTermConnTalkingEv irvCTIPort1 GC1: TermConnDroppedEv irvCTIRD1 GC1: CallCtlTermConnDroppedEv irvCTIRD1 User invoke unhold on terminalconnection of irvCTIPort1 (while it's in Bridged state). This results in irvCTIRD1 being dropped. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 855 Message Sequence Charts Message Sequence Charts

Page 919 diagram

Page 920

Call info Events Action CurrentCalledAddress: 8887000 :: CurrentCallingAddress: 8881000 :: LastRedirectedPartyAddress: 8887000 GC1: TermConnDroppedEv irvCTIPort1 GC1: CallCtlTermConnDroppedEv irvCTIPort1 GC1: ConnDisconnectedEvent 8881000 GC1: CallCtlConnDisconnectedEv 8881000 GC1: TermConnDroppedEv irvCTIPort7 GC1: CallCtlTermConnDroppedEv irvCTIPort7 GC1: ConnDisconnectedEvent 8887000 GC1: CallCtlConnDisconnectedEv 8887000 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect the call from 8881000 connection. Scenario 2-23 (Superprovider Acquires a CTIRD That Is Not on User Control List) User1 open a provider which can observe any terminal (User1 with "Standard CTI Allow Control of All Devices" role), and then acquire a CTI Remote Device "CTIRD_UP" that is not on User1's control list). Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoAddrCreatedEv: 8889999 CiscoTermCreatedEv: CTIRD_UP User1 invokes provider.createTerminal(CTIRD_UP). CTI Remote Device Use Cases Group 3 Use Cases Group 3 (CUCSF Registration and Unregistration, for Normal SIP Mode <-> Extend Mode, and Terminal Switching Scenarios) Pre-conditions on Use Cases group 3 below with default jtapi.ini settings, unless specified explicitly: • Provider is IN_SERVICE state. • Device A (CUCSF - Name: "irvCSF1", Line A (DN: 7771000)) • Remote Destination 1 (Name: "IRVCell", Number: "916267829523", Active RD: true) • Scenario 3-1 (Registration of CUCSF in between Extend mode and SIP mode).: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 856 Message Sequence Charts CTI Remote Device Use Cases Group 3

Page 920 diagram

Page 921

Device A is registered in normal SIP mode when Webex with Jabber client is running and configured this device as its associated phone. User1 open provider and add observers on this device to bring it in service. Now exit Webex to unregister it from SIP, and then User1 calls CiscoTerminal.register() to register it to Extend mode from JTAPI, then add observers back to bring it in service. Now User1 unregister it from Extend mode in JTAPI by calling CiscoRemoteTerminal.unregister(). Now open Webex again to register this device back to SIP mode, and add observers back to bring it in service. Info Events Action CiscoTerminal.getProtocol = 2 CiscoTerminal.isRegistered() = true CiscoRemoteTerminal.getType() = 503 CiscoRemoteTerminal.getTypeName() = Cisco Unified Client Services Framework Provider: ProvInServiceEv 7771000: CiscoAddrOutOfServiceEv irvCSF1: CiscoTermInServiceEv 7771000: CiscoAddrInServiceEv irvCSF1: CiscoTermInServiceEv Webex is opened. User1 adds provider observer. registerFeature 1235 on provider. addObserver on address 7771000. addObserver on terminal irvCSF1. CiscoTerminal.getProtocol = 2 CiscoTerminal.isRegistered() = false Provider: CiscoProvTerminalUnRegisteredEv irvCSF1 7771000: CiscoAddrOutOfServiceEv irvCSF1: CiscoTermOutOfServiceEv Exit Webex CiscoTerminal.getProtocol = 3 CiscoTerminal.isRegistered() = true CiscoRemoteTerminal.getRegistrationType() = 8 CiscoRemoteTerminal.isRegisteredByThisApp() = true Provider: CiscoAddrRemovedEv 7771000 Provider: CiscoTermRemovedEv irvCSF1 Provider: CiscoAddrCreatedEv 7771000 Provider: CiscoTermCreatedEv irvCSF1 Provider: CiscoProvTerminalRegisteredEv irvCSF1: CiscoTermInServiceEv 7771000: CiscoAddrOutOfServiceEv 7771000: CiscoAddrInServiceEv irvCSF1: CiscoTermInServiceEv User1 calls CiscoTerminal.register() on irvCSF1. addObserver on address 7771000. addObserver on terminal irvCSF1. CiscoTerminal.getProtocol = 3 CiscoTerminal. isRegistered() = false CiscoRemoteTerminal.getRegistrationType() = -1 CiscoRemoteTerminal. isRegisteredByThisApp() = false 7771000: CiscoAddrOutOfServiceEv irvCSF1: CiscoTermOutOfServiceEv Provider: CiscoProvTerminalUnRegisteredEv User1 calls CiscoRemoteTerminal. unregister() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 857 Message Sequence Charts Message Sequence Charts

Page 921 diagram

Page 922

Info Events Action CiscoTerminal.getProtocol = 2 CiscoTerminal.isRegistered() = true Provider: CiscoAddrRemovedEv 7771000 Provider: CiscoTermRemovedEv irvCSF1 Provider: CiscoAddrCreatedEv 7771000 Provider: CiscoTermCreatedEv irvCSF1 Provider: CiscoProvTerminalRegisteredEv 7771000: CiscoAddrOutOfServiceEv irvCSF1: CiscoTermInServiceEv 7771000: CiscoAddrInServiceEv irvCSF1: CiscoTermInServiceEv Open Webex addObserver on address 7771000. addObserver on terminal irvCSF1. CTI Remote Device Use Cases Group 4 Use Cases Group 4 (Set/Reset Active Remote Destination Scenarios) Pre-conditions on Use Cases group 4 below with default jtapi.ini settings, unless specified explicitly: • Provider is IN_SERVICE state. Single node. • Device A (CTI Remote Device - Name: "irvCTIRD2", Line A (DN: 8881000)) • Remote Destination 1 (Name: "IRVCell1", Number: "916267829523", Active RD: false) • Scenario 4-1 (User1 opens provider P1, set RD1 as active. Now User1 opens another provider P2, and set same RD1 as active again. Now stop CTI Manager service in this single node, the active RD would be clear out. Now restart CTI Manager, JTAPI will do a provider retry, and upon successfully connection, it will automatically reset the same RD1 as active again seamlessly.): Info Events Action P1: ProvInServiceEv User1 open Provider P1 and adds provider observer. P1 changed event: Remote Terminal: irvCTIRD2 :: [Remote Destination 1: Name:IRVCell1, Number:916267829523, IsActiveRD:true] :: IsMyAppLastToSetActiveRD : true CiscoRemoteTerminal. isMyAppLastToSetActiveRD() = true P1: CiscoProvTerminalRemoteDestinationChangedEv User1 calls CiscoRemoteTerminal. setActiveRemote Destination ("916267829523", true) from P1. P2: ProvInServiceEv User1 open Provider P2 and adds provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 858 Message Sequence Charts CTI Remote Device Use Cases Group 4

Page 922 diagram

Page 923

Info Events Action P1 changed event: Remote Terminal: irvCTIRD2 :: [Remote Destination 1: Name:IRVCell1, Number:916267829523, IsActiveRD:true] :: IsMyAppLastToSetActiveRD : false CiscoRemoteTerminal. isMyAppLastToSetActiveRD() = false P2 changed event: Remote Terminal: irvCTIRD2 :: [Remote Destination 1: Name:IRVCell1, Number:916267829523, IsActiveRD:true] :: IsMyAppLastToSetActiveRD : true CiscoRemoteTerminal. isMyAppLastToSetActiveRD() = true P1: CiscoProvTerminalRemote DestinationChangedEv P2: CiscoProvTerminalRemote DestinationChangedEv User1 calls CiscoRemoteTerminal. setActiveRemote Destination ("916267829523", true) from P2. P1: ProvOutOfServiceEv P2: ProvOutOfServiceEv Stop CTI Manager on this single node where P1 & P2 are connected to. And this active RD will be clear out automatically from CTI/CCM side. Note that no CiscoProvTerminalRemote DestinationChangedEv will be sent to application because it is the same active RD that application previously set. P1: ProvInServiceEv P2: ProvInServiceEv Start this CTI Manager. And JTAPI will automatically reset the same RD1 as active again seamlessly. Scenario 4-2 (User1 Opens Provider P1, Add All Observers on Provider, Terminals, Addresses, Then Set RD1 as Active. Now Stop CTI Manager Service, the Active RD Would Be Clear Out. Now Restart CTI Manager, JTAPI Will Do a Provider Retry, and Upon Successfully Connection, It Will Automatically Reset the Same RD1 as Active Again Seamlessly) Info Events Action P1: ProvInServiceEv User1 open Provider P1 and adds provider observer. P1 changed event: Remote Terminal: irvCTIRD2 :: [Remote Destination 1: Name:IRVCell1, Number:916267829523, IsActiveRD:true] :: IsMyAppLastToSetActiveRD : true CiscoRemoteTerminal. isMyAppLastToSetActiveRD() = true P1: CiscoProvTerminalRemote DestinationChangedEv User1 calls CiscoRemoteTerminal. setActiveRemote Destination ("916267829523", true) from P1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 859 Message Sequence Charts Message Sequence Charts

Page 923 diagram

Page 924

Info Events Action 8881000:: Event: CiscoAddrOutOfServiceEv irvCTIRD2:: Event: CiscoTermOutOfServiceEv P1: ProvOutOfServiceEv Stop CTI Manager where P1 is connected to. And this active RD will be clear out automatically from CTI/CCM side. Note that no CiscoProvTerminalRemote DestinationChangedEv will be sent to application because it is the same active RD that application previously set. P1: ProvInServiceEv irvCTIRD2:: Event: CiscoTermInServiceEv 8881000:: Event: CiscoAddrInServiceEv Start this CTI Manager. And JTAPI will automatically reset the same RD1 as active again seamlessly. CTI Remote Device Use Cases Group 5 Use Cases Group 5 (CTIRD Transfer/Conference/Multiple-Calls Call Scenarios) Pre-conditions on Use Cases group 5 below with default jtapi.ini settings, unless specified explicitly (Note: The CTI Ports have Auto-Accept enabled): • Provider is IN_SERVICE state. • Device A (CTI Remote Device - Name: "irvCTIRD2", Line A (DN: 8889000)) • Remote Destination 1 (Name: "IRVCell1", Number: "916267829523", Active RD: true) • Device B (CTI Port - Name: "irvCTIPort4", Line B (DN: 8884000)) • Device C (CTI Port - Name: "irvCTIPort5", Line B (DN: 8884000)) • Device D (CTI Port - Name: "irvCTIPort6", Line D (DN: 8886000)) • Device E (CTI Remote Device - Name: "irvCTIRD3", Line E (DN: 8889001)) • Remote Destination 1 (Name: "IRVHome1", Number: "916268210080", Active RD: true) Scenario 5-1 (Direct Transfer on CTI Remote Device to CTI Port) D calls A with GC1 as GCID of call; A calls B with GC2 as GCID of call. Set A as transfer controller, and then transfer call from GC2 to GC1. Application is observing all A, B, D. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 860 Message Sequence Charts CTI Remote Device Use Cases Group 5

Page 924 diagram

Page 925

Page 925 diagram

Page 926

Call info Events Action CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress CallingAddress = 8889000, CalledAddress = 8884000, CurrentCallingAddress = 8889000, CurrentCalledAddress = 8884000, ModifiedCallingAddress = 8889000, ModifiedCalledAddress = 8884000, No LastRedirectedPartyAddress GC1: CallCtlTermConnHeldEv irvCTIRD2 GC2: CallActiveEvent GC2: ConnCreatedEvent : Address: 8889000 GC2: ConnConnectedEvent : Address: 8889000 GC2: CallCtlConnInitiatedEv : Address: 8889000 GC2: TermConnCreatedEvent : Terminal: irvCTIRD2 GC2: TermConnActiveEvent : Terminal: irvCTIRD2 GC2: CallCtlTermConnTalkingEv : Terminal: irvCTIRD2 GC2: CallCtlConnDialingEv : Address: 8889000 GC2: CallCtlConnEstablishedEv : Address: 8889000 GC2: ConnCreatedEvent : Address: 8884000 GC2: ConnInprogressEvent : Address: 8884000 GC2: CallCtlConnOfferedEv : Address: 8884000 GC2: ConnAlertingEvent : Address: 8884000 GC2: CallCtlConnAlertingEv : Address: 8884000 GC2: TermConnCreatedEvent : Terminal: irvCTIPort4 GC2: TermConnRingingEvent : Terminal: irvCTIPort4 GC2: CallCtlTermConnRingingEv : Terminal: irvCTIPort4 GC2: TermConnCreatedEvent : Terminal: irvCTIPort5 GC2: TermConnRingingEvent : Terminal: irvCTIPort5 User1 invokes call. connect (irvCTIRD2, 8889000, 8884000) , and answer() on irvCTIPort4 terminal connection. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 862 Message Sequence Charts Message Sequence Charts

Page 926 diagram

Page 927

Call info Events Action GC2: CallCtlTermConnRingingEv : Terminal: irvCTIPort5 GC2: ConnConnectedEvent : Address: 8884000 GC2: CallCtlConnEstablishedEv : Address: 8884000 GC2: TermConnActiveEvent : Terminal: irvCTIPort4 GC2: CallCtlTermConnTalkingEv : Terminal: irvCTIPort4 GC2: TermConnPassiveEvent : Terminal: irvCTIPort5 GC2: CallCtlTermConnInUseEv : Terminal: irvCTIPort5 CallingAddress = 8889000, CalledAddress = 8884000, CurrentCallingAddress = 8884000, CurrentCalledAddress = 8886000, ModifiedCallingAddress = 8884000, ModifiedCalledAddress = 8886000, LastRedirectedPartyAddress = 8889000 CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC2: CiscoTermConnSelectChangedEv : Terminal: irvCTIRD2 GC1: CiscoTermConnSelectChangedEv : Terminal: irvCTIRD2 User1 invokes GC2.setTransferController (terminal connection of irvCTIRD2). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 863 Message Sequence Charts Message Sequence Charts

Page 927 diagram

Page 928

Call info Events Action CallingAddress = 8889000, CalledAddress = 8884000, CurrentCallingAddress = 8884000, CurrentCalledAddress = 8886000, ModifiedCallingAddress = 8884000, ModifiedCalledAddress = 8886000, LastRedirectedPartyAddress = 8889000 GC2: CiscoTransferStartEv GC1: TermConnDroppedEv irvCTIRD2 GC1: CallCtlTermConnDroppedEv : Terminal: irvCTIRD2 GC1: ConnDisconnectedEvent : Address: 8889000 GC1: CallCtlConnDisconnectedEv : Address: 8889000 GC2: TermConnDroppedEv : Terminal: irvCTIRD2 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIRD2 GC2: ConnDisconnectedEvent : Address: 8889000 GC2: CallCtlConnDisconnectedEv : Address: 8889000 GC1: CiscoCallChangedEv GC2: ConnCreatedEvent : Address: 8886000 GC2: ConnConnectedEvent : Address: 8886000 GC2: CallCtlConnEstablishedEv : Address: 8886000 GC2: TermConnCreatedEvent : Terminal: irvCTIPort6 GC2: TermConnActiveEvent : Terminal: irvCTIPort6 GC2: CallCtlTermConnTalkingEv : Terminal: irvCTIPort6 GC1: TermConnDroppedEv : Terminal: irvCTIPort6 User1 invokes GC2.transfer(GC1). GC1: CallCtlTermConnDroppedEv : Terminal: irvCTIPort6 GC1: ConnDisconnectedEvent : Address: 8886000 GC1: CallCtlConnDisconnectedEv : Address: 8886000 GC1: CallInvalidEvent GC1: CallObservationEndedEv GC2: CiscoTransferEndEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 864 Message Sequence Charts Message Sequence Charts

Page 928 diagram

Page 929

Call info Events Action CallingAddress = 8889000, CalledAddress = 8884000, CurrentCallingAddress = 8884000, CurrentCalledAddress = 8886000, ModifiedCallingAddress = 8884000, ModifiedCalledAddress = 8886000, LastRedirectedPartyAddress = 8889000 GC2: TermConnDroppedEv irvCTIPort6 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIPort6 GC2: ConnDisconnectedEvent : Address: 8886000 GC2: CallCtlConnDisconnectedEv : Address: 8886000 GC2: TermConnDroppedEv : Terminal: irvCTIPort4 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIPort4 GC2: TermConnDroppedEv : Terminal: irvCTIPort5 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIPort5 GC2: ConnDisconnectedEvent : Address: 8884000 GC2: CallCtlConnDisconnectedEv : Address: 8884000 GC2: CallInvalidEvent GC2: CallObservationEndedEv disconnect() the call on 8886000 connection. Scenario 5-2 (Conference Call on CTI Remote Device and CTI Port with Another CTI Remote Device) D calls A with GC1 as GCID of call; A calls E with GC2 as GCID of call. Set A as conference controller, and then conference/join call from GC2 to GC1. Application is observing all A, D, E. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 865 Message Sequence Charts Message Sequence Charts

Page 929 diagram

Page 930

Page 930 diagram

Page 931

Call info Events Action CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress CallingAddress = 8889000, CalledAddress = 8889001, CurrentCallingAddress = 8889000, CurrentCalledAddress = 8889001, ModifiedCallingAddress = 8889000, ModifiedCalledAddress = 8889001, No LastRedirectedPartyAddress GC1: CallCtlTermConnHeldEv irvCTIRD2 GC2: CallActiveEvent GC2: ConnCreatedEvent : Address: 8889000 GC2: ConnConnectedEvent : Address: 8889000 GC2: CallCtlConnInitiatedEv : Address: 8889000 GC2: TermConnCreatedEvent : Terminal: irvCTIRD2 GC2: TermConnActiveEvent : Terminal: irvCTIRD2 GC2: CallCtlTermConnTalkingEv : Terminal: irvCTIRD2 GC2: CallCtlConnDialingEv : Address: 8889000 GC2: CallCtlConnEstablishedEv : Address: 8889000 GC2: ConnCreatedEvent : Address: 8889001 GC2: ConnInprogressEvent : Address: 8889001 GC2: CallCtlConnOfferedEv : Address: 8889001 GC2: ConnAlertingEvent : Address: 8889001 GC2: CallCtlConnAlertingEv : Address: 8889001 GC2: TermConnCreatedEvent : Terminal: irvCTIRD3 GC2: TermConnRingingEvent : Terminal: irvCTIRD3 GC2: CallCtlTermConnRingingEv : Terminal: irvCTIRD3 User1 invokes call. connect (irvCTIRD2, 8889000, 8889001). CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = Unknown, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = Unknown, LastRedirectedPartyAddress: 8889000 GC2: ConnConnectedEvent : Address: 8889001 GC2: CallCtlConnEstablishedEv : Address: 8889001 GC2: TermConnActiveEvent : Terminal: irvCTIRD3 GC2: CallCtlTermConnTalkingEv : Terminal: irvCTIRD3 irvCTIRD3's Active remote destination of 916268210080 answers the call. GC2: CiscoTermConnSelectChangedEv : Terminal: irvCTIRD2 GC2: CiscoTermConnSelectChangedEv : Terminal: irvCTIRD2 User1 invokes GC2.setConference Controller (terminal connection of irvCTIRD2). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 867 Message Sequence Charts Message Sequence Charts

Page 931 diagram

Page 932

Call info Events Action CallingAddress = 8889000, CalledAddress = 8889001, CurrentCallingAddress = 8886000, CurrentCalledAddress = Unknown, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = Unknown, LastRedirectedPartyAddress: 8889000 GC2: CiscoConferenceStartEv GC1: TermConnDroppedEv : Terminal: irvCTIRD2 GC1: CallCtlTermConnDroppedEv : Terminal: irvCTIRD2 GC1: ConnDisconnectedEvent : Address: 8889000 GC1: CallCtlConnDisconnectedEv : Address: 8889000 GC1: CiscoCallChangedEv GC2: ConnCreatedEvent : Address: 8886000 GC2: ConnConnectedEvent : Address: 8886000 GC2: CallCtlConnEstablishedEv : Address: 8886000 GC2: TermConnCreatedEvent : Terminal: irvCTIPort6 GC2: TermConnActiveEvent : Terminal: irvCTIPort6 GC2: CallCtlTermConnTalkingEv : Terminal: irvCTIPort6 GC1: TermConnDroppedEv : Terminal: irvCTIPort6 GC1: CallCtlTermConnDroppedEv : Terminal: irvCTIPort6 GC1: ConnDisconnectedEvent : Address: 8886000 GC1: CallCtlConnDisconnectedEv : Address: 8886000 GC1: CallInvalidEvent GC1: CallObservationEndedEv GC2: CiscoConferenceEndEv User1 invokes GC2.conference(GC1). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 868 Message Sequence Charts Message Sequence Charts

Page 932 diagram

Page 933

Call info Events Action CallingAddress = 8889000, CalledAddress = 8889001, CurrentCallingAddress = 8886000, CurrentCalledAddress = Unknown, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = Unknown, LastRedirectedPartyAddress: 8889000 GC2: TermConnDroppedEv : Terminal: irvCTIRD2 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIRD2 GC2: ConnDisconnectedEvent : Address: 8889000 GC2: CallCtlConnDisconnectedEv : Address: 8889000 GC2: TermConnDroppedEv : Terminal: irvCTIRD3 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIRD3 GC2: ConnDisconnectedEvent : Address: 8889001 GC2: CallCtlConnDisconnectedEv : Address: 8889001 disconnect() the call on 8889000 connection. CallingAddress = 8889000, CalledAddress = 8889001, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889001, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889001, LastRedirectedPartyAddress: 8889000 GC2: TermConnDroppedEv : Terminal: irvCTIPort6 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIPort6 GC2: ConnDisconnectedEvent : Address: 8886000 GC2: CallCtlConnDisconnectedEv : Address: 8886000 GC2: CallInvalidEvent GC2: CallObservationEndedEv disconnect() the call on 8889001 connection. Scenario 5-3 (Multiple Calls on CTI Remote Device) D calls A with GC1 as GCID of call; B calls A with GC2 as GCID of call. Application is observing all A, B, D. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 869 Message Sequence Charts Message Sequence Charts

Page 933 diagram

Page 934

Page 934 diagram

Page 935

Call info Events Action CallingAddress = 8884000, CalledAddress = 8889000, CurrentCallingAddress = 8884000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8884000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress CallingAddress = 8889000, CalledAddress = 8889001, CurrentCallingAddress = 8889000, CurrentCalledAddress = 8889001, ModifiedCallingAddress = 8889000, ModifiedCalledAddress = 8889001, No LastRedirectedPartyAddress GC2: CallActiveEvent GC2: ConnCreatedEvent : Address: 8884000 GC2: ConnConnectedEvent : Address: 8884000 GC2: CallCtlConnInitiatedEv : Address: 8884000 GC2: TermConnCreatedEvent : Terminal: irvCTIPort4 GC2: TermConnActiveEvent : Terminal: irvCTIPort4 GC2: CallCtlTermConnTalkingEv : Terminal: irvCTIPort4 GC2: CallCtlConnDialingEv : Address: 8884000 GC2: TermConnCreatedEvent : Terminal: irvCTIPort5 GC2: TermConnPassiveEvent : Terminal: irvCTIPort5 GC2: CallCtlTermConnInUseEv : Terminal: irvCTIPort5 GC2: CallCtlConnEstablishedEv : Address: 8884000 GC2: ConnCreatedEvent : Address: 8889000 GC2: ConnInprogressEvent : Address: 8889000 GC2: CallCtlConnOfferedEv : Address: 8889000 GC2: ConnAlertingEvent : Address: 8889000 GC2: CallCtlConnAlertingEv : Address: 8889000 GC2: TermConnCreatedEvent : Terminal: irvCTIRD2 GC2: TermConnRingingEvent : Terminal: irvCTIRD2 GC2: CallCtlTermConnRingingEv : Terminal: irvCTIRD2 User1 invokes call. connect (irvCTIPort4, 8884000, 8889000) CallingAddress = 8884000, CalledAddress = 8889000, CurrentCallingAddress = 8884000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8884000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: CallCtlTermConnHeldEv : Terminal: irvCTIRD2 GC2: ConnConnectedEvent : Address: 8889000 GC2: CallCtlConnEstablishedEv : Address: 8889000 GC2: TermConnActiveEvent : Terminal: irvCTIRD2 GC2: CallCtlTermConnTalkingEv : Terminal: irvCTIRD2 User1 invokes GC2.answer(terminal connection of irvCTIRD2). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 871 Message Sequence Charts Message Sequence Charts

Page 935 diagram

Page 936

Call info Events Action CallingAddress = 8884000, CalledAddress = 8889000, CurrentCallingAddress = 8884000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8884000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC2: TermConnDroppedEv : Terminal: irvCTIRD2 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIRD2 GC2: ConnDisconnectedEvent : Address: 8889000 GC2: CallCtlConnDisconnectedEv : Address: 8889000 GC2: TermConnDroppedEv : Terminal: irvCTIPort4 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIPort4 GC2: TermConnDroppedEv : Terminal: irvCTIPort5 GC2: CallCtlTermConnDroppedEv : Terminal: irvCTIPort5 GC2: ConnDisconnectedEvent : Address: 8884000 GC2: CallCtlConnDisconnectedEv : Address: 8884000 GC2: CallInvalidEvent GC2: CallObservationEndedEv disconnect() the GC2 call on 8889000 connection. CallingAddress = 8886000, CalledAddress = 8889000, CurrentCallingAddress = 8886000, CurrentCalledAddress = 8889000, ModifiedCallingAddress = 8886000, ModifiedCalledAddress = 8889000, No LastRedirectedPartyAddress GC1: CallCtlTermConnTalkingEv GC1: TermConnDroppedEv : Terminal: irvCTIRD2 GC1: CallCtlTermConnDroppedEv : Terminal: irvCTIRD2 GC1: ConnDisconnectedEvent : Address: 8889000 GC1: CallCtlConnDisconnectedEv : Address: 8889000 GC1: TermConnDroppedEv : Terminal: irvCTIPort6 GC1: CallCtlTermConnDroppedEv : Terminal: irvCTIPort6 GC1: ConnDisconnectedEvent : Address: 8886000 GC1: CallCtlConnDisconnectedEv : Address: 8886000 GC1: CallInvalidEvent GC1: CallObservationEndedEv User1 invokes unhold() on GC1 terminal connection of irvCTIRD2. disconnect() the GC1 call on 8889000 connection. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 872 Message Sequence Charts Message Sequence Charts

Page 936 diagram

Page 937

CTI Remote Device Use Cases Group 6 Use Cases Group 6 (CTIRD URI-Dialing Basic Incoming and Outgoing DVO Call Scenarios) Pre-conditions on Use Cases group 6 below with default jtapi.ini settings, unless specified explicitly (Note: The CTI Ports have Auto-Accept enabled): • Provider is IN_SERVICE state. • Device A (CTI Remote Device - Name: "irvCTIRD3", Line A (DN: 8889001, Directory URIs: "8889001A@cisco.com")) • Remote Destination 1 (Name: "IRVCell1", Number: "916267829523", Active RD: true) • Device B (CTI Port - Name: "irvCTIPort2", Line B (DN: 8882000, Directory URIs: "8882000A@cisco.com")) Scenario 6-1 (Basic Incoming Call From CTI Port to CTI Remote Device Via URI) B calls A with GC1 as GCID of call. Application is observing both A and B. Call info Events Action CallingAddress = 8882000, CalledAddress = 8889001, CurrentCallingAddress = 8882000, CurrentCalledAddress = 8889001, ModifiedCallingAddress = 8882000, ModifiedCalledAddress = 8889001, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8882000 GC1: ConnConnectedEvent 8882000 GC1: CallCtlConnInitiatedEv 8882000 GC1: TermConnCreatedEvent irvCTIPort2 GC1: TermConnActiveEvent irvCTIPort2 GC1: CallCtlTermConnTalkingEv irvCTIPort2 GC1: CallCtlConnDialingEv 8882000 GC1: CallCtlConnEstablishedEv 8882000 GC1: ConnCreatedEvent 8889001 GC1: ConnInprogressEvent 8889001 GC1: CallCtlConnOfferedEv 8889001 GC1: ConnAlertingEvent 8889001 GC1: CallCtlConnAlertingEv 8889001 GC1: TermConnCreatedEvent irvCTIRD3 GC1: TermConnRingingEvent irvCTIRD3 GC1: CallCtlTermConnRingingEv irvCTIRD3 User1 invokes call. connect (irvCTIPort2, 8882000, "8889001A@cisco.com") Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 873 Message Sequence Charts CTI Remote Device Use Cases Group 6

Page 937 diagram

Page 938

Call info Events Action CallingAddress = 8882000, CalledAddress = 8889001, CurrentCallingAddress = 8882000, CurrentCalledAddress = 8889001, ModifiedCallingAddress = 8882000, ModifiedCalledAddress = 8889001, No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889001 GC1: CallCtlConnEstablishedEv 8889001 GC1: TermConnActiveEvent irvCTIRD3 GC1: CallCtlTermConnTalkingEv irvCTIRD3 irvCTIRD3's Active remote destination of 916267829523 answers the call. CallingAddress = 8882000, CalledAddress = 8889001, CurrentCallingAddress = 8882000, CurrentCalledAddress = 8889001, ModifiedCallingAddress = 8882000, ModifiedCalledAddress = 8889001, No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIPort2 GC1: CallCtlTermConnDroppedEv irvCTIPort2 GC1: ConnDisconnectedEvent 8882000 GC1: CallCtlConnDisconnectedEv 8882000 GC1: TermConnDroppedEv irvCTIRD3 GC1: CallCtlTermConnDroppedEv irvCTIRD3 GC1: ConnDisconnectedEvent 8889001 GC1: CallCtlConnDisconnectedEv 8889001 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect() the call on 8882000 connection. Scenario 6-2 (Basic Outgoing DVO Call From CTI Remote Device to CTI Port Via URI) A calls B with GC1 as GCID of call. Application is observing both A and B. Call info Events Action CallingAddress = Unknown, CalledAddress = 8889001, CurrentCallingAddress = Unknown, CurrentCalledAddress = 8889001, ModifiedCallingAddress = Unknown, ModifiedCalledAddress = 8889001, No LastRedirectedPartyAddress GC1: CallActiveEvent GC1: ConnCreatedEvent 8889001 GC1: ConnInprogressEvent 8889001 GC1: CallCtlConnOfferedEv 8889001 User1 invokes call. connect (irvCTIRD3, 8889001, "8882000A@cisco.com") Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 874 Message Sequence Charts Message Sequence Charts

Page 938 diagram

Page 939

Call info Events Action CallingAddress = Unknown, CalledAddress 8889001, CurrentCallingAddress = 8889001, CurrentCalledAddress = 8882000, ModifiedCallingAddress = 8889001, ModifiedCalledAddress = 8882000, No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8889001 GC1: CallCtlConnEstablishedEv 8889001 GC1: TermConnCreatedEvent irvCTIRD3 GC1: TermConnActiveEvent irvCTIRD3 GC1: CallCtlTermConnTalkingEv irvCTIRD3 GC1: ConnCreatedEvent 8882000 GC1: ConnInprogressEvent 8882000 GC1: CallCtlConnOfferedEv 8882000 GC1: ConnAlertingEvent 8882000 GC1: CallCtlConnAlertingEv 8882000 GC1: TermConnCreatedEvent irvCTIPort2 GC1: TermConnRingingEvent irvCTIPort2 GC1: CallCtlTermConnRingingEv irvCTIPort2 irvCTIRD3's Active remote destination of 916267829523 answers the call. CallingAddress = Unknown, CalledAddress = 8889001, CurrentCallingAddress = 8889001, CurrentCalledAddress = 8882000, ModifiedCallingAddress = 8889001, ModifiedCalledAddress = 8882000, No LastRedirectedPartyAddress GC1: ConnConnectedEvent 8882000 GC1: CallCtlConnEstablishedEv 8882000 GC1: TermConnActiveEvent irvCTIPort2 GC1: CallCtlTermConnTalkingEv irvCTIPort2 Answer() the call on 8882000 terminal connection. CallingAddress = Unknown, CalledAddress = 8889001, CurrentCallingAddress = 8889001, CurrentCalledAddress = 8882000, ModifiedCallingAddress = 8889001, ModifiedCalledAddress = 8882000, No LastRedirectedPartyAddress GC1: TermConnDroppedEv irvCTIRD3 GC1: CallCtlTermConnDroppedEv irvCTIRD3 GC1: ConnDisconnectedEvent 8889001 GC1: CallCtlConnDisconnectedEv 8889001 GC1: TermConnDroppedEv irvCTIPort2 GC1: CallCtlTermConnDroppedEv irvCTIPort2 GC1: ConnDisconnectedEvent 8882000 GC1: CallCtlConnDisconnectedEv 8882000 GC1: CallInvalidEvent GC1: CallObservationEndedEv Disconnect() the call on 8889001 connection. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 875 Message Sequence Charts Message Sequence Charts

Page 939 diagram

Page 940

CTI RD Call Forward Table 265: Phone A Calls CTIRD When CTI Remote Device Is Observed, Active RD Is Not Set and "Route Calls to All Remote Destinations When Client Is Not Connected" Is Enabled; A - IP Phone, B - CTI-RD, C - RDD1, D - RDD2, E - Enterprise Line Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer Add Call Observer on A, B and E All RDD's will ring CallActiveEv on A, B, E ConnCreatedEv on A, B, E ConnConnectedEv on A CallCtlConnInitiatedEv on A TermConnCreatedEv on A, B, E TermConnActiveEvent on A CallCtlTermConnTalkingEv on A CallCtlConnDialingEv on A CallCtlConnEstablishedEv on A ConnCreatedEv on B ConnInProgressEv on B, E CallCtlConnOfferedEv on B, E ConnAlertingEv on A, B, E CallCtlConnAlertingEv on A, B, E TermConnCreated on Term B TermConnRingingEv on B, E CallCtlTermConnRingingEv on B, E A calls B At Step 3: ConnConnectedEv on B CallCtlConnEstablishedEv on B TermConnActiveEvent on B CallCtlTermConnTalkingEv on B C answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 876 Message Sequence Charts CTI RD Call Forward

Page 940 diagram

Page 941

Call Info Events Action At Step 4: TermConnDroppedEv on A, B, E CallCtlTermConnDroppedEv on A, B, E ConnDisconnectedEv on A, B, E CallCtlConnDisconnectedEv on A, B, E CallInvalidEv CallObservationEndedEv on A, B, E Disconnects the call Table 266: Phone A Calls CTIRD When CTI Remote Device Is Observed, Active RD Is Not Set and "Route Calls to All Remote Destinations When Client Is Not Connected "is Disabled; A - IP Phone, B - CTI-RD, C - RDD1, D - RDD2 Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer Opens only A and no events for B CallActiveEv on A, B, ConnCreatedEv on A, B, ConnConnectedEv on A CallCtlConnInitiatedEv on A TermConnCreatedEv on A, B, TermConnActiveEvent on A CallCtlTermConnTalkingEv on A CallCtlConnDialingEv on A CallCtlConnEstablishedEv on A ConnAlertingEv on A, B, CallCtlConnAlertingEv on A, B, ConnInProgressEv on B CallCtlConnOfferedEv on B TermConnRingingEv on B CallCtlTermConnRingingEv on B GC1: A calls B USER_BUSY on Shared enterprise line ConnFailedEv for A Call will disconnect with message USER_BUSY Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 877 Message Sequence Charts Message Sequence Charts

Page 941 diagram

Page 942

Table 267: Phone A Calls CTIRD When CTI Remote Device Is Observed, Remote Destination Is Not Configured and "Route Calls to All Remote Destinations When Client Is Not Connected" Is Enabled; A- IP Phone, B - CTI-RD. VoiceMail Is Configured Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CallActiveEv on A, B, ConnCreatedEv on A, B ConnConnectedEv on A CallCtlConnInitiatedEv on A TermConnCreatedEv on A, B TermConnActiveEvent on A CallCtlTermConnTalkingEv on A CallCtlConnDialingEv on A CallCtlConnEstablishedEv on A ConnInProgressEv on VoiceMail of B CallCtlConnOfferedEv on VoiceMail of B ConnAlertingEv on VoiceMail of B CallCtlConnAlertingEv on VoiceMail of B GC1: A calls B Call will route to voice mail number Call will Route to Voice mail number Table 268: Phone A Calls CTIRD When CTI Remote Device Is Observed, Remote Destination Is Not Configured and "Route Calls to All Remote Destinations When Client Is Not Connected" Is Disabled; A - IP Phone, B - CTI-RD. VoiceMail Is Configured for B Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer Only A is observed Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 878 Message Sequence Charts Message Sequence Charts

Page 942 diagram

Page 943

Page 943 diagram

Page 944

Call Info Events Action CallActiveEv on A, B ConnCreatedEv on A, B ConnConnectedEv on A CallCtlConnInitiatedEv on A TermConnCreatedEv on A, B TermConnActiveEvent on A CallCtlTermConnTalkingEv on A CallCtlConnDialingEv on A CallCtlConnEstablishedEv on A ConnAlertingEv on A, B CallCtlConnAlertingEv on A, B ConnInProgressEv on B CallCtlConnOfferedEv on B TermConnRingingEv on CallCtlTermConnRingingEv on B A calls B ConnConnectedEv on B CallCtlConnEstablishedEv on B TermConnActiveEvent on B CallCtlTermConnTalkingEv on B C answers the call TermConnDroppedEv on A, B CallCtlTermConnDroppedEv on A, B ConnDisconnectedEv on A, B CallCtlConnDisconnectedEv on A, B CallObservationEndedEv on A, B C Disconnects the call Table 270: Phone A Calls CTIRD When CTI Remote Device Is Observed, Active RD Is Set and "Route Calls to All Remote Destinations When Client Is Not Connected" Is Disabled; A IP Phone, B CTI-RD, C RDD1, D RDD2 Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer Applications adds C as the active remote destination on B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 880 Message Sequence Charts Message Sequence Charts

Page 944 diagram

Page 945

Call Info Events Action CallActiveEv on A, B ConnCreatedEv on A, B ConnConnectedEv on A CallCtlConnInitiatedEv on A TermConnCreatedEv on A, B TermConnActiveEvent on A CallCtlTermConnTalkingEv on A CallCtlConnDialingEv on A CallCtlConnEstablishedEv on A ConnAlertingEv on A, B, CallCtlConnAlertingEv on A, B ConnInProgressEv on B CallCtlConnOfferedEv on B TermConnRingingEv on B CallCtlTermConnRingingEv on B A calls B ConnConnectedEv on B CallCtlConnEstablishedEv on B TermConnActiveEvent on B CallCtlTermConnTalkingEv on B C answers the call TermConnDroppedEv on A, B CallCtlTermConnDroppedEv on A, B ConnDisconnectedEv on A, B CallCtlConnDisconnectedEv on A, B CallObservationEndedEv on A, B C Disconnects the call Table 271: Phone A Calls CTIRD When CTI Remote Device Is Observed, Active RD Is Not Set and "Route Calls to All Remote Destinations When Client Is Not Connected" Is Enabled; A - IP Phone, B - CTI-RD, C - RDD1, D - RDD2, E - Enterprise Line Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer Add Call Observer on A, B and E Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 881 Message Sequence Charts Message Sequence Charts

Page 945 diagram

Page 946

Call Info Events Action All RDD will ring CallActiveEv on A, B, E ConnCreatedEv on A, B, E ConnConnectedEv on A CallCtlConnInitiatedEv on A TermConnCreatedEv on A, B, E TermConnActiveEvent on A CallCtlTermConnTalkingEv on A CallCtlConnDialingEv on A CallCtlConnEstablishedEv on A ConnAlertingEv on A, B, E CallCtlConnAlertingEv on A, B, E ConnInProgressEv on B, E CallCtlConnOfferedEv on B, E TermConnRingingEv on B, E CallCtlTermConnRingingEv on B, E A calls B ConnConnectedEv on B CallCtlConnEstablishedEv on B TermConnActiveEvent on B CallCtlTermConnTalkingEv on B C answers the call TermConnDroppedEv on A, B, E CallCtlTermConnDroppedEv on A, B, E ConnDisconnectedEv on A, B, E CallCtlConnDisconnectedEv on A, B, E CallObservationEndedEv on A, B, E C Disconnects the call Table 272: Phone A Calls CTIRD When CTI Remote Device Is Observed, Active RD Is Not Set and "Route Calls to All Remote Destinations When Client Is Not Connected "is Disabled; A - IP Phone, B - CTI-RD, C - RDD1, D - RDD2 Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer Add Call Observers on A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 882 Message Sequence Charts Message Sequence Charts

Page 946 diagram

Page 947

Call Info Events Action All RDD will ring CallActiveEv on A, B, ConnCreatedEv on A, B, ConnConnectedEv on A CallCtlConnInitiatedEv on A TermConnCreatedEv on A, B, TermConnActiveEvent on A CallCtlTermConnTalkingEv on A CallCtlConnDialingEv on A CallCtlConnEstablishedEv on A ConnAlertingEv on A, B, CallCtlConnAlertingEv on A, B, ConnInProgressEv on B CallCtlConnOfferedEv on B TermConnRingingEv on B CallCtlTermConnRingingEv on B A calls B USER_BUSYon Shared enterprise line call will disconnect with message USER_BUSY Table 273: Phone A Calls CTIRD When CTI Remote Device Is Observed, Remote Destination Is Not Configured and "Route Calls to All Remote Destinations When Client Is Not Connected" Is Enabled; A - IP Phone, B - CTI-RD, C - RDD1, D - RDD2 Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer Add Call Observers on A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 883 Message Sequence Charts Message Sequence Charts

Page 947 diagram

Page 948

Call Info Events Action CallActiveEv on A, B, ConnCreatedEv on A, B ConnConnectedEv on A CallCtlConnInitiatedEv on A TermConnCreatedEv on A, B TermConnActiveEvent on A CallCtlTermConnTalkingEv on A CallCtlConnDialingEv on A CallCtlConnEstablishedEv on A ConnAlertingEv on A, B CallCtlConnAlertingEv on A, B ConnInProgressEv on B CallCtlConnOfferedEv on B TermConnRingingEv on B CallCtlTermConnRingingEv on B A calls B Call will route to voice mail number Call will Route to Voice mail number Table 274: Phone A Calls CTIRD When CTI Remote Device Is Observed, Remote Destination Is Not Configured and "Route Calls to All Remote Destinations When Client Is Not Connected" Is Disabled; A - IP Phone, B - CTI-RD, C - RDD1, D - RDD2 Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer Add Call Observers on A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 884 Message Sequence Charts Message Sequence Charts

Page 948 diagram

Page 949

Call Info Events Action CallActiveEv on A, B ConnCreatedEv on A, B ConnConnectedEv on A CallCtlConnInitiatedEv on A TermConnCreatedEv on A, B TermConnActiveEvent on A CallCtlTermConnTalkingEv on A CallCtlConnDialingEv on A CallCtlConnEstablishedEv on A ConnAlertingEv on A, B, C CallCtlConnAlertingEv on A, B ConnInProgressEv on B CallCtlConnOfferedEv on B TermConnRingingEv on B CallCtlTermConnRingingEv on B A calls B Call will route to voice mail number Call will Route to Voice mail number CTI Video Support Use cases related to CTI Video Support feature are mentioned below: Scenario 1: Phone A is video capable, telepresence capable, with 1 screen and a camera, and in registered state. User1 has phone A in the control list. User invokes CiscoTerminal.getCiscoMultiMediaCapabilityInfo().getVideoCapability() before opening the device. Call info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer termA. getCiscoMultiMediaCapabilityInfo().getVideoCapability() = VIDEO_ENABLED User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () = TELEPRESENCEINTEROP_ENABLED User1 invokes CiscoTerminal.i getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () on termA Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 885 Message Sequence Charts CTI Video Support

Page 949 diagram

Page 950

Call info Events Action termA. getCiscoMultiMediaCapabilityInfo(). getScreenCount () = 1 User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getScreenCount () on termA Scenario 2 Phone A is not video capable, not telepresence capable with 0 screens. User1 has phone A in the control list. The user invokes CiscoTerminal.getCiscoMultiMediaCapabilityInfo().getVideoCapability() before opening device Call info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer termA. getCiscoMultiMediaCapabilityInfo().getVideoCapability() = NONE User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () = TELEPRESENCEINTEROP_NONE User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () on termA termA. getCiscoMultiMediaCapabilityInfo(). getScreenCount () = 0 User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getScreenCount () on termA Scenario 3 Phone A is video capable, telepresence capable, with 1 screen and a camera. User1 has phone A in the control list. The user invokes CiscoTerminal.getCiscoMultiMediaCapabilityInfo().getVideoCapability() after opening the device. Call info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = NONE CiscoTermOutOfServiceEv CiscoTermInServiceEv User1 opens termA termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = VIDEO_ENABLED User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () = TELEPRESENCEINTEROP_ENABLED User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () on termA Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 886 Message Sequence Charts Message Sequence Charts

Page 950 diagram

Page 951

Call info Events Action termA. getCiscoMultiMediaCapabilityInfo(). getScreenCount () = 1 User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getScreenCount () on termA Scenario 4 Phone A is video not capable, not telepresence capable with 0 screens. User1 has phone A in the control list. The user invokes CiscoTerminal.getCiscoMultiMediaCapabilityInfo().getVideoCapability() after opening the device. Call info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscoTermOutOfServiceEv CiscoTermInServiceEv User1 opens termA termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = NONE User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () = TELEPRESENCEINTEROP_NONE User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () on termA termA. getCiscoMultiMediaCapabilityInfo(). getScreenCount () = 0 User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getScreenCount () on termA Scenario 5 Phone A is video capable, telepresence capable, with 1 screen and a camera. User1 does not have phone A in the control list. User1 has Super provider capabilities. Call info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscoTermCreatedEv TermA CiscoAddrCreatedEv A User1 aquires phone A using prov.createTerminal("phoneA") termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = VIDEO_ENABLED User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 887 Message Sequence Charts Message Sequence Charts

Page 951 diagram

Page 952

Call info Events Action termA. getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () = TELEPRESENCEINTEROP_ENABLED User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () on termA termA. getCiscoMultiMediaCapabilityInfo(). getScreenCount () = 1 User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getScreenCount () on termA Scenario 6 Phone A is not video capable, not telepresence capable and has 0 screens. User1 does not have phone A in the control list. User1 has Super provider capabilities Call info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscoTermCreatedEv TermA CiscoAddrCreatedEv A User1 aquires phone A using prov.createTerminal("phoneA") termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = NONE User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () = TELEPRESENCEINTEROP_NONE User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () on termA termA. getCiscoMultiMediaCapabilityInfo(). getScreenCount () = 0 User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getScreenCount () on termA Scenario 7 Phone A is a CTI Port or RoutePoint. User1 has phone A in the control list. The user invokes CiscoTerminal.getCiscoMultiMediaCapabilityInfo().getVideoCapability(). Call info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscoTermOutOfServiceEv CiscoTermInServiceEv User1 opens termA and registeres it The API returns MethodNotSupportedException - Not supported on Media Terminals and RPs and Remote Terminals User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 888 Message Sequence Charts Message Sequence Charts

Page 952 diagram

Page 953

Call info Events Action The API returns MethodNotSupportedException - Not supported on Media Terminals and RPs and Remote Terminals User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo () on termA The API returns MethodNotSupportedException - Not supported on Media Terminals and RPs and Remote Terminals User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getScreenCount () on termA Scenario 8 Basic Video call: Phone A is video enabled, telepresence enabled with 1 screen. Phone B is video disabled , telepresence disabled with 0 screens. Both the phones are in the control list of User1. Call info Events Action ProvInServiceEv User Opens provider and adds observer CiscoTermInServiceEv TermA CiscotermInServiceEv TermB User adds terminal observers on Phone A and Phone B CiscoAddrInServiceEv A CiscoAddrInServiceEv B User adds callObserves on the address A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 889 Message Sequence Charts Message Sequence Charts

Page 953 diagram

Page 954

Call info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1 CallCtlTermConnRingingEvImpl B User makes a call from A to B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 890 Message Sequence Charts Message Sequence Charts

Page 954 diagram

Page 955

Call info Events Action The API returns 1, indicating video capable device( VIDEO_ENABLED) for TermA( far-end party). App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getVideoCapability() on GC1 The API returns 1, indicating telepresence capable device(TELEPRESENCEINTEROP_ENABLED) for TermA( far-end party). App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getTelepresenceInfo() on GC1 The API returns 1, indicating device has 1 screen, for TermA( far-end party). App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo. getScreenCount() on GC1 The API returns 0, indicating video capable device( NONE) for Term B App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1 The API returns 1, indicating device is not telepresence capable (TELEPRESENCEINTEROP_NONE) for TermA( far-end party). App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getTelepresenceInfo() on GC1 The API returns 1, indicating device has 0 screens, for TermA( far-end party). App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo .getScreenCount() on GC1 Scenario 9 Phone A is video disabled ( in CUCM Admin Phone page, the Video Capabilities field is 'Disabled' ) , but the device has an an external camera (USB or CUVA) plugged in. Phone A is in registered state. Call info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = NONE User1 invokes CiscoTerminal. getCiscoMulti MediaCapabilityInfo(). getVideoCapability() on termA Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 891 Message Sequence Charts Message Sequence Charts

Page 955 diagram

Page 956

Call info Events Action termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = VIDEO_ENABLED CiscoProvTerminalMultiMedia CapabilityChangedEv In Device Configuration CUCM Admin pages- Video Capabilities field is changed to'Enabled' No event is delivered, as the device is still a video capable device as it can receive video The external camera is removed, or the Cisco Camera field in CUCM Admin Phone page is 'Disabled' termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = VIDEO_ENABLED User1 invokes CiscoTerminal. getCiscoMulti MediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = NONE CiscoProvTerminalMultiMedia CapabilityChangedEv In Device Configuration CUCM Admin pages- Video Capabilities field is changed to'Disabled' Device and Line Restriction Events Scenario S.No Application has Devices T1, T2, T3 whose lines are A1, A2, A3 in the control list. T1 and A3 is added into the restricted list. Application opens the provider 1 CiscoTerminal.isRestricted() returns true for T1 and false for T2 and T3 Application queries for is Restricted on T1, T2, T3 CiscoAddress.isRestricted() returns true for A1, A3, false for A2. Application queries for is Restricted on Address A1, A2, A3 CiscoAddress.getRestrictedAddrTerminals() on A1, A3 returns T1, T3 respectively, returns null for A2. addObserver and addCallObserver fails for T1, A1, A3. For T3 observer is added, but no events are received on A3. For A2, application will be able to add observers successfully and events will be received Application tries to addObserver and addCallObserver on T1, T2, T3, A1, A2, A3 Application has Devices T1, T2, T3 whose lines are A1, A2, A3 in the control list. 2 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 892 Message Sequence Charts Device and Line Restriction

Page 956 diagram

Page 957

Events Scenario S.No CiscoTermRestrictedEv for T1 CiscoAddrRestrictedEv for L1 CiscoAddrRestrictedEv for A2 sent to providerObserver. Application opens the provider and adds observer on all terminals and addresses. CiscoTermOutOfServiceEv for T1 CiscoAddrOutOfServiceEv for L1 CiscoAddrOutOfServiceEv for A2 T1 and A2 are added to the restrictedlist. CiscoTermActivatedEv for T1 and CiscoAddrActivatedEv for A1 CiscoAddrActivatedEv for A2 sent to providerObserver. CiscoTermInServiceEv for T1 and CiscoAddrInServiceEv for A1 CiscoAddrInServiceEv for A2 sent to terminal and address observers. T1 and L2 are removed from restricted list Application has Devices T1, T2, T3 whose lines are A1, A1, A2 in the control list. A1 is the shared line on T1 and T2 3 Application opens provider and adds observer on all terminals/addresses Application will see CiscoTermRestrictedEv for T1 and CiscoAddrRestrictedOnTerminalEv which contains getAddress is L1 and getTerminal as T1. Application will also see CiscoTermOutOfServiceEv for T1 and CiscoAddrOutOfService for A1/T1 T1 is added into the restricted list. CiscoTermActivatedEv for T1 CiscoAddrActivatedEv for L1 CiscoTermInServiceEv for T1 CiscoAddrInServiceEv for A1/T1 T1 is removed from the restricted list Application has Devices T1, T2, T3 whose lines are A1, A1, A1 in the control list. A1 is the shared line on T1, T2 and T3 4 Application opens the provider and adds observer on all terminals and addresses CiscoAddrRestrictedOnTerminalEv for A1/T1 CiscoAddrOutOfServiceEv for A1/T1 A1 on T1 is added to the restricted list CiscoAddrRestrictedOnTerminalEv for A1/T2 CiscoAddrOutOfServiceEv for A1/T2 A1 on T2 is added to therestricted list CiscoAddrRestrictedEv for A1 CiscoAddrOutOfServiceEv for A1/T3 A1 on T3 is added to therestricted list Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 893 Message Sequence Charts Message Sequence Charts

Page 957 diagram

Page 958

Events Scenario S.No CiscoAddrActivatedOnTerminalEv for A1/T1 CiscoAddrInServiceEv for A1/T1 A1 on T1 is removed from the restricted list CiscoAddrActivatedOnTerminalEv for A1/T2 CiscoAddrInServiceEv for A1/T2 A1 on T2 is removed from the restricted list CiscoAddrActivatedEv for A1 CiscoAddrInServiceEv for A1/T3 A1 on T3 is removed from the restricted list Application has Devices T1, T2, T3 whose lines are A1, A2, A3 in the control list. 5 CiscoAddrRestrictedEv for A1 CiscoAddrOutOfServiceEv for A1 Application opens the provider and adds observer on all terminals and addresses. A1 is involved in a call with party X. A1 is added into the restricted list. ConnDisconnectedEv CallCtlConnDisconnectedEv TermConnDroppedEv CallCtlConnDroppedEv CallInvalidEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 894 Message Sequence Charts Message Sequence Charts

Page 958 diagram

Page 959

Device State Server Do Not Disturb Configuration: Application is observing terminal A and terminal B. Scenario One Application adds Terminal observer to terminal A using Terminal.addObserver(). Filter is enabled via setDNDChangedEvFilter. DND is enabled on the terminal. Application invokes getDNDStatus() from CiscoTerminal. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 895 Message Sequence Charts Device State Server

Image 1 from page 959

Page 959 content

Page 960

Call info Events Action N.A NEW META EVENT_________ META_CALL_STARTING CiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: true DND status = true is returned to the application Application adds terminal observer to terminal A. Filter is enabled via setDNDChangedEvFilter() in CiscoTermEvFilter. DND is enabled on the terminal through phone or admin page. Application invokes getDNDStatus() from CiscoTerminal. Scenario Two Application enables filter to receive events. Application adds Terminal observer to terminal A using Terminal.addObserver(). DND is enabled on the terminal. Application invokes getDNDStatus() from CiscoTerminal. Call info Events Action N.A NEW META EVENT_________META_CALL_STARTING CiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: true DND status = true is returned to the application Application enables filter to receive events. Application adds terminal observer to terminal A. DND is enabled on the device through phone or admin pages. Application invokes getDNDStatus() from CiscoTerminal. Scenario Three Application adds Terminal observer to terminal A using Terminal.addObserver(). Filter is disabled via setDNDChangedEvFilter() in CiscoTermEvFilter. Application invokes getDNDStatus() from CiscoTerminal. Call info Events Action N.A CiscoTermDNDStatusChangedEv is not delivered to application. Application adds Terminal observer to terminal A using Terminal.addObserver(). Filter is disabled via setDNDChangedEvFilter() in CiscoTermEvFilter. Application invokes getDNDStatus() from CiscoTerminal. Scenario Four Application does not add Terminal observer to terminal. Application invokes getDNDStatus() from CiscoTerminal. Call info Events Action N.A InvalidStateException is thrown Application does not add Terminal observer to terminal. Application invokes getDNDStatus() from CiscoTerminal. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 896 Message Sequence Charts Message Sequence Charts

Page 960 diagram

Page 961

Scenario Five Application does not enable the filter to receive events. Application adds Terminal observer to terminal A. DND status is set to true through the phone or admin pages. Application now enables the filter to receive events. Application invokes getDNDStatus() from CiscoTerminal. Call info Events Action N.A CiscoTermDNDStatusChangedEv is not delivered to application. NEW META EVENT_________ META_CALL_STARTING CiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: true DND status = true is returned to application Application does not enable the filter to receive events.Application adds Terminal observer to terminal A. DND status is set to true through the phone or admin pages. Application now enables the filter to receive events Application invokes getDNDStatus() from CiscoTerminal. Scenario Six Application sets DND status to false by invoking the setDNDStatus() interface on CiscoTerminal. Call info Events Action N.A NEW META EVENT_________ META_CALL_STARTING CiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: false Application invokes setDNDStatus() from CiscoTerminal. Scenario Seven Application 1 and Application 2 are observing terminal a, and both the applications have enabled the filter to receive events. Application 1 sets DND status to false on Terminal A. Application 2 is observing Terminal A. Call info Events Action N.A NEW META EVENT_________ META_CALL_STARTING CiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: false Application invokes setDNDStatus() from CiscoTerminal. Scenario Eight DND Type is RingerOff and CFNA is not set. Terminal B calls Terminal A. Call is presented to A and call is not answered. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 897 Message Sequence Charts Message Sequence Charts

Page 961 diagram

Page 962

Call info Events Action N.A Call is presented to the device, irrespective of the DND settings on the device. CER call overrides DND setting. Application invokes redirect() API with feature priority set to 3 from CiscoCall. N.A Call is presented to the device, irrespective of the DND settings on the device. CER call overrides DND setting. Application invokes selectRoute() API with feature priority set to 3 from CiscoRouteSession. Scenario Nine Call info Events Action N.A ConnFailedEv Cause: CAUSE_NO ANSWER DND Type is RingerOff and CFNA is not set. Terminal B calls Terminal A .Call is presented to A and call is not answered. Scenario Ten DND Type is CallReject and CFB is not set. Terminal B calls Terminal A. Call is not presented to A. Call info Events Action N.A ConnFailedEv Cause: CAUSE_USER BUSY DND Type is CallReject and CFB is not set. Terminal B calls Terminal A. Call is not presented to A Scenario Eleven DND is enabled on the terminal A. Terminal A comes IN_SERVICE. Application invokes getDNDStatus() on CiscoTerm in ServiceEv. Call info Events Action N.A CiscoTermInServiceEv Cause: CAUSE_NORMAL DND Status = true DND is enabled on the terminal A. Terminal A comes IN_SERVICE. Scenario Twelve DND is enabled on terminal A. Terminal A comes IN_SERVICE. Application invokes setDNDStatus(). DB failure happens after the setDNDStatus() request is sent. Call info Events Action N.A PlatformException is thrown “Could not meet post conditions of setDNDStatus()” No CiscoTermDNDStatusChangedEv is received. DND is enabled on the terminal A. Terminal A comes IN_SERVICE. Application invokes setDNDStatus(). DB failure follows and value is not updated in DB. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 898 Message Sequence Charts Message Sequence Charts

Page 962 diagram

Page 963

Scenario Thirteen DND is enabled on the terminalA. Terminal A comes IN_SERVICE, DND status is currently true in phone/admin. Application tries to set the same value i.e. invokes setDNDStatus(true). Call info Events Action N.A InvalidStateException is caught: DND status with value true is already set No CiscoTermDNDStatusChangedEv is received. DND is enabled on the terminal A. Terminal A comes IN_SERVICE.DND status is currently true in phone/admin.Application tries to set the same value i.e. invokes setDNDStatus(true). DND-R Scenario One Application adds Terminal observer to terminal A using Terminal.addObserver (). DND-R is enabled on the terminal B via the Admin page or the Common profile page. Call info Events Action N.A NEW META EVENT_________ META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL ConnFailedEv B Cause:. Cause: CAUSE_USERBUSY. Application adds terminal observers to terminal A and B. DND-R is enabled on the terminal B through phone or admin page. A issues Call.connect to B with the feature Priority = 1 (Normal) Scenario Two Application adds Terminal observer to terminal A using Terminal.addObserver (). DND-R is enabled on the Terminal B via the Admin page or the Common profile page. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 899 Message Sequence Charts DND-R

Page 963 diagram

Page 964

Call info Events Action Calling: A Called: B NEW META EVENT_________ META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause: CAUSE_NORMAL TernConnActiveEv for A Cause:CAUSE_NORMAL CallCtlConnDialingEv for A Cause: CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL ConnCreatedEv for B cause:CAUSE_NORMAL ConnInProgressEv for B Cause:CAUSE_NORMAL CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL ConnAlertingEv for B Cause:CAUSE_NORMAL CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause: CAUSE_NORMAL TermConnRingingEv for B Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL Application adds terminal observers to terminal A and B. DND-R is enabled on the terminal B through phone or admin page. A issues Call.connect to B with the feature Priority = 3 (Emergency) Scenario Three DND-Call reject with CFB not set. Call info Events Action NA NEW META EVENT_________ META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause:CAUSE_NORMAL ConnConnectedEv for A Cause:CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause:CAUSE_NORMAL ConnFailedEv B Cause:CAUSE_USERBUSY. Application adds terminal observers to terminal A and B. DND-R is enabled on the terminal B through phone or admin page with no CFB Setting. Terminal A issues Call.connect to Terminal B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 900 Message Sequence Charts Message Sequence Charts

Page 964 diagram

Page 965

Scenario Four DND – Call reject with CFB set to C. Call info Events Action Calling: A Called: C LastRedirectedParty: B NEW META EVENT_________ META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause:CAUSE_NORMAL ConnConnectedEvfor A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause: CAUSE_NORMAL TernConnActiveEv for A Cause: CAUSE_NORMAL CallCtlConnDialingEv for A Cause: CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL ConnCreatedEv for C cause: REDIRECTED CALL ConnInProgressEv for C Cause: REDIRECTED CALL CallCtlConnOfferedEv for C Cause: REDIRECTED CALL ConnAlertingEv for C Cause REDIRECTED CALL CallCtlConnAlertingEv for C Cause: REDIRECTED CALL TermConnCreatedEv for C Cause: REDIRECTED CALL TermConnRingingEv for C Cause: REDIRECTED CALL CallCtlTermConnTalkingEv Cause: CAUSE_REDIRECTED Application is Observing Terminal A, B & C. DND-R is Enabled in Terminal B with CFB set to Terminal C. Terminal A issues Call.connect to Terminal B. Call is not Presented on Terminal B and is Forwarded to Terminal C. Dynamic CTIPort Registration Per Call The following diagram illustrates the message flows for Dynamic CTIPort Registration per call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 901 Message Sequence Charts Dynamic CTIPort Registration Per Call

Page 965 diagram

Page 966

E911 Teleworker SelectRoute Method Call info Events Use Case No changes in the callinfo No changes in the events No changes in use case with selectRoute Method Redirect Method Call info Events Use Case No changes in the callinfo No changes in the events No changes in use case with redirect Method Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 902 Message Sequence Charts E911 Teleworker

Image 1 from page 966

Page 966 diagram

Page 967

Encryption Enhancement Table 275: Service Parameter "Require Public Key Encryption" Is Set to "False". Application Is Using a Pre 10.x CiscoJTAPI Version Info Result Action ProvInServiceEv Application opens a provider and adds a provider observer Table 276: Service Parameter "Require Public Key Encryption" Is Set to "True". Application Is Using a Pre 10.x CiscoJTAPI Version Info Result Action getErrorCode() = CiscoJtapiException. INCOMPATIBLE_PROTOCOL_ VERSION PlatformException Application opens a provider Table 277: Service Parameter "Require Public Key Encryption" Is Set to "False". Application Is Using a 10.x CiscoJTAPI Version Info Result Action ProvInServiceEv Application opens a provider and adds a provider observer Table 278: Service Parameter "Require Public Key Encryption" Is Set to "True". Application Is Using a 10.x CiscoJTAPI Version Info Result Action ProvInServiceEv Application opens a provider and adds a provider observer Table 279: SP Is Set to "True". Application Is Using 10.x CiscoJTAPI Lib. Application Has Provided Pub and Sub Ctimanager IP in the ProviderString Info Result Action ProvInServiceEv Application opens a provider and adds a provider observer ProvOutOfService CTIManager on the server to which app is connected goes down Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 903 Message Sequence Charts Encryption Enhancement

Page 967 diagram

Page 968

End to End Call Tracing Call info Events Actions ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID1 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(TB) returns ID1 ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(term) will throw InvalidStateException GC1: CallActiveEv GC1: ConnCreatedEv for B GC1: ConnConnectedEv for B GC1: CallCtlConnOfferedEv for B GC1: ConnCreatedEv for A GC1: ConnConnectedEv for A … … GC1: TermConnCreatedEv for TB GC1: TermConnActiveEvent for TB GC1: CallCtlTermConnTalkingEv for TB 1.a) Both A and B are in user’s control list. Basic Call A calls B; App is observing only B ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID1 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(TB) returns ID1 ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(term) will throw PrivilegeViolationException GC1: CallActiveEv GC1: ConnCreatedEv for B GC1: ConnConnectedEv for B GC1: CallCtlConnOfferedEv for B GC1: ConnCreatedEv for A GC1: ConnConnectedEv for A …… …… GC1: TermConnCreatedEv for TB GC1: TermConnActiveEvent for TB GC1: CallCtlTermConnTalkingEv for TB 1.b) Only B is in User’s control list Basic Call A calls B; App is observing only B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 904 Message Sequence Charts End to End Call Tracing

Page 968 diagram

Page 969

Call info Events Actions ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(null) returns ID2 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID3 ( (CiscoConnection)(ConnCreatedEv for C).getConnection() ).getUniqueID(null) returns ID4 GC1: CallActiveEv GC1: ConnCreatedEv for A GC1: CallCtlConnInitiatedEv for A GC1: TermConnCreatedEv for TA GC1: TermConnActiveEvent for TA GC1: CallCtlTermConnTalkingEv for TA GC1: ConnCreatedEv for B GC1: ConnConnectedEv for B GC1: CallCtlConnOfferedEv for B GC1: TermConnCreatedEv for TB GC1: ConnCreatedEv for C GC1: ConnConnectedEv for C GC1: CallCtlConnOfferedEv for C GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B GC1: CallCtlConnDisconnectedEv for B GC1: TermConnCreatedEv for TC GC1: TermConnActiveEvent for TC GC1: CallCtlConnEstablishedEv for C GC1: CallCtlTermConnTalkingEv for TC 2.a) Redirect in offering state Scenario All Observed A calls B; B redirects the call to C in offering state C Accepts the call C answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 905 Message Sequence Charts Message Sequence Charts

Page 969 diagram

Page 970

Call info Events Actions ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(null) returns ID6 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID7 ( (CiscoConnection)(ConnCreatedEv for C).getConnection() ).getUniqueID(null) returns ID8 GC1: CallActiveEv GC1: ConnCreatedEv for A GC1: ConnConnectedEv for A GC1: CallCtlConnInitiatedEv for A GC1: TermConnCreatedEv for TA GC1: TermConnActiveEvent for TA GC1: CallCtlTermConnTalkingEv for TA GC1: ConnCreatedEv for B GC1: ConnConnectedEv for B GC1: CallCtlConnOfferedEv for B GC1: TermConnCreatedEv for TB GC1: ConnConnectedEv for A GC1: CallCtlConnEstablishedEv for A GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B GC1: ConnCreatedEv for C GC1: ConnConnectedEv for C GC1: CallCtlConnOfferedEv for C GC1: TermConnCreatedEv for TC GC1: TermConnActiveEvent for TC GC1: CallCtlTermConnTalkingEv for TC GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B GC1: CallCtlConnDisconnectedEv for B 2.b) Redirect in connected state Scenario All Observed A calls B B answers B redirects the call to C in connected state Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 906 Message Sequence Charts Message Sequence Charts

Page 970 diagram

Page 971

Call info Events Actions ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID10 ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(null) throws InvalidStateException ( (CiscoConnection)(ConnCreatedEv for C).getConnection() ).getUniqueID(null) returns ID11 GC1: CallActiveEv GC1: ConnCreatedEv for B GC1: ConnConnectedEv for B GC1: CallCtlConnOfferedEv for B GC1: ConnCreatedEv for A GC1: ConnConnectedEv for A GC1: TermConnCreatedEv for TB GC1: TermConnActiveEvent for TB GC1: CallCtlConnEstablishedEv for A GC1: CallCtlConnEstablishedEv for B GC1: CallCtlTermConnTalkingEv for TB GC1: ConnCreatedEv for C GC1: ConnConnectedEv for C GC1: CallCtlConnOfferedEv for C GC1: TermConnCreatedEv for TC GC1: TermConnActiveEvent for TC GC1: CallCtlTermConnTalkingEv for TC GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B GC1: CallCtlConnDisconnectedEv for B 3. Redirect Scenario Only B & C are Observed A calls B; B answers B redirects the call to C in connected state Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 907 Message Sequence Charts Message Sequence Charts

Page 971 diagram

Page 972

Call info Events Actions ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(null) returns ID12 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID13 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID14 ( (CiscoConnection)(ConnCreatedEv for C).getConnection() ).getUniqueID(null) returns ID15 ( (CiscoConnection)(ConnCreatedEv for C).getConnection() ).getUniqueID(null) returns ID16 4. Conference Scenario; All observed GC1: A calls B; B answers GC2: B calls C; C answers GC1.conference(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 908 Message Sequence Charts Message Sequence Charts

Page 972 diagram

Page 973

Call info Events Actions GC1: CallActiveEv GC1: ConnCreatedEv for A GC1: ConnConnectedEv for A GC1: CallCtlConnInitiatedEv for A GC1: TermConnCreatedEv for TA GC1: TermConnActiveEvent for TA GC1: CallCtlTermConnTalkingEv for TA GC1: ConnCreatedEv for B GC1: ConnConnectedEv for B GC1: CallCtlConnOfferedEv for B GC1: TermConnCreatedEv for TB GC1: ConnConnectedEv for A GC1: CallCtlConnEstablishedEv for A GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B GC1: CallCtlTermConnHeldEv for TB GC2: CallActiveEv GC2: ConnCreatedEv for B GC2: ConnConnectedEv for B GC2: CallCtlConnInitiatedEv for B GC2: TermConnCreatedEv for TB GC2: TermConnActiveEvent for TB GC2: CallCtlTermConnTalkingEv for TB GC2: ConnCreatedEv for C GC2: ConnConnectedEv for C GC2: CallCtlConnOfferedEv for C GC2: TermConnCreatedEv for TC GC2: ConnConnectedEv for B GC2: CallCtlConnEstablishedEv for B GC2: ConnConnectedEv for C GC1: CiscoConferenceStartEv GC1: CiscoCallFeatureCancelledEv GC2: CiscoCallChangedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 909 Message Sequence Charts Message Sequence Charts

Page 973 diagram

Page 974

Call info Events Actions GC1: ConnCreatedEvent for C GC1: ConnConnectedEvent for C GC1: CallCtlConnEstablishedEv for C GC1: TermConnCreatedEvent for TC GC1: TermConnActiveEvent for TC GC1: CallCtlTermConnTalkingEv TC GC2: TermConnDroppedEv for TC GC2: CallCtlTermConnDroppedEv for TC GC2: ConnDisconnectedEvent for C GC2: CallCtlConnDisconnectedEv for C GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEvent for B2 GC2: CallCtlConnDisconnectedEv for B2 GC2: CallInvalidEvent GC1: CiscoConferenceEndEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 910 Message Sequence Charts Message Sequence Charts

Page 974 diagram

Page 975

Call info Events Actions ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(null) returns ID19 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID20 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID21 ( (CiscoConnection)(ConnCreatedEv for C).getConnection() ).getUniqueID(null) returns ID22 ( (CiscoConnection)(ConnCreatedEv for C).getConnection() ).getUniqueID(null) returns ID23 5. Transfer Scenario; All observed GC1: A calls B; B answers GC2: B calls C; C answers GC1.transfer(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 911 Message Sequence Charts Message Sequence Charts

Page 975 diagram

Page 976

Call info Events Actions GC1: CallActiveEv GC1: ConnCreatedEv for A GC1: ConnConnectedEv for A GC1: CallCtlConnInitiatedEv for A GC1: TermConnCreatedEv for TA GC1: TermConnActiveEvent for TA GC1: CallCtlTermConnTalkingEv for TA GC1: ConnCreatedEv for B GC1: ConnConnectedEv for B GC1: CallCtlConnOfferedEv for B GC1: TermConnCreatedEv for TB GC1: ConnConnectedEv for A GC1: CallCtlConnEstablishedEv for A GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B GC1: CallCtlTermConnHeldEv for TB GC2: CallActiveEv GC2: ConnCreatedEv for B GC2: ConnConnectedEv for B GC2: CallCtlConnInitiatedEv for B GC2: TermConnCreatedEv for TB GC2: TermConnActiveEvent for TB GC2: CallCtlTermConnTalkingEv for TB GC2: ConnCreatedEv for C GC2: ConnConnectedEv for C GC2: CallCtlConnOfferedEv for C GC2: TermConnCreatedEv for TC GC2: ConnConnectedEv for B GC2: CallCtlConnEstablishedEv for B GC2: ConnConnectedEv for C GC2: CallCtlConnEstablishedEv for C GC1: CiscoTransferStartEv GC2: CiscoCallChangedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 912 Message Sequence Charts Message Sequence Charts

Page 976 diagram

Page 977

Call info Events Actions GC1: ConnCreatedEv for C GC1: ConnConnectedEv for C GC1: CallCtlConnEstablishedEv for C GC1: TermConnCreatedEv for TC GC1: TermConnActiveEvent for TC GC1: CallCtlTermConnTalkingEv for TC GC2: TermConnDroppedEv for TC GC2: CallCtlTermConnDroppedEv for TC GC2: ConnDisconnectedEv for C GC2: CallCtlConnDisconnectedEv for C GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B GC1: CallCtlConnDisconnectedEv for B GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEv for B GC2: CallCtlConnDisconnectedEv for B GC2: CallInvalidEvent GC2: CallObservationEndedEv GC1: CiscoTransferEndEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 913 Message Sequence Charts Message Sequence Charts

Page 977 diagram

Page 978

Call info Events Actions ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(TA) returns ID25 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID26 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(T1) returns ID26 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(T2) returns ID26 (Connection of B).getUniqueID(null) returns returns ID26 (Connection of B).getUniqueID(T1) returns returns ID26 (Connection of B).getUniqueID(T2) returns returns ID26 GC1: CallActiveEv GC1: ConnCreatedEv for A GC1: ConnConnectedEv for A GC1: CallCtlConnInitiatedEv for A GC1: TermConnCreatedEv for TA GC1: TermConnActiveEvent for TA GC1: CallCtlTermConnTalkingEv for TA GC1: CallCtlConnDialingEv for A GC1: CallCtlConnEstablishedEv for A GC1: ConnCreatedEv for B GC1: ConnInProgressEv for B GC1: CallCtlConnOfferedEv for B GC1: ConnAlertingEv for B GC1: TermConnCreatedEv for T1B GC1: TermConnRingingEv for T1B GC1: CallCtlTermConnRingingEv for T1B GC1: TermConnCreatedEv for T2B GC1: TermConnRingingEv for T2B GC1: CallCtlTermConnRingingEv for T2B GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B GC1: TermConnActiveEv for T1B GC1: CallCtlTermConnTalkingEv for T1B GC1: TermConnPassiveEv for T2B GC1: CallCtlTermConnBridgedEv 6. Shared Line Scenario; All Observed; DN B is present on T1, T2 A calls B; B(T1) Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 914 Message Sequence Charts Message Sequence Charts

Page 978 diagram

Page 979

Call info Events Actions ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(TA) returns ID27 (Connection of B).getUniqueID(null) returns returns ID28 (Connection of B).getUniqueID(T1) returns returns ID28 (Connection of B).getUniqueID(T2) returns returns ID28 GC1: CallActiveEv GC1: ConnCreatedEv for A GC1: ConnConnectedEv for A GC1: CallCtlConnInitiatedEv for A GC1: TermConnCreatedEv for TA GC1: TermConnActiveEvent for TA GC1: CallCtlTermConnTalkingEv for TA GC1: CallCtlConnDialingEv for A GC1: CallCtlConnEstablishedEv for A GC1: ConnCreatedEv for B GC1: ConnInProgressEv for B GC1: CallCtlConnOfferedEv for B GC1: ConnAlertingEv for B GC1: TermConnCreatedEv for T1B GC1: TermConnRingingEv for T1B GC1: CallCtlTermConnRingingEv for T1B GC1: TermConnCreatedEv for T2B GC1: TermConnRingingEv for T2B GC1: CallCtlTermConnRingingEv for T2B GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B GC1: TermConnActiveEv for T1B GC1: CallCtlTermConnTalkingEv for T1B GC1: TermConnPassiveEv for T2B GC1: CallCtlTermConnBridgedEv 7. Shared Line Barge Scenario; All Observed; DN B is present on T1, T2 A calls B; B(T1) Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 915 Message Sequence Charts Message Sequence Charts

Page 979 diagram

Page 980

Call info Events Actions ( (CiscoConnection)(GC2: ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID29 (GC1: Connection of B).getUniqueID(T1) returns returns ID28 (GC1: Connection of B).getUniqueID(T2) returns returns ID30 (GC1: Connection of B).getUniqueID(null) is unpredictible (can be either of above two) GC2: CallActiveEv GC2: ConnCreatedEv for B GC2: ConnConnectedEv for B GC2: CallCtlConnInitiatedEv for B GC2: TermConnCreatedEv for T2B GC2: TermConnCreatedEv for T1B GC2: CiscoCallChangedEv GC1: TermConnActiveEv for T2B GC1: CallCtlTermConnTalkingEv for T2B GC2: TermConnDroppedEv for T2B GC2: CallCtlTermConnDroppedEv for T2B GC2: TermConnDroppedEv for T2B GC2: CallCtlTermConnDroppedEv for T2B GC2: ConnDisconnectedEv for B GC2: CallCtlConnDisconnectedEv for B GC2: CallInvalidEv GC2: CallObservationEndedEv B(T2) Presses Barge Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 916 Message Sequence Charts Message Sequence Charts

Page 980 diagram

Page 981

Call info Events Actions ( (CiscoConnection)(ConnCreatedEv for A).getConnection() ).getUniqueID(null) returns ID31 ( (CiscoConnection)(ConnCreatedEv for B).getConnection() ).getUniqueID(null) returns ID32 ( (CiscoConnection)(GC1: ConnCreatedEv for ParkDN).getConnection() ).getUniqueID(null) throws PrivilegeVoilationException ( (CiscoConnection)(GC2: ConnCreatedEv for C).getConnection() ).getUniqueID(null) returns ID34 ( (CiscoConnection)(GC1: ConnCreatedEv for C).getConnection() ).getUniqueID(null) returns ID35 8. Park/Unpark Scenario (All Observed) A calls B; B answers B does PARK C Unparks Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 917 Message Sequence Charts Message Sequence Charts

Page 981 diagram

Page 982

Call info Events Actions GC1: CallActiveEv GC1: ConnCreatedEv for A GC1: ConnConnectedEv for A GC1: CallCtlConnInitiatedEv for A GC1: TermConnCreatedEv for TA GC1: TermConnActiveEvent for TA GC1: CallCtlTermConnTalkingEv for TA GC1: ConnCreatedEv for B GC1: ConnConnectedEv for B GC1: CallCtlConnOfferedEv for B GC1: TermConnCreatedEv for TB GC1: ConnConnectedEv for A GC1: CallCtlConnEstablishedEv for A GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B GC1: ConnCreatedEv for ParkDN GC1: CallCtlConnQueuedEv for ParkDN GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B GC1: CallCtlConnDisconnectedEv for B GC2: CallActiveEv GC2: ConnCreatedEv for C GC2: ConnConnectedEv for C GC2: CallCtlConnInitiatedEv for C GC2: TermConnCreatedEv for TC GC2: CiscoCallChangedEv GC1: ConnCreatedEv for C GC1: ConnConnectedEv for C GC1: TermConnCreatedEv for TC GC1: ConnDisconnectedEv for ParkDN GC1: CallCtlConnDisconnectedEv for ParkDN GC2: TermConnDroppedEv for TC Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 918 Message Sequence Charts Message Sequence Charts

Page 982 diagram

Page 983

Call info Events Actions GC2: CallCtlTermConnDroppedEv for TC GC2: ConnDisconnectedEv for C GC2: CallCtlConnDisconnectedEv for C GC2: CallInvalidEv GC2: CallObservationEndedEv (Connection for A ).getUniqueID(null) returns ID37 (Connection for B ).getUniqueID(null) returns ID38 (GC1: Connection for C ).getUniqueID(null) returns ID39 (Connection for C ).getUniqueID(null) returns ID40 (Connection for D ).getUniqueID(null) returns ID41 (GC3: Connection for E ).getUniqueID(null) returns ID42 ( (CiscoConnection)(GC3: ConnCreatedEv for cBridge-GC1).getConnection() ).getUniqueID(null) throws PrivilegeVoilationException ( (CiscoConnection)(GC1: ConnCreatedEv for cBridge-GC3).getConnection() ).getUniqueID(null) throws PrivilegeVoilationException (Connection for A ).getUniqueID(null) returns ID37 (Connection for B ).getUniqueID(null) returns ID38 (Connection for C ).getUniqueID(null) returns ID39 (Connection for D ).getUniqueID(null) returns ID41 (Connection for E ).getUniqueID(null) returns ID42 GC1 and GC3 are created as normal GC1 has connections for A, B and C(Held) GC3 has connections for C(Talking), D and E GC3: ConnCreatedEvent for cBridge-GC1 GC3: CiscoConferenceChainAddedEv GC3: ConnConnectedEvent for cBridge-GC1 GC3: CallCtlConnEstablishedEv for cBridge-GC1 GC3: TermConnDroppedEv for TC GC3: CallCtlTermConnDroppedEv for TC GC3: ConnDisconnectedEvent for C GC3: CallCtlConnDisconnectedEv C GC1: CallCtlTermConnTalkingEv for TC GC1: ConnCreatedEvent for cBridge-GC3 GC1: CiscoConferenceChainAddedEv GC1: ConnConnectedEvent for cBridge-GC3 GC3: CallCtlConnEstablishedEv for cBridge-GC3 9. Conference Chaining Scenario; All Observed GC1: A calls B; B answers and adds C to conference GC3: C calls D; D answers and adds E to conference App sends GC1.conference(GC3) to chain two conferences Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 919 Message Sequence Charts Message Sequence Charts

Page 983 diagram

Page 984

Call info Events Actions ( (CiscoConnection)(GC1: ConnCreatedEv for D).getConnection() ).getUniqueID(null) returns ID43 GC3: TermConnDroppedEv for TE GC3: CallCtlTermConnDroppedEv for TE GC3: ConnDisconnectedEvent for E GC3: CallCtlConnDisconnectedEv E GC1: ConnDisconnectedEvent for cBridge-GC3 GC1: CiscoConferenceChainRemovedEv GC1: CallCtlConnDisconnectedEv cBridge-GC3 GC3: CiscoCallChangedEv GC1: ConnCreatedEvent for D GC1: ConnConnectedEvent for D GC1: CallCtlConnEstablishedEv for D GC1: TermConnCreatedEvent for TD GC1: TermConnActiveEvent for TD GC1: CallCtlTermConnTalkingEv for TD GC3: ConnDisconnectedEvent for cBridge-GC1 GC3: CiscoConferenceChainRemovedEv GC3: CallCtlConnDisconnectedEv cBridge-GC31 GC3: TermConnDroppedEv for TD GC3: CallCtlTermConnDroppedEv for TD GC3: ConnDisconnectedEvent for D GC3: CallCtlConnDisconnectedEv D GC3: CallInvalidEvent GC3: CallObservationEndedEv Application sends E.disconnect() Hunt Log Status for Phone Devices In the following use cases A, B, C, and D are IP phones where A and B are a part of line group which is configured to hunt pilot HP. A is the first hunt member and it is logged out of the hunt group and B is the second hunt member and it is logged in to the hunt group on hunt pilot. For the following use cases the CiscoTermEvFilter. setHuntLogStatusChangedEvFilter() is set to true. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 920 Message Sequence Charts Hunt Log Status for Phone Devices

Page 984 diagram

Page 985

Call To Hunt Pilot where device is logged into hunt group Call information Events Action Ev.getHutLogStatus() = CiscoTerminal.DEVICE_HUNT_LOGGED_IN CiscoTermHuntLogStatusChangedEv on A On A, huntLogStatus is set to CiscoTerminal. DEVICE_HUNT_LOGGED_IN using the method setHuntLogStatus(int huntLogStatus). CurrentCallingParty = C CurrentCalledParty = A GC1 CallActiveEv C GC1 ConnCreatedEv C GC1 ConnConnectedEv C GC1 CallCtlConnInitiatedEv C GC1 TermConnCreatedEv TermC GC1 TermConnActiveEV TermC GC1 CallCtlTermConnTalkingEv TermC GC1 CallCtlConnDialingEv C GC1 CallCtlConnEstablishedEv C GC1 CiscoHuntConnCreatedEv HP GC1 ConnInProgressEv HP GC1 CallCtlConnOfferedEv HP C calls Hunt pilot HP. GC1 ConnCreatedEv A GC1 ConnInProgressEv A GC1 CallCtlConnOfferedEv A GC1 ConnAltertingEv A GC1 CallCtlConnAlertingEv A GC1 TermConnCreatedEv TermA GC1 TermConnRingingEv TermA GC1 CallCtlTermConnRingingEv TermA HP offers the call to A as it is the first hunt member and A starts ringing. CurrentCallingParty = C CurrentCalledParty = A GC1 ConnConnectedEv HP1 GC1 CallCtlConnEstablishedEv HP1 GC1 ConnConnectedEv A GC1 CallCtlConnEstablishedEv A GC1 TermConnActiveEv TermA GC1 CallCtlTermConnTalkingEv TermA A answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 921 Message Sequence Charts Message Sequence Charts

Page 985 diagram

Page 986

Call To Hunt Pilot where device is logged out of the hunt group Call information Events Action Ev.getHuntLogStatus() = CiscoTerminal.DEVICE_HUNT_LOGGED_OUT CiscoTermHuntLogStatusChangedEv on A On A, huntLogStatus is set to CiscoTerminal. DEVICE_HUNT_LOGGED_OUT using the method setHuntLogStatus(int huntLogStatus) for the terminal to log in to the huntgroup. CurrentCallingParty = C CurrentCalledParty = B GC1 CallActiveEv C GC1 ConnCreatedEv C GC1 ConnConnectedEv C GC1 CallCtlConnInitiatedEv C GC1 TermConnCreatedEv TermC GC1 TermConnActiveEV TermC GC1 CallCtlTermConnTalkingEv TermC C calls Hunt pilot HP. GC1 CallCtlConnDialingEv C GC1 CallCtlConnEstablishedEv C GC1 CiscoHuntConnCreatedEv HP GC1 ConnInProgressEv HP GC1 CallCtlConnOfferedEv HP GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAltertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEv TermB HP offers the call to B as A which is the first hunt member logged out of the hunt group and B is the second hunt member. B starts ringing. CurrentCallingParty = C CurrentCalledParty = B GC1 ConnConnectedEv HP1 GC1 CallCtlConnEstablishedEv HP1 GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv TermB GC1 CallCtlTermConnTalkingEv TermB B answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 922 Message Sequence Charts Message Sequence Charts

Page 986 diagram

Page 987

Updating the value of huntlogstatus on Unsupported device(Route Point/Spark Remote device/CTI Remote Device) Call information Events Action com.cisco.jtapi.MethodNotSupportedException:Operation not allowed huntLogStatus is set to CiscoTerminal. DEVICE_HUNT_LOGGED_IN using the method setHuntLogStatus(int huntLogStatus) for the route point to log in to the huntgroup. Updating the value of huntlogstatus on the terminal which is out of service Call information Events Action com.cisco.jtapi.InvalidStateException huntLogStatus is set to CiscoTerminal. DEVICE_HUNT_LOGGED_IN using the method setHuntLogStatus(int huntLogStatus) on D which is not in service Energywise Deep Sleep Mode Scenario 1 JTAPI reports new reason“ENERGYWISE_POWER_SAVE_PLUS”in CiscoProvTerminalUnRegisteredEv and cause“CAUSE_ENERGYWISE_POWER_SAVE_PLUS”in CiscoTermOutOfServiceEv and CiscoAddrOutOfServiceEv to the application when a terminal/address unregisters from Cisco Unified CM due to deep sleep time. Information Events Description ProvInServiceEv P1 [Term A] CiscoTermInServiceEv [Addr A] CiscoAddrInServiceEv Application opens the provider and adds observer on provider, terminal and address of 'A' CiscoProvTerminalUnRegisteredEv.getReason() = CiscoProvTerminalUnRegisteredEv. ENERGYWISE_POWER_ SAVE_PLUS CiscoTermOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS CiscoAddrOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS [Term A] CiscoProvTerminalUnRegisteredEv [Term A] CiscoTermOutOfServiceEv [Addr A] CiscoAddrOutOfServiceEv Terminal 'A' enters Deep Sleep mode and gets unregistered Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 923 Message Sequence Charts Energywise Deep Sleep Mode

Page 987 diagram

Page 988

Scenario 2 Terminal gets unregistered due to Deep Sleep mode and the user tries to manually register the terminal during the Deep Sleep time. Information Events Description ProvInServiceEv P1 [Term A] CiscoTermInServiceEv [Addr A] CiscoAddrInServiceEv Application opens the provider and adds observer on provider, terminal and address of 'A'' CiscoProvTerminalUnRegisteredEv.getReason() = CiscoProvTerminalUnRegisteredEv. ENERGYWISE_POWER_ SAVE_PLUS CiscoTermOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS CiscoAddrOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS [Term A] CiscoProvTerminalUnRegisteredEv [Term A] CiscoTermOutOfServiceEv [Addr A] CiscoAddrOutOfServiceEv Terminal 'A' goes to Deep Sleep mode and gets unregistered Cisco Unified IP 7900 Series phones do not re-register with the Cisco Unified CM during the Deep Sleep time. This is a limitation of the phone. Cisco Unified IP 9900 and 6900 Series phones register back with the Cisco Unified CM by pressing the select key on the phone. A user tries to register the phone with Cisco Unified CM during deep sleep mode. [Term A] CiscoProvTerminalRegisteredEv [Term A] CiscoTermInServiceEv [Addr A] CiscoAddrInServiceEv Phone registers with the Cisco Unified CM after the Deep Sleep time expires. Scenario 3 Shared line scenario. Two devices A (Cisco Unified IP Phones 7900 Series phone) and A' (CTI Port) are configured with the same line. Deep Seep mode is enabled on device A Information Events Description ProvInServiceEv P1 [Term A] CiscoTermInServiceEv [Addr A] CiscoAddrInServiceEv [Term A'] CiscoTermInServiceEv [Addr A'] CiscoAddrInServiceEv Application opens the provider and adds observer on provider, terminal and address of A and A' Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 924 Message Sequence Charts Message Sequence Charts

Page 988 diagram

Page 989

Information Events Description CiscoProvTerminalUnRegisteredEv.getReason() = CiscoProvTerminalUnRegisteredEv. ENERGYWISE_POWER_ SAVE_PLUS CiscoTermOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS CiscoAddrOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS [Term A] CiscoProvTerminalUnRegisteredEv [Term A] CiscoTermOutOfServiceEv [Addr A] CiscoAddrOutOfServiceEv Terminal A goes to Deep Sleep mode and gets unregistered. (Terminal A' remains in registered state.) Scenario 4 Shared line scenario. Two devices A and A' (both are Cisco Unified IP Phones 7900 Series phones) that have are configured with the same line. Deep Sleep mode is enabled on A. Another device B calls the shared line after device A enters to the Deep Sleep mode. Information Events Description ProvInServiceEv P1 [Term A] CiscoTermInServiceEv [Addr A] CiscoAddrInServiceEv [Term A'] CiscoTermInServiceEv [Addr A'] CiscoAddrInServiceEv Application opens the provider and adds observer on provider, terminal and address of A and A' CiscoTermOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS CiscoAddrOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER [Term A] CiscoTermOutOfServiceEv [Addr A] CiscoAddrOutOfServiceEv Terminal A goes to deep sleep mode and gets unregistered. (Terminal A' remains in registered state.) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 925 Message Sequence Charts Message Sequence Charts

Page 989 diagram

Page 990

Information Events Description GC1 CallActiveEv GC1 ConnCreatedEv [Addr B] GC1 ConnConnectedEv [Addr B] GC1 CallCtlConnInitiatedEv [Addr B]

GC1 ConnCreatedEv [Addr A'] GC1 ConnInProgressEv [Addr A'] GC1 CallCtlConnOfferedEv [Addr A']

GC1 ConnConnectedEv [Addr A'] GC1 CallCtlConnEstablishedEv [Addr A'] GC1 TermConnActiveEv [Term A'] GC1 CallCtlTermConnTalkingEv [Term A' Another terminal B calls to the shared line DN. Scenario 5 Shared line scenario. Two device A (Cisco Unified IP Phones Series 9900/6900 phone) and A' (Cisco Unified IP Phones Series 9900/6900 phone) are configured with the same line. Deep Sleep mode is enabled on both devices. Information Events Description ProvInServiceEv P1 [Term A] CiscoTermInServiceEv [Addr A] CiscoAddrInServiceEv [Term A'] CiscoTermInServiceEv [Addr A'] CiscoAddrInServiceEv Application opens the provider and adds observer on provider, terminal and address of A and A' Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 926 Message Sequence Charts Message Sequence Charts

Page 990 diagram

Page 991

Information Events Description CiscoProvTerminalUnRegisteredEv.getReason() = CiscoProvTerminalUnRegisteredEv. ENERGYWISE_POWER_ SAVE_PLUS CiscoProvTerminalUnRegisteredEv.getReason() = CiscoProvTerminalUnRegisteredEv. ENERGYWISE_POWER_ SAVE_PLUS CiscoTermOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS CiscoTermOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS CiscoAddrOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS CiscoAddrOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS [Term A] CiscoProvTerminalUnRegisteredEv [Term A'] CiscoProvTerminalUnRegisteredEv [Term A] CiscoTermOutOfServiceEv [Term A'] CiscoTermOutOfServiceEv [Addr A] CiscoAddrOutOfServiceEv [Addr A'] CiscoAddrOutOfServiceEv Terminal A and A' enters Deep Sleep mode and gets unregistered Term A] CiscoProvTerminalRegisteredEv [Term A'] CiscoProvTerminalRegisteredEv [Term A] CiscoTermInServiceEv [Term A'] CiscoTermInServiceEv [Addr A] CiscoAddrInServiceEv [Addr A'] CiscoAddrInServiceEv Deep Sleep mode power off time has expired and A and A' reregister to the Cisco Unified CM Scenario 6 Basic call scenario. Two devices A (CTI port) and B (Cisco Unified IP Phones 7900 Series phone) are configured on a Cisco Unified CM and Deep Sleep mode is enabled on B with power off time configured for 6:00 PM. A calls B at 5:55 pm and the call continues until 6:10 pm. The idle timer is set for 10 minutes. Information Events Description ProvInServiceEv P1 [Term A] CiscoTermInServiceEv [Addr A] CiscoAddrInServiceEv [Term B] CiscoTermInServiceEv [Addr B] CiscoAddrInServiceEv Application opens the provider and adds observer on provider, terminal and address of A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 927 Message Sequence Charts Message Sequence Charts

Page 991 diagram

Page 992

GC1 ConnCreatedEv [Addr A] GC1 ConnInProgressEv [Addr A] GC1 CallCtlConnOfferedEv [Addr A]

GC1 ConnConnectedEv [Addr A] GC1 CallCtlConnEstablishedEv [Addr A] GC1 TermConnActiveEv [Term A] GC1 CallCtlTermConnTalkingEv [Term A] Terminal B calls A at 5:55 pm. A answers the call and goes to connected state. At 6:00 pm Deep Sleep time is enabled but the call does not get dropped and remains active. GC1 TermConnDroppedEv [Term B] GC1 CallCtlTermConnDroppedEv [Term B] GC1 ConnDisconnectedEv [Addr B] GC1 CallCtlConnDisconnectedEv [Addr B] GC1 CallInvalidEv The user disconnects the call from the phone at 6:10 PM and the idle timer (set for 10 minutes) starts. CiscoProvTerminalUnRegisteredEv.getReason() = CiscoProvTerminalUnRegisteredEv. ENERGYWISE_POWER_ SAVE_PLUS CiscoTermOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS CiscoAddrOutOfServiceEv.getCause() = CiscoOutOfServiceEv. CAUSE_ENERGYWISE_POWER_ SAVE_PLUS [Term B] CiscoProvTerminalUnRegisteredEv [Term B] CiscoTermOutOfServiceEv [Addr B] CiscoAddrOutOfServiceEv There is no action on phone A for the next 10 minutes. So at 6:20 pm, after the idle timer has expired, the terminal enters Deep Sleep mode and unregisters from the Cisco Unified CM. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 928 Message Sequence Charts Message Sequence Charts

Page 992 diagram

Page 993

External Call Control You should assume that all devices in the following use cases are obsereved, unless explicilty stated otherwise in the use case description. The first few use cases go through the full event series for the basic call setup. After the first three or four, the use cases leave this part out, as it is standard for most of the use cases. If you do not see the basic call event series at the beginning of a use case, you can assume that it was intended to have happened successfully before the first event in the use case. The last column in the use cases, that specifies the call info for a various stage of the use case, will initially have the full method invocation to retrieve the call information, for example CiscoCall.getModifiedCallingParty(). After the first three or four uses cases, only the method name is specified, such as .getModifiedCallingParty(). You can assume that this is to be prefixed with CiscoCall unless explicitly stated otherwise, such as for the CiscoCallChangeEvs. Use Cases for BasicCall Basic Call Initiated From JTAPI / Phone Configuration Phone A, B are in cluster devices. Procedure: Application invokes connect() at A to call B, or physical phone for A dials the number for B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 929 Message Sequence Charts External Call Control

Page 993 content

Page 994

Call info Events Actions CiscoCall.getCurrentCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = “”, CiscoCall.getCalledAddress() = “”, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getCurrntCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = “”, CiscoCall.getCalledAddress() = “”, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A, CiscoCall getCallingAddress() = A, CiscoCall getModifiedCalledAddress() = B, CiscoCall getCalledAddress() = B, CiscoCall getCurrentCallingTerminal() = Terminal of A. CiscoCall getCurrentCalledTerminal() = null GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A A initiates call to B Connection of A created, called party info set CiscoCall.getModifiedCallingAddress() = A, CiscoCall getCallingAddress() = A, CiscoCall getModifiedCalledAddress() = B, CiscoCall getCalledAddress() = B, CiscoCall getCurrentCallingTerminal() = Terminal of A. CiscoCall getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = B, CiscoCall.getCalledAddress() = B, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = Terminal of B GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv-B GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-B GC1-ConnConnectedEvent-B GC1-CallCtlConnEstablishedEv-B GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv Connection of B created B starts ringing B Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 930 Message Sequence Charts Message Sequence Charts

Page 994 diagram

Page 995

Use Cases for Calls Going Through Translation Pattern with CEPN Info in Cc Signals Basic Call Initiated From JTAPI to the DN with Translation Pattern Configured to Transform Called Party Configuration Phone A, B are in cluster devices. B has a translation pattern configured where called party get transformed to B1. Procedure: Application invokes connect() at A to call B. Call info Events Actions CiscoCall.getModifiedCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = “”, CiscoCall.getCalledAddress() = “”, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = “”, CiscoCall.getCalledAddress() = “”, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = B1, CiscoCall.getCalledAddress() = B1, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A A initiates call to B Connection of A created, Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 931 Message Sequence Charts Use Cases for Calls Going Through Translation Pattern with CEPN Info in Cc Signals

Page 995 diagram

Page 996

Call info Events Actions CiscoCall.getModifiedCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = “”, CiscoCall.getCalledAddress() = “”, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getCurrentCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getCurrentCalledAddress() = B1, CiscoCall.getCalledAddress() = B1, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = Terminal of B1 GC1-ConnCreatedEvent-B1 GC1-ConnInprogressEvent-B1 GC1-CallCtlConnOfferedEv-B1 GC1-ConnAlertingEvent-B1 GC1-CallCtlConnAlertingEv-B1 GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-B1 GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv Connection of B1 created B1 starts ringing B1 Answers Basic Call Initiated From JTAPI to the DN with Translation Pattern Configured to Transform Calling Party Configuration Phone A, B are in cluster devices. B has a translation pattern configured where calling party gets transformed to A1. Procedure: Application invokes connect() at A to call B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 932 Message Sequence Charts Message Sequence Charts

Page 996 diagram

Page 997

Call info Events Action CiscoCall.getModifiedCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = “”, CiscoCall.getCalledAddress() = “”, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = “”, CiscoCall.getCalledAddress() = “”, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A1, CiscoCall getCallingAddress() = A, CiscoCall getCurrentCallingAddress() = A, CiscoCall getModifiedCalledAddress() = B, CiscoCall getCalledAddress() = B, CiscoCall getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv-B GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-B A initiates call to B Connection of A created, Connection of B created B starts ringin CiscoCall.getModifiedCallingAddress() = A1, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = B, CiscoCall.getCalledAddress() = B, CiscoCall.getCurrentCallingTerminal() = Terminal of A CiscoCall.getCurrentCalledTerminal() = Terminal of B GC1-ConnConnectedEvent-B GC1-CallCtlConnEstablishedEv-B GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv B Answers Basic Call Initiated From JTAPI to the DN with Translation Pattern Configured to Transform Both Calling and Called Parties Configuration Phone A, B are in cluster devices. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 933 Message Sequence Charts Message Sequence Charts

Page 997 diagram

Page 998

B has a translation pattern configured where both calling and called parties get transformed to A1 and B1 respectively Procedure: Application invokes connect() at A to call B Call info Events Action CiscoCall.getModifiedCallingAddress() = A, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = “”, CiscoCall.getCalledAddress() = “”, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A1, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = “”, CiscoCall.getCalledAddress() = “”, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A1, CiscoCall getCallingAddress() = A, CiscoCall getModifiedCalledAddress() = B1, CiscoCall getCalledAddress() = B1, CiscoCall getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A1, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = B1, GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv-B GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-B A initiates call to B Connection of A created, called party info set Connection of B1 created B1 starts ringing A gets CallStateChg For Ringback Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 934 Message Sequence Charts Message Sequence Charts

Page 998 diagram

Page 999

Call info Events Action CiscoCall.getCalledAddress() = B1, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A1, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = B1, CiscoCall.getCalledAddress() = B1, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = Terminal of B1 GC1-ConnConnectedEvent-B GC1-CallCtlConnEstablishedEv-B GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv B1 Answers Called Party Redirects a Call Which Has Transformed Calling and Called Parties Configuration Phone A, B, C are in cluster devices. B has a translation pattern configured where both calling and called parties get transformed to A1 and B1 respectively Procedure: Application invokes connect() at A to call B. B1 redirects the call in connected state. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 935 Message Sequence Charts Message Sequence Charts

Page 999 diagram

Page 1000

Call info Events Actions CiscoCall.getModifiedCallingAddress() = A1, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = B1, CiscoCall.getCalledAddress() = B1, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = Terminal of B1 CiscoCall.getModifiedCallingAddress() = A1, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = C, CiscoCall.getCalledAddress() = C, CiscoCall.getLastRedirectedAddress() = B1, CiscoCall.getCurrentCallingTerminal() = terminal of A. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = A1, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = C, CiscoCall.getCalledAddress() = C, CiscoCall.getLastRedirectedAddress() = B1, CiscoCall.getCurrentCallingTerminal() = terminal of A. CiscoCall.getCurrentCalledTerminal() = null GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B1 GC1-CallCtlConnDisconnectedEv-B1 A and B1 receive Connected Call State (Basic Call) B1 redirects the call to C Connection for C is created C rings B1 gets dropped A gets CallStateChg for Ringback CiscoCall.getModifiedCallingAddress() = A1, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = C, CiscoCall.getCalledAddress() = C, CiscoCall.getLastRedirectedAddress() = B1, CiscoCall.getCurrentCallingTerminal() = terminal of A. CiscoCall.getCurrentCalledTerminal() = terminal of C GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 936 Message Sequence Charts Message Sequence Charts

Page 1000 diagram

Page 1001

Called Party Which Has Transformed Calling and Called Parties Parks the Call and Receives a Park Reminder Call Configuration Phone A, B are in cluster devices. C is a park DN (also in cluster) B has a translation pattern configured where both calling and called parties get transformed to A1 and B1 respectively Procedure: Application invokes connect() at A to call B. B1 answers and then B1 parks the call and after park reversion timer expiry receives the reminder call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 937 Message Sequence Charts Message Sequence Charts

Page 1001 content

Page 1002

Call info Events Actions .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = Terminal of B1 .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = B1, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getLastRedirectedAddress() = Park DN C, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getLastRedirectedAddress() = Park DN C, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of B1 … See use case 15.7.1.1.1 … GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B1 GC1-CallCtlConnDisconnectedEv-B1 GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnQueuedEv-C GC1-ConnCreatedEvent-B1 GC1-ConnInprogressEvent-B1 GC1-CallCtlConnOfferedEv-B1 GC1-ConnAlertingEvent-B1 GC1-CallCtlConnAlertingEv-B1 GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnDisconnectedEvent-C GC1-CallCtlConnDisconnectedEv-C GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv A and B1 receive Connected Call State (Basic Call) B1 Parks the call Connection for C is created B1 gets park reminder B1 rings C gets dropped B1 Answers Calling Party Parks the Call and Receives a Park Reminder Call After a Transformation From Called Party Translation Pattern Configuration Phone A, B are in cluster devices. C is a park DN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 938 Message Sequence Charts Message Sequence Charts

Page 1002 diagram

Page 1003

B has a translation pattern configured where both calling and called parties get transformed to A1 and B1 respectively Procedure: Application invokes connect() at A to call B. B1 answers and then A parks the call and after park reversion timer expiry receives the reminder call. Call info Events Actions .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = Terminal of B1 .getModifiedCallingAddress() = B1, .getCallingAddress() = B1, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = A, .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = B1, .getCallingAddress() = B1, .getModifiedCalledAddress() = A, .getCalledAddress() = A, .getLastRedirectedAddress() = Park DN C, .getCurrentCallingTerminal() = terminal of B1 .getCurrentCalledTerminal() = null GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-A GC1-CallCtlConnDisconnectedEv-A GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnQueuedEv-C GC1-ConnCreatedEvent-A GC1-ConnInprogressEvent-A GC1-CallCtlConnOfferedEv-A GC1-ConnAlertingEvent-A GC1-CallCtlConnAlertingEv-A GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv A and B1 receive Connected Call State (Basic Call) A Parks the call Connection for C is created A gets park reminder A rings .getModifiedCallingAddress() = B1, .getCallingAddress() = B1, .getModifiedCalledAddress() = A, .getCalledAddress() = A, .getLastRedirectedAddress() = Park DN C, .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = terminal of A GC1-ConnDisconnectedEvent-C GC1-CallCtlConnDisconnectedEv-C GC1-ConnConnectedEvent-A GC1-CallCtlConnEstablishedEv-A GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C gets dropped A Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 939 Message Sequence Charts Message Sequence Charts

Page 1003 diagram

Page 1004

Caller Redirects a Call Which Has Transformed Calling and Called Parties Configuration Phone A, B, C are in cluster devices. B has a translation pattern configured where both calling and called parties get transformed to A1 and B1 respectively Procedure: Application invokes connect() at A to call B. A redirects the call in connected state. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 940 Message Sequence Charts Message Sequence Charts

Page 1004 content

Page 1005

Call info Events Actions CiscoCall.getModifiedCallingAddress() = A1, CiscoCall.getCallingAddress() = A, CiscoCall.getModifiedCalledAddress() = B1, CiscoCall.getCalledAddress() = B1, CiscoCall.getCurrentCallingTerminal() = Terminal of A. CiscoCall.getCurrentCalledTerminal() = Terminal of B1 CiscoCall.getModifiedCallingAddress() = B1, CiscoCall.getCallingAddress() = B1, CiscoCall.getModifiedCalledAddress() = C, CiscoCall.getCalledAddress() = C, CiscoCall.getLastRedirectedAddress() = A, CiscoCall.getCurrentCallingTerminal() = terminal of B1. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = B1, CiscoCall.getCallingAddress() = B1, CiscoCall.getModifiedCalledAddress() = C, CiscoCall.getCalledAddress() = C, CiscoCall.getLastRedirectedAddress() = A, CiscoCall.getCurrentCallingTerminal() = terminal of B1. CiscoCall.getCurrentCalledTerminal() = null CiscoCall.getModifiedCallingAddress() = B1, CiscoCall.getCallingAddress() = B1, CiscoCall.getModifiedCalledAddress() = C, CiscoCall.getCalledAddress() = C, CiscoCall.getLastRedirectedAddress() = A, CiscoCall.getCurrentCallingTerminal() = terminal of B1. GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-A GC1-CallCtlConnDisconnectedEv-A GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv A and B1 receive Connected Call State (Basic Call) A redirects the call to C Connection for C is created C rings A gets dropped B1 gets CallStateChg for Ringback C Answers Called Party Transfers the Call Which Has Transformed Calling and Called Parties Configuration Phone A, B, C are in cluster devices. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 941 Message Sequence Charts Message Sequence Charts

Page 1005 diagram

Page 1006

B has a translation pattern configured where both calling and called parties get transformed to A1 and B1 respectively Procedure: Application invokes connect() at A to call B. B1 consult transfer the call to C. Call info Events Actions .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = Terminal of B1 .getModifiedCallingAddress() = B1, .getCallingAddress() = B1, .getModifiedCalledAddress() = null, .getCalledAddress() = null, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = B1, .getCallingAddress() = B1, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = null .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = null GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv CG1-CallCtlTermConnHeldEv GC2-ConsultCallActiveEvent GC2-ConnCreatedEvent-B1 GC2-ConnConnectedEvent-B1 GC2-CallCtlConnInitiatedEv-B1 GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-B1 GC2-CallCtlConnEstablishedEv-B1 GC2-ConnCreatedEvent-C GC2-ConnInprogressEvent-C GC2-CallCtlConnOfferedEv-C GC2-ConnAlertingEvent-C GC2-CallCtlConnAlertingEv-C GC2-TermConnCreatedEvent GC2-TermConnRingingEvent GC2-CallCtlTermConnRingingEv A and B1 receive Connected Call State (Basic Call) B1 consults call to C Connection for C is created (GC2) C rings C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 942 Message Sequence Charts Message Sequence Charts

Page 1006 diagram

Page 1007

Call info Events Actions .getModifiedCallingAddress() = B1, .getCallingAddress() = B1, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = null .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = terminal of C Ev.getOriginalCall = GC2 (OCall) Ev.getSurvivingCall = GC1 (FCall) OCall.getModifiedCallingAddress() = B1, OCall.getCallingAddress() = B1, OCall.getModifiedCalledAddress() = C, OCall.getCalledAddress() = C, OCall.getLastRedirectedAddress() = OCall.getCurrentCallingTerminal() = terminal of B1 OCall.getCurrentCalledTerminal() = terminal of C FCall.getModifiedCallingAddress() = A1, FCall.getCallingAddress() = A, FCall.getModifiedCalledAddress() = B1, FCall.getCalledAddress() = B1, FCall.getLastRedirectedAddress() = FCall.getCurrentCallingTerminal() = terminal of A FCall.getCurrentCalledTerminal() = terminal of B1 GC2-ConnConnectedEvent-C GC2-CallCtlConnEstablishedEv-C GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC1-CiscoTermConnSelectChangedEv GC2-CiscoTermConnSelectChangedEv GC1-CiscoTransferStartEv GC2-CiscoCallChangedEv Transfer starts Call Changes Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 943 Message Sequence Charts Message Sequence Charts

Page 1007 diagram

Page 1008

Call info Events Actions .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = B1 .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of C GC1-ConnCreatedEvent-C GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B1 GC1-CallCtlConnDisconnectedEv-B1 GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-B1 GC2-CallCtlConnDisconnectedEv-B1 GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-CiscoTransferEndEv Connection for C is created (GC1) C gets dropped (GC2) B1 gets dropped (GC1) B1 gets dropped (GC2) GC2 Invalid Transfer comple Called Party Transfers the Call Which Has Transformed Calling and Called Parties to a DN Which Matches the Translation Pattern with Calling Party Transformation Defined Configuration Phone A, B, C are in cluster devices. B has a translation pattern configured where both calling and called parties get transformed to A1 and B1 respectively C matches the the translation pattern with calling party transformation to B2 Procedure: Application invokes connect() at A to call B. B1 consult transfer the call to C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 944 Message Sequence Charts Message Sequence Charts

Page 1008 diagram

Page 1009

Call info Events Actions .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = Terminal of B1 .getModifiedCallingAddress() = B2, .getCallingAddress() = B1, .getModifiedCalledAddress() = null, .getCalledAddress() = null, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = B2, .getCallingAddress() = B1, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = B2, .getCallingAddress() = B1, .getModifiedCalledAddress() = C, GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv CG1-CallCtlTermConnHeldEv GC2-ConsultCallActiveEvent GC2-ConnCreatedEvent-B1 GC2-ConnConnectedEvent-B1 GC2-CallCtlConnInitiatedEv-B1 GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-B1 GC2-CallCtlConnEstablishedEv-B1 GC2-ConnCreatedEvent-C GC2-ConnInprogressEvent-C GC2-CallCtlConnOfferedEv-C GC2-ConnAlertingEvent-C GC2-CallCtlConnAlertingEv-C GC2-TermConnCreatedEvent GC2-TermConnRingingEvent GC2-CallCtlTermConnRingingEv GC2-ConnConnectedEvent-C GC2-CallCtlConnEstablishedEv-C GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC1-CiscoTermConnSelectChangedEv GC2-CiscoTermConnSelectChangedEv A and B1 receive Connected Call State (Basic Call) B1 consults call to C Connection for C is created (GC2) C rings C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 945 Message Sequence Charts Message Sequence Charts

Page 1009 diagram

Page 1010

Call info Events Actions .getCalledAddress() = C, .getLastRedirectedAddress() = null .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = terminal of C Ev.getOriginalCall = GC2 (OCall) Ev.getSurvivingCall = GC1 (FCall) OCall.getModifiedCallingAddress() = B2, OCall.getCallingAddress() = B1, OCall.getModifiedCalledAddress() = C, OCall.getCalledAddress() = C, OCall.getLastRedirectedAddress() = OCall.getCurrentCallingTerminal() = terminal of B1 OCall.getCurrentCalledTerminal() = terminal of C FCall.getModifiedCallingAddress() = A1, FCall.getCallingAddress() = A, FCall.getModifiedCalledAddress() = B1, FCall.getCalledAddress() = B1, FCall.getLastRedirectedAddress() = FCall.getCurrentCallingTerminal() = terminal of A FCall.getCurrentCalledTerminal() = terminal of B1 .getModifiedCallingAddress() = A1, GC1-CiscoTransferStartEv GC2-CiscoCallChangedEv Transfer starts Call Changes Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 946 Message Sequence Charts Message Sequence Charts

Page 1010 diagram

Page 1011

Call info Events Actions .getCallingAddress() = A, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = B1 .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of C GC1-ConnCreatedEvent-C GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B1 GC1-CallCtlConnDisconnectedEv-B1 GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-B1 GC2-CallCtlConnDisconnectedEv-B1 GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-CiscoTransferEndEv Connection for C is created (GC1) C gets dropped (GC2) B1 gets dropped (GC1) B1 gets dropped(GC2) GC2 Invalid Transfer complete Called Party with Transformed Calling and Called Parties Conferences a DN Configuration Phone A, B, C are in cluster devices. B has a translation pattern configured where both calling and called parties get transformed to A1 and B1 respectively Procedure: Application invokes connect() at A to call B. B1 consult conference the call to C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 947 Message Sequence Charts Message Sequence Charts

Page 1011 diagram

Page 1012

Call info Events Actions .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = Terminal of B1 .getModifiedCallingAddress() = B1, .getCallingAddress() = B1, .getModifiedCalledAddress() = null, .getCalledAddress() = null, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = B1, .getCallingAddress() = B1, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = B1, .getCallingAddress() = B1, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = terminal of C GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-CiscoTermConnSelectChangedEv CG1-CallCtlTermConnHeldEv GC2-CiscoConsultCallActiveEv GC2-ConnCreatedEvent-B1 GC2-ConnConnectedEvent-B1 GC2-CallCtlConnInitiatedEv-B1 GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-B1 GC2-CallCtlConnEstablishedEv-B1 GC2-ConnCreatedEvent-C GC2-ConnInprogressEvent-C GC2-CallCtlConnOfferedEv-C GC2-ConnAlertingEvent-C GC2-CallCtlConnAlertingEv-C GC2-TermConnCreatedEvent GC2-TermConnRingingEvent GC2-CallCtlTermConnRingingEv GC2-ConnConnectedEvent-C GC2-CallCtlConnEstablishedEv-C GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv A and B1 receive Connected Call State (Basic Call) B1 consults call to C Connection for C is created (GC2) C rings C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 948 Message Sequence Charts Message Sequence Charts

Page 1012 diagram

Page 1013

Call info Events Actions Ev.getOriginalCall = GC2 (OCall) Ev.getSurvivingCall = GC1 (FCall) OCall.getModifiedCallingAddress() = B1, OCall.getCallingAddress() = B1, OCall.getModifiedCalledAddress() = C, OCall.getCalledAddress() = C, OCall.getLastRedirectedAddress() = OCall.getCurrentCallingTerminal() = terminal of B1 OCall.getCurrentCalledTerminal() = terminal of C FCall.getModifiedCallingAddress() = A1, FCall.getCallingAddress() = A, FCall.getModifiedCalledAddress() = B1, FCall.getCalledAddress() = B1, FCall.getLastRedirectedAddress() = FCall.getCurrentCallingTerminal() = terminal of A FCall.getCurrentCalledTerminal() = terminal of B1 GC1-CiscoConferenceStartEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-B1 GC2-CallCtlConnDisconnectedEv-B1 GC1-CiscoTermConnSelectChangedEv GC1-CallCtlTermConnTalkingEv GC2-CiscoCallChangedEv Conference Starts B1 gets dropped (GC2) .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = null, .getCalledAddress() = C, .getLastRedirectedAddress() = B1 .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null GC1-ConnCreatedEvent-C GC1-ConnConnectedEvent-C * GC1-CallCtlConnEstablishedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv-C GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-CiscoConferenceEndEv Connection for C is created (GC1) C gets dropped (GC2) GC2 invalid Conferece Ends Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 949 Message Sequence Charts Message Sequence Charts

Page 1013 diagram

Page 1014

Called Party with Transformed Calling and Called Parties Conferences a DN Which Matches the Translation Pattern with Calling Party Transformation Defined Configuration Phone A, B, C are in cluster devices. B has a translation pattern configured where both calling and called parties get transformed to A1 and B1 respectively C has a translation pattern configured where calling party gets transformed to B2. Procedure: Application invokes connect() at A to call B. B1 consult conference the call to C. Call info Events Actions .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = Terminal of B1 .getModifiedCallingAddress() = B1, getCallingAddress() = B1, .getModifiedCalledAddress() = null, .getCalledAddress() = null, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = B2, .getCallingAddress() = B1, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = null GC1-ConnConnectedEvent-B1 GC1-CallCtlConnEstablishedEv-B1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-CiscoTermConnSelectChangedEv CG1-CallCtlTermConnHeldEv GC2-CiscoConsultCallActiveEv GC2-ConnCreatedEvent-B1 GC2-ConnConnectedEvent-B1 GC2-CallCtlConnInitiatedEv-B1 GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-B1 GC2-CallCtlConnEstablishedEv-B1 GC2-ConnCreatedEvent-C GC2-ConnInprogressEvent-C GC2-CallCtlConnOfferedEv-C GC2-ConnAlertingEvent-C GC2-CallCtlConnAlertingEv-C GC2-TermConnCreatedEvent GC2-TermConnRingingEvent GC2-CallCtlTermConnRingingEv A and B1 receive Connected Call State (Basic Call) B1 consults call to C Connection for C is created (GC2) C rings C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 950 Message Sequence Charts Message Sequence Charts

Page 1014 diagram

Page 1015

Call info Events Actions .getModifiedCallingAddress() = B2, .getCallingAddress() = B1, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of B1. .getCurrentCalledTerminal() = terminal of C Ev.getOriginalCall = GC2 (OCall) Ev.getSurvivingCall = GC1 (FCall) OCall.getModifiedCallingAddress() = B2, OCall.getCallingAddress() = B1, OCall.getModifiedCalledAddress() = C, OCall.getCalledAddress() = C, OCall.getLastRedirectedAddress() = OCall.getCurrentCallingTerminal() = terminal of B1 OCall.getCurrentCalledTerminal() = terminal of C GC2-ConnConnectedEvent-C GC2-CallCtlConnEstablishedEv-C GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC1-CiscoConferenceStartEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-B1 GC2-CallCtlConnDisconnectedEv-B1 GC1-CiscoTermConnSelectChangedEv GC1-CallCtlTermConnTalkingEv GC2-CiscoCallChangedEv Conference Starts B1 gets dropped (GC2) FCall.getModifiedCallingAddress() = A1, FCall.getCallingAddress() = A, FCall.getModifiedCalledAddress() = B1, FCall.getCalledAddress() = B1, FCall.getLastRedirectedAddress() = FCall.getCurrentCallingTerminal() = terminal of A FCall.getCurrentCalledTerminal() = terminal of B1 .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = null, .getCalledAddress() = C, .getLastRedirectedAddress() = B1 .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null GC1-ConnCreatedEvent-C * GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv-C GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-CiscoConferenceEndEv Connection for C is created (GC1) C gets dropped (GC2) GC2 invalid Conferece Ends Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 951 Message Sequence Charts Message Sequence Charts

Page 1015 diagram

Page 1016

WildCard Routepoint Interaction (Behavior Change) WildCard RoutePoint Redirects a Basic Incoming Call to IPPhone Configuration Phone A, B are in cluster devices. 4XXX is a wildcard routepoint Service parameter “Use WildCard pattern in CTI Call Info” is set to true. Procedure: Application invokes connect() at A to call 4000. 4XXX redirects the call to B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 952 Message Sequence Charts WildCard Routepoint Interaction (Behavior Change)

Page 1016 content

Page 1017

Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCurrentCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = 4000, .getCalledAddress() = 4XXX, .getCurrentCalledAddress() = 4XXX .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, getCurrentCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCurrentCalledAddress() = B .getCalledAddress() = 4XXX, GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-4XXX GC1-ConnInprogressEvent-4XXX GC1-CallCtlConnOfferedEv-4XXX GC1-ConnAlertingEvent-4XXX GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv-B GC1-TermConnCreatedEvent A initiates call to 4000 Connection of A created, called party info set Connection of 4XXX created 4XXX Redirects to B Connection for B created B is ringing Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 953 Message Sequence Charts Message Sequence Charts

Page 1017 diagram

Page 1018

Call info Events Actions .getLastRedirectedAddress() = 4XXX, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCurrentCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCalledAddress() = 4XXX, .getLastRedirectedAddress() = 4XXX, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of B GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-4XXX GC1-CallCtlConnDisconnectedEv-4XXX GC1-ConnConnectedEvent-B GC1-CallCtlConnEstablishedEv-B GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv 4XXX gets dropped B Answers WildCard Routepoint Interaction (Original Behavior) WildCard RoutePoint Redirects a Basic Incoming Call to IPPhone Notes / Caveats This configuration is not supported. This use case is only intended to show the call flow or events for the above use case with the Use WildCard pattern in CTI Call Info service parameter turned off. Applications should not count on this information to be correct, and to properly support Wildcard Routepoint scenarios, should look to adapting their applications so that they can support the new service parameter being enabled. An important thing to note is that a connection is created for the dialed DN, 4000. This connection, as well as the connection of 4XXX is not dropped from the call until the redirect happens. This means that if a Wildcard DN is configured on a phone or device, you will see connections for the calling party, 4000, and 4XXX. This basic call will have three connections, which may confuse applications, which might believe it to be a conference call. CiscoCall.isConference() would still return false in this scenario. As stated in previous sections, this extra connection is created in error, and applications should not rely on this connection being there. Configuration Phone A, B are in cluster devices. 4XXX is a wildcard routepoint Service parameter “Use WildCard pattern in CTI Call Info” is set to false / OFF. Procedure: Application invokes connect() at A to call 4000. 4XXX redirects the call to B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 954 Message Sequence Charts WildCard Routepoint Interaction (Original Behavior)

Page 1018 diagram

Page 1019

Call info Events Actions .getModifiedCallingAddress() = A, .getCurrentCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCurrentCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCurrentCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCurrentCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCurrentCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = 4000, .getCurrentCalledAddress() = 4000, .getCalledAddress() = 4000, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-4000 GC1-ConnInprogressEvent-4000 GC1-CallCtlConnOfferedEv-4000 GC1-ConnAlertingEvent-4000 GC1-ConnCreatedEvent-4XXX GC1-ConnInprogressEvent-4XXX GC1-CallCtlConnOfferedEv-4XXX A initiates call to 4000 Connection of A created, called party info set Connection of 4000 created Connection of 4XXX created Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 955 Message Sequence Charts Message Sequence Charts

Page 1019 diagram

Page 1020

Call info Events Actions .getModifiedCallingAddress() = A, .getCurrentCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = 4000, .getCurrentCalledAddress() = 4000, .getCalledAddress() = 4000, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCurrentCalledAddress() = B .getCalledAddress() = 4000, .getLastRedirectedAddress() = 4000, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCurrentCalledAddress() = B .getCalledAddress() = 4000, .getLastRedirectedAddress() = 4000, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of B GC1-ConnAlertingEvent-4XXX (note: 3 connections on the 2 party call.) GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-4XXX GC1-CallCtlConnDisconnectedEv-4XXX GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-4000 GC1-CallCtlConnDisconnectedEv-4000 GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv-B GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnConnectedEvent-B GC1-CallCtlConnEstablishedEv-B GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv 4XXX Redirects to B Connection for B created B is ringing B Answers External Call Control Use Cases External Call Control on Translation Pattern and CEPM Returns “continue” Configuration Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled. Procedure: Application invokes connect() at A to call B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 956 Message Sequence Charts External Call Control Use Cases

Page 1020 diagram

Page 1021

Result Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. CEPM returns continue and hence call will be presented to B1 (see use case “Basic Call initiated from JTAPI to the DN with Translation Pattern configured to transform called party” in the Use Cases for Calls Going Through Translation Pattern with CEPN Info in Cc Signals, on page 931 topic). External Call Control on Translation Pattern and CEPM Returns “divert” Configuration Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled. Procedure: Application invokes connect() at A to call B. Result Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. CEPM returns divert to C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 957 Message Sequence Charts Message Sequence Charts

Page 1021 content

Page 1022

Page 1022 diagram

Page 1023

Call info Events Actions .getCalledAddress() = BXXX, .getLastRedirectedAddress() = BXXX .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = C, .getCalledAddress() = BXXX, .getLastRedirectedAddress() = B1 .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of C GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-C GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C Answers External Call Control on Translation Pattern and CEPM Returns <reject> Configuration Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled. Procedure: Application invokes connect() at A to call B. Result Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. The routing rule for B says “Reject”<reject> CEPM returns reject. A receives ConnFailedEvent (cause = CtiCallRejected), ConnDisconnectedEv (cause = normal), CallInvalidEvent (caue = Normal). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 959 Message Sequence Charts Message Sequence Charts

Page 1023 diagram

Page 1024

Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null Cause = CtiCallRejected Cause = Normal GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnFailedEv-A GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-A GC1-CallCtlConnDisconnectedEv-A GC1-CallInvalidEvent GC1-CallObservationEndedEv A initiates call to B Connection of A created, CEPM Returns Reject External Call Control on Translation Pattern and CEPM Returns “continue” with Modified Calling and Called Parties Configuration Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled. Procedure: Application invokes connect() at A to call B. Result Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. CEPM returns continue with ModifiedCalling = “MA” and ModifiedCalled = “MB” Call will be extended to “C” (based on description for modified calling and modified called in divertTo routing directive, overrides the calling & called number transformation configured for translation pattern and the call is diverted to C. For details, see Use Cases for Calls Going Through Translation Pattern with CEPN Info in Cc Signals, on page 931.) Call Events: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 960 Message Sequence Charts Message Sequence Charts

Page 1024 diagram

Page 1025

Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = MA, .getCallingAddress() = A, .getCurrentCallingAddress() = A .getModifiedCalledAddress() = MB, .getCurrentCalledAddess() = MB, .getCalledAddress() = B1, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = MA, .getCallingAddress() = A, .getModifiedCalledAddress() = MB, .getCalledAddress() = MB, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of MB GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-MB GC1-ConnInprogressEvent-MB GC1-CallCtlConnOfferedEv-MB GC1-ConnAlertingEvent-MB GC1-CallCtlConnAlertingEv-MB GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-MB GC1-ConnConnectedEvent-MB GC1-CallCtlConnEstablishedEv-MB GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv A initiates call to B Connection of A created, called party info set CEPM Returns continue with modified calling/called Connection of MBcreated MB starts ringing BAnswers External Call Control on Translation Pattern and CEPM Returns “divert” with Modified Calling and Called Parties Configuration: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 961 Message Sequence Charts Message Sequence Charts

Page 1025 diagram

Page 1026

Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled. Procedure: Application invokes connect() at A to call B. Result: Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. CEPM returns divertTo = C, with ModifiedCalling = “MA” and ModifiedCalled = “MB” Call will be extended to “C” (based on description for modified calling and modified called in divertTo routing directive, overrides the calling & called number transformation configured for translation pattern and the call is diverted to C. For details, see Use Cases for Calls Going Through Translation Pattern with CEPN Info in Cc Signals, on page 931.) Call Events: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 962 Message Sequence Charts Message Sequence Charts

Page 1026 content

Page 1027

Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = MA, .getCallingAddress() = A, .getModifiedCalledAddress() = MB, .getCurrentCalledAddress() = C .getCalledAddress() = B1, .getLastRedirectedAddress() = MB, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = MA, .getCallingAddress() = A, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = MB, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of C GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-C GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv A initiates call to B Connection of A created, called party info set CEPM Returns divert to C, modify Called/Calling Connection of C created C starts ringing C Answers External Call Control on Translation Pattern and CEPM Returns “divert” with Modified Calling and Called Parties with resetCallHistory flag = resetLastHop Configuration Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 963 Message Sequence Charts Message Sequence Charts

Page 1027 diagram

Page 1028

Procedure: Application invokes connect at A to call B. Result Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. CEPM returns divertTo = C, with ModifiedCalling = “MA” and ModifiedCalled = “MB”, resetCallHistory = “resetLastHop” Call will be extended to “C” (based on description for modified calling and modified called in divertTo routing directive, overrides the calling & called number transformation configured for translation pattern and the call is diverted to C. For details, see Use Cases for Calls Going Through Translation Pattern with CEPN Info in Cc Signals, on page 931.) Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = MA, .getCallingAddress() = A, .getModifiedCalledAddress() = C, .getCalledAddress() = B1, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-C A initiates call to B Connection of A created, called party info set CEPM Returns divert to C, modify Called/Calling Connection of C created C starts ringing Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 964 Message Sequence Charts Message Sequence Charts

Page 1028 diagram

Page 1029

Call info Events Actions .getModifiedCallingAddress() = MA, .getCallingAddress() = A, .getModifiedCalledAddress() = C, .getCalledAddress() = B1, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of C GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C Answers External Call Control on Translation Pattern and CEPM Returns “divert” with Modified Calling and Called Parties with resetCallHistory flag = resetAll Configuration Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled. Procedure: Application invokes connect() at A to call B. Result Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. CEPM returns divertTo = “C”, with ModifiedCalling = “MA” and ModifiedCalled = “MB” C has a userRule configured to DivertTo = “D” with ModifiedCalling = “MMA”, ModifiedCalled = “MMB”, resetCallHistory = “resetAll” Call will be extended to “D” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 965 Message Sequence Charts Message Sequence Charts

Page 1029 diagram

Page 1030

Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A1, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = MMA, .getCallingAddress() = A, .getModifiedCalledAddress() = D, .getCurrentCalledAddress() = D, .getCalledAddress() = B1, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-D GC1-ConnInprogressEvent-D GC1-CallCtlConnOfferedEv-D GC1-ConnAlertingEvent-D GC1-CallCtlConnAlertingEv-D GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-D A initiates call to B Connection of A created, called party info set CEPM Returns divert to C, modify Called/Calling CEPM Returns divert to D, modify Called/Calling Connection of D created D starts ringing .getModifiedCallingAddress() = MMA, .getCallingAddress() = A, .getModifiedCalledAddress() = D, .getCalledAddress() = D, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of D GC1-ConnConnectedEvent-D GC1-CallCtlConnEstablishedEv-D GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv D Answers External Call Control on Translation Pattern and CEPM Returns <reject> and Service Parameter CTI Use Wildcard Pattern as calledPartyDN Is Set to False Configuration Phone A, B are in cluster devices. B matches the translation pattern BXXX which has calling and called party transformation defined to transform A to A1 and B to B1 and External Call Control is also enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 966 Message Sequence Charts Message Sequence Charts

Page 1030 diagram

Page 1031

Procedure: Application invokes connect() at A to call B. Result Dialed number B matches the translation pattern BXXX which has External Call Control enabled. This takes precedence and CUCM requests CEPM to get routing rule for B. The routing rule for B says “Reject”<reject> CEPM returns reject. Jtapi throws platform exception to the application. A receives ConnFailedEvent (cause = CtiCallRejected), ConnDisconnectedEv (cause = normal), CallInvalidEvent (caue = Normal). Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null Exception info: Could not meet post conditions of connect() Cause = CtiCallRejected Cause = Normal GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnFailedEv-A Jtapi throws Exception: PlatformException GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-A GC1-CallCtlConnDisconnectedEv-A GC1-CallInvalidEvent GC1-CallObservationEndedEv A initiates call to B Connection of A created, CEPM Returns Reject Transfer and External Call Control with Modified Calling and Called Parties Configuration Phone A, B are in cluster devices. B matches the translation pattern BXXX where External Call Contol is enabled. Phone C and D does not match any translation pattern, and have no External Call Control defined. Procedure: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 967 Message Sequence Charts Message Sequence Charts

Page 1031 diagram

Page 1032

Application invokes connect() at A to call B. CEPM returns divertTo = C, with ModifiedCalling = “MA” and ModifiedCalled = “MB”. C initiate transfer to D and completes the transfer. Result Transfer is successfully completed Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B1, .getCalledAddress() = B1, .getLastRedirectedAddress() = null, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = MA, .getCallingAddress() = A, .getModifiedCalledAddress() = C, .getCalledAddress() = B1, .getLastRedirectedAddress() = MB .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-C A initiates call to B Connection of A created, called party info set CEPM Returns divert to C, modify Called/Calling Connection of C created C starts ringing Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 968 Message Sequence Charts Message Sequence Charts

Page 1032 diagram

Page 1033

Call info Events Actions .getModifiedCallingAddress() = MA, .getCallingAddress() = A, .getModifiedCalledAddress() = C, .getCalledAddress() = C, .getLastRedirectedAddress() = MB, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of C .getModifiedCallingAddress() = C, .getCallingAddress() = C, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of C. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = C, .getCallingAddress() = C, .getModifiedCalledAddress() = D, .getCalledAddress() = D, .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of C. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = C, .getCallingAddress() = C, .getModifiedCalledAddress() = D, .getCalledAddress() = D, GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv CG1-CallCtlTermConnHeldEv GC2-ConsultCallActiveEvent GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-C GC2-CallCtlConnEstablishedEv-C GC2-ConnCreatedEvent-D GC2-ConnInprogressEvent-D GC2-CallCtlConnOfferedEv-D GC2-ConnAlertingEvent-D GC2-CallCtlConnAlertingEv-D GC2-TermConnCreatedEvent GC2-TermConnRingingEvent GC2-CallCtlTermConnRingingEv GC2-ConnConnectedEvent-D GC2-CallCtlConnEstablishedEv-D GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv C Answers C consult transfer to D Connection for C created (GC2) Connection for D created (GC2) D Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 969 Message Sequence Charts Message Sequence Charts

Page 1033 diagram

Page 1034

Call info Events Actions .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of C. .getCurrentCalledTerminal() = terminal of D Ev.getOriginalCall = GC2 (OCall) Ev.getSurvivingCall = GC1 (FCall) OCall.getModifiedCallingAddress() = C, OCall.getCallingAddress() = C, OCall.getModifiedCalledAddress() = D, OCall.getCalledAddress() = D, OCall.getLastRedirectedAddress() = OCall.getCurrentCallingTerminal() = terminal of C OCall.getCurrentCalledTerminal() = terminal of D FCall.getModifiedCallingAddress() = MA, FCall.getCallingAddress() = A, FCall.getModifiedCalledAddress() = C, FCall.getCalledAddress() = C, FCall.getLastRedirectedAddress() = MB FCall.getCurrentCallingTerminal() = terminal of A FCall.getCurrentCalledTerminal() = terminal of C .getModifiedCallingAddress() = MA, .getCallingAddress() = A, .getModifiedCalledAddress() = D, .getCurrentCalledAddress() = D, .getCalledAddress() = B1, .getLastRedirectedAddress() = C .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of D GC1-CiscoTermConnSelectChangedEv GC2-CiscoTermConnSelectChangedEv GC1-CiscoTransferStartEv GC2-CiscoCallChangedEv GC1-ConnCreatedEvent-D GC1-ConnConnectedEvent-D GC1-CallCtlConnEstablishedEv-D GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv Transfer Starts D gets added to GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 970 Message Sequence Charts Message Sequence Charts

Page 1034 diagram

Page 1035

Call info Events Actions GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-D GC2-CallCtlConnDisconnectedEv-D GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-C GC1-CallCtlConnDisconnectedEv-C GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-CiscoTransferEndEv D gets dropped from GC2 C gets dropped from GC1 C gets dropped fromGC2 GC2 Invalid Transfer ends Chaperone Use Cases Call Is Redirected to a Hunt List of Chaperones and the Chaperone Enables Call Recording and Conferences in the Called Party Configuration A calls X, X’s DN matches the translation pattern where External Call Control is enabled. CEPM determines this call needs to have a chaperone’s supervise. CEPM returns the permit decision with the obligation <divert>, destination HuntPilot B, which is a hunt pilot of chaperones, and a reason string “chaperone”. CUCM redirects the call to the hunt pilot B, and the chaperone C1 answers the call. After talking to A briefly and discovered that A intended to talk to D, the chaperone C1 starts to establish a conference to D. C1 presses the conference softkey and dials D. CUCM queries CEPM for the call, with calling user C1 with DN C1, and called user D with DN D. CEPM returns the response with permit decision with <continue> call routing directive, since the policy server detects that the caller is the chaperone. CUCM rings D’s phone and D answers the call. C1 presses the conference softkey again, and the conference is established. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 971 Message Sequence Charts Chaperone Use Cases

Page 1035 diagram

Page 1036

The chaperone C1 presses the “record” softkey. This triggers the call recording being setup from C1’s IP phone to the recorder. As one of the steps to establish recording calls to the recorder, two recording calls setup are first sent to the BIB of C1’s IP phone (INVITE for SIP phone and SCCP only the media message are involved). Note only one recording is shown in the picture. As another step to establish the recording calls to the recorder, the two calls are then redirected to the recorder. When the call recording is eablished successfully, the recording warning tone is playing to the C1’s phone. The recording warning tone is enabled by setting service parameter “Play Recording Notification Tone To Observed Target” to True. After comfirming the call recording is established successfully, the chaperone reads an announcement to both A and D and informs them the call is being recorded. A and D starts to talk under the supervision of the chaperone. NOTE Chaperones have limited abilities in what they can do on a call. The most obvious example is that they cannot put the call on hold, because they are required to be on the call at all times. To learn more about Chaperone limitations, please see the related sections of the External Call Control FFS. Call Events: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 972 Message Sequence Charts Message Sequence Charts

Page 1036 content

Page 1037

Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getLastRedirectedParty() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCurrentCalledAddress() = B .getCalledAddress() = X, .getLastRedirectedAddress() = X, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCurrentCalledAddress() = B .getCalledAddress() = X, .getLastRedirectedAddress() = X, GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-CiscoHuntConnCreatedEv-B GC1-ConnInProgressEv-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEv-B GC1-CallCtlConnAlertingEv-B GC1-ConnCreatedEvent-C1 GC1-ConnInprogressEvent-C1 GC1-CallCtlConnOfferedEv-C1 GC1-ConnAlertingEvent-C1 GC1-CallCtlConnAlertingEv-C1 A initiates call to X Connection of A created, Hunt connection created (see Hunt List section) Connection of C1 created C1 starts ringing Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 973 Message Sequence Charts Message Sequence Charts

Page 1037 diagram

Page 1038

Call info Events Actions .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null Reason=REASON_EXTERNALCALLCONTROL .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCurrentCalledAddress() = B .getCalledAddress() = X, .getLastRedirectedAddress() = X, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of C1 Reason=REASON_EXTERNALCALLCONTROL .getModifiedCallingAddress() = C1, .getCallingAddress() = C1, .getModifiedCalledAddress() = .getCurrentCalledAddress() = .getCalledAddress() = .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of C1 .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = C1, .getCallingAddress() = C1, .getModifiedCalledAddress() = D .getCurrentCalledAddress() = D .getCalledAddress() = D GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-C1 GC1-ConnConnectedEvent-C1 GC1-CallCtlConnEstablishedEv-C1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-CallCtlTermConnHeldEv-TermC1 GC2-CiscoConsultCallActiveEv GC2-ConnCreatedEv-C1 GC2-CallCtlTermConnTalkingEv-TermC1 GC2-CallCtlConnDialingEv-C1 GC2-CallCtlConnEstablishedEv-C1 GC2-CiscoConnCreatedEv-D GC2-ConnInProgressEv-D GC2-CallCtlConnOfferedEv-D GC2-ConnAlertingEv-D C1 Answers C1 initiates conference Conference consult call to D , D answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 974 Message Sequence Charts Message Sequence Charts

Page 1038 diagram

Page 1039

Call info Events Actions .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of C1 .getCurrentCalledTerminal() = terminal of D GC2-CallCtlConnAlertingEv-D GC2-ConnConnectedEv-D GC2-CallCtlConnEstablishedEv D CiscoCallChangedEv final call = GC1, consult call = GC2 GC1-ConnCreatedEv D GC1-ConnConnectedEv D GC1-CallCtlConnEstablishedEvD GC2-ConnDisconntedEv C1 GC2-ConnDisconntedEv D GC2-CallCtlConnDisconnectedEv C1 GC2-CallCtlConnDisconnectedEv D GC2-CallCtlTermConnDroppedEv C1 GC2-CallCtlTermConnDroppedEv D GC2-CallInvalidEv Normal recording events when recording is initiated on a conference call will be received. InvalidStateException : Did not meet pre conditions. Call 2 merges Conn for D created on GC1 Call 2 cleaned up Chaperone C1 starts recording Chaperone C1 tries to redirect the call Call Is Redirected to a Hunt List of Chaperones and the Chaperone Conferences in the Called Party From Application Configuration A calls X, X’s DN matches the translation pattern where External Call Control is enabled. CUCM redirect the call to the hunt pilot B. Call is intercepted by the chaperone and the chaperone C1 answers the call. After talking to A briefly and discovered that A intended to talk to D, the chaperone C1 starts to establish a conference to D. C1 initiates a consult call to D. A new global call id GC2 is created. CUCM rings D’s phone and D answers the call. C1 invokes GC2.conference(GC1) from application. At this step, request for establishing the conference would fail. Jtapi would throw InvalidStateException with the error code as “Call state not valid”. In order to establish a conference successfully, application must invoke the conference by passing the CI of the call in which chaperone is the controller as the primary CI. So in this case, if application invokes GC1.conference(GC2), it would be able to establish the conference successfully and if application invokes GC2.conference(GC1), Jtapi would throw an exception. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 975 Message Sequence Charts Message Sequence Charts

Page 1039 diagram

Page 1040

Also application can use CiscoConnection.isChaperone() API to determine controller is chaperone on which call. Call Events: Call info Events Actions .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = “”, .getCalledAddress() = “”, .getLastRedirectedParty() = “”, .getCurrentCallingTerminal() = Terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCurrentCalledAddress() = B .getCalledAddress() = X, .getLastRedirectedAddress() = X, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCurrentCalledAddress() = B .getCalledAddress() = X, .getLastRedirectedAddress() = X, GC1-CallActiveEvent GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv-A GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-CiscoHuntConnCreatedEv-B GC1-ConnInProgressEv-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEv-B GC1-CallCtlConnAlertingEv-B GC1-ConnCreatedEvent-C1 GC1-ConnInprogressEvent-C1 GC1-CallCtlConnOfferedEv-C1 A initiates call to X Connection of A created, Hunt connection created (see Hunt List section) Connection of C1 created Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 976 Message Sequence Charts Message Sequence Charts

Page 1040 diagram

Page 1041

Call info Events Actions .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = null Reason=REASON_EXTERNALCALLCONTROL .getModifiedCallingAddress() = A, .getCallingAddress() = A, .getModifiedCalledAddress() = B, .getCurrentCalledAddress() = B .getCalledAddress() = X, .getLastRedirectedAddress() = X, .getCurrentCallingTerminal() = terminal of A. .getCurrentCalledTerminal() = terminal of C1 Reason=REASON_EXTERNALCALLCONTROL .getModifiedCallingAddress() = C1, .getCallingAddress() = C1, .getModifiedCalledAddress() = .getCurrentCalledAddress() = .getCalledAddress() = .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of C1 GC1-ConnAlertingEvent-C1 GC1-CallCtlConnAlertingEv-C1 GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv-C1 GC1-ConnConnectedEvent-C1 GC1-CallCtlConnEstablishedEv-C1 GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-CallCtlTermConnHeldEv-TermC1 GC2-CiscoConsultCallActiveEv GC2-ConnCreatedEv-C1 GC2-CallCtlTermConnTalkingEv-TermC1 GC2-CallCtlConnDialingEv-C1 GC2-CallCtlConnEstablishedEv-C1 C1 starts ringing C1 Answers C1 initiates conference Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 977 Message Sequence Charts Message Sequence Charts

Page 1041 diagram

Page 1042

Call info Events Actions .getCurrentCalledTerminal() = null .getModifiedCallingAddress() = C1, .getCallingAddress() = C1, .getModifiedCalledAddress() = D .getCurrentCalledAddress() = D .getCalledAddress() = D .getLastRedirectedAddress() = .getCurrentCallingTerminal() = terminal of C1 .getCurrentCalledTerminal() = terminal of GC2-CiscoConnCreatedEv-D GC2-ConnInProgressEv-D GC2-CallCtlConnOfferedEv-D GC2-ConnAlertingEv-D GC2-CallCtlConnAlertingEv-D GC2-ConnConnectedEv-D GC2-CallCtlConnEstablishedEv D InvalidStateException : Call state not valid. CiscoCallChangedEv final call = GC1, consult call = GC2 GC1-ConnCreatedEv D GC1-ConnConnectedEv D GC1-CallCtlConnEstablishedEv D GC2-ConnDisconntedEv C1 GC2-ConnDisconntedEv D GC2-CallCtlConnDisconnectedEv C1 GC2-CallCtlConnDisconnectedEv D GC2-CallCtlTermConnDroppedEv C1 GC2-CallCtlTermConnDroppedEv D GC2-CallInvalidEv Conference consult call to D , D answers C1 completes the conference by invoking GC2.conference(GC1) from application. C1 tries to complete the conference by invoking GC1.conference(GC2_from application Extension Mobility Cross Cluster Call info Events Actions CiscoTerminal.getLoginType() returns CiscoTerminal.NO_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN CiscoTerminal.getLoginType() returns CiscoTerminal.VISITOR_LOGIN Events to provider observer CiscoAddrCreatedEv A CiscoTermCreatedEv TERMA

User1 has a device profile configured with DN A in cluster1. This profile is included in the control list of application. User1 goes to a visiting cluster and EM login to a device TERMA. Device registers to cluster1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 978 Message Sequence Charts Extension Mobility Cross Cluster

Page 1042 diagram

Page 1043

Call info Events Actions getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT CiscoTerminal.getLoginType() returns CiscoTerminal.NO_LOGIN CiscoAddrRemovedEv A CiscoTermRemovedEv TERMA User1 logs off from the Device getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN CiscoTerminal.getLoginType() returns CiscoTerminal.NATIVE_LOGIN CiscoAddrCreatedEv A CiscoTermCreatedEv TERMA 2. User1 has a device profile configured with DN A in cluster1. This device profile is included in the control list of application. User1 EM into a device TERMA on cluster1. Device re-registers with DN A. The device TERMA is not in application control listapplication control list getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT CiscoAddrRemovedEv A CiscoTermRemovedEv TERMA User1 log off from the device. Device re-registers to cluster1 with default DN. getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN CiscoAddrRemovedEv X CiscoAddrCreatedEv A 3. EM into a controlled Device: User1 has a device profile configured with DN A in cluster1. This device profile is included in the control list of application. User1 EM into a device TERMA on cluster1. TERMA with default DN X is in application control list. Device re-registers with DN A. getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT CiscoAddrRemovedEv A CiscoAddrCreatedEv X User1 logs out of the device. Device Unregister, Device and line out of service Device Register to CM with default DN X. getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv. CAUSE_EM_LOGIN_ PROFILE_REMOVE getCiscoCause() returns CiscoProvEv. CAUSE_EM_LOGOUT_ PROFILE_REMOVE CiscoAddrCreatedEv A CiscoTermCreatedEv TERMA CiscoAddrRemovedEv A CiscoTermRemovedEv TERMA 4. Application uses user1 userid. Device profile agent1 is added to application control list after application is started User EMs into a device TERMA and gets the device profile. Agent1 device profile is removed from application control list Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 979 Message Sequence Charts Message Sequence Charts

Page 1043 diagram

Page 1044

Call info Events Actions getCiscoCause() returns CiscoProvEv.CAUSE_EM getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT CiscoTermCreatedEv TERMX CiscoAddrAddedToTerminalEv AddrA CiscoAddrRemovedFromTerminalEv AddA CiscoTermRemovedEv TERMx 5. EMCC scenario resulting in CiscoAddrAddedToTerminalEv and CiscoAddrRemovedFromTerminalEv Cluster1 has application with Terminal TermA (address A) in control list. User1 is a device profile which is configured with line A is included in app control list. User goes to a visiting cluster and logs into a device (TermX, Addr X). TermX registers with cluster1 with address A User logs out of device TermX getCiscoCause() returns CiscoProvEv. CAUSE_EM_LOGIN_ PROFILE_ADD getCiscoCause() returns CiscoProvEv. CAUSE_EM_LOGIN_ PROFILE_ADD getCiscoCause() returns CiscoProvEv. CAUSE_EM_LOGOUT_ PROFILE_REMOVE getCiscoCause() returns CiscoProvEv. CAUSE_EM_LOGOUT_ PROFILE_REMOVE CiscoAddrCreatedEv A CiscoTermCreatedEv TERMA CiscoAddrRemovedEv A CiscoTermRemovedEv TERMA 6. Device profile Agent1 with DN A is logged into a device TERMA. User1 opens provider and then adds the profile Agent1 to the control list through the admin pages. User1 then removes the profile from the control list getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT CiscoAddrCreatedEv A CiscoTermCreatedEv TERMA CiscoAddrRemovedEv A CiscoTermRemovedEv TERMA 7. Device profile Agent1 is not in the applications control list but it is there as a controlled profiles for extension mobility for user1. User1 opens provider and logs into terminal TERMA with profile agent1 and the same user id with which it had opened the provider. User1 logs out of the device getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT CiscoAddrCreatedEv A CiscoTermCreatedEv TERMA CiscoAddrRemovedEv A CiscoTermRemovedEv TERMA 8. Device profile Agent1 (DN A) is in the applications control list with user as user1. User1 opens the provider and does an EM login into TERMA with profile as agent1. TERMA is not in control list. User1 logs out of TERMA. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 980 Message Sequence Charts Message Sequence Charts

Page 1044 diagram

Page 1045

Call info Events Actions getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGIN getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT getCiscoCause() returns CiscoProvEv.CAUSE_EM_LOGOUT CiscoAddrRemovedEv X CiscoAddrCreatedEv A CiscoAddrRemovedEv A CiscoAddrCreatedEv X 9. Device profile Agent1 (DN A) is in the applications control list with user as user1. User1 opens the provider and does an EM login into TERMA with profile as agent1. TERMA is in control list with default DN as X. User1 logs out of TERMA. End to End Session ID for Calls Session ID in a Basic Call Scenario Application has already opened provider and observing TermA and TermB Call information Events Action GC1 CallActiveEv A GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEV TermA Application makes a call between TermA and TermB ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnA) = A's LocalUUID GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 981 Message Sequence Charts End to End Session ID for Calls

Page 1045 diagram

Page 1046

Call information Events Action GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAltertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB Application makes a call between TermA and TermB ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnA) = B's LocalUUID ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB) = B's LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB) = A's LocalUUID GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEv TermB ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB) = B's LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB) = A's LocalUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getLocalUUID(termConnA) = A's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getLocalUUID(termConnB) = B's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getPeerUUID(termConnA) = B's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getPeerUUID(termConnB) = A's localUUID GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConNActiveEv B GC1 CallCtlTermConnTalkingEv B B answers SessionID for a Basic Call involving SIP Endpoints Application has already opened provider and observing SIP terminals TermA and TermB Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 982 Message Sequence Charts Message Sequence Charts

Page 1046 diagram

Page 1047

Call information Events Action ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnA) = null ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnA) = null ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnA) = A's local UUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnA) = B's localUUID ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB) = null ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB) = A's LocalUUID GC1 CallActiveEv A GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEV TermA GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAltertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEv TermB Application makes a call between TermA and TermB Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 983 Message Sequence Charts Message Sequence Charts

Page 1047 diagram

Page 1048

Call information Events Action ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB) = B's LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB) = A's LocalUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getLocalUUID(termConnA) = A's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getLocalUUID(termConnB) = B's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getPeerUUID(termConnA) = B's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getPeerUUID(termConnB) = A's localUUID GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConNActiveEv B GC1 CallCtlTermConnTalkingEv B B answers SessionIDs for Calls Involving Shared Lines and Hold Resume B and B are lines shared on two terminals. Application has opened provider and observed A, B and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 984 Message Sequence Charts Message Sequence Charts

Page 1048 diagram

Page 1049

Call information Events Action ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnA) = A's LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnA) = B's or (B')'s LocalUUID ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB) = B's LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB) = A's LocalUUID ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB') = (B')'s LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB') = A's LocalUUID Application makes a call between TermA and TermB Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 985 Message Sequence Charts Message Sequence Charts

Page 1049 diagram

Page 1050

Call information Events Action GC1 CallActiveEv A GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEV TermA GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAltertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 986 Message Sequence Charts Message Sequence Charts

Page 1050 diagram

Page 1051

Call information Events Action TermB GC1 TermConnCreatedEv TermB' GC1 TermConnRingingEv TermB' GC1 CallCtlTermConnRingingEv TermB' ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB) = B's LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB) = A's LocalUUID ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB') = (B')'s LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB') = A's LocalUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getLocalUUID(termConnA) = A's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getLocalUUID(termConnB) = B's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getPeerUUID(termConnA) = B's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getPeerUUID(termConnB) = A's localUUID GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConNActiveEv B GC1 CallCtlTermConnTalkingEv TermB GC1 TermConnPassiveEv TermB' GC1 CallCtlTermConnBridgedEv TermB' B answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 987 Message Sequence Charts Message Sequence Charts

Page 1051 diagram

Page 1052

Call information Events Action ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB) = B's LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB) = A's LocalUUID ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB') = (B')'s LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB') = A's LocalUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getLocalUUID(termConnA) = A's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getLocalUUID(termConnB) = B's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getLocalUUID(termConnB') = (B')'s localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getPeerUUID(termConnA) = B's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getPeerUUID(termConnB) = A's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getPeerUUID(termConnB') = A's localUUID GC1 TermConNActiveEv TermB GC1 CallCtlTermConnHeldState TermB GC1 TermConnActiveEv termB' GC1 CallCtlTermConnHeldState TermB' B puts the call on hold Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 988 Message Sequence Charts Message Sequence Charts

Page 1052 diagram

Page 1053

Call information Events Action ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB) = B's LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB) = A's LocalUUID ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnB') = (B')'s LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnB') = A's LocalUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getLocalUUID(termConnA) = A's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getLocalUUID(termConnB) = B's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getLocalUUID(termConnB') = (B')'s localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getPeerUUID(termConnA) = (B')'s localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getPeerUUID(termConnB) = A's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(B)).getPeerUUID(termConnB') = A's localUUID GC1 TermConnActiveEv TermB' GC1 CallCtlTermConnTalkingEv TermB' GC1 TermConnPassiveEv TermB GC1 CallCtlTermConnBridgedEv TermB B' resumes the call SessionID when Call is Redirected to a Third Party Application has already opened provider and observed A,B and C and establishes a call between A and B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 989 Message Sequence Charts Message Sequence Charts

Page 1053 diagram

Page 1054

Page 1054 diagram

Page 1055

Call information Events Action ((CiscoConnection)Ev,getConnection()).getLocalUUID(termConnC) = C's LocalUUID ((CiscoConnection)Ev,getConnection()).getPeerUUID(termConnC) = A's LocalUUID CallInfo : CurrentCallingParty = A CurrentCalledParty = C Reason = CiscoFeatureReason.REASON_REDIRECT (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getLocalUUID(termConnA) = A's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(C)).getLocalUUID(termConnC) = C's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(A)).getPeerUUID(termConnA) = C's localUUID (CiscoConnection)(CiscoProvider.getCall(gcid, cid).getConnection(C)).getPeerUUID(termConnC) = A's localUUID GC1 CallActiveEv C GC1 ConnCreatedEv C GC1 ConnConnectedEv C GC1 CallCtlConnInitiatedEv C GC1 TermConnCreatedEv TermC GC1 TermConnActiveEV TermC GC1 CallCtlTermConnTalkingEv TermC GC1 CallCtlConnDialingEv C GC1 CallCtlConnEstablishedEv C GC1TerConnDroppedEv TermB CallCtlTermConnDroppedEv TermB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B Application redirects the call from B to C Forced Authorization and Customer Matter Codes Scenario One The application controls A and B; B requires a forced authorization code (FAC) to extend the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 991 Message Sequence Charts Forced Authorization and Customer Matter Codes

Page 1055 diagram

Page 1056

Event Action NEW META EVENT_________META_CALL_STARTING CallActiveEv Cause: CAUSE_NEW_CALL ConnCreatedEv A Cause: CAUSE_NORMAL ConnConnectedEv A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL TermConnCreatedEv SEPA Cause: Other: 0 TermConnActiveEv SEPA Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL NEW META EVENT_________META_CALL_PROGRESS CallCtlConnDialingEv A NEW META EVENT_________META_CALL_PROGRESS CiscoToneChangedEv ToneType = CiscoTone.ZIPZIP cause = CiscoCallEv.CAUSE_FAC_CMC getWhichCodRequired = CiscoToneChangedEv. FAC_REQUIRED A calls B by using call.Connect(), or A places a consult call to B by using Call.Consult(). NEW META EVENT_________META_CALL_ADDITIONAL_PARTY ConnCreatedEv B ConnInProgressEv B CallCtlConnOfferedEv B NEW META EVENT_________META_CALL_PROGRESS ConnAlertingEv B CallCtlConnAlertingEv B TermConnCreatedEv BTermConnRingingEv B CallCtlTermConnRingingEv B ConnConnectedEv B CallCtlConnEstablishedEv B Application enters additional digits by using CiscoConnection.addToAddress. TermConnActiveEv B B answers the call. Scenario Two The application controls A and B; B requires both an FAC and a CMC (client matter code) to extend the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 992 Message Sequence Charts Message Sequence Charts

Page 1056 diagram

Page 1057

Event Action NEW META EVENT_________META_CALL_STARTING CallActiveEv Cause: CAUSE_NEW_CALL ConnCreatedEv A Cause: CAUSE_NORMAL ConnConnectedEv A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL TermConnCreatedEv SEPA Cause: Other: 0 TermConnActiveEv SEPA Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL NEW META EVENT_________META_CALL_PROGRESS CallCtlConnDialingEv A NEW META EVENT_________META_CALL_PROGRESS CiscoToneChangedEv ToneType = CiscoTone.ZIPZIP cause = CiscoCallEv.CAUSE_FAC_CMC getWhichCodRequired = CiscoToneChangedEv. FAC_CMC_REQUIRED A calls B by using call.Connect(), or A places a consult call to B by using Call.Consult(). NEW META EVENT_________META_CALL_PROGRESS CiscoToneChangedEv ToneType = CiscoTone.ZIPZIP cause = CiscoCallEv.CAUSE_FAC_CMC getWhichCodRequired = CiscoToneChangedEv. CMC_REQUIRED Application enters FAC code digits with # termination by using CiscoConnection.addToAddress within the T302 timer. NEW META EVENT_________META_CALL_ADDITIONAL_PARTY ConnCreatedEv B ConnInProgressEv B CallCtlConnOfferedEv B NEW META EVENT_________META_CALL_PROGRESS ConnAlertingEv B CallCtlConnAlertingEv B TermConnCreatedEv B TermConnRingingEv B CallCtlTermConnRingingEv B Application enters CMC code digits with

terminated by using

CiscoConnection.addToAddress within T302 timer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 993 Message Sequence Charts Message Sequence Charts

Page 1057 diagram

Page 1058

Event Action ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv B CallCtlTermConnTalkingEv B B answers the call. Scenario Three The application controls A and B; B requires a CMC, and the application enters an invalid code. Event Action NEW META EVENT_________META_CALL_STARTING CallActiveEv Cause: CAUSE_NEW_CALL ConnCreatedEv A Cause: CAUSE_NORMAL ConnConnectedEv A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL TermConnCreatedEv SEPA Cause: Other: 0 TermConnActiveEv SEPA Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL NEW META EVENT_________META_CALL_PROGRESS CallCtlConnDialingEv A NEW META EVENT_________META_CALL_PROGRESS CiscoToneChangedEvToneType = CiscoTone.ZIPZIP cause = CiscoCallEv.CAUSE_FAC_CMC getWhichCodRequired = CiscoToneChangedEv. CMC_REQUIRED A calls B by using call.Connect(), or A places a consult call to B by using Call.Consult(). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 994 Message Sequence Charts Message Sequence Charts

Page 1058 diagram

Page 1059

Event Action NEW META EVENT_________META_CALL_PROGRESS ConnFailedEv A CallCtlConnFailedEv A getCiscoCause () = CiscoCallEv.FAC_CMC NEW META EVENT_________META_CALL_ENDING TermConnDroppedEv CallCtlTermConnDropped ConnDisconnectedEv CallCtlConnDisconnectedEv CallInvalidEv CallObservationEndedEv The application enters the incorrect CMC digits (# terminated) by using CiscoConnection.addToAddress within the T302 timer limit. The application receives reorder tone. Scenario Four The application controls both A and B; A calls B; B redirects the call to C, which needs both an FAC and a CMC. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 995 Message Sequence Charts Message Sequence Charts

Page 1059 diagram

Page 1060

Event Action NEW META EVENT_________META_CALL_STARTING CallActiveEv Cause: CAUSE_NEW_CALL ConnCreatedEv A Cause: CAUSE_NORMAL ConnConnectedEv A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL TermConnCreatedEv SEPA Cause: Other: 0 TermConnActiveEv SEPA Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL NEW META EVENT_________META_CALL_PROGRESS CallCtlConnDialingEv A NEW METAEVENT_________META_CALL_ADDITIONAL_PARTY ConnCreatedEv B ConnInProgressEv B CallCtlConnOfferedEv B NEW META EVENT_________META_CALL_PROGRESS ConnAlertingEv B CallCtlConnAlertingEv B TermConnCreatedEv SEPB TermConnRingingEv SEPB CallCtlTermConnRingingEv SEPB ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv SEPB CallCtlTermConnTalkingEv SEPB A calls B by using call.Connect(), or A places a consult call to B by using Call.Consult(). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 996 Message Sequence Charts Message Sequence Charts

Page 1060 diagram

Page 1061

Event Action NEW META EVENT_________META_CALL_REMOVING_PARTY TermConnDroppedEv SEPB CallCtlTermConnDroppedEv SEPB Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED CiscoCause: CAUSE_NORMALUNSPECIFIED ConnDisconnectedEv B Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED CallCtlConnDisconnectedEv B Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED CiscoCause: CAUSE_NORMALUNSPECIFIED NEW META EVENT_________META_CALL_PROGRESS ConnCreatedEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED NEW META EVENT_________META_CALL_PROGRESS ConnInProgressEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED CallCtlConnOfferedEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_REDIRECTED CiscoCause: CAUSE_NORMALUNSPECIFIED NEW META EVENT_________META_CALL_PROGRESS ConnAlertingEv A Cause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED CallCtlConnAlertingEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL CiscoCause: CAUSE_NORMALUNSPECIFIED NEW META EVENT_________META_CALL_PROGRESS ConnConnectedEv C Cause: CAUSE_NORMAL CiscoCause: CAUSE_NOERROR CallCtlConnEstablishedEv C Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL CiscoCause: CAUSE_NOERROR B issues a redirect request to C and passes an FAC and a CMC code. Scenario Five Application controls the device Route Point (RP) and registers the RP. A and B are PNO and within the Cisco Unified Communications Manager cluster. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 997 Message Sequence Charts Message Sequence Charts

Page 1061 diagram

Page 1062

Fields Event Action State = ROUTE getCurrentRouteAddress () = RP getCallingAddress () = A getCallingTerminal () = SEPA (Terminal associated with A) RouteEvent Call arrives at RP State = ROUTE_USED getCallingAddress () = A getCallingTerminal () = SEPA (Terminal associated with A) getRouteUsed () = B RouteUsedEvent Application invokes selectRoute(routeselected[], callingsearchspace, modifiyingcallingnumber[], preferredOriginalCdNumber[], preferredOriginalCdOption[], facCode[], cmcCode[]) where routeSelected[] = BcallingSearchSpace = CiscoRouteSession.DEFAULT_SEARCH_SPACEmodifyingCgNumber = null, preferredOriginalCdNumber = null, preferredOriginalCdOption = CiscoRouteSession.DONOT_RESET_ORIGINALCALLED, facCode[] = “facCode for B”cmcCode[] = “cmcCode for B” State = ROUTE_ENDgetRouteAddress () = RP RouteEndEvent Application invokes endRoute (ERROR_NONE) Hairpin Support Result Expected Behavior Use Case Pre-Condition S.No. A and C are connected. At A: It is connected to B. A’s type is CiscoAddress.Internal B’s type is CiscoAddress.External At C: It is connected to B. C’s type is CiscoAddress.Internal B’s type is CiscoAddress.External A calls B via gateway. B transfers call to C via gateway. B completes the transfer and goes out of scenario. Now IP Phones A and C are connected IP Phones A and C are in same cluster, IP phone B is in another cluster. JTAPI observes A and C. Gateway does not pass new party information to each other. There will be no transfer start and end events as transfer controller is not a controlled device. 1 A and C are connected. At A: It is connected to C. A’s type is CiscoAddress.Internal C’s type is CiscoAddress.External At C: It is connected to A. C’s type is CiscoAddress.Internal A’s type is CiscoAddress.External A calls B via gateway. B transfers call to C via gateway. B completes the transfer and goes out of scenario. Now IP Phones A and C are connected. IP Phones A and C are in same cluster, IP phone B is in another cluster. JTAPI observes A and C. Gateway is able to pass new party information to each other. 2 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 998 Message Sequence Charts Hairpin Support

Page 1062 diagram

Page 1063

Result Expected Behavior Use Case Pre-Condition S.No. A, B and C are in conference call. At A and B, ConferenceCallStateChanged event has participantInfo with following types: A: CiscoAddress.Internal B: CiscoAddress.Internal C: CiscoAddress.External A calls B. B does a conference call to C via gateway. B completes the conference and all A, B and C are in conference. IP Phones A and B are in same cluster, IP phone C is in another cluster. JTAPI observes A and B. 3 A, B and C are in conference call. At A and B, ConferenceCallStateChanged event has participantInfo with following types: A: CiscoAddress.Internal B: CiscoAddress.Internal C: CiscoAddress.External A calls B. B does a conference call to C via gateway. B completes the conference and all A, B and C are in conference. IP Phones A and B are in same cluster, IP phone C is in another cluster. JTAPI observes A, B and C. 4 A, B and C are in conference call. At A and B, ConferenceCallStateChanged event has participantInfo with following types: A: CiscoAddress.Internal B: CiscoAddress.Internal C: CiscoAddress.External A calls B. B does a conference call to D via gateway. D transfers the call to C. B completes the conference and all A, B and C are in conference. IP Phones A, B, C are in same cluster, IP phone D is in another cluster. JTAPI observes A, B and C. Gateway is able to pass new party information to each other. 5 A, B and C are in conference call. At A and B, ConferenceCallStateChanged event has participantInfo with following types: A: CiscoAddress.Internal B: CiscoAddress.Internal D: CiscoAddress.External A calls B. B does a conference call to D via gateway. D transfers the call to C. B completes the conference and all A, B and C are in conference. IP Phones A, B, C are in same cluster, IP phone D is in another cluster. JTAPI observes A, B and C. Gateway does not pass new party information to each other. 6 A and C are connected. At A: It is connected to C. A’s type is CiscoAddress.Internal C’s type is CiscoAddress.External At C: It is connected to A. C’s type is CiscoAddress.Internal A’s type is CiscoAddress.External A calls B via gateway. B redirects call to C. Now IP Phones A and C are connected. IP Phones A and C are in same cluster, IP phone B is in another cluster. JTAPI observes A and C. 7 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 999 Message Sequence Charts Message Sequence Charts

Page 1063 diagram

Page 1064

Half Duplex Media RTP Event at A and B. Check Interface RTP Events Action Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false A – CiscoRTPInputStartedEv CiscoRTPOutputStartedEv B – CiscoRTPInputStartedEv CiscoRTPOutputStartedEv A calls B, B answers the call. Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns True A – CiscoRTPInputStoppedEv CiscoRTPOutputStoppedEv B – CiscoRTPInputStoppredEv CiscoRTPOutputStoppedEv A-CiscoRTPInputStartedEv B puts Call on hold Ev.isHalfDuplex() returns True Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false Ev.isHalfDuplex() returns false A- CiscoRTPInputStoppredEv A – CiscoRTPInputStartedEv CiscoRTPOutputStartedEv B – CiscoRTPInputStartedEv CiscoRTPOutputStartedEv B Retrieves the Call Hunt List Configuration • HuntList feature is enabled for all use cases, unless otherwise indicated • HuntList pilot1 : 2000 • HuntList1 LineGroup Member : 3001, 3002, 3003 • HuntList pilot2: 4000 • HuntList2 LineGroup Member : 5001, 5002, 5003 Cisco Hunt Address mentioned in the call models below indicates that CiscoAddress.getType() returns CiscoAddress.HUNT_PILOT. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1000 Message Sequence Charts Half Duplex Media

Page 1064 diagram

Page 1065

Scenario 1 Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA CallingParty = A, current calling = A Called Party = null, current called = null Lrp = null GC1:CallCtlConnDialingEv A GC1:CallCtlConnEstablishedEv A GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B CallingParty = A, current calling = A Called Party = B, current called = B Lrp = null A (1000) calls Hunt Pilot B (2000), Application is observing only A. GC1 is the GCID of the call. JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = 1000 CalledParty = 2000 type = CiscoAddress.HUNT_PILOT CurrentCalledParty = 2000 type = CiscoAddress.HUNT_PILOT LastRedirectingParty = Null Current called display name = 2000Name. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1001 Message Sequence Charts Message Sequence Charts

Page 1065 diagram

Page 1066

Scenario 2 Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA CallingParty = A, current calling = A Called Party = null, current called = null Lrp = null GC1:CallCtlConnDialingEv A GC1:CallCtlConnEstablishedEv A GC1:CallCtlConnDialingEv A GC1:CallCtlConnEstablishedEv A GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B CallingParty = A, current calling = A Called Party = B, current called = B Lrp = null GC1: ConnCreatedEv C GC1: ConnConnectedEv C GC1: CallCtlConnEstablishedEv C GC1: ConnConnectedEv B GC1: CallCtlConnEstablishedEv B A (1000) calls Hunt Pilot B (2000), call is offered at C (3001); application is observing A. GC1 is the GCID of the call. C(3001) answers the call JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = 1000 CalledParty = 2000 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1002 Message Sequence Charts Message Sequence Charts

Page 1066 diagram

Page 1067

CurrentCalledParty = 2000 LastRedirectingParty = Null Current called party display name = 3001Name. Called party display name changes to the display name of the hunt pilot member that answered the call. Scenario 3 Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: ConnCreatedEv A GC1: CiscoHuntConnCreatedEv B GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: ConnConnectedEv B GC1: CallCtlConnEstablishedEv B CallingParty = A, current calling = A Called Party = B, current called = B Lrp = null GC1: CallCtlConnAlertingEv C GC1:TermConnCreatedEv TermC GC1: TermConnRingingEv TermC GC1: CallCtlTermConnRingingEvTermC: A (1000) calls Hunt Pilot B(2000), call is offered at C (3001). Application is observing C. GC1 is the GCID of the call. JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = 1000 CalledParty = 2000 CurrentCalledParty = 2000 LastRedirectingParty = Null Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1003 Message Sequence Charts Message Sequence Charts

Page 1067 diagram

Page 1068

Scenario 4 Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1:TermConnCreatedEv TermC GC1: TermConnRingingEv TermC GC1: CallCtlTermConnRingingEvTermC CallingParty = A, current calling = A Called Party = B, current called = B Lrp = null
A (1000) calls Hunt Pilot B (2000), call is offered at C (3001) Application is observing A and C. GC1 is the GCID of the call. JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = 1000 CalledParty = 2000 CurrentCalledParty = 2000 LastRedirectingParty = Null Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1004 Message Sequence Charts Message Sequence Charts

Page 1068 diagram

Page 1069

Scenario 5 Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1:TermConnCreatedEv TermC GC1: TermConnRingingEv TermC GC1: CallCtlTermConnRingingEvTermC CallingParty = A, current calling = A Called Party = B, current called = B Lrp = null GC1:CallCtlTermConnTalkingEv TermC A (1000) calls Hunt Pilot (B or 2000), call is offered at C (3001) Application is observing A and C. GC1 is the GCID of the call. JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = 1000 CalledParty = 2000 CurrentCalledParty = 2000 LastRedirectingParty = Null Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1005 Message Sequence Charts Message Sequence Charts

Page 1069 diagram

Page 1070

Scenario 6 Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: CallCtlConnEstablishedEv B GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1:TermConnCreatedEv TermC GC1: TermConnRingingEv TermC GC1: CallCtlTermConnRingingEvTermC CallingParty = A, current calling = A Called Party = B, current called = B Lrp = null GC1:CallCtlTermConnTalkingEv TermC GC1: CiscoHuntConnCreatedEv D GC1: ConnAlertingEv D GC1: CallCtlConnAlertingEv D GC1: TermConnDroppedEv TA GC1: CallCtlTermConnDroppedEv TA getCallControlCause () = CAUSE_REDIRECTED GC1: ConnDisconnectedEv A GC1: CallCtlConnDisconnectedEv A getCallControlCause () = CAUSE_REDIRECTED A (1000) calls Hunt Pilot B (2000), call is offered at C (3001). Application is observing A and C. GC1 is the GCID of the call. A redirects the call to another Hunt Pilot D(4000) JTAPI CallInfo CallingParty = 2000 CurrentCallingParty = 2000 CalledParty = 2000 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1006 Message Sequence Charts Message Sequence Charts

Page 1070 diagram

Page 1071

CurrentCalledParty = 4000 LastRedirectingParty = 1000 Scenario 7 Result Scenario ….. ….. GC1: CiscoHuntConnCreatedEv D GC1: TermConnDroppedEv TermA GC1: CallCtlTermConnDroppedEv TermA getCallControlCause () = CAUSE_REDIRECTED GC1: ConnDisconnectedEv A GC1: CallCtlConnDisconnectedEv A getCallControlCause () = CAUSE_REDIRECTED GC1: ConnCreatedEv E GC1: ConnConnectedEv E GC1: CallCtlConnEstablishedEv E A (1000) calls Hunt Pilot B (2000), call is offered at C (3001) Application is observing A and C. GC1 is the GCID of the call. A redirects the call to D(4000). E(5001) answers the call JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = 2000 CalledParty = 2000 CurrentCalledParty = 4000 LastRedirectingParty = 1000 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1007 Message Sequence Charts Message Sequence Charts

Page 1071 diagram

Page 1072

Scenario 8 Result Scenario ….. ….. GC1: ConnCreatedEv E GC1: ConnInProgressEv E GC1: CallCtlConnOfferedEv E getCallControlCause () = CAUSE_REDIRECTED GC1: CiscoHuntConnCreatedEv D GC1: TermConnDroppedEv TermA GC1: CallCtlTermConnDroppedEv TermA GC1: ConnDisconnectedEv A GC1: CallCtlConnDisconnectedEv A GC1: CallCtlConnEstablishedEv E A (1000) calls Hunt Pilot B(2000), call is offered at C (3001). Application is observing A, E and C. GC1 is the GCID of the call. A redirects the call to D(4000). E(5001) answers the call JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = 2000 CalledParty = 2000 CurrentCalledParty = 4000 LastRedirectingParty = 1000 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1008 Message Sequence Charts Message Sequence Charts

Page 1072 diagram

Page 1073

Scenario 9 Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CallCtlConnEstablishedEv B GC1: ConnCreatedEv D GC1: ConnInProgressEv D GC1: CallCtlConnOfferedEv D GC1: CallCtlConnAlertingEv C GC1: CallCtlTermConnCreatedEv TermC GC1: CallCtlTermConnRingingEv TermC GC1: CallCtlConnAlertingEv D GC1: CallCtlTermConnCreatedEv TermD GC1: CallCtlTermConnRingingEv TermD A (1000) calls Hunt Pilot B(2000), call is offered at C (3001) and D (3002). Application is observing A, C and D. GC1 is the GCID of the call. JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = 1000 CalledParty = 2000 CurrentCalledParty = 2000 LastRedirectingParty = Null Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1009 Message Sequence Charts Message Sequence Charts

Page 1073 diagram

Page 1074

Scenario 10 Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CallCtlConnEstablishedEv B GC1: ConnCreatedEv D GC1: ConnInProgressEv D GC1: CallCtlConnOfferedEv D GC1: CallCtlConnAlertingEv C GC1: CallCtlTermConnCreatedEv TermC GC1: CallCtlTermConnRingingEv TermC GC1: CallCtlConnAlertingEv D GC1: CallCtlTermConnCreatedEv TermD GC1: CallCtlTermConnRingingEv TermD GC1: CallCtlTermConnTalkingEv TermD GC1: CallCtlTermConnDroppedEv TermC GC1: ConnDisconnectedEv C GC1: CallCtlConnDisconnectedEv C A (1000) calls Hunt Pilot B(2000), call is offered at C (3001) and D (3002). Application is observing A, C and D. GC1 is the GCID of the call. D answers the call JTAPI CallInfo CallingParty = 1000 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1010 Message Sequence Charts Message Sequence Charts

Page 1074 diagram

Page 1075

CurrentCallingParty = 1000 CalledParty = 2000 CurrentCalledParty = 2000 LastRedirectingParty = Null Scenario 11 Result Scenario GC1:CallActiveEv GC1:ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1: CallCtlConnEstablishedEv A GC1: CiscoHuntConnCreatedEv B GC1: ConnCreatedEv D GC1: ConnOfferedEv D …. GC1: TermConnCreatedEv TermD GC1: CallCtlTermConnRingingEv TermD GC1: ConnCreatedEv C GC1: ConnConnectedEv C GC1: CallCtlConnEstablishedEv C GC1: CallCtlTermConnDroppedEv TermD GC1: ConnDisconnectedEv D GC1: CallCtlConnDisconnectedEv D A (1000) calls Hunt Pilot (B or 2000), call is offered at C (3001) and D (3002). Application is observing A and D. GC1 is the GCID of the call. C answers the call JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = 1000 CalledParty = 2000 CurrentCalledParty = 2000 LastRedirectingParty = Null Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1011 Message Sequence Charts Message Sequence Charts

Page 1075 diagram

Page 1076

Scenario 12 Result Scenario A (1000) calls Hunt Pilot B (2000), call is offered at C (3001) and is answered. A consults with D (4000) and call is offered at E(5001). A completes the conference. Application is observing A. Initially connection is created to an address with DN = B type = UNKNOWN GC1 is the GCID of the final call. GC2 is the consult call C answers the call E answers the call Conference is completed Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1012 Message Sequence Charts Message Sequence Charts

Page 1076 diagram

Page 1077

Result Scenario GC1:CallActiveEv GC1:ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1: CallCtlConnEstablishedEv A GC1: CiscoHuntConnCreatedEv B-U GC1: ConnInProgressEv B-U GC1: CallCtlConnOfferedEv B-U GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: ConnDisconnectedEv B-U GC1: CallCtlConnDisconnectedEv B-U GC1: ConnCreatedEv C GC1: ConnOfferedEv C …. GC1: CallCtlConnEstablishedEv C GC1: CallCtlTermConnHeldEv TermA GC2: CiscoConsultCallActiveEv GC2: ConnCreatedEv A ….. GC2: CallCtlTermConnTalkingEv TermA GC2: CallCtlConnDialingEv A GC2: CallCtlConnEstablishedEv A GC2: CiscoHuntConnCreatedEv D GC2: ConnInProgressEv D GC2: CallCtlConnOfferedEv D GC2: ConnAlertingEv D Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1013 Message Sequence Charts Message Sequence Charts

Page 1077 diagram

Page 1078

Result Scenario GC2: CallCtlConnAlertingEv D GC2: ConnCreatedEv E GC2: ConnConnectedEv E GC2: CallCtlConnEstablishedEv E GC2: ConnConnectedEv D GC2: CallCtlConnEstablishedEv D CiscoCallChangedEv final call –GC1, consult call = GC2 GC1: CiscoHuntConnCreatedEv B GC1: ConnCreatedEv C GC1: ConnConnectedEv C GC1: CallCtlConnEstablishedEv C GC1: CiscoHuntConnCreatedEv E GC1: ConnCreatedEv E GC1: ConnConnectedEv E GC1: CallCtlConnEstablishedEv E GC2: ConnDisconntedEv B GC2: ConnDisconntedEv C GC2: CallCtlConnDisconnectedEv C GC2: ConnDisconntedEv D GC2: ConnDisconntedEv E GC2: CallCtlConnDisconnectedEv E GC2: CallCtlTermConnDroppedEv TermA .. GC2: ConnDisconntedEv A GC2: CallCtlConnDisconnectedEv A GC2: CallInvalidEv JTAPI CallInfo CallingParty = 1000 CurrentCallingParty = [No guaranted for conference scenario] CalledParty = 2000 CurrentCalledParty = [No guaranted for conference scenario] LastRedirectingParty = 1000 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1014 Message Sequence Charts Message Sequence Charts

Page 1078 diagram

Page 1079

Scenario 13 Transfer to a line group member. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1015 Message Sequence Charts Message Sequence Charts

Page 1079 content

Page 1080

Result Scenario A (1000) calls B(1001), consult to Hunt Pilot P (2000), call is offered at C (3001) and is answered. B completes the transfer. Application is observing A, B and C. GC1 is the GCID of the final call. GC2 is the consult call B answers the call B consults to Hunt pilot C answers the call Transfer is completed Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1016 Message Sequence Charts Message Sequence Charts

Page 1080 diagram

Page 1081

Result Scenario GC1:CallActiveEv GC1:ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1: CallCtlConnEstablishedEv A GC1: ConnCreatedEv B GC1: ConnOfferedEv B … GC1: TermConnRingingEv TermB GC1: TermConnTalkingEv TermB GC1: CallCtlTermConnHeldEv TermB GC2: CiscoConsultCallActiveEv GC2: ConnCreatedEv B ….. GC2: CallCtlTermConnTalkingEv TermB GC2: CiscoHuntConnCreatedEv P GC2: ConnInProgressEv P GC2: CallCtlConnOfferedEv P GC2: ConnCreatedEv C GC2: ConnOfferedEv C GC2: TermConnRingingEv TermC GC2: ConnConnectedEv P GC2: CallCtlConnEstablishedEv P GC2: CiscoHuntConnCreatedEv P GC2: ConnInProgressEv P GC2: CallCtlConnOfferedEv P GC2: ConnAlertingEv P GC2: CallCtlConnAlertingEv P GC2: ConnDisconnectedEv P GC2: CallCtlConnDisconnectedEv P Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1017 Message Sequence Charts Message Sequence Charts

Page 1081 diagram

Page 1082

Result Scenario GC2: ConnConnectedEv P GC2: CallCtlConnEstablishedEv P GC2: ConnConnectedEv C GC2: CallCtlConnEstablishedEv C GC2: TermConnTalkingEv TermC GC1: CiscoHuntConnCreatedEv P GC1: ConnInProgressEv P GC1: CallCtlConnOfferedEv P GC1: ConnAlertingEv P GC1: CallCtlConnAlertingEv P CiscoCallChangedEv final call –GC1, consult call = GC2 GC1: ConnCreatedEv C GC1: ConnConnectedEv C GC1: CallCtlConnEstablishedEv C GC1: TermConnTalkingEv TC GC1: ConnConnectedEv P GC1: CallCtlConnEstablishedEv P GC2: ConnDisconntedEv P GC2: CallCtlConnDisconnectedEv P GC2: ConnDisconntedEv B GC2: CallCtlConnDisconnectedEv B … …. GC2: ConnDisconntedEv C GC2: CallCtlConnDisconnectedEv C .. GC2: CallInvalidEv GC1: ConnDisconntedEv B GC1: CallCtlConnDisconnectedEv B GC1: TermConnDroppedEv TB GC1: CallCtlTermConnDroppedEv TB Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1018 Message Sequence Charts Message Sequence Charts

Page 1082 diagram

Page 1083

Scenario 14 Pickup from line group Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1019 Message Sequence Charts Message Sequence Charts

Page 1083 content

Page 1084

Result Scenario A (1000) calls (GC1) Hunt Pilot B (2000), call is offered at C (3001). Application is observing A, C and D. C and D are in the same pickup group. D picks up the call ringing at C. GC2 is the initial call at D. A and D are connected on GC1 D goes off-hook and answers call from C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1020 Message Sequence Charts Message Sequence Charts

Page 1084 diagram

Page 1085

Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: TermConnRingingEv TC GC1: CallCtlTermConnRingingEv TC GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC2: CallActiveEv GC2: ConnCreatedEv D GC2: ConnConnectedEv D GC2: CallCtlConnInitiatedEv D GC2: TermConnCreatedEv TD GC2: TermConnActiveEv TD GC2: CallCtlTermConnTalkingEv TD GC2: CiscoCallChangedEv GC2->GC1 GC1: ConnCreatedEv D GC1: ConnConnectedEv D GC1: CallCtlConnInitiatedEv D GC1: TermConnCreatedEv TD GC1: TermConnActiveEv TD GC1: CallCtlTermConnTalkingEv TD GC2: TermConnDroppedEv TD GC2: CallCtlTermConnDroppedEv TD GC2: ConnDisconnectedEv D Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1021 Message Sequence Charts Message Sequence Charts

Page 1085 diagram

Page 1086

Result Scenario GC2: CallCtlConnDisconnectedEv D GC2: CallInvalidEv GC1: TermConnDroppedEv TC GC1: TermConnTermConnDroppedEv TC GC1: ConnDisconnectedEv B GC1: CallCtlConnDisconnectedEv B Note: For this scenario, if the pickup is done from the address of the hunt member that is currently ringing with Auto Pickup disabled, then getCiscoHuntConnection() returns the connection to the hunt pilot. If the pickup is done from an address that is in the pickup group but is not the current ringing terminal, then getCiscoHuntConnection() returns null. If Auto Pickup is enabled, then getCiscoHuntConnection() always returns null after the call is picked up (it does not matter whether the pickup is done from the ringing terminal or from another address in the pickup group). This is true for Pickup, Group Pickup, Other Pickup, and Directed Call Pickup. Note Scenario 15 Gpickup a ringing hunt list member. Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B A (1000) calls (GC1) Hunt Pilot B (2000), call is offered at C (3001). Application is observing A, C and D. D picks up the call ringing at C. GC2 is the initial call at D. A and D are connected on GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1022 Message Sequence Charts Message Sequence Charts

Image 1 from page 1086

Page 1086 diagram

Page 1087

Result Scenario D goes off-hook and dials the pickup number Z. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1023 Message Sequence Charts Message Sequence Charts

Page 1087 diagram

Page 1088

Result Scenario GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: TermConnRingingEv TC GC1: CallCtlTermConnRingingEv TC GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC2: CallActiveEv GC2: ConnCreatedEv D GC2: ConnConnectedEv D GC2: CallCtlConnInitiatedEv D GC2: TermConnCreatedEv TD GC2: TermConnActiveEv TD GC2: CallCtlTermConnTalkingEv TD GC2: CallCtlConnDialingEv D GC2: ConnCretatedEv Z GC2: ConnInProgressEv Z GC2: CallCtlConnOfferedEv Z GC2: CallCtlConnEstablishedEv D GC2: CiscoCallChangedEv GC2->GC1 GC1: ConnCreatedEv D GC1: ConnCreatedEv Z GC1: ConnConnectedEv D GC1: CallCtlConnEstablishedEv D GC1: TermConnCreatedEv TD GC1: TermConnActiveEv TD GC1: CallCtlTermConnTalkingEv TD GC1: ConnInProgressEv Z GC1: CallCtlConnOfferedEv Z GC2: ConnDisconnectedEv Z GC2: CallCtlConnDisconnectedEv Z GC2: TermConnDroppedEv TD GC2: CallCtlTermConnDroppedEv TD GC2: ConnDisconnectedEv D Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1024 Message Sequence Charts Message Sequence Charts

Page 1088 diagram

Page 1089

Result Scenario GC2: CallCtlConnDisconnectedEv D GC2: CallInvalidEv GC1: ConnDisconnectedEv Z GC1: CallCtlConnDisconnectedEv Z GC1: TermConnDroppedEv TC GC1: TermConnTermConnDroppedEv TC GC1: ConnDisconnectedEv B GC1: CallCtlConnDisconnectedEv B For this scenario, if the pickup is done from the address of the hunt member that is currently ringing with Auto Pickup disabled, getCiscoHuntConnection() returns the connection to the hunt pilot. If the pickup is done from an address that is in the pickup group but is not the current ringing terminal, getCiscoHuntConnection() returns null. If the Auto Pickup is enabled, getCiscoHuntConnection() always returns null after the call is picked up (it does not matter whether the pickup is done from the ringing terminal or from another address in the pickup group). This is true for Pickup, Group Pickup, Other Pickup, and Directed Call Pickup. Note Scenario 16 Redirect by a hunt member: Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnEstablishedEv B GC1: ConnAlertingEv B A (1000) calls (GC1) Hunt Pilot B (2000), call is offered at C (3001). Application is observing A, C and D. C redirects the call to D. D is not a member. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1025 Message Sequence Charts Message Sequence Charts

Image 1 from page 1089

Page 1089 diagram

Page 1090

Result Scenario GC1: TermConnRingingEv TC GC1: CallCtlTermConnRingingEv TC GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1: CallCtlEstablishedEv C GC1: ConnCreatedEv D GC1: ConnInProgressEv D GC1: CallCtlConnOfferedEv D getCallControlCause() = CAUSE.REDIRECTED GC1: CallCtlConnDisconnectedEv B GC1: CallCtlConnDisconnected C GC1: TermConnDisconnEv C GC1: CallCtlTermConnDisconnectedEv C getCallControlCause() = CAUSE.REDIRECTED Call info: Current calling A Current Called D LRP B type CiscoAdress.UNKNOWN C answers the call. Application redirects the call from C to D Scenario 17 Calls Moving Between Members When call is moving between hunt members, the call could go to invalid state. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1026 Message Sequence Charts Message Sequence Charts

Page 1090 diagram

Page 1091

Result Scenario GC1: CallActiveEv … GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: ConnCreatedEv A GC1: CiscoHuntConnCreatedEv B GC1: CallCtlConnEstablishedEv B GC1: TermConnRingingEv TC GC1: CallCtlTermConnRingingEv TC GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1: ConnCreatedEv D GC1: ConnInProgressEv D GC1: CallCtlConnOfferedEv D GC1: ConnAlertingEv D GC1: CallCtlConnAlertingEv D GC1: TermConnCreatedEv TD GC1: TermConnRingingEv TD GC1: CallCtlTermConnRingingEv TD GC1: TermConnDroppedEv TC GC1: CallCtlTermConnDroppedEv TC getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEvTC GC1: CallCtlConnDisconnectedEv TC getCallControlCause() = CAUSE.REDIRECTED Call info: Current calling A Current Called D LRP = null A (1000) calls (GC1) Hunt Pilot B (2000), call is offered at C (3001). C does not answer the call, call is offered at D. Application is observing C and D Call moves to D. Scenario 18 Not All Members Are Observed Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1027 Message Sequence Charts Message Sequence Charts

Page 1091 diagram

Page 1092

If all members are not observed call could go to invalid state when moving between hunt members Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: ConnCreatedEv A GC1: CiscoHuntConnCreatedEv B GC1: ConnConnectedEv B GC1: CallCtlConnEstablishedEv B GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1: TermConnRingingEv TC GC1: CallCtlTermConnRingingEv TC A (1000) calls (GC1) Hunt Pilot B (2000), call is offered at C (3001). C does not answer the call, call moves to D, and to E where it is answered. C, D, E and F are the members. Application is observing C and E. GC1: ConnDisconnectedEv B GC1: CallCtlConnDisconnectedEv B getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEv A GC1: CallCtlConnDisconnectedEv A getCallControlCause() = CAUSE.REDIRECTED GC1: TermConnDroppedEv TC GC1: CallCtlTermConnDroppedEv getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEv C GC1: CallCtlConnDisconnectedEv C getCallControlCause() = CAUSE.REDIRECTED GC1: CallInvalidEv GC1: CallActiveEv Call moves to D (not unobserved). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1028 Message Sequence Charts Message Sequence Charts

Page 1092 diagram

Page 1093

Result Scenario GC1: ConnCreatedEv E GC1: ConnInProgressEv E GC1: CallCtlConnOfferedEv E GC1: ConnCreatedEv A GC1: CiscoHuntConnCreatedEv B GC1: ConnConnectedEv B GC1: CallCtlConnEstablishedEv B GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: ConnAlertingEv E GC1: CallCtlConnAlertingEv E GC1: TermConnRingingEv TE GC1: CallCtlTermConnRingingEv TE Call moves from D to E. GC1: ConnConnectedEv E GC1: CallCtlConnEstablishedEv E GC1: TermConnActiveEv TE GC1: CallCtlTermConnTalkingEv TE Call info: Current calling A Current Called E LRP = null E answers the call. Scenario 19 Not All Members Are Observed, but Calling Party Is Observed Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1029 Message Sequence Charts Message Sequence Charts

Page 1093 diagram

Page 1094

Result Scenario A (1000) calls (GC1) Hunt Pilot B (2000), call is offered at C (3001). C does not answer the call, call moves to D, and to E where it is answered. C, D, E and F are the members. Application is observing A, C and E. Call moves to D (not unobserved). Call moves from D to E. E answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1030 Message Sequence Charts Message Sequence Charts

Page 1094 diagram

Page 1095

Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A GC1: ConnConnectedEv A GC1: CallCtlConnInitiatedEv A GC1: TermConnCreatedEv TA GC1: TermConnActiveEv TA GC1: CallCtlTermConnTalkingEv TA GC1: CallCtlConnDialingEv A GC1: CallCtlConnEstablishedEv A GC1: CiscoHuntConnCreatedEv B GC1; ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1: TermConnRingingEv TC GC1: CallCtlTermConnRingingEv TC GC1: ConnConnectedEv B GC1: CallCtlConnEstablishedEv B GC1: TermConnDroppedEv TC GC1: CallCtlTermConnDroppedEv getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEv C GC1: CallCtlConnDisconnectedEv C getCallControlCause() = CAUSE.REDIRECTED GC1: ConnCreatedEv E GC1: ConnInProgressEv E GC1: CallCtlConnOfferedEv E GC1: ConnAlertingEv E GC1: CallCtlConnAlertingEv E GC1: TermConnRingingEv TE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1031 Message Sequence Charts Message Sequence Charts

Page 1095 diagram

Page 1096

Result Scenario GC1: CallCtlTermConnRingingEv TE GC1: ConnConnectedEv E GC1: CallCtlConnEstablishedEv E GC1: TermConnActiveEv TE GC1: CallCtlTermConnTalkingEv TE Call info: Current calling A Current Called E LRP = null Scenario 20 Calling and All Hunt List Members Are Observed; the Call Is Not Answered and Goes to Hunt No Answer Forward Destination Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1032 Message Sequence Charts Message Sequence Charts

Page 1096 diagram

Page 1097

Result Scenario A (1000) calls (GC1) Hunt Pilot B (2000), call is offered at C (3001). C does not answer the call, call moves to D, and to E. The call goes to hunt no answer forward destination F which is observed. C, D, E and F are the members.Application is observing A, C, D, E and F. Call moves to D. Call moves from D to E. Call moves to F. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1033 Message Sequence Charts Message Sequence Charts

Page 1097 diagram

Page 1098

Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A GC1: ConnConnectedEv A GC1: CallCtlConnInitiatedEv A GC1: TermConnCreatedEv TA GC1: TermConnActiveEv TA GC1: CallCtlTermConnTalkingEv TA GC1: CallCtlConnDialingEv A GC1: CallCtlConnEstablishedEv A GC1: CiscoHuntConnCreatedEv B GC1; ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1: TermConnRingingEv TC GC1: CallCtlTermConnRingingEv TC GC1: ConnConnectedEv B GC1: CallCtlConnEstablishedEv B GC1: ConnCreatedEv D GC1: ConnInProgressEv D GC1: CallCtlConnOfferedEv D GC1: ConnAlertingEv D GC1: CallCtlConnAlertingEv D GC1: TermConnCreatedEv TD GC1: TermConnRingingEv TD GC1: CallCtlTermConnRingingEv TD GC1: TermConnDroppedEv TC GC1: CallCtlTermConnDroppedEv getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEv C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1034 Message Sequence Charts Message Sequence Charts

Page 1098 diagram

Page 1099

Result Scenario GC1: CallCtlConnDisconnectedEv C getCallControlCause() = CAUSE.REDIRECTED GC1: ConnCreatedEv E GC1: ConnInProgressEv E GC1: CallCtlConnOfferedEv E GC1: ConnAlertingEv E GC1: CallCtlConnAlertingEv E GC1: TermConnRingingEv TE GC1: CallCtlTermConnRingingEv TE GC1: TermConnDroppedEv TD GC1: CallCtlTermConnDroppedEv TD getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEv D GC1: CallCtlConnDisconnectedEv D getCallControlCause() = CAUSE.REDIRECTED GC1: ConnCreatedEv F GC1: ConnInProgressEv F GC1: CallCtlConnOfferedEv F GC1: ConnAlertingEv F GC1: CallCtlConnAlertingEv F GC1: TermConnRingingEv TF GC1: CallCtlTermConnRingingEv TF GC1: ConnDisconnectedEv B GC1: CallCtlConnDisconnectedEv B GC1: TermConnDroppedEv TE GC1: CallCtlTermConnDroppedEv TE getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEv E GC1: CallCtlConnDisconnectedEv E getCallControlCause() = CAUSE.REDIRECTED Call info: Current calling A Current Called F Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1035 Message Sequence Charts Message Sequence Charts

Page 1099 diagram

Page 1100

Result Scenario LRP = null Scenario 21 Forward Hunt No Answer to Another Hunt Pilot Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv A GC1: ConnConnectedEv A GC1: CallCtlConnInitiatedEv A GC1: TermConnCreatedEv TA GC1: TermConnActiveEv TA GC1: CallCtlTermConnTalkingEv TA GC1: CallCtlConnDialingEv A GC1: CallCtlConnEstablishedEv A GC1: CiscoHuntConnCreatedEv HP1 GC1; ConnInProgressEv HP1 GC1: CallCtlConnOfferedEv HP1 GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1: TermConnRingingEv TC GC1: CallCtlTermConnRingingEv TC GC1: ConnConnectedEv HP1 GC1: CallCtlConnEstablishedEv HP1 A (1000) calls (GC1) Hunt Pilot HP1 (2000), call is offered at C (3001). C does not answer the call, call moves to D, and to E. The call goes to hunt no answer forward destination F which is observed. C, D, E are the members . HP2 is the forward hunt no answer destination. H, L are its members. All parties are observed. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1036 Message Sequence Charts Message Sequence Charts

Page 1100 diagram

Page 1101

Result Scenario GC1: ConnCreatedEv D GC1: ConnInProgressEv D GC1: CallCtlConnOfferedEv D GC1: ConnAlertingEv D GC1: CallCtlConnAlertingEv D GC1: TermConnCreatedEv TD GC1: TermConnRingingEv TD GC1: CallCtlTermConnRingingEv TD GC1: TermConnDroppedEv TC GC1: CallCtlTermConnDroppedEv getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEv C GC1: CallCtlConnDisconnectedEv C getCallControlCause() = CAUSE.REDIRECTED GC1: ConnCreatedEv E GC1: ConnInProgressEv E GC1: CallCtlConnOfferedEv E GC1: ConnAlertingEv E GC1: CallCtlConnAlertingEv E GC1: TermConnRingingEv TE GC1: CallCtlTermConnRingingEv TE GC1: TermConnDroppedEv TD GC1: CallCtlTermConnDroppedEv TD getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEv D GC1: CallCtlConnDisconnectedEv D getCallControlCause() = CAUSE.REDIRECTED Call moves to D Call moves from D to E. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1037 Message Sequence Charts Message Sequence Charts

Page 1101 diagram

Page 1102

Result Scenario GC1: ConnCreatedEv H GC1: ConnInProgressEv H GC1: CallCtlConnOfferedEv H GC1: CiscoHuntConnCreatedEv HP2 GC1: ConnAlertingEv H GC1: CallCtlConnAlertingEv H GC1: TermConnRingingEv TH GC1: CallCtlTermConnRingingEv TH GC1: ConnConnectedEv HP2 GC1: CallCtlConnEstablishedEv HP2 GC1: ConnCreatedEv L GC1: ConnInProgressEv L GC1: CallCtlConnOfferedEv L GC1: ConnAlertingEv L GC1: CallCtlConnAlertingEv L GC1: TermConnRingingEv TL GC1: CallCtlTermConnRingingEv TL GC1: ConnDisconnectedEv HP1 GC1: CallCtlConnDisconnectedEv HP1 GC1: TermConnDroppedEv TH GC1: CallCtlTermConnDroppedEv TH getCallControlCause() = CAUSE.REDIRECTED GC1: ConnDisconnectedEv H GC1: CallCtlConnDisconnectedEv H getCallControlCause() = CAUSE.REDIRECTED Call info: Current calling A Current Called F LRP = null Call goes t HP2, call is offered at H Call moves from H to L Scenario 22 Consult Transfer by a Member to Another Hunt Pilot Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1038 Message Sequence Charts Message Sequence Charts

Page 1102 diagram

Page 1103

Result Scenario GC1: CallActiveEv GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: ConnCreatedEv A GC1: CiscoHuntConnCreatedEv HP1 GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: ConnConnectedEv HP1 GC1: CallCtlConnEstablishedEv HP1 GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1: TermConnRingingEv TC GC1: CallCtlTermConnRingingEv TC GC1: ConnConnectedEv C GC1: CallCtlConnEstablishedEv C GC1: TermConnActiveEv TC GC1: CallCtlTermConnTalkingEv TC GC1: CiscoTermConnSelectChangedEv TC GC1: CallCtlTermConnHeldEv TC GC2: ConsultCallActive GC2: ConnCreatedEv C GC2: ConnConnectedEv C GC2: CallCtlConnInitiatedEv C GC2: TermConnCreatedEv C GC2: TermConnActiveEv C GC2: CallCtlTermConnTalkingEv TC GC2: CallCtlConnDialingEv TC GC2: CallCtlConnEstablishedEv TC GC2: CiscoHuntConnCreatedEv HP2 GC2: ConnInProgressEv HP2 GC2: CallCtlConnOfferedEv HP2 A (1000) calls (GC1) Hunt Pilot HP1 (2000), call is offered at C (3001). C answers the call and consult to HP2. L in HP2 is ringing. C completes the transfer. C and L are observed C answers the call C consults with HP2 (GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1039 Message Sequence Charts Message Sequence Charts

Page 1103 diagram

Page 1104

Result Scenario GC2: ConnCreatedEv L GC2: ConnInProgressEv L GC2: CallCtlConnOfferedEv L GC2: ConnAlertingEv L GC2: CallCtlConnAlertingEv L GC2: TermConnRingingEv TL GC2: CallCtlTermConnRingingEv TL GC2: ConnConnectedEv HP2 GC2: CallCtlConnEstablishedEv HP2 GC2: CiscoCallChangedEv GC1: ConnCreatedEv L GC1: ConnAlertingEv L GC1: CallCtlConnAlertingEv L GC1: TermConnCreatedEv TL GC1: TermConnRingingEv TL GC1: CallCtlTermConnRingingEv TL GC2: ConnDisconnectedEv HP2 GC2: CallCtlConnDisconnectedEv HP2 GC2: TermConnDroppedEv TL GC2: CallCtlTermConnDroppedEv TL GC2: ConnDisconnectedEv L GC2: CallCtlConnDisconnectedEv L GC2: TermConnDroppedEv C GC2: CallCtlTermConnDroppedEv C GC2: ConnDisconnectedEv C GC2: CallCtlConnDisconnectedEv C GC1: ConnDisconnectedEv HP1 GC1: CallCtlConnDisconnectedEv HP1 GC2: CallInvalidEv GC1: CiscoHuntConnCreatedEv HP2 GC2: ConnConnectedEv HP2 GC2: CallCtlConnEstablishedEv HP2 Call is offered to L C completes the transfer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1040 Message Sequence Charts Message Sequence Charts

Page 1104 diagram

Page 1105

Result Scenario GC1: TermConnDroppedEv C GC1: CallCtlTermConnDroppedEv C GC1: ConnDisconnectedEv C GC1: CallCtlConnDisconnectedEv C GC1: ConnConnectedEv L GC1: CallCtlConnEstablishedEv L GC1: TermConnActiveEv L GC1: CallCtlTermConnTalkingEv TL L answers the call The following call scenarios are generally un-supported and applications are encouraged to enable the huntlist feature and adapt to the event flows described above. Following are the expected events when the feature is disabled. Scenario 23 Hunt list feature is disabled. Basic call to hunt pilot Result Scenario GC1:CallActiveEv GC1:ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1: CallCtlConnEstablishedEv A GC1: ConnCreatedEv P GC1: ConnOfferedEv P … GC1: ConnAlertingEv P GC1: ConnConnected P GC1: CallCtlConnEstablishedEv A A (1000) calls Hunt Pilot P (2000), call is offered at C (3001) and is answered. Application is observing A. GCID is the call is GC1. C answers the call bvHunt list feature is disabled Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1041 Message Sequence Charts Message Sequence Charts

Page 1105 diagram

Page 1106

Scenario 24 Consult – Transfer Scenario Result Scenario GC1:CallActiveEv GC1:ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1: CallCtlConnEstablishedEv A GC1: ConnCreatedEv B GC1: ConnOfferedEv B … GC1: TermConnRingingEv TermB GC1: TermConnTalkingEv TermB GC1: CallCtlTermConnHeldEv TermB GC2: CiscoConsultCallActiveEv GC2: ConnCreatedEv B ….. GC2: CallCtlTermConnTalkingEv TermB GC2: ConnCreatedEv P .. .. GC2: ConnAlertingEv P GC2: CallCtlConnEstablishedEv P A (1000) calls B(1001), consult to Hunt Pilot P (2000), call is offered at C (3001) and is answered. B completes the transfer. Application is observing A and B. GC1 is the GCID of the final call. GC2 is the consult call B answers the call B consults to Hunt pilot C answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1042 Message Sequence Charts Message Sequence Charts

Page 1106 diagram

Page 1107

Result Scenario CiscoTransferStartEv final call –GC1, consult call = GC2 GC1: ConnCreatedEv P CiscoCallChangedEv GC2 = >GC1 GC2: ConnDisconnectedEv P GC2: ConnDisconntedEv B GC2: CallCtlConnDisconnectedEv B … …. GC2: CallInvalidEv GC1: CallCtlConnEstablishedEv P GC1: ConnDisconnectedEv B CiscoTransferEndEv Transfer is completed Scenario 25 Hunt list feature is disabled Consult – Transfer Scenario Result Scenario UnSupported Configuration A (1000) calls B(1001), consult to Hunt Pilot P (2000), call is offered at C (3001) and is answered. B completes the transfer. Application is observing A, B and C. Hunt List Connected Number Hunt pilot B configured with "Display Line Group Member DN as Connected Party" enabled. B has HL1 as its hunt list which has C and D as its hunt members Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1043 Message Sequence Charts Hunt List Connected Number

Page 1107 diagram

Page 1108

Call info Expected results Scenario Call.getCurrentCallingAddress = A Call.getModifiedCallingAddress = A Call.getCurrentCalledAddress = null Call.getModifiedCalledAddress = null Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = B Call.getModifiedCalledAddress = B Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = B Call.getModifiedCalledAddress = C GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1:CallCtlConnEstablishedEv A GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: ConnCreatedEv C GC1: ConnConnectedEv C GC1: CallCtlConnEstablishedEv C GC1: ConnConnectedEv B GC1: CallCtlConnEstablishedEv B A calls B, Application is observing A only. GC1 is the GCID of the call. Call is offered on the huntmember C and C answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1044 Message Sequence Charts Message Sequence Charts

Page 1108 diagram

Page 1109

Call info Expected results Scenario Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = B Call.getModifiedCalledAddress = B Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = B Call.getModifiedCalledAddress = C GC1: CallActiveEv GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: ConnCreatedEv A GC1: CiscoHuntConnCreatedEv B GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: ConnConnectedEv B GC1: CallCtlConnEstablishedEv B GC1: CallCtlConnAlertingEv C GC1:TermConnCreatedEv TermC GC1: TermConnRingingEv TermC GC1: CallCtlTermConnRingingEvTermC: GC1: ConnConnectedEv C GC1: CallCtlConnEstablishedEv C GC1: TermConnActiveEv TermC CG1: CallCtlTermConnTalkingEv termC A calls Hunt Pilot B, call is offered at C. Application is observing C. GC1 is the GCID of the call. C answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1045 Message Sequence Charts Message Sequence Charts

Page 1109 diagram

Page 1110

Call info Expected results Scenario Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = B Call.getModifiedCalledAddress = C GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1:TermConnCreatedEv TermC GC1: TermConnRingingEv TermC GC1: CallCtlTermConnRingingEvTermC GC1:CallCtlTermConnTalkingEv TermC A calls Hunt Pilot B, call is offered at C Application is observing A and C. GC1 is the GCID of the call. C answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1046 Message Sequence Charts Message Sequence Charts

Page 1110 diagram

Page 1111

Call info Expected results Scenario Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = B Call.getModifiedCalledAddress = B Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = B Call.getModifiedCalledAddress = D GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1:TermConnCreatedEv TermC GC1: TermConnRingingEv TermC GC1: CallCtlTermConnRingingEvTermC GC1: ConnCreatedEv D GC1: ConnAlertingEv D GC1: ConnDisConnEv C GC1: CallCtlConnDiscConnEv C GC1:TermConnDroppedEv TermC GC1: CallCtlTermConnDroppedEv TermC GC1: ConnConnectedEv D GC1: CallCtlConnEstablishedEv D GC1: TermConnActiveEv TermD CG1: CallCtlTermConnTalkingEv termD A calls Hunt Pilot B, call is offered at C and then to D Application is observing A, C and D. GC1 is the GCID of the call. Call moves to D and D answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1047 Message Sequence Charts Message Sequence Charts

Page 1111 diagram

Page 1112

Call info Expected results Scenario Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = B Call.getModifiedCalledAddress = C GC1: CallActiveEv GC1: ConnCreatedEv A ... GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv C GC1: ConnInProgressEv C GC1: CallCtlConnOfferedEv C GC1: CiscoHuntConnCreatedEv B GC1: ConnInProgressEv B GC1: CallCtlConnOfferedEv B GC1: ConnAlertingEv B GC1: CallCtlConnAlertingEv B GC1: ConnAlertingEv C GC1: CallCtlConnAlertingEv C GC1:TermConnCreatedEv TermC GC1: TermConnRingingEv TermC GC1: CallCtlTermConnRingingEvTermC GC1:CallCtlTermConnTalkingEv TermC GC2: CallActiveEv GC2: ConnCreatedEv C ... GC2: CallCtlTermConnTalkingEv A A calls Hunt Pilot B, call is offered at C Application is observing A, C and D. GC1 is the GCID of the call. C answers the call. C consults D and completes transfer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1048 Message Sequence Charts Message Sequence Charts

Page 1112 diagram

Page 1113

Call info Expected results Scenario Call.getCurrentCallingAddress = C Call.getModifiedCalledAddress = C Call.getCurrentCalledAddress = D Call.getModifiedCalledAddress = D Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = D Call.getModifiedCalledAddress = D GC2: ConnCreatedEv D GC2: ConnInProgressEv D GC2: CallCtlConnOfferedEv D ... GC2: ConnAlertingEv D GC2: CallCtlConnAlertingEv D GC2:TermConnCreatedEv TermD GC2: TermConnRingingEv TermD GC2:CallCtlTermConnRingingEvTermD GC2:CallCtlTermConnTalkingEv TermD CiscoTransferStartEv GC1 ConnCreatedEv D GC1: CallCtlConnEstablishedEv D GC1:CallCtlTermConnTalkingEv TermD ... ... GC1 ConnDroppedEv C GC1 ConnDroppedEv B ... GC2 CallInvalidEv CiscoTransferEndEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1049 Message Sequence Charts Message Sequence Charts

Page 1113 diagram

Page 1114

Call info Expected results Scenario Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = D Call.getModifiedCalledAddress = D GC1: CallActiveEv GC1: ConnCreatedEv A … GC1: CallCtlTermConnTalkingEv A GC1: ConnCreatedEv D GC1: ConnInProgressEv D GC1: CallCtlConnOfferedEv D GC1: ConnAlertingEv D GC1: CallCtlConnAlertingEv D GC1:TermConnCreatedEv TermD GC1: TermConnRingingEv TermD GC1: CallCtlTermConnRingingEvTermD GC1 CallCtlConnEstablishedEv D GC1:CallCtlTermConnTalkingEv TermD GC2: CallActiveEv GC2: ConnCreatedEv D ... GC2: CallCtlTermConnTalkingEv D GC2: ConnCreatedEv C GC2: ConnInProgressEv C GC2: CallCtlConnOfferedEv C GC2: ConnCreatedEv D GC2: CiscoHuntConnCreatedEv B GC2: ConnConnectedEv D GC2: CallCtlConnEstablishedEv A GC2: ConnConnectedEv B GC2: CallCtlConnEstablishedEv B A calls D. D calls HP B, call is offered on C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1050 Message Sequence Charts Message Sequence Charts

Page 1114 diagram

Page 1115

Call info Expected results Scenario Call.getCurrentCallingAddress = D Call.getModifiedCalledAddress = B Call.getCurrentCallingAddress = D Call.getModifiedCalledAddress = B Call.getCurrentCallingAddress = D Call.getModifiedCalledAddress = B Call.getCurrentCallingAddress = D Call.getModifiedCalledAddress = C Call.getCurrentCallingAddress = A Call.getModifiedCalledAddress = A Call.getCurrentCalledAddress = B Call.getModifiedCalledAddress = C GC2: CallCtlConnAlertingEv C GC2:TermConnCreatedEv TermC GC2: TermConnRingingEv TermC GC2: CallCtlTermConnRingingEvTermC: GC2 CallCtlConnEstablishedEv C GC2 CallCtlTermConnTalkingEv termC CiscoTransferStartEv GC1 ConnCreatedEv C GC1 CiscoHuntConnectionCreatedEv B GC1: ConnConnectedEv B GC1: CallCtlConnEstablishedEv B GC1: CallCtlConnEstablishedEv C GC1:CallCtlTermConnTalkingEv TermD ... ... GC1 ConnDroppedEv D ... GC2 CallInvalidEv CiscoTransferEndEv C answers the call D completes transfer Intercom Configuration: terminal T1 has intercom line A with TargetDN B, label Bob, Unicode label UBob. Terminal T2 has intercom line B. Application provider has both T1 and T2 in control list. C, Carol, UCarol is in the same intercom group as A, and B. D, David, UDavid is not in the same intercom group as A, B and C. Call info Result Action N.A JTAPI returns A and B as array of CiscoIntercomAddress. Application opens provider, after provider comes in service, application issues provider.getIntercomAddresses() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1051 Message Sequence Charts Intercom

Page 1115 diagram

Page 1116

Call info Result Action N.A JTAPI will return B as target DN and Bob and UBob as target label. Application issues CiscoIntercomAddress.getIntercomTargetDN(), CiscoIntercomAddress.getIntercomTargetLabel() and CiscoIntercomAddress.getIntercomUnicodeTarget Label() request at A. N.A JTAPI will return B as target DN and Bob and UBob as target label. Application issues CiscoIntercomAddress.getDafaultIntercomTargetDN(), CiscoIntercomAddress.getDefaultIntercomTargetLabel() and CiscoIntercomAddress.getDefaultIntercomUnicodeTargetLabel() request at A. N.A AddressObserver at A: CiscoAddrIntercomInfoChangedEv Cause: CAUSE_NORMAL JTAPI will return C as target DN and Carol and UCarol as target label. Application issues CiscoIntercomAddres.setIntercomTarget(C, Carol, UCarol) on intercom address A. After successful response, Application issues CiscoIntercomAddress.getIntercomTargetDN(), CiscoIntercomAddress.getIntercomTargetLabel() and CiscoIntercomAddress.getIntercomUnicodeTargetLabel() request at A. N.A App1 : AddressObserver at A: CiscoAddrIntercomInfoChangedEv Cause: CAUSE_NORMAL Application1 is observing CiscoIntercomAddress A and has AddressObserverAdded to it. Application2 sets intercom target, label to C, Carol, UCarol. N.A Exception will be thrown to application as another application instance has already set the target to C, Carol, UCarol. After above step Application1 issues CiscoIntercomAddres.setIntercomTarget(B, Bob, UBob) on intercom address A. N.A Exception will be thrown as D, David, UDavid is not in the same intercom group. Intercom target DN and label for intercom address A is set to default, now application issues CiscoIntercomAddres.setIntercomTarget(D, David, UDavid) on intercom address A. N.A AddressObserver at A: CiscoAddrIntercomInfoChangedEv Cause: CAUSE_NORMAL JTAPI will return C as target DN and Carol and UCarol as target label. Application has set intercom target DN and label to C, Carol, UCarol for intercom address A. Now CTI Manager goes out of service, JTAPI failover to another CTIManager node. After intercom address A come back in service, JTAPI will restore intercom target DN and label to C, Carol, UCarol respectively. Application issues CiscoIntercomAddress.getIntercomTargetDN(), CiscoIntercomAddress.getIntercomTargetLabel() and CiscoIntercomAddress.getIntercomUnicodeTargetLabel() request at A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1052 Message Sequence Charts Message Sequence Charts

Page 1116 diagram

Page 1117

Call info Result Action N.A AddressObserver at A: CiscoAddrIntercomInfoRestorationFailedEv Cause: CAUSE_NORMAL Application has set intercom target DN and label to C, Carol for intercom address A. Now CTI Manager goes out of service, JTAPI failsover to another CTIManager node. After intercom address A come back in service, JTAPI tries to restore intercom target DN, label and UnicodeLabel to C, Carol, UCarol respectively, however due to race condition some other application has already set the target DN, JTAPI get failure response from CTI. N.A AddressObserver at A: CiscoAddrIntercomInfoChangedEv Cause: CAUSE_NORMAL JTAPI will return C as target DN and Carol and UCarol as target label. Application is connected to a CTIManager node, Cisco Unified Communications Manager node goes down, intercom device failsover to another Cisco Unified Communications Manager node, after intercom address comes back in service. CTIManager should restore intercom target Dn and label. Application issues CiscoIntercomAddress.getIntercomTargetDN(), CiscoIntercomAddress.getIntercomLabel() and CiscoIntercomAddress.getIntercomUnicodeTargetLabel() request at A. N.A AddressObserver at A: CiscoAddrIntercomInfoRestorationFailedEv Cause: CAUSE_NORMAL Application is connected to a CTIManager node, Cisco Unified Communications Manager node goes down, intercom device failsover to another Cisco Unified Communications Manager node, after intercom address comes back in service. CTIManager tries to restore intercom target Dn and label, however due to race condition some other application has already set the target Dn and Label, hence CTI is not able to restore the intercom target DN and label. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1053 Message Sequence Charts Message Sequence Charts

Page 1117 diagram

Page 1118

Call info Result Action Cg = A Cd = B CurrentCg = A CurredCd = B LRP = null CallObserver at A and B: CallActiveEv GC1 Cause: CAUSE_NORMALConnCreatedEv A, Cause: CAUSE_NORMALConnConnectedEv A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv A Cause: CAUSE_NORMAL CallCtlCause = CAUSE_NORMALTermConnCreatedEv A- T1 Cause: CAUSE_NORMAL TermConnActiveEv A- T1 Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv A - T1 Cause: CAUSE_NORMAL CallCtlCause = CAUSE_NORMAL CallCtlConnDialingEv A Cause: CAUSE_NORMAL CallCtlCause = CAUSE_NORMAL CallCtlConnEstablishedEv A Cause: CAUSE_NORMAL CallCtlCause = CAUSE_NORMAL ConnCreatedEv B, Cause: CAUSE_NORMAL ConnConnectedEv B Cause: CAUSE_NORMAL CallCtlConnOfferedEv B Cause: CAUSE_NORMAL CallCtlCause = CAUSE_NORMAL CallCtlConnEstablishedEv B Cause: CAUSE_NORMALCallCtlCause=CAUSE_NORMAL TermConnCreatedEv B- T2 Cause: CAUSE_NORMAL TermConnPassiveEv B – T2 Cause: CAUSE_NORMAL CallCtlTermConnBridgeEv B – T2 Cause: CAUSE_NORMAL CallCtl Cause = CAUSE_NORMAL CiscoToneChangedEv – T1 –GC1 CiscoToneChangedEv – T2 –GC1 CiscoRTPOutputStartedEv – T1 CiscoRTPInputStartedEv – T2 Application is observing intercom addresses A and B. A has target set to B. User initiates intercom call. Intercom call is successful. Cg = A Cd = B CurrentCg = A CurredCd = B LRP = null CallObserver at A and B: TermConnActiveEv B - T2 Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv B – T2 Cause: CAUSE_NORMALCallCtlCause=CAUSE_NORMAL CiscoRTPOutputStartedEv – T2CiscoRTPInputStartedEv – T1 User at B presses talkback softkey to get connected to intercom initiator. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1054 Message Sequence Charts Message Sequence Charts

Page 1118 diagram

Page 1119

Call info Result Action Cg = A Cd = B CurrentCg = A CurredCd = B LRP = null CallObserver at A and B : CallActiveEv GC1 Cause: CAUSE_NORMAL ConnCreatedEv A Cause: CAUSE_NORMAL ConnConnectedEv A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv A Cause: CAUSE_NORMAL CallCtlCause = CAUSE_NORMAL TermConnCreatedEv T1 Cause: CAUSE_NORMAL TermConnActiveEv T1 Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv T1 Cause: CAUSE_NORMALCallCtlCause=CAUSE_NORMAL CallCtlConnDialingEv A Cause: CAUSE_NORMAL CallCtlConnEstablishedEv A Cause: CAUSE_NORMALCallCtlCause=CAUSE_NORMAL ConnCreatedEv B Cause: CAUSE_NORMAL C ConnConnectedEv B Cause: CAUSE_NORMAL CallCtlConnOfferedEv B Cause: CAUSE_NORMAL CallCtlCause = CAUSE_NORMAL CallCtlConnEstablishedEv B Cause: CAUSE_NORMALCallCtlCause=CAUSE_NORMAL TermConnCreatedEv B- T2 Cause: CAUSE_NORMAL TermConnPassiveEv B – T2 Cause: CAUSE_NORMAL CallCtlTermConnBridgeEv B – T2 Cause: CAUSE_NORMALCallCtlCause=CAUSE_NORMAL CiscoToneChangedEv – T1 –GC1 CiscoToneChangedEv – T2 –GC1 CiscoRTPOutputStartedEv – T1 CiscoRTPInputStartedEv – T2 Intercom address A has target defined as B. Application initiates an intercom call by calling interface Address.ConnectIntercom() with dialeddigit as empty. Intercom call is successful. Cg = A Cd = B CurrentCg = A CurredCd = B LRP = null CallObserver at A and B : TermConnActiveEv B – T2 Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv B – T2 Cause: CAUSE_NORMALCallCtlCause=CAUSE_NORMAL CiscoRTPOutputStartedEv – T2 CiscoRTPInputStartedEv – T1 Application initiate TerminalConnection.join() request on TerminalConnection of B to talkback. Request is successful. N.A PlatformException will be thrown, intercom call stay connected. Application tried to put the intercom call on hold at A by issuing TerminalConnection.hold() N.A PlatformException will be thrown, intercom call stay connected. Application tried to accept intercom call at intercom target by issuing connection.accept() at connection of B. N.A Intercom call will be disconnected. Application tried to reject intercom call at intercom target by issuing connection.reject() at connection of B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1055 Message Sequence Charts Message Sequence Charts

Page 1119 diagram

Page 1120

Call info Result Action N.A PlatformException will be thrown, intercom call stay connected. Application tried to redirect intercom call by issuing connection.redirect() at connection of A or B. N.A PlatformException will be thrown, intercom call stay connected. Application tried to park call by issuing connection.park() at Connection of A or B. N.A No event to GC1 call, it will stay in Connected State. Terminal T1 has intercom address A which has intercom target set to B. Terminal T2 has intercom address B and another address C. C is in call with D, GC1. A initiates intercom call to B, intercom call is auto-answered at B N.A PlatformException will be thrown. Application tries to set forward on intercom address A by issuing CiscoIntercomAddress. setForwarding () N.A PlatformException will be thrown. Application tries to setRingerStatus on intercom address A by issuing CiscoIntercomAddress. setRingerStatus() N.A PlatformException will be thrown. Application tries to setMessageWaiting on intercom address A by issuing CiscoIntercomAddress.setMessageWaiting() N.A PlatformException will be thrown. Application tries to setAutoAcceptEnabled on intercom address A at CTIPort by issuing CiscoIntercomAddress. setAutoAcceptStatus () N.A PlatformException will be thrown. Application tries to getAutoAcceptEnabled on intercom address A at CTIPort by issuing CiscoIntercomAddress. getAutoAcceptStatus () DeviceState Whisper Scenario Configuration: Terminal T1 has intercom address B, Terminal T2 has intercom address A. Application has set CiscoTermEvFilter to enable CiscoTermDeviceStateWhisperEv as well as all other DeviceState filters on T1 and T2. Application had added Terminal observer on both T1 and T2. Call info Events Action N.A Event received at TerminalObserver of T1 CiscoTermDeviceStateActiveEv T1 Cause: CAUSE_NORMAL Event received at TerminalObserver of T2 CiscoTermDeviceStateWhisperEv T1 Cause: CAUSE_NORMAL Intercom address A has target defined as B. Application initiates an intercom call by calling interface Address.ConnectIntercom() with dialeddigit as empty. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1056 Message Sequence Charts Message Sequence Charts

Page 1120 diagram

Page 1121

Call info Events Action N.A Event received at TerminalObserver of T1 None. Event received at TerminalObserver of T2 CiscoTermDeviceStateActiveEv T1 Cause: CAUSE_NORMAL Application issue join() request on TerminalConnection of T2 (intercomTarget) to talkback to T1(intecomInitiator) N.A Event received at TerminalObserver of T2 CiscoTermDeviceStateWhisperEv T1 Cause: CAUSE_SNAPSHOT Terminal T2 already have intercom target call, Application enables CiscoTermFilter for CiscoTermDeviceStateWhisperEv. iSac Codec CiscoMediaTerminal Static Registration with iSac Codec Call info Events Actions CiscoTermInServirceEv for TA CiscoAddrInServiceEv for A

Observe both A(CiscoMediaTerminal) and B Static Register A with media capability as CiscoMediaCapability. ISAC A calls B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1057 Message Sequence Charts iSac Codec

Page 1121 diagram

Page 1122

Call info Events Actions (CiscoRTPInputStartedEv for TA).getRTPInputProperties().getPayloadType() will return CiscoRTPPayload.ISAC (CiscoRTPInputStartedEv for TA).getRTPInputProperties().getBitRate() is not deterministic (CiscoRTPInputStartedEv for TA).getRTPInputProperties().getPacketSize() is not deterministic (CiscoRTPOutputStartedEv for TA).getRTPOutputProperties().getPayloadType() will return CiscoRTPPayload.ISAC (CiscoRTPOutputStartedEv for TA).getRTPOutputProperties().getBitRate() is not deterministic (CiscoRTPOutputStartedEv for TA).getRTPOutputProperties().getPacketSize() is not deterministic GC1: CallActiveEv GC1: ConnCreatedEv for A GC1: ConnConnectedEv for B GC1: CallCtlConnInitiatedEv for A GC1: TermConnCreatedEv for TA GC1: TermConnActiveEvent for TA GC1: CallCtlTermConnTalkingEv for TA GC1: CallCtlConnDialingEv for A GC1: CallCtlConnEstablishedEv for B GC1: ConnCreatedEv for B GC1: ConnInProgressEv for B GC1: CallCtlConnOfferedEv for B GC1: ConnAlertingEv for B GC1: CallCtlConnAlertingEv for B GC1: TermConnCreatedEv for TB GC1: TermConnRingingEv for TB GC1: CallCtlTermConnRingingEv for TB GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B GC1: TermConnActiveEv for TB GC1: CallCtlTermConnTalkingEv for TB TB: CiscoRTPOutputStartedEv for TB TA: CiscoRTPInputStartedEv for TA TA: CiscoRTPOutputStartedEv for TB TB: CiscoRTPInputStartedEv for TA B answers CiscoMediaTerminal Dynamic Registration with iSac Codec Call info Events Actions CiscoTermInServirceEv for TB CiscoAddrInServiceEv for B

Observe both A and B (CiscoMediaTerminal) Dynamic Register B with media capability as CiscoMediaCapability. ISAC Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1058 Message Sequence Charts Message Sequence Charts

Page 1122 diagram

Page 1123

Page 1123 diagram

Page 1124

Call info Events Actions CiscoMediaOpenLogicalChannelEv.getPayloadType() will return CiscoRTPPayload.ISAC CiscoMediaOpenLogicalChannelEv.getPacketSize() is not deterministic (CiscoRTPInputStartedEv for TB).getRTPInputProperties().getPayloadType() will return CiscoRTPPayload.ISAC (CiscoRTPInputStartedEv for TB).getRTPInputProperties().getBitRate() is not deterministic (CiscoRTPInputStartedEv for TB).getRTPInputProperties().getPacketSize() is not deterministic (CiscoRTPOutputStartedEv for TB).getRTPOutputProperties().getPayloadType() will return CiscoRTPPayload.ISAC (CiscoRTPOutputStartedEv for TB).getRTPOutputProperties().getBitRate() is not deterministic (CiscoRTPOutputStartedEv for TB).getRTPOutputProperties().getPacketSize() is not deterministic GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B GC1: TermConnActiveEv for TB GC1: CallCtlTermConnTalkingEv for TB TB: CiscoMediaOpenLogicalChannelEv for TB TB: CiscoRTPOutputStartedEv for TA TA: CiscoRTPInputStartedEv for TB TA: CiscoRTPOutputStartedEv for TB TB: CiscoRTPInputStartedEv for TA B answers App sets RTP params on B CiscoRouteTerminal Dynamic Registration with iSac Codec Call info Events Actions CiscoTermInServirceEv for TB CiscoAddrInServiceEv for B

Observe both A and B (CiscoRouteTerminal) Dynamic Register B with media capability as CiscoMediaCapability. ISAC Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1060 Message Sequence Charts Message Sequence Charts

Page 1124 diagram

Page 1125

Call info Events Actions GC1: CallActiveEv GC1: ConnCreatedEv for A GC1: ConnConnectedEv for B GC1: CallCtlConnInitiatedEv for A GC1: TermConnCreatedEv for TA GC1: TermConnActiveEvent for TA GC1: CallCtlTermConnTalkingEv for TA GC1: CallCtlConnDialingEv for A GC1: CallCtlConnEstablishedEv for B GC1: ConnCreatedEv for B GC1: ConnInProgressEv for B GC1: CallCtlConnOfferedEv for B GC1: ConnAlertingEv for B GC1: CallCtlConnAlertingEv for B GC1: TermConnCreatedEv for TB GC1: TermConnRingingEv for TB GC1: CallCtlTermConnRingingEv for TB A calls B CiscoMediaOpenLogicalChannelEv.getPayloadType() will return CiscoRTPPayload.ISAC CiscoMediaOpenLogicalChannelEv.getPacketSize() is not deterministic GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B GC1: TermConnActiveEv for TB GC1: CallCtlTermConnTalkingEv for TB TB: CiscoMediaOpenLogicalChannelEv for TB B answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1061 Message Sequence Charts Message Sequence Charts

Page 1125 diagram

Page 1126

Call info Events Actions (CiscoRTPInputStartedEv for TB).getRTPInputProperties().getPayloadType() will return CiscoRTPPayload.ISAC (CiscoRTPInputStartedEv for TB).getRTPInputProperties().getBitRate() is not deterministic (CiscoRTPInputStartedEv for TB).getRTPInputProperties().getPacketSize() is not deterministic (CiscoRTPOutputStartedEv for TB).getRTPOutputProperties().getPayloadType() will return CiscoRTPPayload.ISAC (CiscoRTPOutputStartedEv for TB).getRTPOutputProperties().getBitRate() is not deterministic (CiscoRTPOutputStartedEv for TB).getRTPOutputProperties().getPacketSize() is not deterministic TB: CiscoRTPOutputStartedEv for TA TA: CiscoRTPInputStartedEv for TB TA: CiscoRTPOutputStartedEv for TB TB: CiscoRTPInputStartedEv for TA App sets RTP params on B JTAPI Cisco Unified IP 7931G Phone Interaction A and C are JTAPI application controllable Addresses. B1 and B2 are Address on Cisco Unified IP 7931G Terminal. Cisco Unified IP 7931G Terminal is configured to do Transfer across Addresses. B1 and B2 has shared Line B1’ and B2’ respectively configured on JTAPI controllable Terminal. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1062 Message Sequence Charts JTAPI Cisco Unified IP 7931G Phone Interaction

Page 1126 diagram

Page 1127

Call info Events Action Calling = A Called = B1 CurrCalling = A CurrCalled = B1 LRP = B1 JTAPI Event received to CallObserver at A GC-1 CiscoTransferStartedEv (ControllerAddress = B1, ControllerTerminalConnection = Null, FinalCall = GC1, TransferredCall = null) GC-1 ConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN GC-1 CallCtlConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC-1 CiscoTransferEndEv Scenario:1 Application is observing A: A calls B1, B1 answers – GC1 User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses transfer key to complete transfer. Calling = A Called = B1 CurrCalling = A CurrCalled = B1 LRP = B1 JTAPI Event received to CallObservers at A and B1’ GC-1 CiscoTransferStartedEv (ControllerAddress = B1, ControllerTerminalConnection = TC at TB1’, FinalCall = GC1, TransferredCall = null) GC1- TermConnDroppedEv for TB1’ Cause: CAUSE_NORMAL GC1- CallCtlTermConnDroppedEv for TB1’ Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC-1 ConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN GC-1 CallCtlConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC-1 CiscoTransferEndEv Scenario:2 Application is observing A, B1’: A calls B1, B1 answers – GC1 User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses transfer key to complete transfer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1063 Message Sequence Charts Message Sequence Charts

Page 1127 diagram

Page 1128

Call info Events Action Calling = A Called = B1 CurrCalling = A CurrCalled = B1 LRP = B1 Scenario:3 Application is observing A, B1’, B2’: A calls B1, B1 answers – GC1 User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses transfer key to complete transfer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1064 Message Sequence Charts Message Sequence Charts

Page 1128 diagram

Page 1129

Call info Events Action JTAPI Event received to CallObserver at A and B1’ GC-1 CiscoTransferStartedEv (ControllerAddress = B1, ControllerTerminalConnection = TC at TB1’, FinalCall = GC1, TransferredCall = GC2) GC1- TermConnDroppedEv for TB1’ Cause: CAUSE_NORMAL GC1- CallCtlTermConnDroppedEv for TB1’ Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC-1 ConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN GC-1 CallCtlConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- TermConnDroppedEv for TB2’ Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for TB2’ Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- CallInvalidEv Cause: CAUSE_NORMAL GC-1 CiscoTransferEndEv CallControlCause: CAUSE_TRANSFER GC2- CallInvalidEv Cause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1065 Message Sequence Charts Message Sequence Charts

Page 1129 diagram

Page 1130

Call info Events Action GC-1 CiscoTransferEndEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1066 Message Sequence Charts Message Sequence Charts

Page 1130 diagram

Page 1131

Call info Events Action Calling = A Called = B1 CurrCalling = A CurrCalled = B1 LRP = B1 Scenario:4 Application is observing A, B1’, B2’ and C: A calls B1, B1 answers – GC1 User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses transfer key to complete transfer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1067 Message Sequence Charts Message Sequence Charts

Page 1131 diagram

Page 1132

Call info Events Action JTAPI Event received to CallObserver at A, B1’, B2’ and C GC-1 CiscoTransferStartedEv (ControllerAddress = B1, ControllerTerminalConnection = TC at TB1’, FinalCall = GC1, TransferredCall = GC2) GC1- TermConnDroppedEv for TB1’ Cause: CAUSE_NORMAL GC1- CallCtlTermConnDroppedEv for TB1’ Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC-1 ConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN GC-1 CallCtlConnDisconnectedEv for B1 Cause: CAUSE_UNKNOWN CallControlCause: CAUSE_TRANSFER GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC1- TermConnCreatedEv CT Cause: Other: 31 GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL GC2- TermConnDroppedEv for TB2’ Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for TB2’ Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for B2 Cause: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1068 Message Sequence Charts Message Sequence Charts

Page 1132 diagram

Page 1133

Call info Events Action CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- CallInvalidEv Cause: CAUSE_NORMAL GC-1 CiscoTransferEndEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1069 Message Sequence Charts Message Sequence Charts

Page 1133 diagram

Page 1134

Call info Events Action Calling = B2 Called = C CurrCalling = A CurrCalled = C LRP = B1 Scenario:5 Application is observing C: A calls B1, B1 answers – GC1 User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses transfer key to complete transfer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1070 Message Sequence Charts Message Sequence Charts

Page 1134 diagram

Page 1135

Call info Events Action JTAPI Event received to CallObserver at C GC1- CallActiveEv for callID = 101 Cause: CAUSE_NEW_CALL GC1- ConnCreatedEv for C Cause: CAUSE_NORMAL GC1- ConnCreatedEv for B2 Cause: CAUSE_NORMAL GC-1CiscoTransferStartEv (ControllerAddress = B1, ControllerTerminalConnection = Null, FinalCall = GC1, TransferredCall = GC2) Cause: CAUSE_NORMAL GC1- ConnConnectedEv for C Cause: CAUSE_NORMAL GC1- CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC1- TermConnCreatedEv CT Cause: Other: 31 GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER CallControlCause: CAUSE_TRANSFER GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- CallInvalidEv Cause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1071 Message Sequence Charts Message Sequence Charts

Page 1135 diagram

Page 1136

Call info Events Action GC1- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC1- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC1- 1 CiscoTransferEndEv Cause: CAUSE_NORMAL GC1- ConnCreatedEv for A Cause: CAUSE_NORMAL GC1- ConnConnectedEv for A Cause: CAUSE_NORMAL GC1- CallCtlConnEstablishedEv for A Cause: CAUSE_NORMAL GC1- ConnConnectedEv for B2 Cause: CAUSE_NORMAL GC1- CallCtlConnEstablishedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER CallControlCause: CAUSE_TRANSFER Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1072 Message Sequence Charts Message Sequence Charts

Page 1136 diagram

Page 1137

Call info Events Action Calling = A Called = B1 CurrCalling = A CurrCalled = C LRP = B1 Scenario:6 Application is observing both A and C: A calls B1, B1 answers – GC1 User presses transfer key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses transfer key to complete transfer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1073 Message Sequence Charts Message Sequence Charts

Page 1137 diagram

Page 1138

Call info Events Action JTAPI events at observer of A & C: GC-1CiscoTransferStartEv (ControllerAddress = B1, ControllerTerminalConnection = Null, FinalCall = GC1, TransferredCall = GC2) Cause: CAUSE_NORMAL GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC2- CallInvalidEv Cause: CAUSE_NORMAL GC1- 1 CiscoTransferEndEv Cause: CAUSE_NORMAL GC1- ConnCreatedEv for C Cause: CAUSE_NORMAL GC1- ConnConnectedEv for C Cause: CAUSE_NORMAL GC1- CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER GC1- TermConnCreatedEv CT Cause: Other: 31 GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER NEW META GC-1 ConnDisconnectedEv for B1 –GC1 Cause: CAUSE_UNKNOWN GC-1 CallCtlConnDisconnectedEv for B1 – GC1 Cause: CAUSE_UNKNOWN CallControlCause: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1074 Message Sequence Charts Message Sequence Charts

Page 1138 diagram

Page 1139

Call info Events Action CAUSE_TRANSFER Calling = A Called = B1 CurrCalling = A CurrCalled = Conference LRP = B1 JTAPI Event received to CallObserver at A GC-1 CiscoConferenceStartedEv (ControllerAddress = B1, ControllerTerminalConnection = Null, FinalCall = GC1, ConsultCall = null) GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC-1 CiscoConferenceEndEv Scenario:7 Application is observing A: A calls B1, B1 answers – GC1 User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses conference key to complete conference Calling = A Called = B1 CurrCalling = A CurrCalled = Conference LRP = B1 JTAPI Event received to CallObserver at A GC-1 CiscoConferenceStartedEv (ControllerAddress = B1, ControllerTerminalConnection = TC at TB1’, FinalCall = GC1, ConsultCall = null) GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1 TermConnPassiveEv TB1’ GC1 CallCtlTermConnBridgedEv TB1’ GC-1 CiscoConferenceEndEv Scenario:8 Application is observing A, B1’: A calls B1, B1 answers – GC1 User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses conference key to complete conference Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1075 Message Sequence Charts Message Sequence Charts

Page 1139 diagram

Page 1140

Call info Events Action Calling = A Called = B1 CurrCalling = A CurrCalled = Conference LRP = B1 JTAPI Event received to CallObserver at A, B1’ and B2’ GC-1 CiscoConferenceStartedEv (ControllerAddress = B1, ControllerTerminalConnection = TC at TB1’, FinalCall = GC1, ConsultCall = GC2) GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1 TermConnPassiveEv – TB1’ GC1 CallCtlTermConnBridgedEv – TB1’ GC2- TermConnDroppedEv for TB2’ Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for TB2’ Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- CallInvalidEv Cause: CAUSE_NORMAL GC-1 CiscoConferenceEndEv Scenario:9 Application is observing A, B1’, B2’: A calls B1, B1 answers – GC1 User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses conference key to complete conference Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1076 Message Sequence Charts Message Sequence Charts

Page 1140 diagram

Page 1141

Call info Events Action Calling = A Called = B1 CurrCalling = A CurrCalled = Conference LRP = B1 Scenario:10 Application is observing A, B1’, B2’, and C: A calls B1, B1 answers – GC1 User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses conference key to complete conference Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1077 Message Sequence Charts Message Sequence Charts

Page 1141 diagram

Page 1142

Call info Events Action JTAPI Event received to CallObserver at A, B1’, B2’ and C GC-1 CiscoConferenceStartedEv (ControllerAddress = B1, ControllerTerminalConnection = TC at TB1’, FinalCall = GC1, ConsultCall = GC2) GC-1 ConnCreatedEv for C Cause: CAUSE_NORMAL GC-1 ConnConnectedEv for C Cause: CAUSE_NORMAL GC-1 CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1 TermConnPassiveEv - TB1’ GC1 CallCtlTermConnBridgedEv - TB1’ GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL GC2- TermConnDroppedEv for TB2’ Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for TB2’ Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- TermConnDroppedEv for TC Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for TC Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- CallInvalidEv Cause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1078 Message Sequence Charts Message Sequence Charts

Page 1142 diagram

Page 1143

Call info Events Action GC-1 CiscoConferenceEndEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1079 Message Sequence Charts Message Sequence Charts

Page 1143 diagram

Page 1144

Call info Events Action Calling = B2 Called = C CurrCalling = A CurrCalled = Conference LRP = B1 Scenario:11 Application is observing C: A calls B1, B1 answers – GC1 User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses conference key to complete conference. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1080 Message Sequence Charts Message Sequence Charts

Page 1144 diagram

Page 1145

Call info Events Action JTAPI Event received to CallObserver at C GC1- CallActiveEv for callID = 101 Cause: CAUSE_NEW_CALL GC1- ConnCreatedEv for C Cause: CAUSE_NORMAL GC1- ConnCreatedEv for B2 Cause: CAUSE_NORMAL GC-1CiscoConferenceStartEv (ControllerAddress = B1, ControllerTerminalConnection = Null, FinalCall = GC1, ConsultCall = GC2) Cause: CAUSE_NORMAL GC1- ConnConnectedEv for C Cause: CAUSE_NORMAL GC1- CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1- TermConnCreatedEv CT Cause: Other: 31 GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1- ConnConnectedEv for B2 Cause: CAUSE_NORMAL GC1- CallCtlConnEstablishedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1081 Message Sequence Charts Message Sequence Charts

Page 1145 diagram

Page 1146

Call info Events Action GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- CallInvalidEv Cause: CAUSE_NORMAL GC1- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC1- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1- ConnCreatedEv for A Cause: CAUSE_NORMAL GC1- ConnConnectedEv for A Cause: CAUSE_NORMAL GC1- CallCtlConnEstablishedEv for A Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1- ConnCreatedEv for B1 Cause: CAUSE_NORMAL GC1- ConnConnectedEv for B1 Cause: CAUSE_NORMAL GC1- CallCtlConnEstablishedEv for B1 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1- 1 CiscoConferenceEndEv Cause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1082 Message Sequence Charts Message Sequence Charts

Page 1146 diagram

Page 1147

Call info Events Action Calling = A Called = B1 CurrCalling = A CurrCalled = Conference LRP = B1 JTAPI events at observer of A & C: GC-1CiscoConferenceStartEv (ControllerAddress = B1, ControllerTerminalConnection = Null, FinalCall = GC1, ConsultCall = GC2) Cause: CAUSE_NORMAL GC2- CiscoCallChangedEv for C Cause: CAUSE_NORMAL GC2- ConnDisconnectedEv for B2 Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for B2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- TermConnDroppedEv for CT Cause: CAUSE_NORMAL GC2- CallCtlTermConnDroppedEv for CT Cause: CAUSE_NORMAL CallControlCause:CAUSE_TRAN CAUSE_CONFERENCE SFER GC2- ConnDisconnectedEv for C Cause: CAUSE_NORMAL GC2- CallCtlConnDisconnectedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC2- CallInvalidEv Cause: CAUSE_NORMAL GC1- ConnCreatedEv for C Cause: CAUSE_NORMAL GC1- ConnConnectedEv for C Cause: CAUSE_NORMAL GC1- CallCtlConnEstablishedEv for C Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1- TermConnCreatedEv CT Cause: Other: 31 GC1- TermConnActiveEv CT Cause: CAUSE_NORMAL GC1- CallCtlTermConnTalkingEv CT Cause: CAUSE_NORMAL CallControlCause: CAUSE_CONFERENCE GC1- 1 CiscoConferenceEndEv Cause: CAUSE_NORMAL Scenario:12 Application is observing both A and C: A calls B1, B1 answers – GC1 User presses conference key on Cisco Unified IP 7931G phone and dials C, call initiated from B2 to C: B2 calls C, C answers - GC2 User presses conference key to complete conference. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1083 Message Sequence Charts Message Sequence Charts

Page 1147 diagram

Page 1148

Locale Infrastructure Development Scenarios Scenario 1—JTAPI Client Machine Has Connectivity to CallManager TFTP Server • During install, JTAPI client would prompt user to enter TFTP IP address. • TFTP-IP Address is stored in JTAPI.ini parameter. • JTAPI Preferences application is run first time, it will take user to language tab to language selection. • User can select language for running JTAPI Preference application. • JTAPI Preference application is run second time, it will present UI in the language that user selected before. Scenario 2—JTAPI Client Machine Doesn’t Have Connectivity to CallManager TFTP Server • During install JTAPI Client would prompt user to Enter TFTP-IP Address • TFTP-IP Address is stored in JTAPI.ini parameter. • JTAPI Preferences application is run first time, it will take user to language tab to language selection but user will have only English language to select. • JTAPI Preference application is run second time, it will present UI in the English languages. • TFTP connectivity is restored. Now JTAPI Preferences UI is run, it will take user to language selection Scenario 3—JTAPI Client Machine Has Connectivity to CallManager TFTP Server • During install JTAPI Client would prompt user to Enter TFTP-IP Address • TFTP-IP Address is stored in JTAPI.ini parameter. • JTAPI Preferences application is run first time, it will take user to language tab to language selection. • User can select language for running JTAPI Preference application. • JTAPI Preference application is run second time, it will present UI in the language that user selected before. • Now new locale files are available with added support for a new languages. • User runs JTAPI Preferences application, JTAPI Preferences application would notify user about available. • Application restart JTAPI Preferences application, user will be support for new language. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1084 Message Sequence Charts Locale Infrastructure Development Scenarios

Page 1148 content

Page 1149

Calling Party Normalization Scenario 1—Incoming Call From a PSTN Number (Local) to JTAPI Observed Terminal Call info Events Action Calling: A (55555555) Called: B (2222) getModifiedCallingAddress (): A (55555555) getModifiedCalledAddress (): B (2222.) getCurrentCalledAddress(): B (2222) getCurrentCalledPartyInfo(): B (2222) getGlobalizedCallingParty: A +140855555555 getCurrentCallingPartyInfo NumberType(). getNumberType() would return: Subscriber NEW META EVENT_________META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause:CAUSE_NORMAL ConnConnectedEv for A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause: CAUSE_NORMAL TernConnActiveEv for A Cause: CAUSE_NORMAL CallCtlConnDialingEv for A Cause: CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL ConnCreatedEv for B cause: CAUSE_NORMAL ConnInProgressEv for B Cause: CAUSE_NORMAL CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL ConnAlertingEv for B Cause CAUSE_NORMAL CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause: CAUSE_NORMAL TermConnRingingEv for B Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL A call is offered from a PSTN Number [55555555] A & the Number type is [Subscriber] through the gateway to a JTAPI Observed Terminal [2222] B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1085 Message Sequence Charts Calling Party Normalization

Page 1149 diagram

Page 1150

Scenario Two—Incoming Call From a National PSTN Number to JTAPI Observed Terminal Call info Events Action Calling: A (97255555555) Called: B (2222) getModifiedCallingAddress (): 97255555555 getModifiedCalledAddress (): 2222 getCurrentCalledAddress(): 2222 getCurrentCalledPartyInfo(): 2222 getGlobalizedCallingParty (): +197255555555 getCurrentCallingPartyInfo NumberType(). getNumberType() would return: National NEW META EVENT_________META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause: CAUSE_NORMAL TernConnActiveEv for A Cause: CAUSE_NORMAL CallCtlConnDialingEv for A Cause: CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL ConnCreatedEv for B cause: CAUSE_NORMAL ConnInProgressEv for B Cause: CAUSE_NORMAL CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL ConnAlertingEv for B Cause: CAUSE_NORMAL CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause: CAUSE_NORMAL TermConnRingingEv for B Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL A call is offered from a Dallas PSTN Number [55555555] A & the Number type is [National] through a gateway to a JTAPI Observed Terminal [2222] B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1086 Message Sequence Charts Message Sequence Charts

Page 1150 diagram

Page 1151

Scenario Three—Incoming Call From Inter-National PSTN Number to JTAPI Observed Terminal Call info Events Action Calling: A (918028520261) Called: B (2222) getModifiedCallingAddress (): 918028520261 getModifiedCalledAddress (): 2222 getCurrentCalledAddress(): 2222 getCurrentCalledPartyInfo(): 2222 getGlobalizedCallingParty (): +918028520261 getCurrentCallingPartyInfo NumberType(). getNumberType() would return: Inter-National NEW META EVENT_________META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause: CAUSE_NORMAL TernConnActiveEv for A Cause: CAUSE_NORMAL CallCtlConnDialingEv for A Cause: CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL ConnCreatedEv for B cause: CAUSE_NORMAL ConnInProgressEv for B Cause: CAUSE_NORMAL CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL ConnAlertingEv for B Cause: CAUSE_NORMAL CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause: CAUSE_NORMAL TermConnRingingEv for B Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL A Call is offered from India PSTN Number [918028520261] & the Number type is [Inter-national] through a San Jose Gateway to a JTAPI observed Terminal [2222] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1087 Message Sequence Charts Message Sequence Charts

Page 1151 diagram

Page 1152

Scenario Four—Outgoing Call From JTAPI Observed Terminal to PSTN Number [SUBSCRIBER] Call info Events Action Calling: A (2222) Called: B (44444444) getModifiedCallingAddress (): 2222 getModifiedCalledAddress (): 44444444 getCurrentCalledAddress(): 44444444 getCurrentCalledPartyInfo(): 44444444 getGlobalizedCallingParty (): 2222 getCurrentCallingPartyInfo NumberType (). getNumberType () would return: Unknown. NEW META EVENT_________META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause: CAUSE_NORMAL TernConnActiveEv for A Cause: CAUSE_NORMAL CallCtlConnDialingEv for A Cause: CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL ConnCreatedEv for B cause: CAUSE_NORMAL ConnInProgressEv for B Cause: CAUSE_NORMAL CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL ConnAlertingEv for B Cause: CAUSE_NORMAL CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause: CAUSE_NORMAL TermConnRingingEv for B Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL A call is initiated from a JTAPI Observed Terminal 2222 through a San Jose gateway to a PSTN number [44444444] and the Number type is [SUBSCRIBER] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1088 Message Sequence Charts Message Sequence Charts

Page 1152 diagram

Page 1153

Scenario Five—Outgoing Call From JTAPI Observed Terminal to National PSTN Number Call info Events Action Calling: A (2222) Called: B (97244444444) getModifiedCallingAddress (): 2222 getModifiedCalledAddress(): 97244444444 getCurrentCalledAddress(): 97244444444 getCurrentCalledPartyInfo(): 97244444444 getGlobalizedCallingParty (): 2222 getCurrentCallingPartyInfo NumberType(). getNumberType() would return: Unknown. NEW META EVENT_________META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause: CAUSE_NORMAL TernConnActiveEv for A Cause: CAUSE_NORMAL CallCtlConnDialingEv for A Cause: CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL ConnCreatedEv for B cause: CAUSE_NORMAL ConnInProgressEv for B Cause: CAUSE_NORMAL CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL ConnAlertingEv for B Cause: CAUSE_NORMAL CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause: CAUSE_NORMAL TermConnRingingEv for B Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL A call is initiated from a JTAPI Observed Terminal 2222 through a San Jose gateway to a Dallas PSTN number [97244444444] & the Number type is [NATIONAL] Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1089 Message Sequence Charts Message Sequence Charts

Page 1153 diagram

Page 1154

Scenario Six—Outgoing Call From JTAPI Observed Terminal to International PSTN Number Call info Events Action Calling: A (2222) Called: B (918028520261) getModifiedCallingAddress (): 2222 getModifiedCalledAddress (): 918028520261 getCurrentCalledAddress():918028520261 getCurrentCalledPartyInfo(): 918028520261 getGlobalizedCallingParty (): 2222 getCurrentCallingPartyInfo NumberType(). getNumberType() would return: Unknown. NEW META EVENT_________META_CALL_STARTING CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause: CAUSE_NORMAL TernConnActiveEv for A Cause: CAUSE_NORMAL CallCtlConnDialingEv for A Cause: CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL ConnCreatedEv for B cause: CAUSE_NORMAL ConnInProgressEv for B Cause: CAUSE_NORMAL CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL ConnAlertingEv for B Cause: CAUSE_NORMAL CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause: CAUSE_NORMAL TermConnRingingEv for B Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL A call is initiated from a JTAPI Observed Terminal 2222 through a San Jose gateway to India PSTN number [918028520261] & the Number type is [INTERNATIONAL] Scenario Seven—Incoming Call From PSTN Redirected to Another PSTN by JTAPI Observed Terminal Call info Events Action Calling: A (55555555)Called: B (2222) NEW META EVENT_________META_CALL_STARTING A call is offered from PSTN [55555555] through a San Jose Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1090 Message Sequence Charts Message Sequence Charts

Page 1154 diagram

Page 1155

Call info Events Action getModifiedCallingAddress (): 55555555 getModifiedCalledAddress (): 2222 getCurrentCalledAddress(): 2222 getCurrentCalledPartyInfo(): 2222 getGlobalizedCallingParty (): +140855555555 getCurrentCallingPartyInfo NumberType(). getNumberType() would return: SUBSCRIBER destinationAddress: 44444444. getCurrentCallingPartyInfo NumberType(). getNumberType() would return: Unknowns CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause:CAUSE_NORMAL ConnConnectedEv for A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause: CAUSE_NORMAL TernConnActiveEv for A Cause: CAUSE_NORMAL CallCtlConnDialingEv for A Cause: CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause: CAUSE_NORMAL ConnCreatedEv for B cause:CAUSE_NORMAL ConnInProgressEv for B Cause: CAUSE_NORMAL CallCtlConnOfferedEv for B Cause: CAUSE_NORMAL ConnAlertingEv for B Cause: CAUSE_NORMAL CallCtlConnAlertingEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause: CAUSE_NORMAL TermConnRingingEv for B Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv Cause: CAUSE_NORMAL CallRedirectReq Redirect Address = C CallRedirectRes ConnCreatedEv at C Cause: CAUSE_REDIRECTED ConnInProgress Calling party:A, Called Party: C, LRP: B CallRedirectResCallStateChangedEv(IDLE) Reason: REDIRECT Gateway to a JTAPI observed terminal [2222] which redirects the call to another San Jose PSTN [44444444]. In CallState [Idle] the fwdDestination Address (Redirect Address) should be a minus (-). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1091 Message Sequence Charts Message Sequence Charts

Page 1155 diagram

Page 1156

Scenario Eight—Incoming Call From PSTN Number (Local) to JTAPI Observed Terminal Who Transfers to Another JTAPI Observed Terminal Call info Events Action After Transfer: Calling: A (55555555) Called: B (2222) getModifiedCallingAddress (): A (+140855555555) getModifiedCalledAddress (): B (2222.) getCurrentCalledAddress(): B (2222) getCurrentCalledPartyInfo(): B (2222) getGlobalizedCallingParty: A +140855555555 getCurrentCallingPartyInfo NumberType(). getNumberType() would return: Subscriber After Transfer: GC1: CiscoTransferStartEv ConnCreatedEv for B ConnConnectedEv for B CallCtlConnEstablishedEv for B TermConnDroppedEv for X ConnDisconnectedEv for X CallCtlConnDisconnectedEv for X CiscoTransferStartEv GC2: CiscoTransferStartEv TermConnDroppedEv for X ConnDisconnectedEv for X CallCtlConnDisconnectedEv for X CiscoTransferStartEv A call is offered from a PSTN Number [55555555] A & the Number type is [Subscriber] through a San Jose gateway to a JTAPI observed Terminal [1111] X which transfers the call to another JTAPI Observed Terminal [2222] B Click to Conference A, B, C and D are addresses and TermA, TermB, TermC and TermD are corresponding terminals. Call info Events Action callingAddress = unknown calledAddress = C CurrentCalling = unknown CurrentCalled = C GC2: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_CONFERENCE GC2: ConnCreatedEv C CiscoFeatureReason = REASON_CONFERENCECause: CAUSE_NORMAL GC2: ConnInProgressEv C CiscoFeatureReason = REASON_CONFERENCECause: CAUSE_NORMAL A and B are in a call GC1 created using click-to-call. User adds C to the conference call. GC2 is the initial call at C. Application is observing only C GC2: CallCtlConnOfferedEv C CiscoFeatureReason = REASON_CONFERENCECause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1092 Message Sequence Charts Click to Conference

Page 1156 diagram

Page 1157

Call info Events Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1093 Message Sequence Charts Message Sequence Charts

Page 1157 diagram

Page 1158

Call info Events Action GC2: ConnAlertingEv C CiscoFeatureReason = REASON_CONFERENCECause: CAUSE_NORMAL GC2: CallCtlConnAlertingEv C CiscoFeatureReason = REASON_CONFERENCECause: CAUSE_NORMAL GC2: TermConnCreatedEv TermC GC2: TermConnRingingEv TermC CiscoFeatureReason = REASON_CONFERENCE Cause: CAUSE_NORMAL GC2: CallCtlTermConnRingingEv TermC CiscoFeatureReason = REASON_CONFERENCE Cause: CAUSE_NORMAL CiscoCallChangedEv GC2->GC1 CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE GC1: ConnCreatedEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: ConnAlertingEv C GC1 CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: CallCtlConnAlertingEv C GC1 CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: TermConnCreatedEv TermC GC1: TermConnRingingEv TermC CiscoCallChangedEv GC2->GC1 CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC2: TermConnDroppedEv TermC CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC2: CallCtlTermConnDroppedEv TermC CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC2: ConnDisconnectedEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1094 Message Sequence Charts Message Sequence Charts

Page 1158 diagram

Page 1159

Call info Events Action GC2: CallCtlConnDisconnectedEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC2: CallInvalidEv CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: ConnCreatedEv B CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: ConnConnectedEv B CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: CallCtlConnEstablishedEv B CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: ConnCreatedEv A CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: ConnConnectedEv A CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: CallCtlConnEstablishedEv A CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: ConnConnectedEv C CiscoFeatureReason = REASON_NORMALCause: CAUSE_NORMAL GC1: CallCtlConnEstablishedEv C CiscoFeatureReason = REASON_NORMALCause: CAUSE_NORMAL GC1: TermConnTalkingEv TermC CiscoFeatureReason = REASON_NORMALCause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1095 Message Sequence Charts Message Sequence Charts

Page 1159 diagram

Page 1160

Call info Events Action Calling address: A Called address: B Current calling: A Current called: B Last redirecting party = null After C is conferenced, callinfo is not applicable. A calls B using click-to-call – GC1. A adds C to the call using click-2-conf. Application has call observer on A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1096 Message Sequence Charts Message Sequence Charts

Page 1160 diagram

Page 1161

Call info Events Action GC1: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_REFER GC1: ConnCreatedEv A CiscoFeatureReason = REASON_REFER Cause: CAUSE_NORMAL GC1: ConnInProgressEv A CiscoFeatureReason = REASON_REFER Cause: CAUSE_NORMAL GC1: CallCtlConnOfferedEv A CiscoFeatureReason = REASON_REFER Cause: CAUSE_NORMAL GC1: ConnAlertingEv A CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL GC1: CallCtlConnAlertingEv A CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL GC1: TermConnCreatedEv TermA GC1: TermConnRingingEv TermA CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL GC1: CallCtlTermConnRingingEv TermA CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL GC1: GC1: ConnConnectedEv A CiscoFeatureReason = REASON_NORMAL cause: CAUSE_NORMAL GC1: CallCtlConnEstablishedEv A CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL TermConnActiveEv TermA CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL GC1: TermConnTalkingEv TermA CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL GC1: ConnCreatedEv B CiscoFeatureReason = REASON_REFER Cause: CAUSE_NORMAL GC1: ConnInProgressEv B CiscoFeatureReason = REASON_REFER Cause: CAUSE_NORMAL GC1: CallCtlConnOfferedEv B CiscoFeatureReason = REASON_REFER Cause: CAUSE_NORMAL GC1: ConnAlertingEv B CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL GC1: CallCtlConnAlertingEv B CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL GC1: GC1: ConnConnectedEv B CiscoFeatureReason = REASON_NORMAL: CAUSE_NORMAL GC1: CallCtlConnEstablishedEv B CiscoFeatureReason = REASON_NORMAL Cause: CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1097 Message Sequence Charts Message Sequence Charts

Page 1161 diagram

Page 1162

Call info Events Action GC1: ConnCreatedEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: ConnAlertingEv C CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL GC1: CallCtlConnAlertingEv TermC CiscoFeatureReason = REASON_CLICK_TO_CONFERENCE Cause: CAUSE_NORMAL For consult call GC3: Calling address: A Called address: D Callinfo not applicable after conference is completed. GC1: TermConnHeldEv TermA GC3: ConsultCallActiveEv GC3: ConnCreatedEv A GC3: ConnCreatedEv D GC3: CallCtlConnAlerting D GC3: ConnConnectedEv D GC3: CallCtlConnEstablishedEv B CiscoConferenceStartEv GC3->GC1 GC3: CallCtlConnDisconnectedEv A GC3: CallCtlConnDisconnectedEv D GC1: ConnCreatedEv D GC1: CallCtlConnEstablishedEv D GC1: TermConnTalkingEv TermA GC3: CallInvalidEv CiscoConferenceEndEvent A consults with D-GC3. A completes conference. The events received by application remains the same (as that of consult conference). Calling address: A Called address: B GC1: ConnDisconnectedEv D CiscoFeatureReason = REASON_CONFERENCECause: CAUSE_NORMAL GC1: CallCtlConnDisconnectedEv D CiscoFeatureReason = REASON_CONFERENCE Cause: CAUSE_NORMAL GC1: ConnDisconnectedEv C CiscoFeatureReason = REASON_CONFERENCECause: CAUSE_NORMAL GC1: CallCtlConnDisconnectedEv C CiscoFeatureReason = REASON_CONFERENCE Cause: CAUSE_NORMAL User drops D using click-2-conf feature User drops C using click-2-conference interface Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1098 Message Sequence Charts Message Sequence Charts

Page 1162 diagram

Page 1163

Call info Events Action Calling address: A Called address: B GC2: Calling address = unknown Called address: C GC1: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_REFER GC1: ConnCreatedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER Drop all parties a conference. A calls B using click-2-call. User adds C to the conference using click-2-conference. All parties are dropped using click to conference. Application has call observers on A, B and C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1099 Message Sequence Charts Message Sequence Charts

Page 1163 diagram

Page 1164

Call info Events Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1100 Message Sequence Charts Message Sequence Charts

Page 1164 diagram

Page 1165

Call info Events Action GC1: ConnInProgressEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER GC1: CallCtlConnOfferedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER GC1: ConnAlertingEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER GC1: CallCtlConnAlertingEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER GC1: TermConnCreatedEv TermA GC1: TermConnRingingEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlTermConnRingingEv TermA GC1: ConnConnectedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlConnEstablishedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: TermConnActiveEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlTermConnTalkingEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: ConnCreatedEv B Cause: CAUSE_NORMAL CiscoFeatureReason:REASON_REFER GC1: ConnInProgressEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER GC1: CallCtlConnOfferedEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_REFER GC1: ConnAlertingEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlConnAlertingEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: TermConnCreatedEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1101 Message Sequence Charts Message Sequence Charts

Page 1165 diagram

Page 1166

Call info Events Action GC1: TermConnRingingEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlTermConnRingingEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: ConnConnectedEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlConnEstablishedEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: TermConnActiveEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlTermConnTalkingEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_CONFERENCE GC2: ConnCreatedEv Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CONFERENCE GC2: ConnInProgressEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CONFERENCE GC2: CallCtlConnOfferedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CONFERENCE GC2: ConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: CallCtlConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: TermConnCreatedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: TermConnRingingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: CallCtlTermConnRingingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1102 Message Sequence Charts Message Sequence Charts

Page 1166 diagram

Page 1167

Call info Events Action GC2: CiscoCallChangedEv GC2->GC1 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: ConnCreatedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: ConnInProgressEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: CallCtlConnOfferedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: ConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: CallCtlConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: TermConnCreatedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason REASON_CLICK_TO_CONFERENCE GC1: TermConnRingingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: CallCtlTermConnRingingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC2: TermConnDroppedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC2: CallCtlTermConnDroppedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC2: ConnDisconnectedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC2: CallCtlConnDisconnectedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC2: CallInvalidEv Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1103 Message Sequence Charts Message Sequence Charts

Page 1167 diagram

Page 1168

Call info Events Action GC1: ConnConnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: CallCtlConnEstablishedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: TermConnActiveEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: CallCtlTermConnTalkingEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE All parties are dropped using click-2-conference GC1: TermConnDroppedEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: CallCtlTermConnDroppedEv TermA Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: ConnDisconnectedEv A Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: CallCtlConnDisconnectedEv A Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: TermConnDroppedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: CallCtlTermConnDroppedEv TermC Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: ConnDisconnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: CallCtlConnDisconnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: TermConnDroppedEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1104 Message Sequence Charts Message Sequence Charts

Page 1168 diagram

Page 1169

Call info Events Action GC1: CallCtlTermConnDroppedEv TermB Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: ConnDisconnectedEv B Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: CallCtlConnDisconnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE GC1: CallInvalidEv NA GC1: TermConnDroppedEv TermC CiscoFeatureReason = REASON_CONFERENCE A calls B using click-to-call – GC1. A adds C to the call using click-2-conf. User drops party C. Application has call observer on C only. GC1: CallCtlTermConnDroppedEv TermC CiscoFeatureReason = REASON_CONFERENCE GC1: ConnDisconnectedEv C CiscoFeatureReason = REASON_CONFERENCE GC1: CallCtlConnDisconnectedEv C CiscoFeatureReason = REASON_CONFERENCE GC1: ConnDisconnectedEv A CiscoFeatureReason = REASON_CONFERENCE GC1: CallCtlConnDisconnectedEv A CiscoFeatureReason = REASON_CONFERENCE GC1: ConnDisconnectedEv B CiscoFeatureReason = REASON_CONFERENCE GC1: CallCtlConnDisconnectedEv B CiscoFeatureReason = REASON_CONFERENCE GC1: CallInvalidEv Calling = unknown Called = C Last redirecting = null GC2: CallActiveEv CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_CONFERENCE A calls B using GC1. Address C is configured on TermC1 and TermC2. Application has call observer on C GC2: ConnCreatedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CONFERENCE User uses click-to-conference to C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1105 Message Sequence Charts Message Sequence Charts

Page 1169 diagram

Page 1170

Call info Events Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1106 Message Sequence Charts Message Sequence Charts

Page 1170 diagram

Page 1171

Call info Events Action GC2: ConnInProgressEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CONFERENCE GC2: CallCtlConnOfferedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CONFERENCE GC2: ConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: CallCtlConnAlertingEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: TermConnCreatedEv TermC1 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: TermConnRingingEv TermC1 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: TermConnCreatedEv TermC2 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC2: TermConnRingingEv TermC2 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallActiveEv Cause: CAUSE_NEW_CALL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: ConnCreatedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE CiscoCallChangedEv GC2->GC1 TermConn TermC1 CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: ConnAlertingEv C Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: CallCtlConnAlertingEv C Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: TermConnCreatedEv TermC1 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: TermConnRingingEv TermC1 Cause:CAUSE_NORMAL CiscoFeatureReason: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1107 Message Sequence Charts Message Sequence Charts

Page 1171 diagram

Page 1172

Call info Events Action REASON_CLICK_TO_CONFERENCE CiscoCallChangedEv GC2->GC1 TermConn TermC2 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: TermConnCreatedEv TermC2 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: TermConnRingingEv TermC2 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC2: CallCtlConnDisconnectedEv C Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC2: TermConnDroppedEv TermC1 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC2: TermConnDroppedEv TermC2 Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC2: CallInvalidEv GC1: ConnCreatedEv B Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: ConnConnectedEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: CallCtlConnEstablishedEv B Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: ConnCreatedEv A Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: ConnConnectedEv A Cause:CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE GC1: CallCtlConnEstablishedEv A Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_CLICK_TO_CONFERENCE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1108 Message Sequence Charts Message Sequence Charts

Page 1172 diagram

Page 1173

Call info Events Action C answers at TermC1 GC1: ConnConnectedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlConnEstablishedEv C Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlTermConnTalkingEv TermC1 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: TermConnPassEv TermC2 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL GC1: CallCtlTermConnInUseEv TermC2 Cause: CAUSE_NORMAL CiscoFeatureReason: REASON_NORMAL Call Pickup The basic test case for the fix was the following: 1. B and C are devices in a call pick up group. A is a device not in it. 2. A calls B. 3. C goes off-hook, and presses the Pickup softkey. 4. C is now on the call with A. This test was run with variations in which devices were observed, and the full matrix was run. This included: • Observing A, B, and C • Observing A and B • Observing A and C • Observing B and C • Observing only A • Observing only B • Observing only C The final test run, observing only C, was the primary concern for this fix, based on customer usage. The feature request was, when only observing C, being able to get information about the original called party (A) on Pickup. All test cases passed and the correct information was displayed for all of them. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1109 Message Sequence Charts Call Pickup

Page 1173 diagram

Page 1174

For cases 3 and 4, the call information depends on the order of events that JTAPI delivers. If JTAPI delivers the GC1-CallInvalidEvent/CallObservationEndedEv events before the GC2-CiscoCallChangedEv, then the call information, such as calling and called addresses, will be what was seen in GC2. Conversely, if JTAPI delivers the GC1-CallInvalidEvent/CallObservationEndedEv events after the GC2-CiscoCallChangedEv, then the call information, such as calling and called addresses, will be what was seen in GC1. As an example, if JTAPI delivers the GC1-CallInvalidEvent/CallObservationEndedEv events before the GC2-CiscoCallChangedEv, the Calling Address = C, Called Address = Pickup Number. If JTAPI delivers the GC1-CallInvalidEvent/CallObservationEndedEv events after the GC2-CiscoCallChangedEv, the Calling Address = A, Called Address = B. These test cases were run with auto-pickup enabled and disabled, and there was much difference in the functionality of the two. Most of the test cases are enumerated below. The basic call from A to B is the same in all cases, and is only shown in the first case below. Scenario One Observing all devices and auto-pickup enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1110 Message Sequence Charts Message Sequence Charts

Page 1174 content

Page 1175

Call info (GCID info) Events Action Calling: A, CCalled: NONE Calling: A, Called: NONE CAUSE_NEW_CALL REASON_NORMAL LRP: NONE CCalling: A, CCalled: B Calling: A, Called: B CCalling: C, CCalled: NONE CAUSE_NEW_CALL REASON_NORMAL LRP: NONE REASON_CALLPICKUP CCalling: A, CCalled: C LRP: NONE REASON_CALLPICKUP CCalling: C, CCalled: NONE LRP: NONE REASON_NORMAL REASON_CALLPICKUP CCalling: A, CCalled: C REASON_NORMAL A goes off-hook and dials B (Basic Call) B is ringing. C goes off-hook and presses Pickup softkey. Connection for C is dropped, B is dropped / cleaned up, C connection on Call 1 is established Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1111 Message Sequence Charts Message Sequence Charts

Page 1175 diagram

Page 1176

Call info (GCID info) Events Action GC1-CallActiveEvent-NONE GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CiscoCallChangedEv GC1-ConnCreatedEvent-C GC1-ConnConnectedEvent-C GC1-CallCtlConnInitiatedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1112 Message Sequence Charts Message Sequence Charts

Page 1176 diagram

Page 1177

Call info (GCID info) Events Action GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B GC1-CallCtlConnDisconnectedEv-B GC1-CallCtlConnEstablishedEv-C Both B and C in the following scenarios have exactly the same behavior and events. Only the behavior of device C (the one picking up the call) changes. Note Scenario Two Observing all devices with auto-pickup disabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1113 Message Sequence Charts Message Sequence Charts

Image 1 from page 1177

Page 1177 diagram

Page 1178

Call ID Info Events Action CCalling C, CCalled: NONE LRP: NONE REASON_NORMAL REASON_CALLPICKUP CCalling A, CCalled: C Calling: A, Called: C, LRP: B REASON_CALLPICKUP Calling A, CCalled: C Calling: A, Called: C, LRP: B REASON_CALLPICKUP REASON_NORMAL REASON_NORMAL GC2-CallActiveEvent GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B GC1-CallCtlConnDisconnectedEv-B GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C goes off-hook and presses Pickup softkey Call 2 gets dropped or invalidated C gets a connection on Call 1 B is dropped from Call 1 C is ringing C is on call with A The flow of events differs greatly when the auto-pickup option is enabled or disabled. When Auto Call Pickup is disabled and a user presses the Pickup softkey (C), the phone rings. The user has to answer the phone as if it is a normal call. When the phone is ringing, the original call that was created when they went offhook is terminated, they are connected to the existing call, and the old party (B) is removed from the call. There is no CiscoCallChangedEv generated when Auto Call Pickup is disabled, because the call does not change, it is terminated before C joins the new call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1114 Message Sequence Charts Message Sequence Charts

Page 1178 diagram

Page 1179

A Group Pickup scenario follows, during which the Group Pickup softkey is used in place of the Pickup softkey. This required actually dialing the number for the pickup group. Group Pickup also is subject to the Auto Call Pickup service parameter. The general flow and call events are identical to the normal Call Pickup scenarios, except with added events for the required dialing of the pickup number. Scenario Three Observing all devices with group pickup and auto-pickup enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1115 Message Sequence Charts Message Sequence Charts

Page 1179 content

Page 1180

Call ID Info Call event Action CCalling: C, CCalled: NONE LRP: NONE REASON_NORMAL CCalling: C, CCalled: NONE REASON_CALLPICKUP CCalling: C, CCalled: PU, LRP: PU CCalling C, CCalled: PU CCalling: A, CCalled: C, LRP: B Calling: A, Called: B REASON_CALLPICKUP CCalling: A, CCalled: C, LRP:B REASON_CALLPICKUP, LRP: PU CCalling: C, CCalled: PU REASON_CALLPICKUP CCalling: A, CCalled C, LRP: B REASON_CALLPICKUP CCalling: A, CCalled C, LRP: B REASON_CALLPICKUP GC1 [add to others to clarify] GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-C GC2-ConnCreatedEvent-PU GC2-ConnInprogressEvent-PU GC2-CallCtlConnEstablishedEv-C GC2-CiscoCallChangedEv GC1-ConnCreatedEvent-C GC1-ConnCreatedEvent-PU GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-ConnInprogressEvent-PU GC1-CallCtlConnOfferedEv-PU GC2-ConnDisconnectedEvent-PU GC2-CallCtlConnDisconnectedEv-PU GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-ConnDisconnectedEvent-PU GC1-CallCtlConnDisconnectedEv-PU GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B GC1-CallCtlConnDisconnectedEv-B C goes offhook and presses Group Pickup softkey C is dialing the PU Number C is added to the original call Pickup added to original call Pickup # is removed Call 2C is dropped from Call 2Pickup # is removed Call 1 B is dropped / invalidated There are only a handful of changes for the above Group Pickup case, and they all directly relate to the extra required step of dialing the pickup number. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1116 Message Sequence Charts Message Sequence Charts

Page 1180 diagram

Page 1181

Scenario Four Observing all devices with Group Pickup and Auto-Pickup disabled. Call info Event Action CCalling: C, CCalled: NO, NO LRP REASON_NORMAL CCalling: C, CCalled: NO, NO LRP REASON_NORMAL CCalling: C, CCalled: PU CCalling: C, CCalled: PU, LRP: PU REASON_CALLPICKUP CCalling: A, CCalled: C, LRP: B Calling: A, Called: B REASON_CALLPICKUP CCalling: A, CCalled: C, LRP: B REASON_CALLPICKUP REASON_NORMAL CCalling: A, CCalled: C, LRP: B REASON_NORMAL GC1 GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-C GC2-ConnCreatedEvent-PU GC2-ConnInprogressEvent-PU GC2-CallCtlConnEstablishedEv-C GC2-ConnDisconnectedEvent-PU GC2-CallCtlConnDisconnectedEv-PU GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-ConnCreatedEvent[ADDRS] GC1-ConnInprogressEvent GC1-CallCtlConnOfferedEv GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent GC1-CallCtlConnDisconnectedEv GC1-ConnAlertingEvent GC1-CallCtlConnAlertingEv GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnConnectedEvent GC1-CallCtlConnEstablishedEv GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C goes offhook and pressed “Group Pickup” softkey C is dialing the PU number PU is removed from Call 2 C is removed from Call 2 Call 2 is destroyed C gets a connection on Call 1 B is dropped from Call 1 C is ringingC picks up Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1117 Message Sequence Charts Message Sequence Charts

Page 1181 diagram

Page 1182

The tables above have scenarios during which all of the devices were observed. The devices were run with every possible combination, across all varieties of Pickup and Group Pickup. Parts of the scenarios had the exact same output and others were redundant and are not shown here. For example, device A and B were identical and shown only once. Scenario Five Only observing device B. Call IDs/Call info Call events Action CCalling: A, CCalled: B, Calling: A, Called: B, LRP: NONE REASON_NORMAL REASON_CALLPICKUP REASON_NORMAL GC1-CallActiveEvent-NONE GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnEstablishedEv-A GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv-B GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnDisconnectedEvent-A GC1-CallCtlConnDisconnectedEv-A GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B GC1-CallCtlConnDisconnectedEv-B GC1-CallInvalidEvent GC1-CallObservationEndedEv A is in the process of calling B B is ringing A is removed from Call 1 B is removed from Call 1 Scenario Six Observing only device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1118 Message Sequence Charts Message Sequence Charts

Page 1182 diagram

Page 1183

Call IDs/Call info Call events Action CCalling: A, CCalled: NO, NO LRP REASON_NORMAL CCalling A, CCalled B, Called: NOT SET LRP: NONE CCalling: A, CCalled: C, LRP: B Called: NOT SET REASON_CALLPICKUP REASON_NORMAL REASON_CALLPICKUP REASON_NORMAL GC1-CallActiveEvent-NONE GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv-B GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-ConnDisconnectedEvent-B GC1-CallCtlConnDisconnectedEv-B GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C A goes offhook and dials B B is ringing C is ringing B is removed from Call 1 Scenario Seven Observing only device C with Auto-Pickup enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1119 Message Sequence Charts Message Sequence Charts

Page 1183 diagram

Page 1184

Call IDs/Call info Call events Action CCalling: C, CCalled: NO, NO LRP REASON_NORMAL REAON_CALLPICKUP CCalling A, CCalled: NONE LRP: NONE CCalling: A, CCalled: C, LRP: B REASON_CALLPICKUP CCalling: C, CCalled: NONE REASON_CALLPICKUP REASON_CALLPICKUP CCalling A, CCalled: C, LRP: B REASON_CALLPICKUP REASON_NORMAL GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CiscoCallChangedEv GC1-CallActiveEvent-NONE GC1-ConnCreatedEvent-C GC1-ConnConnectedEvent-C GC1-CallCtlConnInitiatedEv GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnEstablishedEv-A GC1-CallCtlConnEstablishedEv-C C goes offhook and presses “Pickup” hotkey C is connected to Call 1 C is dropped from Call 2Call 2 is invalidated / cleared A and C are connected on Call 1 Scenario Eight Observing only device C with Auto-Pickup disabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1120 Message Sequence Charts Message Sequence Charts

Page 1184 diagram

Page 1185

Call IDs/Call info Call events Action CCalling: C, CCalled: NO, NO LR PREASON_NORMAL REASON_CALLPICKUP CCalling: C, CCalled: NONE REASON_NORMAL CCalling: A, CCalled: C, LRP: B REASON_CALLPICKUP REASON_NORMAL CCalling: A, CCalled: C, LRP: B REASON_NORMAL GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-CallActiveEvent GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnEstablishedEv-A GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C goes offhook and pressed “Pickup” softkey Call 2 is destroyed C is added to Call 1, but does not pick upC is ringing C picks up, and is connected to Call 1 Scenario Nine Observing only device C with Group Pickup and AutoPickup enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1121 Message Sequence Charts Message Sequence Charts

Page 1185 diagram

Page 1186

Call IDs/Call info Call event Action CCalling: C, CCalled: NO, NO LRP REASON_NORMAL CCalling: C, CCalled: PUCCalling: C, CCalled: PU, LRP: PU REASON_CALLPICKUP REASON_NORMAL REASON_CALLPICKUP CCalling: A, C Called: C CCalling: A, CCalled: C, LRP: B Calling: A, Called: B REASON_CALLPICKUP CCalling C, CCalled: PU, LRP: PU REASON_CALLPICKUP CCalling C, CCalled: PU, LRP: PU REASON_CALLPICKU PREASON_NORMAL CCalling: A, CCalled: C REASON_CALLPICKUP CCalling: A, CCalled: C REASON_CALLPICKUP GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-C GC2-ConnCreatedEvent-PU GC2-ConnInprogressEvent-PU GC2-CallCtlConnEstablishedEv-C GC2-CiscoCallChangedEv GC1-CallActiveEvent GC1-ConnCreatedEvent-C GC1-ConnCreatedEvent-PU GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-ConnInprogressEvent-PU GC1-CallCtlConnOfferedEv-PU GC2-ConnDisconnectedEvent-PU GC2-CallCtlConnDisconnectedEv-PU GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-PU GC1-CallCtlConnEstablishedEv-PU GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-ConnDisconnectedEvent-PU GC1-CallCtlConnDisconnectedEv-PU C goes offhook and presses “Pickup” softkey C dials the Pickup Number C is added to Call 1PU is added to Call 1 PU # is removed from Call 2 C is removed from Call 2Call 2 I invalidated / cleared C is connected to Call 1 PU is removed from Call 1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1122 Message Sequence Charts Message Sequence Charts

Page 1186 diagram

Page 1187

Scenario Ten Observing only device C with Group Pickup and Auto-Pickup disabled. Call IDs/Call info Call events Action CCalling: C, CCalled: NO, NO LRP REASON_NORMAL CCalling: C, CCalled: PU, LRP: PU REASON_CALLPICKUP REASON_NORMAL REASON_CALLPICKUP REASON_CALLPICKUP REASON_NOTMAL CCalling: A, CCalled: C, LRP: B REASON_CALLPICKUP REASON_NORMAL GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-C GC2-ConnCreatedEvent-PU GC2-ConnInprogressEvent-PU GC2-CallCtlConnEstablishedEv-C GC2-ConnDisconnectedEvent-PU GC2-CallCtlConnDisconnectedEv-PU GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC1-CallObservationEndedEv GC1-CallActiveEvent GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnEstablishedEv-A GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C goes offhook, and presses “Group Pickup” softkey C dials the PU Number PU is dropped from Call 2C is dropped from Call 2Call 2 is destroyed C is added to Call 1 C is ringing C is connected to A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1123 Message Sequence Charts Message Sequence Charts

Page 1187 diagram

Page 1188

selectRoute() with Calling Search Space and Feature Priority The selectRoute() API with calling search space and feature priority as array of int. is shown in the following table. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1124 Message Sequence Charts selectRoute() with Calling Search Space and Feature Priority

Page 1188 content

Page 1189

Call info Events Action calling: C lastRedirected:RP called: A GC1 CallActiveEv GC1 ConnCreatedEv C: GC1 ConnConnectedEv C GC1 CallCtlConnInitiatedEv C: GC1 TermConnCreatedEv TC GC1 TermConnActiveEv TC GC1 CallCtlTermConnTalkingEv TC GC1 CallCtlConnDialingEv C: GC1 CallCtlConnEstablishedEv C: GC1 ConnCreatedEv RP: GC1 ConnInProgressEv RP: GC1 CallCtlConnOfferedEv RP: After redirect request is processed GC1 ConnCreatedEv A: GC1 ConnInProgressEv A: GC1 CallCtlConnOfferedEv A: GC1 ConnDisconnectedEv RP: GC1 CallCtlConnDisconnectedEv RP: GC1 ConnAlertingEv A: GC1 CallCtlConnAlertingEv A: GC1 TermConnCreatedEv TA GC1 TermConnRingingEv TA GC1 CallCtlTermConnRingingEvImpl TA GC1 ConnConnectedEv A: GC1 CallCtlConnEstablishedEv A: GC1 TermConnActiveEv A GC1 TermConnActiveEv A [C] CiscoRTPInputStartedEv [A] CiscoRTPOutputStartedEv [A] CiscoRTPInputStartedEv [C] CiscoRTPOutputStartedEv Add call observer on phones A, B, C, D. Register Route Point RP Register route call back, with select route API with three rows route selected: A, .....CSS: 0, FP: 1 route selected: B, .....CSS: 1, FP:3 route selected: D, .....CSS: 1, FP:1 C calls RP Call rings at A. A answers. C-A call is connected. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1125 Message Sequence Charts Message Sequence Charts

Page 1189 diagram

Page 1190

Extension Mobility Login Username Terminal A is in control list of user, Terminal B is not in control list of User. Extension Mobility login username is John, end user id user for application is John. Call info Result Action NA InvalidStateException is thrown. Open provider, Terminal A doesn't have any observer, Application calls CiscoTerminal.getEMLoginUserName() at Terminal A. NA Application should get empty string “” for username. Open provider, Add Observer to Terminal A, Application calls CiscoTerminal.getEMLoginUserName() at Terminal A. NA Application should get String “John” Open provider, User “John” EMLogin to Terminal A and add observer to the Terminal A, Application calls CiscoTerminal.getEMLoginUserName() at Terminal A Note Application verifies if EM login has been done by invoking CiscoTerminal.getLoginType(). NA Application should get String “John” User “John” EMLogin to Terminal A, now open provider, add observer to Terminal A, Application calls CiscoTerminal.getEMLoginUserName() at Terminal A. Note Application verifies if EM login has been done by invoking CiscoTerminal.getLoginType(). NA Application should get empty string “” for username User “John” EMLogin to Terminal A, now open provider, add observer to Terminal A, User “John” EMLogout of Terminal A, Application calls CiscoTerminal.getEMLoginUserName() at Terminal A. Note Application verifies if EM login has been done by invoking CiscoTerminal.getLoginType(). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1126 Message Sequence Charts Extension Mobility Login Username

Page 1190 diagram

Page 1191

Call info Result Action NA Application should get String “John” OpenProvider, User “John” EMLogin to Terminal B, add observer, application calls CiscoTerminal.getEMLoginUserName() at Terminal B Note Application verifies if EM login has been done by invoking CiscoTerminal.getLoginType(). NA Application should get String “John” User “John” EMLogin to Terminal B, OpenProvider, add observer to Terminal B, Application calls CiscoTerminal.getEMLoginUserName() at Terminal B Note Application verifies if EM login has been done by invoking CiscoTerminal.getLoginType(). Terminal A is in control list of user and configured with the Extension Mobility logout profile of user Kerry. The Kerry profile is configured with logout username as Kerry. There is another profile with login username of John. Call info Result Action NA NA Application should get String John. Application should get String Kerry. User John logs into Terminal A, OpenProvider and add observer to Terminal A. Application calls CiscoTerminal.getEMLoginUserName() at Terminal A. John logs out at Terminal A. Application calls CiscoTerminal.getEMLoginUserName() at Terminal A. Note Application verifies if EM login has been done by invoking CiscoTerminal.getLoginType(). Calling Party IP Address The following are some examples of call scenarios. Basic Call Scenario • JTAPI application monitors party B • Party A is an IP phone • A calls B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1127 Message Sequence Charts Calling Party IP Address

Page 1191 diagram

Page 1192

• IP Address of A is available to JTAPI application monitoring party B Consultation Transfer Scenario • JTAPI application monitors party C • Party B is an IP phone • A talking 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 talking 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 (not a supported scenario). • Calling IP address of B is provided to JTAPI application monitoring party C. CiscoJtapiProperties 1. Set Socket Connect Timeout to 5 seconds; Plug out the Ethernet cable for PRIMARY CTI Manager and do a normal provider open. Expected Result: Socket Connect to Primary CTI Manager should fail in not more than 5 secs 2. Set Socket Connect Timeout to 5 seconds; Plug out the Ethernet cable for PRIMARY CTI Manager, set security options to True and do a secured provider open. Expected Result: Socket Connect to Primary CTI Manager should fail in not more than 5 secs (Socket Connect timed-out in ~5 seconds, though it took some additional time initially for verifying security certificates) 3. Set Socket Connect Timeout to 0 seconds; Plug out the Ethernet cable for PRIMARY CTI Manager, set security options to true and do a secured provider open. Expected Result: Socket Connect to Primary CTI Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1128 Message Sequence Charts CiscoJtapiProperties

Page 1192 content

Page 1193

Manager will no longer rely on new Service Parameter (Socket Connect timed-out in ~23 seconds, though it took some additional time initially for verifying security certificates). IPv6 Support Use Case1 - Basic Call Scenario: Calling Is IPv6 Enabled Phone; Called Is IPv6 Call info/Expected result Events Action CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return IPv6 format address for A as an InetAddress object. getCallingPartyIpAddr() will return null getRemoteAddress() on CiscoRTPOutputProperties in CiscoOutputStartedEv will contain the far-end Ipv6 RTP address(of A) getRemoteAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv6 RTP address of the monitored phone(B) NEW META EVENT_________META_CALL_STARTING IPv6 enabled phone A calls JTAPI Observed IPv6 enabled device B using GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1129 Message Sequence Charts IPv6 Support

Page 1193 diagram

Page 1194

Call info/Expected result Events Action CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause : CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause : CAUSE_NORMAL TernConnActiveEv for A Cause : CAUSE_NORMAL CallCtlConnDialingEv for A Cause : CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause : CAUSE_NORMAL ConnCreatedEv for B cause : CAUSE_NORMAL ConnInProgressEv for B Cause : CAUSE_NORMAL CallCtlConnOfferedEv for B Cause : CAUSE_NORMAL ConnAlertingEv for B Cause : CAUSE_NORMAL CallCtlConnAlertingEv for B Cause : CAUSE_NORMAL TermConnCreatedEv for B Cause : CAUSE_NORMAL TermConnRingingEv for B Cause : CAUSE_NORMAL CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL B Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1130 Message Sequence Charts Message Sequence Charts

Page 1194 diagram

Page 1195

Use Case2 - Basic Call Scenario: Calling Is IPv6 Enabled Phone; Called Is IPv4 Call info/Expected result Events Action CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return IPv6 format address for A as an InetAddress object. getCallingPartyIpAddr() will return null getRemoteAddress() on CiscoRTPOutputProperties in CiscoRTPOutputStartedEv will contain the far-end Ipv4 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion. getLocalAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv4 RTP address of the monitored phone NEW META EVENT_________META_CALL_STARTING IPv6 enabled phone A calls JTAPI Observed IPv4 enabled device B using GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1131 Message Sequence Charts Message Sequence Charts

Page 1195 diagram

Page 1196

Page 1196 diagram

Page 1197

Use Case3 - Basic Call Scenario: Calling Is IPv4 Enabled Phone; Called Is IPv6 Call info/Expected Result Events Action CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for A in an InetAddress object. CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return null getRemoteAddress() on CiscoRTPOutputProperties in CiscoRTPOutputStartedEv will contain the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion. getLocalAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv6 RTP address of the monitored phone NEW META EVENT_________META_CALL_STARTING IPv4 enabled phone A calls JTAPI Observed IPv6 enabled device B using GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1133 Message Sequence Charts Message Sequence Charts

Page 1197 diagram

Page 1198

Page 1198 diagram

Page 1199

Use Case4 - Basic Call Scenario: Calling Is IPv4 Enabled Phone; Called Is IPv4 Call info/Expected Result Events Action CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for A in an InetAddress object. CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return null getRemoteAddress() on CiscoRTPOutputProperties in CiscoRTPOutputStartedEv will contain the far-end Ipv4 RTP address. getLocalAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv4 RTP address of the monitored phone NEW META EVENT_________META_CALL_STARTING IPv4 enabled phone A calls JTAPI Observed IPv4 enabled device B using GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1135 Message Sequence Charts Message Sequence Charts

Page 1199 diagram

Page 1200

Page 1200 diagram

Page 1201

Use Case5 - Consultation Transfer Scenario, IPv6 Device Consults Call info/Expected Result Events Action For Consult Call: CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return IPv6 format address for B in an InetAddress object to the JTAPI Application observing C. While, CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return null NEW META EVENT_________META_CALL_STARTING GC1: Call between A & B Consult Call: IPv6 enabled phone B consults JTAPI Observed device C for Transfer using GC2. CallActiveEv for callID = GC2 Cause: CAUSE_NEW_CALL ConnCreatedEv for B Cause: CAUSE_NORMAL ConnConnectedEv for B Cause : CAUSE_NORMAL CallCtlConnInitiatedEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause : CAUSE_NORMAL TernConnActiveEv for B Cause : CAUSE_NORMAL CallCtlConnDialingEv for B Cause : CAUSE_NORMAL CallCtlConnEstabilishedEv for B Cause : CAUSE_NORMAL ConnCreatedEv for C cause : CAUSE_NORMAL ConnInProgressEv for C Cause : CAUSE_NORMAL CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL ConnAlertingEv for C Cause : CAUSE_NORMAL CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL TermConnCreatedEv for C Cause : CAUSE_NORMAL TermConnRingingEv for C Cause : CAUSE_NORMAL CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1137 Message Sequence Charts Message Sequence Charts

Page 1201 diagram

Page 1202

Use Case6 - Consultation Transfer Scenario, IPv4 Device Consults Call info/Expected Result Events Action CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for B in an InetAddress object to the JTAPI Application observing C While, CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return null NEW META EVENT_________META_CALL_STARTING GC1: Call between A & B Consult Call: IPv4 enabled phone B consults JTAPI Observed device C for Transfer using GC2. CallActiveEv for callID = GC2 Cause: CAUSE_NEW_CALL ConnCreatedEv for B Cause: CAUSE_NORMAL ConnConnectedEv for B Cause : CAUSE_NORMAL CallCtlConnInitiatedEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause : CAUSE_NORMAL TernConnActiveEv for B Cause : CAUSE_NORMAL CallCtlConnDialingEv for B Cause : CAUSE_NORMAL CallCtlConnEstabilishedEv for B Cause : CAUSE_NORMAL ConnCreatedEv for C cause : CAUSE_NORMAL ConnInProgressEv for C Cause : CAUSE_NORMAL CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL ConnAlertingEv for C Cause : CAUSE_NORMAL CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL TermConnCreatedEv for C Cause : CAUSE_NORMAL TermConnRingingEv for C Cause : CAUSE_NORMAL CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1138 Message Sequence Charts Message Sequence Charts

Page 1202 diagram

Page 1203

Use Case7: Redirect Scenario Call info/Expected Result Events Action CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return IPv6 format address for A in an InetAddress object to the JTAPI Application observing C While, CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return null New Meta Event_______META_CALL_STARTING GC1: Call between A(IPv6) & B Redirect Call: phone B redirects call to JTAPI Observed device C using GC2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1139 Message Sequence Charts Message Sequence Charts

Page 1203 diagram

Page 1204

Call info/Expected Result Events Action C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1140 Message Sequence Charts Message Sequence Charts

Page 1204 diagram

Page 1205

Call info/Expected Result Events Action CallActiveEv for callID = GC2 Cause: CAUSE_NEW_CALL ConnCreatedEv for B Cause: CAUSE_NORMAL ConnConnectedEv for B Cause : CAUSE_NORMAL CallCtlConnEstablishedEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause : CAUSE_NORMAL TernConnActiveEv for B Cause : CAUSE_NORMAL CallCtlTermConnTalkingEv for B Cause : CAUSE_NORMAL CallCtlConnDialingEv for B Cause : CAUSE_NORMAL ConnCreatedEv for A Cause : CAUSE_NORMAL CallCtlConnEstablishedEv for A Cause : CAUSE_NORMAL ConnCreatedEv for C cause : CAUSE_NORMAL ConnInProgressEv for C Cause : CAUSE_NORMAL CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL ConnAlertingEv for C Cause : CAUSE_NORMAL CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL TermConnCreatedEv for C Cause : CAUSE_NORMAL TermConnRingingEv for C Cause : CAUSE_NORMAL TermConnDroppedEv for B Cause : CAUSE_NORMAL ConnDisconnectedEv for B Cause : CAUSE_NORMAL CallCtlTermConnDroppedEv for B Cause : CAUSE_REDIRECTED ConnConnectedEv for C Cause : CAUSE_NORMAL TermConnActiveEv for C Cause : Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1141 Message Sequence Charts Message Sequence Charts

Page 1205 diagram

Page 1206

Call info/Expected Result Events Action CAUSE_NORMAL CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL Use Case8: Redirect Scenario (IPv4) Call info/Expected results Events Action CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for A in an InetAddress object to the JTAPI Application observing C While, CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr_v6() will return null New Meta Event_______META_CALL_STARTING GC1: Call between A(IPv4) & B Redirect Call: phone B redirects call to JTAPI Observed device C using GC2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1142 Message Sequence Charts Message Sequence Charts

Page 1206 diagram

Page 1207

Call info/Expected results Events Action C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1143 Message Sequence Charts Message Sequence Charts

Page 1207 diagram

Page 1208

Call info/Expected results Events Action CallActiveEv for callID = GC2 Cause: CAUSE_NEW_CALL ConnCreatedEv for B Cause: CAUSE_NORMAL ConnConnectedEv for B Cause : CAUSE_NORMAL CallCtlConnEstablishedEv for B Cause: CAUSE_NORMAL TermConnCreatedEv for B Cause : CAUSE_NORMAL TernConnActiveEv for B Cause : CAUSE_NORMAL CallCtlTermConnTalkingEv for B Cause : CAUSE_NORMAL CallCtlConnDialingEv for B Cause : CAUSE_NORMAL ConnCreatedEv for A Cause : CAUSE_NORMAL CallCtlConnEstablishedEv for A Cause : CAUSE_NORMAL ConnCreatedEv for C cause : CAUSE_NORMAL ConnInProgressEv for C Cause : CAUSE_NORMAL CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL ConnAlertingEv for C Cause : CAUSE_NORMAL CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL TermConnCreatedEv for C Cause : CAUSE_NORMAL TermConnRingingEv for C Cause : CAUSE_NORMAL TermConnDroppedEv for B Cause : CAUSE_NORMAL ConnDisconnectedEv for B Cause : CAUSE_NORMAL CallCtlTermConnDroppedEv for B Cause : CAUSE_REDIRECTED ConnConnectedEv for C Cause : CAUSE_NORMAL TermConnActiveEv for C Cause : Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1144 Message Sequence Charts Message Sequence Charts

Page 1208 diagram

Page 1209

Call info/Expected results Events Action CAUSE_NORMAL CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL Use Case9: Redirect Scenario, Calling Device Redirects Call info/Expected Result Events Action CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() will return IPv4 format address for B in an InetAddress object to the JTAPI Application observing C CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr() or, CiscoCallCtlConnOfferedEv. getCallingPartyIpAddr()_v6 will not return IP address for A in an InetAddress object to the JTAPI Application observing B after redirect. New Meta Event_______META_CALL_STARTING CallActiveEv for callID = GC2 Cause: CAUSE_NEW_CALL GC1: A calls B(IPv4) Redirect Call: Phone A redirects call to JTAPI Observed device C using GC2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1145 Message Sequence Charts Message Sequence Charts

Page 1209 diagram

Page 1210

Call info/Expected Result Events Action C Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1146 Message Sequence Charts Message Sequence Charts

Page 1210 diagram

Page 1211

Call info/Expected Result Events Action ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause : CAUSE_NORMAL CallCtlConnEstablishedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause : CAUSE_NORMAL TernConnActiveEv for A Cause : CAUSE_NORMAL CallCtlTermConnTalkingEv for A Cause : CAUSE_NORMAL CallCtlConnDialingEv for A Cause : CAUSE_NORMAL ConnCreatedEv for B Cause : CAUSE_NORMAL CallCtlConnEstablishedEv for B Cause : CAUSE_NORMAL ConnCreatedEv for C cause : CAUSE_NORMAL ConnInProgressEv for C Cause : CAUSE_NORMAL CallCtlConnOfferedEv for C Cause : CAUSE_NORMAL ConnAlertingEv for C Cause : CAUSE_NORMAL CallCtlConnAlertingEv for C Cause : CAUSE_NORMAL TermConnCreatedEv for C Cause : CAUSE_NORMAL TermConnRingingEv for C Cause : CAUSE_NORMAL TermConnDroppedEv for A Cause : CAUSE_NORMAL ConnDisconnectedEv for A Cause : CAUSE_NORMAL CallCtlTermConnDroppedEv for A Cause : CAUSE_REDIRECTED ConnConnectedEv for C Cause : CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1147 Message Sequence Charts Message Sequence Charts

Page 1211 diagram

Page 1212

Call info/Expected Result Events Action TermConnActiveEv for C Cause : CAUSE_NORMAL CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL Use Case10: Route Scenario, IPv6 Enabled Calls RoutePoint Which Routes Call to IPv6 Device Call info/Expected Result Events Action CiscoRouteEvent.getCallingPartyIpAddr_v6() will return IPv6 format address for A as an InetAddress object. While, CiscoRouteEvent. getCallingPartyIpAddr() will return null getRemoteAddress() on CiscoRTPOutputProperties in CiscoRTPOutputStartedEv will contain the far-end Ipv6 RTP address getLocalAddress() on CiscoRTPInputProperties in CiscoRTPInputStartedEv will contain the Ipv6 RTP address of the monitored phone NEW META EVENT_________META_CALL_STARTING IPv6 enabled phone A calls RoutePoint which routes the call to JTAPI Observed IPv6 enabled device B using GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1148 Message Sequence Charts Message Sequence Charts

Page 1212 diagram

Page 1213

Call info/Expected Result Events Action CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL ConnCreatedEv for A Cause: CAUSE_NORMAL ConnConnectedEv for A Cause : CAUSE_NORMAL CallCtlConnInitiatedEv for A Cause: CAUSE_NORMAL TermConnCreatedEv for A Cause : CAUSE_NORMAL TernConnActiveEv for A Cause : CAUSE_NORMAL CallCtlConnDialingEv for A Cause : CAUSE_NORMAL CallCtlConnEstabilishedEv for A Cause : CAUSE_NORMAL ConnCreatedEv for B cause : CAUSE_NORMAL ConnInProgressEv for B Cause : CAUSE_NORMAL CallRouteEv for B Cause : CAUSE_NORMAL ConnAlertingEv for B Cause : CAUSE_NORMAL CallCtlConnAlertingEv for B Cause : CAUSE_NORMAL TermConnCreatedEv for B Cause : CAUSE_NORMAL TermConnRingingEv for B Cause : CAUSE_NORMAL CallCtlTermConnTalkingEv Cause : CAUSE_NORMAL B Answers Use Case11: Enterprise Parameter “Enable IPv6” is Enabled Application does an open provider by providing the list of CTI Manager IPs as • IPv4 address of CTI Manager1 • IPv6 address of CTI Manager1 • IPv4 address of CTI Manager2 • IPv6 address of CTI Manager2 Now once the JTAPI is able to establish a connection with CTI Manager and later on if CTI Manager1 goes down, in failover attempt application can see delay in connecting as JTAPI will first try to connect with IPv6 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1149 Message Sequence Charts Message Sequence Charts

Page 1213 diagram

Page 1214

address of CTI Manager1 (which is next in the list) even though that IP address is of the same CTI Manager and only once it times out it will try with the IPv4 address of the CTI Manager2 which will succeed (assuming CTI Manager2 is running). Provider Open Scenario 1. Service Parameter for Reconnect Attempt is not set(or set to 0), Enterprise parameter “Enable IPv6” is disabled. Application tries to open a provider with IPv4 address. JTAPI will be able to open a connection with CTI manager. • CTI Manager is stopped – JTAPI will try reconnecting to CTI manager indefinitely till the CTI Manager is stared again and connection is restored. • Enterprise parameter “Enable IPv6”is enabled and CTI manager is restarted – JTAPI will be able to reconnect to CTI Manager with the same IPv4 address. 2. Service Parameter for Reconnect Attempt is not set (or set to 0), Enterprise parameter “Enable IPv6” is enabled. Application tries to open a provider with IPv4 address. JTAPI will be able to open a connection with CTI Manager. • CTI Manager is stopped – JTAPI will try reconnecting to CTI manager indefinitely till the CTI Manager is stared again and connection is restored. • Enterprise parameter “Enable IPv6”is disabled and CTI manager is restarted – JTAPI will be able to reconnect to CTI Manager with the same IPv4 address. But, the existing devices registered with IPv6 address will be closed with “CiscoTermRegistrationFailedEv” with a new reason code “IP_CAPABILITY_MISMATCH” 3. Service Parameter for Reconnect Attempt is not set (or set to 0), Enterprise parameter “Enable IPv6” is enabled. Application tries to open a provider with IPv6 address. JTAPI will be able to open a connection with CTI Manager. • CTI Manager is stopped – JTAPI will try reconnecting to CTI manager indefinitely till the CTI Manager is started again and connection is restored. • Enterprise parameter “Enable IPv6”is disabled and CTI manager is restarted – JTAPI will not be able to reconnect to CTI Manager, as it no longer supports IPv6 address but JTAPI will try reconnecting to CTI Manager indefinitely till the time service parameter is again enabled and CTI Service restarted. 4. Service Parameter for Reconnect Attempt is set to some integer value (say 5), Enterprise parameter “Enable IPv6” is disabled. Application tries to open a provider with IPv4 address. JTAPI will be able to open a connection with CTI manager. • CTI Manager is stopped – JTAPI will try reconnecting to CTI manager 5 times before closing all the opened devices and provider. • Enterprise parameter “Enable IPv6”is enabled and CTI manager is restarted – JTAPI will be able to reconnect to CTI Manager with the same IPv4 address. 5. Service Parameter for Reconnect Attempt is set to some integer value (say 5), Enterprise parameter “Enable IPv6” is enabled. Application tries to open a provider with IPv4 address. JTAPI will be able to open a connection with CTI Manager. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1150 Message Sequence Charts Provider Open Scenario

Page 1214 content

Page 1215

• CTI Manager is stopped – JTAPI will try reconnecting to CTI manager 5 times before closing all the opened devices and provider. • Enterprise parameter “Enable IPv6”is disabled and CTI manager is restarted – JTAPI will be able to reconnect to CTI Manager with the same IPv4 address. But, the existing devices registered with IPv6 address will be closed with “CiscoTermRegistrationFailedEv” with a new reason code “IP_CAPABILITY_MISMATCH” 6. Service Parameter for Reconnect Attempt is set to some integer value (say 5), Enterprise parameter “Enable IPv6” is enabled. Application tries to open a provider with IPv6 address. JTAPI will be able to open a connection with CTI Manager. • CTI Manager is stopped – JTAPI will try reconnecting to CTI manager 5 times before closing all the opened devices and provider. • Enterprise parameter “Enable IPv6”is disabled and CTI manager is restarted – JTAPI will not be able to reconnect to CTI Manager, as it no longer supports IPv6 address but JTAPI will try reconnecting to CTI Manager 5 more times (as the same can again be enabled on Cisco Unified Communications Manager) before closing all the devices and provider. 7. Enterprise parameter “Enable IPv6” is disabled. Application tries to open a provider with IPv6 address. JTAPI will not be able to open a connection with CTI manager. Retry attempts are applicable only if connection gets established once, but since in this scenario even the first attempt is failing so there will be no subsequent reconnect attempts. Enterprise parameter “Enable IPv6” is enabled. Application does an open provider by providing the list of CTI Manager IPs as • IPv4 address of CTI Manager1 • IPv6 address of CTI Manager1 • IPv4 address of CTI Manager2 • IPv6 address of CTI Manager2 Now once the JTAPI is able to establish a connection with CTI Manager and later on if CTI Manager1 goes down, in failover attempt application can see delay in connecting as JTAPI will first try to connect with IPv6 address of CTI Manager1 (which is next in the list) even though that IP address is of the same CTI Manager and only onMangerce it times out it will try with the IPv4 address of the CTI Manager2 which will succeed (assuming CTI Manager2 is running). Calling Party IP Address Scenarios 1. Ipv6 enabled phone calls a CTI controllable device. Subsequently, the CTI controllable device is monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv6 calling party IP address. getCallingPartyIpAddr() will return NULL getCallingPartyIpAddr_v6() will return the actual calling Party IPv6 address. 2. Ipv4 enabled phone calls a CTI controllable device. Subsequently, the CTI controllable device is monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv4 calling party IP address (existing behavior) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1151 Message Sequence Charts Calling Party IP Address Scenarios

Page 1215 content

Page 1216

getCallingPartyIpAddr() will return the actual calling Party IPv4 address. getCallingPartyIpAddr_v6() will return NULL. 3. Ipv6 only phone calls a CTI controllable device that is already monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv6 calling party IP address. getCallingPartyIpAddr() will return NULL getCallingPartyIpAddr_v6() will return the actual calling Party IPv6 address 4. Ipv4 enabled phone calls a CTI controllable device that is already monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv4 formatted calling party IP address. getCallingPartyIpAddr() will return the actual calling Party IPv4 address. getCallingPartyIpAddr_v6() will return NULL. 5. Ipv4_v6(Two Stack) phone calls a CTI controllable device. Subsequently, the CTI controllable device is monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv4 and Ipv6 calling party IP addresses. getCallingPartyIpAddr() will return the actual calling Party IPv4 address. getCallingPartyIpAddr_v6() will return the actual calling Party IPv6 address 6. Ipv4_v6(Two Stack) phone calls a CTI controllable device that is already monitored by a JTAPI application. JTAPI will generate a CiscoCallCtlConnOfferedEv (non-Route Points) or CiscoRouteEvent (Route Points) notification containing an Ipv4 and Ipv6 calling party IP addresses. getCallingPartyIpAddr() will return the actual calling Party IPv4 address. getCallingPartyIpAddr_v6() will return the actual calling Party IPv6 address RTP Addresses 1. An Ipv6 enabled phone calls an Ipv6 JTAPI Observed phone and the call is answered. JTAPI will generate: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address. • CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone. 2. An Ipv4 enabled phone calls an Ipv4 JTAPI Observed phone and the call is answered. JTAPI will generate(existing behavior): • CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address. • CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone. 3. An Ipv4 enabled phone calls an Ipv6 JTAPI Observed device and the call is answered. JTAPI will generate: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion. • CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1152 Message Sequence Charts RTP Addresses

Page 1216 content

Page 1217

An Ipv6 enabled phone calls an Ipv4 JTAPI Observed device and the call is answered. JTAPI will generate: • CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion. • CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone. 5. A Dual stack(Ipv4_v6) phone calls another dual stack(Ipv4_v6) JTAPI Observed device, preferred media termination is set to IPv6, and the call is answered then JTAPI will generate: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of the calling device. • CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone. 6. A Dual stack(Ipv4_v6) phone calls another dual stack(Ipv4_v6) JTAPI Observed device, preferred media termination is set to IPv4, and the call is answered then JTAPI will generate: • CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address of the calling device. • CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone. 7. A Dual stack(Ipv4_v6) phone calls an Ipv4 JTAPI Observed device and the call is answered then JTAPI will generate: • CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address of the calling device. • CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone. 8. A Dual stack(Ipv4_v6) phone calls an Ipv6 JTAPI Observed device and the call is answered then JTAPI will generate: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of the calling device. • CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone. 9. An IPv4 phone calls a dual stack (Ipv4_v6) JTAPI Observed device and the call is answered then JTAPI will generate: • CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address of the calling device. • CiscoRTPInputStartedEv containing the Ipv4 RTP address of the monitored phone. 10. An IPv6 phone calls a dual stack (Ipv4_v6) JTAPI Observed device and the call is answered then JTAPI will generate: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of the calling device. • CiscoRTPInputStartedEv containing the Ipv6 RTP address of the monitored phone. 11. JTAPI observed IPv6 phone(A) calls JTAPI observed IPv4 phone(B). B answers and consults IPv6 phone(C) for Transfer. C answers and B completes the Transfer, then JTAPI will generate: • At A: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of C. • CiscoRTPInputStartedEv containing the Ipv6 RTP address of A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1153 Message Sequence Charts Message Sequence Charts

Page 1217 content

Page 1218

• At C: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address of A. • CiscoRTPInputStartedEv containing the Ipv4 RTP address of C. 12. JTAPI observed IPv4 phone(A) calls JTAPI observed IPv4 phone(B). B answers and consults IPv6 phone(C) for Transfer. C answers and B completes the Transfer, then JTAPI will generate: • At A: • CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion. • CiscoRTPInputStartedEv containing the Ipv4 RTP address of A. • At C: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion. • CiscoRTPInputStartedEv containing the Ipv6 RTP address of C. 13. JTAPI observed IPv6 phone(A) calls JTAPI observed IPv4 phone(B). B answers and consults IPv6 phone(C) for conference. C answers and B completes the conference. Conference Bridge has an IPv4 address. Then JTAPI will generate: • At A: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion. • CiscoRTPInputStartedEv containing the Ipv6 RTP address of A. • At B: • CiscoRTPOutputStartedEv containing the far-end Ipv4 RTP address of the Conference Bridge. • CiscoRTPInputStartedEv containing the Ipv4 RTP address of B. • At C: • CiscoRTPOutputStartedEv containing the far-end Ipv6 RTP address which corresponds to the MTP that was automatically inserted by Call Manager to perform Ipv4/Ipv6 conversion. • CiscoRTPInputStartedEv containing the Ipv6 RTP address of C. CTI Port/Route Point Registration Scenarios 1. CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv4_v6’. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv6 address and Application addressing capability as IPv6. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv6 address. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1154 Message Sequence Charts CTI Port/Route Point Registration Scenarios

Page 1218 content

Page 1219

CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv4_v6’. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv4 address and Application addressing capability as IPv4. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv4 address. 3. CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv4_v6’. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv4 and IPv6 addresses and Application addressing capability as IPv4_v6. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv4 and IPv6 addresses. 4. CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv4 only’. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv4 address and Application addressing capability as IPv4. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv4 address. 5. CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv6 only’. Application tries to do a static register of that CTI Port/Route Point to CTIManager with IPv6 address and Application addressing capability as IPv6. The registration will succeed and CTI Port/Route Point will get registered with CTIManager with IPv6 address. 6. CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv4 only’. Application tries a static register of that CTI Port/Route Point by providing an IPv6 address or/and by advertising application addressing capability as IPv6 (or Ipv4_v6) only then request will fail with a CiscoRegistrationException. 7. CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv6 only’. Application tries to dynamically register that CTI Port/Route Point to CTIManager. IP capabilities advertised by the application at the time of registration are IPv4 (or IPv4_v6) only. Then the request will be denied with a CiscoRegistrationException. 8. CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv4 only (or IPv4_v6 both)’. Application tries to dynamically register that CTI Port/Route Point to CTIManager. IP capabilities advertised by the application at the time of registration are IPv4 only. Then the registration will succeed and CTI Port/Route point will get registered with IPv4 address when the same is provided with SetRTPParams request. 9. CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv6 only (or IPv4_v6 both)’. Application tries to dynamically register that CTI Port/Route Point to CTIManager. IP capabilities advertised by the application at the time of registration are IPv6 only. Then the registration will succeed and CTI Port/Route point will get registered with IPv6 address when the same is provided with SetRTPParams request. 10. CTI Port/Route Point has ‘IP Addressing Mode’ configured as ‘IPv4_v6 both’. Application tries to dynamically register that CTI Port/Route Point to CTIManager. IP capabilities advertised by the application at the time of registration are IPv4_v6 both. Then the registration will succeed and CTI Port/Route point will get registered with IPv4_v6 address when the same is provided with SetRTPParams request. 11. If an application tries to dynamically register a CTI Port/Route Point by advertising its IP capabilities as IPv6, which is already registered to another application with IPv4 address. Then the request will be declined with a CiscoRegistrationException or “CiscoTermRegistrationFailedEv” will be sent with new reason code “IP_CAPABILITY_MISMATCH”. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1155 Message Sequence Charts Message Sequence Charts

Page 1219 content

Page 1220

Advance Test Cases 1. Application does a provider Open with IPv4 address to a CTI Manager which has enterprise parameter “Enable IPv6” enabled. Application tries to register a CTI Port/Route point with an IPv6 address whose device IP Addressing Mode is set to “IPv4_v6” by advertising applications addressing capability as “IPv6 only”. The registration request will succeed. 2. JTAPI observed IPv6 device A calls another JTAPI observed IPv4 device B, call is offered and answered at B. In that case: CiscoCallCtlConnOfferedEv.getCallingPartyIpAddr() will return NULL CiscoCallCtlConnOfferedEv.getCallingPartyIpAddr_v6() will the actual calling Party IPv6 address • At B: • CiscoRTPInputStartedEv will have B’s IPv4 Address • CiscoRTPOutputStartedEv will have IPv4 address of the MTP Resource Interesting thing to notice here is CiscoRTPOutputStartedEv has an IPv4 address while calling party IP Address is an IPv6 address. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1156 Message Sequence Charts Advance Test Cases

Page 1220 content

Page 1221

Direct Transfer Across Lines Use Cases Call info/Expected Result Events Action CiscoTransferStartEv. getControllerTerminalName() returns Terminal name for B1&B2 GC1: CiscoTransferStartEv GC1: CiscoCallChangedEv GC1: ConnCreatedEv for C GC1: ConnConnectedEv for C GC1: CallCtlConnEstablishedEv for C GC1: TermConnCreatedEv for TC GC1: TermConnActiveEvent for TC GC1: CallCtlTermConnTalkingEv TC GC2: TermConnDroppedEv for TC GC2: CallCtlTermConnDroppedEv for TC GC2: ConnDisconnectedEv for C GC2: CallCtlConnDisconnectedEv for C GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B1 GC1: CallCtlConnDisconnectedEv for B1 GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEv for B2 GC2: CallCtlConnDisconnectedEv for B2 GC2: CallInvalidEvent GC2: CallObservationEndedEv GC1: CiscoTransferEndEv Application is observing A, B1, B2, and C (B1 and B2 are two Addresses on the same Terminal TB) A calls B1, B1 answers – GC1 B2 calls C, C answers – GC2 setTransferController to B1 GC1.transfer(GC2) CiscoTransferStartEv. getControllerTerminalName() returns Terminal name for B1&B2 Application is observing A, B1, B2, and C (B1 and B2 are two Addresses on the same Terminal which allows connected transfer across lines over phone manually which supports this feature) A calls B1, B1 answers – GC1 B2 calls C, C answers – GC2 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1157 Message Sequence Charts Direct Transfer Across Lines Use Cases

Page 1221 diagram

Page 1222

Call info/Expected Result Events Action GC2: CallCtlTermConnHeldEv for TB GC3: CiscoConsultCallActiveEv GC3: ConnCreatedEv for B2 GC3: ConnConnectedEv for B2 GC3: CallCtlConnInitiatedEv for B2 GC3: TermConnCreatedEv for TB2 GC3: TermConnActiveEvent for TB2 GC3: CallCtlTermConnTalkingEv for TB2 User B2 presses transfer and user selects active call(A–> B call) from the phone UI and presses transfer again to do connected Transfer Across Lines Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1158 Message Sequence Charts Message Sequence Charts

Page 1222 diagram

Page 1223

Call info/Expected Result Events Action GC3: TermConnDroppedEv for TB2 GC3: CallCtlTermConnDroppedEv for TB2 GC3: ConnDisconnectedEv for B2 GC3: CallCtlConnDisconnectedEv for B2 GC3: CallInvalidEvent GC3: CallObservationEndedEv GC2: CiscoTransferStartEv GC1: CiscoCallChangedEv GC2: ConnCreatedEv for A GC2: ConnConnectedEv for A GC2: CallCtlConnEstablishedEv for A GC2: TermConnCreatedEv for TA GC2: TermConnActiveEvent for TA GC2: CallCtlTermConnTalkingEv for TA GC1: TermConnDroppedEv for TA GC1: CallCtlTermConnDroppedEv for TA GC1: ConnDisconnectedEv for A GC1: CallCtlConnDisconnectedEv for A GC2: TermConnDroppedEv for TB2 GC2: CallCtlTermConnDroppedEv for TB2 GC2: ConnDisconnectedEv for B2 GC2: CallCtlConnDisconnectedEv for B2 GC1: TermConnDroppedEv for TB1 GC1: CallCtlTermConnDroppedEv for TB1 GC1: ConnDisconnectedEv for B1 GC1: CallCtlConnDisconnectedEv for B1 GC1: CallInvalidEvent GC1: CallObservationEndedEv GC2: CiscoTransferEndEv User Presses transfer again to complete connected transfer across lines Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1159 Message Sequence Charts Message Sequence Charts

Page 1223 diagram

Page 1224

Call info/Expected Result Events Action CiscoTransferStartEv. getControllerTerminalName() returns Terminal name for B1&B2 GC1: CiscoTransferStartEv GC1: CiscoCallChangedEv GC1: ConnCreatedEv for C GC1: ConnConnectedEv for C GC1: CallCtlConnEstablishedEv for C GC2: ConnDisconnectedEv for C GC2: CallCtlConnDisconnectedEv for C GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B1 GC1: CallCtlConnDisconnectedEv for B1 GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEv for B2 GC2: CallCtlConnDisconnectedEv for B2 GC2: CallInvalidEvent GC2: CallObservationEndedEv GC1: CiscoTransferEndEv Application is observing A, B1, B2: A calls B1, B1 answers – GC1 B2 calls C, C answers - GC2 setTransferController to B1 GC1.transfer(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1160 Message Sequence Charts Message Sequence Charts

Page 1224 diagram

Page 1225

Call info/Expected Result Events Action CiscoTransferStartEv. getControllerTerminalName() returns Terminal name for B1&B2 GC1: CiscoTransferStartEv GC1: ConnDisconnectedEv for A GC1: CallCtlConnDisconnectedEv for A GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B1 GC1: CallCtlConnDisconnectedEv for B1 GC1: CallInvalidEv GC2: ConnDisconnectedEv for C GC2: CallCtlConnDisconnectedEv for C GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEv for B2 GC2: CallCtlConnDisconnectedEv for B2 GC2: CallInvalidEvent GC1: CiscoTransferEndEvGC1: CallObservationEndedEv Application is observing B1, B2: A calls B1, B1 answers – GC1 B2 calls C, C answers - GC2 setTransferController to B1 GC1.transfer(GC2) JTAPI will throw PlatformException “Transfer controller is not set and could not find a suitable TerminalConnection”. Since JTAPI cannot get/find call leg for B2 from GC2 Application is observing only B1: A calls B1, B1 answers – GC1 B2 calls C, C answers - GC2 setTransferController to B1 GC1.transfer(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1161 Message Sequence Charts Message Sequence Charts

Page 1225 diagram

Page 1226

Call info/Expected Result Events Action CiscoTransferStartEv. getControllerTerminalName() returns Terminal name for B1&B2 GC2: CallActiveEvent GC2: ConnCreatedEv for A GC2: ConnCreatedEv for C GC1: CiscoCallChangedEv GC2: ConnConnectedEv for A GC2: CallCtlConnEstablishedEv for A GC2: TermConnCreatedEv for A GC2: TermConnActiveEvent for A GC2: CallCtlTermConnTalkingEv for A GC2: ConnConnectedEv for C GC2: CallCtlConnEstablishedEv for C GC1: ConnDisconnectedEv for B1 GC1: CallCtlConnDisconnectedEv for B1 GC1: TermConnDroppedEv for A GC1: CallCtlTermConnDroppedEv for A GC1: ConnDisconnectedEv for A GC1: CallCtlConnDisconnectedEv for A GC1: CallInvalidEvent GC1: CallObservationEndedEv Application is observing only A: A calls B1, B1 answers – GC1 B2 calls C, C answers - GC2 User presses transfer and selects active call(A –> B call) from the phone UI and presses Transfer again to do Connected Transfer Across Lines JTAPI will throw PlatformException “Transfer controller is not set and could not find a suitable TerminalConnection” Since JTAPI cannot get/find call leg for B1 from GC1 Application is observing only B2: A calls B1, B1 answers – GC1 B2 calls C, C answers - GC2 setTransferController to B1 GC1.transfer(GC2) CiscoTransferStartEv. getControllerTerminalName() returns Terminal name for B1&B2 GC2: CiscoTransferStartEv GC2: ConnDisconnectedEv for B2 GC2: CallCtlConnDisconnectedEv for B2 GC2: ConnCreatedEv for A GC2: ConnConnectedEv for A GC2: CallCtlConnEstablishedEv for AGC2: CiscoTransferEndEv Application is observing only C: A calls B1, B1 answers – GC1 B2 calls C, C answers - GC2 User presses transfer and selects active call(A–>B call) from the phone UI and preses Transfer again to do Connected Transfer Across Lines. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1162 Message Sequence Charts Message Sequence Charts

Page 1226 diagram

Page 1227

Call info/Expected Result Events Action CiscoProviderCapabilityChangedEv. hasConnectedTransfer ConferenceCapabilityChanged() returns True JTAPI delivers: ProvInServiceEv CiscoProviderCapabilityChangedEv CiscoTermRestrictedEv CiscoAddrRestrictedEv (for all the phones that support connected tx/conf across lines) New user role(Standard Supports Connected Xfer/Conf) is associated with application user Application opens a provider and disassociates the above mentioned user role Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1163 Message Sequence Charts Message Sequence Charts

Page 1227 diagram

Page 1228

Call info/Expected Result Events Action CiscoTransferStartEv. getControllerTerminalName() returns Terminal name for B1&B2 At Transfer: GC1: CiscoTransferStartEvGC2: CiscoCallChangedEv GC1: ConnCreatedEv for C GC1: ConnConnectedEv for C GC1: CallCtlConnEstablishedEv for C GC1: TermConnCreatedEv for TC' GC1: TermConnPassiveEvent for TC' GC1: CallCtlTermConnInUseEv for TC' GC2: TermConnDroppedEv for TC' GC2: CallCtlTermConnDroppedEv for TC' GC2: CiscoCallChangedEv GC1: TermConnCreatedEv for TC GC1: TermConnActiveEvent for TC GC1: CallCtlTermConnTalkingEv for TC GC2: TermConnDroppedEv for TC GC2: CallCtlTermConnDroppedEv for TC GC2: ConnDisconnectedEv for C GC2: CallCtlConnDisconnectedEv for C GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B1 GC1: CallCtlConnDisconnectedEv for B1 GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEv for B2 GC2: CallCtlConnDisconnectedEv for B2 GC2: CallInvalidEvent GC2: CallObservationEndedEv GC1: CiscoTransferEndEv Application is observing A, B1, B2, C and C’ (B1 and B2 are two Addresses on the same Terminal, C’ is sharedline of C) A calls B1, B1 answers – GC1 B2 calls C, C answers – GC2 setTransferController to B1 GC1.transfer(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1164 Message Sequence Charts Message Sequence Charts

Page 1228 diagram

Page 1229

Call info/Expected Result Events Action CiscoTerminal.isRestricted() returns TRUE Phones that allow connected transfer/conference across lines are exposed as restricted. JTAPI throws PlatformExceptionImpl ("Terminal is restricted", CiscoJtapiException.CTIERR_DEVICE_RESTRICTED ). New user role(Standard Supports Connected Xfer/Conf) is not associated with application user Application tries to add observer on phone which allows connected transfer/conference across lines CiscoProviderCapabilityChangedEv. hasConnectedTransferConference CapabilityChanged() returns True JTAPI delivers: ProvInServiceEv CiscoProviderCapabilityChangedEv CiscoAddrActivatedEv CiscoTermActivatedEv (for all the phones that support connected tx/conf across lines) New user role(Standard Supports Connected Xfer/Conf) is not associated with application user Application opens a provider and associates the above mentioned user role ConnectedConferenceorJoinAcrossLinesUseCases-NewPhonesBehavior Call info/Expected result Events Action New Role “Standard Supports Connected Xfer/Conf” to control phones which support connected conference across lines is Not Associated with user.Phones TA(Line A), TB(Lines B1, B2) and T3(Lines C); TC is a phones which allows connected conference across lines. Observe All; GC1: A calls B1, GC2: B2 calls C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1165 Message Sequence Charts Connected Conference or Join Across Lines Use Cases - New Phones Behavior

Page 1229 diagram

Page 1230

Call info/Expected result Events Action CiscoConferenceStartEv.getControllerAddress() returns B1CiscoConferenceStartEv.getControllerTerminalName() returns TB App, gets an PlatformExceptionImpl ("Terminal is restricted", CiscoJtapiException.CTIERR_DEVICE_RESTRICTED ) when the add observer on TB, B1 and B2 GC2: CallCtlTermConnHeldEv for TB GC3: CiscoConsultCallActiveEv GC3: ConnCreatedEv for B GC3: ConnConnectedEv for B GC3: CallCtlConnInitiatedEv for B GC3: ConnDisconnectedEv for B GC3: CallCtlConnDisconnectedEv for B GC3: CallInvalidEvent GC3: CallObservationEndedEv GC2: CiscoConferenceStartEv GC1: CiscoCallChangedEv GC2: ConnCreatedEv for A GC2: ConnConnectedEv for A GC2: CallCtlConnEstablishedEv for A GC2: TermConnCreatedEv for TA GC2: TermConnActiveEvent for TA GC2: CallCtlTermConnTalkingEv for TA GC1: TermConnDroppedEv for TA GC1: CallCtlTermConnDroppedEv for TA GC1: ConnDisconnectedEv for A GC1: CallCtlConnDisconnectedEv for A GC1: ConnDisconnectedEv for B GC1: CallCtlConnDisconnectedEv for B GC1: CallInvalidEvent GC1: CallObservationEndedEv GC2: CiscoConferenceEndEv Do connected Conference Across Lines manually on Phone TB (which supports this feature) to conference GC1 and GC2 Enhanced MWI Use Cases Result Action Phone displays updated voice and fax counts provided and also updates the MWI indicator accordingly. A successful response is returned. Application calls CiscoAddress.setMessageSummary() to set voice and fax counts on a phone that supports the enhanced message waiting counts. Phone only updates the MWI indicator accordingly—no voice and fax counts are displayed on the phone. A successful response is returned Application calls CiscoAddress.setMessageSummary() to set voice and fax counts on a phone that does not support the enhanced message waiting counts. The request fails with the following error returned: INVALID_HIGH_PRIORITY_VOICE_COUNTS Application calls CiscoAddress.setMessageSummary() to set voice counts, but the “high priority” voice counts provided are bigger than “total” voice counts provided. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1166 Message Sequence Charts Enhanced MWI Use Cases

Page 1230 diagram

Page 1231

Result Action The request fails with the following error returned: INVALID_TOTAL_FAX_COUNTS Application calls CiscoAddress.setMessageSummary() to set fax counts, but the “total” fax counts provided is bigger than maximum size allowed. Join Across Lines Enhancements A, C, D, E and F are addresses on different terminals. B1 and B2 are addresses on the same terminal TermB. A, B1 and C are in a conference call GC1 with B1 as the controller and connected to conference bridge Conference-1. B2, D and E are in conference call GC2 with D as controller and connected to bridge Conference-2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1167 Message Sequence Charts Join Across Lines Enhancements

Page 1231 diagram

Page 1232

Events Action Events to CallObserver of A, C and B1: TermConnActiveEv TermB GC1 CallCtlTermConnTalkingEv TermB GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-2 GC1 ConnConnectedEv Conference-2 GC1 CallCtlConnEstablishedEv Conference-2 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv GC1 Ev.getAddedConnection will return connection for Conference-2 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2Ev.getConferenceChain().getChainedConferenceCalls() will returnGC1 Event for CallObserver at B2, D & E: ConnDisconnectedEv B2 GC2 Cause = NORMAL CallCtlConnDisconnectedEv B2 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE TermConnDroppedEv TermB GC2 Cause = NORMAL CallCtlTermConnDroppedEv TermB GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-1 GC2 ConnConnectedEv Conference-1 GC2 CallCtlConnEstablishedEv Conference-1 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC2 Ev.getAddedConnection will return connection of Conference-1 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1 & Conference-2 Ev.getConferenceChain().getChainedConferenceCalls() will return GC1 & GC2 Application conferences the two calls on B1 and B2 by invoking GC1.conference(GC2) to chain two conference call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1168 Message Sequence Charts Message Sequence Charts

Page 1232 diagram

Page 1233

Events Action Event for CallObserver at B2, D & E: TermConnActiveEv TermB GC2 CallCtlTermConnTalkingEv TermB GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-1 GC2 ConnConnectedEv Conference-1 GC2 CallCtlConnEstablishedEv Conference-1 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC2 Ev.getAddedConnection will return connection for Conference-1 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1 Ev.getConferenceChain().getChainedConferenceCalls() will return GC2 Events for CallObservers at A, B1 & C: ConnDisconnectedEv B1 GC1 Cause = NORMAL CallCtlConnDisconnectedEv B1 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE TermConnDroppedEv TermB GC1 Cause = NORMAL CallCtlTermConnDroppedEv TermB GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-2 GC1 ConnConnectedEv Conference-2 GC1 CallCtlConnEstablishedEv Conference-2 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC1 Ev.getAddedConnection will return connection for Conference-2 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2 Ev.getConferenceChain().getChainedConferenceCalls() will returnGC1 Application invokes GC2.conference(GC1) to chain two conference calls. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1169 Message Sequence Charts Message Sequence Charts

Page 1233 diagram

Page 1234

Events Action A, B1, C are in conference-1 (GC1), B1, D, E are in conference-2 ( GC2), B2, F, G are in conference-3 (GC-3) Application completes conference at C by initiating GC1.conference(GC2, GC3) setting B1 as controller. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1170 Message Sequence Charts Message Sequence Charts

Page 1234 diagram

Page 1235

Events Action Event for CallObserver at A, B1 & C: TermConnActiveEv TermB GC1 CallCtlTermConnTalkingEv TermB GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-2 GC1 ConnConnectedEv Conference-2 GC1 CallCtlConnEstablishedEv Conference-2 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC1 Ev.getAddedConnection will return connection for Conference-2 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2 Ev.getConferenceChain().getChainedConferenceCalls() will return GC1 TermConnDroppedEv TermB GC2 CallCtlTermConnDroppedEvTermB GC2 ConnCreatedEv Conference-3 GC1 ConnConnectedEv Conference-3 GC1 CallCtlConnEstablishedEv Conference-3 GC1 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC1 Ev.getAddedConnection will return connection for Conference-3 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-2 & Conference-3 Ev.getConferenceChain().getChainedConferenceCalls() will return GC2 & GC3 Event for CallObserver at B1, D & E: ConnDisconnectedEv B1 GC2 Cause = NORMAL CallCtlConnDisconnectedEv B1 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE TermConnDroppedEv TermB GC2 Cause = NORMAL CallCtlTermConnDroppedEv TermB GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-1 GC2 ConnConnectedEv Conference-1 GC2 CallCtlConnEstablishedEv Conference-1 GC2 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC2 Ev.getAddedConnection will return connection for Conference-1 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1-GC2 Ev.getConferenceChain().getChainedConferenceCalls() will returnGC2 Event for CallObserver at B2, F & G: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1171 Message Sequence Charts Message Sequence Charts

Page 1235 diagram

Page 1236

Events Action ConnDisconnectedEv B2 GC3 Cause = NORMAL CallCtlConnDisconnectedEv B2 GC3 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE TermConnDroppedEv TermB GC3 Cause = NORMAL CallCtlTermConnDroppedEv TermB GC3 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE ConnCreatedEv Conference-1 GC3 ConnConnectedEv Conference-1 GC3 CallCtlConnEstablishedEv Conference-1 GC3 Cause = NORMAL, callCtlCause = CAUSE_CONFERENCE CiscoConferenceChainAddedEv – GC3 Ev.getAddedConnection will return connection for Conference-1 Ev.getConferenceChain().getChainedConferenceConnections() will return connections of Conference-1 Ev.getConferenceChain().getChainedConferenceCalls() will return GC3 Call Scenario: A, B1 and C are in conference call GC1 with B1 as controller. B2 is in call GC2 with D Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1172 Message Sequence Charts Message Sequence Charts

Page 1236 diagram

Page 1237

Events Action A CiscoConferenceStartEv CallCtlTermConnTalkingEvTermB GC1 ConnCreatedEv D GC1 ConnConnectedEv D GC1 CallCtlTermConnDroppedEv TermB GC2 CiscoConferenceEndEv B1 CallCtlTermConnHeldEv TermB GC1 CiscoConferenceStartEv CallCtlTermConnTalkingEv TermB GC1 ConnCreatedEv D ConnConnectedEv CiscoConferenceEndEv B2 ConnDisconnectedEv B GC2 CallCtlTermConnHeldEv TermB GC2 D CallActiveEv GC2 ConnAlertingEv D GC2 ConnConnectedEv D GC2 CiscoConferenceStartEv TermConnDroppedEv TermB GC2 CallActiveEv GC1 CiscoCallChangedEv TermConnTalkingEv TermB GC1 TermConnDroppedEv TermD GC2 CallObservationEndedEv GC2 CiscoConferenceEndEv Application sets the requestor as B2 and calls GC2.conference(GC1) getControllerAddress() returns B2. getOriginalControllerAddress() returns B1. Events are same as above If application uses B1 as request controller in the above setup getControllerAddress() returns B1. getOriginalControllerAddress() returns B1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1173 Message Sequence Charts Message Sequence Charts

Page 1237 diagram

Page 1238

Swap or Cancel and Transfer or Conference Behavior Change Use Case 1 GC1 & GC2 call will be created as normal. Connected Transfer on the phone which allows connected Transfer GC1: CallCtlTermConnHeldEv for TB A calls B, B answers – GC1 B puts A–>B call on hold B calls C, C answers – GC2 GC2: CallCtlTermConnHeldEv for TB GC3: CiscoConsultCallActiveEv GC3: ConnCreatedEv for B GC3: ConnConnectedEv for B GC3: CallCtlConnInitiatedEv for B GC3: TermConnCreatedEv for TB GC3: TermConnActiveEvent for TB GC3: CallCtlTermConnTalkingEv for TB User B presses transfer and user selects active call(A–>B call) from the phone UI GC3: TermConnDroppedEv for TB GC3: CallCtlTermConnDroppedEv for TB GC3: ConnDisconnectedEv for B GC3: CallCtlConnDisconnectedEv for B GC3: CallInvalidEvent GC3: CallObservationEndedEv GC2: CiscoTransferStartEv GC1: CiscoCallChangedEv GC2: ConnCreatedEv for A GC2: ConnConnectedEv for A GC2: CallCtlConnEstablishedEv for A GC2: TermConnCreatedEv for TA GC2: TermConnActiveEvent for TA GC2: CallCtlTermConnTalkingEv for TA GC1: TermConnDroppedEv for TA GC1: CallCtlTermConnDroppedEv for TA GC1: ConnDisconnectedEv for A GC1: CallCtlConnDisconnectedEv for A GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEv for B GC2: CallCtlConnDisconnectedEv for B GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B GC1: CallCtlConnDisconnectedEv for B GC1: CallInvalidEvent GC1: CallObservationEndedEv GC2: CiscoTransferEndEv User B presses transfer again Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1174 Message Sequence Charts Swap or Cancel and Transfer or Conference Behavior Change

Page 1238 diagram

Page 1239

Use case 2 GC1 & GC2 call will be created as normal. GC1: CallCtlTermConnHeldEv for TB GC2: CallCtlTermConnHeldEv for TB GC3: CiscoConsultCallActiveEv GC3: ConnCreatedEv for B GC3: ConnConnectedEv for B GC3: CallCtlConnInitiatedEv for B GC3: TermConnCreatedEv for TB GC3: TermConnActiveEvent for TB GC3: CallCtlTermConnTalkingEv for TB| GC3: TermConnDroppedEv for TB GC3: CallCtlTermConnDroppedEv for TB GC3: ConnDisconnectedEv for B GC3: CallCtlConnDisconnectedEv for B GC3: CallInvalidEv GC2: CiscoTransferStartEv GC1: CiscoCallChangedEv GC2: ConnCreatedEv for A GC2: ConnConnectedEv for A GC2: CallCtlConnEstablishedEv for A GC2: TermConnCreatedEv for TA' GC2: TermConnPassiveEvent for TA' GC2: CallCtlTermConnInUseEv for TA' GC1: TermConnDroppedEv for TA' GC1: CallCtlTermConnDroppedEv for TA' GC2: TermConnCreatedEv for TA GC2: TermConnActiveEvent for TA GC2: CallCtlTermConnTalkingEv for TA GC1: TermConnDroppedEv for TA GC1: CallCtlTermConnDroppedEv for TA GC1: ConnDisconnectedEv for A GC1: CallCtlConnDisconnectedEv for A GC2:TermConnDroppedEv for TB2 GC2: CallCtlTermConnDroppedEv for TB2 GC2: ConnDisconnectedEv for B2 GC2: CallCtlConnDisconnectedEv for B2 GC1: TermConnDroppedEv for TB1 GC1: CallCtlTermConnDroppedEv for TB1 GC1: ConnDisconnectedEv for B1 GC1: CallCtlConnDisconnectedEv for B1 GC1: CallInvalidEvent GC1: CallObservationEndedEv GC2: CiscoTransferEndEv Connected Transfer on phone with sharedline (A and A’ are sharedlines) A calls B, B answers – GC1 B puts A–>B call on hold B calls C, C answers – GC2 User B presses transfer and selects active calls (A–>B call), User B presses transfer again Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1175 Message Sequence Charts Message Sequence Charts

Page 1239 diagram

Page 1240

Use case 3 CiscoCallFeatureCancelled Ev.getConsultCall() returns GC3 GC1 & GC2 call will be created as normal. GC1: CallCtlTermConnHeldEv for TB GC2: CallCtlTermConnHeldEv for TB GC3: CiscoConsultCallActiveEv GC3: ConnCreatedEv for B GC3: ConnConnectedEv for B GC3: CallCtlConnInitiatedEv for B GC3: TermConnCreatedEv for TB GC3: TermConnActiveEvent for TB GC3: CallCtlTermConnTalkingEv for TB GC3: TermConnDroppedEv for TB GC3: CallCtlTermConnDroppedEv for TB GC3: ConnDisconnectedEv for B GC3: CallCtlConnDisconnectedEv for B GC3: CallInvalidEv GC2: CiscoCallFeatureCancelledEv Connected Transfer/Conference – Cancel feature A calls B, B answers – GC1 B puts A–>B call on hold B calls C, C answers – GC2 User B presses transfer hard key User B presses cancel key Use case 4a CiscoCallFeatureCancelled Ev.getConsultCall() returns null GC1 & GC2 call will be created as normal. GC1: CallCtlTermConnHeldEv for TB GC2: CallCtlTermConnHeldEv for TB GC3: CiscoConsultCallActiveEv GC3: ConnCreatedEv for B GC3: ConnConnectedEv for B GC3: CallCtlConnInitiatedEv for B GC3: TermConnCreatedEv for TB GC3: TermConnActiveEvent for TB GC3: CallCtlTermConnTalkingEv for TB GC3: TermConnDroppedEv for TB GC3: CallCtlTermConnDroppedEv for TB GC3: ConnDisconnectedEv for B GC3: CallCtlConnDisconnectedEv for B GC3: CallInvalidEv GC2: CiscoCallFeatureCancelledEv Connected Transfer/Conference – Cancel feature A calls B, B answers – GC1 B puts A–>B call on hold B calls C, C answers – GC2 User B presses transfer hard key User press select active calls key. User B presses cancel key Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1176 Message Sequence Charts Message Sequence Charts

Page 1240 diagram

Page 1241

Use case 4b CiscoCallFeatureCancelled Ev.getConsultCall() returns GC1 GC1 & GC2 call will be created as normal. GC1: CallCtlTermConnHeldEv for TB GC2: CallCtlTermConnHeldEv for TB GC3: CiscoConsultCallActiveEv GC3: ConnCreatedEv for B GC3: ConnConnectedEv for B GC3: CallCtlConnInitiatedEv for B GC3: TermConnCreatedEv for TB GC3: TermConnActiveEvent for TB GC3: CallCtlTermConnTalkingEv for TB GC3: TermConnDroppedEv for TB GC3: CallCtlTermConnDroppedEv for TB GC3: ConnDisconnectedEv for B GC3: CallCtlConnDisconnectedEv for B GC3: CallInvalidEv GC2: CiscoCallFeatureCancelledEv Connected Transfer/Conference – Cancel feature A calls B, B answers – GC1 B puts A–>B call on hold B calls C, C answers – GC2 User B presses transfer (or conference) hard key. User press select active calls key and also selects GC1 (A‡B call) User B presses cancel key Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1177 Message Sequence Charts Message Sequence Charts

Page 1241 diagram

Page 1242

Use case 5 getCiscoFeatureReason() returns CiscoFeatureReason. REASON_NORMAL GC1 & GC2 call will be created as normal. GC1: CallCtlTermConnHeldEv for TB GC2: CallCtlTermConnHeldEv for TB GC1: CallCtlTermConnTalkingEv for TB GC1: CiscoTransferStartEv GC1: CiscoCallChangedEv GC1: ConnCreatedEv for C GC1: ConnConnectedEv for C GC1: CallCtlConnEstablishedEv for C GC1: TermConnCreatedEv for TC GC1: TermConnActiveEvent for TC GC1: CallCtlTermConnTalkingEv TC GC2: TermConnDroppedEv for TC GC2: CallCtlTermConnDroppedEv for TC GC2: ConnDisconnectedEv for C GC2: CallCtlConnDisconnectedEv for C GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B1 GC1: CallCtlConnDisconnectedEv for B1 GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEv for B2 GC2: CallCtlConnDisconnectedEv for B2 GC2: CallInvalidEvent GC2: CallObservationEndedEv GC1: CiscoTransferEndEv Consult Transfer – Swap calls A calls B, B answers – GC1 B puts A–>B call on hold B setup consult Transfer to C, C answers – GC2 User B presses Swap key, User B presses transfer to complete the transfer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1178 Message Sequence Charts Message Sequence Charts

Page 1242 diagram

Page 1243

Use case 6 getCiscoFeatureReason() returns CiscoFeatureReason. REASON_NORMAL CiscoCallFeatureCancelledEv.getCall() returns GC1 CiscoCallFeatureCancelledEv.getConsultCall() returns GC2 GC1 & GC2 call will be created as normal. GC1: CallCtlTermConnHeldEv for TB For TA (GC2), CallCtlTermConnHeldEv For TA (GC1), CallCtlTermConnTalkingEv GC1: CiscoCallFeatureCancelledEv Consult Transfer – Swap/Cancel A calls B, B answers – GC1 A puts A–>B call on hold B setup consult Transfer to C, C answers – GC2 User B presses press Swap softkey, User B presses Cancel softkey Use case 7 GC1 & GC2 call will be created as normal. Request will fail with PlatformException “CTIERR_CONSULTCALL_ALREADY_OUTSTANDING” Consultative Transfer Initiated from Phone, App sends SetupTransfer/Conference request – request fails A calls B, B answers – GC1 B setups transfer call to C B calls C, C answers – GC2 Application creates a new call and sends another consult() request Use case 8a getCiscoFeatureReason() returns CiscoFeatureReason.REASON_NORMAL CiscoCallFeatureCancelledEv.getCall() returns GC1 CiscoCallFeatureCancelledEv.getConsultCall() returns GC2 GC1 and GC2 will be created as normal For TB (GC2), CallCtlTermConnHeldEv For TB (GC1), CallCtlTermConnTalkingEv CiscoCallFeatureCancelledEv Consult call will go through and GC3 will be created as normal Consult Transfer/Conference – Application Resumes primary call on phone which supports connected transfer/conference and sends another consult setup request GC1: A calls B GC2: B consults C Application resumes GC1 on TB Application creates another call and sends consult() request to call D; D answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1179 Message Sequence Charts Message Sequence Charts

Page 1243 diagram

Page 1244

Use case 8b CiscoCallFeatureCancelledEv.getCall() returns GC1 CiscoCallFeatureCancelledEv.getConsultCall() returns GC2 GC1 and GC2 will be created as normal On Manual Resume or Swap, Consult Call will not be cancelled on the phone, nor will application get CiscoCallFeatureCancelledEv. When application tries to setup another consult, it will go through (GC3 will be created as normal) and it will cancel the existing consult call and application will get: CiscoCallFeatureCancelledEv Consult Transfer/Conference – Manually Resume primary call on phone which supports connected transfer/conference and then sends another consult setup request GC1: A calls B GC2: B consults C User manually resumes (SWAP) GC1 on B Application creates another call and sends consult() request to call D; D answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1180 Message Sequence Charts Message Sequence Charts

Page 1244 diagram

Page 1245

Use case 9 GC1 & GC2 call will be created as normal. C1: CallCtlTermConnHeldEv for TB GC2: CallCtlTermConnHeldEv for TB GC3: CiscoConsultCallActiveEv GC3: ConnCreatedEv for B GC3: ConnConnectedEv for B GC3: CallCtlConnInitiatedEv for B GC3: TermConnCreatedEv for TB GC3: TermConnActiveEvent for TB GC3: CallCtlTermConnTalkingEv for TB GC3: TermConnDroppedEv for TB GC3: CallCtlTermConnDroppedEv for TB GC3: ConnDisconnectedEv for B GC3: CallCtlConnDisconnectedEv for B GC3: CallInvalidEvent GC3: CallObservationEndedEv GC2: CiscoConferenceStartEv GC1: CiscoCallChangedEv GC2: ConnCreatedEv for A GC2: ConnConnectedEv for A GC2: CallCtlConnEstablishedEv for A GC2: TermConnCreatedEv for TA GC2: TermConnActiveEvent for TA GC2: CallCtlTermConnTalkingEv for TA GC1: TermConnDroppedEv for TA GC1: CallCtlTermConnDroppedEv for TA GC1: ConnDisconnectedEv for A GC1: CallCtlConnDisconnectedEv for A GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B GC1: CallCtlConnDisconnectedEv for B GC1: CallInvalidEvent GC1: CallObservationEndedEv GC2: CiscoConferenceEndEv Connected ConferenceA (Phone which allows connected conference) calls B, B answer, B puts A onhold, B calls C, C answer B press “Conference” hardkey, and picks active call from UI, and selects A‡B call B press “Conference” again to complete connected conference Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1181 Message Sequence Charts Message Sequence Charts

Page 1245 diagram

Page 1246

Use case 10 getCiscoFeatureReason() returns CiscoFeatureReason. REASON_NORMAL GC1 & GC2 call will be created as normal. GC2: CallCtlTermConnHeldEv for TB GC1: CallCtlTermConnTalkingEv for TB GC2: CiscoConferenceStartEv GC1: CiscoCallChangedEv GC2: ConnCreatedEv for A GC2: ConnConnectedEv for A GC2: CallCtlConnEstablishedEv for A GC2: TermConnCreatedEv for TA GC2: TermConnActiveEvent for TA GC2: CallCtlTermConnTalkingEv for TA GC1: TermConnDroppedEv for TA GC1: CallCtlTermConnDroppedEv for TA GC1: ConnDisconnectedEv for A GC1: CallCtlConnDisconnectedEv for A GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEv for B GC1: CallCtlConnDisconnectedEv for B GC1: CallInvalidEvent GC1: CallObservationEndedEv GC2: CiscoTransferEndEv Consult Conference from Phone, then Swap and complete conference through phone A calls B, B answerB setup conference to C, C answer B press “Swap” softkey A press “Conference” Use case 11 getCiscoFeatureReason() returns CiscoFeatureReason. REASON_NORMAL CiscoCallFeatureCancelled Ev.getCall() returns GC1 CiscoCallFeatureCancelled Ev.getConsultCall() returns GC2 GC1 & GC2 call will be created as normal. GC1: CallCtlTermConnTalkingEv for TB GC2: CallCtlTermConnHeldEv for TB GC1: CiscoCallFeatureCancelledEv(consultCall = GC2) Consult Conference from Phone and then Swap and Cancel conference thru phone A calls B, B answer B setup conference to C, C answer A press “Swap” key, and picks active call from UI, and selects A–>B call B press “Cancel” Use case 12 Same as JAL scenario but we will have a temporary call GC3 Connected Conference Across Lines Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1182 Message Sequence Charts Message Sequence Charts

Page 1246 diagram

Page 1247

Use case 13 At Transfer: GC1: CiscoTransferStartEv GC1: CiscoCallChangedEv GC1: ConnCreatedEvent for C GC1: ConnConnectedEvent for C GC1: CallCtlConnEstablishedEv for C GC1: TermConnCreatedEvent for TC GC1: TermConnActiveEvent for TC GC1: CallCtlTermConnTalkingEv TC GC2: TermConnDroppedEv for TC GC2: CallCtlTermConnDroppedEv for TC GC2: ConnDisconnectedEvent for C GC2: CallCtlConnDisconnectedEv for C GC1: CiscoCallFeatureCancelledEv GC1: TermConnDroppedEv for TB GC1: CallCtlTermConnDroppedEv for TB GC1: ConnDisconnectedEvent for B1 GC1: CallCtlConnDisconnectedEv for B1 GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEvent for B2 GC2: CallCtlConnDisconnectedEv for B2 GC2: CallInvalidEvent GC1: CiscoTransferEndEv Manual Consult followed by transfer complete by application GC1: A calls B1 GC2: B1 setups consult call to C manually over phone G1.transfer(GC2) Use case 14 At Conference: GC1: CiscoCallFeatureCancelledEv GC1: CiscoConferenceStartEv GC1: CiscoCallFeatureCancelledEv GC1: CiscoCallChangedEv GC1: ConnCreatedEvent for C GC1: ConnConnectedEvent for C GC1: CallCtlConnEstablishedEv for C GC1: TermConnCreatedEvent for TC GC1: TermConnActiveEvent for TC GC1: CallCtlTermConnTalkingEv TC GC2: TermConnDroppedEv for TC GC2: CallCtlTermConnDroppedEv for TC GC2: ConnDisconnectedEvent for C GC2: CallCtlConnDisconnectedEv for C GC2: TermConnDroppedEv for TB GC2: CallCtlTermConnDroppedEv for TB GC2: ConnDisconnectedEvent for B2 GC2: CallCtlConnDisconnectedEv for B2 GC2: CallInvalidEvent GC1: CiscoConferenceEndEv Manual consult followed by conference complete by application GC1: A calls B1 GC2: B1 setups consult call to C manually over phone G1.conference(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1183 Message Sequence Charts Message Sequence Charts

Page 1247 diagram

Page 1248

Drop Any Party Use Cases • JTAPI INI parameter is enabled to allow dropAnyPartyFeature. • Cisco Unified Communications Manager service parameter “Advanced Ad Hoc Conference Enable” is set to FALSE. • Cisco Unified Communications Manager service parameter “Drop Ad Hoc Conference” set “never” CallInfo Result Action Scenario N.A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL InvalidStateException is thrown. InvalidStateException is thrown. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C CallInvalidEv A is dropped out of conference. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect() on Connection of C. Application invokes Connection.disconnect() on Connection of A. Use Case 1 Application is observing A, B is conference controller. A, B, and C are in conference. N.A Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL InvalidStateException is thrown. InvalidStateException is thrown. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv C is dropped out of conference. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C. Use Case 2 Application is observing C, B is conference controller. A, B, and C are in conference. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1184 Message Sequence Charts Drop Any Party Use Cases

Page 1248 diagram

Page 1249

CallInfo Result Action Scenario N.A Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL InvalidStateException is thrown. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C C is dropped out of conference. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C. Use Case3 Application is observing A and C. B is conference controller. A, B, and C are in conference. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A is dropped out of conference. ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C C is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C CallInvalidEv And B is dropped out of conference. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C Application invokes Connection.disconnect() on Connection of B. Use Case 4 Application is observing B, and B is conference controller. A, B, and C are in conference. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1185 Message Sequence Charts Message Sequence Charts

Page 1249 diagram

Page 1250

CallInfo Result Action Scenario Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C C is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C Application invokes Connection.disconnect() on Connection of B. Use Case 5 Application is observing A, B and C, and B is conference controller. A, B, and C are in conference. • JTAPI INI parameter is enabled to allow dropAnyPartyFeature. • Cisco Unified Communications Manager service parameter “Advanced Ad Hoc Conference Enable” is set to TRUE. • Cisco Unified Communications Manager service parameter “Drop Ad Hoc Conference” set “never” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1186 Message Sequence Charts Message Sequence Charts

Page 1250 diagram

Page 1251

CallInfo Result Action Scenario Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C C is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C CallInvalidEv A is dropped out of conference. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect() on Connection of C. Application invokes Connection.disconnect() on Connection of A. Use Case 6 Application is observing A, B is conference controller. A, B, and C are in conference. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv C is dropped out of conference. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C. Use Case 7 Application is observing C, B is conference controller. A, B, and C are in conference. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1187 Message Sequence Charts Message Sequence Charts

Page 1251 diagram

Page 1252

CallInfo Result Action Scenario Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C C is dropped out of conference. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C. Use Case 8 Application is observing A and C. B is conference controller. A, B, and C are in conference. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A is dropped out of conference. ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C C is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C CallInvalidEv B is dropped out of conference. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C Application invokes Connection.disconnect() on Connection of B. Use Case 9 Application is observing B, and B is conference controller. A, B, and C are in conference. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1188 Message Sequence Charts Message Sequence Charts

Page 1252 diagram

Page 1253

CallInfo Result Action Scenario Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C C is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C Application invokes Connection.disconnect() on Connection of B. Use Case 10 Application is observing A, B and C, and B is conference controller. A, B, and C are in conference. • JTAPI INI parameter is enabled to allow dropAnyPartyFeature. • Cisco Unified Communications Manager service parameter “Advanced Ad Hoc Conference Enable” is set to FALSE. A and A’ are shared line • Cisco Unified Communications Manager service parameter “Drop Ad Hoc Conference” set “never” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1189 Message Sequence Charts Message Sequence Charts

Page 1253 diagram

Page 1254

Call info Result Action Scenario N.A Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” InvalidStateException is thrown. InvalidStateException is thrown. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv A(abc) is dropped out of conference TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv Connections of A, and B are A(abc) is dropped out of conference. Application invokes Connection.getPartyInfo() at Connection of A. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect(xyz) on Connection of A. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect() on Connection of A. Use Case 11 Application is observing A, B is conference controller. A, A’ and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1190 Message Sequence Charts Message Sequence Charts

Page 1254 diagram

Page 1255

Call info Result Action Scenario N, A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” InvalidStateException is thrown. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv . A’(“xyz”) is dropped out of conference... InvalidStateException is thrown. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv A’(“xyz”) is dropped out of conference.. Application invokes Connection.getDisplayNames() at Connection of A. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect(xyz) on Connection of A. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect() on Connection of A. Use Case 12 Application is observing A’, B is conference controller. A, A’, and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1191 Message Sequence Charts Message Sequence Charts

Page 1255 diagram

Page 1256

Call info Result Action Scenario N.A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” InvalidStateException is thrown. TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ A’(xyz) is dropped out of conference. TermConnDropEv-TA CallCtlTermConnDroppedEv-TA A(abc) is dropped out of conference. TermConnDropEv-TA CallCtlTermConnDroppedEv-TA TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv A(abc) and A’(xyz)is dropped out of conference. Application invokes Connection.getDisplayNames() at Connection of A. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect(xyz) on Connection of A. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect() on Connection of A. Use Case 13 Application is observing A and A’. B is conference controller. A, A’, and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1192 Message Sequence Charts Message Sequence Charts

Page 1256 diagram

Page 1257

Call info Result Action Scenario N.A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” No Events A’(xyz) is dropped out of conference. No Events A(abc) is dropped out of conference. TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A CallInvalidEv B is disconnected from conference.g ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv Connections of A, and B are disconnected, A(abc) and A’(xyz) will be dropped, and since only B is left, it will also get dropped and call goes Invalid. Application invokes Connection.getDisplayNames() at Connection of A. Application invokes Connection.disconnect(xyz) on Connection of A. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect() on Connection of A. Use Case 14 Application is observing B, and B is conference controller. A, A’, and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1193 Message Sequence Charts Message Sequence Charts

Page 1257 diagram

Page 1258

Call info Result Action Scenario N.A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ A(xyz), dropped out of conference. TermConnDropEv-TA CallCtlTermConnDroppedEv-TA A(abc), dropped out of conference. TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is disconnected from conference. Application invokes Connection.getDisplayNames() at Connection of A. Application invokes Connection.disconnect(xyz) on Connection of A. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect() on Connection of B. Use Case 15 Application is observing A, A’ and B, and B is conference controller. A, A’, and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL TermConnDropEv-TA CallCtlTermConnDroppedEv-TA TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv Connections of A, and B are disconnected, A(abc) and A’(xyz) will be dropped, and since only B is left, it will also get dropped and call goes Invalid. Application invokes Connection.disconnect() on Connection of A. • JTAPI INI parameter is enabled to allow dropAnyPartyFeature. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1194 Message Sequence Charts Message Sequence Charts

Page 1258 diagram

Page 1259

• Cisco Unified Communications Manager service parameter “Advanced Ad Hoc Conference Enable” is set to TRUE. A and A’ are shared line • Cisco Unified Communications Manager service parameter “Drop Ad Hoc Conference” set “never” CallInfo Result Action Scenario N.A Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. No Events. A’(xyz) is disconnected from conference. TermConnDropEv-TA CallCtlTermConnDroppedEv-TA ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv A(abc) dropped out of conference TermConnDropEv-TA CallCtlTermConnDroppedEv-TA ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalid A(abc) is dropped out of conference. Application invokes Connection.getDisplayNames() at Connection of A. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect(xyz) on Connection of A. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect() on Connection of A. Use Case 16 Application is observing A, B is conference controller. A, A’ and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1195 Message Sequence Charts Message Sequence Charts

Page 1259 diagram

Page 1260

CallInfo Result Action Scenario N.A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. No Events. A(abc) is disconnected from conference. TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv A’(xyz) dropped out of conference TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalid A(xyz) is dropped out of conference. Application invokes Connection.getDisplayNames() at Connection of A. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect(xyz) on Connection of A. Application invokes Connection.disconnect() on Connection of A. Use Case 17 Application is observing A’, B is conference controller. A, A’, and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1196 Message Sequence Charts Message Sequence Charts

Page 1260 diagram

Page 1261

CallInfo Result Action Scenario N.A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ No Events. A’(xyz) is disconnected from conference. TermConnDropEv-TA CallCtlTermConnDroppedEv-TA A(abc) dropped out of conference TermConnDropEv-TA CallCtlTermConnDroppedEv-TA TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalid A(xyz) is dropped out of conference. Application invokes Connection.getDisplayNames() at Connection of A. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect(xyz) on Connection of A. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect() on Connection of A. Use Case 18 Application is observing A and A’. B is conference controller. A, A’, and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1197 Message Sequence Charts Message Sequence Charts

Page 1261 diagram

Page 1262

CallInfo Result Action Scenario N.A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalid B is disconnected from conference. No Events. A’(xyz) is disconnected from conference. No Events A(abc) dropped out of conference ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalid A(abc), A(xyz) and B is dropped out of conference. Application invokes Connection.getDisplayNames() at Connection of A. Application invokes Connection.disconnect() on Connection of B. Application invokes Connection.disconnect(xyz) on Connection of A. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect() on Connection of A. Use Case 19 Application is observing B, and B is conference controller. A, A’, and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1198 Message Sequence Charts Message Sequence Charts

Page 1262 diagram

Page 1263

CallInfo Result Action Scenario N.A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B B is dropped out of conference. TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ A’(xyz) is disconnected from conference. TermConnDropEv-TA CallCtlTermConnDroppedEv-TA A(abc) dropped out of conference TermConnDropEv-TA CallCtlTermConnDroppedEv-TA TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalid A(abc), A(xyz) and B is dropped out of conference. Application invokes Connection.getDisplayNames () at Connection of A. Application invokes Connection.disconnect () on Connection of B Application invokes Connection.disconnect (xyz) on Connection of A. Application invokes Connection.disconnect (abc) on Connection of A. Application invokes Connection.disconnect() on Connection of A. Use Case 20 Application is observing A, A’ and B, and B is conference controller. A, A’, and B are in conference. Display name for A is “abc”, and displayname for A’ is “xyz” N..A Interface Returns “True” Application invokes CiscoCall.isConferenceCall() A, B, C are in conference. N..A Interface Returns “False” Application invokes CiscoCall.isConferenceCall() A, B, C are in conference. B drops from conference Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1199 Message Sequence Charts Message Sequence Charts

Page 1263 diagram

Page 1264

N..A Interface Returns “True” Application invokes CiscoCall.isConferenceCall() A, B, B’ are in conference. N..A Interface Returns “False” Application invokes CiscoCall.isConferenceCall() A, B, B’ are in conference, B’ drops from conference. N..A Interface Returns “True” Application invokes CiscoCall.isConferenceCall() A, B, C are in conference. Applications opens provider, gets snapshot call event N..A Interface Returns “True” Application invokes CiscoCall.isConferenceCall() A, B, B’ are in conference. Applications opens provider, gets snapshot call event • JTAPI INI parameter is enabled to allow dropAnyPartyFeature. • Cisco Unified Communications Manager service parameter “Advanced Ad Hoc Conference Enable” is set to FALSE. • Cisco Unified Communications Manager service parameter “Drop Ad Hoc Conference” set “When controller leaves” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1200 Message Sequence Charts Message Sequence Charts

Page 1264 diagram

Page 1265

CallInfo Result Action Scenario Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C C is dropped out of conference. TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C TermConnDropEv CallCtlTermConnDroppedEv ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A CallInvalidEV A, B C is dropped out of conference. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C Application invokes Connection.disconnect() on Connection of B. Use Case 21 Application is observing A, B and C, and B is conference controller. A, B, and C are in conference. • JTAPI INI parameter is enabled to allow dropAnyPartyFeature. • Cisco Unified Communications Manager service parameter “Advanced Ad Hoc Conference Enable” is set to TRUE. • Cisco Unified Communications Manager service parameter “Drop Ad Hoc Conference” set “When controller leaves” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1201 Message Sequence Charts Message Sequence Charts

Page 1265 diagram

Page 1266

CallInfo Result Action Scenario Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE TermConnDropEv-TA CallCtlTermConnDroppedEv-TA ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A is dropped out of conference. TermConnDropEv-TC CallCtlTermConnDroppedEv-TC ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C C is dropped out of conference. TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B TermConnDropEv-TC CallCtlTermConnDroppedEv-TC ConnDisconnectedEv-C CallCtlConnDisconnectedEv-C TermConnDropEv-TA CallCtlTermConnDroppedEv-TA ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A, B, and C are dropped out of conference. Application invokes Connection.disconnect() on Connection of A. Application invokes Connection.disconnect() on Connection of C Application invokes Connection.disconnect() on Connection of B. Use Case 22 Application is observing A, B and C, and B is conference controller. A, B, and C are in conference. • JTAPI INI parameter is enabled to allow dropAnyPartyFeature. • Cisco Unified Communications Manager service parameter “Advanced Ad Hoc Conference Enable” is set to FALSE. • Cisco Unified Communications Manager service parameter “Drop Ad Hoc Conference” set “When controller leaves” Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1202 Message Sequence Charts Message Sequence Charts

Page 1266 diagram

Page 1267

CallInfo Result Action Scenario N.A. Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ A(xyz), dropped out of conference. Application invokes Connection.getDisplayNames() at Connection of A. Application invokes Connection.disconnect(xyz) on Connection of A. Use Case 23 Application is observing A, A’ and B, and B is conference controller. A, A’, and B are in conference. Displayname for A is “abc”, and displayname for A’ is “xyz” Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE TermConnDropEv-TA CallCtlTermConnDroppedEv-TA A(abc), dropped out of conference. TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B TermConnDropEv-TA CallCtlTermConnDroppedEv-TA TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A, A’ and B is disconnected from conference. Application invokes Connection.disconnect(abc) on Connection of A. Application invokes Connection.disconnect() on Connection of B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1203 Message Sequence Charts Message Sequence Charts

Page 1267 diagram

Page 1268

CallInfo Result Action Scenario Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL TermConnDropEv-TA CallCtlTermConnDroppedEv-TA TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalidEv Connections of A, and B are disconnected, A(abc) and A’(xyz) will be dropped, and since only B is left, it will also get dropped and call goes Invalid. Application invokes Connection.disconnect() on Connection of A. • JTAPI INI parameter is enabled to allow dropAnyPartyFeature. • Cisco Unified Communications Manager service parameter “Advanced Ad Hoc Conference Enable” is set to TRUE. • Cisco Unified Communications Manager service parameter “Drop Ad Hoc Conference” set “When controller leaves” CallInfo Result Action Scenario N.A. JTAPI returns CiscoPartyInfo[] with CiscoPartyInfo.getDisplayName() of “abc” and “xyz” Application invokes Connection.getDisplayNames () at Connection of A. Use Case 24 Application is observing A, A’ and B, and B is conference controller. A, A’, and B are in conference. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1204 Message Sequence Charts Message Sequence Charts

Page 1268 diagram

Page 1269

CallInfo Result Action Scenario Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_CONFERENCE Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B TermConnDropEv-TA CallCtlTermConnDroppedEv-TA TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A A, A’ and B is dropped out of conference. TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ A’(xyz) is disconnected from conference. TermConnDropEv-TA CallCtlTermConnDroppedEv-TA A(abc) dropped out of conference Application invokes Connection.disconnect () on Connection of B Application invokes Connection.disconnect (xyz) on Connection of A. Application invokes Connection.disconnect (abc) on Connection of A. Display name for A is “abc”, and displayname for A’ is “xyz” Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_NORMAL TermConnDropEv-TA CallCtlTermConnDroppedEv-TA TermConnDropEv-TA’ CallCtlTermConnDroppedEv-TA’ ConnDisconnectedEv-A CallCtlConnDisconnectedEv-A TermConnDropEv-TB CallCtlTermConnDroppedEv-TB ConnDisconnectedEv-B CallCtlConnDisconnectedEv-B CallInvalid A(abc), A(xyz) and B is dropped out of conference. Application invokes Connection.disconnect() on Connection of A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1205 Message Sequence Charts Message Sequence Charts

Page 1269 diagram

Page 1270

Park Monitoring Support Phone B—Cisco Unified IP Phone 7900 Series with SIP/SCCP Phone A—Future models. Phone A’—Cisco Unified IP Phone 7900 Series with SIP/SCCP Park DN—P1, P2 Phone C—Cisco Unified IP Phone 7900 Series with SIP/SCCP All the default values for the Park Monitoring Reversion timer and Park Monitoring Forward No reversion timers apply. Use Case 1: Park Monitoring States Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers. Event/Call info Result Action Cause = CAUSE_NORMAL park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 1 Application invokes CiscoConnection.park() on connection on A. Park Monitoring Reversion timer starts Cause = CAUSE_NORMAL park state = REMINDER sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Step 2 After step 1, Park Monitoring reversion timer expires after the configured time Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1206 Message Sequence Charts Park Monitoring Support

Page 1270 diagram

Page 1271

Event/Call info Result Action Cause = CAUSE_NORMAL park state = RETRIEVED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC2 CallActiveEv GC2 ConnCreatedEv C GC2 ConnConnectedEv C GC2 CallCtlConnInitiatedEv C GC2 TermConnCreatedEv TC GC2 TermConnActiveEv TC GC2 CallCtlTermConnTalkingEv TC GC2 CallCtlConnDialingEv C GC2 CallCtlConnEstablishedEv C GC2 ConnCreatedEv P1 GC2 ConnInProgressEv P1 GC2 CallCtlConnOfferedEv P1 GC1 CiscoCallChangedEv GC2 ConnCreatedEv B GC2 ConnConnectedEv B GC2 CallCtlConnEstablishedEv B GC2 TermConnCreatedEv TB GC2 TermConnActiveEv TB GC2 CallCtlTermConnTalkingEv TB GC2 ConnConnectedEv P1 GC2 CallCtlConnEstablishedEv P1 GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 GC1 TermConnDroppedEv TB GC1 CallCtlTermConnDroppedEv TB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B GC1 CallInvalidEv GC2 ConnDisconnectedEv P1 GC2 CallCtlConnDisconnectedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 3 After step 1 or 2, application sends unpark request CiscoTerminal.unpark() on Terminal of C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1207 Message Sequence Charts Message Sequence Charts

Page 1271 diagram

Page 1272

Event/Call info Result Action Cause = CAUSE_NORMAL park state = ABANDONED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 TermConnDroppedEv TB GC1 CallCtlTermConnDroppedEv TB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 GC1 CallInvalidEv Events received at Address Observer on A CiscoAddrParkStatusEv A Step 4 After step 1 or 2 above, B drops off the call invoking CiscoConnection.disconnect() on the connection of B. Reason = CiscoFeatureReason.FORWARD_NO_RETRIEVE Cause = CAUSE_NORMAL park state = FORWARDED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 ConnCreatedEv F GC1 ConnInProgressEv F GC1 CallCtlConnOfferedEv F GC1 ConnAlertingEv F GC1 CallCtlConnAlertingEv F GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 5 Consider Park Monitoring forward no retrieve destination on A is configured as F After step 2, Park Monitoring Forward no retrieve timer starts • Park Monitoring Forward no retrieve timer expires. • Call is forwarded to F Reason = CiscoFeatureReason.FORWARD_NO_RETRIEVE Cause = CAUSE_NORMAL park state = FORWARDED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 ConnCreatedEv A GC1 ConnInProgressEv A GC1 CallCtlConnOfferedEv A GC1 ConnAlertingEv A GC1 CallCtlConnAlertingEv A GC1 TermConnCreatedEv TA GC1 TermConnRingingEv TA GC1 CallCtlTermConnRingingEvImpl TA GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 6 Consider Forward no retrieve destination on A is configured to self • After step 2, Park Monitoring Forward no retrieve timer starts • Park Monitoring Forward no retrieve timer expires. • Call is forwarded to parker’s line A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1208 Message Sequence Charts Message Sequence Charts

Page 1272 diagram

Page 1273

Event/Call info Result Action Reason = CiscoFeatureReason.PARKREMINDER Cause = CAUSE_NORMAL park state = FORWARDED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 ConnCreatedEv A GC1 ConnInProgressEv A GC1 CallCtlConnOfferedEv A GC1 ConnAlertingEv A GC1 CallCtlConnAlertingEv A GC1 TermConnCreatedEv TA GC1 TermConnRingingEv TA GC1 CallCtlTermConnRingingEvImpl TA GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 7 Consider Forward no retrieve destination is not configured • After step 2, Park Monitoring Forward no retrieve timer starts • Park Monitoring Forward no retrieve timer expires. • Call is forwarded/reverted to parker’s line A Use Case 2: Shared Line Scenario - Cisco Unified IP Phone Does Park Initial scenario: Application has added Call Observer on A, B, A’. Application has added Address Observer on A. B calls A. A/A’ ring. A answers. Event/Call info Result Action Cause = CAUSE_NORMAL park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 TermConnDroppedEv TA' GC1 CallCtlTermConnDroppedEv TA' GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 1 Application invokes CiscoConnection.park() on connection on A. Park Monitoring Reversion timer starts Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1209 Message Sequence Charts Use Case 2: Shared Line Scenario - Cisco Unified IP Phone Does Park

Page 1273 diagram

Page 1274

Event/Call info Result Action Reason = CiscoFeatureReason.PARKREMINDER Cause = CAUSE_NORMAL park state = FORWARDED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 ConnCreatedEv A GC1 ConnInProgressEv A GC1 CallCtlConnOfferedEv A GC1 ConnAlertingEv A GC1 CallCtlConnAlertingEv A GC1 TermConnCreatedEv TA GC1 TermConnRingingEv TA GC1 CallCtlTermConnRingingEvImpl TA GC1 ConnInProgressEv A GC1 ConnAlertingEv A GC1 TermConnCreatedEv TA' GC1 TermConnRingingEv TA' GC1 CallCtlTermConnRingingEvImpl TA' GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Note all shared lines ring as is today Step 2 Consider Forward no retrieve destination is not configured, • Consider Park Monitoring Reversion timer and Park Monitoring Forward no reversion timer expires. • Call is forwarded/reverted to parker's line A Use Case 3: Shared Line Scenario - Cisco Unified IP Phone 7900 Series with SIP Does Park Initial scenario: Application has added Call Observer on A, B, A’. Application has added Address Observer on A. B calls A. A/A’ ring. A’ answers. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1210 Message Sequence Charts Use Case 3: Shared Line Scenario - Cisco Unified IP Phone 7900 Series with SIP Does Park

Page 1274 diagram

Page 1275

Event/Call info Result Action Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 TermConnDroppedEv TA' GC1 CallCtlTermConnDroppedEv TA' GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Note New event is not seen as Cisco Unified IP Phone 7900 Series does park Step 1 Application invokes CiscoConnection.park() on connection on A. Park reversion timer starts Reason = CiscoFeatureReason.PARKREMINDER Events received at Call Observer on A, B GC1 ConnCreatedEv A GC1 ConnInProgressEv A GC1 CallCtlConnOfferedEv A GC1 ConnAlertingEv A GC1 CallCtlConnAlertingEv A GC1 TermConnCreatedEv TA GC1 TermConnRingingEv TA GC1 CallCtlTermConnRingingEvImpl TA GC1 ConnInProgressEv A GC1 ConnAlertingEv A GC1 TermConnCreatedEv TA' GC1 TermConnRingingEv TA' GC1 CallCtlTermConnRingingEvImpl TA' GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 Note All shared lines including the Cisco Unified IP Phone (future model) phone A receives the incoming call Step 2 Consider Park Reversion timer expires • Call is reverted to parker's line A Use Case 4: Use Case for Snap Shot Scenario Initial scenario: Application has added Call Observer on A, B. Application has NOT added Address Observer on A. B calls A. A answers. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1211 Message Sequence Charts Use Case 4: Use Case for Snap Shot Scenario

Page 1275 diagram

Page 1276

Page 1276 diagram

Page 1277

Event/Call info Result Action Events received at Call Observer on A, B GC2 CallActiveEv GC2 ConnCreatedEv C GC2 ConnConnectedEv C GC2 CallCtlConnInitiatedEv C GC2 TermConnCreatedEv TC GC2 TermConnActiveEv TC GC2 CallCtlTermConnTalkingEv TC GC2 CallCtlConnDialingEv C GC2 CallCtlConnEstablishedEv C GC2 ConnCreatedEv P1 GC2 ConnInProgressEv P1 GC2 CallCtlConnOfferedEv P1 GC1 CiscoCallChangedEv GC2 ConnCreatedEv B GC2 ConnConnectedEv B GC2 CallCtlConnEstablishedEv B GC2 TermConnCreatedEv TB GC2 TermConnActiveEv TB GC2 CallCtlTermConnTalkingEv TB GC2 ConnConnectedEv P1 GC2 CallCtlConnEstablishedEv P1 GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 GC1 TermConnDroppedEv TB GC1 CallCtlTermConnDroppedEv TB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B GC1 CallInvalidEv GC2 ConnDisconnectedEv P1 GC2 CallCtlConnDisconnectedEv P1 Step 3b After step 1, application sends unpark request CiscoTerminal.unpark() on Terminal of C. New address event with park state = RETRIEVED is not received at A, since the call is already retrieved Step 4 After step 3, application now adds Address Observer on A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1213 Message Sequence Charts Message Sequence Charts

Page 1277 diagram

Page 1278

Use Case 5: Park DN Is Monitored Initial scenario: Application has added Call Observer on A, B. Application invokes registerFeature() API on Provider in order to monitor park DN P1. Application has added Address Observer on A. B calls A. A answers. Event/Call info Result Action Cause = CAUSE_NORMAL park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Provider Observer Prov1 CiscoProvCallParkEv Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 1 Application invokes CiscoConnection.park() on connection on A. Park Monitoring reversion timer starts Use Case 6: Query Number of Parked Calls Initial scenario: Application has added Call Observer on A, B, C. Event/Call info Result Action Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Step 1 B calls A. A answers. Application invokes CiscoConnection.park() on connection on A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1214 Message Sequence Charts Use Case 5: Park DN Is Monitored

Page 1278 diagram

Page 1279

Event/Call info Result Action Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P2 GC1 ConnInProgressEv P2 GC1 CallCtlConnQueuedEv P2 Step 2 C calls A. A answers. Application invokes CiscoConnection.park() on connection on A for the second call on A. CiscoAddressCallInfo is returned which includes information about number of parked calls getNumParkedCalls() returns 2 Step 3 Application invokes CiscoAddress.getAddress CallInfo( Term A) Application invokes CiscoAddress CallInfo.getNumParkedCalls() Use Case 7: Filter Enabling or Disabling Initial scenario: Application has added Call Observer on A, B. B calls A. A answers. Event/Call info Result Action Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Events received at Address Observer on A No event received as filter is disabled Step 1 Initially filter is disabled. • Application adds AddressObserver on A. • Application now invokes CiscoConnection.park() on connection on A. • Park reversion timer starts Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1215 Message Sequence Charts Use Case 7: Filter Enabling or Disabling

Page 1279 diagram

Page 1280

Event/Call info Result Action Cause = CAUSE_SNAPSSHOT park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Step 2 After step 1, Application enables filter via setCiscoAddrPark StatusEvFilter(true) and then by invoking CiscoAddress. setFilter(CiscoAddrEvFilter), for being able to receive the events. Use Case 8: Filter Enabling or Disabling Initial scenario: From the phone B calls A. A answers.(Call Observers are not added) Event/Call info Result Action Cause = CAUSE_NORMAL park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Step 1 Initially filter is enabled. • Application adds AddressObserver on A. • Application now invokes park directly from the phone A. • Park reversion timer starts Use Case 9: Filter Enabling or Disabling Initial scenario: From the phone B calls A. A answers.(Call Observers are not added) Event/Call info Result Action Cause = CAUSE_SNAPSHOT park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A No event received yet, since filter is disabled Events received at Address Observer on A CiscoAddrParkStatusEv A Step 1 Initially filter is disabled. • Application adds AddressObserve on A. • Application now invokes park directly from the phone A. • Park reversion timer starts. • Application now enables filter and invokes CiscoAddress. setFilter(CiscoAddr EvFilter) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1216 Message Sequence Charts Use Case 8: Filter Enabling or Disabling

Page 1280 diagram

Page 1281

Event/Call info Result Action Cause = CAUSE_NORMAL park state = REMINDER sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Step 2 Park reminder timer expires Use Case 10: Filter Enabling or Disabling Initial Scenario : Initial scenario: Application has added Call Observer on A, B. B calls A. A answers. Event/Call info Result Action Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Events received at Address Observer on A No event received as filter is disabled Step 1 Initially all filters are disabled in CiscoAddEvFilter • Application adds AddressObserver on A. • Application now invokes CiscoConnection. park() on connection on A. • Park reversion timer starts Events received at Address Observer on A No event received as the address filter is not set. Step 2 After step 1, Application invokes setCiscoAddrPark StatusEvFilter(true) but does not invoke CiscoAddress. setFilter (CiscoAddrEvFilter) Cause = CAUSE_SNAPSSHOT park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Step 3 Now the application invokes setFilter (CiscoAddrEvFilter) on CiscoAddress Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1217 Message Sequence Charts Use Case 10: Filter Enabling or Disabling

Page 1281 diagram

Page 1282

Additional Use Cases for Park Monitoring Phone B—Cisco Unified IP Phone 7900 Series with SIP/SCCP Phone A—Future models. Phone A’—Cisco Unified IP Phone 7900 Series with SIP/SCCP Park DN—P1, P2 Phone C—Cisco Unified IP Phone 7900 Series with SIP/SCCP All the default values for the Park Monitoring Reversion timer and Park Monitoring Forward No reversion timers apply. 1. Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers. Filter value has been set to ‘true’ through setCiscoAddrParkStatusEvFilter(). Event/Call info Result Action Cause = CAUSE_NORMAL park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 1 • Application invokes CiscoConnection.park() on connection on A. • Park Monitoring Reversion timer starts Cause = CAUSE_NORMAL park state = REMINDER sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Step 2 After step 1, Park Monitoring reversion timer expires after the configured time Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1218 Message Sequence Charts Additional Use Cases for Park Monitoring

Page 1282 diagram

Page 1283

Page 1283 diagram

Page 1284

Event/Call info Result Action Cause = CAUSE_NORMAL park state = ABANDONED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 TermConnDroppedEv TB GC1 CallCtlTermConnDroppedEv TB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 GC1 CallInvalidEv Events received at Address Observer on A CiscoAddrParkStatusEv A Step 4 After step 1 or 2 above, B drops off the call invoking CiscoConnection.disconnect() on the connection of B. Reason = CiscoFeatureReason.FORWARD_NO_RETRIEVE Cause = CAUSE_NORMAL park state = FORWARDED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 ConnCreatedEv F GC1 ConnInProgressEv F GC1 CallCtlConnOfferedEv F GC1 ConnAlertingEv F GC1 CallCtlConnAlertingEv F GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 5 Consider Park Monitoring forward no retrieve destination on A is configured as F • After step 2, Park Monitoring Forward no retrieve timer starts • Park Monitoring Forward no retrieve timer expires. • Call is forwarded to F Reason = FORWARD_NO_RETRIEVE Cause = CAUSE_NORMAL park state = FORWARDED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 ConnCreatedEv A GC1 ConnInProgressEv A GC1 CallCtlConnOfferedEv A GC1 ConnAlertingEv A GC1 CallCtlConnAlertingEv A GC1 TermConnCreatedEv TA GC1 TermConnRingingEv TA GC1 CallCtlTermConnRingingEvImpl TA GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 6 Consider Forward no retrieve destination on A is configured to self • After step 2, Park Monitoring Forward no retrieve timer starts • Park Monitoring Forward no retrieve timer expires. • Call is forwarded to parker’s line A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1220 Message Sequence Charts Message Sequence Charts

Page 1284 diagram

Page 1285

Event/Call info Result Action Reason = PARKREMINDER Cause = CAUSE_NORMAL park state = FORWARDED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 ConnCreatedEv A GC1 ConnInProgressEv A GC1 CallCtlConnOfferedEv A GC1 ConnAlertingEv A GC1 CallCtlConnAlertingEv A GC1 TermConnCreatedEv TA GC1 TermConnRingingEv TA GC1 CallCtlTermConnRingingEvImpl TA GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 7 Consider Forward no retrieve destination is not configured • After step 2, Park Monitoring Forward no retrieve timer starts • Park Monitoring Forward no retrieve timer expires. • Call is forwarded/reverted to parker’s line A 2. Initial scenario: Application has added Call Observer on A, B, A’. Application has added Address Observer on A. B calls A. A/A’ ring. A answers. Filter value has been set to ‘true’ through setCiscoAddrParkStatusEvFilter(). Event/Call info Result Action Cause = CAUSE_NORMAL park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 TermConnDroppedEv TA' GC1 CallCtlTermConnDroppedEv TA' GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 1 Application invokes CiscoConnection.park() on connection on A. Park Monitoring Reversion timer starts Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1221 Message Sequence Charts Message Sequence Charts

Page 1285 diagram

Page 1286

Event/Call info Result Action Events received at Call Observer on A, B GC1 ConnCreatedEv A GC1 ConnInProgressEv A GC1 CallCtlConnOfferedEv A GC1 ConnAlertingEv A GC1 CallCtlConnAlertingEv A GC1 TermConnCreatedEv TA GC1 TermConnRingingEv TA GC1 CallCtlTermConnRingingEvImpl TA GC1 ConnInProgressEv A GC1 ConnAlertingEv A GC1 TermConnCreatedEv TA' GC1 TermConnRingingEv TA' GC1 CallCtlTermConnRingingEvImpl TA' GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 Step 2 Consider Forward no retrieve destination is not configured, • Consider Park Monitoring Reversion timer and Park Monitoring Forward no reversion timer expires. • Call is forwarded/reverted to parker's line A Cause = CAUSE_NORMAL park state = FORWARDED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Note All shared lines ring as is today 3. Initial scenario: Application has added Call Observer on A, B. Application has NOT added Address Observer on A. B calls A. A answers. Filter value has been set to ‘true’ through setCiscoAddrParkStatusEvFilter(). Event/Call info Result Action Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Step 1 Application invokes CiscoConnection.park() on connection on A. Park Monitoring reversion timer starts Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1222 Message Sequence Charts Message Sequence Charts

Page 1286 diagram

Page 1287

Event/Call info Result Action Cause = CAUSE_SNAPSHOT park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Step 2 After step 1, application now adds Address Observer on A. Cause = CAUSE_NORMAL park state = REMINDER sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Step 3a After step 2, consider Park Monitoring Reversion timer expires Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1223 Message Sequence Charts Message Sequence Charts

Page 1287 diagram

Page 1288

Event/Call info Result Action Events received at Call Observer on A, B GC2 CallActiveEv GC2 ConnCreatedEv C GC2 ConnConnectedEv C GC2 CallCtlConnInitiatedEv C GC2 TermConnCreatedEv TC GC2 TermConnActiveEv TC GC2 CallCtlTermConnTalkingEv TC GC2 CallCtlConnDialingEv C GC2 CallCtlConnEstablishedEv C GC2 ConnCreatedEv P1 GC2 ConnInProgressEv P1 GC2 CallCtlConnOfferedEv P1 GC1 CiscoCallChangedEv GC2 ConnCreatedEv B GC2 ConnConnectedEv B GC2 CallCtlConnEstablishedEv B GC2 TermConnCreatedEv TB GC2 TermConnActiveEv TB GC2 CallCtlTermConnTalkingEv TB GC2 ConnConnectedEv P1 GC2 CallCtlConnEstablishedEv P1 GC1 ConnDisconnectedEv P1 GC1 CallCtlConnDisconnectedEv P1 GC1 TermConnDroppedEv TB GC1 CallCtlTermConnDroppedEv TB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv BC1 CallInvalidEv GC2 ConnDisconnectedEv P1 GC2 CallCtlConnDisconnectedEv P1 Step 3b After step 1, application sends unpark request CiscoTerminal.unpark() on Terminal of C. New address event with park state = RETRIEVED is not received at A, since the call is already retrieved Step 4 After step 3, application now adds Address Observer on A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1224 Message Sequence Charts Message Sequence Charts

Page 1288 diagram

Page 1289

Initial scenario: Application has added Call Observer on A, B, C. Filter value has been set to ‘true’ through setCiscoAddrParkStatusEvFilter(). Event/Call info Result Action Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Step 1 B calls A. A answers. Application invokes CiscoConnection.park() on connection on A. Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P2 GC1 ConnInProgressEv P2 GC1 CallCtlConnQueuedEv P2 Step 2 C calls A. A answers. Application invokes CiscoConnection.park() on connection on A for the second call on A. CiscoAddressCallInfo is returned which includes information about number of parked calls getNumParkedCalls() returns 2 Step 3 Application invokes CiscoAddress.getAddressCallInfo( Term A) Application invokes CiscoAddressCallInfo.getNumParkedCalls() 5. Use case to check for address event filter to control event notification- Filter value is set to ‘false’ through setCiscoAddrParkStatusEvFilter(). This is also the default value. Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1225 Message Sequence Charts Message Sequence Charts

Page 1289 diagram

Page 1290

Event/Call info Result Action Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Events received at Address Observer on A No event notification since filter value is false Step 1 By default the address event filter value is false. Application invokes CiscoConnection.park() on connection on A. Park Monitoring Reversion timer starts 6. Use case to check for address event filter to control event notification. Filter value has been set to ‘true’ through setCiscoAddrParkStatusEvFilter(). Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers. Event/Call info Result Action Cause = CAUSE_NORMAL park state = PARKED sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Call Observer on A, B GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnCreatedEv P1 GC1 ConnInProgressEv P1 GC1 CallCtlConnQueuedEv P1 Events received at Address Observer on A CiscoAddrParkStatusEv A Step 1 Application enables the filter through CiscoAddrEvFilter. setCiscoAddrParkStatusEvFilter(true). Application invokes CiscoConnection.park() on connection on A. Park Monitoring Reversion timer starts Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1226 Message Sequence Charts Message Sequence Charts

Page 1290 diagram

Page 1291

Event/Call info Result Action Events received at Address Observer on A No event notification as filter is disabled Step 2 After step 1 above, Application now disables the filter through CiscoAddrEvFilter. setCiscoAddrParkStatusEvFilter(false). Consider Park Monitoring Reversion timer expires Cause = CAUSE_SNAPSHOT park state = REMINDER sub ID = 1234 CiscoCallID = CiscoCallID for GC1 park DN = P1 parked party = B terminal = TA Events received at Address Observer on A CiscoAddrParkStatusEv A Step 3 After step 2 above, Application now enables the filter through CiscoAddrEvFilter. setCiscoAddrParkStatusEvFilter(true). 7. Use case to check the value of the filter set for the event CiscoAddrPArkrStatusEv. Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers. Event/Call info Result Action The application receives the Boolean value ‘false’. Step 1 Application disables the filter through CiscoAddrEvFilter. setCiscoAddrParkStatusEvFilter(false) Application invokes the API getCiscoAddrParkStatusEvFilter() on CiscoAddrEvFilter. The Application receives the Boolean value ‘true’. Step 2 Application enables the filter value through CiscoAddrEvFilter. setCiscoAddrParkStatusEvFilter(true) Application invokes the API getCiscoAddrParkStatusEvFilter on CiscoAddrEvFilter. 8. Use case to check the notification of CiscoAddrIntercomInfoChangedEv and the value of the filter for the event, when the Intercom feature (target DN and/or intercom taget label) has not been changed. Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1227 Message Sequence Charts Message Sequence Charts

Page 1291 diagram

Page 1292

Event/Call info Result Action Events received at Address Observer on A No address notification as filter is disabled. The application receives the Boolean value ‘false’. Step 1 Application has set the filter value to ‘false’ through CiscoAddrEvFilter. setAddrIntercomInfo ChangedEvFilter(false) Application invokes the API getCiscoAddrIntercomInfo ChangedEvFilter() on CiscoAddrEvFilter. Events Received at Address Observer on A No events received as the intercom Feature is unchanged. The application receives the Boolean value ‘true’. Step 2 Application enables the filter value through CiscoAddrEvFilter. setCiscoAddrIntercomInfo ChangedEvFilter(true) Application invokes the API getCiscoAddrIntercomInfo ChangedEvFilter on CiscoAddrEvFilter. 9. Use case to check the notification of CiscoAddrIntercomInfoChangedEv and the value of the filter for the event, when the Intercom feature (target DN and/or intercom taget label) has been changed. Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers Event/Call info Result Action Events received at Address Observer on A No address notification as filter is disabled. The application receives the Boolean value ‘false’. Step 1 Application has set the filter value to ‘false’ through CiscoAddrEvFilter. setAddrIntercomInfo ChangedEvFilter(false) Application issues CiscoIntercomAddress.setIntercomTarget() on intercom address A Application invokes the API getCiscoAddrIntercomInfo ChangedEvFilter() on CiscoAddrEvFilter. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1228 Message Sequence Charts Message Sequence Charts

Page 1292 diagram

Page 1293

Event/Call info Result Action Events Received at Address Observer on A CiscoAddrIntercomInfoChangedEv A The application receives the Boolean value ‘true’. Step 2 Application enables the filter value through CiscoAddrEvFilter. setCiscoAddrIntercomInfo ChangedEvFilter(true) Application issues CiscoIntercomAddress.setIntercomTarget() on intercom address A Application invokes the API getCiscoAddrIntercomInfo ChangedEvFilter on CiscoAddrEvFilter. 10. Use case to check the notification of CiscoAddrIntercomInfoRestorationFailedEv and the value of the filter for this event. Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers Event/Call info Result Action Events Received at Address Observer on A No notification as the filter is disabled. The Application receives a Boolean value ‘false’ Step 1 • Application has set the filter value to ‘false’ through CiscoAddrEvFilter. setCiscoAddrIntercomInfo RestorationEvFilter(false) • Application has set intercom target DN and label for intercom address A. Now CTI Manager goes outofservice, JTAPI failsover to another CTIManager node. After intercom address A come back in service, JTAPI tries to restore intercom target DN , label and UnicodeLabel to the set values, however due to race condition some other application has already set the target DN, JTAPI get failure response from CTI. • Applications invokes the API getCiscoAddrIntercomInfo RestorationEvFilter() on CiscoAddrEvFilter. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1229 Message Sequence Charts Message Sequence Charts

Page 1293 diagram

Page 1294

Event/Call info Result Action Events Received at Address Observer on A CiscoAddrIntercomInfoRestorationFailedEv A The Application receives a Boolean value ‘true’ Step 2 • The application enables the filter through the API CiscoAddrEvFilter. setCiscoAddrIntercomInfo RestorationEvFilter(true) • Application has set intercom target DN and label for intercom address A. Now CTI Manager goes outofservice, JTAPI failsover to another CTIManager node. After intercom address A come back in service, JTAPI tries to restore intercom target DN , label and UnicodeLabel to the set values, however due to race condition some other application has already set the target DN, JTAPI get failure response from CTI. • Applications invokes the API getCiscoAddrIntercomInfo RestorationEvFilter() on CiscoAddrEvFilter. 11. Use case to check the notification of CiscoAddrRecordingConfigChangedEv and the value of the filter for this event. Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers Recording Profile Configurations Settings have not been changed Event/Call info Result Action Events received at Address Observer on A No address notification as filter is disabled. The application receives the Boolean value ‘false’. Step 1 • Application has set the filter value to ‘false’ through CiscoAddrEvFilter. setCiscoAddrRecording ConfigChangedEvFilter is set to default value (false) • Application invokes the API getCiscoAddrRecording ConfigChangedEvFilter() on CiscoAddrEvFilter. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1230 Message Sequence Charts Message Sequence Charts

Page 1294 diagram

Page 1295

Event/Call info Result Action Events Received at Address Observer on A No events as the Recording settings are unchanged. The application receives the Boolean value ‘true’. Step 2 • Application enables the filter value through CiscoAddrEvFilter. setCiscoAddrRecording ConfigChangedEvFilter(true) • Application invokes the API getCiscoAddrRecording ConfigChangedEvFilter on CiscoAddrEvFilter. 12. Use case to check the notification of CiscoAddrRecordingConfigChangedEv and the value of the filter for this event. Initial scenario: Application has added Call Observer on A and B. Application has added Address Observer on A. B calls A. A answers Event/Call info Result Action Events received at Address Observer on A No address notification as filter is disabled. The application receives the Boolean value ‘false’. Step 1 • Application has set the filter value to ‘false’ through CiscoAddrEvFilter. setCiscoAddrRecording ConfigChangedEvFilter (false)User changes the Recording Profile Configurations, through the Admin Pages. • Application invokes the API getCiscoAddrRecording ConfigChangedEvFilter() on CiscoAddrEvFilter. Events Received at Address Observer on A CiscoAddrRecordingConfigChangedEv A The application receives the Boolean value ‘true’. Step 2 • Application enables the filter value through CiscoAddrEvFilter. setCiscoAddrRecording ConfigChangedEvFilter(true)User changes the Recording Profile Configurations, through the Admin Pages. • Application invokes the API getCiscoAddrRecording ConfigChangedEvFilter on CiscoAddrEvFilter. Use Cases Related to DPark Initial set up: -Application has added call observer on B and A -User has configured DPark DN D Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1231 Message Sequence Charts Use Cases Related to DPark

Page 1295 diagram

Page 1296

B is a future model Cisco Unified IP Phone -A calls B. B answers with GCID GC1 Expected behavior Call Scenario When A( parked party) is connected to D, the following events are received Events received at Call Observer on B, A GC1 CallCtlTermConnHeldEv TB (CiscoFeatureReason. REASON_DPARK_CALLPARK) GC1 CiscoTermConnSelectChangedEv TB GC1 ConnUnknownEv B GC1 CallCtlConnUnknownEv B GC1 TermConnUnknownEv TB (CiscoFeatureReason. REASON_REFER)) GC1 ConnCreatedEv DGC1 ConnInProgressEv DGC1 CallCtlConnQueuedEv D (CiscoFeatureReason. REASON_REFER)) GC1 TermConnDroppedEv TB GC1 CallCtlTermConnDroppedEv TBGC1 ConnDisconnectedEv BGC1 CallCtlConnDisconnectedEv B(CiscoFeatureReason. REASON_REFER)) Assisted DPark from a Cisco Unified IP Phone: • Cisco Unified IP Phone phone B (which is on active call with A) presses the pre-configured ‘DPark BLF’ button • The parked party A will be connected to D and hearMoH No change in behavior. All events/reason remain the same as is today DPark from Cisco Unified IP Phone • Cisco Unified IP Phone phone B (which is on active call with A) presses the ‘Transfer’ softkey • Parked party A is put on hold, and parker B dials D • Parker B is connected to D and hears MOH. • Parker B presses"Transfer" softkey again to complete the transfer of the parked party A to Dpark code D. • Parked party A is connected to D No change in behavior. All events/reason remain the same as is today DPark from JTAPI API • Application requests for a consult call from B, using the consult() API with destination address as DPark DN D. Say this call has GCID–GC2 • Application complete transfer, using the transfer() API GC1.transfer(GC2) • When transfer is completed A is connected to DPark DN Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1232 Message Sequence Charts Message Sequence Charts

Page 1296 diagram

Page 1297

Expected behavior Call Scenario No change in behavior. All events/reason remain the same as is today Unpark from JTAPI API • Consider application is observing C. • After step 3, application issues a request to unpark using the connect() API, with destination address as the prefix code followed by DPark code. • A is connected to C No change in behavior. B is connected to DPark DN, but no park operation. Redirect to DPark DN via JTAPI API • B redirects to DPark code D, via the redirect() API with redirect destination as D. Logical Partitioning Feature Use Cases Redirect from a Logical Partition (LP) Restricted Cluster Terminal TA is configured with address A and is registered to a cluster which is configured with logical partition restrictions. Terminal TX is registered with address X which is configured to a cluster with no LP configuration. Result Action PlatformException is thrown to redirect request. getErrorCode() on the exception returns CiscoJtapiException. REDIRECT_CALL_PARTITIONING_POLICY X calls A. A redirects the call to a local PSTN number Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1233 Message Sequence Charts Logical Partitioning Feature Use Cases

Page 1297 diagram

Page 1298

Result Action Originating cluster recognizes that the call is redirect to a PSTN and disconnects the call Events delivered to Call Observer of A GC1 ConnFailedEv A CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED GC1 CallCtlConnFailedEv CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED GC1: GC1 TermConnDroppedEv A GC1 CallCtlTermConnDroppedEv TA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 ConnDisconnected X GC1 CallCtlConnDisconnectedEv X GC1 CallInvalidEv A calls X (GC1) , X redirects the call to its local PSTN number Call forward: Call to a address which is forward all to PSTM in GeoLocation with “disallowed” policy Result Action Connect() API succeeds but the call is dropped due to restrictions on A side. Events delivered to call observer of X GC1 ConnFailedEv A CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED GC1 CallCtlConnFailedEv CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED GC1: GC1 TermConnDroppedEv X GC1 CallCtlTermConnDroppedEv TX GC1 ConnDisconnectedEv X GC1 CallCtlConnDisconnectedEv X GC1 ConnDisconnected A GC1 CallCtlConnDisconnectedEv A GC1 CallInvalidEv setForward on A t o local PSTN Application is monitoring X. • X calls A using GC1.connect() Call Transfer: Transferring a call from different geo location to PSTN by controller in GeoLocation with “disallowed” policy Result Action Platform exception is thrown to transfer() request. getErrorCode() returns CiscoJtapiException. TRANSFERFAILED X calls A, A consults to PSTN number. Application is monitoring A. • A completes the transfer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1234 Message Sequence Charts Message Sequence Charts

Page 1298 diagram

Page 1299

Call Conference: Conferencing a call from different location to PSTN by controller in GeoLocation with “disallowed” policy Result Action Platform exception is thrown to conference() request. getErrorCode() returns CiscoJtapiException. CTIERR_FEATURE_NOT_AVAILABLE. X calls A, A consults to PSTN number. Application is monitoring A. • A completes the conference. Call Park / UnPark: Parking and un parking a PSTN call. A and B are in the same cluster but configured in different geo locations with LP restrictions. PSTN is the same geo location as B Result Action Call fails: ConnFailedEv A CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED CallCtlConnFailedEvCAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED PSTN number calls A, A answers and parks the call. Application is monitoring A and B • B un-parks the call using unpark() API. Shared Lines TermA and TermA’ are in the same cluster but configured in different geo locations with LP restrictions. PSTN is the same geo location as TermA. Result Action GC1: CallActiveEv GC1: ConnAlertingEv A GC1: TermConnRingingEv TermA GC1: CallCtlTermConnRingingEv TermA PSTN number calls A. Only TermA rings Call Park Reversion with Shared Lines in Different Geographic Locations TermA and TermA’ are in the same cluster but configured in different geo locations with LP restrictions. PSTN is the same geo location as TermA. Result Action GC1: CallActiveEv GC1: ConnAlertingEv A GC1: TermConnRingingEv TermA GC1: CallCtlTermConnRingingEv TermA PSTN number calls A, TermA answers and parks the call. After time out call is offered at TermA and not at TermA’ Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1235 Message Sequence Charts Shared Lines

Page 1299 diagram

Page 1300

ComponentUpdater Enhancement Use Cases Result Action Updater.log is creaated in the same directory Application calls ComponentUpdater(null) Updater.log is created in c:\temp Application calls ComponentUpdater("C:\temp\") No log is created. Application calls ComponentUpdater(“readonlydirectory”) Application does not have write permission to Readonlydirectory IPv6 Support Use case for getIPAddressingMode() Result Action getIPAddressingMode() returns 0 Step 1 IP Adrressing mode for terminal A in Cisco Unified Communications Manager Admin pages is set as IPv4 Application invokes CiscoTerminal.getIPAddressingMode() on terminal A. getIPAddressingMode() returns 1( provided user had re-set the device) Step 2 After step 1, the IP Addressing mode is changed from IPv4 to IPv6. User would be prompted to re set the device. Now application invokes CiscoTerminal.getIPAddressingMode() on terminal A. Support for Cisco Unified IP Phone 6900 Series Events to application Scenario / Description CiscoProviderCapabilityChangedEv – CiscoProvider.canObserverTerminalsWithRoleOver() returns true. CiscoProviderCapabilityChangedEv .hasObserverTerminalsWithRoleOverChanged() returns true. Events to Provider Observer: CiscoTermActivatedEv TermA CiscoTermA ctivatedEv TermB Application connects to CTIManager. • TermA is a Cisco Unified IP Phone 6921. • TermB is a Cisco Unified IP Phone 7931 with roll over mode. Admin now enables the new user role. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1236 Message Sequence Charts ComponentUpdater Enhancement Use Cases

Page 1300 diagram

Page 1301

Events to application Scenario / Description CiscoProviderCapabilityChangedEv – CiscoProvider.canObserverlTerminalsWithRoleOver() returns false. CiscoProviderCapabilityChangedEv .hasObserverTerminalsWithRoleOverChanged() returns true. Events to Provider Observer: CiscoTermRestrictedEv TermACiscoTermRestrictedEv TermB Admin removes the new user role. PlatformException is thrown. getErrorCode() returns CiscoJtapiException.CTIERR_DEVICE_RESTRICTED Term A is a Cisco Unfied IP 6900 series phone. Application does not have the new role enabled. Term A is in application control list Application adds observer on TermA Call Scenarios: Events delivered to Terminal Observer GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: CallCtlTermConnTalkingEv TermA GC1: CallCtlTermConnHeldEv TermA GC2: CallActiveEvGC2: ConnCreatedEv A:P1 GC2: ConnConnectedEv A:P1 GC2: CallCtlConnInitiatedEv A:P1 Term A is configured with adress A, A:P1, A:P2 where P1 and P2 are 2 partitions. Application has the new role “Standard CTI Allow Control of Phones supporting roll over mode”enabled. Term A is configured to roll over calls to same DN with max calls and busy trigger set to 1. Application adds callObserver on terminal. X calls A, application answers the call (GC1) Application issues consult request to Y (GC2). Call is created on A:P1 Events delivered to Terminal Observer GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: CallCtlTermConnTalkingEv TermA GC2: CallActiveEv GC2: ConnCreatedEv B GC2: ConnConnectedEv B GC2: CallCtlConnInitiatedEv B GC2: TermConnCreatedEv TernB GC2: CallCtlConnDialingEv B GC2: CallCtlConnEstablishedEv B GC2: ConnFailedEv B. getCiscoCause() returns CiscoCallEv.CAUSE_USERBUSY No roll over for incoming calls: Term A is configured with adress A, A:P1, A:P2 where P1 and P2 are 2 partitions. Application has the new role “Standard CTI Allow Control of Phones supporting roll over mode”enabled. Term A is configured to roll over calls to same DN with max calls and busy trigger set to 1. Application adds callObserver on terminal. X calls A, application answers the call (GC1). Applications calls A from B using connect API. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1237 Message Sequence Charts Message Sequence Charts

Page 1301 diagram

Page 1302

Events to application Scenario / Description Events delivered to Terminal Observer GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: CallCtlTermConnTalkingEv TermA PlatformException is thrown. getErrorCode() returns CiscoJtapiException.CTIERR_MAXCALL_LIMIT_REACHED Roll over for Transfer and Conference (consult())only: Term A is configured with adress A, A:P1, A:P2 where P1 and P2 are 2 partitions. Application has the new role “Standard CTI Allow Control of Phones supporting roll over mode”enabled. Term A is configured to roll over calls to same DN with max calls and busy trigger set to 1. Application adds callObserver on terminal. X calls A, application answers the call (GC1). Applications calls connect() API from Adress A to Y. Similar exception will be seen for unPark(), startMonitor() requests. Events delivered to CallObserver on A GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: CallCtlTermConnTalkingEv TermA PlatformException is thrown. getErrorDescription() returns (“No callobserver on address A:P1). getErrorCode() returns CiscoJtapiException. ASSOCIATED_LINE_NOT_OPEN Only 1 address has callObserver: Term A is configured with adress A, A:P1, A:P2 where P1 and P2 are 2 partitions. Application has the new role “Standard CTI Allow Control of Phones supporting roll over mode”enabled. Term A is configured to roll over calls to same DN with max calls and busy trigger set to 1. Application adds callObserver on address A only. X calls A, call is answered Applications consults with Y using consult() API. On phone call consult call is created on A:P1 Events delivered to Terminal Observer GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: CallCtlTermConnTalkingEv TermA GC1: CallCtlTermConnHeldEv TermA GC2: CallActiveEv GC2: ConnCreatedEv A:P1 GC2: ConnConnectedEv A:P1 GC2: CallCtlConnInitiatedEv A:P1 Roll over to any line: In roll over, preference is giving to addresses with the same DN. If an address with the same DN is available it is choosen to roll over the consult call. Term A is configured with adress A, B, A:P1 where P1 is partition. Application has the new role “Standard CTI Allow Control of Phones supporting roll over mode”enabled. Term A is configured to roll over calls to any line with max calls and busy trigger set to 1. Application adds callObserver on TermA X calls A, application answers the call. Applicaton consults with Y. The consult call is created on line3. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1238 Message Sequence Charts Message Sequence Charts

Page 1302 diagram

Page 1303

Events to application Scenario / Description Events delivered to Terminal Observer GC2: ConnConnectedEv A GC2: CallCtlConnEstablishedEv A GC2: CallCtlTermConnTalkingEv TermA GC2: CallCtlTermConnHeldEv TermA GC3: CallActiveEv GC3: ConnCreatedEv B GC3: ConnConnectedEv B GC3: CallCtlConnInitiatedEv B … GC3: ConnCreatedEv Y .. GC3: CallCtlConnAlertingEv Y .. GC3: ConnConnectedEv Y GC3: CallCtlConnEstablishedEv Y CiscoTransferStartEv getTransferControllerAddress() returns A….CiscoTransferEndEv Roll over to any line (same DN has another call): Term A is configured with adress A, B, A:P1 where P1 is partition. Application has the new role “Standard CTI Allow Control of Phones supporting roll over mode”enabled. Term A is configured to roll over calls to any line with max calls and busy trigger set to 1. Application adds callObserver on TermA GC1: A:P1 calls Z, A:P1 holds the call GC2:X calls A, application answers the call Application consults GC2 to Y (GC3) Application completes the transfer Events delivered to Terminal Observer … … GC1: ConnConnectedEv A GC1: CallCtlConnEstablishedEv A GC1: CallCtlTermConnTalkingEv TermA GC1: CallCtlTermConnHeldEv TermA GC2: CallActiveEv GC2: ConnCreatedEv A GC2: ConnConnectedEv A GC2: CallCtlConnInitiatedEv A Max call > 1: Term A is configured with adress A, A:P1 where P1 is partition. Application has the new role “Standard CTI Allow Control of Phones supporting roll over mode”enabled. Term A is configured to roll over calls to any line with max calls and busy trigger set to 3 and 2 on A. Application adds callObserver on TermA. X call A, A answers Application consults with Y Consult is setup on A (same line) PlatformException is thrown. getErrorCode() returns CiscoJtapiException.CTIERR_MAXCALL_LIMIT_REACHED Term A is configured with address A, A:P1 where P1 is partition. Application has the new role “Standard CTI Allow Control of Phones supporting roll over mode”enabled. Term A is configured to roll over calls to any line with max calls and busy trigger set to 1/1 on A and A:P1. Application adds callObserver on TermA. A1 calls X. X answers the call – GC1 Y calls A. A answers the call and calls consult to Z Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1239 Message Sequence Charts Message Sequence Charts

Page 1303 diagram

Page 1304

Terminal and Address Capability Settings Use Cases Expected behavior Call Scenario A.getMaxCalls(TermA) returns 2 A.getMaxCalls(TermA1) returns 3 A.getMaxCalls(null) return 2 or 3 A.getBusyTrigger(TermA) returns 1 A.getBusyTrigger(TermA1) returns 2 A.getButtonPosition(TermA) returns 1 A.getButtonPosition(TermA1) returns 2 Max Calls, busy trigger and Line Button: Address A is configured on TermA and TermA1. Line on TermA is configured with max calls 2 and line on TermA1 is configured with max calls 3. A on TermA is configured with busy trigger of 1 and A on TermA1 is configured with busy trigger of 2. A is on button 1 on TermA and on button 2 on TermA1. A.getVoiceMailPilot() returns 2001 = CiscoAddrVoiceMailPilotChangedEv Ev.getAddress.getVoiceMailPilot() returns 2002 Voice Mail Pilot: Voice mail profile on address A is configured to point to pilot 2001 Voice mail profile on A is changed to point to to pilot 2002 B.getAsciiLabel( null) returns “asciiB” B.getUnicodeLabel(null) returns “unicodeB” B.getAsciiLabel( TermB) returns “asciiB” B.getUnicodeLabel(TermB) returns “unicodeB” B.getAsciiLabel( TermC) – throws Exception Labels: Address B on TermB is configured with ascii label = assciB and unicode label unicodeB. TermC.getIPV4Address() returns a valid InetAddress TermC.getIPV6Address() returns null TermD.getIPV6Address() returns a valid InetAddress TermE.getIPV4Address() returns a valid InetAddress TermE.getIPV6Address() returns a valid InetAddress IP Address TermC is registered in IPV4 mode only TermD is registered in IPV6 mode only TermE is registered in dual mode Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1240 Message Sequence Charts Terminal and Address Capability Settings Use Cases

Page 1304 diagram

Page 1305

Expected behavior Call Scenario TermF.canDirectTransferAcrossLines(CiscoTerminal .APPLICATION) returns true; TermF.canDirectTransferAcrossLines(CiscoTerminal .PHONE_USER) returns true; TermG.canDirectTransferAcrossLines(CiscoTerminal .APPLICATION) returns false; TermG.canDirectTransferAcrossLines(CiscoTerminal .PHONE_USER) returns false; TermH.canDirectTransferAcrossLines(CiscoTerminal .APPLICATION) returns true; TermH.canDirectTransferAcrossLines(CiscoTerminal .PHONE_USER) returns false; TermI. canJoinAcrossLines (CiscoTerminal .APPLICATION) returns true; TermI. canJoinAcrossLines (CiscoTerminal .PHONE_USER) returns true; TermJ canJ ConsultCallRollOver (CiscoTerminal .APPLICATION) returns false; TermJ can ConsultCallRollOver (CiscoTerminal .PHONE_USER) returns false; Features: DTAL: TermF is Cisco Unified IP Phone model 7970 TermG is a CiscoRouteTerminal TermH is a CiscoMediaTerminal Join Across Lines: TermI has join across lines option enabled ConsultCallRollOver: TermJ is Cisco Unified IP Phone model 6921 Provider Observer will get CiscoProvTermialUnRegisteredEv – getTerminal() returns Term1. Term1.isRegistered() returns false. Provider has term1 and term2 in control list and both are registered to CUCM Application gets provider and registers for the register and unregister events. Provider.registerFeature(CiscoProvFeatureID. TERMINAL_REGISTER_UNREGISTER_EVENT_NOTIFY Term1 unregisters CiscoProvTermialRegisteredEv – getTerminal() returns Term1. Term1.isRegistered() returns true. Term1 registers TermK.getRollOverConfig() returns CiscoTerminal.ROLLOVER_ANY_DN. TermL.getRollOverConfig() returnd CiscoTerminal.NO_ROLLOVER. Roll Over: TermK is Cisco Unified IP Phone model 7931 configured with rollover to any line. TermL is Cisco Unified IP Phone model 7940 All of the following use cases use the same basic configuration, unless specifically noted in the use case itsellf: Pickup group1: N:P1 ( pickup group number = N, partition = P1) Pickup group2: M:P1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1241 Message Sequence Charts Message Sequence Charts

Page 1305 diagram

Page 1306

A, B and C are defined to be in pickup group1 D, E, and F are defined to be in pickup group2 Pickup group2 is subgroup for pickup group1 The following scenarios are basic use cases for the new Call Pickup APIs, and do not require an enumerated event list because of their simplicity. After these, two Call Pickup use cases will be presented so that you can see the new events in place. Interested parties should refer to the Unison JTAPI Interface Specification (EDCS-614242) for the full set of Pickup Use Cases. The Use Cases in that document will not have the new event, but after reading these use cases it should be readily apparent where they belong in the existing use cases. Result Action Scenario API returns N and P1 respectively Application opens provider and issues CiscoAddress.getPickupGroupDN() and CiscoAddress.getPickupGroupPartition() at C JTAPI Application is observing C API returns FALSE Application opens provider and issues Provider.getCapabilities() and then calls API CiscoProviderCapabilities.canAutoPickup() Cisco UCM service parameter AutoCallPickupEnabled is set to false. API returns TRUE Application issues Provider.getCapabilities() and then calls API CiscoProviderCapabilities.canAutoPickup() Cisco UCM service parameter AutoCallPickupEnabled is set to true. i) API returns FALSE ii). CiscoProviderCapabilityChangedEv is delivered iii). API returns TRUE Application opens provider and issues Provider.getCapabilities() and then calls API CiscoProviderCapabilities.canAutoPickup() ii). Now adminitrator sets AutoCallPickupEnabled service parameter to TRUE, iii). Application calls API CiscoProviderCapabilities.canAutoPickup() Cisco UCM service parameter AutoCallPickupEnabled is set to FALSE. i) Registration successful. ii). After Call Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). Unregistration successful. iv). No Events for pickup alert. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii). Application opens provider and issues provider.unregisterPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. iv). A calls B JTAPI Application is observing C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1242 Message Sequence Charts Message Sequence Charts

Page 1306 diagram

Page 1307

Result Action Scenario i) Registration successful. ii). After Call Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). A-B calls starts ringing at C. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii). Application issues CiscoTerminal.pickup(Address of C) at C JTAPI Application is observing C. Cisco UCM service parameter AutoCallPickupEnabled is set to FALSE. i) Registration successful. ii). After Call Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). A-B call is answered at C. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii). Application issues CiscoTerminal.pickup(Address of C) at C JTAPI Application is observing C. Cisco UCM service parameter AutoCallPickupEnabled is set to TRUE. i) Registration successful. ii). After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). A-B call starts ringing at D. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii). Application issues CiscoTerminal.groupPickup(Address of D, N) at D JTAPI Application is observing C and D Cisco UCM service parameter AutoCallPickupEnabled is set to FALSE. i) Registration successful. ii). After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). A-B call is answered at D. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii). Application issues CiscoTermina;.groupPickup(Address of D, N) at D JTAPI Application is observing C and D. Cisco UCM service parameter AutoCallPickupEnabled is set to TRUE. i) Registration successful. ii). After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). A-B call starts ringing at D. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii).Application issues CiscoTerminal.otherPickup(Address of D) at D JTAPI Application is observing C and D. Cisco UCM service parameter AutoCallPickupEnabled is set to FALSE. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1243 Message Sequence Charts Message Sequence Charts

Page 1307 diagram

Page 1308

Result Action Scenario i) Registration successful. ii). After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). A-B calls answered at D i)Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii). Application issues CiscoTerminal.otherPickup(Address of C) at D JTAPI Application is observing C and D. Cisco UCM service parameter AutoCallPickupEnabled is set to TRUE. i) Registration successful. ii). After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 CiscoProvPickupCallAlertEvent with calling E, Called C, pickup group number : N, pickup group partition: P1 iii). A-B calls answered at D. (Longest ringing call is picked up) i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B and then E calls C iii). Application issues CiscoTerminal.otherPickup(Address of D) at D JTAPI Application is observing C, D. Cisco UCM service parameter AutoCallPickupEnabled is set to TRUE. i) Registration successful. ii). After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). Application will get PlatformException with error CTIERR_NO_CALLS_TO_PICKUP. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii). A-B call goes IDLE. Then Application issues CiscoTerminal.pickup(Address of C) at C JTAPI Application is observing C, D. Cisco UCM service parameter AutoCallPickupEnabled is set to TRUE. i) Registration successful. ii). After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). Request successful, new call created, but call gets disconnected with reason NORMAL. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii). A-B call goes IDLE. Then Application issues CiscoTerminal.groupPickup(Address fo D, N) at D JTAPI Application is observing C, D. Cisco UCM service parameter AutoCallPickupEnabled is set to TRUE. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1244 Message Sequence Charts Message Sequence Charts

Page 1308 diagram

Page 1309

Result Action Scenario i) Registration successful. ii). After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). Application will get PlatformException with errorCTIERR_NO_CALLS_TO_PICKUPandcause NORMAL i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). A calls B iii). A-B call goes IDLE. Then Application issues CiscoTerminal.otherPickup(Address of D) at D JTAPI Application is observing C, D. Cisco UCM service parameter AutoCallPickupEnabled is set to TRUE. i) PlatformException thrown with error CTIERR_INVALID_GROUP_NUMBER and cause NORMAL i). Application opens provider and issues provider. registerPickupAlert(K, P1) to register for pickup alert notification for call pickup group K:P1, where K is not a valid group number JTAPI Application is observing C, D. i). Registration successful ii.) Registration blocked at the JTAPI layer, and a InvalidStateException is thrown to the application with error CTIERR_ALREADY_REGISTERED and description “Pickup Group already registerred / observed”. i). Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii). Application again issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. i). InvalidStateException thrown to application with error CTIERR_REGISTRATION_NOT_FOUND and description, “Pickup group is not registerred with this provider”. i). Application opens provider and issues provider.deregisterPickupAlert(N, P1) to deregister for pickup alert notification for call pickup group N:P1, which was not registerred for previously. i). Registration successful ii.) After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). A-B calls answered at J in P1. i). Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii.) A calls B. iii.) Application issues CiscoTerminal.pickup(Address of J in P1) at terminal of J in P1 JTAPI Application is observing J. Cisco UCM service parameter “AutoCallPickupEnabled” is set to true. J is an address in two partitions, P1 and P2. J belongs to the Pickup Group with number N. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1245 Message Sequence Charts Message Sequence Charts

Page 1309 diagram

Page 1310

Result Action Scenario i). Registration successful ii.) After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii). A-B calls answered at J in P2. i). Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii.) A calls B. iii.) Application issues CiscoTerminal.pickup(Address of J in P2) at terminal of J in P2 JTAPI Application is observing J. Cisco UCM service parameter “AutoCallPickupEnabled” is set to true. J is an address in two partitions, P1 and P2. J belongs to the Pickup Group with number N.. i). Registration successful ii.) After Calll Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii.) InvalidStateException thrown to application with error CTIERR_NO_CALLS_TO_PICKUPand description, “There are no calls to pickup”. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii.) A calls B. iii.) Application issues CiscoTerminal.groupPickup(Address of K in P3, N) at terminal of K in P3. JTAPI Application is observing K. Cisco UCM service parameter “AutoCallPickupEnabled” is set to true. K is an address in partition P3, and belongs to Pickup Group 3, in partiton P3. Pickup Group 3 has the same number as Pickup Group 1, N. CSS of K is configured to check P3:P1. i). Registration successful ii.) The JTAPI layer sense the failover and re-registers for the pickup groups that it was registers for (N, P1). i.) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii.) The CUCM crashes / goes offline, and CTI failsover to the the secondary CUCM server. i) Registration successful ii.) Application recieves a ProviderPickupNotificationRegistrationClosedEvent, with reason = CTIERR_PICKUPGROUP_CHANGED i.) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii.) An administrator logs into the CUCM Admin page and changes the DN for the Pickup Group.i). i.) Registration successful ii.) Application receives a CiscoProviderCapabilityChangedEv. CiscoProviderCapabilities. canAutoPickup() will be changed to reflect the new setting. i.) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii.) An administratior logs in to the CUCM Admin page and changes the “Auto Pickup Enabled” service parameter. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1246 Message Sequence Charts Message Sequence Charts

Page 1310 diagram

Page 1311

Result Action Scenario i) Registration successful ii.) After Call Pickup Group notification time, applications gets CiscoProvPickupCallAlertEvent with calling A, Called B, pickup group number : N, pickup group partition: P1 iii.) PlatformException is thrown with reason = CTIERR_TEMPORARY_FAILUREand description “Temporary Failure”. i) Application opens provider and issues provider. registerPickupAlert(N, P1) to register for pickup alert notification for call pickup group N:P1. ii.) A calls B iii.) Application issues CiscoTerminal.pickup(Address of J in P3) at terminal of J in P3. JTAPI Application is observing J. Cisco UCM service parameter “AutoCallPickupEnabled” is set to true. J is an address in partition P3. J belongs to the Pickup Group with number N, in P1. J’s CSS is not configured to check P1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1247 Message Sequence Charts Message Sequence Charts

Page 1311 diagram

Page 1312

Full-Event Use Case 1: (Observing All Devices): Auto-Pickup Disabled Call ID / Info Call event Action CCalling: A, CCalled: NONE Calling: A, Called: NONE CAUSE_NEW_CALL REASON_NORMAL LRP: NONE CCalling: A, CCalled: B Calling: A, Called: B Calling A, Called B, PUG Number N, PUG partition P1 CCalling C, CCalled: NONE LRP: NONE REASON_NORMAL GC1-CallActiveEvent-NONE GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv CiscoProvPickupCallAlertEvent GC2-CallActiveEvent GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv provider. registerPickupAlert(N, P1) A goes offhook and dials B (Basic Call) B is ringing … pause for Pickup Group’s delay Provider receives Pickup Alert Application invokes Terminal.pickup(Address of C) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1248 Message Sequence Charts Message Sequence Charts

Page 1312 diagram

Page 1313

Call ID / Info Call event Action REASON_CALLPICKUP CCalling A, CCalled: C Calling: A, Called: C, LRP: B REASON_CALLPICKUP CCalling A, CCalled: C Calling: A, Called: C, LRP: B REASON_CALLPICKUP REASON_NORMAL REASON_NORMAL GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B GC1-CallCtlConnDisconnectedEv-B GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv Call 2 gets dropped / invalidated C gets a connection on Call 1 B is dropped from Call 1 C is ringing C is on call with A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1249 Message Sequence Charts Message Sequence Charts

Page 1313 diagram

Page 1314

Full-Event Use Case 2 (Observing All Devices): Auto-Pickup Enabled Call info (GCID: Info) Events Actions CCalling: A, CCalled: NONE Calling: A, Called: NONE CAUSE_NEW_CALL REASON_NORMAL LRP: NONE CCalling: A, CCalled: B Calling: A, Called: B Calling A, Called B, PUG Number N, PUG partition P1 CCalling: C, CCalled: NONE CAUSE_NEW_CALL REASON_NORMAL LRP: NONE GC1-CallActiveEvent-NONE GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv CiscoProvPickupCallAlertEvent GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv provider. registerPickupAlert(N, P1) A goes offhook and dials B (Basic Call) B is ringing … pause for Pickup Group’s delay Provider recieves Pickup Alert C invokes Terminal.pickup(Address of C) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1250 Message Sequence Charts Message Sequence Charts

Page 1314 diagram

Page 1315

Call info (GCID: Info) Events Actions REASON_CALLPICKUP CCalling: A, CCalled: C LRP: NONE REASON_CALLPICKUP CCalling: C, CCalled: NONE LRP: NONE REASON_NORMAL REASON_CALLPICKUP CCalling: A, CCalled: C LRP: B REASON_NORMAL GC2-CiscoCallChangedEv GC1-ConnCreatedEvent-C GC1-ConnConnectedEvent-C GC1-CallCtlConnInitiatedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B GC1-CallCtlConnDisconnectedEv-B GC1-CallCtlConnEstablishedEv-C Old Conn for C is dropped B is dropped / cleaned up C’s connection on Call 1 is established Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1251 Message Sequence Charts Message Sequence Charts

Page 1315 diagram

Page 1316

Full-Event Use Case 3 (Observing All Devices): Group Pickup, Auto-Pickup Enabled Call Id/Info Call event Action Calling A, Called B, PUG Number N, PUG partition P1 CCalling: C, CCalled: NONE LRP: NONE REASON_NORMAL CCalling: C, CCalled: NONE REASON_CALLPICKUP CCalling: C, CCalled: PU, LRP: PU CCalling C, CCalled: PU CCalling: A, CCalled: C, LRP: B Calling: A, Called: B REASON_CALLPICKUP CCalling: A, CCalled: C, LRP:B CiscoProvPickupCallAlertEvent GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-C GC2-ConnCreatedEvent-PU GC2-ConnInprogressEvent-PU GC2-CallCtlConnEstablishedEv-C GC2-CiscoCallChangedEv GC1-ConnCreatedEvent-C GC1-ConnCreatedEvent-PU GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-ConnInprogressEvent-PU GC1-CallCtlConnOfferedEv-PU provider. registerPickupAlert(N, P1) [Basic call happens, see case 1] … pause for Pickup Group’s delay Provider receives Pickup Alert Application invokes groupPickup(Address of C, N) C is dialing the PU Number C is added to the original call Pickup added to original call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1252 Message Sequence Charts Message Sequence Charts

Page 1316 diagram

Page 1317

Call Id/Info Call event Action REASON_CALLPICKUP, LRP: PU CCalling: C, CCalled: PU REASON_CALLPICKUP CCalling: A, CCalled C, LRP: B REASON_CALLPICKUP CCalling: A, CCalled C, LRP: B REASON_CALLPICKUP GC2-ConnDisconnectedEvent-PU GC2-CallCtlConnDisconnectedEv-PU GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-ConnDisconnectedEvent-PU GC1-CallCtlConnDisconnectedEv-PU GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent-B GC1-CallCtlConnDisconnectedEv-B Pickup # is removed Call 2 C is dropped from Call 2 Pickup # is removed Call 1 B is dropped / invalidated As you can see, there are only a handful of changes for this Group Pickup case, and they all directly relate to the extra required step of dialing the Pickup Number. A similar test was run with Auto-Pickup disabled: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1253 Message Sequence Charts Message Sequence Charts

Page 1317 diagram

Page 1318

Full-Event Use Case 4 (Observing All Devices): Group Pickup, Auto-Pickup Disabled Call info Events Action Calling A, Called B, PUG Number N, PUG partition P1 CCalling: C, CCalled: NO, NO LRP REASON_NORMAL CCalling: C, CCalled: NO, NO LRP REASON_NORMAL CCalling: C, CCalled: PU CCalling: C, CCalled: PU, LRP: PU REASON_CALLPICKUP CiscoProvPickupCallAlertEvent GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-C GC2-ConnCreatedEvent-PU GC2-ConnInprogressEvent-PU GC2-CallCtlConnEstablishedEv-C GC2-ConnDisconnectedEvent-PU GC2-CallCtlConnDisconnectedEv-PU GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv provider. registerPickupAlert(N, P1) [Basic call happens, see Case 1] … pause for Pickup Group’s delay Provider receives Pickup Alert Application invokes directedPickup(Address of C, N) at Terminal for C C is dialing the PU number PU is removed from Call 2 C is removed from Call 2 Call 2 is destroyed Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1254 Message Sequence Charts Message Sequence Charts

Page 1318 diagram

Page 1319

Call info Events Action CCalling: A, CCalled: C, LRP: B Calling: A, Called: B REASON_CALLPICKUP CCalling: A, CCalled: C, LRP: B REASON_CALLPICKUP REASON_NORMAL CCalling: A, CCalled: C, LRP: B REASON_NORMAL GC1-ConnCreatedEvent[ADDRS] GC1-ConnInprogressEvent GC1-CallCtlConnOfferedEv GC1-TermConnDroppedEv GC1-CallCtlTermConnDroppedEv GC1-ConnDisconnectedEvent GC1-CallCtlConnDisconnectedEv GC1-ConnAlertingEvent GC1-CallCtlConnAlertingEv GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnConnectedEvent GC1-CallCtlConnEstablishedEv GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C gets a connection on Call 1 B is dropped from Call 1 C is ringing C picks up Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1255 Message Sequence Charts Message Sequence Charts

Page 1319 diagram

Page 1320

Observing Only Device C: Auto-Pickup Enabled Call IDs/ Call info Call events Actions Calling A, Called B, PUG Number N, PUG partition P1 CCalling: C, CCalled: NO, NO LRP REASON_NORMAL REAON_CALLPICKUP CCalling A, CCalled: NONE LRP: NONE CCalling: A, CCalled: C, LRP: B REASON_CALLPICKUP CCalling: C, CCalled: NONE REASON_CALLPICKUP REASON_CALLPICKUP CCalling A, CCalled: C, LRP: B REASON_CALLPICKUP REASON_NORMAL CiscoProvPickupCallAlertEvent GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CiscoCallChangedEv GC1-CallActiveEvent-NONE GC1-ConnCreatedEvent-C GC1-ConnConnectedEvent-C GC1-CallCtlConnInitiatedEv GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnEstablishedEv-A GC1-CallCtlConnEstablishedEv-C provider. registerPickupAlert(N, P1) Provider receives Pickup Alert Application invokes pickup(Address of C) at Terminal for C C is connected to Call 1 C is dropped from Call 2 Call 2 is invalidated / cleared A and C are connected on Call 1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1256 Message Sequence Charts Message Sequence Charts

Page 1320 diagram

Page 1321

Observing Only Device C: Auto-Pickup Disabled Call events\ Call info Events Actions Calling A, Called B, PUG Number N, PUG partition P1 CCalling: C, CCalled: NO, NO LRP REASON_NORMAL REASON_CALLPICKUP CCalling: C, CCalled: NONE REASON_NORMAL CCalling: A, CCalled: C, LRP: B REASON_CALLPICKUP CiscoProvPickupCallAlertEvent GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-CallActiveEvent GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnEstablishedEv-A provider. registerPickupAlert(N, P1) Provider receives Pickup Alert Application invokes pickup(Address of C) at Terminal for C Call 2 is destroyed C is added to Call 1, but does not pick up REASON_NORMAL GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv C is ringing CCalling: A, CCalled: C, LRP: B REASON_NORMAL GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C picks up, and is connected to Call 1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1257 Message Sequence Charts Message Sequence Charts

Page 1321 diagram

Page 1322

Observing Only Device C: Group Pickup, Auto-Pickup Enabled Call ID/ Call info Call event Actions Calling A, Called B, PUG Number N, PUG partition P1 CCalling: C, CCalled: NO, NO LRP REASON_NORMAL CCalling: C, CCalled: PU CCalling: C, CCalled: PU, LRP: PU REASON_CALLPICKUP REASON_NORMAL REASON_CALLPICKUP CCalling: A, C Called: C CCalling: A, CCalled: C, LRP: B Calling: A, Called: B REASON_CALLPICKUP CiscoProvPickupCallAlertEvent GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-C GC2-ConnCreatedEvent-PU GC2-ConnInprogressEvent-PU GC2-CallCtlConnEstablishedEv-C GC2-CiscoCallChangedEv GC1-CallActiveEvent GC1-ConnCreatedEvent-C GC1-ConnCreatedEvent-PU GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-ConnInprogressEvent-PU GC1-CallCtlConnOfferedEv-PU provider. registerPickupAlert(N, P1) Provider receives Pickup Alert Application invokes directedPickup(Address of C, N) at Terminal for C C dials the Pickup Number C is added to Call 1 PU is added to Call 1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1258 Message Sequence Charts Message Sequence Charts

Page 1322 diagram

Page 1323

Call ID/ Call info Call event Actions CCalling C, CCalled: PU, LRP: PU REASON_CALLPICKUP CCalling C, CCalled: PU, LRP: PU REASON_CALLPICKUP REASON_NORMAL CCalling: A, CCalled: C REASON_CALLPICKUP CCalling: A, CCalled: C REASON_CALLPICKUP GC2-ConnDisconnectedEvent-PUv GC2-CallCtlTermConnDroppedEvvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC2-CallObservationEnde GC2-ConnDisconnectedE GC2-CallCtlConnDisconnectedEv-PU GC2-TermConnDroppedEdEv GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-PU GC1-CallCtlConnEstablishedEv-PU GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-ConnDisconnectedEvent-PU GC1-CallCtlConnDisconnectedEv-PU PU # is removed from Call 2 C is removed from Call 2 Call 2 I invalidated / cleared C is connected to Call 1 PU is removed from Call 1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1259 Message Sequence Charts Message Sequence Charts

Page 1323 diagram

Page 1324

Observing Only Device C: Group Pickup, Auto-Pickup Disable Call ID/ Call info Call event Actions Calling A, Called B, PUG Number N, PUG partition P1 CCalling: C, CCalled: NO, NO LRP REASON_NORMAL CCalling: C, CCalled: PU, LRP: PU REASON_CALLPICKUP REASON_NORMAL REASON_CALLPICKUP REASON_CALLPICKUP REASON_NOTMAL CCalling: A, CCalled: C, LRP: B REASON_CALLPICKUP CiscoProvPickupCallAlertEvent GC2-CallActiveEvent-NONE GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-CallCtlConnDialingEv-C GC2-ConnCreatedEvent-PU GC2-ConnInprogressEvent-PU GC2-CallCtlConnEstablishedEv-C GC2-ConnDisconnectedEvent-PU GC2-CallCtlConnDisconnectedEv-PU GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent-C GC2-CallCtlConnDisconnectedEv-C GC2-CallInvalidEvent GC1-CallObservationEndedEv GC1-CallActiveEvent GC1-ConnCreatedEvent-C GC1-ConnInprogressEvent-C GC1-CallCtlConnOfferedEv-C GC1-ConnCreatedEvent-A provider. registerPickupAlert(N, P1) Provider receives Pickup Alert Application invokes directedPickup(Address of C, N) at Terminal for C C dials the PU Number PU is dropped from Call 2 C is dropped from from Call 2 Call 2 is destroyed C is added to Call 1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1260 Message Sequence Charts Message Sequence Charts

Page 1324 diagram

Page 1325

Call ID/ Call info Call event Actions REASON_NORMAL GC1-ConnConnectedEvent-A GC1-CallCtlConnEstablishedEv-A GC1-ConnAlertingEvent-C GC1-CallCtlConnAlertingEv-C GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnConnectedEvent-C GC1-CallCtlConnEstablishedEv-C GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv C is ringing C is connected to A Invoking Pickup on a Ringing Shared Line (CSCsy30964) This is an odd scenario that normal applications will probably not see. A calls a shared line DN (B), that has SLT1 and SLT2 on it. B is in pickup group N, P1. B and B’ ring, and instead of invoking answer(), the application invokes pickup() on B’. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1261 Message Sequence Charts Message Sequence Charts

Page 1325 diagram

Page 1326

Call ID/Info Call event Action CCalling: A, CCalled: NONE Calling: A, Called: NONE CAUSE_NEW_CALL REASON_NORMAL LRP: NONE CCalling: A, CCalled: B Calling: A, Called: B GC1-CallActiveEvent-NONE GC1-ConnCreatedEvent-A GC1-ConnConnectedEvent-A GC1-CallCtlConnInitiatedEv-A GC1-TermConnCreatedEvent GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv GC1-CallCtlConnDialingEv-A GC1-CallCtlConnEstablishedEv-A GC1-ConnCreatedEvent-B GC1-ConnInprogressEvent-B GC1-CallCtlConnOfferedEv-B GC1-ConnAlertingEvent-B GC1-CallCtlConnAlertingEv GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1-CallCtlTermConnRingingEv GC1-ConnInprogressEvent GC1-ConnAlertingEvent GC1-TermConnCreatedEvent GC1-TermConnRingingEvent GC1- CallCtlTermConnRingingEv provider. registerPickupAlert(N, P1) A goes offhook and dials B (Basic Call) B is ringing on both shared lines Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1262 Message Sequence Charts Message Sequence Charts

Page 1326 diagram

Page 1327

Call ID/Info Call event Action Calling A, Called B, PUG Number N, PUG partition P1 CCalling C, CCalled: NONE LRP: NONE REASON_NORMAL CCalling A, CCalled: B Calling: A, Called: B, LRP: B REASON_CALLPICKUP CiscoProvPickupCallAlertEvent GC2-CallActiveEvent GC2-ConnCreatedEvent-C GC2-ConnConnectedEvent-C GC2-CallCtlConnInitiatedEv-C GC2-TermConnCreatedEvent GC2-TermConnActiveEvent GC2-CallCtlTermConnTalkingEv GC2-TermConnCreatedEvent GC2- TermConnPassiveEvent GC2-CallCtlTermConnInUseEv GC2-CiscoCallChangedEv GC1-ConnConnectedEvent GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-CiscoCallChangedEv GC2-TermConnDroppedEv GC2-CallCtlTermConnDroppedEv GC2-ConnDisconnectedEvent GC2-CallCtlConnDisconnectedEv GC2-CallInvalidEvent GC2-CallObservationEndedEv GC1-TermConnPassiveEvent GC1-CallCtlTermConnBridgedEv GC1-CallCtlConnEstablishedEv GC1-CallCtlTermConnInUseEv GC1-TermConnActiveEvent GC1-CallCtlTermConnTalkingEv … pause for Pickup Group’s delay Provider receives Pickup Alert Application invokes Terminal.pickup(Address of B) on Terminal of SLT2 Shared line gets a connection on GC1 GC2 gets cleaned up SLT1 on Call 1 goes passive/bridged SLT2 on Call2 goes active SLT2 is talking Media Termination at Route Point The following diagrams illustrate the message flows for Media Termination at Route Point. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1263 Message Sequence Charts Media Termination at Route Point

Page 1327 diagram

Page 1328

Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1264 Message Sequence Charts Message Sequence Charts

Image 1 from page 1328

Page 1328 content

Page 1329

Mobility Interaction Support Pre-conditions to mobility interaction use cases, unless specified otherwise: • Provider is in IN_SERVICE state • All addresses and terminals are already in service. • Enable "Route calls to all remote destinations" checkbox for CTIRD1 and CTIRD3. • CTIRD1 associated to user "Mobility1", dn = 2303 • Remote destination 1 (Name: "C1_CTIRD1_RDD3", Number: "339007") • CTIRD3 associated to user "Mobility3", dn = 9202 • Remote destination 1 (Name: "C1_CTIRD3_RDD1", Number: "339006") • RDP1 associated to user "Mobility1", dn = 2303 • Remote destination 1 (Name: "C1_CTIRD1_RDP1", Number: "334007") • RDP3 associated to user "Mobility3", dn = 9202 • Remote destination 1 (Name: "C1_CTIRD3_RDP1", Number: "334003") • Remote destination 2 (Name: "C1_CTIRD3_RDD1", Number: "339006") • Device A (IP Phone - Name: "SEP2401C7824EA3", Line A1 (dn: 9000)) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1265 Message Sequence Charts Mobility Interaction Support

Image 1 from page 1329

Page 1329 content

Page 1330

• User1 has in its control list: Device A, CTIRD1 and CTIRD3. All devices and lines are observed. Table 280: Call to CTI RD When App Not Active with Unique RD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitiatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 2303 GC1: ConnInProgressEv 2303 GC1: CallCtlConnOfferedEv 2303 GC1: ConnAlertingEv 2303 GC1: CallCtlConnAlertingEv 2303 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 *Call is offered to the remote destination of RDP1 after delay. Call is not offered to CTIRD1 or to the remote destination of CTIRD1 (dn = 9007). A1 calls CTIRD1 in which active rd is not set. User1 invokes Call.connect("SEP2401C7824EA3", "9000", "2303"). Call is answered at the RD of RDP1 (dn = 4007). Table 281: Call to CTI RD When App Active with Unique RD with Answer on RD of RDP Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1266 Message Sequence Charts Message Sequence Charts

Page 1330 diagram

Page 1331

Call Info Events Action CiscoRemoteTerminal. getActiveRemoteDestinations()

CiscoRemoteDestinationInfo[1]. CiscoRemoteDestinationInfo[0]. getRemoteDestinationNumber() = "339007" CiscoRemoteDestinationInfo[0]. getIsActiveRD() = true. CiscoProvTerminalRemoteDestinationChangedEv App sets active rd of CTIRD1 to be 339007. User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("339007", true). GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitiatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 2303 GC1: ConnInProgressEv 2303 GC1: CallCtlConnOfferedEv 2303 GC1: ConnAlertingEv 2303 GC1: CallCtlConnAlertingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnRingingEv CTIRD1 A1 calls CTIRD1 in which active rd is set. User1 invokes Call.connect("SEP2401C7824EA3", "9000", "2303"). GC1: CallCtlTermConnRingingEv CTIRD1 *Call is offered to CTIRD1 and to the RD of CTIRD1 without delay. Call is offered to RD of RDP1 after delay. GC1: TermConnDroppedEv CTIRD1 GC1: CallCtlTermConnDroppedEv CTIRD1 Call is answered at the RD of RDP1 (dn = 4007). Table 282: Call to CTI RD When App Active with Unique RD with Answer on RD of CTI RD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1267 Message Sequence Charts Message Sequence Charts

Page 1331 diagram

Page 1332

Call Info Events Action CiscoRemoteTerminal. getActiveRemoteDestinations()

CiscoRemoteDestinationInfo[1]. CiscoRemoteDestinationInfo[0]. getRemoteDestinationNumber() = "339007" CiscoRemoteDestinationInfo[0]. getIsActiveRD() = true. CiscoProvTerminalRemoteDestinationChangedEv App sets active rd of CTIRD1 to be 339007. User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("339007", true). GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitiatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 2303 GC1: ConnInProgressEv 2303 GC1: CallCtlConnOfferedEv 2303 GC1: ConnAlertingEv 2303 GC1: CallCtlConnAlertingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnRingingEv CTIRD1 GC1: CallCtlTermConnRingingEv CTIRD1 *Call is offered to CTIRD1 and to the RD of CTIRD1 without delay. Call is offered to RD of RDP1 after delay. A1 calls CTIRD1 in which active rd is set. User1 invokes Call.connect("SEP2401C7824EA3", "9000", "2303"). GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 Call is answered at the RD of CTIRD1 (dn = 9007). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1268 Message Sequence Charts Message Sequence Charts

Page 1332 diagram

Page 1333

Table 283: Call to CTI RD When App Not Active with Shared and Unique RD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitiatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 *Call is offered to the remote destination of RDP3 after delay. Since 339006 is shared between CTIRD3 and RDP3, call is only seen at 339006 after delay. A1 calls CTIRD3 in which active rd is not set. User1 invokes Call.connect("SEP2401C7824EA3", "9000", "9202"). Call is answered at the RD of RDP3 (dn = 4003). Table 284: Call to CTI RD When App Active with Shared and Unique RD with Answer on RD of CTI RD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoRemoteTerminal. getActiveRemoteDestinations()

Page 1333 diagram

Page 1334

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitiatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEv CTIRD3 *Call is offered to CTIRD3 and to the RD of CTIRD3 (which is shared with RDP3) without delay. Call is offered to the unique RD of RDP3 after delay. A1 calls CTIRD3 in which active rd is set. User1 invokes Call.connect("SEP2401C7824EA3", "9000", "9202"). GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 Call is answered at the RD of CTIRD3 (dn = 9006). This is the RD that is shared between CTIRD3 and RDP3. Table 285: Call to CTI RD When App Active with Shared and Unique RD with Answer on RD of RDP Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1270 Message Sequence Charts Message Sequence Charts

Page 1334 diagram

Page 1335

Call Info Events Action CiscoRemoteTerminal. getActiveRemoteDestinations()

CiscoRemoteDestinationInfo[1]. CiscoRemoteDestinationInfo[0]. getRemoteDestinationNumber() = "339006" CiscoRemoteDestinationInfo[0]. getIsActiveRD() = true. CiscoProvTerminalRemoteDestinationChangedEv App sets active rd of CTIRD3 to be 339006. User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("339006", true). GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitiatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEv CTIRD3 *Call is offered to CTIRD3 and to the RD of CTIRD3 (which is shared with RDP3) without delay. Call is offered to the unique RD of RDP3 after delay. A1 calls CTIRD3 in which active rd is set. User1 invokes Call.connect("SEP2401C7824EA3", "9000", "9202"). GC1: TermConnDroppedEv CTIRD3 GC1: CallCtlTermConnDroppedEv CTIRD3 Call is answered at the RD of RDP3 (dn = 4003). Modifying Calling Number The following scenario illustrates the message flows for Modifying Calling Number. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1271 Message Sequence Charts Modifying Calling Number

Page 1335 diagram

Page 1336

Scenario One The application controls the device Route Point (RP) and registers RP . A and B are PNO and appear within the Cisco Unified Communications Manager cluster. A calls RP. Call arrives at RP Fields Event Action State = ROUTE getCurrentRouteAddress () = RP getCallingAddress () = A getCallingTerminal () = SEPA (Terminal associated with A) RouteEvent Call Arrives at RP State = ROUTE_USED getCallingAddress () = A getCallingTerminal () = SEPA (Terminal associated with A) getRouteUsed () = C RouteUsedEvent Application invokes selectRoute( routeselected[], callingsearchspace, modifiyingcallingnumber[] ) where routeSelected[] = C callingSearchSpace = CiscoRouteSession.DEFAULT_SEARCH_SPACE State = ROUTE_END getRouteAddress () = RP RouteEndEvent Application invokes endRoute (ERROR_NONE) Scenario Two The application is controls A and B. A calls RP, which selects Route call to B with modified calling number as M. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1272 Message Sequence Charts Message Sequence Charts

Page 1336 diagram

Page 1337

Fields Event Action getCallingAddress() = A getCalledAddress() = getLastRedirectedAddress () = getCurrentCallingAddress () = A getCurrentCalledAddress() = getModifiedCallingAddress() = A getModifiedCalledAddress() = getCallingAddress() = A getCalledAddress() = getLastRedirectedAddress () = getCurrentCallingAddress () = A getCurrentCalledAddress() = getModifiedCallingAddress() = A getModifiedCalledAddress() = getCallingAddress() = A getCalledAddress() = B getLastRedirectedAddress () = getCurrentCallingAddress () = A getCurrentCalledAddress() = B getModifiedCallingAddress() = A getModifiedCalledAddress() = B NEW META EVENT_________META_CALL_STARTING CallActiveEv Cause: CAUSE_NEW_CALL ConnCreatedEv A Cause: CAUSE_NORMAL ConnConnectedEv A Cause: CAUSE_NORMAL CallCtlConnInitiatedEv Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL TermConnCreatedEv SEPA Cause: Other: 0 TermConnActiveEv SEPA Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv SEPA Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL NEW META EVENT_________META_CALL_PROGRESS CallCtlConnDialingEv A NEW META EVENT_________META_CALL_PROGRESS CallCtlConnEstablishedEv A ConnCreatedEv RP ConnInProgressEv RP CallCtlConnOfferedEv RP A calls RP, which is not in controlled list. getCallingAddress() = A getCalledAddress() = B getLastRedirectedAddress () = RP getCurrentCallingAddress () = A getCurrentCalledAddress() = B getModifiedCallingAddress() = M getModifiedCalledAddress() = B getCallingAddress() = A getCalledAddress() = B getLastRedirectedAddress () = RP getCurrentCallingAddress () = A getCurrentCalledAddress() = B getModifiedCallingAddress() = M getModifiedCalledAddress() = B NEW META EVENT_________ META_CALL_ADDITIONAL_PARTY ConnCreatedEv B ConnInProgressEv B CallCtlConnOfferedEv B ConnDisconnectedEv RP CallCtlConnDisconnectedEv RP NEW META EVENT_________ META_CALL_PROGRESS ConnAlertingEv B CallCtlConnAlertingEv B TermConnCreatedEv B TermConnRingingEv B CallCtlTermConnRingingEv B Another application controls the RP selectRoute to B with modifying calling number as M. getCallingAddress() = A getCalledAddress() = B getLastRedirectedAddress () = RP getCurrentCallingAddress () = A getCurrentCalledAddress() = B getModifiedCallingAddress() = M getModifiedCalledAddress() = B ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv B CallCtlTermConnTalkingEv B B answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1273 Message Sequence Charts Message Sequence Charts

Page 1337 diagram

Page 1338

AutoAccept for CTIPort and RoutePoint Silent Monitoring Use Cases A and TA are address and terminal of monitor target or recording initiator B and TB are address and terminal of monitor initiator. Scenario One Administrator enables monitoring capability for the user. Call info Events Action NA CiscoProviderCapabilityChangedEv hasMonitorCapabilityChanged() on this event returns true hasRecordingCapabilityChanged() returns true NA JTAPI returns true ciscoProvider.getCapabilities().canMonitor() Scenario Two Start and Stop monitor: A is monitor target, B is monitor initiator. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2. Application has call observer on both A and B. Application has monitoring capability enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1274 Message Sequence Charts AutoAccept for CTIPort and RoutePoint

Image 1 from page 1338

Page 1338 diagram

Page 1339

Call info Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called: A GC2: Calling: B Called: A LRP: null Current calling: B Current called: A CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL GC1: ConnConnectedEv X … GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv CiscoRTPInputStartedEv GC2:CallActive Cause: CAUSE_NORMAL GC2: GC1:ConnConnectedEv for B Cause: CAUSE_NORMAL GC2: CallCtlTermConnTalkingEv TB GC2: ConnCreatedEv A (No terminal connection for A or GC2) GC2: ConnConnectedEv A GC2:CiscoTermConnMonitorTargetInfoEv Cause: CAUSE_NORMAL address:A, terminal name: TA, rtphandle = CI1 GC1: CiscoTermConnMonitorStartEv TA GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_NORMAL address:B, device name: TB A answers GC1 B calls start monitor using GC2 giving CI1, A and TermA from GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1275 Message Sequence Charts Message Sequence Charts

Page 1339 diagram

Page 1340

Call info Events Action GC2: CiscoRTPOutputStoppedEv GC1: CiscoRTPOutputStoppedEv GC1: CallCtlTermConnHeldEv TA GC2:CiscoRTPInputStoppedEv GC1: CiscoRTPInputStoppedEv GC1: CiscoRTPOutputStartedEv GC2: CiscoRTPOutputStartedEv GC1: CallCtlTermConnTalking TA GC2:CiscoRTPInputStartedEv GC1: CiscoRTPInputStartedEv GC2: CallCtlTermConnDroppedEv TB GC2: ConnDisconnEv A GC1: CiscoTermConnMonitorEndEv TA GC2: ConnDisconnEv B GC2: CallInvalidEv A puts the call on hold A resumes the call B calls drop on GC2 to stop monitoring Scenario Three Monitor initiator transfers the call to Y. A is monitor target, B is monitor initiator. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2. Application has call observer on both A and B. application has monitoring capability enabled. B transfers the call to Y. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1276 Message Sequence Charts Message Sequence Charts

Page 1340 diagram

Page 1341

Call info Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called: A CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL GC1: ConnConnectedEv X … GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv CiscoRTPInputStartedEv GC2:CallActive Cause: CAUSE_NORMAL GC2: ConnConnectedEv for B Cause: CAUSE_NORMAL GC2: CallCtlTermConnTalkingEv TB GC2: ConnCreatedEv A (No terminal connection for A or GC2) GC2: ConnConnectedEv A GC2:CiscoTermConnMonitorTargetInfoEv Cause: CAUSE_NORMAL Monitor_TARGET address:A, device name: TA, rtphandle = CI1 GC1: CiscoTermConnMonitorStartEv TA GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_NORMAL address:B, device name: TB rtphandle = ci2 A answers GC1 B calls start monitor using GC2 and ci2 giving CI1, A and TermA from GC1 Or using the teminalconnection of A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1277 Message Sequence Charts Message Sequence Charts

Page 1341 diagram

Page 1342

Call info Events Action GC1: Calling: X Called: A LRP: A Current calling: X Current called: Y GC3: CallActiveEv GC3: ConnConnectedEv B GC3: CallCtlTermConnTalkingEv TB GC3: ConnConnectedEv Y CiscoTransferStartEv(GC3->GC2) GC3: ConnDisconnectedEv Y GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_NORMAL address:Y, device name: TY GC3: ConnDisconnectedEv B GC3: CallCtlTermConnDroppedEv TB GC3: CallInvalidEv GC2: CallCtlTermConnDroppedEv TB …. GC2: CallInvalidEv CiscoTransferEndEv GC3: CallActive GC3: CallCtlTermConnRingingEv TY GC3: CallCtlTermConnTalkingEv TY CiscoTransferStartEv CiscoCallChangedEv GC3->GC2 GC2: ConnConnectedEv Y GC2: ConnConnectedEv B GC2: CiscoTermConnMonitorTargetInfoEv TY Cause: CAUSE_NORMAL address:A, device name: TA GC3: ConnDisconnectedEv Y GC3: CallCtlTermConnDroppedEv TY GC3: CallInvalidEV GC2: ConnConnectedEv X GC2: ConnDisconnectedEv A CiscoTransferEndEv (CiscoTermConnMonitorInitiatorInfoEv on GC1 is independent of transfer events on GC3 and GC2 and can be delivered at any time before or after end event.) B consults Y using GC3 and completes transfer. Call observer on Y would see Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1278 Message Sequence Charts Message Sequence Charts

Page 1342 diagram

Page 1343

Scenario Four Monitoring a barged call: A and A’ are shared lines. Caller calls A, A answers the call. A’ barge into the call. B calls start monitor. Call info Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called: A CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL GC1: ConnConnectedEv X … GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv CiscoRTPInputStartedEv GC1: CallCtlTermConnBridgedEv TermA’ GC1: GC1:CallCrlTermConnTalkingEv TA’ Exception is thrown to startMonitor request. A answers GC1 A’ barges the call B calls start monitor using GC2 giving CI1, A and TermA from GC1 Scenario Five Monitor and recording: A is monitor target and has auto recording configured. B is monitor initiator. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2. Application has call observer on both A and B. Application has monitoring capability enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1279 Message Sequence Charts Message Sequence Charts

Page 1343 diagram

Page 1344

Call info Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called: A CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL GC1: ConnConnectedEv X … GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv GC1: CiscoTermConnRecordingStartEv TA GC1: CiscoTermConnRecordingTargetInfoEv TA CiscoRTPInputStartedEv GC2:CallActive Cause: CAUSE_NORMAL GC2: GC1:ConnConnectedEv for B Cause: CAUSE_NORMAL GC2: CallCtlTermConnTalkingEv TB GC2: ConnCreatedEv A (No terminal connection for A on GC2) GC2: ConnConnectedEv A GC2:CiscoTermConnMonitorTargetInfoEv Cause: CAUSE_NORMAL address:A, device name: TA, rtphandle = CI1 GC1: CiscoTermConnMonitorStartEv TA GC1: CiscoTermConnMonitorTargetInfoEv TA Cause: CAUSE_NORMAL address:B, device name: TB A answers GC1 B calls start monitor using GC2 giving CI1, A and TermA from GC1 Scenario Six Observing remote in use shared line in Monitoring: A and A’ are shared lines. Caller calls A, A answers the call. B calls start monitor. Application has call observer on A’ only. B initiates monitor request for connected call on A. No start events are delivered to call observer of A’. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1280 Message Sequence Charts Message Sequence Charts

Page 1344 diagram

Page 1345

Call info Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called: A CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A’ Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A’ Cause: CAUSE_NORMAL GC1: ConnConnectedEv X … GC1:CallCrlTermConnRingingEv TA’ Cause: CAUSE_NORMAL GC1: CallCtlTermConnBridgedEv TermA’ Cause: CAUSE_NORMAL GC1: CallCrlTermConnHeldEv TA’ GC1:CallCrlTermConnTalkingEv TA’ GC1: CiscoTermConnMonitorStartEv TA’ GC1: CiscoTermConnMonitorInitiatorInfoEv TA’ Cause: CAUSE_NORMAL address:B, device name: TB A answers GC1 and B initiates monitor A puts the call on HOLD A’ answers the call B drops the call and initiates start monitor using GC3 giving the terminal connection of A’ in monitor request. Scenario Seven Snap Shot events for Monitor and recording: A is monitor target and has auto recording configured. B is monitor initiator. X calls A, A answers the call GC1 (ci1), B calls start monitor using GC2. Another application adds call observer on A after monitoring and recording sessions are established. Call info Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called: A CallActiveEv for callID = GC1 Cause: CAUSE_SNAPSHOT GC1:ConnCreatedEv for A Cause: CAUSE_SNAPSHOT GC1:ConnConnectedEv for A Cause: CAUSE_SNAPSHOT GC1: ConnConnectedEv X … GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_SNAPSHOT GC1: CiscoTermConnRecordingStartEv TA Cause: CAUSE_SNAPSHOT GC1: CiscoTermConnRecordingTargetInfoEv TA Cause: CAUSE_SNAPSHOT GC1: CiscoTermConnMonitorStartEv TA Cause: CAUSE_SNAPSHOT GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_SNAPSHOT address:B, device name: TB Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1281 Message Sequence Charts Message Sequence Charts

Page 1345 diagram

Page 1346

Secured Monitoring Use Cases Monitoring Use Cases Info Expected Result Scenario Initiatortaddress = S InitiatorTerminal = TermS InitiatorCall = GC2 TargetAddress = A TargetTerminal = TermA targetCall = GC1 GC1: CallCtlTermConnTalkingEv TermA GC2: CallActiveEv GC2: ConnCreatedEv S …. …. GC2: CallCtlConnEstablishedEv TermS GC1: CiscoTermConnMonitorStartEv TermA GC1: CiscoTermConnMonitorInitiatorInfoEv TermA GC2: ConnCreatedEv A …. …. GC2: CallCtlConnEstablishedEv TermA GC2: CiscoTermConnMonitorTargetInfoEv TermS Scenario 1

Supervisor and agent’s device security mode is encrypted
Customer and Agent are in a secured call.
Supervisor initiates a monitoring request. GC1: CiscoTermConnMonitoringEndEv TermA … GC1: CallInvalidEv … GC2: CallInvalidEv
The Agent Customer call is dropped. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1282 Message Sequence Charts Secured Monitoring Use Cases

Page 1346 diagram

Page 1347

Info Expected Result Scenario Initiatortaddress = S InitiatorTerminal = TermS InitiatorCall = GC2 Targetaddress = A TargetTerminal = TermATarget call = GC1 GC1: CallCtlTermConnTalkingEv TermA GC2: CallActiveEv GC2: ConnCreatedEv S …. GC2: CallCtlConnEstablishedEv TermS GC1: CiscoTermConnMonitorStartEv GC1: CiscoTermConnMonitorInitiatorInfoEv TermA GC2: ConnCreatedEv A …. …. GC2: CallCtlConnEstablishedEv TermA GC2: CiscoTermConnMonitorTargetInfoEv TermS Scenario 2

Supervisor and agent’s device security mode is encrypted
Customer and Agent are in a non-secured call.
Supervisor initiates a monitoring request GC1: CiscoTermConnMonitoringEndEv TermA … GC2: CallInvalidEv
Supervisor stops monitoring Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1283 Message Sequence Charts Message Sequence Charts

Page 1347 diagram

Page 1348

Info Expected Result Scenario Initiatortaddress = S InitiatorTerminal = TermS InitiatorCall = GC2 Targetaddress = A TargetTerminal = TermATarget call = GC1 GC1: CallCtlTermConnTalkingEv TermA GC2: CallActiveEv GC2: ConnCreatedEv S …. GC2: CallCtlConnEstablishedEv TermS GC1: CiscoTermConnMonitorStartEv TermA GC1: CiscoTermConnMonitorInitiatorInfoEv TermA GC2: ConnCreatedEv A …. …. GC2: CallCtlConnEstablishedEv TermA GC2: CiscoTermConnMonitorTargetInfoEv TermS GC1: CiscoTermConnMonitoringEndEv TermA … GC2: CallInvalidEv Scenario 3

Agent’s Device is non-secured and supervisor is secured
Customer and Agent are in a non secured call
Supervisor initiates a monitoring request
Supervisor stops Monitoring Cause: BCNAUTHORIZED GC1: CallCtlTermConnTalkingEv TermA GC2: ConnCreatedEv S .. GC2: CallCtlConnEstablished TermS GC2: ConnFailedEv S2 GC2: CallCtlConnFailedEv S2 PriviledgeViolationException :CTIERR_SECURITY_CAPABILITY_ MISMATCH ( as supervisor’s does not meet the security capabilities of the Agent) Scenario 4
Agent’s device is secured and supervisor is non-secured
Customer and agent are in a secured/non-secured call
Supervisor initiates a monitoring request Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1284 Message Sequence Charts Message Sequence Charts

Page 1348 diagram

Page 1349

Info Expected Result Scenario Initiatortaddress = S InitiatorTerminal = TermS InitiatorCall = GC2 Targetaddress = A TargetTerminal = TermATarget call = GC1 GC1: CallCtlTermConnTalkingEv TermA GC2: ConnCreatedEv S ….. GC2: CallCtlConnEstablishedEv TermS GC1: CiscoTermConnMonitorStartEv TermA GC1: CiscoTermConnMonitorInitiatorInfoEv TermA GC2: connCreatedEv A .. GC2: CallCtlConnEstablishedEv termA GC2: CiscoTermConnMonitoringTargetInfoEv Scenario 5

Both supervisor and agent are non-secured
Customer and agent are in a non-secured call
Supervisor initiates a monitoring request GC1: CiscoTermConnMonitoringEndEv TermA … GC2: CallInvalidEv
Supervisor stops monitoring Initiatortaddress = S InitiatorTerminal = TermS InitiatorCall = GC2 Targetaddress = A TargetTerminal = TermATarget call = GC1 cause : CAUSE_BCNAUTHORISED GC1: CallCtlTermConnTalkingEv TermA GC2: ConnCreatedEv S ….. GC2: CallCtlConnEstablishedEv TermS GC1: CiscoTermConnMonitorStartEv GC1: CiscoTermConnMonitoringInitiatorInfoEv termA GC2 : ConnCreatedEv A .. GC2: CallCtlConnEstablishedEv TermA GC2: CiscoTermConnMonitoringTargetInfoEv Scenario 6
Supervisor1 and agent are secured, supervisor2 is non-secured.
Customer and Agent are in a secured/non-secured call
A secured monitoring session is in progress with supervisor1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1285 Message Sequence Charts Message Sequence Charts

Page 1349 diagram

Page 1350

Info Expected Result Scenario TransactionID : xxxx AgentAddr = A AgentDevice = termA AgentCID = agentCI in GC1 Supervisor1 Device Name = TermS1 Cause = BCNAuthorised CiscoTransferStartEv ….. CiscoTransferEndEv The monitoring session is torn down (since supervisor2 does not meet the security capabilities of the agent) GC2: ConnFailedEv S2 GC2: CallCtlConnFailedEv S2 GC1: CiscoTermConnMonitorEndEv Events Received on Supervisor1 CiscoAddrMonitoringTerminatedEv 4. Supervisor1 transfers the monitoring call to supervisor2 Initiatortaddress = S InitiatorTerminal = TermS InitiatorCall = GC2 Targetaddress = A TargetTerminal = TermATarget call = GC1 GC1: CallCtlTermConnTalkingEv TermA GC2: ConnCreatedEv S ….. GC2: CallCtlConnEstablishedEv TermS GC1: CiscoTermConnMonitorStartEv GC1: CiscoTermConnMonitoringInitiatorInfoEv termA GC2 : ConnCreatedEv A .. GC2: CallCtlConnEstablishedEv TermA GC2: CiscoTermConnMonitoringTargetInfoEv Scenario 7

Supervisor1 and agent are secured, supervisor2 is secured.
Customer and Agent are in a secured/non-secured call
A secured monitoring session is in progress with supervisor1. Targetaddress = A TargetTerminal = TermATarget call = GC1 CiscoTransferStarteEv …. CiscoTransferEndEv GC2: ConnCreatedEv S2 ….. GC2: CallCtlConnEstablishedEv TermS2 GC2: CiscoTermConnMonitoringTargetInfoEv
Supervisor1 transfers the monitoring call to supervisor2 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1286 Message Sequence Charts Message Sequence Charts

Page 1350 diagram

Page 1351

Monitoring and Recording Use Cases Expected Result Scenario GC1: CallCtlTermConnTalkingEv TermA GC2: CallActiveEv GC2: ConnCreatedEv S …. …. GC2: CallCtlConnEstablishedEv TermS GC1: CiscoTermConnMonitorStartEv TermA GC1: CiscoTermConnMonitorInitiatorInfoEv TermA GC2: ConnCreatedEv A …. …. GC2: CallCtlConnEstablishedEv TermA GC2: CiscoTermConnMonitorTargetInfoEv TermS Scenario 1

Agent is non-secured, Supervisor and recorder are encrypted
Agent is in a non-secured call with customer
Supervisor monitors the call in non-secured mode CiscoTermConnRecordingStartEv CallCtlTermConnTalkingEv TermS The recording is done in a secured mode as Both the supervisor and recorder are secured, but the overall call security is non-secured.
Application requests for recording the call at Supervisor Native Queuing

Hunt Pilot HP has one member B. 2. Check box for “Queue Calls” is checked. 3. “Maximum In Queue timer” is set as 60 seconds. 4. “Destination When Maximum Wait Time is Met” is set as C 5. Queue depth is set to 1 6. “Destination When Queue is Full” is set to C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1287 Message Sequence Charts Native Queuing

Page 1351 diagram

Page 1352

Queuing of Call Call info Event Action GC1 CallActiveEv GC1 ConnCreatedEv A GC1 CallCtlConnInitiatedEv A GC1 CiscoHuntConnCreatedEv HP GC1 CallCtlConnEstablishedEv A GC1 TermConnCreatedEv A GC1 CallCtlTermConnTalkingEv TermA GC1 ConnConenctedEv HP GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 CallCtltermConnRingingEv termB GC1 CallCtlConnEstablishedEv HP A calls HP GC1 CallCtlConnEstablishedEv B GC1 CallCtlTermConnTalkingEv termB B answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1288 Message Sequence Charts Queuing of Call

Page 1352 diagram

Page 1353

Call info Event Action Connected.getAddress().getType() = CiscoAddress.HUNT_PILOT Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_QUEUING Connected.getAddress().getType() = CiscoAddress.INTERNAL Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = HP Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = HP Call.getLastRedirectedAddress() = HP Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_QUEUING Connected.getAddress().getType() = CiscoAddress.HUNT_PILOT GC2 CallActiveEv GC2 ConnCreatedEv D GC2 CallCtlConnInitiatedEv D GC2 CallCtlConnEstablishedEv D GC2 TermConnCreatedEv D GC2 CallCtlTermConnTalkingEv TermD GC2 CiscoHuntConnCreatedEv HP GC2 ConnCreatedEv HP GC2 ConnInProgessEv HP GC2 CallCtlConnQueuedEv HP GC2 CallCtlConnDisconenctedEv HP GC2 ConnDisconnectedEv HP D calls HP (Call gets Queued) De-queuing of a call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1289 Message Sequence Charts Message Sequence Charts

Page 1353 diagram

Page 1354

Call info Event Action GC1 CallActiveEv GC1 ConnCreatedEv A GC1 CallCtlConnInitiatedEv A GC1 CiscoHuntConnCreatedEv HP GC1 CallCtlConnEstablishedEv A GC1 TermConnCreatedEv A GC1 CallCtlTermConnTalkingEv TermA GC1 ConnConenctedEv HP GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 CallCtltermConnRingingEv termB GC1 CallCtlConnEstablishedEv HP A calls HP GC1 CallCtlConnEstablishedEv B GC1 CallCtlTermConnTalkingEv termB B answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1290 Message Sequence Charts Message Sequence Charts

Page 1354 diagram

Page 1355

Call info Event Action Connected.getAddress().getType() = CiscoAddress.HUNT_PILOT Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_QUEUING Connected.getAddress().getType() = CiscoAddress.INTERNAL Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = HP Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = HP Call.getLastRedirectedAddress() = HP Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_QUEUING Connected.getAddress().getType() = CiscoAddress.HUNT_PILOT GC2 CallActiveEv GC2 ConnCreatedEv D GC2 CallCtlConnInitiatedEv D GC2 CallCtlConnEstablishedEv D GC2 TermConnCreatedEv D GC2 CallCtlTermConnTalkingEv TermD GC2 CiscoHuntConnCreatedEv HP GC2 ConnCreatedEv HP GC2 ConnInProgessEv HP GC2 CallCtlConnQueuedEv HP GC2 CallCtlConnDisconenctedEv HP GC2 ConnDisconnectedEv HP D calls HP (Call gets Queued) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1291 Message Sequence Charts Message Sequence Charts

Page 1355 diagram

Page 1356

Call info Event Action Connected.getAddress().getType() = CiscoAddress.HUNT_PILOT Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_DEQUEUING Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = B Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = B Call.getLastRedirectedAddress() = HP Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_DEQUEUING (AddressImpl)(ConnectionImpl)((ConnEvImpl) Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL GC1 ConnDisconnectedEv HP GC1 CallCtlConnDisconnectedEv HP GC1 TermConnDroppedEv TermB GC1 CallCtlTermConnDroppedEv termB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconenctedEv B GC1 TermConnDroppedEv TermA GC1 CallCtlTermConnDroppedEv termA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconenctedEv A GC1 CallInvalidEv GC2 ConnCreatedEv B GC2 ConnInProgressEv B GC2 CallCtlConnOfferedEv B GC2 CiscoHuntConnCreatedEv HP GC2 ConnAlertinEv B GC2 CallCtlConnAleringEv B GC2 TermConnCreatedEv Term B Gc2 termConnRingingEv TermB GC2 CallCtlTermConnRingingEv TermB GC2 ConnConnectedEv HP GC2 CallCtlConnEstablishedEv HP GC2 ConnDisconnectedEv HP GC2 CallCtlConnDisconnectedEv HP B disconnects the call Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = B Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = B Call.getLastRedirectedAddress() = HP GC2 ConnConnectedEv B GC2 CallCtlConnEstablishedEv B GC2 TermConnActiveEv Term B GC2 TermConnCtalkingEv TermB B Answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1292 Message Sequence Charts Message Sequence Charts

Page 1356 diagram

Page 1357

Maximum In-Queue Timer Expires Call info Event Action GC1 CallActiveEv GC1 ConnCreatedEv A GC1 CallCtlConnInitiatedEv A GC1 CiscoHuntConnCreatedEv HP GC1 CallCtlConnEstablishedEv A GC1 TermConnCreatedEv A GC1 CallCtlTermConnTalkingEv TermA GC1 ConnConenctedEv HP GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 CallCtltermConnRingingEv termB GC1 CallCtlConnEstablishedEv HP A calls HP GC1 CallCtlConnEstablishedEv B GC1 CallCtlTermConnTalkingEv termB B answers the call Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = HP Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = HP Call.getLastRedirectedAddress() = HP Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_QUEUING Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL GC2 CallActiveEv GC2 ConnCreatedEv D GC2 CallCtlConnInitiatedEv D GC2 CallCtlConnEstablishedEv D GC2 TermConnCreatedEv D GC2 CallCtlTermConnTalkingEv TermD GC2 CiscoHuntConnCreatedEv HP GC2 ConnCreatedEv HP GC2 CallCtlCallOfferedEv HP GC2 ConnConnectedEv HP GC2 CallCtlConnEstablishedEv HP D calls HP (Call gets Queued) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1293 Message Sequence Charts Maximum In-Queue Timer Expires

Page 1357 diagram

Page 1358

Call info Event Action Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING_TIMER_EXPIRED Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = C Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = C Call.getLastRedirectedAddress() = HP Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING_TIMER_EXPIRED Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL GC2 ConnCreatedEv C GC2 ConnInProgressEv C GC2 CallCtlConnOfferedEv C GC2 ConnAlertingEv C GC2 CallCtlConnAlertingEv C GC2 CallCtltermConnRingingEv termC GC2 ConnDisconnectedEv HP GC2 CallCtlConnDisconnectedEv HP After 60 seconds Maximum In-Queue Timer Expires with Destination as Another HP Whose Member E Is Free All members of HP are busy. The destination when queue timer expires is HP2 whose members E is free Call info Event Action Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_QUEUING Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = HP Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = HP Call.getLastRedirectedAddress() = HP GC2 CallActiveEv GC2 ConnCreatedEv D GC2 CallCtlConnInitiatedEv D GC2 CallCtlConnEstablishedEv D GC2 TermConnCreatedEv D GC2 CallCtlTermConnTalkingEv TermD GC2 CiscoHuntConnCreatedEv HP GC2 ConnCreatedEv HP GC2 CallCtlCallOfferedEv HP GC2 ConnConnectedEv HP GC2 CallCtlConnEstablishedEv HP D calls HP (Call gets Queued) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1294 Message Sequence Charts Maximum In-Queue Timer Expires with Destination as Another HP Whose Member E Is Free

Page 1358 diagram

Page 1359

Call info Event Action Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING_TIMER_EXPIRED Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = E Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = B Call.getLastRedirectedAddress() = HP Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING_TIMER_EXPIRED (AddressImpl)(ConnectionImpl)((ConnEvImpl) Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL GC2 ConnCreatedEv E GC2 ConnInProgressEv E GC2 CallCtlConnOfferedEv E GC2 CiscoHuntConnCreatedEv HP2 GC2 ConnAlertinEv E GC2 CallCtlConnAleringEv E GC2 TermConnCreatedEv Term E Gc2 termConnRingingEv TermE GC2 CallCtlTermConnRingingEv TermE GC2 ConnConnectedEv HP2 GC2 CallCtlConnEstablishedEv HP2 GC2 ConnDisconnectedEv HP GC2 CallCtlConnDisconnectedEv HP After 60s call gets offered on HP2 Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = E Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = E Call.getLastRedirectedAddress() = HP GC2 ConnConnectedEv E GC2 CallCtlConnEstablishedEv E GC2 TermConnActiveEv Term E GC2 TermConnCtalkingEv TermE E answers Maximum In-Queue Timer Expires with Destination as Another HP Whose Members Are Busy All members of HP are busy. The destination when queue timer expires is HP2 whose members (E) is also busy Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1295 Message Sequence Charts Maximum In-Queue Timer Expires with Destination as Another HP Whose Members Are Busy

Page 1359 diagram

Page 1360

Call info Event Action Ev.getConnection()). getAddress()). getType() = CiscoAddress.HUNT_PILOT Ev.getConnection()).getAddress()).getType()

CiscoAddress.INTERNAL Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_QUEUING Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = HP Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = HP Call.getLastRedirectedAddress() = HP GC2 CallActiveEv GC2 ConnCreatedEv D GC2 CallCtlConnInitiatedEv D GC2 CallCtlConnEstablishedEv D GC2 TermConnCreatedEv D GC2 CallCtlTermConnTalkingEv TermD GC2 CiscoHuntConnCreatedEv HP GC2 ConnCreatedEv HP GC2 CallCtlCallOfferedEv HP GC2 ConnConnectedEv HP GC2 CallCtlConnEstablishedEv HP D calls HP (Call gets Queued) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1296 Message Sequence Charts Message Sequence Charts

Page 1360 diagram

Page 1361

Call info Event Action Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING Ev.getConnection()). getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getConnection()). getAddress()).getType() = CiscoAddress.HUNT_PILOT Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = E Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = E Call.getLastRedirectedAddress() = HP Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING (AddressImpl)(ConnectionImpl) ((ConnEvImpl) Ev.getConnection()). getAddress()).getType() = CiscoAddress.INTERNAL GC2 ConnCreatedEv E GC2 ConnInProgressEv E GC2 CallCtlConnOfferedEv E GC2 CiscoHuntConnCreatedEv HP2 GC2 ConnAlertinEv E GC2 CallCtlConnAleringEv E GC2 TermConnCreatedEv Term E Gc2 termConnRingingEv TermE GC2 CallCtlTermConnRingingEv TermE GC2 ConnConnectedEv HP2 GC2 CallCtlConnEstablishedEv HP2 GC2 ConnDisconnectedEv HP GC2 CallCtlConnDisconnectedEv HP E becomes Free after >60s Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = E Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = E Call.getLastRedirectedAddress() = HP GC2 ConnConnectedEv E GC2 CallCtlConnEstablishedEv E GC2 TermConnActiveEv Term E GC2 TermConnCtalkingEv TermE E answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1297 Message Sequence Charts Message Sequence Charts

Page 1361 diagram

Page 1362

Queue Is Full Fields Event Action GC1 CallActiveEv GC1 ConnCreatedEv A GC1 CallCtlConnInitiatedEv A GC1 CiscoHuntConnCreatedEv HP GC1 CallCtlConnEstablishedEv A GC1 TermConnCreatedEv A GC1 CallCtlTermConnTalkingEv TermA GC1 ConnConenctedEv HP GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 CallCtltermConnRingingEv termB GC1 CallCtlConnEstablishedEv HP A calls HP GC1 CallCtlConnEstablishedEv B GC1 CallCtlTermConnTalkingEv termB B answers the call Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_QUEUING Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = HP Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = HP Call.getLastRedirectedAddress() = HP GC2 CallActiveEv GC2 ConnCreatedEv D GC2 CallCtlConnInitiatedEv D GC2 CallCtlConnEstablishedEv D GC2 TermConnCreatedEv D GC2 CallCtlTermConnTalkingEv TermD GC2 CiscoHuntConnCreatedEv HP GC2 ConnCreatedEv HP GC2 CallCtlCallOfferedEv HP GC2 ConnConnectedEv HP GC2 CallCtlConnEstablishedEv HP D calls HP (Call gets Queued) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1298 Message Sequence Charts Queue Is Full

Page 1362 diagram

Page 1363

Fields Event Action Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING_AGENTS_BUSY Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING_AGENTS_BUSY GC3 CallActiveEv GC3 ConnCreatedEv E GC3 CallCtlConnInitiatedEv E GC3 ConnCreatedEv E GC3 CallCtlConnInitiatedEv E GC3 CallCtlConnEstablishedEv E GC3 TermConnCreatedEv E GC3 CallCtlTermConnTalkingEv TermE GC3 CiscoHuntConnCreatedEv HP GC3 ConnCreatedEv C GC3 CallCtlCallOfferedEv C GC3 ConnAlertinEv C GC3 CallCtlConnAleringEv C GC3 TermConnCreatedEv Term C Gc3 termConnRingingEv TermC GC3 CallCtlTermConnRingingEv TermC GC3 CallCtlConnDisconnectedEv HP GC3 ConnCisconnectedEv HP E calls HP Call gets offered on C Call.getCalledAddress() = HP Call.getCallingAddress() = E Call.getCurrentCalledAddress() = C Call.getCurrentCallingAddress() = E Call.getModifiedCallingAddress() = E Call.getModifiedCalledAddress() = C Call.getLastRedirectedAddress() = HP GC3 CallCtlConnEstablishedEv C GC3 CallCtlTermConnTalkingEv termC C answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1299 Message Sequence Charts Message Sequence Charts

Page 1363 diagram

Page 1364

When Disconnect Is Selected for Queue Full Call info Event Action GC1 CallActiveEv GC1 ConnCreatedEv A GC1 CallCtlConnInitiatedEv A GC1 CiscoHuntConnCreatedEv HP GC1 CallCtlConnEstablishedEv A GC1 TermConnCreatedEv A GC1 CallCtlTermConnTalkingEv TermA GC1 ConnConenctedEv HP GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 CallCtltermConnRingingEv termB GC1 CallCtlConnEstablishedEv HP A calls HP GC1 CallCtlConnEstablishedEv B GC1 CallCtlTermConnTalkingEv termB B answers the call Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_QUEUING Call.getCalledAddress() = HP Call.getCallingAddress() = D Call.getCurrentCalledAddress() = HP Call.getCurrentCallingAddress() = D Call.getModifiedCallingAddress() = D Call.getModifiedCalledAddress() = HP Call.getLastRedirectedAddress() = HP GC2 CallActiveEv GC2 ConnCreatedEv D GC2 CallCtlConnInitiatedEv D GC2 CallCtlConnEstablishedEv D GC2 TermConnCreatedEv D GC2 CallCtlTermConnTalkingEv TermD GC2 CiscoHuntConnCreatedEv HP GC2 ConnCreatedEv HP GC2 CallCtlCallOfferedEv HP GC2 ConnConnectedEv HP GC2 CallCtlConnEstablishedEv HP D calls HP (Call gets Queued) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1300 Message Sequence Charts When Disconnect Is Selected for Queue Full

Page 1364 diagram

Page 1365

Call info Event Action Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_NORMAL Cause = UserBusy GC3 CallActiveEv GC3 ConnCreatedEv E GC3 CallCtlConnInitiatedEv E GC3 ConnCreatedEv E GC3 CallCtlConnInitiatedEv E GC3 CallCtlConnEstablishedEv E GC3 TermConnCreatedEv E GC3 CallCtlTermConnTalkingEv TermE GC3 CiscoHuntConnCreatedEv HP GC3 ConnFaileEv E GC3 CallCtlConnFailedEv E Gc3 ConnDisconenctedEv HP Gc3 ConnDisconnectedEv E Gc3 CallCtlConnDisconenctedEv E Gc3 CallInvalidEv E calls HP Call fails Same result as above is observed when "Disconnect" is selected for MaxQueueTime and Agents Not Logged in configs and those conditions get hit. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1301 Message Sequence Charts Message Sequence Charts

Page 1365 diagram

Page 1366

No Agents Are Logged In Call info Event Action Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING_AGENTS_UNAVAILABLE Ev.getCiscoFeatureReason() = CiscoFeatureReason. REASON_DEQUEUING_AGENTS_UNAVAILABLE Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT GC1 CallActiveEv GC1 ConnCreatedEv A GC1 CallCtlConnInitiatedEv A GC1 CiscoHuntConnCreatedEv HP GC1 CallCtlConnEstablishedEv A GC1 TermConnCreatedEv A GC1 CallCtlTermConnTalkingEv TermA GC3 ConnCreatedEv C GC3 CallCtlCallOfferedEv C GC3 ConnAlertinEv C GC3 CallCtlConnAleringEv C GC3 TermConnCreatedEv Term C Gc3 termConnRingingEv TermC GC3 CallCtlTermConnRingingEv TermC GC3 CallCtlConnDisconnectedEv HP GC3 ConnCisconnectedEv HP A calls HP GC1 CallCtlConnEstablishedEv C GC1 CallCtlTermConnTalkingEv termC C answers the call Caller Redirects While in Queue A calls HP, call offered on B and B answers (GC1). D calls HP and gets queued (GC2). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1302 Message Sequence Charts No Agents Are Logged In

Page 1366 diagram

Page 1367

Call info Event Action Ev.getCiscoFeatureReason() = REASON_REDIRECT Call.getCalledAddress() = E Call.getCallingAddress() = HP Call.getCurrentCalledAddress() = E Call.getCurrentCallingAddress() = HP Call.getModifiedCallingAddress() = HP Call.getModifiedCalledAddress() = E Call.getLastRedirectedAddress() = D GC2 ConnCreatedEv E GC2 CallCtlCallOfferedEv E GC2 TermConnDroppedEv TermD GC2 CallCtlTermConnDroppedEv termD GC2 ConnDisconnectedEv D GC2 CallCtlTermConnDisconnectedEv D GC2 ConnAlertinEv E GC2 CallCtlConnAleringEv E GC2 TermConnCreatedEv Term E GC2 TermConnRingingEv TermE GC2 CallCtlTermConnRingingEv TermE D redirects the call to E GC2 CallCtlConnEstablishedEv E GC2 CallCtlTermConnTalkingEv termE E answers Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_DEQUEUING Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Call.getCalledAddress() = HP Call.getCallingAddress() = E Call.getCurrentCalledAddress() = HP Call.getCurrentCallingAddress() = E Call.getModifiedCallingAddress() = E Call.getModifiedCalledAddress() = HP Call.getLastRedirectedAddress() = HP GC1 TermConnDroppedEv TermA GC1 CallCtlTermConnDroppedEv termA GC1 ConnDisconnectedEv A GC1 CallCtlTermConnDisconnectedEv A GC1 TermConnDroppedEv TermB GC1 CallCtlTermConnDroppedEv termB GC1 ConnDisconnectedEv B GC1 CallCtlTermConnDisconnectedEv B GC1 CallInvalidEv GC2 ConnCreatedEv B GC2 ConnInProgressEv B GC2 CallCtlConnOfferedEv B GC2 CiscoHuntConnCreatedEv HP GC2 ConnAlertinEv B GC2 CallCtlConnAleringEv B GC2 TermConnCreatedEv Term B Gc2 termConnRingingEv TermB GC2 CallCtlTermConnRingingEv TermB GC2 ConnConnectedEv HP GC2 CallCtlConnEstablishedEv HP B drops GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1303 Message Sequence Charts Message Sequence Charts

Page 1367 diagram

Page 1368

Call info Event Action Ev.getCiscoFeatureReason() = CiscoFeatureReason.REASON_DEQUEUING (AddressImpl)(ConnectionImpl)((ConnEvImpl) Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL GC2 ConnDisconnectedEv HP GC2 CallCtlConnDisconnectedEv HP GC2 CallCtlConnEstablishedEv B GC2 CallCtlTermConnTalkingEv termB B answers Caller (Observed) Conferences While in Queue A calls HP, call offered on B and B answers (GC1). D calls HP and gets queued (GC2). Call info Event Action GC2 callCtltermConnHeldEv termD GC3 CallActiveEv GC3 ConnCreatedEv D GC3 CallCtlConnInitiatedEv D GC3 CallCtlConnEstablishedEv D GC3 TermConnCreatedEv D GC3 CallCtlTermConnTalkingEv TermD GC3 ConnCreatedEv E GC3 ConnInProgressEv E GC3 CallCtlConnOfferedEv E GC3 ConnAlertingEv E GC3 CallCtlConnAlertingEv E GC3 CallCtltermConnRingingEv termE D initiates a consult call with E GC2 CallCtlConnEstablishedEv E GC2 CallCtlTermConnTalkingEv termE E answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1304 Message Sequence Charts Caller (Observed) Conferences While in Queue

Page 1368 diagram

Page 1369

Call info Event Action Ev.getCiscoFeatureReason() = REASON_CONFERENCE Ev.getCiscoFeatureReason() = REASON_CONFERENCE Ev.getCiscoFeatureReason() = REASON_CONFERENCE Ev.getCiscoFeatureReason() = REASON_CONFERENCE Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL Ev.getConnection()).getAddress()).getType() = CiscoAddress.UNKNOWN GC2 CiscoConfereceStartedEv GC3 TermConnDroppedEv TermE GC3 CallCtlTermConnDroppedEv termE GC3 ConnDisconnectedEv E GC3 CallCtlTermConnDisconnectedEv E GC3 TermConnDroppedEv TermD GC3 CallCtlTermConnDroppedEv termD GC3 ConnDisconnectedEv D GC3 CallCtlTermConnDisconnectedEv D GC3 CallInvalidEv GC2 ConnDisconnectedEv HP GC2 CallCtlConnDisconnectedEv HP GC2 ConnCreatedEv HP GC2 CallCtlConnEstablishedEv HP GC2 CiscoConferenceEndEv D conferences GC1 with Cg2 GC1.conference(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1305 Message Sequence Charts Message Sequence Charts

Page 1369 diagram

Page 1370

Call info Event Action Ev.getCiscoFeatureReason()= REASON_NORMAL Ev.getConnection()).getAddress()).getType() = CiscoAddress.UNKNOWN Ev.getCiscoFeatureReason() = REASON_DEQUEUING Ev.getCiscoFeatureReason() = REASON_DEQUEUING Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT Ev.getCiscoFeatureReason() = REASON_CONFERENCE Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL Ev.getCiscoFeatureReason() = REASON_CONFERENCE Ev.getConnection()).getAddress()).getType() = CiscoAddress.HUNT_PILOT GC1 TermConnDroppedEv TermA GC1 CallCtlTermConnDroppedEv termA GC1 ConnDisconnectedEv A GC1 CallCtlConnDisconnectedEv A GC1 TermConnDroppedEv TermB GC1 CallCtlTermConnDroppedEv termB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B GC1 CallInvalidEv GC2 ConnDisconnectedEv HP GC2 CallCtlConnDisconnectedEvHP GC2 ConnCreatedEv B GC2 ConnInProgressEv B GC2 CallCtlConnOfferedEv B GC2 CiscoHuntConnCreatedEv HP GC2 ConnAlertingEv B GC2 CallCtlConnAlertingEv B GC2 CallCtltermConnRingingEv termB Gc2 ConnConenctedEv HP GC2 CallCtlConnEstablished HP GC2 ConnCreatedEv HP Gc2 ConnAlertingEv HP GC2 CallCtlConnAlertingEv HP GC2 ConnDisconnectedEv HP GC2 CallCtlConnDisconnectedEvHP B drops GC1 Ev.getConnection()).getAddress()).getType() = CiscoAddress.INTERNAL Gc2 ConnConenctedEv HP GC2 CallCtlConnEstablished HP Gc2 ConnConenctedEv HP GC2 CallCtlConnEstablished HP GC2 TermConnActiveEv termb GC2 CallCtlTermConnTalkingEv termB B answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1306 Message Sequence Charts Message Sequence Charts

Page 1370 diagram

Page 1371

Use Cases for NuRD (Number Matching for Remote Destination) Prerequisites Pre-conditions to nurd use cases, unless specified otherwise: • Provider is in IN_SERVICE state • All addresses and terminals are already in service. • Enable "Route calls to all remote destinations" checkbox for CTIRD1 and CTIRD2. • Clusterwide service parameter "Reroute Remote Destination Calls to Enterprise Number" is set to true. • ICT Trunk configured with Route pattern is 408XXXXX with no discard digits. • SIP Trunk configured with Route pattern is 409XXXXX with no discard digits. • ICT Trunk configured with Route pattern is 33.XXXX with discard digits pre-dot. • CTIRD1 associated to user "Mobility1", dn = 2303 • Remote destination 1 (Name: "RDD1", Number: "40822077") • Remote destination 2 (Name: "RDD2", Number: "40922078") • CTIRD2 associated to user "Mobility2", dn = 9200 • Remote destination 1 (Name: "RDD3", Number: "40812115") • Remote destination 2 (Name: "RDD4", Number: "40912116") • CTIRD2 has a shared ip phone D • RDP2 associated to user "Mobility2", dn = 9200 with display and Unicode name configured to be "RDP2". • Remote destination 1 (Name: "RDD3", Number: "40812115"). This is shared with CTIRD2. • Remote destination 2 (Name: "RDDP1", Number: "40922095") • Device A (IP Phone - Name: "SEP2401C7824EA3", Line A1 (dn: 9000)). • Device B (IP Phone - Name: "SEP2401C7824EAE", Line B1 (dn: 9001)). • User1 has in its control list: Device A, B, CTIRD1 and CTIRD2. All devices and lines are observed. Basic Calls Initiated From Remote Destination Table 286: Remote Destination Initiates Call with No Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1307 Message Sequence Charts Use Cases for NuRD (Number Matching for Remote Destination)

Page 1371 diagram

Page 1372

Call Info Events Action CallingAddress = 40822077, CalledAddress = 9000, CurrentCallingAddress = 40822077, CurrentCalledAddress = 9000 CurrentCallingAddress.getType () = External GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnInProgressEv 9000 GC1: CallCtlConOfferedEv 9000 GC1: ConnCreatedEv 40822077 GC1: ConnConnectedEv 40822077 GC1: CallCtlConnEstablishedEv 40822077 GC1: ConnAlertingEv 9000 GC1: CallCtlConnAlertingEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnRingingEv SEP2401C7824EA3 GC1: CallCtlTermConnRingingEv SEP2401C7824EA3 GC1: ConnConnectedEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 *Direct call between RDD1 and A. RDD1 calls A1 in which active rd is not set. Call is answered at A1 (dn = 9000). Table 287: Remote Destination Initiates Call with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1308 Message Sequence Charts Message Sequence Charts

Page 1372 diagram

Page 1373

Call Info Events Action CallingAddress = 2303, CalledAddress = 9000, CurrentCallingAddress = 2303, CurrentCalledAddress = 9000 CurrentCallingAddress.getType () = Internal GC1: CallActiveEv GC1: ConnCreatedEv 2303 GC1: CallCtlConnDialingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: ConnCreatedEv 9000 GC1: ConnInProgressEv 9000 GC1: CallCtlConnOfferedEv 9000 GC1: ConnAlertingEv 9000 GC1: CallCtlConnAlertingEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnRingingEv SEP2401C7824EA3 GC1: CallCtlTermConnRingingEv SEP2401C7824EA3 GC1: ConnConnectedEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 *Call is routed through CTIRD1 so looks like CTIRD1 is initiating a call to A. RDD1 calls A1 in which active rd is set. Call is answered at A1 (dn = 9000). Table 288: Remote Destination Initiates Call with Active RDD with Only CTIRD Observed Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. User1 observes only CTIRD *If active remote destination is not set, then app will not see any call events as it would be direct call between RDD1 and A1. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1309 Message Sequence Charts Message Sequence Charts

Page 1373 diagram

Page 1374

Page 1374 diagram

Page 1375

Call Info Events Action CallingAddress = 9000, CalledAddress = 40822077, CurrentCallingAddress = 9000, CurrentCalledAddress = 40822077 CurrentCalledAddress.getType() = External GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 40822077 GC1: ConnConnectedEv 40822077 GC1: CallCtlConnNetworkReachedEv 40822077 GC1: CallCtlConnNetworkAlertingEv 40822077 GC1: CallCtlConnEstablishedEv 40822077 *Direct call between A and RDD1. A1 calls RDD1 in which active rd is not set. User1 invokes Call.connect("SEP2401C7824EA3", "9000", "40822077"). Call is answered at RDD1 (dn = 40822077). Table 289: Call to Remote Destination with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination("40822077", true) on CTIRD1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1311 Message Sequence Charts Message Sequence Charts

Page 1375 diagram

Page 1376

Call Info Events Action CallingAddress = 9000, CalledAddress = 40822077, CurrentCallingAddress = 9000, CurrentCalledAddress = 2303 CurrentCalledAddress.getType() = Internal GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 2303 GC1: ConnInProgressEv 2303 GC1: CallCtlConnOfferedEv 2303 GC1: ConnAlertingEv 2303 GC1: CallCtlConnAlertingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnRingingEv CTIRD1 GC1: CallCtlTermConnRingingEv CTIRD1 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 *Call is routed through and offered on CTIRD1 and extended to RDD1 with no delay. A1 calls RDD1 in which active rd is set. User1 invokes Call.connect("SEP2401C7824EA3", "9000", "40822077"). Call is answered at RDD1 (dn = 40822077). Table 290: Call to Remote Destination with Active RDD with Only CTIRD Observed Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. User1 observes only CTIRD *If active remote destination is not set, then app will not see any call events as it would be direct call between A1 and RDD1. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination("40822077", true) on CTIRD1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1312 Message Sequence Charts Message Sequence Charts

Page 1376 diagram

Page 1377

Call Info Events Action CallingAddress = 9000, CalledAddress = 2303, CurrentCallingAddress = 9000, CurrentCalledAddress = 2303 CurrentCalledAddress.getType() = Internal GC1: CallActiveEv GC1: ConnCreatedEv 2303 GC1: ConnInProgressEv 2303 GC1: CallCtlConnOfferedEv 2303 GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnAlertingEv 2303 GC1: CallCtlConnAlertingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnRingingEv CTIRD1 GC1: CallCtlTermConnRingingEv CTIRD1 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 *Call is routed through and offered on CTIRD1 and extended to RDD1 with no delay. A1 calls RDD1 in which active rd is set. User1 invokes Call.connect("SEP2401C7824EA3", "9000", "40822077"). Call is answered at RDD1 (dn = 40822077). CTIRD/RDP Interaction Table 291: Remote Destination Shared Between CTIRD and RDP Initiates Call with No Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1313 Message Sequence Charts CTIRD/RDP Interaction

Page 1377 diagram

Page 1378

Call Info Events Action CallingAddress = 9200, CalledAddress = 9001, CurrentCallingAddress = 9200, CurrentCalledAddress = 9001 CurrentCallingPartyDisplayName = RDP2 GC1: CallActiveEv GC1: ConnCreatedEv 9200 GC1: ConnConnectedEv 9200 GC1: CallCtlConnInitiatedEv 9200 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnPassiveEv SEP2401C7824EA3 GC1: CallCtlTermConnInUseEv SEP2401C7824EA3 GC1: CallCtlConnEstablishedEv 9200 GC1: ConnCreatedEv 9001 GC1: ConnInProgressEv 9001 GC1: CallCtlConnOfferedEv 9001 GC1: ConnAlertingEv 9001 GC1: CallCtlConnAlertingEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnRingingEv SEP2401C7824EAE GC1: CallCtlTermConnRingingEv SEP2401C7824EAE GC1: ConnConnectedEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEv SEP2401C7824EAE *Call is routed through the RDP. RDD3 calls B1 in which active rd is not set. Call is answered at B1 (dn = 9001). Table 292: Remote Destination Shared Between CTIRD and RDP Initiates Call with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD2 to be RDD3 (dn = 40812115). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40812115", true) on CTIRD2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1314 Message Sequence Charts Message Sequence Charts

Page 1378 diagram

Page 1379

Call Info Events Action CallingAddress = 9200, CalledAddress = 9001, CurrentCallingAddress = 9200, CurrentCalledAddress = 9001 CurrentCallingPartyDisplayName

GC1: CallActiveEv GC1: ConnCreatedEv 9200 GC1: CallCtlConnDialingEv 9200 GC1: TermConnCreatedEv CTIRD2 GC1: TermConnActiveEv CTIRD2 GC1: CallCtlTermConnTalkingEv CTIRD2 GC1: ConnConnectedEv 9200 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnPassiveEv SEP2401C7824EA3 GC1: CallCtlTermConnBridgedEv SEP2401C7824EA3 GC1: CallCtlConnEstablishedEv 9200 GC1: ConnCreatedEv 9001 GC1: ConnInProgressEv 9001 GC1: CallCtlConnOfferedEv 9001 GC1: ConnAlertingEv 9001 GC1: CallCtlConnAlertingEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnRingingEv SEP2401C7824EAE GC1: CallCtlTermConnRingingEv SEP2401C7824EAE GC1: ConnConnectedEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEv SEP2401C7824EAE *Call is routed through CTIRD2 so looks like CTIRD2 is initiating a call to B. RDD3 calls B1 in which active rd is set. Call is answered at B1 (dn = 9001). Table 293: Remote Destination Unique to CTIRD2 Initates Call with No Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1315 Message Sequence Charts Message Sequence Charts

Page 1379 diagram

Page 1380

Call Info Events Action CallingAddress = 40912116, CalledAddress = 9001, CurrentCallingAddress = 40912116, CurrentCalledAddress = 9001 CurrentCallingPartyDisplayName

GC1: CallActiveEv GC1: ConnCreatedEv 9001 GC1: ConnInProgressEv 9001 GC1: CallCtlConnOfferedEv 9001 GC1: ConnCreatedEv 40912116 GC1: ConConnectedEv 40912116 GC1: CallCtlConnEstablishedEv 40912116 GC1: ConnAlertingEv 9001 GC1: CallCtlConnAlertingEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TemConnRingingEv SEP2401C7824EAE GC1: CallCtlTermConnRingingEv SEP2401C7824EAE GC1: ConnConnectedEv 9001 GC1: CallCtlTermConnEstablishedEv 9001 GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEv SEP2401C7824EAE *Direct call between RDD4 and B1. RDD4 calls B1 in which active rd is not set. Call is answered at B1 (dn = 9001). Table 294: Remote Destination Unique to CTIRD2 Initates Call with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD2 to be RDD4 (dn = 40912116). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40912116", true) on CTIRD2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1316 Message Sequence Charts Message Sequence Charts

Page 1380 diagram

Page 1381

Call Info Events Action CallingAddress = 9200, CalledAddress = 9001, CurrentCallingAddress = 9200, CurrentCalledAddress = 9001 CurrentCallingPartyDisplayName

GC1: CallActiveEv GC1: ConnCreatedEv 9200 GC1: CallCtlConnDialingEv 9200 GC1: TermConnCreatedEv CTIRD2 GC1: TermConnActiveEv CTIRD2 GC1: CallCtlTermConnTalkingEv CTIRD2 GC1: ConnConnectedEv 9200 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnPassiveEv SEP2401C7824EA3 GC1: CallCtlTermConnBridgedEv SEP2401C7824EA3 GC1: CallCtlConnEstablishedEv 9200 GC1: ConnCreatedEv 9001 GC1: ConnInProgressEv 9001 GC1: CallCtlConnOfferedEv 9001 GC1: ConnAlertingEv 9001 GC1: CallCtlConnAlertingEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnRingingEv SEP2401C7824EAE GC1: CallCtlTermConnRingingEv SEP2401C7824EAE GC1: ConnConnectedEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEv SEP2401C7824EAE *Call is routed through CTIRD2 so looks like CTIRD2 is initiating a call to B. RDD4 calls B1 in which active rd is set. Call is answered at B1 (dn = 9001). Table 295: Remote Destination Unique to RDP Initiates Call with No Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1317 Message Sequence Charts Message Sequence Charts

Page 1381 diagram

Page 1382

Call Info Events Action CallingAddress = 9200, CalledAddress = 9001, CurrentCallingAddress = 9200, CurrentCalledAddress = 9001 CurrentCallingPartyDisplayName = RDP2 GC1: CallActiveEv GC1: ConnCreatedEv 9200 GC1: ConnConnectedEv 9200 GC1: CallCtlConnInitiatedEv 9200 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnPassiveEv SEP2401C7824EA3 GC1: CallCtlTermConnInUseEv SEP2401C7824EA3 GC1: CallCtlConnEstablishedEv 9200 GC1: ConnCreatedEv 9001 GC1: ConnInProgressEv 9001 GC1: CallCtlConnOfferedEv 9001 GC1: ConnAlertingEv 9001 GC1: CallCtlConnAlertingEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnRingingEv SEP2401C7824EAE GC1: CallCtlTermConnRingingEv SEP2401C7824EAE GC1: ConnConnectedEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEv SEP2401C7824EAE *Call is routed through the RDP. RDDP1 calls B1. Call is answered at B1 (dn = 9001). Table 296: Call to Remote Destination Shared with RDP with No Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1318 Message Sequence Charts Message Sequence Charts

Page 1382 diagram

Page 1383

Call Info Events Action CallingAddress = 9001, CalledAddress = 40812115, CurrentCallingAddress = 9001, CurrentCalledAddress = 9200 CurrentCalledPartyDisplayName = RDP2 GC1: CallActiveEv GC1: ConnCreatedEv 9001 GC1: ConnConnectedEv 9001 GC1: CallCtlConnInitatedEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEvSEP2401C7824EAE GC1: CallCtlConnDialingEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: ConnCreatedEv 9200 GC1: ConnInProgressEv 9200 GC1: CallCtlConnOfferedEv 9200 GC1: ConnConnectedEv 9200 GC1: CallCtlConnEstablishedEv 9200 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnPassiveEv SEP2401C7824EA3 GC1: CallCtlTermConnInUseEv SEP2401C7824EA3 *Call is routed through RDP. B1 calls RDD3 in which active rd is not set. User1 invokes Call.connect ("SEP2401C7824EAE", "9001", "40812115"). Call is offered to RDD3 after delay and then answered at RDD3 (dn = 40812115). Table 297: Call to Remote Destination Shared with RDP with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD2 to be RDD3 (dn = 40812115). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40812115", true) on CTIRD2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1319 Message Sequence Charts Message Sequence Charts

Page 1383 diagram

Page 1384

Call Info Events Action CallingAddress = 9001, CalledAddress = 40812115, CurrentCallingAddress = 9001, CurrentCalledAddress = 9200 CurrentCalledPartyDisplayName

GC1: CallActiveEv GC1: ConnCreatedEv 9001 GC1: ConnConnectedEv 9001 GC1: CallCtlConnInitatedEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEvSEP2401C7824EAE GC1: CallCtlConnDialingEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: ConnCreatedEv 9200 GC1: ConnInProgressEv 9200 GC1: CallCtlConnOfferedEv 9200 GC1: ConnAlertingEv 9200 GC1: CallCtlConnAlertingEv 9200 GC1: TermConnCreatedEv CTIRD2 GC1: TermConnRingingEv CTIRD2 GC1: CallCtlTermConnRingingEv CTIRD2 GC1: ConnConnectedEv 9200 GC1: CallCtlConnEstablishedEv 9200 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnPassiveEv SEP2401C7824EA3 GC1:CallCtlTermConnBridgedEvSEP2401C7824EA3 GC1: TermConnActiveEv CTIRD2 GC1: CallCtlTermConnTalkingEv CTIRD2 *Call is routed through and offered on CTIRD2 and extended to RDD3 with no delay. B1 calls RDD3 in which active rd is set. User1 invokes Call.connect ("SEP2401C7824EAE", "9001", "40812115"). Call is answered at RDD3 (dn = 40812115). Table 298: Call to Remote Destination Unique to RDP with No Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1320 Message Sequence Charts Message Sequence Charts

Page 1384 diagram

Page 1385

Call Info Events Action CallingAddress = 9001, CalledAddress = 40922095, CurrentCallingAddress = 9001, CurrentCalledAddress = 9200 CurrentCalledPartyDisplayName = RDP2 GC1: CallActiveEv GC1: ConnCreatedEv 9001 GC1: ConnConnectedEv 9001 GC1: CallCtlConnInitatedEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEvSEP2401C7824EAE GC1: CallCtlConnDialingEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: ConnCreatedEv 9200 GC1: ConnInProgressEv 9200 GC1: CallCtlConnOfferedEv 9200 GC1: ConnConnectedEv 9200 GC1: CallCtlConnEstablishedEv 9200 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnPassiveEv SEP2401C7824EA3 GC1: CallCtlTermConnInUseEv SEP2401C7824EA3 *Call is routed through RDP. B1 calls RDDP1. User1 invokes Call.connect ("SEP2401C7824EAE", "9001", "40922095"). Call is offered to RDDP1 after delay and then answered at RDDP1 (dn = 40922095). Table 299: Call to Remote Destination Unique to CTIRD with No Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1321 Message Sequence Charts Message Sequence Charts

Page 1385 diagram

Page 1386

Call Info Events Action CallingAddress = 9001, CalledAddress = 40912116, CurrentCallingAddress = 9001, CurrentCalledAddress = 40912116 CurrentCalledPartyDisplayName

GC1: CallActiveEv GC1: ConnCreatedEv 9001 GC1: ConnConnectedEv 9001 GC1: CallCtlConnInitatedEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEvSEP2401C7824EAE GC1: CallCtlConnDialingEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: ConnCreatedEv 40912116 GC1: ConnConnectedEv 40912116 GC1: CallCtlConnNetworkReachedEv 40912116 GC1: CallCtlConnNetworkAlertingEv 40912116 GC1: CallCtlConnEstablishedEv 40912116 *Direct call between B1 and RDD4. B1 calls RDD4 in which active rd is not set. User1 invokes Call.connect ("SEP2401C7824EAE", "9001", "40912116"). Call is answered at RDD4 (dn = 40912116). Table 300: Call to Remote Destination Unique to CTIRD with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD2 to be RDD4 (dn = 40912116). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40912116", true) on CTIRD2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1322 Message Sequence Charts Message Sequence Charts

Page 1386 diagram

Page 1387

Call Info Events Action CallingAddress = 9001, CalledAddress = 40912116, CurrentCallingAddress = 9001, CurrentCalledAddress = 9200 CurrentCalledPartyDisplayName

GC1: CallActiveEv GC1: ConnCreatedEv 9001 GC1: ConnConnectedEv 9001 GC1: CallCtlConnInitatedEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEvSEP2401C7824EAE GC1: CallCtlConnDialingEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: ConnCreatedEv 9200 GC1: ConnInProgressEv 9200 GC1: CallCtlConnOfferedEv 9200 GC1: ConnAlertingEv 9200 GC1: CallCtlConnAlertingEv 9200 GC1: TermConnCreatedEv CTIRD2 GC1: TermConnRingingEv CTIRD2 GC1: CallCtlTermConnRingingEv CTIRD2 GC1: ConnConnectedEv 9200 GC1: CallCtlConnEstablishedEv 9200 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnPassiveEv SEP2401C7824EA3 GC1:CallCtlTermConnBridgedEvSEP2401C7824EA3 GC1: TermConnActiveEv CTIRD2 GC1: CallCtlTermConnTalkingEv CTIRD2 *Call is routed through and offered on CTIRD2 and extended to RDD4 with no delay. B1 calls RDD4 in which active rd is set. User1 invokes Call.connect ("SEP2401C7824EAE", "9001", "40912116"). Call is answered at RDD4 (dn = 40912116). Multiple Calls Table 301: Make Multiple Calls From Remote Destination with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1323 Message Sequence Charts Multiple Calls

Page 1387 diagram

Page 1388

Call Info Events Action Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. CallingAddress = 2303, CalledAddress = 9000, CurrentCallingAddress = 2303, CurrentCalledAddress = 9000 GC1: CallActiveEv GC1: ConnCreatedEv 2303 GC1: CallCtlConnDialingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: ConnCreatedEv 9000 GC1: ConnInProgressEv 9000 GC1: CallCtlConnOfferedEv 9000 GC1: ConnAlertingEv 9000 GC1: CallCtlConnAlertingEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnRingingEv SEP2401C7824EA3 GC1: CallCtlTermConnRingingEv SEP2401C7824EA3 GC1: ConnConnectedEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 *Call is routed through CTIRD1. RDD1 calls A1. Call is answered at A1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1324 Message Sequence Charts Message Sequence Charts

Page 1388 diagram

Page 1389

Call Info Events Action CallingAddress = 40822077, CalledAddress = 9001, CurrentCallingAddress = 40822077, CurrentCalledAddress = 9001 GC2: CallActiveEv GC2: ConnCreatedEv 9001 GC2: ConnInProgressEv 9001 GC2: CallCtlConnOfferedEv 9001 GC2: ConnCreatedEv 40822077 GC2: ConnConnectedEv 40822077 GC2: CallCtlConnEstablishedEv 40822077 GC2: ConnAlertingEv 9001 GC2: CallCtlConnAlertingEv 9001 GC2: TermConnCreatedEv SEP2401C7824EA3 GC2: TermConnRingingEv SEP2401C7824EA3 GC2: CallCtlTermConnRingingEv SEP2401C7824EA3 GC2: ConnConnectedEv 9001 GC2: CallCtlConnEstablishedEv 9001 GC2: TermConnActiveEv SEP2401C7824EAE GC2: CallCtlTermConnTalkingEv SEP2401C7824EAE *Direct call between RDD1 and B1. RDD1 calls B1. Call is answered at B1. Table 302: Make Multiple Calls To Remote Destination with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1325 Message Sequence Charts Message Sequence Charts

Page 1389 diagram

Page 1390

Call Info Events Action CallingAddress = 9000, CalledAddress = 40822077, CurrentCallingAddress = 9000, CurrentCalledAddress = 2303 GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 2303 GC1: ConnInProgressEv 2303 GC1: CallCtlConnOfferedEv 2303 GC1: ConnAlertingEv 2303 GC1: CallCtlConnAlertingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnRingingEv CTIRD1 GC1: CallCtlTermConnRingingEv CTIRD1 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 *Call is routed through CTIRD1. A1 calls RDD1. User1 invokes Call.connect ("SEP2401C7824EA3", "9000", "40822077"). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1326 Message Sequence Charts Message Sequence Charts

Page 1390 diagram

Page 1391

Call Info Events Action CallingAddress = 9001, CalledAddress = 40822077, CurrentCallingAddress = 9001, CurrentCalledAddress = 2303 GC2: CallActiveEv GC2: ConnCreatedEv 9001 GC2: ConnConnectedEv 9001 GC2: CallCtlConnInitiatedEv 9001 GC2: TermConnCreatedEv SEP2401C7824EAE GC2: TermConnActiveEv SEP2401C7824EAE GC2: CallCtlTermConnTalkingEv SEP2401C7824EAE GC2: CallCtlConnDialingEv 9001 GC2: CallCtlConnEstablishedEv 9001 GC2: ConnCreatedEv 2303 GC2: ConnInProgressEv 2303 GC2: CallCtlConnOfferedEv 2303 GC2: ConnAlertingEv 2303 GC2: CallCtlConnAlertingEv 2303 GC2: TermConnCreatedEv CTIRD1 GC2: TermConnRingingEv CTIRD1 GC2: CallCtlTermConnRingingEv CTIRD1 GC1: CallCtlTermConnHeldEv CTIRD1 GC2: ConnConnectedEv 2303 GC2: CallCtlConnEstablishedEv 2303 GC2: TermConnActiveEv CTIRD1 GC2: CallCtlTermConnTalkingEv CTIRD1 B1 calls RDD1. User1 invokes Call.connect ("SEP2401C7824EAE", "9001", "40822077"). Call is offered on CTIRD1 and then answered. Table 303: Remote Destination First Makes a Call and Then Receives a Call with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1327 Message Sequence Charts Message Sequence Charts

Page 1391 diagram

Page 1392

Call Info Events Action CallingAddress = 2303, CalledAddress = 9000, CurrentCallingAddress = 2303, CurrentCalledAddress = 9000 GC1: CallActiveEv GC1: ConnCreatedEv 2303 GC1: CallCtlConnDialingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: ConnCreatedEv 9000 GC1: ConnInProgressEv 9000 GC1: CallCtlConnOfferedEv 9000 GC1: ConnAlertingEv 9000 GC1: CallCtlConnAlertingEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnRingingEv SEP2401C7824EA3 GC1: CallCtlTermConnRingingEv SEP2401C7824EA3 GC1: ConnConnectedEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 *Call is routed through CTIRD1. RDD1 calls A1. Call is answered at A1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1328 Message Sequence Charts Message Sequence Charts

Page 1392 diagram

Page 1393

Call Info Events Action CallingAddress = 9001, CalledAddress = 40822077, CurrentCallingAddress = 9001, CurrentCalledAddress = 2303 GC2: CallActiveEv GC2: ConnCreatedEv 9001 GC2: ConnConnectedEv 9001 GC2: CallCtlConnInitiatedEv 9001 GC2: TermConnCreatedEv SEP2401C7824EAE GC2: TermConnActiveEv SEP2401C7824EAE GC2: CallCtlTermConnTalkingEv SEP2401C7824EAE GC2: CallCtlConnDialingEv 9001 GC2: CallCtlConnEstablishedEv 9001 GC2: ConnCreatedEv 2303 GC2: ConnInProgressEv 2303 GC2: CallCtlConnOfferedEv 2303 GC2: ConnAlertingEv 2303 GC2: CallCtlConnAlertingEv 2303 GC2: TermConnCreatedEv CTIRD1 GC2: TermConnRingingEv CTIRD1 GC2: CallCtlTermConnRingingEv CTIRD1 GC1: CallCtlTermConnHeldEv CTIRD1 GC2: ConnConnectedEv 2303 GC2: CallCtlConnEstablishedEv 2303 GC2: TermConnActiveEv CTIRD1 GC2: CallCtlTermConnTalkingEv CTIRD1 B1 calls RDD1. User1 invokes Call.connect ("SEP2401C7824EAE", "9001", "40822077"). Call is offered on CTIRD1 and then answered. Table 304: Remote Destination First Receives a Call and Then Makes a Call with Active RDD Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1329 Message Sequence Charts Message Sequence Charts

Page 1393 diagram

Page 1394

Page 1394 diagram

Page 1395

Call Info Events Action CallingAddress = 40822077, CalledAddress = 9001, CurrentCallingAddress = 40822077, CurrentCalledAddress = 9001 GC2: CallActiveEv GC2: ConnCreatedEv 9001 GC2: ConnInProgressEv 9001 GC2: CallCtlConnOfferedEv 9001 GC2: ConnCreatedEv 40822077 GC2: ConnConnectedEv 40822077 GC2: CallCtlConnEstablishedEv 40822077 GC2: ConnAlertingEv 9001 GC2: CallCtlConnAlertingEv 9001 GC2: TermConnCreatedEv SEP2401C7824EA3 GC2: TermConnRingingEv SEP2401C7824EA3 GC2: CallCtlTermConnRingingEv SEP2401C7824EA3 GC2: ConnConnectedEv 9001 GC2: CallCtlConnEstablishedEv 9001 GC2: TermConnActiveEv SEP2401C7824EAE GC2: CallCtlTermConnTalkingEv SEP2401C7824EAE *Direct call between RDD1 and B1. RDD1 calls B1. Call is answered at B1. Table 305: Persistent Call Exists and Remote Destination Initiates Call Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. Create persistent call on CTIRD1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1331 Message Sequence Charts Message Sequence Charts

Page 1395 diagram

Page 1396

Call Info Events Action CallingAddress = 40822077, CalledAddress = 9000, CurrentCallingAddress = 40822077, CurrentCalledAddress = 9000 GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnInProgressEv 9000 GC1: CallCtlConnOfferedEv 9000 GC1: ConnCreatedEv 40822077 GC1: ConnConnectedEv 40822077 GC1: CallCtlConnEstablishedEv 40822077 GC1: ConnAlertingEv 9000 GC1: CallCtlConnAlertingEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnRingingEv SEP2401C7824EA3 GC1: CallCtlTermConnRingingEv SEP2401C7824EA3 GC1: ConnConnectedEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 *Direct call between RDD1 and A1 RDD1 calls A1. Call is answered at A1. Disconnect the persistent call. Call disconnects successfully. A drops the call. Call disconnects successfully. Table 306: Persistent Call Exists and Make Call to Remote Destination Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. Create persistent call on CTIRD1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1332 Message Sequence Charts Message Sequence Charts

Page 1396 diagram

Page 1397

Call Info Events Action CallingAddress = 9000, CalledAddress = 40822077, CurrentCallingAddress = 9000, CurrentCalledAddress = 2303 GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 2303 GC1: ConnInProgressEv 2303 GC1: CallCtlConnOfferedEv 2303 GC1: ConnAlertingEv 2303 GC1: CallCtlConnAlertingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnRingingEv CTIRD1 GC1: CallCtlTermConnRingingEv CTIRD1 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 *Call is offered on CTIRD1. A1 calls RDD1. User1 invokes Call.connect ("SEP2401C7824EA3", "9000", "40822077"). Let "ex" be an instance of PlatformException: ( (CiscoJtapiException) ex).getErrorCode () = CiscoJtapiException. CTIERR_DISCONNECT_ PERSISTENT_CALL_FAILED_ CALL_ACTIVE Disconnect the persistent call. Disconnect throws exception. A drops the call. Call disconnects successfully. Disconnect the persistent call. Call disconnects successfully. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1333 Message Sequence Charts Message Sequence Charts

Page 1397 diagram

Page 1398

Table 307: Call to Remote Destination with Active RDD and Call Forward All Configured on CTIRD with Only CTIRD Observed Call Info Events Action Configure CallForwardAll on CTIRD1 to 2302. ProvInServiceEv User1 opens Provider and adds a provider observer. Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. CallingAddress = 9000, CalledAddress = 2303, CurrentCallingAddress = 9000, CurrentCalledAddress = 2303 GC1: CallActiveEv GC1: ConnCreatedEv 2303 GC1: ConnInProgressEv 2303 GC1: CallCtlConnOfferedEv 2303 GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnAlertingEv 2303 GC1: CallCtlConnAlertingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnRingingEv CTIRD1 GC1: CallCtlTermConnRingingEv CTIRD1 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 *Nurd features disables CFA. A1 calls RDD1. User1 invokes Call.connect ("SEP2401C7824EA3", "9000", "40822077"). Table 308: Max Calls Limit Reached Where CTIRD Has 2 Calls to the Remote Destination and CTIRD Still Tries to Make a Call Call Info Events Action Set Max Calls = 2 and Busy Trigger = 2 ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1334 Message Sequence Charts Message Sequence Charts

Page 1398 diagram

Page 1399

Call Info Events Action Set active remote destination of CTIRD1 to be RDD1 (dn = 40822077). User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("40822077", true) on CTIRD1. CallingAddress = 9000, CalledAddress = 40822077, CurrentCallingAddress = 9000, CurrentCalledAddress = 2303 GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 2303 GC1: ConnInProgressEv 2303 GC1: CallCtlConnOfferedEv 2303 GC1: ConnAlertingEv 2303 GC1: CallCtlConnAlertingEv 2303 GC1: TermConnCreatedEv CTIRD1 GC1: TermConnRingingEv CTIRD1 GC1: CallCtlTermConnRingingEv CTIRD1 GC1: ConnConnectedEv 2303 GC1: CallCtlConnEstablishedEv 2303 GC1: TermConnActiveEv CTIRD1 GC1: CallCtlTermConnTalkingEv CTIRD1 A1 calls RDD1. User1 invokes Call.connect ("SEP2401C7824EA3", "9000", "40822077"). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1335 Message Sequence Charts Message Sequence Charts

Page 1399 diagram

Page 1400

Call Info Events Action CallingAddress = 9001, CalledAddress = 40822077, CurrentCallingAddress = 9001, CurrentCalledAddress = 2303 GC2: CallActiveEv GC2: ConnCreatedEv 9001 GC2: ConnConnectedEv 9001 GC2: CallCtlConnInitiatedEv 9001 GC2: TermConnCreatedEv SEP2401C7824EAE GC2: TermConnActiveEv SEP2401C7824EAE GC2: CallCtlTermConnTalkingEv SEP2401C7824EAE GC2: CallCtlConnDialingEv 9001 GC2: CallCtlConnEstablishedEv 9001 GC2: ConnCreatedEv 2303 GC2: ConnInProgressEv 2303 GC2: CallCtlConnOfferedEv 2303 GC2: ConnAlertingEv 2303 GC2: CallCtlConnAlertingEv 2303 GC2: TermConnCreatedEv CTIRD1 GC2: TermConnRingingEv CTIRD1 GC2: CallCtlTermConnRingingEv CTIRD1 GC1: CallCtlTermConnHeldEv CTIRD1 GC2: ConnConnectedEv 2303 GC2: CallCtlConnEstablishedEv 2303 GC2: TermConnActiveEv CTIRD1 GC2: CallCtlTermConnTalkingEv CTIRD1 B1 calls RDD1. User1 invokes Call.connect ("SEP2401C7824EAE", "9001", "40822077"). Call is offered on CTIRD1 and then answered. Let "ex" be an instance of PlatformException: ( (CiscoJtapiException) ex).getErrorCode () = CiscoJtapiException. CTIERR_MAXCALL_ LIMIT_REACHED CTIRD makes outgoing call to 2302. User1 invokes Call.connect ("CTIRD1", "2303", "2302"). Fail to make outgoing call since max calls limit reached so throws exception. Revert back to orig values. Set Max Calls = 4 and Busy Trigger = 2 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1336 Message Sequence Charts Message Sequence Charts

Page 1400 diagram

Page 1401

Partition Support Since the address hashing mechanism in JTAPI has changed, this feature is expected to have performance degradation in address lookup time and during load tests. Using getPartition() API The example given below illustrates how getPartition(), will be used by JTAPI and applications, to differentiate between addresses having same DN but belonging to different partitions. Using getPartition() API In this case, there are three addresses which belong to three different partitions: A(2001, P1), B(2001, P2) and C(2001, P3), where 2001 indicates DN and P1, P2, and P3 denote different partitions. When JTAPI calls provider.getAddress(“2001”), the provider object will return an array of three address objects containing A, B and C, since all of them have the same DN. The application and JTAPI will distinguish between the three addresses by using the getPartition() method of the address object. Using getAddress (String Number String Partition) Consider the example shown below to see how JTAPI will use the getAddress (String number, String partition) API to retrieve the address object corresponding to a particular DN and partition when there are multiple addresses with same DN and different partitions. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1337 Message Sequence Charts Partition Support

Image 1 from page 1401

Page 1401 content

Page 1402

Using getAddress (String Number, String Partition) In this case, there are three addresses which belong to three different partitions. Let us denote them by A(2001, P1), B(2001, P2) and C(2001, P3), where 2001, indicates DN and P1, P2, P3 denote different partitions. When JTAPI calls provider.getAddress(“2001”, “P1”), the provider object will return the address object which has the same DN i.e. 2001 and the same partition info, that is P1–as provided in the API. In this case, the address object A will be returned to the application. Simple Call Scenario Consider the following scenario where A calls B. A has DN 1000 and calls B which also has DN 1000. A belongs to partition P1 and B belongs to partition P2. The following diagram illustrates the various events and the results of API calls pertaining to this scenario, which are relevant to partition support feature. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1338 Message Sequence Charts Message Sequence Charts

Image 1 from page 1402

Page 1402 content

Page 1403

Figure 20: Simple Call Scenario Park DN Park DNs are also treated as addresses in JTAPI. Hence, the same treatment given to normal DN is also given to park DN. The following message flow illustrates how an application will use park DN partition information in a call where park DNs are involved. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1339 Message Sequence Charts Park DN

Image 1 from page 1403

Page 1403 content

Page 1404

Park DN Scenario When the application is monitoring park DN, it is possible to have the park DN to be the same as a regular DN (while both belong to different partitions). In this case, C is a park DN having same DN value as A and B while belonging to a different partition. A receives a call and parks the call at C. B unparks the call. While the call is parked, and unparked, CiscoProvCallParkEv is generated. The API getParkingPartyPartition(), getParkedPartyPartition() and getParkPartyPartition() return the associated address objects as shown in the figure. Partition Change Partition attribute is similar to the DN attribute of an address. Hence, whenever the partition attribute changes, the address object has to be destroyed and recreated. When the partition information of an address is changed, JTAPI will be restarted during which the current address objects will be deleted and new address objects will be created, reflecting the changed partition information. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1340 Message Sequence Charts Partition Change

Image 1 from page 1404

Page 1404 content

Page 1405

Change in Partition When the partition information of an address is changed, the address object will be destroyed and a new address object will be created. The new address object will have the new partition information. In the example given, Address A's partition string was changed to P4. Hence, the current address object of A will be deleted and a new address object will be created. A query on the old address object using A.getPartition() will retrieve “P1”, while the same query on the new object will return “P4”. When the address partition changes, applications should query the address objects to update their partition information. JTAPI Partition Support The common assumption for all of the following use cases is that CTI provides partition information for all the lines which the JTAPI opens in the response message and JTAPI stores the partition information for every address it maintains. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1341 Message Sequence Charts JTAPI Partition Support

Image 1 from page 1405

Page 1405 content

Page 1406

Result Expected Behavior Scenario Pre-Condition S.No. Call is established between A and B Two address objects are created, one for A and one for B. All the appropriate call related events are delivered to both the addresses. Calls between addresses with same DN in different device but different partitions should go through. A and B are two addresses in the same cluster with same DN and different partitions (P1, P2) and in same cluster. A calls B. CSS of A has B’s partition in it first. 1 Call is established between A and B. Two address objects are created, one for A and one for B. All the appropriate call related events are delivered to both the addresses. Calls between addresses with same DN in same device but different partitions should go through. A and B are two addresses with same DN in same device but different partitions (P1, P2) and in same cluster. A calls B. CSSof A has B’s partition in it first. 2 C is successfully able to unpark the call from park DN. JTAPI should allow C to unpark the call from park DN. A calls B. B parks the call. C unparks the call from a park DN which is same as C’s DN. A, B, and C are three different addresses with different DN. (P1, P2, P3). A park DN is configured with same DN as C and different partition (P4). 3 A is able to call B. B should be able to park the call at the park DN. C should be able to pick up the call. JTAPI should allow C to unpark the call from park DN. A calls B, B parks call at park DN. C unparks the call. A, B, and C are three different addresses having the same DN and different partitions (P1, P2, P3). Apark DN is configured with same DN but belonging to a different partition (P4) 4 JTAPI maintains the address objects based on partition info and DN. Three address objects are returned each corresponding to A, B and C. JTAPI calls getPartitionAddress(DN of A). A, B, and C are three different addresses with same DN and different partitions (P1, P2, and P3) 5 Partition strings of the addresses are returned correctly. Application calls getPartition() on the address objects of A and B. A and B are addresses with same DN but belong to different partitions (P1, P2). 6 Address objects for A and B are created successfully. Lines A and B will be opened, but since they have different DN, user need not specify the partition info. DN alone is sufficient to open the lines, but users can also give partition info and both modes of opening lines will be supported by JTAPI. JTAPI supports old API to open lines when DN is different. There will be no change in behavior. A and B are two different addresses (different DNs) belonging to different partitions. A and B are in the control list of the same user. Provider open is completed and the lines are opened. 7 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1342 Message Sequence Charts Message Sequence Charts

Page 1406 diagram

Page 1407

Result Expected Behavior Scenario Pre-Condition S.No. New partition information is reflected in the new address object. JTAPI will delete the current address object and create a new address object for A when it comes in service again. By querying the partition info of this address object, user should get changed partition info. Partition information of a DN is changed. JTAPI should reflect new partition information. A is an address in the control list of user and is opened by the user. From the CM admin page the partition information of A is changed. The device is restarted after this. 8 Persistent Connection Use Cases The following pre-conditions apply to all persistent call use cases, unless specified: • The provider is in IN_SERVICE state. • All addresses and terminals are already in service. • Device A (CTI Remote Device - Name: "CTIRDtapi", Line A1 (dn: 881000)) Remote destination 1 (Name: "rd", Number: "78000") • Device B (IP Phone - Name: "SEP001319ACCA26", Line B1 (dn: 1000)) • Device C (IP Phone - Name: "SEP00156247EE60", Line C1 (dn: 2000)) • User1 has in its control list: Devices A, B and C. All devices and lines are observed. Table 309: Call createPersistentCall() on an Address That Is Not Configured to a Remote Terminal Device, i.e. on an IP Phone Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. COMMAND_NOT_IMPLEMENTED _ON_DEVICE. Caught exception com.cisco.jtapi.PlatformException: Internal callprocessing error :Device does not support the command User1 invokes CiscoAddress. createPersistentCall ("SEP00156247EE60", "5000", "remote") on device C. Table 310: Call createPersistentCall()on an Address That Is Configured to a Remote Terminal Device Where Active RD Is Not Set Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1343 Message Sequence Charts Persistent Connection Use Cases

Page 1407 diagram

Page 1408

Call Info Events Action Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_REMOTE_DEVICE_REQUEST _FAILED_ACTIVE_RD_NOT_SET Caught exception com.cisco.jtapi.PlatformException: The active remote destination is not set. User1 invokes CiscoAddress. createPersistentCall ("CTIRDjtapi", "5000", "remote") on device A. Table 311: Call createPersistentCall() on an Address That Is Configured to a Remote Terminal Device and Where Active RD Is Set; Verify That Persistent Call Is Connected Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. A.getActiveRemoteDestinations() = CiscoRemoteDestinationInfo[1]. CiscoRemoteDestinationInfo[0]. getRemoteDestinationNumber() = "78000" CiscoRemoteDestinationInfo[0]. getIsActiveRD() = true. CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal .setActiveRemoteDestination ("78000", true) on device A. CallingAddress = 5000, CalledAddress = 8881000, CurrentCallingAddress = 5000, CurrentCalledAddress = 8881000 GC1: CallActiveEv GC1: ConnCreatedEv 8881000 GC1: ConnInProgressEv 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnCreatedEv 5000 GC1: ConnConnectedEv 5000 GC1: CallCtlConnEstablishedEv 5000 GC1: ConnAlertingEv 8881000 GC1: CallCtlConnAlertingEv 8881000 GC1: TermConnCreatedEv CTIRDjtapi GC1: TermConnRingingEv CTIRDjtapi GC1: CallCtlTermConnRingingEv CTIRDjtapi User1 invokes CiscoAddress. createPersistentCall ("CTIRDjtapi", "5000", "remote") on device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1344 Message Sequence Charts Message Sequence Charts

Page 1408 diagram

Page 1409

Call Info Events Action CallingAddress = 5000, CalledAddress = 8881000, CurrentCallingAddress = 5000, CurrentCalledAddress = 8881000 GC1: ConnConnectedEv 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnActiveEv CTIRDjtapi GC1: CallCtlTermConnTalkingEv CTIRDjtapi Call answered at remote destination, dn = 78000 ((CiscoAddress.getPersistentConnection ("CTIRDjtapi")).getCall()).isPersistentCall() = true. User1 invokes CiscoAddress. getPersistentConnection ("CTIRDjtapi") and verify that the connection for the persistent call is returned and uses that to get the Call object and confirm it is for the persistent call. Provider.getCalls() = null User1 invokes Provider.getCalls() Address.getConnections() on line A = null User1 invokes Address.getConnections() on line A. Terminal.getTerminalConnections() on device A = null User1 invokes Terminal. getTerminalConnections() on device A. GC1: ConnDisconnectedEv 5000 GC1: CallCtlConnDisconnectedEv 5000 GC1: TermConnDroppedEv CTIRDjtapi GC1: CallCtlTermConnDroppedEv CTIRDjtapi GC1: ConnDisconnectedEv 8881000 GC1: CallCtlConnDisconnectedEv 8881000 GC1: CallInvalidEv Disconnect/drop the persistent call. User1 invokes either Call.drop() or Connection.disconnect() Table 312: Call createPersistentCall() on an Address Configured to a Remote Terminal Device Where a Persistent Call Already Exists Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_PERSISTENT_CALL_EXISTS. Caught exception com.cisco.jtapi.PlatformException: Persistent Call exists. User1 invokes CiscoAddress. createPersistentCall("CTIRDjtapi", "6000", "remote2") on device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1345 Message Sequence Charts Message Sequence Charts

Page 1409 diagram

Page 1410

Table 313: Call createPersistentCall() on an Address That Is Configured to a Remote Terminal Device and Where Active Rd Is Set; Verify That Persistent Call Is Connected and Then Have Remote Destination Hang Up Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. A.getActiveRemoteDestinations() = CiscoRemoteDestinationInfo[1]. CiscoRemoteDestination Info[0].getRemoteDestinationNumber() = "78000" CiscoRemoteDestination Info[0].getIsActiveRD() = true. CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("78000", true) on device A. CallingAddress = 5000, CalledAddress = 8881000, CurrentCallingAddress = 5000, CurrentCalledAddress = 8881000 GC1: CallActiveEv GC1: ConnCreatedEv 8881000 GC1: ConnInProgressEv 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnCreatedEv 5000 GC1: ConnConnectedEv 5000 GC1: CallCtlConnEstablishedEv 5000 GC1: ConnAlertingEv 8881000 GC1: CallCtlConnAlertingEv 8881000 GC1: TermConnCreatedEv CTIRDjtapi GC1: TermConnRingingEv CTIRDjtapi GC1: CallCtlTermConnRingingEv CTIRDjtapi User1 invokes CiscoAddress. createPersistentCall("CTIRDjtapi", "5000", "remote") on device A. CallingAddress = 5000, CalledAddress = 8881000, CurrentCallingAddress = 5000, CurrentCalledAddress = 8881000 GC1: ConnConnectedEv 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnActiveEv CTIRDjtapi GC1: CallCtlTermConnTalkingEv CTIRDjtapi Call answered at remote destination, dn = 78000 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1346 Message Sequence Charts Message Sequence Charts

Page 1410 diagram

Page 1411

Call Info Events Actions GC1: ConnDisconnectedEv 5000 GC1: CallCtlConnDisconnectedEv 5000 GC1: TermConnDroppedEv CTIRDjtapi GC1: CallCtlTermConnDroppedEv CTIRDjtapi GC1: ConnDisconnectedEv 8881000 GC1: CallCtlConnDisconnectedEv 8881000 GC1: CallInvalidEv Remote destination with dn = 78000 hangs up. Table 314: Call createPersistentCall() on an Address That Is Configured to a Remote Terminal Device and Where Active RD = True; Verify That Persistent Call Is Connected; Set Active RD = False and Verify That Persistent Call Is Dropped Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. A.getActiveRemoteDestinations() = CiscoRemoteDestination Info[1]. CiscoRemoteDestination Info[0].getRemoteDestinationNumber() = "78000" CiscoRemoteDestination Info[0].getIsActiveRD() = true. CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("78000", true) on device A CallingAddress = 5000, CalledAddress = 8881000, CurrentCallingAddress = 5000, CurrentCalledAddress = 8881000 GC1: CallActiveEv GC1: ConnCreatedEv 8881000 GC1: ConnInProgressEv 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnCreatedEv 5000 GC1: ConnConnectedEv 5000 GC1: CallCtlConnEstablishedEv 5000 GC1: ConnAlertingEv 8881000 GC1: CallCtlConnAlertingEv 8881000 GC1: TermConnCreatedEv CTIRDjtapi GC1: TermConnRingingEv CTIRDjtapi GC1: CallCtlTermConnRingingEv CTIRDjtapi User1 invokes CiscoAddress. createPersistentCall("CTIRDjtapi", "5000", "remote") on device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1347 Message Sequence Charts Message Sequence Charts

Page 1411 diagram

Page 1412

Call Info Events Actions CallingAddress = 5000, CalledAddress = 8881000, CurrentCallingAddress = 5000, CurrentCalledAddress = 8881000 GC1: ConnConnectedEv 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnActiveEv CTIRDjtapi GC1: CallCtlTermConnTalkingEv CTIRDjtapi Call answered at remote destination, dn = 78000 A.getActiveRemoteDestinations() = CiscoRemoteDestination Info[1]. CiscoRemoteDestination Info[0].getRemoteDestinationNumber() = "78000" CiscoRemoteDestination Info[0].getIsActiveRD() = false CiscoProvTerminalRemote DestinationChangedEv See persistent call gets dropped: GC1: ConnDisconnectedEv 5000 GC1: CallCtlConnDisconnectedEv 5000 GC1: TermConnDroppedEv CTIRDjtapi GC1: CallCtlTermConnDroppedEv CTIRDjtapi GC1: ConnDisconnectedEv 8881000 GC1: CallCtlConnDisconnectedEv 8881000 GC1: CallInvalidEv User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("78000", false) on device A. Table 315: Call createPersistentCall() on an Address That Is Configured to a Remote Terminal Device and Where Active RD = True; Verify That Persistent Call Is Connected; Make Incoming Customer Call to Same Remote Terminal Device Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. A.getActiveRemoteDestinations() = CiscoRemoteDestination Info[1]. CiscoRemoteDestination Info[0].getRemoteDestinationNumber() = "78000" CiscoRemoteDestination Info[0].getIsActiveRD() = true. CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("78000", true) on device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1348 Message Sequence Charts Message Sequence Charts

Page 1412 diagram

Page 1413

Call Info Events Actions CallingAddress = 5000, CalledAddress = 8881000, CurrentCallingAddress = 5000, CurrentCalledAddress = 8881000 GC1: CallActiveEv GC1: ConnCreatedEv 8881000 GC1: ConnInProgressEv 8881000 GC1: CallCtlConnOfferedEv 8881000 GC1: ConnCreatedEv 5000 GC1: ConnConnectedEv 5000 GC1: CallCtlConnEstablishedEv 5000 GC1: ConnAlertingEv 8881000 GC1: CallCtlConnAlertingEv 8881000 GC1: TermConnCreatedEv CTIRDjtapi GC1: TermConnRingingEv CTIRDjtapi GC1: CallCtlTermConnRingingEv CTIRDjtapi User1 invokes CiscoAddress. createPersistentCall("CTIRDjtapi", "5000", "remote") on device A. CallingAddress = 5000, CalledAddress = 8881000, CurrentCallingAddress = 5000, CurrentCalledAddress = 8881000 GC1: ConnConnectedEv 8881000 GC1: CallCtlConnEstablishedEv 8881000 GC1: TermConnActiveEv CTIRDjtapi GC1: CallCtlTermConnTalkingEv CTIRDjtapi Call answered at remote destination, dn = 78000 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1349 Message Sequence Charts Message Sequence Charts

Page 1413 diagram

Page 1414

Call Info Events Actions CallingAddress = 1000, CalledAddress = 8881000, CurrentCallingAddress = 1000, CurrentCalledAddress = 8881000 GC2: CallActiveEv GC2: ConnCreatedEv 1000 GC2: ConnConnectedEv 1000 GC2: CallCtlConnInitiatedEv 1000 GC2: TermConnCreatedEv SEP001319ACCA26 GC2: TermConnActiveEv SEP001319ACCA26 GC2: CallCtlTermConnTalkingEv SEP001319ACCA26 GC2: CallCtlConnDialingEv 1000 GC2: CallCtlConnEstablishedEv 1000 GC2: ConnCreatedEv 8881000 GC2: ConnInProgressEv 8881000 GC2: CallCtlConnOfferedEv 8881000 GC2: ConnAlertingEv 8881000 GC2: CallCtlConnAlertingEv 8881000 GC2: TermConnCreatedEv CTIRDjtapi GC2: TermConnRingingEv CTIRDjtapi GC2: CallCtlTermConnRingingEv CTIRDjtapi Call.connect("SEP001319ACCA26", "1000", "8881000") GC2: ConnConnectedEv 8881000 GC2: CallCtlConnEstablishedEv 8881000 GC2: TermConnActiveEv CTIRDjtapi GC2: CallCtlTermConnTalkingEv CTIRDjtapi Call is answered at device A A.getActiveRemoteDestinations() = CiscoRemoteDestination Info[1]. CiscoRemoteDestination Info[0].getRemoteDestinationNumber() = "78000" CiscoRemoteDestination Info[0].getIsActiveRD() = false. CiscoProvTerminalRemote DestinationChangedEv Both persistent call with GC1 and customer call with GC2 are not dropped/disconnected even though active rd = false. User1 invokes CiscoRemoteTerminal. setActiveRemoteDestination ("78000", false) on device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1350 Message Sequence Charts Message Sequence Charts

Page 1414 diagram

Page 1415

Call Info Events Actions GC2: TermConnDroppedEv SEP001319ACCA26 GC2: CallCtlTermConnDroppedEv SEP001319ACCA26 GC2: ConnDisconnectedEv 1000 GC2: CallCtlConnDisconnectedEv 1000 GC2: TermConnDroppedEv CTIRDjtapi GC2: CallCtlTermConnDroppedEv CTIRDjtapi GC2: ConnDisconnectedEv 8881000 GC2: CallCtlConnDisconnectedEv 8881000 GC2: CallInvalidEv Since there are no active calls on device A and active rd is now false, the persistent call with GC1 is now dropped/disconnected. GC1: ConnDisconnectedEv 5000 GC1: CallCtlConnDisconnectedEv 5000 GC1: TermConnDroppedEv CTIRDjtapi GC1: CallCtlTermConnDroppedEv CTIRDjtapi GC1: ConnDisconnectedEv 8881000 GC1: CallCtlConnDisconnectedEv 8881000 GC1: CallInvalidEv Customer call with GC2 is disconnected/dropped. User1 invokes either Call.drop() or Connection.disconnect() on the call with GC2. Table 316: Have a Persistent Call and Customer Call Connected; Invoke hold() on the Persistent Call Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1351 Message Sequence Charts Message Sequence Charts

Page 1415 diagram

Page 1416

Call Info Events Actions Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION_NOT _ALLOWED_ON_PERSISTENT_CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Invoke hold() on the persistent call with GC1. Table 317: Have a Persistent Call and Customer Call Connected; Invoke startRecording() on the Persistent Call Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION_NOT _ALLOWED_ON_PERSISTENT_CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Invoke startRecording() on the persistent call with GC1. Table 318: Have a Persistent Call and Customer Call Connected; Invoke stopRecording() on the Persistent Call Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION_NOT _ALLOWED_ON_PERSISTENT_CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Invoke stopRecording() on the persistent call with GC1. Make sure Selective call recording is enabled. Table 319: Have a Persistent Call and Customer Call Connected; Invoke conference() on the Persistent Call Where Persistent Call Is Primary Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1352 Message Sequence Charts Message Sequence Charts

Page 1416 diagram

Page 1417

Call Info Events Actions Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Invoke conference() where persistent call with GC1 is the primary call and customer call with GC2 is the secondary call (jtapi internally calling join() for this). Table 320: Have a Persistent Call and Customer Call Connected; Invoke conference() on the Persistent Call Where Persistent Call Is Secondary Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Invoke conference() where customer call with GC2 is primary call and persistent call with GC1 is secondary call (jtapi internally calling join() for this). Table 321: Have a Persistent Call and Customer Call Connected; Invoke park() on the Persistent Call Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation not allowed. Invoke park(). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1353 Message Sequence Charts Message Sequence Charts

Page 1417 diagram

Page 1418

Table 322: Have a Persistent Call and Customer Call Connected; Invoke transfer() on the Persistent Call Where PC Is Primary Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Invoke transfer(Call) where persistent call with GC1 is primary call and customer call with GC2 is secondary. Table 323: Have a Persistent Call and Customer Call Connected; Invoke transfer() on the Persistent Call Where PC Is Primary to Another DN Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Invoke transfer(String address) where persistent call with GC1 is primary call to line C (dn = 2000). Table 324: Have a Persistent Call and Customer Call Connected; Invoke transfer() on the Persistent Call Where PC Is Secondary Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1354 Message Sequence Charts Message Sequence Charts

Page 1418 diagram

Page 1419

Call Info Events Actions Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Invoke transfer(Call) where customer call with GC2 is primary call and persistent call with GC1 is secondary. Table 325: Have a Persistent Call and Customer Call Connected; Invoke consult() on the Persistent Call Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Make consult call from device A to line C (dn = 2000). Table 326: Have a Persistent Call and Customer Call Connected; Invoke pickup() on the Persistent Call Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation not allowed. Invoke pickup("8881000") on device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1355 Message Sequence Charts Message Sequence Charts

Page 1419 diagram

Page 1420

Table 327: Have a Persistent Call and Customer Call Connected; Invoke otherPickup() on the Persistent Call Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation not allowed. Invoke otherPickup("8881000") on device A. Table 328: Have a Persistent Call and Customer Call Connected; Invoke redirect() on the Persistent Call Which Should Be Rejected Call Info Events Actions ProvInServiceEv User1 opens Provider and adds a provider observer. Assume already have a persistent call with GC1 and customer call with GC2. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_OPERATION _NOT_ALLOWED _ON_PERSISTENT _CALL. Caught exception com.cisco.jtapi.PlatformException: Operation is not allowed on a Persistent Call. Invoke redirect("2000") on the persistent call. Play Announcement Prerequisites Pre-conditions to all play announcement use cases, unless specified otherwise: • Provider is in IN_SERVICE state • All addresses and terminals are already in service. • Device A (CTI Remote Device - Name: "CTIRD3", Line A1 (dn: 9202)) • o Remote destination 1 (Name: "C1_CTIRD3_RDD1", Number: "339006") • Device B (IP Phone - Name: "SEP2401C7824EA3", Line B1 (dn: 9000)) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1356 Message Sequence Charts Play Announcement

Page 1420 diagram

Page 1421

• Announcement Identifier is Welcome Greeting Sample. • User1 has in its control list: Devices A, and B. All devices and lines are observed. Basic Play Announcement Use Cases Basic Play Announcement Use Cases Table 329: Play Announcement on CTI Remote Device with Persistent Call Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEvCTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 User1 invokes CiscoAddress. createPersistentCall("CTIRD3", "1000", "remote") on device A and remote destination answers. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1357 Message Sequence Charts Basic Play Announcement Use Cases

Page 1421 diagram

Page 1422

Call Info Events Action CiscoAnnouncementStartedEv. getAnnouncementID() = Welcome Greeting Sample GC2: CallActiveEv GC2: ConnCreatedEv 9202 GC2: CallCtlConnDialingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalkingEv CTIRD3 GC2: ConnConnectedEv 9202 GC2: CallCtlConnOfferedEv Unknown User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. Feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC2: CallCtlConnEstablishedEv 9202 GC2: ConnCreatedEv Unknown GC2: ConnInProgressEv Unknown CiscoAnnouncementStartedEv. will have feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC2: ConnConnectedEv Unknown GC2: CallCtlConnEstablishedEv Unknown GC2: CiscoAnnouncementStartedEv. Provider.getCalls() returns the announcement call. User1 invokes Provider.getCalls() Address.getConnections() on line A returns the Connection for the announcement call. User1 invokes Address.getConnections() on line A. Terminal.getTerminalConnections() on device A returns the TerminalConnection for the announcement call. User1 invokes Terminal.getTerminalConnections() on device A. Table 330: Play Announcement That Stopped Playing Before the End of the Announcement Call info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1358 Message Sequence Charts Message Sequence Charts

Page 1422 diagram

Page 1423

Call info Events Action CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEvCTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 User1 invokes CiscoAddress. createPersistentCall("CTIRD3", "1000", "remote") on device A and remote destination answers. CiscoAnnouncementStartedEv. getAnnouncementID() = Welcome Greeting Sample GC2: CallActiveEv GC2: ConnCreatedEv 9202 GC2: CallCtlConnDialingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalkingEv CTIRD3 GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC2: ConnCreatedEv Unknown GC2: ConnInProgressEv Unknown GC2: CallCtlConnOfferedEv Unknown GC2: ConnConnectedEv Unknown GC2: CallCtlConnEstablishedEv Unknown CiscoAnnouncementStartedEv. will have feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC2: CiscoAnnouncementStartedEv. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1359 Message Sequence Charts Message Sequence Charts

Page 1423 diagram

Page 1424

Call info Events Action Provider.getCalls() returns the announcement call. User1 invokes Provider.getCalls() Address.getConnections() on line A returns the Connection for the announcement call. User1 invokes Address.getConnections() on line A. Terminal.getTerminalConnections() on device A returns the TerminalConnection for the announcement call. User1 invokes Terminal.getTerminalConnections() on device A. CiscoAnnouncementEndedEv. getSuccess() = true. CiscoAnnouncementEndedEv. getErrorCode() = 0 CiscoAnnouncementEndedEv. getErrorDescription() = No Error GC2: CiscoAnnouncementEndedEv GC2: TermConnDroppedEv CTIRD3 GC2: CallCtlTermConnDroppedEv CTIRD3 GC2: ConnDisconnectedEv Unknown GC2: CallCtlConnDisconnectedEv Unknown GC2: ConnDisconnectedEv 9202 GC2: CallCtlConnDisconnectedEv 9202 GC2: CallInvalidEv GC2: CallObservationEndedEv Disconnect/drop the announcement call. User1 invokes either Call.drop() or Connection.disconnect() to stop the announcement before it finishes playing. Table 331: Play Announcement with Incoming Customer Call in Ringing State Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1360 Message Sequence Charts Message Sequence Charts

Page 1424 diagram

Page 1425

Page 1425 diagram

Page 1426

Call Info Events Action GC2: CallActiveEv GC2: ConnCreatedEv 9000 GC2: ConnConnectedEv 9000 GC2: CallCtlConnInitiatedEv 9000 GC2: TermConnCreatedEv SEP2401C7824EA3 GC2: TermConnActiveEv SEP2401C7824EA3 GC2: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC2: CallCtlConnDialingEv 9000 GC2: CallCtlConnEstablishedEv 9000 GC2: ConnCreatedEv 9202 GC2: ConnInProgressEv 9202 GC2: CallCtlConnOfferedEv 9202 GC2: ConnAlertingEv 9202 GC2: CallCtlConnAlertingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnRingingEv CTIRD3 GC2: CallCtlTermConnRingingEvCTIRD3 User1 invokes Call.connect("SEP2401C7824EA3", "9000", "9202") and is left ringing. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1362 Message Sequence Charts Message Sequence Charts

Page 1426 diagram

Page 1427

Call Info Events Action CiscoAnnouncementStartedEv. getAnnouncementID() = Welcome Greeting Sample GC3: CallActiveEv GC3: ConnCreatedEv 9202 GC3: CallCtlConnDialingEv 9202 GC3: TermConnCreatedEv CTIRD3 GC3: TermConnActiveEv CTIRD3 GC3: CallCtlTermConnTalkingEv CTIRD3 GC3: ConnConnectedEv 9202 GC3: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: ConnCreatedEv Unknown GC3: ConnInProgressEv Unknown GC3: CallCtlConnOfferedEv Unknown GC3: ConnConnectedEv Unknown GC3: CallCtlConnEstablishedEv Unknown CiscoAnnouncementStartedEv. will have feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: CiscoAnnouncementStartedEv. Provider.getCalls() returns both the customer call and the announcement call User1 invokes Provider.getCalls() Address.getConnections() on line A returns the Connection for both the customer call and the announcement call. User1 invokes Address.getConnections() on line A. Terminal.getTerminalConnections() on device A returns the TerminalConnection for both the customer call and the announcement call. User1 invokes Terminal.getTerminalConnections() on device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1363 Message Sequence Charts Message Sequence Charts

Page 1427 diagram

Page 1428

Call Info Events Action CiscoAnnouncementEndedEv. getSuccess() = true. CiscoAnnouncementEndedEv. getErrorCode() = 0 CiscoAnnouncementEndedEv. getErrorDescription() = No Error GC3: CiscoAnnouncementEndedEv GC3: TermConnDroppedEv CTIRD3 GC3: CallCtlTermConnDroppedEv CTIRD3 GC3: ConnDisconnectedEv Unknown GC3: CallCtlConnDisconnectedEv Unknown GC3: ConnDisconnectedEv 9202 GC3: CallCtlConnDisconnectedEv 9202 GC3: CallInvalidEv GC3: CallObservationEndedEv After announcement finishes playing, call is disconnected. Table 332: Play Announcement Where the Call Is Answered Before the Full Message Plays Call Info Event Action ProvInServiceEv User1 opens Provider and adds a provider observer. CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEvCTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 User1 invokes CiscoAddress. createPersistentCall("CTIRD3", "1000", "remote") on device A and remote destination answers. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1364 Message Sequence Charts Message Sequence Charts

Page 1428 diagram

Page 1429

Call Info Event Action GC2: CallActiveEv GC2: ConnCreatedEv 9000 GC2: ConnConnectedEv 9000 GC2: CallCtlConnInitiatedEv 9000 GC2: TermConnCreatedEv SEP2401C7824EA3 GC2: TermConnActiveEv SEP2401C7824EA3 GC2: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC2: CallCtlConnDialingEv 9000 GC2: CallCtlConnEstablishedEv 9000 GC2: ConnCreatedEv 9202 GC2: ConnInProgressEv 9202 GC2: CallCtlConnOfferedEv 9202 GC2: ConnAlertingEv 9202 GC2: CallCtlConnAlertingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnRingingEv CTIRD3 GC2: CallCtlTermConnRingingEvCTIRD3 User1 invokes Call.connect("SEP2401C7824EA3", "9000", "9202") and is left ringing. CiscoAnnouncementStartedEv. getAnnouncementID() = Welcome Greeting Sample GC3: CallActiveEv GC3: ConnCreatedEv 9202 GC3: CallCtlConnDialingEv 9202 GC3: TermConnCreatedEv CTIRD3 GC3: TermConnActiveEv CTIRD3 GC3: CallCtlTermConnTalkingEv CTIRD3 GC3: ConnConnectedEv 9202 GC3: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. Feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: ConnCreatedEv Unknown GC3: ConnInProgressEv Unknown GC3: CallCtlConnOfferedEv Unknown GC3: ConnConnectedEv Unknown GC3: CallCtlConnEstablishedEv Unknown Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1365 Message Sequence Charts Message Sequence Charts

Page 1429 diagram

Page 1430

Call Info Event Action CiscoAnnouncementStartedEv. will have feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: CiscoAnnouncementStartedEv. CiscoAnnouncementEndedEv. getSuccess() = true. CiscoAnnouncementEndedEv. getErrorCode() = 0 CiscoAnnouncementEndedEv. getErrorDescription() = No Error GC3: CallCtlTermConnHeldEv CTIRD3 GC3: CiscoAnnouncementEndedEv GC3: TermConnDroppedEv CTIRD3 GC3: CallCtlTermConnDroppedEv CTIRD3 GC3: ConnDisconnectedEv Unknown GC3: CallCtlConnDisconnectedEv Unknown GC3: ConnDisconnectedEv 9202 GC3: CallCtlConnDisconnectedEv 9202 GC3: CallInvalidEv GC3: CallObservationEndedEv GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalking CTIRD3 Customer call is answered. Announcement call is dropped/disconnected. Table 333: Play Announcement Where the Call Is Answered Before the Full Message Plays Call Info Event Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1366 Message Sequence Charts Message Sequence Charts

Page 1430 diagram

Page 1431

Call Info Event Action CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEvCTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 User1 invokes CiscoAddress. createPersistentCall("CTIRD3", "1000", "remote") on device A and remote destination answers. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1367 Message Sequence Charts Message Sequence Charts

Page 1431 diagram

Page 1432

Call Info Event Action GC2: CallActiveEv GC2: ConnCreatedEv 9000 GC2: ConnConnectedEv 9000 GC2: CallCtlConnInitiatedEv 9000 GC2: TermConnCreatedEv SEP2401C7824EA3 GC2: TermConnActiveEv SEP2401C7824EA3 GC2: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC2: CallCtlConnDialingEv 9000 GC2: CallCtlConnEstablishedEv 9000 GC2: ConnCreatedEv 9202 GC2: ConnInProgressEv 9202 GC2: CallCtlConnOfferedEv 9202 GC2: ConnAlertingEv 9202 GC2: CallCtlConnAlertingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnRingingEv CTIRD3 GC2: CallCtlTermConnRingingEvCTIRD3 User1 invokes Call.connect("SEP2401C7824EA3", "9000", "9202") and is left ringing. CiscoAnnouncementStartedEv. getAnnouncementID() = Welcome Greeting Sample GC3: CallActiveEv GC3: ConnCreatedEv 9202 GC3: CallCtlConnDialingEv 9202 GC3: TermConnCreatedEv CTIRD3 GC3: TermConnActiveEv CTIRD3 GC3: CallCtlTermConnTalkingEv CTIRD3 GC3: ConnConnectedEv 9202 GC3: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A Feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: ConnCreatedEv Unknown GC3: ConnInProgressEv Unknown GC3: CallCtlConnOfferedEv Unknown GC3: ConnConnectedEv Unknown GC3: CallCtlConnEstablishedEv Unknown Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1368 Message Sequence Charts Message Sequence Charts

Page 1432 diagram

Page 1433

Call Info Event Action CiscoAnnouncementStartedEv. will have feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: CiscoAnnouncementStartedEv. CiscoAnnouncementEndedEv. getSuccess() = true. CiscoAnnouncementEndedEv. getErrorCode() = 0 CiscoAnnouncementEndedEv. getErrorDescription() = No Error GC3: CallCtlTermConnHeldEv CTIRD3 GC3: CiscoAnnouncementEndedEv GC3: TermConnDroppedEv CTIRD3 GC3: CallCtlTermConnDroppedEv CTIRD3 GC3: ConnDisconnectedEv Unknown GC3: CallCtlConnDisconnectedEv Unknown GC3: ConnDisconnectedEv 9202 GC3: CallCtlConnDisconnectedEv 9202 GC3: CallInvalidEv GC3: CallObservationEndedEv GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalking CTIRD3 Customer call is answered. Announcement call is dropped/disconnected. Table 334: Play Announcement with Call in Connected State Call Info Event Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1369 Message Sequence Charts Message Sequence Charts

Page 1433 diagram

Page 1434

Page 1434 diagram

Page 1435

Call Info Event Action GC2: CallActiveEv GC2: ConnCreatedEv 9000 GC2: ConnConnectedEv 9000 GC2: CallCtlConnInitiatedEv 9000 GC2: TermConnCreatedEv SEP2401C7824EA3 GC2: TermConnActiveEv SEP2401C7824EA3 GC2: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC2: CallCtlConnDialingEv 9000 GC2: CallCtlConnEstablishedEv 9000 GC2: ConnCreatedEv 9202 GC2: ConnInProgressEv 9202 GC2: CallCtlConnOfferedEv 9202 GC2: ConnAlertingEv 9202 GC2: CallCtlConnAlertingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnRingingEv CTIRD3 GC2: CallCtlTermConnRingingEvCTIRD3 GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalking CTIRD3 User1 invokes Call.connect("SEP2401C7824EA3", "9000", "9202") and is answered. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. OPERATION_NOT_AVAILABLE_ IN_CURRENT_STATE. Caught exception com.cisco.jtapi.PlatformException: Operation not available in current state. User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. Table 335: Play Announcement with Held Customer Call Call Info Event Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1371 Message Sequence Charts Message Sequence Charts

Page 1435 diagram

Page 1436

Call Info Event Action CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEvCTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv User1 invokes CiscoAddress. createPersistentCall("CTIRD3", "1000", "remote") on device A and remote destination answers. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1372 Message Sequence Charts Message Sequence Charts

Page 1436 diagram

Page 1437

Call Info Event Action GC2: CallActiveEv GC2: ConnCreatedEv 9000 GC2: ConnConnectedEv 9000 GC2: CallCtlConnInitiatedEv 9000 GC2: TermConnCreatedEv SEP2401C7824EA3 GC2: TermConnActiveEv SEP2401C7824EA3 GC2: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC2: CallCtlConnDialingEv 9000 GC2: CallCtlConnEstablishedEv 9000 GC2: ConnCreatedEv 9202 GC2: ConnInProgressEv 9202 GC2: CallCtlConnOfferedEv 9202 GC2: ConnAlertingEv 9202 GC2: CallCtlConnAlertingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnRingingEv CTIRD3 GC2: CallCtlTermConnRingingEvCTIRD3 GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalking CTIRD3 User1 invokes Call.connect("SEP2401C7824EA3", "9000", "9202") and is answered. GC2: CallCtlTermConnHeldEv CTIRD3 User1 puts the customer call on hold. Invokes TerminalConnection.hold() on Device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1373 Message Sequence Charts Message Sequence Charts

Page 1437 diagram

Page 1438

Call Info Event Action CiscoAnnouncementStartedEv. getAnnouncementID() = Welcome Greeting Sample GC3: CallActiveEv GC3: ConnCreatedEv 9202 GC3: CallCtlConnDialingEv 9202 GC3: TermConnCreatedEv CTIRD3 GC3: TermConnActiveEv CTIRD3 GC3: CallCtlTermConnTalkingEv CTIRD3 GC3: ConnConnectedEv 9202 GC3: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. Feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: ConnCreatedEv Unknown GC3: ConnInProgressEv Unknown GC3: CallCtlConnOfferedEv Unknown GC3: ConnConnectedEv Unknown GC3: CallCtlConnEstablishedEv Unknown CiscoAnnouncementStartedEv. will have feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: CiscoAnnouncementStartedEv. CiscoAnnouncementEndedEv. getSuccess() = true. CiscoAnnouncementEndedEv. getErrorCode() = 0 CiscoAnnouncementEndedEv. getErrorDescription() = No Error GC3: CiscoAnnouncementEndedEv GC3: TermConnDroppedEv CTIRD3 GC3: CallCtlTermConnDroppedEv CTIRD3 GC3: ConnDisconnectedEv Unknown GC3: CallCtlConnDisconnectedEv Unknown GC3: ConnDisconnectedEv 9202 GC3: CallCtlConnDisconnectedEv 9202 GC3: CallInvalidEv GC3: CallObservationEndedEv After the announcement finishes playing, call is disconnected. Table 336: Play Announcment with an Outgoing Call Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1374 Message Sequence Charts Message Sequence Charts

Page 1438 diagram

Page 1439

Page 1439 diagram

Page 1440

Call Info Events Action GC2: CallActiveEv GC2: ConnCreatedEv 9202 GC2: ConnConnectedEv 9202 GC2: CallCtlConnInitiatedEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalkingEv CTIRD3 GC2: CallCtlConnDialingEv 9202 GC2: CallCtlConnEstablishedEv 9202 GC2: ConnCreatedEv 9000 GC2: ConnInProgressEv 9000 GC2: CallCtlConnOfferedEv 9000 GC2: ConnAlertingEv 9000 GC2: CallCtlConnAlertingEv 9000 GC2: TermConnCreatedEv SEP2401C7824EA3 GC2: TermConnRingingEv SEP2401C7824EA3 GC2: CallCtlTermConnRingingEv SEP2401C7824EA3 Device A makes outgoing call to Device C. User1 invokes Call.connect("CTIRD3", "9202", "9000"). Call is left unanswered (ringing state). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1376 Message Sequence Charts Message Sequence Charts

Page 1440 diagram

Page 1441

Call Info Events Action CiscoAnnouncementStartedEv. getAnnouncementID() = Welcome Greeting Sample GC2: TermConnDroppedEv CTIRD3 GC2: CallCtlTermConnDroppedEv CTIRD3 GC2: ConnDisconnectedEv 9202 GC2: CallCtlConnDisconnectedEv 9202 GC2: TermConnDroppedEv SEP2401C7824EA3 GC2: CallCtlTermConnDroppedEv SEP2401C7824EA3 GC2: ConnDisconnectedEv 9000 GC2: CallCtlConnDisconnectedEv 9000 GC2: CallInvalidEv GC2: CallObservationEndedEv GC3: CallActiveEv GC3: ConnCreatedEv 9202 GC3: CallCtlConnDialingEv 9202 GC3: TermConnCreatedEv CTIRD3 GC3: TermConnActiveEv CTIRD3 GC3: CallCtlTermConnTalkingEv CTIRD3 GC3: ConnConnectedEv 9202 GC3: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. Feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: ConnCreatedEv Unknown GC3: ConnInProgressEv Unknown GC3: CallCtlConnOfferedEv Unknown GC3: ConnConnectedEv Unknown GC3: CallCtlConnEstablishedEv Unknown CiscoAnnouncementStartedEv. will have feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC3: CiscoAnnouncementStartedEv. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1377 Message Sequence Charts Message Sequence Charts

Page 1441 diagram

Page 1442

Call Info Events Action CiscoAnnouncementEndedEv. getSuccess() = true. CiscoAnnouncementEndedEv. getErrorCode() = 0 CiscoAnnouncementEndedEv. getErrorDescription() = No Error GC3: CiscoAnnouncementEndedEv GC3: TermConnDroppedEv CTIRD3 GC3: CallCtlTermConnDroppedEv CTIRD3 GC3: ConnDisconnectedEv Unknown GC3: CallCtlConnDisconnectedEv Unknown GC3: ConnDisconnectedEv 9202 GC3: CallCtlConnDisconnectedEv 9202 GC3: CallInvalidEv GC3: CallObservationEndedEv After announcement finishes playing, call is disconnected. Table 337: Play Announcement on an IP Phone Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. COMMAND_NOT_IMPLEMENTED_ ON_DEVICE. Caught exception com.cisco.jtapi.PlatformException: Internal callprocessing error :Device does not support the command User1 invokes CiscoAddress. startAnnouncement("SEP8478ACE7F9B9", "Welcome Greeting Sample") on ip phone. Table 338: Play Announcement on the CTI Port Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. COMMAND_NOT_IMPLEMENTED_ ON_DEVICE. Caught exception com.cisco.jtapi.PlatformException: Internal callprocessing error :Device does not support the command User1 invokes CiscoAddress. startAnnouncement("CTI3", "Welcome Greeting Sample") on CTI Port. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1378 Message Sequence Charts Message Sequence Charts

Page 1442 diagram

Page 1443

Table 339: Play Announcement on CTI Remote Device Without Persistent Call Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_NO_PERSISTENT_ CALL_EXISTS. Caught exception com.cisco.jtapi.PlatformException: No persistent call exists. User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. Table 340: Play Announcement on a CTI Remote Device While a Persistent Call Is Being Set Up Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEvCTIRD3 User1 invokes CiscoAddress. createPersistentCall("CTIRD3", "1000", "remote") on device A. Call is offered to the remote destination but not picked up. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_PERSISTENT_CALL_ BEING_SETUP. Caught exception com.cisco.jtapi.PlatformException: Persistent Call is being set up. User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1379 Message Sequence Charts Message Sequence Charts

Page 1443 diagram

Page 1444

Table 341: Play Announcement on CTI Remote Device with a Persistent Call with an Invalid Announcement Identifier Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEvCTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 User1 invokes CiscoAddress. createPersistentCall("CTIRD3", "1000", "remote") on device A and remote destination answers. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_INVALID_MEDIA_ RESOURCE_ID. Caught exception com.cisco.jtapi.PlatformException: Invalid Media resource ID. User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome") on Device A. Table 342: Play Announcement Back to Back Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1380 Message Sequence Charts Message Sequence Charts

Page 1444 diagram

Page 1445

Call Info Events Action CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEvCTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 User1 invokes CiscoAddress. createPersistentCall("CTIRD3", "1000", "remote") on device A and remote destination answers. CiscoAnnouncementStartedEv. getAnnouncementID() = Welcome Greeting Sample CiscoAnnouncementEndedEv. getSuccess() = true. CiscoAnnouncementEndedEv. getErrorCode() = 0 CiscoAnnouncementEndedEv. getErrorDescription() = No Error GC2: CallActiveEv GC2: ConnCreatedEv 9202 GC2: CallCtlConnDialingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalkingEv CTIRD3 GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. For these 3 call events, feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC2: ConnCreatedEv Unknown GC2: ConnInProgressEv Unknown GC2: CallCtlConnOfferedEv Unknown GC2: ConnConnectedEv Unknown GC2: CallCtlConnEstablishedEv Unknown CiscoAnnouncementStartedEv. will have feature reason = CiscoFeatureReason. REASON_PLAY_ANNOUNCEMENT GC2: CiscoAnnouncementStartedEv. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1381 Message Sequence Charts Message Sequence Charts

Page 1445 diagram

Page 1446

Call Info Events Action GC2: CiscoAnnouncementEndedEv GC2: TermConnDroppedEv CTIRD3 GC2: CallCtlTermConnDroppedEv CTIRD3 GC2: ConnDisconnectedEv Unknown GC2: CallCtlConnDisconnectedEv Unknown GC2: ConnDisconnectedEv 9202 GC2: CallCtlConnDisconnectedEv 9202 GC2: CallInvalidEv GC2: CallObservationEndedEv After announcement finishes playing, the call is disconnected. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex).getErrorCode() = CiscoJtapiException. CTIERR_ANNOUNCEMENT_ALREADY_ IN_PROGRESS. Caught exception com.cisco.jtapi.PlatformException: Announcement already in progress. User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. Table 343: Play Announcement to Stop IPVMS Service Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1382 Message Sequence Charts Message Sequence Charts

Page 1446 diagram

Page 1447

Page 1447 diagram

Page 1448

Call Info Events Action CiscoAnnouncementErrorEv. getErrorCode() = -1932787536 CiscoAnnouncementErrorEv. getErrorDescription() = Resource Not Available. GC2: CallActiveEv GC2: ConnCreatedEv 9202 GC2: CallCtlConnDialingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalkingEv CTIRD3 GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 GC2: ConnCreatedEv Unknown GC2: ConnInProgressEv Unknown GC2: CallCtlConnOfferedEv Unknown GC2: ConnConnectedEv Unknown GC2: CallCtlConnEstablishedEv Unknown GC2: CiscoAnnouncementErrorEv GC2: TermConnDroppedEv CTIRD3 GC2: CallCtlTermConnDroppedEv CTIRD3 GC2: ConnDisconnectedEv Unknown GC2: CallCtlConnDisconnectedEv Unknown GC2: ConnDisconnectedEv 9202 GC2: CallCtlConnDisconnectedEv 9202 GC2: CallInvalidEv GC2: CallObservationEndedEv User1 invokes CiscoAddress. startAnnouncement("CTIRD3", "Welcome Greeting Sample") on Device A. Play Announcement Feature Interaction Use Cases Play Announcement Feature Interaction Use Cases Table 344: Hold Announcement Call Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1384 Message Sequence Charts Play Announcement Feature Interaction Use Cases

Page 1448 diagram

Page 1449

Call Info Events Action CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEv CTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 User1 invokes CiscoAddress.createPersistentCall ("CTIRD3", "1000", "remote") on device A and remote destination answers. CiscoAnnouncementStartedEv. getAnnouncementID () = Welcome Greeting Sample GC2: CallActiveEv GC2: ConnCreatedEv 9202 GC2: CallCtlConnDialingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalkingEv CTIRD3 GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress.startAnnouncement ("CTIRD3", "Welcome Greeting Sample") on Device A. Feature reason = CiscoFeatureReason. REASON_PLAY_ ANNOUNCEMENT GC2: ConnCreatedEv Unknown GC2: ConnInProgressEv Unknown GC2: CallCtlConnOfferedEv Unknown GC2: ConnConnectedEv Unknown GC2: CallCtlConnEstablishedEv Unknown CiscoAnnouncementStartedEv will have feature reason = CiscoFeatureReason. REASON_PLAY_ ANNOUNCEMENT GC2: CiscoAnnouncementStartedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1385 Message Sequence Charts Message Sequence Charts

Page 1449 diagram

Page 1450

Page 1450 diagram

Page 1451

Call Info Events Action CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEv CTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 User1 invokes CiscoAddress.createPersistentCall ("CTIRD3", "1000", "remote") on device A and remote destination answers. CiscoAnnouncementStartedEv. getAnnouncementID () = Welcome Greeting Sample GC2: CallActiveEv GC2: ConnCreatedEv 9202 GC2: CallCtlConnDialingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalkingEv CTIRD3 GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress.startAnnouncement ("CTIRD3", "Welcome Greeting Sample") on Device A. Feature reason = CiscoFeatureReason. REASON_PLAY_ ANNOUNCEMENT GC2: ConnCreatedEv Unknown GC2: ConnInProgressEv Unknown GC2: CallCtlConnOfferedEv Unknown GC2: ConnConnectedEv Unknown GC2: CallCtlConnEstablishedEv Unknown CiscoAnnouncementStartedEv will have feature reason = CiscoFeatureReason. REASON_PLAY_ ANNOUNCEMENT GC2: CiscoAnnouncementStartedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1387 Message Sequence Charts Message Sequence Charts

Page 1451 diagram

Page 1452

Page 1452 diagram

Page 1453

Call Info Events Action CallingAddress = 1000, CalledAddress = 9202, CurrentCallingAddress = 1000, CurrentCalledAddress = 9202 GC1: CallActiveEv GC1: ConnCreatedEv 9202 GC1: ConnInProgressEv 9202 GC1: CallCtlConnOfferedEv 9202 GC1: ConnCreatedEv 1000 GC1: ConnConnectedEv 1000 GC1: CallCtlConnEstablishedEv 1000 GC1: ConnAlertingEv 9202 GC1: CallCtlConnAlertingEv 9202 GC1: TermConnCreatedEv CTIRD3 GC1: TermConnRingingEv CTIRD3 GC1: CallCtlTermConnRingingEv CTIRD3 GC1: ConnConnectedEv 9202 GC1: CallCtlConnEstablishedEv 9202 GC1: TermConnActiveEv CTIRD3 GC1: CallCtlTermConnTalkingEv CTIRD3 User1 invokes CiscoAddress.createPersistentCall ("CTIRD3", "1000", "remote") on device A and remote destination answers. CiscoAnnouncementStartedEv. getAnnouncementID () = Welcome Greeting Sample GC2: CallActiveEv GC2: ConnCreatedEv 9202 GC2: CallCtlConnDialingEv 9202 GC2: TermConnCreatedEv CTIRD3 GC2: TermConnActiveEv CTIRD3 GC2: CallCtlTermConnTalkingEv CTIRD3 GC2: ConnConnectedEv 9202 GC2: CallCtlConnEstablishedEv 9202 User1 invokes CiscoAddress.startAnnouncement ("CTIRD3", "Welcome Greeting Sample") on Device A. Feature reason = CiscoFeatureReason. REASON_PLAY_ ANNOUNCEMENT GC2: ConnCreatedEv Unknown GC2: ConnInProgressEv Unknown GC2: CallCtlConnOfferedEv Unknown GC2: ConnConnectedEv Unknown GC2: CallCtlConnEstablishedEv Unknown CiscoAnnouncementStartedEv will have feature reason = CiscoFeatureReason. REASON_PLAY_ ANNOUNCEMENT GC2: CiscoAnnouncementStartedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1389 Message Sequence Charts Message Sequence Charts

Page 1453 diagram

Page 1454

Call Info Events Action Let "ex" be an instance of PlatformException: ( (CiscoJtapiException) ex).getErrorCode () = CiscoJtapiException. CTIERR_OPERATION_ NOT_ALLOWED. Caught exception com.cisco.jtapi.PlatformException: Operation not allowed. User1 invokes Connection.park () on the announcement call. CiscoAnnouncementEndedEv. getSuccess () = true. CiscoAnnouncementEndedEv. getErrorCode () = 0 CiscoAnnouncementEndedEv. getErrorDescription () = No Error GC2: CiscoAnnouncementEndedEv GC2: TermConnDroppedEv CTIRD3 GC2: CallCtlTermConnDroppedEv CTIRD3 GC2: ConnDisconnectedEv Unknown GC2: CallCtlConnDisconnectedEv Unknown GC2: ConnDisconnectedEv 9202 GC2: CallCtlConnDisconnectedEv 9202 GC2: CallInvalidEv GC2: CallObservationEndedEv After announcement finishes playing, call is disconnected. Play Zip Tone A and B represents the terminals. TermConnB represents the Cisco terminal connection of Terminal B. TermConnCTI1 represents the Cisco terminal connection of terminal CTI1. CTI1 is a Cisco media terminal. Events/Response Scenario Sl.No User on B hears the ZIP tone. A calls B. B answers the call and the application invokes TermConnB.playTone(CiscoTone.ZIPTONE, CiscoCall. PLAYTONE_LOCALONLY) 1. User on A hears the ZIP tone. A calls B. B answers the call and application invokes TermConnB.playTone(CiscoTone.ZIPTONE, CiscoCall. PLAYTONE_REMOTEONLY) 2. Tone is heard by user B. A calls B. B is alerting. Application calls TermConnB. playTone(CiscoTone.ZIPTONE, CiscoCall. PLAYTONE_LOCALONLY) 3. PlatformException is thrown to application request. A calls CTI1. Call is answered by CTI1. Application calls TermCTI. playTone(CiscoTone.ZIPTONE, CiscoCall. PLAYTONE_LOCALONLY) 4. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1390 Message Sequence Charts Play Zip Tone

Page 1454 diagram

Page 1455

Events/Response Scenario Sl.No User on A hears the ZIP tone. A calls CTI1. Call is answered by CTI1. Application calls TermConnCTI1. playTone(CiscoTone.ZIPTONE, CiscoCall. PLAYTONE_REMOTEONLY) 5. User on B hears the ZIP tone. A, B and CTI1 are in conference. Application calls TermConnB.playTone(CiscoTone.ZIPTONE, CiscoCall. PLAYTONE_LOCALONLY) 6. None of the users on A, B and CTI hear the tone. A, B and CTI1 are in conference. Application calls TermB.playTone(CiscoTone.ZIPTONE, CiscoCall. PLAYTONE_REMOTEONLY) 7. QoS Support Figure 21: Call Flow Diagram for QoS Support JTAPI QoS For QoS to work in Windows, complete the following steps: 1. Start Registry Editor (Regedt32.exe). 2. Go to the following key: HKEY_LOCAL_ MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
The registry key is one path. Note Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1391 Message Sequence Charts QoS Support

Image 1 from page 1455

Image 2 from page 1455

Page 1455 diagram

Page 1456

On the Edit menu, click Add Value. 2. Type DisableUserTOSSetting. 3. Click REG_DWORD in the Data Type box. 4. Click OK. 5. Enter 0 in the prompt box. 6. Quit the Registry Editor. 7. Restart the computer. For more information on this see http://support.microsoft.com/default.aspx?scid = kb;en-us;248611 JTAPI Behavior Scenario JTAPI returns the DSCP value received from CTI in StartTransmissionEvent to the application. Application uses the JTAPI getPrecedenceValue() API to query for the new DSCP value, in CiscoRTPOutputStartedEvent. JTAPI returns the DSCP value received from CTI in ProviderOpenCompletedEvent to the application. Application uses the JTAPI getAppDSCPValue() API to query for the new DSCP value, when it gets ProviderInServiceEvent. QSIG Path Replacement The following table shows the JTAPI events that are delivered to applications when calls between PBXs that are connected by Q.Signaling (QSIG) trunks are transferred and forwarded. This table also shows the events that are delivered to applications when the real-time path (RTP) is optimized by the QSIG Path Replacement feature. Calls going out on a QSIG trunk may not have a connection for the far end if any translation pattern is changing the pattern. In other words, when the application sees two calls in the trombone case, B may not serve as the common connection on the calls. Event Action No. These events get delivered to applications: CallCtrlConnectionEstablishedEv A CallCtrlConnectionDisConnectEv B OpenLogicalChannelEvent if C is a CTI device (Dynamically registered CTIPorts and RP) A registered with CM1, B is registered with CM2, and C registered with CM3. A calls B (GC1); B transfers the call to C. The application is monitors C. The PR feature replaces the path after the call gets connected to C. The same action applies to scenarios that involve call forward at B. (The called party transfers the call.) 1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1392 Message Sequence Charts QSIG Path Replacement

Page 1456 diagram

Page 1457

Event Action No. In this case, both A are C represent called parties when transfer completes. After the call is answered, PR replaces the path. In this case, A and C represent IP phones; the display will be updated as a part of PR feature operation, that makes either A or C as calling. JTAPI events: GC1: CallCtlConnEstablishedEv A GC1: CallCtlConnDisconnectedEv B A registered with CM1, B registered with CM2, and C registered with CM3. B calls C; C answers; B transfers the call to A. A answers. The application is monitors only C. (The calling party transfers the call.) 2 For GC1 Call Observer: GC1: CallCtlConnEstablishedEv C GC1: CallCtlConnDisconnected B Before the PR feature replaces the path, the application sees two calls: GC1 with connections to A and C (external) and GC2 with connections to C and A (external). When the PR feature replaces the path, either GC1 changes GC2, or GC2 changes to GC1. Assuming A's GCID changes from GC1 to GC2: GC1: CiscoCallChangedEv (oldGCID = GC1, newGCID = GC2) GC1: CallCtlConnDisconnected for A GC1: CallCtlConnDisconnected for C GC1: CallInValid GC2: TermConnTalkingEvent for TerminalA cause = CAUSE_QSIG_PR Trombone case: A registered to CM1, B registered to CM2, and C registered to CM1. A calls B (GC1); B answers and transfers the call to C (GC2). Path replacement connects A and C bypassing CM2. The application observes both A and C. (The called party transfers the call.) 3 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1393 Message Sequence Charts Message Sequence Charts

Page 1457 diagram

Page 1458

Event Action No. Before the PR feature replaces the path, the application will see two calls: GC1 with connections to A and B (external) and GC2 with connections to C and B (external). In this case, the application will not see any transfer start events. When PR feature replaces the path, it updates the display of A and C and path gets replaced, resulting in a GCID change. Assuming A's GCID is changed and made the calling party, the following JTAPI events occur: GC1: CiscoCallChangedEv (GC1 to GC2) GC1: CallCtlConnDisconnected for A GC1: CallCtlConnDisconnected for C GC1: CallInValid GC2: ConnCreatedEv A GC2: ConnConnectedEv A GC2: TermConnTalkingEvent for TerminalA cause = CAUSE_QSIG_PR Trombone case: A registered to CM1, B registered to CM2, and C registered to CM1. B calls A and transfers the call to C. Path replacement connects A and C, bypassing CM2. Application observes both A and C. (The calling party transfers the call.) 4 Path replacement gets abandoned. A registered to CM1, B registered to CM2, and C registered to CM1. A calls B; B transfers the call to C. C answers and before path replacement completes, C invokes a feature (park, redirect, and so on). 5 JTAPI: Exception will be thrown from JTAPI for feature requests. In some conditions, call processing ignores feature requests (redirect, park, transfer, and so on). This happens when a setup request is sent out, and the local CM is waiting for connect from the other end. 6 No events JTAPI Apps: Hang up the call In some cases, the application could receive dead air when CM goes down when the PR feature is trying to switch the RTP path. This could happen to a previously connected call. 7 Recording Use Cases Expose ClusterID in CiscoProvider Interface Call Info Events Actiions Start application and initialize JTAPI ProvInServiceEv Add provider observer JTAPI returns 'StandAloneCluster' Application calls ciscoProvider.getClusterID() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1394 Message Sequence Charts Recording Use Cases

Page 1458 diagram

Page 1459

Admin changes the clusterID to '3NodeClusterinSanJose' and restarts the services Application calls getClusterID() - JTAPI returns ' 3NodeClusterinSanJose' ProvOutofService ProvInServiceEv Multi-Clusters Gateway Recording Use Cases Test configurations Specification: • Cluster 1 = SME Cluster with 1 PUB and 1 SUB (Note: Only use DN's 2xxx, 3xxx, 9xxx) • Cluster 2 = External Cluster (Note: Only use DN's 1xxx, 4xxx) • Cluster 3 = Leaf Cluster (Note: Only use DN's 5xxx, 6xxx) Assumption: All devices have BIB enabled unless specified in the detailed test cases. CTIRD does not support BIB. • Cluster 1 and Cluster 2 are connected thru SIP GW which is recording enabled. • Cluster 1 and Cluster 3 are connected thru SIP trunk ICT. • Cluster 2 and Cluster 3 are connected thru SIP trunk ICT. On Cluster 1 Route-Patterns: • 180.XXXX: SIP ICT trunk from cluster 1 to cluster 3, calledPartyTranformation: remove PreDot. • 171.XXXX: SIP GW from cluster 1 to cluster 2, calledPartyTranformation: remove PreDot. On Cluster 2 Route-Patterns: • 172.XXXX: SIP GW from cluster 2 to cluster 1, calledPartyTranformation: remove PreDot. • 172180.XXXX: SIP GW from cluster 2 to cluster 1 to cluster 3, calledPartyTranformation: remove PreDot. • 180.XXXX: SIP ICT trunk from cluster 2 to cluster 3 directly, calledPartyTranformation: remove PreDot. On Cluster 3 Route-Patterns: • 172.XXXX: SIP ICT trunk from cluster 3 to cluster 1, calledPartyTranformation: remove PreDot. • 172171.XXXX: SIP GW from cluster 3 to cluster 1 to cluster 2, calledPartyTranformation: remove PreDot. • 171.XXXX: SIP ICT trunk from cluster 3 to cluster 2 directly, calledPartyTranformation: remove PreDot. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1395 Message Sequence Charts Message Sequence Charts

Page 1459 diagram

Page 1460

Recording IP Phones Scenario 1 IP phones (Basic): Multi-Clusters Gateway preferred with auto recording Events and Call Info Setup and Action Step 3- Check A1 and B1 CiscoAddres.AUTO_RECORDING Step 5- Check two recording sessions established on A1 and B1. Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name – SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Check B1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = recorder B device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE .getMediaForkingDeviceName() = device name of B .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster2 Step 6- Check A1 and B1 get CiscoTermConnRecordingEndEv and disconnect on recorders. Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 Cluster 2: • Phone B (SEP8E0E) has line B1:4006 • GW preferred • auto recording enabled • recorder B:2000 Cluster 3: • Branch recorder: 2000 • Phone A (SEP3B5F) has line A1 3601 configured as: • GW preferred • auto recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. Verify A1 have recording type AUTO_RECORDING 4. A1 (cluster3) call B1 (cluster2) (e.g. 3602 call 1721714006) 5. B1 answers the call 6. A1 drops Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1396 Message Sequence Charts Recording IP Phones

Page 1460 diagram

Page 1461

Scenario 2 IP phones (Basic): Multi-Clusters Gateway preferred with auto recording Events and Call Info Setup and Action Step 3- Check A1 CiscoAddres.SELECTIVE_RECORDING Step 5- Check auto recording started on B1. Check B1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check B1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = recorder B device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE .getMediaForkingDeviceName() = device name of B .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster2 Step 6- Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER_INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name – SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check A1 get CiscoTermConnRecordingEndEv and disconnect on recorders. Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 Cluster 2: • Phone B (SEP8E0E) has line B1:4006 • GW preferred • auto recording enabled • recorder B:2000 Cluster 3: • Branch recorder: 2000 • Phone A (SEP3B5F) has line A1 3601 configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. Verify A1 have recording type SELECTIVE_RECORDING 4. A1 calls B1 (3601 calls 1721714006) 5. B1 answers 6. A1 requests startRecording(app) 7. A1 requests stopRecording() 8. A1 disconnects B1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1397 Message Sequence Charts Message Sequence Charts

Page 1461 diagram

Page 1462

Scenario 3 IP phones (Basic): Multi-Clusters Gateway preferred with press key invoke recording Events and Call Info Setup and Action Step 3- Check A1 and B1 CiscoAddres.SELECTIVE_RECORDING Step 6-Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER_INITIATED_FROM_DEVICE .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name – SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 Cluster 2: • Phone B (SEP723F) has line B1:4008 • GW preferred • selective recording enabled • recorder B:2000 Cluster 3: • Branch recorder: 2000 • Phone A (SEPDB17) has line A1 2303 configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. Verify A1 have recording type SELECTIVE_RECORDING 4. A1 calls B1 ( 2303 calls 1721714008) 5. B1 answers 6. Press recording key on A 7. A1 disconnects B1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1398 Message Sequence Charts Message Sequence Charts

Page 1462 diagram

Page 1463

Scenario 4 IP phones (Basic): Multi-Clusters Gateway preferred with selective recording and Cluster 1 fork media to branch recorder on cluster3 Events and Call Info Setup and Action Step 5- Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A2 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION_INITIATED_SILENT .getTerminalName() = SIPICT-To-Cluster3 .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk name – SIP GW.getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 6- Check A1 get CiscoTermConnRecordingEndEv Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 Cluster 2: • Phone B (SEP723F) has line B1:4008 • GW preferred • selective recording enabled • recorder B:2000 Cluster 3: • Branch recorder: 2000 • Phone A (SEPDB17) has line A1 1623 configured as: • GW preferred • selective recording enabled • recording profile:rec_profile2: 1802000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. A1 call B1 (1623 call 1721714008) 4. B1 answer the call 5. Start silent recording on A1 6. Stop recording on A1 7. A1 drop Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1399 Message Sequence Charts Message Sequence Charts

Page 1463 diagram

Page 1464

Scenario 5 IP phones (Basic): Multi-Clusters Device preferred with selective recording and device fork media to central recorder Events and Call Info Setup and Action Step 5-Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER_INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 1722000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE .getMediaForkingDeviceName() = device name of A .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster3 Step 6- Check A1 get CiscoTermConnRecordingEndEv and disconnect on recorder. Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 Cluster 2: • Phone B (SEP723F) has line B1:4008 • selective recording enabled Cluster 3: • Branch recorder: 2000 • Phone A (SEPDB17) has line A1 2008 configured as: • Device preferred • selective recording enabled • recording profile:rec_profile2: 1722000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. A1 call B1 (A1 call 70662050 4. B1 answer the call 5. A1 request startRecording(app) 6. A1 request stopRecording() 7. A1 drop Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1400 Message Sequence Charts Message Sequence Charts

Page 1464 diagram

Page 1465

Scenario 6 IP phones (Basic): Multi-Clusters Hold and resume - Gateway preferred with automatic recording Events and Call Info Setup and Action Step 4-Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name – SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Check B1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = recorder B device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk 2 device name – SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster2 Step 5- Check A1 get CiscoTermConnRecordingEndEv Step 6- Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Step 7- Check A1 get CiscoTermConnRecordingEndEv Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 Cluster 2: • Phone B ( SEP8E0E) has line B1:4006 • GW preferred • auto recording enabled • recorder B:2000 Cluster 3: • Branch recorder: 2000 • GW preferred • auto recording enabled • recording profile:rec_profile1: 2000 • Phone A ( SEP3B5F) has line A1 3602 configured as: 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. A1 call B1 (3602 call 1721714006) 4. B1 answer the call 5. A1 put call on hold 6. A1 resume the call 7. A1 drop Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1401 Message Sequence Charts Message Sequence Charts

Page 1465 diagram

Page 1466

Scenario 7 IP phones (Basic): Hold and resume - Phone preferred with Selective Recording Step 4-Check B get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check B TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION_INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN = 1505) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE .getMediaForkingDeviceName() = Phone Name .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster Check B TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = recorder B device name .getAddress() = Recording profile (DN 1505) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE .getMediaForkingDeviceName() = Phone name .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster Step 6- Check B get CiscoTermConnRecordingEndEv Step 7- Check B get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv Step 8- Check B get CiscoTermConnRecordingEndEv Phone A has line : 1506 Phone B has line : 1504 • Phone Prefered • Selective Recording enabled On Phone B • Recorder Phone C : 1505 • Recorder Phone D : 1503 • recording profile: rec_profile : 1505 1. Open provider 2. Observe A, B, C, D in Prov1 3. A call B (1506 calls 1504) 4. B answer the call. 5. Selective recording was initiated on Phone B. 6. B put call on hold. 7. B resumes the call. 8. A drop the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1402 Message Sequence Charts Message Sequence Charts

Page 1466 diagram

Page 1467

Scenario 8 IP phones (Basic): Multi-Clusters Multiple calls - Gateway preferred with automatic recording Events and Call Info Setup and Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1403 Message Sequence Charts Message Sequence Charts

Page 1467 diagram

Page 1468

Events and Call Info Setup and Action Step 4- Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Cluster 1: • “Allow trunk use GW recording” is enabled Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC • Central recorder: 2000 .getTerminalName() = central recording device name Cluster 2: .getAddress() = Recording profile (DN 2000) • Phone B (SEP8E0E) has line B1 1681 .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW • GW preferred • selective recording enabled .getMediaForkingDeviceName() = SIP trunk device name – SIP GW • recorder B:2000 .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 • Phone C ( SEP723F) has line B1: 4008 Step 5- Check A1 get CiscoTermConnRecordingEndEv • GW preferred Step 7-Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. (Recording is started on A1 for call A1->C1) • selective recording enabled Check A1 TermConnection.getCiscoRecorderInfo(): • recorder B:2000 .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC Cluster 3: .getTerminalName() = central recorder device name • Branch recorder: 2000 .getAddress() = Recording profile (DN 2000) • Phone A (SEPDB17) has line A1 3602 configured as: .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW • GW preferred .getMediaForkingDeviceName() = SIP trunk device name – SIP GW • auto recording enabled .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 • recording profile:rec_profile1: 2000 Step 8- Retrieve first call. Check A1 get CiscoTermConnRecordingEndEv (for A1->C1) 1. Open provider Prov1, Prov2, Prov3 Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv (for A1->B1) 2. Observe A1 in Prov3, B1, C1 in Prov2 3. A1 call B1 (3602 call 1721714006) Check A1 TermConnection.getCiscoRecorderInfo(): 4. B1 answer the call .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC 5. A1 put call on hold .getTerminalName() = central recorder device name 6. A1 call C1 (3602 call 1721714008) .getAddress() = Recording profile (DN 2000) 7. C1 answer .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW 8. A1 retrieve first call .getMediaForkingDeviceName() = SIP trunk device name – SIP GW 9. A1 retrieve second call .getProtocolReferenceGUID() = 10. A1 drop second call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1404 Message Sequence Charts Message Sequence Charts

Page 1468 diagram

Page 1469

Events and Call Info Setup and Action A1 drop first call .getMediaForkingClusterID() = name of cluster1 11. Step 9- Retrieve second call. Check A1 get CiscoTermConnRecordingEndEv (for A1->B1) Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv (for A1->C1) Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name – SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 CTI Remote Devices Use Cases Scenario 9 CTI Remote Devices (Basic): Multi-Clusters Gateway preferred with automatic recording- IP phone (cluster3) call remote device (cluster1) Events and Call Info Setup and Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1405 Message Sequence Charts CTI Remote Devices Use Cases

Page 1469 diagram

Page 1470

Step 4- Check auto recording started on A1. Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 5- Check A1 get CiscoTermConnRecordingEndEv Note: Auto recording start on B1 (new changes) Step 4- Check B1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check B1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 5- Check B1 get CiscoTermConnRecordingEndEv Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 • Mobile through PSTN GW in Cluster 1 • devB (CTIRD3) has line B1:9008 (active remote destination: 1711681 on cluster2) configured as: • auto recording enabled • GW preferred Cluster 2: • Phone C has line C1 (1681) Cluster 3: • Branch recorder: 2000 • Phone A (SEP3B5F) has line A1 (3601) configured as: • GW preferred • auto recording enabled • recording profile:rec_profile2: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. A1 (cluster 3) call B1 (cluster1) (3601 call 1729008) 4. Remote destination on cluster 2 answer the call 5. A1 drop Scenario 10 CTI Remote Devices (Basic): Multi-Clusters Gateway preferred with silent recording- IP phone (cluster3) call remote device (cluster2) Events and Call Info Setup and Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1406 Message Sequence Charts Message Sequence Charts

Page 1470 diagram

Page 1471

Step 5- Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION_INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check A1 get CiscoTermConnRecordingEndEv Note: Auto recording start on B1 (new changes) Step 6- Check B1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check B1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION_INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check B1 get CiscoTermConnRecordingEndEv Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 • Mobile through PSTN GW in Cluster 1 Cluster 2: • devB (CTI_RD3) has line B1:1625 (remote destination: 1722602 on cluster 1) configured as: • selective recording enabled • GW preferred Cluster 3: • Branch recorder: 2000 • Phone A (SEP3B5F) has line A1 (3601) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. A1 call B1 (3601 calls 1721711620) 4. Remote destination on cluster 1 answer the call 5. Start silent recording on A1 6. Start silent recording on B1 7. Stop recording on A1 8. A1 drop Scenario 11 CTI Remote Devices (Basic): Multi-Clusters Gateway preferred with automatic recording- Remote device (cluster3) call Remote device (cluster2) Events and Call Info Setup and Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1407 Message Sequence Charts Message Sequence Charts

Page 1471 diagram

Page 1472

Step 7- Check auto recording started on A1. Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 • Mobile through PSTN GW in Cluster 1 Cluster 2: • devB (remote device CTI_RD2) has line B1:1624 (remote destination: 2303 on cluster 1) configured as: • selective recording enabled • GW preferred Cluster 3: • Branch recorder: 2000 • devA (remote device CTI_RD3) has line A1 1622 (remote destination: 9000 on cluster 1) configured as: • GW preferred • auto recording enabled • recording profile:rec_profile2: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. A1 (cluster 3) call B1 (cluster2) 4. Call is offered to devA’s remote destination 5. Remote destination of devA answer 6. Call is offered to B1 7. DevB’s remote destination answer the call 8. Remote destination of devB drop (or devB drop) Scenario 12 CTI Remote Devices (Basic): Multi-Clusters Hold and resume with automatic recording-IP phone call (cluster3) remote device (cluster2) Events and Call Info Setup and Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1408 Message Sequence Charts Message Sequence Charts

Page 1472 diagram

Page 1473

Step 4- Check auto recording started on A1. Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 5- Check A1 get CiscoTermConnRecordingEndEv Step 6- Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check A1 get CiscoTermConnRecordingEndEv Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 • Mobile through PSTN GW in Cluster 1 Cluster 2: • devB (CTI_RD3) has line B1:1620 (remote destination: 1722602 on cluster 1) configured as: • auto recording enabled • GW preferred Cluster 3: • Branch recorder: 2000 • devA (IP phone) has line 3602 configured as: • GW preferred • auto recording enabled • recording profile:rec_profile2: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1 in Prov3, B1 in Prov2 3. A1 (cluster 3) call B1 (cluster2) 4. Remote destination of devB answer the call 5. A1 put call on hold 6. A1 resume the call 7. A1 drop Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1409 Message Sequence Charts Message Sequence Charts

Page 1473 diagram

Page 1474

Feature Interaction: Recording Use Cases Scenario 13 FI: Redirect - IP phone (cluster3) call auto recording remote device (cluster1), redirect to IP phone (cluster3) Events and Call Info Setup and Action Step 4- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 5- Check RD1 get CiscoTermConnRecordingEndEv Step 5- Check auto recording restarted on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 6- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1: • “Allow trunk use GW recording” is enabled • Central recorder: 2000 • Mobile through PSTN GW in Cluster 1 • devRD (CTIRD3) has line RD1:9008 (active remote destination: 1711681 on cluster2) configured as: • GW preferred • automatic recording enabled Cluster 2: • Phone D (RDD) has line D1 (1681) Cluster 3: • Branch recorder: 2000 • Phone A (SEP3B5F) has line A1 (3601) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • Phone B (SEPDB17) has line B1 (2303) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe A1, B1 in Prov3, D1 in Prov2, RD1 in Prov1 3. A1 (cluster3) call RD1 (cluster1) (3601 call 1729008) 4. Remote destination on cluster 2 answer the call 5. A1 redirect to B1 6. B1 disconnect the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1410 Message Sequence Charts Feature Interaction: Recording Use Cases

Page 1474 diagram

Page 1475

Scenario 14 FI: Redirect -devRD (cluster1/SME), RDD (cluster2), A(cluster3/leaf) and B (cluster3/leaf) - RD auto recording and RD redirect Events and Call Info Setup and Action Cluster 1: • Central recorder: 2000 • devRD (CTIRD3) has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • automatic recording enabled • GW preferred Cluster 2: • RDD has line RDD1 (1681) Cluster 3: • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devA (SEPDB17) has line A1 (2008) configured as: • Phone preferred • auto recording enabled • recording profile:rec_profile1: 2000 • devB (SEP3B5F) has line B1 (3601) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1 in Prov1, RDD1 in Prov2, A1, B1 in Prov3 3. A1 (cluster3) call RD1 (cluster1) 4. Remote destination on cluster 2 answer the call 5. RD1 redirect to B1 (cluster3) 6. B1 answer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1411 Message Sequence Charts Message Sequence Charts

Page 1475 diagram

Page 1476

Events and Call Info Setup and Action Step 4- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 4- Check auto recording started on A1. Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = branch recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_PHONE .getMediaForkingDeviceName() = device name of A .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster3 Step 5: Check Recording retriggered on A1 Check A1 get CiscoTermConnRecordingEndedEv. Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = branch recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_PHONE .getMediaForkingDeviceName() = device name of A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1412 Message Sequence Charts Message Sequence Charts

Page 1476 diagram

Page 1477

Events and Call Info Setup and Action .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster3 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1413 Message Sequence Charts Message Sequence Charts

Page 1477 diagram

Page 1478

Scenario 15 FI: Redirect- devRD (leaf), RDD (SME), A (SME) and B (cluster2) - RD auto recording and A redirect Events and Call Info Setup and Action Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTI_RD3) on cluster 3 has line RD1 (1622) (active remote destination: 1729000 on cluster1) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 1. • devA (SEP334F) on cluster 1 has line A1 (2205) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • devB (SEP723F) on cluster 2 has line B1 (4008) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1 in Prov1, RDD1 in Prov2, A1, B1 in Prov3 3. A1 call RD1 4. Remote destination answer the call 5. A1 redirect to B1 6. B1 answer 7. Close RD1 and reopen RD1 (unobserved and reobserve RD1) 8. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1414 Message Sequence Charts Message Sequence Charts

Page 1478 diagram

Page 1479

Events and Call Info Setup and Action Step 4- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 6- Recording retriggered on RD1. Check RD1 get CiscoTermConnRecordingEndedEv , CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check RD1 CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1415 Message Sequence Charts Message Sequence Charts

Page 1479 diagram

Page 1480

Events and Call Info Setup and Action .getMediaForkingClusterID() = name of cluster1 Step 8- Check RD1 get CiscoTermConnRecordingEndedEv Scenario 16 FI: Redirect- devRD (SME), RDD (leaf), A (leaf) and B (cluster2) - RD silent recording and A redirect Events and Call Info Setup and Action Step 5- Start recording should fail on RD1 (error = CTIERR_RESOURCE_NOT_AVAILABLE??) Step 8- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 9- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD4) on cluster 1 has line RD1 (9008) (active remote destination: 1802303 on cluster3) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 3. • devA (SEP3B5F) on cluster 3 has line A1 (3601) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • devB (SEP723F) on cluster 2 has line B1 (4008) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. App start silent recording on RD1 6. A1 redirect to B1 thru GW (i.e. A1 redirect to 171XXXX) 7. B1 answer 8. Start app recording on RD1 9. App stop recording on RD1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1416 Message Sequence Charts Message Sequence Charts

Page 1480 diagram

Page 1481

Scenario 17 FI: Transfer- devRD (SME), RDD (cluster2), A (leaf) and B (leaf) - RD auto recording and A transfer Events and Call Info Setup and Action Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 6- Complete Transfer. Recording retriggered on RD1. Check RD1 get CiscoTermConnRecordingEndedEv , CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 8- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEP3B5F) on cluster 3 has line A1 (3601) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • devB (SEPDB17) on cluster 3 has line B1 (2303) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. A1 setup transfer to B1 6. B1 answer 7. A1 complete transfer 8. B1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1417 Message Sequence Charts Message Sequence Charts

Page 1481 diagram

Page 1482

Scenario 18 FI: Direct Transfer- devRD (SME), RDD (cluster2), A (leaf) and B (leaf) - RD auto recording and A direct transfer Events and Call Info Setup and Action Step 4- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- B1 and RD1 are connected. Recording retriggered on RD1. Check RD1 get CiscoTermConnRecordingEndedEv , CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 8- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEP3B5F) on cluster 3 has line A1 (3601) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • devB (SEPDB17) on cluster 3 has line B1 (2303) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. A1 call B1 6. B1 answer 7. App send direct transfer request on A1 with primary call = A1-RD1 8. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1418 Message Sequence Charts Message Sequence Charts

Page 1482 diagram

Page 1483

Scenario 19 FI: Conference- devRD (leaf), RDD (cluster2), A (SME) and B (SME) - RD silent recording and A conference Events and Call Info Setup and Action Step 5- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 8- A1 complete conference. A1, B1 and RD1 are in conference. Recording not retriggered on RD1. Step 9- Check RD1 get ExistingCallEvent and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 10- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTI_RD3) on cluster 3 has line RD1 (1621) (active remote destination: 1721711681 on cluster2) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (IP10) on cluster 1 has line A1 (2303) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • devB (SEP334F) on cluster 1 has line B1 (2205) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. Start silent recording on RD1 6. A1 setup conference to B1 7. B1 answer 8. A1 complete conference 9. Close line RD1 and reopen line RD1 10. App stop recording on RD1 11. RD disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1419 Message Sequence Charts Message Sequence Charts

Page 1483 diagram

Page 1484

Scenario 20 FI: Join calls - devRD (SME), RDD (cluster2), A (leaf) and B (leaf) - RD auto recording and A join calls Events and Call Info Setup and Action Step 4- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- A1, B1 and RD1 are in conference. Recording not retriggered on RD1. Step 8- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEP3B5F) on cluster 3 has line A1 (3601) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • devB (SEPDB17) on cluster 3 has line B1 (2303) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. B1 call A1 6. A1 answer 7. A1 join two calls wit primary call = A1 –RD1 call 8. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1420 Message Sequence Charts Message Sequence Charts

Page 1484 diagram

Page 1485

Scenario 21 FI: JAL- devRD (SME), RDD (cluster2), A1, A2 and B (leaf) - RD silent recording and A1 does JAL Events and Call Info Setup and Action Step 5- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- A2 and B1 are connected. Step 8- JAL. A1, B1 and RD1 in conference. Recording not retriggered on RD1. Step 9- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEPDB17) on cluster 3 has line A1 (2303) and A2 (1623) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • devB (SEP3B5F) on cluster 3 has line B1 (3601) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. Start silent recording on RD1 6. A2 call B1 7. B1 answer 8. A1 join two calls with primary call = A1 RD1 9. Stop recording on RD1 10. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1421 Message Sequence Charts Message Sequence Charts

Page 1485 diagram

Page 1486

Scenario 22 FI: Drop any party- devRD (SME), RDD (cluster2), A (leaf) and B (leaf) - RD auto recording and A drop B from conference Events and Call Info Setup and Action Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEP3B5F) on cluster 3 has line A1 (3601) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • devB (SEPDB17) on cluster 3 has line B1 (2303) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. A1 set up conference to B1 6. B1 answer 7. A1 complete conference 8. Reopen RD1 9. A drop B from conference 10. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1422 Message Sequence Charts Message Sequence Charts

Page 1486 diagram

Page 1487

Events and Call Info Setup and Action Step 4- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType()=CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- A1 complete conference. A1, B1 and RD1 are in conference. Recording not retriggered on RD1. Step 8- Check RD1 get ExistingCallEvent and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType()=CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 9- A drop B. A1 and RD1 are connected as two parties call. Recording retriggered on RD1. Check RD1 get CiscoTermConnRecordingEndedEv , CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType()=CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1423 Message Sequence Charts Message Sequence Charts

Page 1487 diagram

Page 1488

Events and Call Info Setup and Action .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 10- Check RD1 get CiscoTermConnRecordingEndedEv Scenario 23 FI: EM- devRD (leaf), RDD (cluster2), A (SME) - RD auto recording and A EM Login Events and Call Info Setup and Action Step 5- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- EM logout succeed. Step 7- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTI_RD3) on cluster 3 has line RD1 (1622) (active remote destination: 1721711681 on cluster2) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEPAB21) on cluster 1 has line A1 (9000) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • EM profile with line E1 (7788) 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. EM login to devA with line E1 4. E1 call RD1 5. Remote destination answer the call 6. E1 disconnect call 7. EM logout Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1424 Message Sequence Charts Message Sequence Charts

Page 1488 diagram

Page 1489

Scenario 24 Hunt list - devRD (leaf), RDD (cluster2), A (SME), B (SME) and HP(SME) - RD selective recording Events and Call Info Setup and Action Step 5- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name

SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTI_RD3) on cluster 3 has line RD1 (1621) (active remote destination: 1721711681 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (IP9) on cluster 1 has line A1 (2302) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • devB (RP) on cluster 1 has line B1 (1500) configured as: • no recording • Cluster 1 (SME): • Line Group: LG2: A1 and B1, top down • Hunt list: HL2:LG2 • Hunt pilot: 3636 - HL2

Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. RD1 call HP 3636 (1723636) 4. After remote destination answer, call is offered to A1 5. A1 answer 6. App start recording on RD1 7. App stop recording on RD1 8. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1425 Message Sequence Charts Message Sequence Charts

Page 1489 diagram

Page 1490

Scenario 25 FI: Call Park- devRD (SME), RDD (cluster2), A (leaf) - RD selective recording and A park and park reversion Events and Call Info Setup and Action Step 5- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER _INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 6- Recording not retriggered on RD1. Step 7- Park Reversion happens. Recording retriggered on RD1. Check RD1 get CiscoTermConnRecordingEndedEv , CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER _INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 8- A1 answers. Recording remains. Step 9- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEPDB17) on cluster 3 has line A1 (2303) configured as: • GW preferred • selective recording enabled • recording profile:rec_profile1: 2000 • Call park number P1 on same cluster of A with park reversion number set to A1 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. App start recording on RD1 6. A1 park call to park number P1 7. Wait for park reversion happen 8. A1 answer the call 9. App stop recording on RD1 10. A1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1426 Message Sequence Charts Message Sequence Charts

Page 1490 diagram

Page 1491

Scenario 26 FI: Barge- devRD (SME), RDD (cluster2), A (leaf), A' (leaf) - RD selective recording and A' does Barge Events and Call Info Setup and Action Step 5- A1' barge in succeeds. Check barge events. Step 6- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER _INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEPDB17) on cluster 3 has line A1 (2010) configured as: • GW preferred • selective recording enabled • devA' (SEP1396) on cluster 3 has line A1' (2010) configured as: • GW preferred • selective recording enabled 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. A1’ does barge 6. App start recording on RD1 7. App stop recording on RD1 8. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1427 Message Sequence Charts Message Sequence Charts

Page 1491 diagram

Page 1492

Scenario 27 FI: Dpark- devRD (leaf), RDD (cluster2), A (SME), B (SME) - RD selective recording and A dpark and B retrive Events and Call Info Setup and Action Step 5- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER _INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 6- Recording not retriggered on RD1. Step 7- B1 and RD1 are connected. Recording retriggered on RD1. Check RD1 get CiscoTermConnRecordingEndedEv , CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER _INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 8- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTI_RD3) on cluster 3 has line RD1 (1621) (active remote destination: 1721711681 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (IP10) on cluster 1 has line A1 (2303) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 • devB (SEP334F) on cluster 1 has line B1 (2205) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 • dpark DN: D1 (7001) is in same cluster of A, a prefix of 666 is to retrieve. 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. App start recording on RD1 6. A1 transfer call to dPark number D1 7. B1 calls dpark D1 8. Stop recording on RD1 9. B1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1428 Message Sequence Charts Message Sequence Charts

Page 1492 diagram

Page 1493

Scenario 28 FI: Monitoring- devRD (SME), RDD (cluster2), A (leaf) and B (leaf) - RD selective recording and B start monitoring Events and Call Info Setup and Action Step 5- Check A1 get CiscoTermConnMonitoringStartEv. A1: CiscoTermConnMonitorTargetInfoEv B1: CiscoTermConnMonitorTargetInfoEv Step 6- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check RD1 get CiscoTermConnRecordingEndedEv Check A1 get CiscoTermConnMonitoringEndEv. Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEPDB17) on cluster 3 has line A1 (2303) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 • devB (SEP3B5F) on cluster 3 has line B1 (3601) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 • devB is the Supervisor 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. B1 start monitoring on A1 6. App start recording on RD1 7. App stop recording on RD1 8. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1429 Message Sequence Charts Message Sequence Charts

Page 1493 diagram

Page 1494

Scenario 29 FI: Whisper coaching- devRD (leaf), RDD (cluster2), A (SME) and B (SME) - RD selective recording and B start whisper coaching Events and Call Info Setup and Action Step 5- Check A1 get MonitoringStartEvent. A1:CallAttributeInfoEvent with type = coaching B1:CallAttributeInfoEvent with type = coaching Step 6- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTI_RD3) on cluster 3 has line RD1 (1622) (active remote destination: 1721711681 on cluster2) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SIP2) on cluster 1 has line A1 (9001) configured as: • no recording • devB (SIP3) on cluster 1 has line B1 (9002) configured as: • no recording • devB is the Supervisor 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. B1 start whisper coaching on A1 6. App start recording on RD1 7. App stop recording on RD1 8. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1430 Message Sequence Charts Message Sequence Charts

Page 1494 diagram

Page 1495

Scenario 30 FI: Agent Greeting- devRD (SME), RDD (cluster2), A (leaf) and B (leaf) - RD selective recording and B start agent greeting Events and Call Info Setup and Action Step 5- Check A1 get CiscoMediaStreamStartedEv (CTI: sendMediaToBIBStartEvent). Step 6- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEPDB17) on cluster 3 has line A1 (2303) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 • devB (CTI1) on cluster 3 has line B1 (1600) configured as: • no recording • devB is the IVR 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answer the call 5. Start agent greeting on A1 with B1 as IVR DN 6. App start recording on RD1 7. App stop recording on RD1 8. A1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1431 Message Sequence Charts Message Sequence Charts

Page 1495 diagram

Page 1496

Scenario 31 FI: Persistent connection- devRD (SME), RDD (cluster2), A (leaf) - RD auto recording Events and Call Info Setup and Action Step 3- Persistent connection is created on RD1. Step 5- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 6- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEPDB17) on cluster 3 has line A1 (2303) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. App makes CreatePersistentConnection() request on RD1 4. A1 call RD1 5. Remote device answer 6. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1432 Message Sequence Charts Message Sequence Charts

Page 1496 diagram

Page 1497

Scenario 32 FI: Call pick up- devRD (SME), RDD (cluster2), A (leaf), B (leaf)- RD selective recording Events and Call Info Setup and Action Step 5- After pickup, A1 and RD1 are connected. Step 6- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (CTI1) on cluster 3 has line A1 (1600) configured as: • no recording • devB (SIP1) on cluster 3 has line B1 (9000) configured as: • no recording • A1 and B1 are in pick up group: PG_1 • Service parameter: auto pick up enabled 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. RD1 call B1 4. After remote destination answer, call is offered to B1 and A1 5. A1 pick up the call 6. App start recording on RD1 7. App stop recording on RD1 8. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1433 Message Sequence Charts Message Sequence Charts

Page 1497 diagram

Page 1498

Scenario 33 FI: CTI Failover- devRD (SME), RDD (cluster2), A (leaf) - RD selective recording Events and Call Info Setup and Action Step 4- A1 and RD1 are connected. Step 5- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 6- Stop CTI Manager service on Pub1 successfully. Step 7- Open provider on Sub1 successfully. Step 8- Check RD1 get ExistingCallEvent and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 9- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD1) on cluster 1 has line RD1 (2303) (active remote destination: 1711623 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD (CTI Port) on cluster 2. • devA (SEP3B5F) on cluster 3 has line A1 (3601) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 • devRD in device pool DPPS1 (ccm1 (cluster1 PUB), ccm2 (cluster1 SUB)) 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. RD1 call A1 4. Remote destination answers, and then A1 answer 5. App start recording on RD1 6. Stop CTI Manager service on Pub1 7. Open provider on Sub1 (SME/Cluster1) 8. Reopen RD1 9. App start recording on RD1 10. RD1 disconnects the call 11. Start CTI Manager service on Pub1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1434 Message Sequence Charts Message Sequence Charts

Page 1498 diagram

Page 1499

Scenario 34 FI: CPN- devRD (SME), RDD (cluster2), A (leaf) - RD selective recording Events and Call Info Setup and Action Step 4- A1 and RD1 are connected. Step 5- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 6- Stop CTI Manager service on Pub1 successfully. Step 7- Open provider on Sub1 successfully. Step 8- Check RD1 get ExistingCallEvent and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_APPLICATION _INITIATED_SILENT .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 9- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD1) on cluster 1 has line RD1 (2303) (active remote destination: 1711623 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD (CTI Port) on cluster 2. • devA (SEPDB17) on cluster 3 has line A1 (2010) configured as: • Phone preferred • selective recording enabled • rec_profile1: 2000 • devRD in device pool DPPS1 (ccm1 (cluster1 PUB), ccm2 (cluster1 SUB)) • SIP trunk configured for CPN on SME/cluster1 and leaf, RD set up CPN also. 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. RD1 call A1 4. Remote destination answers, and then A1 answer 5. App start recording on RD1 6. Stop CTI Manager service on Pub1 7. Open provider on Sub1 8. Reopen RD1 9. App start recording on RD1 10. RD1 disconnects the call 11. Start CTI Manager service on Pub1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1435 Message Sequence Charts Message Sequence Charts

Page 1499 diagram

Page 1500

Scenario 35 FI: Redirect- local- devRD (leaf), RDD (cluster2), A (leaf) and B (leaf) - RD auto recording and A redirect Events and Call Info Setup and Action Step 4- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 5- A1 redirects. Step 6- B1 answers. B1 and RD1 are connected. Recording retriggered on RD1. Check RD1 get CiscoTermConnRecordingEndedEv , CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 7- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTI_RD3) on cluster 3 has line RD1 (1622) (active remote destination: 1721711681 on cluster2) configured as: • auto recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (SEP3B5F) on cluster 3 has line A1 (3601) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 • devB (SEPDB17) on cluster 3 has line B1 (2303) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answers, and then A1 answer 5. A1 redirect to B1 6. B1 answer 7. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1436 Message Sequence Charts Message Sequence Charts

Page 1500 diagram

Page 1501

Scenario 36 FI: Transfer- local-devRD (SME), RDD (cluster2), A (SME) and B (SME) - RD selective recording and A transfer Events and Call Info Setup and Action Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER _INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 8- A1 complete transfer. B1 and RD1 are connected. Recording retriggered on RD1. Check RD1 get CiscoTermConnRecordingEndedEv , CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER _INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 9- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (IP10) on cluster 1 has line A1 (2303) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 • devB (SEP334F) on cluster 1 has line B1 (2205) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answers, and then A1 answer 5. App start user recording on RD1 6. A1 setup transfer to B1 7. B1 answer 8. A1 complete transfer 9. Stop recording on RD1 10. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1437 Message Sequence Charts Message Sequence Charts

Page 1501 diagram

Page 1502

Scenario 37 FI: Conference- local-devRD (SME), RDD (cluster2), A (SME) and B (SME) - RD selective recording and A conference Events and Call Info Setup and Action Step 5- Check recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER _INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 8- A1 complete conference. A1, B1 and RD1 are in conference. Recording retriggered on RD1. Check RD1 get CiscoTermConnRecordingEndedEv , CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_USER _INITIATED_FROM_APPLICATION .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_ DEVICE_TYPE_GW .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = .getMediaForkingClusterID() = name of cluster1 Step 9- Check RD1 get CiscoTermConnRecordingEndedEv Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: • selective recording enabled • GW preferred Remote Destination RDD on cluster 2. • devA (IP10) on cluster 1 has line A1 (2303) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 • devB (SEP334F) on cluster 1 has line B1 (2205) configured as: • GW preferred • selective recording enabled • rec_profile1: 2000 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, and B1 in Prov1/Prov2/Prov3 accordingly 3. A1 call RD1 4. Remote destination answers, and then A1 answer 5. App start user recording on RD1 6. A1 setup transfer to B1 7. B1 answer 8. A1 complete transfer 9. App stop recording on RD1 10. RD1 disconnects the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1438 Message Sequence Charts Message Sequence Charts

Page 1502 diagram

Page 1503

Recording Fail Event Scenario 38 Failure Event: Hold Resume- auto recording on IP phone - devRD, A, C, D (SME) and RDD (cluster2) Events and Call Info Setup and Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1439 Message Sequence Charts Recording Fail Event

Page 1503 diagram

Page 1504

Cluster 1 (SME): Step 4- Check auto recording started on A1. Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Check A1 TermConnection.getCiscoRecorderInfo(): Cluster 2: .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC Cluster 3 (leaf): .getTerminalName() = central recorder device name • "Allow trunk use GW recording" is enabled .getAddress() = Recording profile (DN 2000) • Branch recorder: 2000 .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW • devRD (CTIRD1) on cluster 1 has line RD1 (2303) (active remote destination: 1711623 on cluster2) configured as: .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = • selective recording enabled .getMediaForkingClusterID() = name of cluster1 • GW preferred Step 5- A1 put call on hold. Check A1 get CiscoTermConnRecordingEndedEv Step 6- Check auto recording started on C1. Remote Destination RDD on cluster 2. Check C1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. • devA (SEP334F) on cluster 1 has line A1 (2206) configured as: Check C1 TermConnection.getCiscoRecorderInfo(): • GW preferred .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC • auto recording enabled .getTerminalName() = central recorder device name • rec_profile1: 2000 .getAddress() = Recording profile (DN 2000) • devC (IP10) on cluster 1 has line C1 (3300) configured as: .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE • GW preferred .getMediaForkingDeviceName() = Device name of C .getProtocolReferenceGUID() = • auto recording enabled .getMediaForkingClusterID() = name of cluster1 • rec_profile1: 2000 Step 7- A1 resume. No CiscoTermConnRecordingFailedEv. • devD (SEP3925) on cluster 1 has line D1 (9002) Step 8- C1 drop. Check C1 get CiscoTermConnRecordingEndedEv 1. Open provider Prov1, Prov2, Prov3 Step 10- Check auto recording started on A1. 2. Observe RD1, RDD1, A1, C1, and D1 in Prov1/Prov2/Prov3 accordingly Check A1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. Check A1 TermConnection.getCiscoRecorderInfo(): 3. A1 call RD1 .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC 4. Remote destination answers, and then A1 answer .getTerminalName() = central recorder device name 5. A1 put call on hold .getAddress() = Recording profile (DN 2000) 6. C1 call D1, D1 answer .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW 7. A1 resume Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1440 Message Sequence Charts Message Sequence Charts

Page 1504 diagram

Page 1505

.getMediaForkingDeviceName() = SIP trunk device name - SIP GW 8. C1 drop .getProtocolReferenceGUID() = 9. A1 put on hold .getMediaForkingClusterID() = name of cluster1 10. A1 resume Step 11- Check A1 get CiscoTermConnRecordingEndedEv 11. A1 disconnect the call Scenario 39 Failure Event: Redirect- auto recording on CTI remote device - devRD, A, C, D, B, E (SME) and RDD (cluster2) Events and Call Info Setup and Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1441 Message Sequence Charts Message Sequence Charts

Page 1505 diagram

Page 1506

Cluster 1 (SME): Step 4- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Check RD1 TermConnection.getCiscoRecorderInfo(): Cluster 2: .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC Cluster 3 (leaf): .getTerminalName() = central recorder device name • "Allow trunk use GW recording" is enabled .getAddress() = Recording profile (DN 2000) • Branch recorder: 2000 .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = • auto recording enabled .getMediaForkingClusterID() = name of cluster1 • GW preferred Step 5- Drop call from recorder. Check RD1 get CiscoTermConnRecordingEndedEv Remote Destination RDD on cluster 2. Step 6- Check auto recording started on C1. • devA (SEP334F) on cluster 1 has line A1 (2205) configured as: Check C1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. • GW preferred Check C1 TermConnection.getCiscoRecorderInfo(): • selective recording enabled .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC • rec_profile1: 2000 .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) • devC (IP10) on cluster 1 has line C1 (3300) configured as: .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE • GW preferred .getMediaForkingDeviceName() = Device name of C • auto recording enabled .getProtocolReferenceGUID() = • rec_profile1: 2000 .getMediaForkingClusterID() = name of cluster1 • devD (SEP3925) on cluster 1 has line D1 (9002) Step 7-. A1 redirect and B1 answer. No CiscoTermConnRecordingFailedEv. • devB (SEPAB21) on cluster 1 has line B1 (9000) Step 9- C1 drop. Check C1 get CiscoTermConnRecordingEndedEv Step 10- Check auto recording started on RD1. • devE (IP9) on cluster 1 has line E1 (2302) Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, B1, C1, D1, and E1 in Prov1/Prov2/Prov3 accordingly Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC 3. A1 call RD1 .getTerminalName() = central recorder device name 4. Remote destination answers .getAddress() = Recording profile (DN 2000) 5. Drop call from recorder .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW 6. C1 call D1, D1 answer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1442 Message Sequence Charts Message Sequence Charts

Page 1506 diagram

Page 1507

A1 redirect to B1 .getMediaForkingDeviceName() = SIP trunk device name - SIP GW 7. .getProtocolReferenceGUID() = 8. B1 answer .getMediaForkingClusterID() = name of cluster1 9. C1 drop Step 11- Check RD1 get CiscoTermConnRecordingEndedEv 10. B1 redirect to E1 11. E1 disconnect the call Scenario 40 Failure Event: Transfer- auto recording on CTI remote device - devRD, A, C, D, B, E (SME) and RDD (cluster2) Events and Call Info Setup and Action Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1443 Message Sequence Charts Message Sequence Charts

Page 1507 diagram

Page 1508

Cluster 1 (SME): Step 4- Check auto recording started on RD1. Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Check RD1 TermConnection.getCiscoRecorderInfo(): Cluster 2: .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC Cluster 3 (leaf): .getTerminalName() = central recorder device name • "Allow trunk use GW recording" is enabled .getAddress() = Recording profile (DN 2000) • Branch recorder: 2000 .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW • devRD (CTIRD3) on cluster 1 has line RD1 (9008) (active remote destination: 1711681 on cluster2) configured as: .getMediaForkingDeviceName() = SIP trunk device name - SIP GW .getProtocolReferenceGUID() = • auto recording enabled .getMediaForkingClusterID() = name of cluster1 • GW preferred Step 5- Drop call from recorder. Check RD1 get CiscoTermConnRecordingEndedEv Remote Destination RDD on cluster 2. Step 6- Check auto recording started on C1. • devA (SEP334F) on cluster 1 has line A1 (2205) configured as: Check C1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. • GW preferred Check C1 TermConnection.getCiscoRecorderInfo(): • selective recording enabled .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC • rec_profile1: 2000 .getTerminalName() = central recorder device name .getAddress() = Recording profile (DN 2000) • devC (IP10) on cluster 1 has line C1 (3300) configured as: .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_PHONE • GW preferred .getMediaForkingDeviceName() = Device name of C • auto recording enabled .getProtocolReferenceGUID() = • rec_profile1: 2000 .getMediaForkingClusterID() = name of cluster1 • devD (SEP3925) on cluster 1 has line D1 (9002) Step 9-. A1 complete transfer. No CiscoTermConnRecordingFailedEv. • devB (SEPAB21) on cluster 1 has line B1 (9000) Step 10- C1 drop. Check C1 get CiscoTermConnRecordingEndedEv Step 13- Check auto recording started on RD1. • devE (IP9) on cluster 1 has line E1 (2302) Check RD1 get CiscoTermConnRecordingStartedEv and CiscoTermConnRecordingTargetInfoEv. 1. Open provider Prov1, Prov2, Prov3 2. Observe RD1, RDD1, A1, B1, C1, D1, and E1 in Prov1/Prov2/Prov3 accordingly Check RD1 TermConnection.getCiscoRecorderInfo(): .getRecordingType() = CALL_RECORDING_TYPE_AUTOMATIC 3. A1 call RD1 .getTerminalName() = central recorder device name 4. Remote destination answers .getAddress() = Recording profile (DN 2000) 5. Drop call from recorder .getMediaForkingDeviceType() = CALL_RECORDING_MEDIA_FORKING_DEVICE_TYPE_GW 6. C1 call D1, D1 answer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1444 Message Sequence Charts Message Sequence Charts

Page 1508 diagram

Page 1509

A1 setup transfer to B1 .getMediaForkingDeviceName() = SIP trunk device name - SIP GW 7. .getProtocolReferenceGUID() = 8. B1 answer .getMediaForkingClusterID() = name of cluster1 9. A1 complete transfer Step 14- Check RD1 get CiscoTermConnRecordingEndedEv 10. C1 drop 11. B1 transfer to E1 12. E1 answer 13. B1 complete transfer 14. E1 disconnect the call Scenario 41 Cluster ID in Open Provider: Open providers after changing cluster ID Events and Call Info Setup and Action Step 4- After provider is reopened, check to see new cluster ID via VerifyProviderInfo on getClusterID. Step 4- After provider is reopened, check to see original cluster ID via VerifyProviderInfo on getClusterID. Cluster 1 (SME): • "Allow trunk use GW recording" is enabled • Central recorder: 2000 Cluster 2: Cluster 3 (leaf): • "Allow trunk use GW recording" is enabled • Branch recorder: 2000 Remote Destination RDD on cluster 2. 1. Open provider on cluster 3 Leaf 2. Change cluster ID on cluster 3 (e.g. “ClusterArcadia2013”) 3. Restart CTI and CCM services 4. Provider is reopened on cluster 3 Leaf 5. Change cluster ID on cluster 3 back to original (e.g. “ClusterID3”) 6. Restart CTI and CCM services 7. Provider is reopened on cluster 3 Leaf 8. Close provider Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1445 Message Sequence Charts Message Sequence Charts

Page 1509 diagram

Page 1510

Secured Recording Secured Recording Use Cases Info Expected Result Scenario CallCtlTermConnTalkingEv TermA Request succeeds CiscoTermConnRecordingStartEv TermA CiscoTermConnRecordingTargetInfoEv Scenario 1 1 .Agent and recorder are encrypted 2. Customer is in a secured/non-secured call with the agent. 3. The agent initiates a request to record the call CallCtlTermConnTalkingEv TermA Request succeeds CiscoTermConnRecordingStartEv TermA CiscoTermConnRecordingTargetInfoEv Scenario 2

Agent is non-secured and recorder is encrypted
Customer is in a non-secured call with agent
Agent issues a request to record the call Cause = CAUSE_BCNAUTHORISED CallCtlTermConnTalkingEv TermA CiscoTermConnRecordingStartEv CiscoTermConnRecordingEndEv Scenario3
Agent is encrypted and recorder is non-secured
Customer is in a secured/non-secured call with the agent
The agent issues a request to record the call CallCtlTermConnTalkingEv TermA Request succeeds CiscoTermConnRecordingStartEv termA CiscoTermConnRecordingTargetInfoEv Scenario 4
Agent and Recorder are non-secured
Customer and Agent are in a non-secured call
Agent issues a request to record the call CallCtlTermConnTalkingEv TermA Request fails with exception Scenario 5
Agent and recorder are authenticated
Agent and customer are in a call
Agent issues a request to record the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1446 Message Sequence Charts Secured Recording

Page 1510 diagram

Page 1511

Agent is non-secured, Supervisor and recorder are encrypted
Agent is in a non-secured call with customer
Supervisor monitors the call in non-secured mode CiscoTermConnRecordingStartEv CallCtlTermConnTalkingEv TermS The recording is done in a secured mode as Both the supervisor and recorder are secured, but the overall call security is non-secured.
Application requests for recording the call at Supervisor Redirect Set OriginalCalledID The following scenario illustrates the message flows for Redirect Set OriginalCalledID. Scenario One • A, B, and C appear in an applications controlled list. • D is does not appear in the control list. • A calls B. • B redirects call to D with C as preferredOriginalCalledParty. Application will see following events for parties A and B: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1447 Message Sequence Charts Redirect Set OriginalCalledID

Page 1511 diagram

Page 1512

Fields Event Call Meta Event Cause CallingParty = A CalledParty = B LastRedirectedParty = C CurrentCalledParty = D ConnCreatedEv for D ConnConnectedEv for DCallCtl ConnEstablishedEv for D Call 1 META_CALL_ADDING_PARTY CallingParty = A CalledParty = B LastRedirectedParty = C CurrentCalledParty = D ConnDisconnectedEv for B CallCtlConnDisconnectedEv for B TermConnDroppedEv for B CallCtlTermConnDroppedEv for B CallObservationEndedEv for B Call 1 META_CALL_REMOVE_PARTY The specified event group may not be in the same order and might change depending on where parties are present in the cluster, on the load, and other conditions. Note Scenario Two • A, B, and C do not appear in the Control list, and • D is in the application control list. • A calls B. • B redirects the call to D with C as preferredOriginalCalledParty. The application will see following events for party D: . Fields Event Call Meta Event Cause CallingParty = A CalledParty = D LastRedirectedParty = C CurrentCalledParty = D CallActiveEv ConnCreatedEv for D ConnInProgressEv for D CallCtlConnOfferedEv for D ConnCreatedEv for A CallCtlConnInitiatedEv for A Call1 META_CALL_STARTING CallingParty = A CalledParty = D LastRedirectedParty = C CurrentCalledParty = D ConnAlertingEv for D CallCtlConnAlertingEv for D TermConnCreatedEv for D CallCtlTermConnRingingEv for D ConnConnectedEv for A CallCtlConnEstablishedEv for A Call1 META_CALL_PROGRESS CallingParty = A CalledParty = D LastRedirectedParty = C CurrentCalledParty = D ConnConnectedEv for D CallCtlConnEstablishedEv for D TermConnActiveEv for D CallCtlTermConnTalkingEv for D Call META_CALL_PROGRESS Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1448 Message Sequence Charts Message Sequence Charts

Image 1 from page 1512

Page 1512 diagram

Page 1513

Redirect to a Device The following tables display message sequence charts for the Redirect enhancement that allows you to redirect calls to a specific device, even if that device is sharing a line with another device. CallRedirect to Shared Line with Device Name In this use case devices A, B, C, and C' are IP phones where C and C' share a line. RP is the route point. CallInfo Events Action GC1 CallActiveEv A GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEv TermA GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAltertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEv TermB GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B A calls B and B answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1449 Message Sequence Charts Redirect to a Device

Page 1513 diagram

Page 1514

CallInfo Events Action CurrentCallingParty = A CurrentCalledParty = C Reason = CiscoFeatureReason.REASON_REDIRECT GC1 ConnCreatedEv C GC1 ConnInProgressEv C GC1 CallCtlConnOfferedEv C GC1 ConnAlertingEv C GC1 CallCtlConnAlertingEv C GC1 TermConnCreatedEv TermC GC1 TermConnRingingEv TermC GC1 CallCtlTermConnRingingEvImpl TermC GC1 TermConnCreatedEv TermC' GC1 TermConnPassiveEv TermC' GC1 CallCtlTermConnInUseEv TermC' GC1 TerConnDroppedEv TermB GC1 CallCtlTermConnDroppedEv TermB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B Application redirects the call from B to C using CiscoConnection.redirect() method with devcieName as C CallRedirect to Shared Line with Invalid Device Name In this use case devices A, B, C, and C' are IP phones where C and C' share a line. RP is the route point. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1450 Message Sequence Charts Message Sequence Charts

Page 1514 diagram

Page 1515

CallInfo Events Action GC1 CallActiveEv A GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEV TermA GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAltertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEv TermB GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B A calls B and B answers InvalidPartyException caught: geterrorcode() = CiscoJtapiException. REDIRECT_CALL_INVALID _DEVICE_NAME Application redirects the call from B to C using CiscoConnection.redirect() method with deviceName as D CallRedirect to Shared Line using selectRoute In this use case devices A, B, C, and C' are IP phones where C and C' share a line. RP is the route point. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1451 Message Sequence Charts Message Sequence Charts

Page 1515 diagram

Page 1516

CallInfo Events Action GC1 CallActiveEv A GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEV TermA GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv RP GC1 ConnInProgressEv RP GC1 CallCtlConnOfferedEv RP A calls route point RP. RP redirects the call to the destination C using selectRoute() method CurrentCallingParty = A CurrentCalledParty = C Reason = CiscoFeatureReason.REASON_REDIRECT GC1 ConnCreatedEv C GC1 ConnInProgressEv C GC1 ConnAltertingEv C GC1 CallCtlConnAlertingEv C GC1 TermConnCreatedEv TermC GC1 TermConnRingingEv TermC GC1 CallCtlTermConnRingingEv TermC GC1 ConnCreatedEv C' GC1 TermConnPassiveEv TermC' GC1 CallCtlTermConnInUseEv TermC' RP redirects the call to the destination C using selectRoute() method Verify Remote Destination Support Table 347: Verify Remote Destination in Add Where Route Pattern Configured Is 7.XXXX and Destination Reachable. User1 Has cti Remote Device in Its Control List Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1452 Message Sequence Charts Verify Remote Destination Support

Page 1516 diagram

Page 1517

Call Info Events Action CiscoProvTerminalRemote DestinationChangedEv. getRemoteDestinations() which returns an array of all remote destinations configured for that remote terminal, CiscoRemoteDestinationInfo[0] (assuming only one configured) CiscoRemoteDestination Info[0].getRemoteDestinationName() = "testRDD" CiscoRemoteDestination Info[0].getRemoteDestinationNumber() = "77000" CiscoRemoteDestination Info[0].getIsActiveRD() = true CiscoProvTerminalRemoteDestinationChangedEv User1 invokes CiscoRemoteTerminal. addRemoteDestination ("testRDD", "77000", true) Table 348: Verify Remote Destination in Update Where Route Pattern Configured Is 7.XXXX and Destination Reachable. User1 Has cti Remote Device in Its Control List and Existing Remote Destination of 77000 Configured. User Invokes CiscoRemoteTerminal.updateRemoteDestination() Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. CiscoProvTerminalRemote DestinationChangedEv. getRemoteDestinations() which returns an array of all remote destinations configured for that remote terminal, CiscoRemoteDestinationInfo[0] (assuming only one configured) CiscoRemoteDestination Info[0].getRemoteDestinationName() = "testRDD" CiscoRemoteDestination Info[0].getRemoteDestinationNumber() = "79000" CiscoRemoteDestination Info[0].getIsActiveRD() = true CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. updateRemoteDestination("77000", "testRDD", "79000", true) Table 349: Verify Remote Destination in Update Where Route Pattern Configured Is 7.XXXX and Destination Reachable. User1 Has cti Remote Device in Its Control List and Existing Remote Destination of 77000 Configured. User Invokes CiscoRemoteTerminal.updateRemoteDestination() Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1453 Message Sequence Charts Message Sequence Charts

Page 1517 diagram

Page 1518

Call Info Events Action CiscoProvTerminalRemote DestinationChangedEv. getRemoteDestinations() which returns an array of all remote destinations configured for that remote terminal, CiscoRemoteDestination Info[0] (assuming only one configured) CiscoRemoteDestination Info[0].getRemoteDestinationNumber() = "79000" CiscoProvTerminalRemote DestinationChangedEv User1 invokes CiscoRemoteTerminal. updateRemoteDestination Number("77000", "79000") Table 350: Verify Remote Destination in Add Where Route Pattern Configured Is 7.XXXX and Destination Is Not Reachable. User1 Has cti Remote Device in Its Control List Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex). getErrorCode() = CiscoJtapiException. CTIERR_EXTEND_AND_ CONNECT_DESTINATION _NOT_REACHABLE. Caught exception com.cisco.jtapi.PlatformExceptionImpl:Extend and Connect destination is not reachable User1 invokes CiscoRemoteTerminal. addRemoteDestination ("testRDD", "99000", true) Table 351: Verify Remote Destination in Update Where Route Pattern Configured Is 7.XXXX and Destination Is Not Reachable. User1 Has cti Remote Device in Its Control List and Existing Remote Destination of 77000 Configured. User Invokes CiscoRemoteTerminal.updateRemoteDestination() Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex). getErrorCode() = CiscoJtapiException. CTIERR_EXTEND_AND_CONNECT _DESTINATION_NOT_REACHABLE. Caught exception com.cisco.jtapi. PlatformExceptionImpl: Extend and Connect destination is not reachable User1 invokes CiscoRemoteTerminal. updateRemoteDestination ("77000", "testRDD", "99000", true) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1454 Message Sequence Charts Message Sequence Charts

Page 1518 diagram

Page 1519

Table 352: Verify Remote Destination in Update Where Route Pattern Configured Is 7.XXXX and Destination Is Not Reachable. User1 Has cti Remote Device in Its Control List and Existing Remote Destination of 77000 Configured. User Invokes CiscoRemoteTerminal.updateRemoteDestinationNumber() Call Info Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. Let "ex" be an instance of PlatformException: ((CiscoJtapiException) ex). getErrorCode() = CiscoJtapiException. CTIERR_EXTEND_AND_CONNECT _DESTINATION_NOT_REACHABLE. Caught exception com.cisco.jtapi. PlatformExceptionImpl: Extend and Connect destination is not reachable User1 invokes CiscoRemoteTerminal. updateRemoteDestinationNumber ("77000", "99000") Secure Conferencing Call info Events Action Calling: A Called: B CallSecurityStatus = 3 (ENCRYPTED) will get updated in the call info. CallSecurityStatus = 3 (ENCRYPTED). CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A’ Cause: CAUSE_NORMAL GC1:ConnCreatedEv for B’ Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CallSecurityStatusChangedEv for callID = GC1 Returns the call security status of the call. Scenario:1 Configuration: A (secure) and B (secure). A calls B. B answers. Application issues getCallSecurtyStatus(). Participants: A, B, C CallSecurityStatus = 1 (NOTAUTHENTICATED). Note: Though CallSecurityStatus = NotAuthenticated, A and B will continue to have secure media between themselves and the conference bridge, i.e. they will continue to receive SRTP key info because they are encrypted parties. CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A’ Cause: CAUSE_NORMAL GC1:ConnCreatedEv for B’ Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CallSecurityStatusChangedEv for callID = GC1. Configuration: A (secure), B (secure) and C (non-secure). Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv () A calls B. B answers. B call C. C answers. B completes conference. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1455 Message Sequence Charts Secure Conferencing

Page 1519 diagram

Page 1520

Call info Events Action Participants: A, B, C CallSecurityStatus = 3 (ENCRYPTED) will get updated in the call info. CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A’ Cause: CAUSE_NORMAL GC1:ConnCreatedEv for B’ Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CallSecurityStatusChangedEv for callID = GC1. Returns the call security status of the call (Secure). Scenario:3 Configuration: A (secure), B (secure) and C (secure). Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv () A calls B. B answers. B call C. C answers. B completes conference. Application issues getCallSecurtyStatus(). Participants: A, B, C CallSecurityStatus = 1 (NOTAUTHENTICATED) will get updated in the call info. CallSecurityStatusChangedEv for callID = GC1 with Cause = CAUSE_SNAPSHOT Returns the call security status of the call. Scenario:4 Application does not add call observers on A, B, C. Configuration: A (secure), B (secure) and C (non-secure). A calls B. B answers. B call C. C answers. B completes conference. Application later adds call observers on A, B, C. Application issues getCallSecurtyStatus(). CallSecurityStatus = 3 (ENCRYPTED) will get updated in the call info. CallSecurityStatus = 0 (UNKNOWN) will get updated in the call info. CallSecurityStatus = (ENCRYPTED) will get updated in the call info. CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnCreatedEv for B Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CallSecurityStatusChangedEv for callID = GC1 CallSecurityStatusChangedEv for callID = GC1 CallSecurityStatusChangedEv for callID = GC1 Scenario:5 Configuration: A (secure), B (secure). Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv() A calls B. B answers. B puts call on hold. B resumes call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1456 Message Sequence Charts Message Sequence Charts

Page 1520 diagram

Page 1521

Call info Events Action CallSecurityStatus = 3 (ENCRYPTED) will get updated in the call info for GC1. CallSecurityStatus = 1 (NOTAUTHENTICATED) will get updated in the call info for GC2. CallSecurityStatus = 1 (NOTAUTHENTICATED) will get updated in the call info for GC1. CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A’ Cause: CAUSE_NORMAL GC1:ConnCreatedEv for B’ Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CallSecurityStatusChangedEv for callID = GC1 CallActiveEv for callID = GC2 Cause: CAUSE_NEW_CALL GC2:ConnCreatedEv for B’ Cause: CAUSE_NORMAL GC2:ConnCreatedEv for C’ Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CallSecurityStatusChangedEv for callID = GC2 CallCtlSecurityStatusChangedEv for callID = GC1 Scenario:6 Configuration: A (secure), B (secure) and C (non-secure). Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv() A calls B. B answers. B consults C. C answers. B completes transfer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1457 Message Sequence Charts Message Sequence Charts

Page 1521 diagram

Page 1522

Call info Events Action CallSecurityStatus = 3 (ENCRYPTED) will get updated in the call info for GC1. CallSecurityStatus = 2 (AUTHENTICATED) will get updated in the call info for GC2. CallSecurityStatus = 1 (NOTAUTHENTICATED) will get updated in the call info for GC1 and GC2. CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A’ Cause: CAUSE_NORMAL GC1:ConnCreatedEv for B’ Cause: CAUSE_NORMAL GC1:ConnCreatedEv for C’ Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC2:ConnCreatedEv for C’ Cause: CAUSE_NORMAL GC2:ConnCreatedEv for D’ Cause: CAUSE_NORMAL GC2:ConnCreatedEv for E’ Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CallCtlSecurityStatusChangedEv for callID = GC1 Scenario:7 Configuration: A (secure), B (secure), C (secure), D (secure), and E (Authenticated). Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv() A, B and C are part of a conference Call 1. C, D and E are a part of another conference Call 2. C chains the 2 conferences. CallSecurityStatus = 2 (AUTHENTICATED) will get updated in the call info for GC1. Note Applications who have added call observers on B’ will also get the event, i.e. the new event will be delivered to RIU Parties as well. CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A’ Cause: CAUSE_NORMAL GC1:ConnCreatedEv for B’ Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CallSecurityStatusChangedEv for callID = GC1. Scenario:8 Configuration: A (secure), B (secure), B (authenticated) Application sets ini parameter = true by issuing enableSecurtyStatusChangedEv() Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1458 Message Sequence Charts Message Sequence Charts

Page 1522 diagram

Page 1523

Secure Connection Enhancements Call information Events Action Provider is initialized correctly through TLS connection. Provider.getAddress() and provider.getTerminals() return correct number of addresses and terminals ProvInService event is delivered to provider observer The application wants to connect securely to Cisco Unified Communications Manager and downloads the certficate using the interfaces in CiscoJtapiProperties. After down loading the certificate, application initializes provider using a providerString formatted with new parameters: String providerString = serverName + ";login = " + login + ";passwd = " + passwd + ";InstanceID = " + instanceID + ";CAPF = " + CAPFserver + ";CAPFPort = " + capfport + ";TFTP = " + TFTPServer + ";TFTPPort = " + tftpport + ";CertPath = " + certificatepath+ ";CertStorePassphrase = " + cartificatepassphrase +";" JtapiPeer peer = JtapiPeerFactory.getJtapiPeer ( null ); MyProviderObserver providerObserver = new MyProviderObserver (); provider = peer.getProvider ( providerString ); Provider is initialized correctly. Provider.getAddress() and provider.getTerminals() return correct number of addresses and terminals ProvInService is delivered to provider observer The application is not interested in secure connection and open provider using userid and passwd in provider String String providerString = serverName + ";login = " + login + ";passwd = " + ";" Provider is initialized correctly through TLS connection. Provider.getAddress() and provider.getTerminals() return correct number of addresses and terminals The application uses jtprefs to download the certificates and initializes provider specifying only the userid, passwd, instanceid and certificate pass phrase in provider string. String providerString = serverName + ";login = " + login + ";passwd = " + passwd + ";InstanceID = " + instanceID +":CertStorePassphrase = " + cartificatepassphrase +";" Secure Icon Enhancements Enable the callSecurityStatusChangedEv using JTAPI ini parameters or using the JTAPIProperties. Cluster1 and Cluster2 are secured and User is also a secured user having a CAPF profile associated with it. Enable "SRTP Allowed" in the SIP trunk Configurations. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1459 Message Sequence Charts Secure Connection Enhancements

Page 1523 diagram

Page 1524

TermA is registered to Cluster1 with address A. TermB is registered to Cluster2 with address B TermC is registered to Cluster2 or Cluster1 as per Use case and has address C SIP trunk is configured on Cluster1 to make calls to cluster2 A Route Pattern is configured on Cluster 1 to route the call to the SIP trunk Use Case One Information Expected results Action Set the value for "Consider Traffic on this Trunk Secure" to 'When Using only sRTP' in the SIP trunk config on cluster1. Security Mode of Both term A and termB is encrypted. Security mode of the SIP trunk is non secured. GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConenctedEvA GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEv TermA GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 ConnEstablishedEv A A calls B though the route pattern. Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEvImpl termB Call is offered on B and B accepts. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1460 Message Sequence Charts Message Sequence Charts

Page 1524 diagram

Page 1525

Information Expected results Action Ev.getCallSecurityStatus() = CALLSECURITY_ENCRYPTED TermA CiscoRTPOutputStartedEv GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv TermB TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermB CiscoRTPInputStartedEv GC1 CiscoCallSecurityStatusChangedEv B answers the call Use Case Two Information Expected results Action Set the value for "Consider Traffic on this Trunk Secure" to 'When Using only sRTP' in the SIP trunk config on cluster1. Security Mode for term A and termB and term C is encrypted. Security mode of the SIP trunk is non secured. GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConenctedEvA GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEv TermA GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 ConnEstablishedEv A A calls B though the route pattern. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1461 Message Sequence Charts Message Sequence Charts

Page 1525 diagram

Page 1526

Information Expected results Action Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEvImpl termB Call is offered to B and B accepts. Ev.getCallSecurityStatus() = CALLSECURITY_ENCRYPTED TermA CiscoRTPOutputStartedEv GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv TermB TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermB CiscoRTPInputStartedEv GC1 CiscoCallSecurityStatusChangedEv B answers the call. call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED TermA CiscoRTPOutputStoppedEv TermB CiscoRTPOutputStoppedEv TermA CiscoRTPInputStoppedEv TermB CiscoRTPInputStoppedEv GC1 ConnCreatedEv C GC1 ConnInProgressEv C GC1 CallCtlConnOfferedEv C GC1 ConnAlertingEv C GC1 CallCtlConnAlertingEv C GC1 TermConnCreatedEv TermC GC1 TermConnRingingEv TermC GC1 CallCtlTermConnRingingEvImpl termC GC1 TermConnDroppedEv TermB GC1 CallCtlTermConnDroppedEv TernB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B B Redirects the call to C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1462 Message Sequence Charts Message Sequence Charts

Page 1526 diagram

Page 1527

Information Expected results Action Ev.getCallSecurityStatus() = CALLSECURITY_ENCRYPTED GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv TermB TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermB CiscoRTPInputStartedEv TermA CiscoRTPOutputStartedEv GC1 CiscoCallSecurityStatusChangedEv C answers the call Use Case Three Information Expected results Action Set the value for "Consider Traffic on this Trunk Secure" to 'When Using only sRTP' in the SIP trunk config on cluster1 Security Mode of Both term A and termB and term C is encrypted Security mode of the SIP trunk is non secured GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConenctedEvA GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEv TermA GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 ConnEstablishedEv A A calls B though the route pattern Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1463 Message Sequence Charts Message Sequence Charts

Page 1527 diagram

Page 1528

Information Expected results Action Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEvImpl termB Call is offered on B and B accepts Ev.getCallSecurityStatus() = CALLSECURITY_ENCRYPTED TermA CiscoRTPOutputStartedEv GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv TermB TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermB CiscoRTPInputStartedEv GC1 CiscoCallSecurityStatusChangedEv B answers the call Ev.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED GC1 CallCtlTermConnHeldEv TermB GC1 CiscoCallSecurityStatusChangedEv GC2 CallActiveEv GC2 ConnCreatedEv B GC2 ConnConenctedEvB GC2 CallCtlConnInitiatedEv B GC2 TermConnCreatedEv TermB GC2 TermConnActiveEv TermB GC2 CallCtlTermConnTalkingEv TermB GC2 CallCtlConnDialingEv B GC2 ConnEstablishedEv B B calls C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1464 Message Sequence Charts Message Sequence Charts

Page 1528 diagram

Page 1529

Information Expected results Action Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED GC2 ConnCreatedEv C GC2 ConnInProgressEv C GC2 CallCtlConnOfferedEv C GC2 ConnAlertingEv C GC2 CallCtlConnAlertingEv C GC2 TermConnCreatedEv TermC GC2 TermConnRingingEv TermC GC2 CallCtlTermConnRingingEvImpl termC Call is offered on C and C accepts Ev.getCallSecurityStatus() = CALLSECURITY_ENCRYPTED TermB CiscoRTPOutputStartedEv GC2 ConnConnectedEv C GC2 CallCtlConnEstablishedEv C GC2 TermConnActiveEv C GC2 CallCtlTermConnTalkingEv TermC TermB CiscoRTPInputStartedEv TermC CiscoRTPOutputStartedEv TermC CiscoRTPInputStartedEv GC2 CiscoCallSecurityStatusChangedEv C answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1465 Message Sequence Charts Message Sequence Charts

Page 1529 diagram

Page 1530

Information Expected results Action Ev.getCallSecurityStatus() = CALLSECURITY_ENCRYPTED GC1 CiscoTermConnSelectChangedEv termB GC2 CiscoTermConnSelectChangedEv TermB TermC CiscoRTPOutputStoppedEv TermB CiscoRTPOutputStoppedEv TermC CiscoRTPInputStoppedEv TermB CiscoRTPInputStoppedEv GC1 CiscoTransferStartEv GC2 CiscoCallChangedEv GC1 ConnCreatedEv C GC1 ConnConnectedEv C GC1 CallCtlConnEstablishedEv C GC1 TermConnCreatedEv TermC Gc1 TermConnActiveEv TermC Gc1 CallCtlTermConnTalkingEv TermC GC2 TermConnDroppedEv TermC GC2 CallCtlTermConnDroppedEv TermC GC2 ConnDisconnectedEv C GC2 CallCtlConnDisconnectedEv C GC2 TermConnDroppedEv termB GC2 CallCtlTermConnDroppedEv TermB GC2 ConnDisconnectedEv B GC2 CallCtlConnDisconnectedEv B GC2 CallInvalidEv GC1 TermConnDroppedEv termB GC1 CallCtlTermConnDroppedEv TermB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B GC1 CiscoTransferEndEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermB CiscoRTPInputStartedEv TermA CiscoRTPOutputStartedEv GC1 CiscoCallSecurityStatusChangedEv B does a Direct Transfer GC1.transfer(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1466 Message Sequence Charts Message Sequence Charts

Page 1530 diagram

Page 1531

Use Case Four Information Expected results Action Set the value for "Consider Traffic on this Trunk Secure" to 'When using both sRTP and TLS' in the SIP trunk config on cluster1 Security Mode of Both term A and termB and term C is encrypted Security mode of the SIP trunk is non secured GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConenctedEvA GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEv TermA GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 ConnEstablishedEv A A calls B though the route pattern Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TermB GC1 TermConnRingingEv TermB GC1 CallCtlTermConnRingingEvImpl termB Call is offered on B and B accepts Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1467 Message Sequence Charts Message Sequence Charts

Page 1531 diagram

Page 1532

Information Expected results Action Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED TermA CiscoRTPOutputStartedEv GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv TermB TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermB CiscoRTPInputStartedEv B answers the call Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED GC1 CallCtlTermConnHeldEv TermB GC2 CallActiveEv GC2 ConnCreatedEv B GC2 ConnConenctedEvB GC2 CallCtlConnInitiatedEv B GC2 TermConnCreatedEv TermB GC2 TermConnActiveEv TermB GC2 CallCtlTermConnTalkingEv TermB GC2 CallCtlConnDialingEv B GC2 ConnEstablishedEv B B calls C Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED GC2 ConnCreatedEv C GC2 ConnInProgressEv C GC2 CallCtlConnOfferedEv C GC2 ConnAlertingEv C GC2 CallCtlConnAlertingEv C GC2 TermConnCreatedEv TermC GC2 TermConnRingingEv TermC GC2 CallCtlTermConnRingingEvImpl termC Calls is offered on C and C accepts Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1468 Message Sequence Charts Message Sequence Charts

Page 1532 diagram

Page 1533

Information Expected results Action Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED TermB CiscoRTPOutputStartedEv GC2 ConnConnectedEv C GC2 CallCtlConnEstablishedEv C GC2 TermConnActiveEv C GC2 CallCtlTermConnTalkingEv TermC TermB CiscoRTPInputStartedEv TermC CiscoRTPOutputStartedEv TermC CiscoRTPInputStartedEv C answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1469 Message Sequence Charts Message Sequence Charts

Page 1533 diagram

Page 1534

Information Expected results Action Call.getCallSecurityStatus() = CALLSECURITY_NOTAUTHENTICATED GC1 CiscoTermConnSelectChangedEv termB GC2 CiscoTermConnSelectChangedEv TermB TermC CiscoRTPOutputStoppedEv TermB CiscoRTPOutputStoppedEv TermC CiscoRTPInputStoppedEv TermB CiscoRTPInputStoppedEv GC1 CiscoTransferStartEv GC2 CiscoCallChangedEv GC1 ConnCreatedEv C GC1 ConnConnectedEv C GC1 CallCtlConnEstablishedEv C GC1 TermConnCreatedEv TermC Gc1 TermConnActiveEv TermC Gc1 CallCtlTermConnTalkingEv TermC GC2 TermConnDroppedEv TermC GC2 CallCtlTermConnDroppedEv TermC GC2 ConnDisconnectedEv C GC2 CallCtlConnDisconnectedEv C GC2 TermConnDroppedEv termB GC2 CallCtlTermConnDroppedEv TermB GC2 ConnDisconnectedEv B GC2 CallCtlConnDisconnectedEv B GC2 CallInvalidEv GC1 TermConnDroppedEv termB GC1 CallCtlTermConnDroppedEv TermB GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectedEv B GC1 CiscoTransferEndEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermB CiscoRTPInputStartedEv TermA CiscoRTPOutputStartedEv B does a Direct Transfer GC1.transfer(GC2) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1470 Message Sequence Charts Message Sequence Charts

Page 1534 diagram

Page 1535

Shared Line Support The following diagrams illustrate the message flows for Shared Line support. AddressInService/AddressOutofService Events Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1471 Message Sequence Charts Shared Line Support

Image 1 from page 1535

Page 1535 content

Page 1536

Incoming Call to Shared Address Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1472 Message Sequence Charts Incoming Call to Shared Address

Image 1 from page 1536

Page 1536 content

Page 1537

Outgoing Call From Shared Address Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1473 Message Sequence Charts Outgoing Call From Shared Address

Image 1 from page 1537

Page 1537 content

Page 1538

Shared Address Calling Itself Single Sign-On Here are the list of use cases for this feature. Result Scenario Sl. No Returns provider to the application and all the addresses configured in the control list. Start the application (cucimoc) and getProvider(str) API is called by application specifying the singlesignon ticket. Application calls getAddresses() API. 1. Throws a platform exception to getProvider() API. Application specifies an invalid ticket but correct userid and password in API. 2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1474 Message Sequence Charts Shared Address Calling Itself

Image 1 from page 1538

Page 1538 diagram

Page 1539

Result Scenario Sl. No Returns provider to the application. Delivers ProvOutOfServiceEv to provider observer. JTAPI connects and tries to authenticate the user which fails. Delivers ProvShutdownEv to provider observer. Returns provider object to the application. Start the application and it calls the getProvider() API with singlesignon ticket. The network connectivity is lost. Application gets a new singlesignon token and calls getProvider(). 3. Throws PlatformException and getErrorCode() returns CiscoJTAPIException - CTIERR_SSO_DISABLED. Start the application and getProvider() API is called by application with the singlesignon ticket. But the feature is not enabled on Cisco Unified Communications Manager. 4. Throws PlatformException and getErrorCode() returns CiscoJTAPIException - CTIERR_DIRECTORY_LOGIN_FAILED. Start the application and getProvider() API is called by application with invalid singlesignon ticket. 5. Both getProvider() call is successful with the first provider. Throws exception to the second getProvider(). Multiple providers: Start the application and getProvider() on two nodes in the cluster with the same token. 6. Single Step Transfer Addresses A, B, and C appear in the control list, and the call between A and B is then gets transferred to C with B as the transfer controller. Applications will see the following events: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1475 Message Sequence Charts Single Step Transfer

Page 1539 diagram

Page 1540

Address C (5003) Terminal CTIP3 Address B (5002) Terminal CTIP2 Address A (5001) Terminal CTIP1 Action CallActiveEv Cause: CAUSE_NEW_CALL ConnCreatedEv 5003 Cause: CAUSE_NORMAL ConnInProgressEv 5003 Cause: CAUSE_NORMAL CallCtlConnOfferedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER ConnCreatedEv 5001Cause: CAUSE_NORMAL ConnConnectedEv 5001 Cause: CAUSE_NORMAL CallCtlConnEstablishedEv 5001Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL NEW META EVENT__META_CALL_ REMOVING_PARTY TermConnDroppedEv CTIP2 Cause: CAUSE_NORMAL CallCtlTermConnDroppedEv CTIP2 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER ConnDisconnectedEv 5002 Cause: CAUSE_NORMAL CallCtlConnDisconnectedEv 5002 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER ConnCreatedEv 5003 Cause: CAUSE_NORMAL ConnInProgressEv 5003 Cause: CAUSE_NORMAL CallCtlConnOfferedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER ConnAlertingEv 5003 Cause: CAUSE_NORMAL CallCtlConnAlertingEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_TRANSFER Call.transfer(string) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1476 Message Sequence Charts Message Sequence Charts

Page 1540 diagram

Page 1541

Address C (5003) Terminal CTIP3 Address B (5002) Terminal CTIP2 Address A (5001) Terminal CTIP1 Action ConnAlertingEv 5003 Cause: CAUSE_NORMALCallCtl ConnAlertingEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL TermConnCreatedEv CTIP3 TermConnRingingEv CTIP3Cause: CAUSE_NORMAL CallCtlTermConnRingingEvImpl CTIP3 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL CiscoRTPInputStartedEv Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv Cause: CAUSE_NORMAL ConnConnectedEv 2004 Cause: CAUSE_NORMAL CallCtlConnEstablishedEv 5003Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL NEW META EVENT_________META_UNKNOWN CallObservationEndedEv Cause: CAUSE_NORMAL CiscoRTPInputStartedEv Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv Cause: CAUSE_NORMAL ConnConnectedEv 5003 CAUSE_NORMAL CallCtlConnEstablishedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL Call.transfer(string) (continued) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1477 Message Sequence Charts Message Sequence Charts

Page 1541 diagram

Page 1542

Address C (5003) Terminal CTIP3 Address B (5002) Terminal CTIP2 Address A (5001) Terminal CTIP1 Action TermConnActiveEv CTIP3 Cause: CAUSE_NORMAL CallCtlTermConnTalkingEv CTIP3 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL CiscoRTPInputStoppedEv Cause: CAUSE_NORMAL CiscoRTPOutputStoppedEv Cause: CAUSE_NORMAL ConnDisconnectedEv 5001 Cause: CAUSE_NORMAL CallCtlConnDisconnectedEv 5001 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL TermConnDroppedEv CTIP3 Cause: CAUSE_NORMAL CallCtlTermConnDroppedEv CTIP3 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL ConnDisconnectedEv 5003 Cause: CAUSE_NORMAL CallCtlConnDisconnectedEv 5003 Cause: CAUSE_NORMAL CallControlCause: CAUSE_NORMAL META_UNKNOWN CallInvalidEv [#32] Cause: CAUSE_NORMAL Call.transfer(string) (continued) SIP REPLACE For the JTAPI events in the scenario described below, we have not shown Terminal events. It will be sent for all the observed Terminals as usual. Also events are shown with the assumption that only A, B, or C is observed; events would vary if combination of A, B, or C is observed. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1478 Message Sequence Charts SIP REPLACE

Page 1542 diagram

Page 1543

Events at C Events at B Events at A Scenario SN NewCall/CSCE -Dialing/ CSCE -Connected with Cgpn = C, Cdpn = A, Ocdpn = B, Lrp = B JTAPI Events: CallActiveEv –GC2 ConnCreatedEv –C –GC2 ConnConnectedEv -C -–GC2 CallCtlConnEstablishedEv -C–GC2 ConnCreatedEv –A–GC2 ConnConnectedEv A -–GC2 CallCtlConnEstablishedEv -A -–GC2 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES JTAPI CallInfo: Calling = C, Called = A, CurrentCalling = C, CurrentCalled = A, LastRedirecting = B CSCE IDLE with reason REPLACES JTAPI Events: ConnDisconnectedEv –A –GC1 CallCtlConnDisconnectedEv -A -GC1 ConnDisconnectedEv –B -GC1 CallCtlConnDisconnectedEv -B -GC1 CallInvalidEv -GC1 CAUSE_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES GCID and CPIC with reason REPLACES, Cgpn = C, Cdpn = A, Ocdpn = A, Lrp = B JTAPI Events: CiscoCallChangedEv - (GC1 -GC2) ConnDisconnectedEv –B -GC1 CallCtlConnDisconnectedEv -B–GC1 ConnDisconnectedEv –A -GC1 CallCtlConnDisconnectedEv -A–GC1 CallInvalid -GC1 CallActive -CG2 ConnCreatedEv –C -GC2 ConnConnectedEv –C -GC2 CallCtlConnEstablishedEv -C -CG2 ConnCreatedEv –A –GC2 ConnConnectedEv –A -GC2 CallCtlConnEstablishedEv -A -CG2 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES JTAPI CallInfo: Calling = C, Called = A, CurrentCalling = C, CurrentCalled = A, LastRedirecting = B REPLACE with INVITE a confirmed Dialog: A (Dialog1) is in Call with B (Dialog2) (GC1). C sends INVITE with REPLACE Dialog2 (GC2). After replace is completed, A (Dialog1) and C (Dialog3) are in the Call 1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1479 Message Sequence Charts Message Sequence Charts

Page 1543 diagram

Page 1544

Events at C Events at B Events at A Scenario SN NewCall/CSCE -Dialing/CSCE -Connected, with Cgpn = C, Ccdpn = A, Ocdpn = A, Lrp = B JTAPI Events: CallActiveEv –GC2 ConnCreatedEv –C –GC2 ConnConnectedEv -C -–GC2 CallCtlConnEstablishedEv -C–GC2 ConnCreatedEv –A–GC2 ConnConnectedEv A -–GC2 CallCtlConnEstablishedEv -A -–GC2 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES JTAPI CallInfo: Calling = C, Called = A, CurrentCalling = C, CurrentCalled = A, LastRedirecting = B CSCE -Idle with reason REPLACES JTAPI Events: ConnDisconnectedEv –A –GC1 CallCtlConnDisconnectedEv -A -GC1 ConnDisconnectedEv –B -GC1 CallCtlConnDisconnectedEv -B -GC1 CallInvalidEv -GC1 CAUSE_NORMAL Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES GCID and CPIC with reason REPLACES, Cgpn = C, Cdpn = A, Ocdpn = A, Lrp = B JTAPI Events CiscoCallChangedEv - (GC1 -GC2) ConnDisconnectedEv –B -GC1 CallCtlConnDisconnectedEv -B–GC1 ConnDisconnectedEv –A -GC1 CallCtlConnDisconnectedEv -A–GC1 CallInvalid -GC1 CallActive -CG2 ConnCreatedEv –C -GC2 ConnConnectedEv –C -GC2 CallCtlConnEstablishedEv -C -CG2 ConnCreatedEv –A –GC2 ConnConnectedEv –A -GC2 CallCtlConnEstablishedEv -A -CG2 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES JTAPI CallInfo: Calling = C, Called = A, CurrentCalling = C, CurrentCalled = A, LastRedirecting = B REPLACE with INVITE an early Dialog: A (Dailog1) is in Call with B (Dialog2) (GC1), B is ringing. C sends INVITE with REPLACE Dialog2 (GC2). After replace completed, A (Dialog1) and C (Dialog3) in the Call 2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1480 Message Sequence Charts Message Sequence Charts

Page 1544 diagram

Page 1545

Events at C Events at B Events at A Scenario SN NewCall/CSCE_Dialing/ reason REPLACES CSCE -Disconnected with reason REPLACES JTAPI Events: CallActiveEv –GC2 ConnCreatedEv –C–GC2 ConnConnectedEv –C–GC2 CallCtlConnEstablishedEv -C -–GC2 ConnFailedEv –C -–GC2 ConnConnectedEv –C -–GC2 CallCtlConnEstablishedEv -A -–GC2 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES JTAPI CallInfo: Calling = C, Called = , CurrentCalling = C, CurrentCalled = , LastRedirecting = REPLACE with INVITE an early Dialog: A (Dialog1) is in Call with B (Dialog2) (GC1), B is ringing. C sends invite with replace Dialog -X (GC2) 3. TransferStartEv GCID with reason TRANSFER and Cgpn = B, Cdpn = C, Lrp = A OCdpn = C TransferEndEv JTAPI Event: Regular TransferEvents TransterStartEv CPIC with reason TRANSFER and Cgpn = B, Cdpn = C, Lrp = A OCdpn = C TransferEndEv JTAPI Event: Regular TransferEvents TransferStartEv CSCE -Idle at Dialog1 with reason TRANSFER and at Dialog3 with reason TRANSFER TransferEndEv JTAPI Event: Regular TransferEvent REFER request with REPLACE Dialog: When REPLACE Dialog is in a Cisco Unified Communications Manager Cluster. A is in call with B (REFEREE) Dialog1, and Dialog2 A is in Call with C (REFER TO TARGET) Dialog3 and Dialog4 SIP -UA A send REFER B on Dialog1 to C with REPLACES Dialog3 4. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1481 Message Sequence Charts Message Sequence Charts

Page 1545 diagram

Page 1546

Events at C Events at B Events at A Scenario SN No Events CPIC with reason REFER and Cgpn = B, Cdpn = C, Lrp = A OCdpn = B JTAPI Events: ConnDisconnectedEv –A -GC1 CallCtlConnDisconnectedEv -A -GC1 ConnCreatedEv – C –GC1 ConnConnectedEv –C -GC1 CallCtlConnEstablishedEv–C -GC1 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REFER JTAPI CallInfo: Calling = A, Called = B, CurrentCalling = B, CurrentCalled = C, LastRedirecting = A No Events REFER request with REPLACE Dialog: When REPLACE Dialog is outside Cisco Unified Communications Manager Cluster SIP -UA A is in call with B, Dialog1 and Dialog2 (GC1) SIP -UA A is in call with SIP -UA C Dialog3 SIP -UA A sends REFER B on Dialog1 to SIP -UA C with REPLACES Dialog3 5. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1482 Message Sequence Charts Message Sequence Charts

Page 1546 diagram

Page 1547

Events at C Events at B Events at A Scenario SN GCID with reason REPLACES and Cgpn = B, Cdpn = C, Lrp = A OCdpn = C JTAPI Events: CiscoCallChangedEv (GC2 -GC1) ConnDisconnectedEv –A -GC2 CallCtlConnDisconnectedEv -A -GC2 ConnDisconnectedEv –C -GC2 CallCtlConnDisconnectedEv -C -GC2 CallInvalid -GC2 CallActive -CG1 ConnCreatedEv –B –GC1 ConnConnectedEv –B -GC1 CallCtlConnEstablishedEv -B -CG1 ConnCreatedEv –C -GC1 ConnConnectedEv –C -GC1 CallCtlConnEstablishedEv -C -CG1 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES JTAPI CallInfo: Calling = A, Called = B, CurrentCalling = B, CurrentCalled = C, LastRedirecting = A CPIC with reason REPLACES and Cgpn = B, Cdpn = C, Lrp = A, OCdpn = C JTAPI Events: ConnDisconnectedEv –A -GC1 CallCtlConnDisconnectedEv -A -GC1 ConnCreatedEv – C - GC1 ConnConnectedEv –C –GC1 CallCtlConnEstablishedEv–C -GC1 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES JTAPI CallInfo: Calling = A, Called = B, CurrentCalling = B, CurrentCalled = C, LastRedirecting = A No Events REFER request with REPLACE Dialog: When A is outside a Cisco Unified Communications Manager Cluster SIP -UA A is in call with B, Dialog1 and Dialog2 SIP -UA A is in call with C Dialog3 and Dialog4 SIP -UA A sends REFER B on Dialog1 to C with REPLACES Dialog3 6. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1483 Message Sequence Charts Message Sequence Charts

Page 1547 diagram

Page 1548

Events at C Events at B Events at A Scenario SN GCID with reason REPLACES and Cgpn = B, Cdpn = C, Lrp = D, OCdpn = C JTAPI Events: CiscoCallChangedEv (GC2 -GC1) ConnDisconnectedEv -D CallCtlConnDisconnectedEv -D ConnDisconnectedEv -C CallCtlConnDisconnectedEv -C CallInvalid -GC2 CallActive -CG1 ConnCreatedEv –C -GC1 ConnConnectedEv –C -GC1 CallCtlConnEstablishedEv -C -CG1 ConnCreatedEv –B –GC1 ConnConnectedEv –B -GC1 CallCtlConnEstablishedEv -B -CG2 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES JTAPI CallInfo: Calling = C, Called = C, CurrentCalling = B, CurrentCalled = C, LastRedirecting = D CPIC with reason REPLACES and Cgpn = B, Cdpn = C, Lrp = D OCdpn = C JTAPI Events: ConnDisconnectedEv –A -GC1 CallCtlConnDisconnectedEv -A -GC1 ConnCreatedEv –C -GC1 ConnConnectedEv –C –GC1 CallCtlConnEstablishedEv -C -GC1 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES JTAPI CallInfo: Calling = A, Called = B, CurrentCalling = B, CurrentCalled = C, LastRedirecting = D CSCE -Idle at Dialog1 with reason REFER and at Dialog3 with reason REPLACES JTAPI Events: ConnDisconnectedEv –A –GC1 CallCtlConnDisconnectedEv -A -GC1 ConnDisconnectedEv –B -GC1 CallCtlConnDisconnectedEv -B -GC1 CallInvalidEv -GC1 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REFER Event at D: ConnDisconnectedEv –D –GC2 CallCtlConnDisconnectedEv -D -GC2 ConnDisconnectedEv –C -GC2 CallCtlConnDisconnectedEv -C -GC2 CallInvalidEv -GC2 Cause = CAUSE_NORMAL CiscoFeatureReason = REASON_REPLACES REFER request with REPLACE Dialog: When REPLACE Dialog is in a Cisco Unified Communications Manager Cluster. A is in call with B (REFEREE) Dailog1, and Dialog2 (GC1) D is in Call with C (REFER TO TARGET) Dialog3 and Dialog4 (GC2) A sends REFER B on Dialog1 to C with REPLACES Dialog3 B and C in final call. 7. SIP REFER The following section describes the scenarios that might be encountered during a SIP REFER. There are two categories of REFER scenarios: IN-Dialog and OutOfDialog. IN-Dialog REFER Scenario There are 11 scenarios (A through K) described in the sections that follow for IN-Dialog REFERs. Scenario One A (SIP UA in cluster/in control) is in a call with B. A (referrer) REFERs B (Referee) to C (Refer to target), C is Ringing. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1484 Message Sequence Charts SIP REFER

Page 1548 diagram

Page 1549

JTAPI moves A’s Connect/CallControlConnection/TerminalConnection/ CallControlTerminalConnection into the “UNKNOWN” state. CAUSE_CODE provided will be CAUSE_NORMAL, new API provides REASON_REFER. For C a new Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection would be created. CallInfo at B and C would be as follows: At B: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C At C: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C JTAPI Application observing B will see: getCallingParty() = A getCalledParty() = B getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A JTAPI Application observing C will see: getCallingParty() = B getCalledParty() = C getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A Scenario Two A(SIP UA in cluster/in control) is in a call with B. A(referrer) REFERs B(Referee) to C(Refer to target), C Answers the Call. JTAPI will Disconnect/Drop A’s Connect/CallControlConnection/TerminalConnection/ CallControlTerminalConnection. CAUSE_CODE provided will be CAUSE_NORMAL and the new API would provide REASON_REFER. For C Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection will move to the Connected/Established/Active/Talking state. CallInfo at B and C will be as follows At B: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C At C: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C JTAPI Application observing B will see: getCallingParty() = A getCalledParty() = B getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1485 Message Sequence Charts Message Sequence Charts

Page 1549 content

Page 1550

JTAPI Application observing C will see: getCallingParty() = B getCalledParty() = C getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A Scenario Three A(SIP UA inside cluster) is in a call with B. A(referrer) REFERs B(Referee) to C(Refer to target), C is ringing but C did not answer the call and has no forward configured. Refer fails, the original call between A and B is restored. JTAPI will Disconnect/Drop the Connection/CallControlConnection/TerminalConnection/ CallControlTerminalConnection for C. CAUSE_CODE provided will be CAUSE_NORMAL and the new API will provide REASON_REFER and move A’s Connection/CallControlConnection/ TerminalConnection/CallControlTerminalConnection from the “Unknown” state to the Connected/ Established/Active/Talking state. CallInfo at A and B will be as follows At A: Cgpn = A, Cdpn = B, Lrp = OCdpn = B At B: Cgpn = A, Cdpn = B, Lrp = OCdpn = B JTAPI Application observing A will see: getCallingParty() = A getCalledParty() = B getCurrentCallingParty() = A getCurrentCalledParty() = B getLastRedirecting() = NULL JTAPI Application observing B will see: getCallingParty() = A getCalledParty() = B getCurrentCallingParty() = A getCurrentCalledParty() = B getLastRedirecting() = NULL Scenario Four A(SIP UA outside cluster) is in call with B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1486 Message Sequence Charts Message Sequence Charts

Page 1550 content

Page 1551

A(referrer) REFERs B(Referee) to C(Refer to target), C is ringing. JTAPI will create Connection/CallControlConnection/TerminalConnection/ CallControlTerminalConnection for C and will drop A's Connection/CallControlConnection on getting CPIC at B, CAUSE_CODE provided will be CAUSE_NORMAL and the new API will provide REASON_REFER. CallInfo at B and C will be as follows: At B: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C At C: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C JTAPI Application observing B will see: getCallingParty() = A getCalledParty() = B getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A JTAPI Application observing C will see: getCallingParty() = B getCalledParty() = C getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A Scenario Five A(SIP UA outside cluster) is in a call with B. A(referrer) refers B(Referee) to C(Refer to target), C is ringing but C did not answer the call and has no forward configured. Refer fails, the original Call between A and B is restored. JTAPI will create Connection/CallControlConnection for A again and drops Connection/ CallControlConnection/TerminalConnection/CallControlTerminalConnection for C. CAUSE_CODE provided will be CAUSE_NORMAL and new API will provide REASON_REFER. CallInfo at A and B will be as follows At A: Cgpn = A, Cdpn = B, Lrp = OCdpn = B At B: Cgpn = A, Cdpn = B, Lrp = OCdpn = B JTAPI Application observing A will see: getCallingParty() = A getCalledParty() = B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1487 Message Sequence Charts Message Sequence Charts

Page 1551 content

Page 1552

getCurrentCallingParty() = A getCurrentCalledParty() = B getLastRedirecting() = NULL JTAPI Application observing C will see: getCallingParty() = A getCalledParty() = B getCurrentCallingParty() = A getCurrentCalledParty() = B getLastRedirecting() = NULL Scenario Six A(SIP UA in cluster/in control) is in a call with B. A(referrer) REFERs B(Referee) to C(Refer to target), C answers the call. JTAPI moves Connection/CallControlConnection/TerminalConnection/CallControlTerminalConnection for C to the Connected/Established/Active/Talking state. CAUSE_CODE provided is CAUSE_NORMAL and the new API will provide REASON_REFER. CallInfo at B and C will be as follows At B: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C At C: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C JTAPI Application observing B will see: getCallingParty() = A getCalledParty() = B getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A JTAPI Application observing C will see: getCallingParty() = B getCalledParty() = C getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A Scenario Seven A(SIP UA in cluster/in control) is in a call with B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1488 Message Sequence Charts Message Sequence Charts

Page 1552 content

Page 1553

A(referrer) REFERs B(Referee) to C(Refer to target), C forwardAll to D, D is ringing. JTAPI creates Connection/CallControlConnection/TerminalConnection/CallControlTerminalConnection for D. CAUSE_CODE provided will be CAUSE_REDIRECT and the reason received from CTI would be ForwardAll. CallInfo at B and D will be as follows At B: Cgpn = B, Cdpn = D, Lrp = C OCdpn = C At D: Cgpn = B, Cdpn = D, Lrp = C OCdpn = C JTAPI Application observing B will see: getCallingParty() = A getCalledParty() = B getCurrentCallingParty() = B getCurrentCalledParty() = D getLastRedirecting() = C JTAPI Application observing D will see: getCallingParty() = B getCalledParty() = D getCurrentCallingParty() = B getCurrentCalledParty() = D getLastRedirecting() = C Scenario Eight A (SIP UA in cluster/in control) is in a call with B. A(referrer) REFERs B(Referee) to C(Refer to target), C Redirect to D, D is ringing. JTAPI creates Connection/CallControlConnection/TerminalConnection/CallControlTerminalConnection for D. CAUSE_CODE provided will be CAUSE_REDIRECT and the reason received from CTI in NewCallEvent at D will be Redirect. Callinfo when Call is offered at C: At B: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C At C: Cgpn = B, Cdpn = C, Lrp = A OCdpn = C CallInfo in final Call: At B: Cgpn = B, Cdpn = D, Lrp = C OCdpn = C At D: Cgpn = B, Cdpn = D, Lrp = C OCdpn = C JTAPI Application observing B will see in final Call: getCallingParty() = A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1489 Message Sequence Charts Message Sequence Charts

Page 1553 content

Page 1554

getCalledParty() = B getCurrentCallingParty() = B getCurrentCalledParty() = D getLastRedirecting() = C JTAPI Application observing D will see: getCallingParty() = B getCalledParty() = D getCurrentCallingParty() = B getCurrentCalledParty() = D getLastRedirecting() = C Scenario Nine A(SIP UA in cluster/in control) is in a call with B. B consult transfer to D, A(Referrer) REFERs B(Referee) to C(Refer to target), C is ringing, Bcompletes the transfer. Attempt to transfer will fail while C is ringing. Scenario Ten A(SIP UA in cluster/in control) is in a call with B. B consult transfer to D, A(Referrer) REFERs B(Referee) to C(Refer to target), C answers the call. Refer will be successful. B completes the transfer, transfer will be successful, C and D will be in call. JTAPI Disconnect/Drops A’s Connect/CallControlConnection/TerminalConnection/ CallControlTerminalConnection. CAUSE_CODE provided will be CAUSE_NORMAL and the new API will provide REASON_REFER. For C, Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection will move to Connected/Established/Active/Talking state. CallInfo at D and C would be as follows At D: Cgpn = C, Cdpn = D, Lrp = B OCdpn = D At C: Cgpn = C, Cdpn = D, Lrp = B OCdpn = D JTAPI Application observing D will see: getCallingParty() = B getCalledParty() = D getCurrentCallingParty() = C getCurrentCalledParty() = D getLastRedirecting() = B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1490 Message Sequence Charts Message Sequence Charts

Page 1554 content

Page 1555

JTAPI Application observing C will see: getCallingParty() = B getCalledParty() = C getCurrentCallingParty() = C getCurrentCalledParty() = D getLastRedirecting() = B Scenario Eleven B is in a call with D, B consults to A(SIP UA in cluster/in control). A(Referrer) REFERs B(Referee) to C(Refer to target), C is ringing, B completes the transfer. REFER would fail. Call at A will be dropped, transfer is successful, D is getting RingBack, C is ringing. JTAPI Disconnect/Drops A’s Connect/CallControlConnection/TerminalConnection/ CallControlTerminalConnection. CAUSE_CODE provided will be CAUSE_NORMAL and the new API would provide REASON_REFER, Application will not know if REFER failed. For C, Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection will move to Alerting/Alerting/Ringing/Ringing state. CallInfo at D and C would be as follows: At D: Cgpn = D, Cdpn = C, Lrp = B OCdpn = C At C: Cgpn = D, Cdpn = C, Lrp = B OCdpn = C JTAPI Application observing D will see: getCallingParty() = B getCalledParty() = D getCurrentCallingParty() = D getCurrentCalledParty() = C getLastRedirecting() = B JTAPI Application observing C will see: getCallingParty() = B getCalledParty() = C getCurrentCallingParty() = D getCurrentCalledParty() = C getLastRedirecting() = B OutOfDialog Refer SIP-UA A REFERs B(Referee) to C (Refer To Target) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1491 Message Sequence Charts OutOfDialog Refer

Page 1555 content

Page 1556

B gets newcall with Cgpn = A, Cdpn = B, Lrp = , OCdpn = B. JTAPI Application will get CallActive, Connection, CallCtlConnection, TerminalConnecton and CallCtlTerminalConnection created for B with CAUSE_NORMAL, and the new API will return REASON_REFER. B’s Connection/CallCtlConnection, TerminalConnection/CallCtlTerminalConnection will go into the Connected/Established/Active/Talking state. JTAPI creates Connection and CallCtlConnection for A in “UNKNOWN” state based on FarEndPointType_ServerCall provided by CTI/CP. B answers the call and is connected to A (at this point no RTPEvent will be sent). B get CallPartyInfoChangedEv with Cgpn = B, Cdpn = C, Lrp = A, OCdpn = C, Reason = REFER. C get NewCall offering with Cgpn = B, Cdpn = C, Lrp = A, OCdpn = C, Reason = REFER. JTAPI Application will get Connection, CallControlConnection, TerminalConnecton and CallCtlTerminalConnection created for B with CAUSE_NORMAL, and the new API will return REASON_REFER. C Accepts/Answers the call, B is connected to C (now Application receives RTP events). C’s Connection/CallCtlConnection, TerminalConnection/CallCtlTerminalConnection will go into the Connected/Established/Active/Talking state. JTAPI Application observing B will see: getCallingParty() = A getCalledParty() = B getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A JTAPI Application observing C will see: getCallingParty() = B getCalledParty() = C getCurrentCallingParty() = B getCurrentCalledParty() = C getLastRedirecting() = A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1492 Message Sequence Charts Message Sequence Charts

Page 1556 content

Page 1557

SIP 3XX Redirection 3XX Redirection – 302 Moved Temporarily JTAPI application monitors 1000@ccm.cisco.com Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE. JTAPI reports CallActiveEv and Connection and CallCtlConnection events for 1000 JTAPI reports CallCtlConnEstablishedEv SIP proxy reports a 302 for 333555@aaa.com. Based on the 302, the Cisco Unified Communications Manager initiates a call to the first contact in the Target list based on the q value to 333777@bbb.com. CallPartyInfoChange event is reported to application based on the SIPAlertInd from a Cisco Unified Communications Manager, if the called party information is changed. JTAPI reports connection created events for 333777@bbb.com CTI reports CtiCallStateNotify (Ringback) and CtiCallStateNotify (Connected). JTAPI reports ConnAlertingEv and ConnEstablishedEv for far end. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1493 Message Sequence Charts SIP 3XX Redirection

Image 1 from page 1557

Page 1557 content

Page 1558

3XX Redirection – Contact Busy JTAPI CTI application monitors 1000@ccm.cisco.com Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE. JTAPI reports CallActiveEv and Connection and CallCtlConnection events for 1000 CTI reports CtiCallStateNotify (Proceeding) JTAPI reports CallCtlConnEstablishedEv SIP proxy reports a 302 for 333555@aaa.com. Based on the 302 the Cisco Unified Communications Manager initiates a call to the first contact in the Target list based on the q value to 333777@bbb.com. A 486 user busy response is reported by 333777@bbb.com. Based on this response the Cisco Unified Communications Manager initiates a call to 555888@cisco.com. CallPartyInfoChange event is reported to application based on the SIPAlertInd from the Cisco Unified Communications Manager if the called party information is changed. JTAPI reports connection created event for 555888@cisco.com. CTI also reports CtiCallStateNotify (Ringback) and CtiCallStateNotify (Connected). JTAPI reports CallCtlConnAlertingEv and CallCtlConnEstablishedEv for the new party Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1494 Message Sequence Charts Message Sequence Charts

Image 1 from page 1558

Page 1558 content

Page 1559

3XX Redirection – Contact Does Not Answer JTAPI application monitors 1000@ccm.cisco.com Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE. JTAPI reports CallActiveEv and connection and terminalConnection events for 1000 CTI reports CtiCallStateNotify (Proceeding) JTAPI reports CallCtlConnEstablishedEv for 1000 SIP proxy reports a 302 for 333555@aaa.com. Based on the 302 the Cisco Unified Communications Manager initiates a call to the first contact in the Target list based on the q value to 333777@bbb.com. The Cisco Unified Communications Manager starts the RNAR timer. CallPartyInfoChange event is reported to application based on the SIPAlertInd from the Cisco Unified Communications Manager if the called party information is changed. JTAPI reports connection created events for 333777 RNAR timer expires and based on this expiration the Cisco Unified Communications Manager initiates a call to 555888@cisco.com. CallPartyInfoChange event is reported to application based on the SIPAlertInd/CcNotifyReq from the Cisco Unified Communications Manager if the called party information is changed. JTAPI removes connection for 333777 and creates connection for 555888 CTI also reports CtiCallStateNotify (Connected). JTAPI reports CallCtlConnEstablishedEv for 555888 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1495 Message Sequence Charts Message Sequence Charts

Image 1 from page 1559

Page 1559 content

Page 1560

3XX Redirection – Contact Within Cisco Unified Communications Manager Cluster Configured with Call Forward JTAPI application monitors 1000@ccm.cisco.com Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE. JTAPI reports CallActiveEv and connection and terminalConnection events for 1000 CTI reports CtiCallStateNotify (Proceeding) JTAPI reports CallCtlConnEstablishedEv for 1000 SIP proxy reports a 302 for 333555@aaa.com. Based on the 302 the Cisco Unified Communications Manager initiates a call to the first contact in the Target list based on the q value to 2000@ccm.cisco.com. A 486 user busy response is reported by 2000@ccm.cisco.com. 2000 has Call Forward busy configured so the Cisco Unified Communications Manager initiates a call to 3000@ccm.cisco.com. The Cisco Unified Communications Manager also starts the RNAR timer. CallPartyInfoChange event is reported to application based on the SIPAlertInd from the Cisco Unified Communications Manager if the called party information is changed. JTAPI reports connection created event for 3000 3000 does not answer and RNAR timer expires and based on this expiration the Cisco Unified Communications Manager initiates a call to 555888@cisco.com. CallPartyInfoChange event is reported to application based on the SIPAlertInd/CcNotifyReq from the Cisco Unified Communications Manager if the called party information is changed. JTAPI destroys connection for 3000 and creates connection for 555888 CTI also reports CtiCallStateNotify (Connected). JTAPI reports CallCtlConnEstablishedEv for 555888 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1496 Message Sequence Charts Message Sequence Charts

Image 1 from page 1560

Page 1560 content

Page 1561

3XX Redirection – Non-Available Target Member JTAPI application monitors 1000@ccm.cisco.com Cisco Unified Communications Manager user1000 initiates a call to 333555@aaa.com CTI reports NewCallNotify and CtiCallStateNotify (Dialtone/Dialing) based on INVITE. JTAPI reports CallActiveEv and connection and terminalConnection events for 1000 CTI reports CtiCallStateNotify (Proceeding) JTAPI reports CallCtlConnEstablishedEv for 1000 SIP proxy reports a 302 for 333555@aaa.com. 302 contains target list of 1212@ccm.cisco.com and 2000@ccm.cisco.com. 1212@ccm.cisco.com is an invalid DN. The Cisco Unified Communications Manager tries to contact 1212@ccm.cisco.com first, but gets an invalid DN and so attempts to place the call to 2000@ccm.cisco.com. CallPartyInfoChange event is reported to application based on the SIPAlertInd from the Cisco Unified Communications Manager if the called party information is changed. JTAPI reports connection created event for 2000 CTI also reports CtiCallStateNotify (Ringback/Connected). JTAPI reports CallCtlConnAlertingEv and CallCtlConnEstablishedEv for 2000. SIP Support Events Scenario S.No Event delivered to call observer on A CallActiveEv ConnCreatedEv A Conn CreatedEv unknown getCurrentCallingPartyInfo().geUrlInfo().getUser() returns external. getCurrentCallingPartyInfo().geUrlInfo().getHost() returns someserver.com getCurrentCallingPartyInfo().geUrlInfo().getUrlType() returns SIP_URL_TYPE External SIP phone(external@someserver.com) calls A, A is monitored by application. Assuming external sip phone uses uri and not DN. 1 GCID3 CallActiveEv GCID3 ConnCreatedEv A GCID3 ConnFailedEv A GCID3 callInvalidEv 7970 runs SIP protocol with 2 max calls set. 3rd call comes in with GCID = GCID3 2 Exception is thrown to addobserver exception. TerminalRestrictedEv will be delivered if the status changed. 7960 running SIP is included in the control list. Applications add callobserver on the terminal 3 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1497 Message Sequence Charts SIP Support

Page 1561 diagram

Page 1562

SIP Trunk Early Offer Scenario One Early offer call on a IPV4 mode. CTIPort or RP supports this feature.Application opens provider and adds address, terminal and call observers. (Device = TermA address = A) Call information Result Action CiscoTermInServiceEv termACiscoAddrInServiceEv A Application registers the terminal dynamically using the new CiscoBaseMediaTerminal .register() API and passes DYNAMIC_MEDIA_REGISTRATION_FOR GET_PORT_SUPPORT for registration type and CiscoTerminal.IP _ADDRESSING_MODE_IPv4 for activeAddressingMode. getMediaIPAddressingMode() = IPv4 (((CiscoBaseMediaTerminal) (ev.getTerminal())). getRegistrationType = CiscoBaseMediaTerminal . passes DYNAMIC_MEDIA_REGISTRATION_FOR GET_PORT_SUPPORT GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEvTerm A GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 CiscoMediaOpenIPPortEv TermA Application invokes connect() API to connect to the other address B on terminal termB. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1498 Message Sequence Charts SIP Trunk Early Offer

Page 1562 diagram

Page 1563

Call information Result Action ev.isRTPRequired() = false GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1 CallCtlTermConnRingingEvImpl B GC1 CiscoMediaOpenLogicalChannelEv TermA GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv CiscoRTPOutputStarted Application sets the RTP parameters( IPv4 address and port) Application answers the call on B. Scenario Two Early offer call on a IPv4 mode. CTIPort or RP supports this feature. Application does not set RTP parameters in time(Fail Call Over SIP Trunk if MTP Allocation Fails = true). Application opens provider and adds Address, terminal and call observers.(Device = TermA address = A) Call information Result Action CiscoTermInServiceEv termACiscoAddrInServiceEv A Application registers the terminal dynamically using the new CiscoBaseMediaTermina.register() API and passes DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type and CiscoTerminal.IP _ADDRESSING_MODE_IPv4 for activeAddressingMode Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1499 Message Sequence Charts Message Sequence Charts

Page 1563 diagram

Page 1564

Call information Result Action getMediaIPAddressingMode() = IPv4 (((CiscoBaseMediaTerminal) (ev.getTerminal())). getRegistrationType = CiscoBaseMediaTerminal . passes DYNAMIC_MEDIA_REGISTRATION_FOR GET_PORT_SUPPORT GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEvTerm A GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 CiscoMediaOpenIPPortEv TermA Application invokes connect() API to connect to another address B on terminal termB ev.getCause() = CAUSE_RESOURCES_NOT_AVAILABLE GC1 TermConnDroppedEv TermA GC1 CallCtlTermConnDroppedEv TermA Gc1 ConnFailedEv A Gc1 CallCtlConnFailedEv A Gc1 CallInvalidEv PlatformException: Could not meet post condition of connect() Application does not sets the RTP parameters (IPv4 address and port). Scenario Three Early offer call on a IPv4 mode. CTIPort or RP supports this feature. Application does not setPort in time. (Fail Call Over SIP Trunk if MTP Allocation Fails = false) Application opens provider and adds address, terminal and call observers. (Device = TermA address = A ) Call information Result Action CiscoTermInServiceEv termACiscoAddrInServiceEv A Application registers the terminal dynamically using the new CiscoBaseMediaTermina.register() API and passes DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type and CiscoTerminal.IP _ADDRESSING_MODE_IPv4 for activeAddressingMode Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1500 Message Sequence Charts Message Sequence Charts

Page 1564 diagram

Page 1565

Call information Result Action getMediaIPAddressingMode() = IPv4 (((CiscoBaseMediaTerminal) (ev.getTerminal())). getRegistrationType = CiscoBaseMediaTerminal . passes DYNAMIC_MEDIA_REGISTRATION_FOR GET_PORT_SUPPORT GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEvTerm A GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 CiscoMediaOpenIPPortEv TermA Application invokes connect() API to connect to another address B on terminal termB. isRTPRequired() = true. GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1 CallCtlTermConnRingingEvImpl B GC1 CiscoMediaOpenLogicalChannelEv TermA GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv Application does not sets the RTP parameters. (IPv4 address and port) B answers the call. Application sets the RTP parameters. Scenario Four Early offer call on a dynamically registered IPv6 only CtiPort/RP with DYNAMIC_MEDIA_REGISTRATION_FOR GET_PORT_SUPPORT for registration type. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1501 Message Sequence Charts Message Sequence Charts

Page 1565 diagram

Page 1566

Call information Result Action CiscoTermInServiceEv termACiscoAddrInServiceEv A Application registers the terminal dynamically using the new CiscoBaseMediaTerminal .register() API and passes DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type and CiscoTerminal.IP _ADDRESSING_MODE_IPv6 for activeAddressingMode GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEvTerm A GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1 CallCtlTermConnRingingEvImpl B Application invokes connect() API to connect to another address B on terminal termB ev.isRTPRequired() = false GC1 CiscoMediaOpenLogicalChannelEv TermA GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv CiscoRTPInputStartedEv CiscoRTPOutputStarted App answers the call on B Application sets RTP parameters. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1502 Message Sequence Charts Message Sequence Charts

Page 1566 diagram

Page 1567

Scenario Five Early Offer call on a dynamically registered CtiPort or RP with DYNAMIC_MEDIA_REGISTRATION for registration type. Call information Result Action CiscoTermInServiceEv termACiscoAddrInServiceEv A Application registers the terminal dynamically using the new BaseMediaTerminal.register() API and DYNAMIC_MEDIA_REGISTRATION for registration type. GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEvTerm A GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1 CallCtlTermConnRingingEvImpl B. Application invokes connect() API to connect to another address B on terminal termB ev.isRTPRequired() = true GC1 CiscoMediaOpenLogicalChannelEv TermA GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv CiscoRTPInputStartedEv CiscoRTPOutputStarted App answers the call on B Application sets RTP parameters Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1503 Message Sequence Charts Message Sequence Charts

Page 1567 diagram

Page 1568

Scenario Six Two applications registering same CTIPort or RP with different values for registrationType.(dynamic). Call information Result Action CiscoTermInServiceEv termACiscoAddrInServiceEv A Application1 registers the terminal TermA dynamically using the new CiscoBaseMediaTerminal .register() API and DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type. CTIERR_MEDIA_ALREADY_ TERMINATED_DYNAMIC_ GETPORT_SUPPORT PlatformException: Application2 registers the terminal TermA dynamically usig the new CiscoBaseMediaTerminal .register() API and passes something other than DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type. CiscoTermInServiceEv termACiscoAddrInServiceEv A Application3 registers the terminal TermA dynamically usig the new CiscoBaseMediaTerminal .register() API and passes DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type. Scenario Seven Application sets RTP parameters again for an early offer call with dynamically registered terminal having DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type. Call information Result Action CiscoTermInServiceEv termACiscoAddrInServiceEv A Application registers the terminal dynamically using the new CiscoBaseMediaTerminal .register() API DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1504 Message Sequence Charts Message Sequence Charts

Page 1568 diagram

Page 1569

Call information Result Action getMediaIPAddressingMode() = IPv4 (((CiscoBaseMediaTerminal) (ev.getTerminal())). getRegistrationType = CiscoBaseMediaTerminal . passes DYNAMIC_MEDIA_REGISTRATION_FOR GET_PORT_SUPPORT GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEvTerm A GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 CiscoMediaOpenIPPortEv TermA Application invokes connect() API to connect to another address B on terminal termB. ev.isRTPRequired() = false. CTIERR_OPERATION_NOT_ AVAILABLE_IN_CURRENT_STATE. GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1 CallCtlTermConnRingingEvImpl B GC1 CiscoMediaOpenLogicalChannelEv TermA InvalidStateException GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv CiscoRTPOutputStarted Application sets the RTP parameters (IPv4 address and port). Application answers the call on B. Application sets the RTP parameters again. Scenario Eight Transfer involving a early offer call Application registers two terminals TermA and TermB dynamically with DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type and for both. A call is established between TermA and TermB. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1505 Message Sequence Charts Message Sequence Charts

Page 1569 diagram

Page 1570

Call information Result Action GC1 CallCtlTermConnHeldEv TermA A puts the call on hold getMediaIPAddressingMode() = IPv4 (((CiscoBaseMediaTerminal) (ev.getTerminal())). getRegistrationType = CiscoBaseMediaTerminal . passes DYNAMIC_MEDIA_REGISTRATION_FOR GET_PORT_SUPPORT GC2 CallActiveEv GC2 ConnCreatedEv A GC2 ConnConnectedEv A GC2 CallCtlConnInitiatedEv A GC2 TermConnCreatedEv TermA GC2 TermConnActiveEvTerm A GC2 CallCtlTermConnTalkingEv TermA GC2 CallCtlConnDialingEv A GC2 CallCtlConnEstablishedEv A GC2 CiscoMediaOpenIPPortEv TermA A initiates a call to C Ev.isRTPRequired() = false GC2 TermConnRingingEv C GC2 CallCtlTermConnRingingEvImpl C GC2 CiscoMediaOpenLogicalChannelEv TermA GC2 ConnConnectedEv C GC2 CallCtlConnEstablishedEv C GC2 TermConnActiveEv C GC2 CallCtlTermConnTalkingEv C CiscoRTPInputStartedEvs CiscoRTPOutputStartedEvs GC2 ConnCreatedEv C GC2 ConnInProgressEv C GC2 CallCtlConnOfferedEv C GC2 ConnAletingEv C GC2 CallCtlConnAlertingEv C GC2 TermConnCreatedEv Application sets the RTP parameters for TermA and opens the port( IPv4 address and port) App answers the call on C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1506 Message Sequence Charts Message Sequence Charts

Page 1570 diagram

Page 1571

Call information Result Action Ev.isRTPRequired() = true GC2 ConnDisconnectedEv C Gc2 CallCtlConnDisconnectedEv C GC2 ConnDisconnectedEv A GC2 CallCtlConDisconnectedEv A GC2 CallInvalidEv GC1 ConnCreatedEv C GC1 CiscoMediaOpenLogicalChannelEv TermB A tansfers the two calls GC1.transfer(GC2) GC1 ConnEstablishedEv C CiscoRTPInputStartedEv CiscoRTPOutputStartedEvs Application sets the RTP parameters for TermB Scenario Nine Hold Resume Scenario The application registers terminal TermA with DYNAMIC_MEDIA_REGISTRATION_FOR _GET_PORT_SUPPORT for registration type. A call is established between TermA and TermB. Call information Result Action Gc1 CallCtlTermConnHeldEv CiscoRTPInputStopped EvCiscoRTPOutoutStoppedEv TermA puts the call on hold. Ev.isRTPRequired() = true GC1 CiscoMediaOpenLogicalChannelEv TermA TermA resumes the call. CiscoRTPInputstartedEv CiscoRTPOutputStarted EvCallCtlTermConnTalkingEv Application sets the RTP parameters for TermA. Scenario Ten Call from a terminal registered with registration type as CiscoBaseMediaTerminal .STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1507 Message Sequence Charts Message Sequence Charts

Page 1571 diagram

Page 1572

Call information Result Action CiscoTermInServiceEvterm ACiscoAddrInServiceEv A Application registers the terminal statically using the new CiscoBaseMediaTerminal .register() API and passes STATIC_MEDIA_REGISTRATION_FOR GET_PORT_SUPPORT for registration type and CiscoTerminal.IP _ADDRESSING_MODE_IPv4 for activeAddressingMode getMediaIPAddressingMode() = IPv4 (((CiscoBaseMediaTerminal) (ev.getTerminal())). getRegistrationType = CiscoBaseMediaTerminal . passes STATIC_MEDIA_REGISTRATION_FOR GET_PORT_SUPPORT GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TermA GC1 TermConnActiveEvTerm A GC1 CallCtlTermConnTalkingEv TermA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 CiscoMediaOpenIPPortEv TermA Application invokes connect() API to connect to another address B on terminal termB. GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1 CallCtlTermConnRingingEvImpl B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv CiscoRTPOutputStarted Application sets the RTP parameters.(IPv4 address and port). Application answers the call on B. Scenario Eleven Two Applications registering same CTIPort or RP with different values for registrationType (static). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1508 Message Sequence Charts Message Sequence Charts

Page 1572 diagram

Page 1573

Call information Result Action CiscoTermInServiceEv termACiscoAddrInServiceEv A Application1 registers the terminal TermA statically using the new register() API and STATIC_MEDIA_REGISTRATION _FOR_GET_PORT_SUPPORT for registration type CTIERR_MEDIA_ALREADY_ TERMINATED_STATIC_ GETPORT_SUPPORT PlatformException Application2 registers the terminal TermA statically usig the new register() API and passes something other than STATIC_MEDIA_REGISTRATION _FOR_GET_PORT_SUPPORT for registration type CiscoTermInServiceEv termACiscoAddrInServiceEv A Application3 registers the terminal TermA statically usig the new register() API and passes STATIC_MEDIA_REGISTRATION _FOR_GET_PORT_SUPPORT for registration type SRTP Key Material If this feature is enabled, it is expected to degrade the performance of Cisco Unified JTAPI. Performance degradation is because of encrypted signaling between CTI and JTAPI and also because of encrypted media between end points. Scenario One Event Action CiscoRTPInputKeyEv CiscoRTPInputStartedEv CiscoRTPOutputKeyEv CiscoRTPOutputStartedEv App adds CallObserver on an Address 1 and initiates a call to address2 and involves in secure media conversation. If user is authorized, then CiscoRTPInputKeyEv and CiscoRTPOutputKeyEv contain key material. Scenario Two Event Action CiscoTermSnapshotEv using which applications can query getCiscoMediaCallSecurity () to find out if a call is secured or not. Application adds TerminalObserver by enabling snapshotEnabled filter. Device is already in a secure call and queries invokes CiscoTerminal.createSnapshot () Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1509 Message Sequence Charts SRTP Key Material

Page 1573 diagram

Page 1574

Scenario Three Response Action PrivilegeViolationException is thrown to the application Application does not have a TLS link and tries to register with secure media.CiscoMediaTerminal.register (ipAddr, portNum, mediaCaps, algorithm) Request is successful Application has a secure media and registers CiscoMediaTerminal.register (ipAddr, portNum, mediaCaps, algorithm) Super Provider Message Flow The application tries to create Terminal for CTIPort1 that has Addresses 2000 and 2001. The following events get sent to the application. Event Action No. JTAPI would return CiscoTerminal object and the following events get sent: CiscoTermCreatedEv CTIPort1<--------------- CiscoAddrCreated 2000<------------------------ CiscoAddrCreated 2001<------------------------- Application invokes CiscoProvider. CreateTerminal(CTIPort1) whereCiscoProviderCapabilities. canObserveAnyTerminal() returns TRUE. 1 JTAPI would return CiscoTerminal object and the following events get sent CiscoTermCreatedEv CTIPort1<---------------- CiscoAddrCreated 2000<------------------------ CiscoAddrAddedToTerminalEv 2001<-------- If the application already has a terminal where the 2001 address already exists, that is, 2001 is a SharedLine Address. Now, the application invokes CiscoProvider.CreateTerminal(CTIPort1) 2 JTAPI would throw an exception: InvalidArgumentException Application invokes CiscoProvider.CreateTerminal(CTIPortX)where CTIPortX does not exist in Cisco Unified Communications Manager cluster. 3 JTAPI would throw an exception: PrivilegeViolationException Application invokes CiscoProvider.CreateTerminal(CTIPort1) whereCiscoProviderCapabilities. canObserveAnyTerminal() returns FALSE. 4 SuperProvider and Change Notification Enhancements Use Cases New events have been added to JTAPI, which will be sent to applications in order to handle new failover scenario and change notification. This enhances JTAPI to handle failover scenarios and the time required to shift between Superprovider and normal user modes. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1510 Message Sequence Charts Super Provider Message Flow

Page 1574 diagram

Page 1575

Scenario One Superprovider user opens provider and opens a few devices in Superprovider mode which are not in control list. From admin pages, Superprovider privilege is removed. Application receives CiscoProviderCapabilityChangedEvent event. JTAPI sends CiscoTermRemovedEv all the devices which are opened / acquired and are not in the control list. JTAPI will send provider OOS to application, CiscoTermRemovedEv to devices not in control list and will reopen connection to CTI. When connect succeeds, JTAPI will send provider in service event to the application. Else, it will close the provider. Scenario Two Normal user opens provider and opens a few devices in control list. From admin pages, Superprovider privilege is added to the user. Application receives CiscoProviderCapabilityChangedEvent event. User will now be able to acquire/open devices not in its control list. Scenario Three Normal user opens provider and opens a few park DNs. From admin pages, park DN monitor privilege is removed for the user. Application receives CiscoProviderCapabilityChangedEvent event. JTAPI will cleanup all park DN addresses. Scenario Four Normal user opens provider. From admin pages, park DN monitor privilege is added for the user. Application receives CiscoProviderCapabilityChangedEvent event. Application registers the park DN monitoring feature and is able to monitor park DN. Scenario Five Normal user opens provider. From admin pages, “modify calling party” privilege is removed for the user. Application receives CiscoProviderCapabilityChangedEvent event. Application is not able to change the calling party number during redirect. JTAPI will throw error if application tries to do this. Scenario Six Normal user opens provider. From admin pages, “modify calling party” privilege is added for the user. Application receives CiscoProviderCapabilityChangedEvent event. Application is able to change the calling party number in a call during redirect. Scenario Seven Superprovider user opens provider and acquires a device not in control list. From admin pages, the device is deleted. Application receives CiscoTermRemovedEv event. Device is closed from JTAPI perspective. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1511 Message Sequence Charts Message Sequence Charts

Page 1575 content

Page 1576

Support for Cisco Unified IP Phone 6901 Scenario 1 Phone A is a Cisco Unified IP Phone 6901 and phone B is a normal SCCP/SIP phone. Application is observing the devices A and B. Phone A is off-hook and application initiates a call through createCall() API from phone A to phone B. Configuration: • Phone A – Cisco Unified IP Phone 6901 • Phone B – SCCP/SIP Device Call info Result Action Application observes A and B. CiscoAddrInServiceEv – A CiscoAddrInServiceEv - B Application observes A and B. GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A] GC1: TermConnDroppedEv [Term A] CallCtlTermConnDroppedEv [Term A] ConnDisconnectedEv A CallCtlConnDisconnectedEv A CallInvalidEv A goes off-hook Application calls createCall() and call connect() API to Call B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1512 Message Sequence Charts Support for Cisco Unified IP Phone 6901

Page 1576 diagram

Page 1577

Call info Result Action GC2: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A] CallCtlConnDialingEv A CallCtlConnEstablishedEv A ConnCreatedEv – B

ConnAlertingEv B CallCtlConnAlertingEv B TermConnCreatedEv [Term B] TermConnRingingEv [Term B] CallCtlTermConnRingingEvImpl [Term B] currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC2: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call and A & B are connected. Scenario 2 Phone A is a normal SCCP/SIP phone and phone B is Cisco Unified IP Phone 6901. Application is observing both the devices A & B. User initiates a call from phone A to phone B. Phone B goes off-hook and answers the incoming call. Configuration: • Phone A – SCCP/SIP Device • Phone B – Cisco Unified IP Phone 6901 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1513 Message Sequence Charts Message Sequence Charts

Page 1577 diagram

Page 1578

Call info Result Action currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC2: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call and A & B are connected. Scenario 3 Phone A is Cisco Unified IP Phone 6901 and phone B is a normal SCCP/SIP phone. Application is observing both the devices A and B. Phone A is on-hook and application initiates a call from phone A to phone B. Configuration: • Phone A – Cisco Unified IP Phone 6901 • Phone B – SCCP/SIP Device Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv - B Application observes A and B. Operation not available in current state. Jtapi throws Exception: InvalidStateException A is on-hook and application call createcall() and connect API to call B Scenario 4 Application is observing both the devices A and B. Phone A is a normal SCCP/SIP phone and phone B is Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B is on-hook and application tries to answer the call on B. Configuration: • Phone A – SCCP/SIP Device • Phone B – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv - B Application observes A and B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1514 Message Sequence Charts Message Sequence Charts

Page 1578 diagram

Page 1579

Call info Result Action GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A]

A intitiates a call to B from application. Operation not available in current state. Jtapi throws Exception: InvalidStateException B is on-hook and tries to answer the call from the application. Scenario 5 Application is observing both the devices A and B. Phone A is a normal SCCP/SIP phone and phone B is Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B parks the call from application. Configuration: • Phone A – SCCP/SIP Device • Phone B – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv - B Application observes A and B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1515 Message Sequence Charts Message Sequence Charts

Page 1579 diagram

Page 1580

A intitiates a call to B from the application. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call and A & B are connected. currentCalling = A currentCalled = Park DN CAUSE = CAUSE_NORMAL GC1: TermConnDroppedEv [Term B] CallCtlTermConnDroppedEv [Term B] ConnDisconnectedEv B CallCtlConnDisconnectedEv B ConnCreatedEv ParkDN ConnInProgressEv ParkDN CallCtlConnQueuedEv ParkDN B parks the call from the application. Scenario 6 Call Park Reversion Timer is set to 30 seconds at service parameter page. Application is observing both the devices A and B. Phone A is a normal SCCP/SIP phone and phone B is Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B parks the call. B goes on-hook. Configuration: • Phone A – SCCP/SIP Device • Phone B – Cisco Unified IP Phone 6901 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1516 Message Sequence Charts Message Sequence Charts

Page 1580 diagram

Page 1581

Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv - B Application observes A and B. GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A]

Page 1581 diagram

Page 1582

Call info Result Action Operation not available in current state. GC1: ConnCreatedEv B ConnInProgressEv B CallCtlConnOfferedEv B ConnAlertingEv B CallCtlConnAlertingEv B TermConnCreatedEv [Term B] TermConnRingingEv [Term B] CallCtlTermConnRingingEvImpl [Term B] Jtapi throwsEception: InvalidStateException. B goes on-hook. Call Park reversion Timer expires after 30 seconds and the call comes back to B. B tries to answer the call from the application. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B goes off-hook and answers the call. Scenario 7 Application is observing the devices A, B and C. Phone A is a normal SCCP/SIP phone, B and C are Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B parks the call from application. C is off-hook and unparks the call from the application. Configuration: • Phone A – SCCP/SIP Device • Phones B and C – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv – B CiscoAddrInServiceEv - C Application observes A, B and C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1518 Message Sequence Charts Message Sequence Charts

Page 1582 diagram

Page 1583

Call info Result Action currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A]

A intitiates a call from the application. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call and A & B are connected. currentCalling = A currentCalled = Park DN CAUSE = CAUSE_NORMAL GC1: TermConnDroppedEv [Term B] CallCtlTermConnDroppedEv [Term B] ConnDisconnectedEv B CallCtlConnDisconnectedEv B ConnCreatedEv ParkDN ConnInProgressEv ParkDN CallCtlConnQueuedEv ParkDN B parks the call from the application. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1519 Message Sequence Charts Message Sequence Charts

Page 1583 diagram

Page 1584

Call info Result Action GC2: CallActiveEv ConnCreatedEv –C ConnConnectedEv – C CallCtlConnInitiatedEv - C

ConnCreatedEv ParkDN ConnInProgressEv ParkDN CallCtlConnOfferedEv ParkDN C unparks the call from the application. GC1: ConnDisconnectedEv ParkDN CallCtlConnDisconnectedEv ParkDN GC1: ConnCreatedEv –C ConnConnectedEv – C CallCtlConnEstablishedEv – C TermConnCreatedEv [Term C] TermConnActiveEv [Term C] CallCtlTermConnTalkingEv [Term C] ConnCreatedEv ParkDN ConnInProgressEv ParkDN CallCtlConnOfferedEv ParkDN GC2: ConnDisconnectedEv ParkDN CallCtlConnDisconnectedEv ParkDN TermConnDroppedEv [Term C] CallCtlTermConnDroppedEv [Term C] ConnDisconnectedEv C GC2 CiscoCallChangedEv CallCtlConnDisconnectedEv C CallInvalidEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1520 Message Sequence Charts Message Sequence Charts

Page 1584 diagram

Page 1585

Scenario 8 Application is observing the devices A, B and C. Phone A is a normal SCCP/SIP phone, B and C are Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B parks the call from application. C is on-hook and unparks the call from the application. Configuration: • Phone A – SCCP/SIP Device • Phones B and C – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv – B CiscoAddrInServiceEv - C Application observes A, B and C. currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A]

A intitiates a call from the application. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call and A & B are connected. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1521 Message Sequence Charts Message Sequence Charts

Page 1585 diagram

Page 1586

Call info Result Action currentCalling = A currentCalled = Park DN CAUSE = CAUSE_NORMAL GC1: TermConnDroppedEv [Term B] CallCtlTermConnDroppedEv [Term B] ConnDisconnectedEv B CallCtlConnDisconnectedEv B ConnCreatedEv ParkDN ConnInProgressEv ParkDN CallCtlConnQueuedEv ParkDN B parks the call from the application. Operation not available in current state. Jtapi throws Exception: InvalidStateException C unparks the call from the application. Scenario 9 Application is observing the devices A, B and C. Phone A is a normal SCCP/SIP phone, B and C are Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B transfers the call to C from the application. Configuration: • Phone A – SCCP/SIP Device • Phones B and C – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv – B CiscoAddrInServiceEv - C Application observes A, B and C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1522 Message Sequence Charts Message Sequence Charts

Page 1586 diagram

Page 1587

A initiates a call from the application. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call and A and B are connected. currentCalling = B currentCalled = C CAUSE = CAUSE_NORMAL GC1: CallCtlTermConnHeldEv B GC2: CallActiveEv ConnCreatedEv –B ConnConnectedEv – B CallCtlConnInitiatedEv - BTermConnCreatedEv - [Term B] TermConnActiveEv –[Term B] CallCtlTermConnTalkingEv –[Term B]

B makes consult call to C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1523 Message Sequence Charts Message Sequence Charts

Page 1587 diagram

Page 1588

Call info Result Action currentCalling = B currentCalled = C CAUSE = CAUSE_NORMAL GC2: ConnConnectedEv C CallCtlConnEstablishedEv C TermConnActiveEv [Term C] CallCtlTermConnTalkingEv [Term C] C goes off-hook and answers the call. B and C are connected. GC1: CiscoTermConnSelectChangedEv [Term B] GC2: CiscoTermConnSelectChangedEv [Term B] GC1 CiscoTransferStartEv GC2 CiscoCallChangedEv B completes transfer by invoking GC1.transfer(GC2) GC1: ConnCreatedEv - C ConnConnectedEv – C CallCtlConnEstablishedEv - C TermConnCreatedEv - [Term C] TermConnActiveEv –[Term C] CallCtlTermConnTalkingEv –[Term C] GC2: TermConnDroppedEv [Term C] CallCtlTermConnDroppedEv [Term C] ConnDisconnectedEv C CallCtlConnDisconnectedEv C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1524 Message Sequence Charts Message Sequence Charts

Page 1588 diagram

Page 1589

Call info Result Action GC1: TermConnDroppedEv [Term B] CallCtlTermConnDroppedEv [Term B] ConnDisconnectedEv B CallCtlConnDisconnectedEv B GC2: TermConnDroppedEv [Term B] CallCtlTermConnDroppedEv [Term B] ConnDisconnectedEv B CallCtlConnDisconnectedEv B CallInvalidEv CiscoTransferEndEv Scenario 10 Application is observing the devices A, B and C. Phone A is a normal SCCP/SIP phone, B and C are Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B does a conference with C from the application. Configuration: • Phone A – SCCP/SIP Device • Phones B and C – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv – B CiscoAddrInServiceEv – C Application observes A, B and C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1525 Message Sequence Charts Message Sequence Charts

Page 1589 diagram

Page 1590

ConnConnectedEv C CallCtlConnEstablishedEv C TermConnActiveEv [Term C] CallCtlTermConnTalkingEv [Term C] B makes consult call to C. C goes off-hook and answers the call. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1526 Message Sequence Charts Message Sequence Charts

Page 1590 diagram

Page 1591

Call info Result Action GC1: CiscoTermConnSelectChangedEv [Term B] GC2: CiscoTermConnSelectChangedEv [Term B] GC1 CiscoConferenceStartEv GC2 CiscoCallChangedEv B conferences two calls by invoking GC1.conference(GC2) GC1: ConnCreatedEv - C ConnConnectedEv – C CallCtlConnEstablishedEv - C TermConnCreatedEv - [Term C] TermConnActiveEv –[Term C] CallCtlTermConnTalkingEv –[Term C] GC2: TermConnDroppedEv [Term B] CallCtlTermConnDroppedEv [Term B] ConnDisconnectedEv B CallCtlConnDisconnectedEv B CallInvalidEv GC1 CiscoConferenceEndedEv Scenario 11 Application is observing the devices A, B and C. Phone A is a normal SCCP/SIP phone, B and C are Cisco Unified IP Phone 6901 models. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B redirects the call to C from the application. Configuration: • Phone A – SCCP/SIP Device • Phones B and C – Aleta Device Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv – B CiscoAddrInServiceEv - C Application observes A, B and C. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1527 Message Sequence Charts Message Sequence Charts

Page 1591 diagram

Page 1592

A intitiates a call from the application. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call and A & B are connected. GC1: ConnCreatedEv C ConnInProgressEv C CallCtlConnOfferedEv C TermConnDroppedEv [Term B] CallCtlTermConnDroppedEv [Term B] ConnDisconnectedEv B B redirects the call to C from the application. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1528 Message Sequence Charts Message Sequence Charts

Page 1592 diagram

Page 1593

Call info Result Action currentCalling = A currentCalled = C CAUSE = CAUSE_NORMAL CallCtlConnDisconnectedEv B ConnAlertingEv C CallCtlConnAlertingEv C TermConnCreatedEv [Term C] TermConnRingingEv [Term C] CallCtlTermConnRingingEvImpl [Term C] ConnConnectedEv C CallCtlConnEstablishedEv C TermConnActiveEv [Term C] CallCtlTermConnTalkingEv [Term C] C is off-hook and answers the call from application. Scenario 12 Application is observing both the devices A and B. Phone A is a normal SCCP/SIP phone and phone B is Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B puts the call on hold by pressing the corresponding button from the phone. B resumes the call by pressing Line key from the phone. Configuration: • Phone A – SCCP/SIP Device • Phone B – Aleta Phone Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv - B Application observes A and B. currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A]

A initiates a call from the application. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1529 Message Sequence Charts Message Sequence Charts

Page 1593 diagram

Page 1594

Call info Result Action currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call, and A and B are connected. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: CallCtlTermConnHeldEv B B presses Hold button from the phone and puts the call on hold. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: CallCtlTermConnTalkingEv B B presses Line button from the phone and resumes the call. Scenario 13 Application is observing both the devices A and B. Phone A is a normal SCCP/SIP phone and phone B is Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B puts the call on hold by pressing the button and goes on-hook. Now B tries to resume the call from application. Configuration: • Phone A – SCCP/SIP Device • Phone B – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv - B Application observes A and B. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1530 Message Sequence Charts Message Sequence Charts

Page 1594 diagram

Page 1595

A initiates a call to B from the application. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call and A & B are connected. GC1: CallCtlTermConnHeldEv B B presses hold hardkey from the phone and puts the call on hold. Operation not available in current state. Exception: InvalidStateException. B goes on-hook. B tries to resume the call from the application. Scenario 14 Application is observing devices A and B. Phone A is a normal SCCP/SIP phone and phone B is Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B puts the call on hold by pressing hard key and goes on-hook. Now B tries to resume the call by pressing the line hard key from phone. Configuration: • Phone A – SCCP/SIP Device • Phone B – Cisco Unified IP Phone 6901 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1531 Message Sequence Charts Message Sequence Charts

Page 1595 diagram

Page 1596

Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv - B Application observes A and B. currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A]

A intitiates a call to B from the application. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv B CallCtlConnEstablishedEv B TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B answers the call and A & B are connected. GC1: CallCtlTermConnHeldEv B B presses hold hardkey from the phone and puts the call on hold. Operation not available in current state. GC1: CallCtlConnTalkingEv [Term B] TermConnDroppedEv [Term B] CallCtlTermConnDroppedEv [Term B] ConnDisconnectedEv B CallCtlConnDisconnectedEv B TermConnDroppedEv [Term A] CallCtlTermConnDroppedEv [Term A] ConnDisconnectedEv A CallCtlConnDisconnectedEv A CallInvalidEv B goes on-hook. B tries to resume the call by pressing the line key from phone. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1532 Message Sequence Charts Message Sequence Charts

Page 1596 diagram

Page 1597

Scenario 15 Application is observing the devices A, B and C. Phone A is a normal SCCP/SIP phone, B and C are Cisco Unified IP Phone 6901. CFA is set to C at phone B. Application initiates a call from phone A to phone B. Due to CFA set to C, call goes to C. C goes off-hook and answers the call. Configuration: • Phone A – SCCP/SIP Device • Phone B and C – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv – B CiscoAddrInServiceEv - C Application observes A, B and C. CAUSE = CAUSE_NORMAL REASON = FORWARDALL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A]

A intitiates a call to B from the application. B has CFA set to C. Call goes to C. currentCalling = A currentCalled = B CAUSE = CAUSE_NORMAL GC1: ConnConnectedEv C CallCtlConnEstablishedEv C TermConnActiveEv [Term C] CallCtlTermConnTalkingEv [Term C] C goes off-hook and answers the call. A & C are connected. Scenario 16 Application is observing the devices A and B. Phone C is not observed. Phone A is a normal SCCP/SIP phone, B and C are Cisco Unified IP Phone 6901. Application initiates a call from phone A to phone B. B goes off-hook and answers the call. B redirects the call to C. C goes off-hook and answers the call. Configuration: • Phone A – SCCP/SIP Device Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1533 Message Sequence Charts Message Sequence Charts

Page 1597 diagram

Page 1598

• Phone B and C – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv – B Application observes A and B. Phone C is not observed. currentCalling = A currentCalled = null CAUSE = CAUSE_NORMAL GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A]

Page 1598 diagram

Page 1599

Scenario 17 Application is observing the devices A, B and C. Phone A is a normal SCCP/SIP phone, B is Cisco Unified IP Phone 6901 and phone C is a normal SCCP/SIP phone. B and C have a shared line. Application initiates a call from phone A to shared line on B and C. B goes off-hook and answers the call. Configuration: • Phone A and C – SCCP/SIP Device • Phone B – Cisco Unified IP Phone 6901 Call info Result Action CiscoAddrInServiceEv – A CiscoAddrInServiceEv – B CiscoAddrInServiceEv - C Application observes A, B and C. GC1: CallActiveEv ConnCreatedEv –A ConnConnectedEv – A CallCtlConnInitiatedEv - ATermConnCreatedEv - [Term A] TermConnActiveEv –[Term A] CallCtlTermConnTalkingEv –[Term A]

A initiates a call to the shared line on B and C ConnConnectedEv B CallCtlConnEstablishedEv B TermConnCreatedEv [Term C] TermConnPassiveEv [Term C] CallCtlTermConnInUseEv [Term C] TermConnActiveEv [Term B] CallCtlTermConnTalkingEv [Term B] B goes off-hook and answers the call. SHA Support for Digital Signatures The following tables display the CallInfo messages for the following three use cases: • SHA-1 is the configured encryption algorithm Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1535 Message Sequence Charts SHA Support for Digital Signatures

Page 1599 diagram

Page 1600

• SHA-512 is the configured encryption algorithm (Cisco JTAPI is version 11.5) • SHA-512 is the configured encryption algorithm (Cisco JTAPI is a pre-11.5 version) Table 353: SHA-1 is Configured CallInfo Action JTAPIProperties.getSecurityPropertyForInstance(). certificateStatus=true TFTP File Signature Algorithm enterprise parameteris set to SHA1 (the default value). JTAPIProperties.setSecurityPropertyForInstance() is invoked with CAPF login and instance ID. Table 354: SHA-512 is Configured (Cisco JTAPI is version 11.5) CallInfo Action JTAPIProperties.getSecurityPropertyForInstance(). certificateStatus=true TFTP File Signature Algorithm enterprise parameter is set to SHA 512. JTAPIProperties.setSecurityPropertyForInstance() is invoked with username and instance ID. Table 355: SHA-512 is Configured (Cisco JTAPI is pre-11.5 version) CallInfo Action JTAPIProperties.getSecurityPropertyForInstance(). certificateStatus=false TFTP File Signature Algorithm enterprise parameter is set to SHA 512. JTAPIProperties.setSecurityPropertyForInstance() is invoked with username and instance ID. TLS Security Message flow for updating certificate and establishing TLS certificate is illustrated in the following two figures. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1536 Message Sequence Charts TLS Security

Page 1600 diagram

Page 1601

Figure 22: CTI/API Security Approach Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1537 Message Sequence Charts Message Sequence Charts

Image 1 from page 1601

Page 1601 content

Page 1602

Figure 23: CTI/API Security Approach (Continued) Transfer and Direct Transfer The following diagrams illustrate the message flows for Transfer and Direct Transfer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1538 Message Sequence Charts Transfer and Direct Transfer

Image 1 from page 1602

Page 1602 content

Page 1603

DirectTransfer/Arbitrary Transfer Scenario Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1539 Message Sequence Charts DirectTransfer/Arbitrary Transfer Scenario

Image 1 from page 1603

Page 1603 content

Page 1604

Direct Transfer/Arbitrary Transfer-Page 2 Consult Transfer The message flow for Consult Transfer acts the same as the flow for Arbitrary Transfer. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1540 Message Sequence Charts Direct Transfer/Arbitrary Transfer-Page 2

Image 1 from page 1604

Page 1604 content

Page 1605

Unicode Support Unicode Display Name Scenario Events Delivered to JTAPI Applications Scenario Call info should contain: getCurrentCalledPartyDisplayName = asciiNameB getCurrentCalledPartyUnicodeDisplayName = null getCurrentCallingPartyDisplayName = null getCurrentCallingPartyUnicodeDisplayName = japaneseNameA A line is configured on IP phone A with no ASCII name and a Unicode name in Japanese. IP phone B is configured with ASCII name and no Unicode name. A calls B. Only B is observed. DisplayName does not apply. Applications should consider “conference” as the called party. A, B and C are in conference. Calling party Unicode display name can change between A and B. Shared lines – A and B are shared lines with different locales. A calls C. C is unobserved. GetLocale and UniCodeCapabilities of Terminal Events delivered to JTAPI applications Scenario CiscoTerminalInServiceEv contains getLocale = JAPANESE getSupportedEncoding = UCS2UNICODE_ENCODING CiscoTerminal.getLocale = JAPANESE CiscoTerminal. getSupportedEncoding = UCS2UNICODE_ENCODING A line is configured on IP phone A with no ASCII name and Unicode name in Japanese. Application adds TerminalObserver on the Device. Application queries the following using CiscoTerminal. Unrestricted Unified CM Use Case One The application tries to register with an insecure CTI Port to the unrestricted Cisco Unified Communications Manager. Call information Result Action [Term A] CiscoTermOutOfService[A] CiscoAddrOutOfServiceEv[Term A] CiscoTermInServiceEv[A] CiscoAddrInServiceEv Application opens a provider with the unrestricted Cisco Unified Communications Manager and tries to register with an insecure phone CTI Port 'A'. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1541 Message Sequence Charts Unicode Support

Page 1605 diagram

Page 1606

Variance Application tries to register with an insecure route point to the unrestricted Cisco Unified Communications Manager. Use Case Two Restricted Cisco Unified Communications Manager is upgraded to unrestricted Cisco Unified Communications Manager. The application tries to register with a secure phone after the upgrade. In some of the scenarios, where the application registers a device in a secure mode, the registeration is successful but eventually can be rejected with a new error code - CiscoTermRegisterationFailedEv. Variance Application tries to register a secure Route Point after an upgrade from a restricted Cisco Unified Communications Manager to unrestricted Cisco Unified Communications Manager. Video Capabilities and Multi-Media Information The following sections describe use cases that are related to video capabilities and multi-media information feature. Scenario One Phone A is video capable, telepresence capable, with 1 screen and a camera, and in registered state. User1 has phone A in the control list. User queries for multimedia capabilities before adding a terminal observer. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer termA. getCiscoMulti MediaCapabilityInfo() .getVideoCa pability() = CiscoMultiMedia CapabilityInfo.ENABLED User1 invokes CiscoTerminal.i getCiscoMulti MediaCapabilityInfo() .getVid eoCapability() on termA termA. getCiscoMulti MediaCapabilityInfo() .getTelepres enceInfo () = CiscoMultiMedia CapabilityInfo.TELEPRESENC EINTEROP_ENABLED User1 invokes CiscoTerminal.i getCiscoMulti MediaCapabilityInfo() .getTel epresenceInfo () on termA termA. getCiscoMulti MediaCapabilityInfo() .getScreenC ount () = 1 User1 invokes CiscoTerminal.i getCiscoMulti MediaCapabilityInfo() .getScr eenCount () on termA Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1542 Message Sequence Charts Video Capabilities and Multi-Media Information

Page 1606 diagram

Page 1607

Scenario Two Phone A is a video disabled SIP Phone (In Cisco Unified CM Administration Phone page, Video Capabilities field is “Disabled”). Phone A is in a registered state. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer termA.getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = CiscoMultiMediaCapabilityInfo. DISABLED User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMultiMediaCapabilityInfo(). getVideoCa pability() = CiscoMultiMediaCapabilityInfo. ENABLED CiscoProvTerminalMulti MediaCapabilityChangedEv In Device Configuration Cisco Unified CM Administration pages- Video Capabilities field is changed to “Enabled” termA. getCiscoMultiMediaCapabilityInfo(). getVideoCa pability() = CiscoMultiMediaCapabilityInfo. ENABLED User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMultiMediaCapabilityInfo(). getVideoCa pability() = CiscoMultiMediaCapabilityInfo. DISABLED CiscoProvTerminalMulti MediaCapabilityChangedEv In Device Configuration Cisco Unified CM Administration pages- Video Capabilities field is changed to “Disabled” Scenario Three Phone A is a video disabled SCCP Phone (In Cisco Unified CM Administration Phone page, Video Capabilities field is “Disabled”). Phone A is in a registered state. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = CiscoMultiMediaCapabilityInfo. DISABLED User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1543 Message Sequence Charts Scenario Two

Page 1607 diagram

Page 1608

Call Info Events Action termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = CiscoMultiMediaCapabilityInfo. ENABLED CiscoProvTerminalMulti MediaCapabilityChangedEv In Device Configuration Cisco Unified CM Administration pages- Video Capabilities field is changed to “Enabled” termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = CiscoMultiMediaCapabilityInfo. ENABLED User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() = CiscoMultiMediaCapabilityInfo. DISABLED CiscoProvTerminalMulti MediaCapabilityChangedEv will not be delivered to applications, as the device will unregister and register back. In this case applications can query video capability after the device is registered. In Device Configuration Cisco Unified CM Administration pages- Video Capabilities field is changed to “Disabled” Scenario Four Phone A is video capable, telepresence capable, has 1 screen, has a camera, and is in an unregistered state. User1 has phone A in the control list. User queries for multimedia capabilities before adding a terminal observer. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer InvalidStateException: Terminal is not in registered state. User1 invokes CiscoTerminal. getCiscoMultiMedia CapabilityInfo().getVideoCapability() on termA InvalidStateException: Terminal is not in registered state. User1 invokes CiscoTerminal. getCiscoMultiMedia CapabilityInfo().getTelepresenceInfo() on termA InvalidStateException: Terminal is not in registered state. User1 invokes CiscoTerminal. getCiscoMultiMedia CapabilityInfo().getScreenCount() on termA Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1544 Message Sequence Charts Scenario Four

Page 1608 diagram

Page 1609

Scenario Five Phone A is video capable, telepresence capable, with 1 screen and a camera. User1 has phone A in the control list. Application queries for mutlimedia capabilities on CiscoTerminal. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer termA. getCiscoMulti MediaCapabilityInfo().getVideoCapability() = NONE CiscoTermOutOfServiceEv CiscoTermInServiceEv User1 opens termA termA. getCiscoMulti MediaCapabilityInfo(). getVideoCapability() = CiscoMultiMediaCapabilityInfo.ENABLED User1 invokes CiscoTerminal. getCiscoMulti MediaCapabilityInfo(). getVideoCapability() on termA termA. getCiscoMulti MediaCapabilityInfo(). getTelepresenceInfo() = CiscoMultiMediaCapabilityInfo.TELEPRE SENCEINTEROP_ENABLED User1 invokes CiscoTerminal. i getCiscoMulti MediaCapabilityInfo(). getTelepresenceInfo() on termA termA. getCiscoMulti MediaCapabilityInfo(). getScreenCount () = 1 User1 invokes CiscoTerminal. i getCiscoMulti MediaCapabilityInfo(). getScreenCount() on termA Scenario Six Phone A is a CTI Port or RoutePoint. User1 has phone A in the control list. The user invokes CiscoTerminal.getCiscoMultiMediaCapabilityInfo().getVideoCapability(). Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscoTermOutOfServiceEv CiscoTermInServiceEv User1 opens termA and registers it The API returns MethodNotSupportedException - Not supported on Media Terminals and RPs and Remote Terminals User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA The API returns MethodNotSupportedException - Not supported on Media Terminals and RPs and Remote Terminals User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo() on termA Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1545 Message Sequence Charts Scenario Five

Page 1609 diagram

Page 1610

Call Info Events Action The API returns MethodNotSupportedException - Not supported on Media Terminals and RPs and Remote Terminals User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getScreenCount() on termA Scenario Seven Phone A is a CTI Port or RoutePoint. User1 has phone A in the control list. The user invokes CiscoTerminal.getCiscoMultiMediaCapabilityInfo().getVideoCapability(). Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscoTermOutOfServiceEv CiscoTermInServiceEv User1 opens termA and registers it The API returns MethodNotSupportedException - Not supported on Media Terminals and RPs and Remote Terminals User1 invokes CiscoTerminal. getCiscoMultiMediaCapabilityInfo(). getVideoCapability() on termA The API returns MethodNotSupportedException - Not supported on Media Terminals and RPs and Remote Terminals User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getTelepresenceInfo() on termA The API returns MethodNotSupportedException - Not supported on Media Terminals and RPs and Remote Terminals User1 invokes CiscoTerminal. i getCiscoMultiMediaCapabilityInfo(). getScreenCount() on termA Scenario Eight Basic Video call: Phone A is video enabled, Telepresence Enabled and has 1 screen. Phone B has video disabled, Telepresence Disabled and has 0 screens. Both phones are in User1's control list. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscoTermInServiceEv TermA CiscoTermInServiceEv TermB User1 adds terminal observers on Phone A and Phone B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1546 Message Sequence Charts Scenario Seven

Page 1610 diagram

Page 1611

Call Info Events Action CiscoAddrInServiceEv A CiscoAddrInServiceEv B User1 adds call observes on the address A and B GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEvImpl B User1 makes a call from A to B The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo() .getVideoCapability() on GC1. The API returns 1, indicating telepresence capable device(CiscoMultiMedia CapabilityInfo. TELEPRESENCEINTEROP_ENABLED) for TermA App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo() .getTelepresenceInfo() on GC1. The API returns 1, indicating device has 1 screen, for TermA App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo.getScreenCount() on GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1547 Message Sequence Charts Message Sequence Charts

Page 1611 diagram

Page 1612

Call Info Events Action The API returns 0, indicating video capable device (CiscoMultiMedia CapabilityInfo.DISABLED) for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo().getCallingTerminal VideoCapability() on GC1. The API returns 0, indicating telepresence capable device (CiscoMultiMedia CapabilityInfo. TELEPRESENCEINTEROP_DISABLED) for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo().getTelepresenceInfo() on GC1. The API returns 0, indicating device has 01 screen, for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo.getScreenCount() on GC1. GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo() .getVideoCapability() on GC1. The API returns 1, indicating telepresence capable device (CiscoMultiMedia CapabilityInfo. TELEPRESENCEINTEROP_ENABLED) for TermA App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo() .getTelepresenceInfo() on GC1. The API returns 1, indicating device has 1 screen, for TermA App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo.getScreenCount() on GC1. The API returns 0, indicating not video capable device (CiscoMultiMedia CapabilityInfo.DISABLED) for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo().getCallingTerminal VideoCapability() on GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1548 Message Sequence Charts Message Sequence Charts

Page 1612 diagram

Page 1613

Call Info Events Action The API returns 0, indicating device is not telepresence capable (TELEPRESENCEINTEROP_DISABLED) for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo().getTelepresenceInfo() on GC1. The API returns 0, indicating device has 0 screens, for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo.getScreenCount() on GC1. Scenario Nine Shared Line: Phone A has video enabled, Phone B has video disabled and Phone B' has video enabled. B' is in User1's control list. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscotermInServiceEv TermB' User1 adds terminal observers on Phone B' CiscoAddrInServiceEv B' User1 adds call observes on the address B' Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1549 Message Sequence Charts Scenario Nine

Page 1613 diagram

Page 1614

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B The API returns 1, indicating video capable device (CiscoMultiMediaCapabilityInfo. ENABLED) for TermA App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo().getVideoCapability() on GC1. The API returns 1, indicating video capable device (CiscoMultiMediaCapabilityInfo. DISABLED) for TermB App does CiscoCall. getCalledTerminal MultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1550 Message Sequence Charts Message Sequence Charts

Page 1614 diagram

Page 1615

Call Info Events Action The API returns 1, indicating video capable device (CiscoMultiMediaCapabilityInfo. ENABLED) for TermA App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo().getVideoCapability() on GC1. Application will receive the following incorrect data: The API returns 1, indicating not video capable device(CiscoMultiMediaCapabilityInfo. ENABLED) for Term B. App does CiscoCall. getCalledTerminal MultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. Scenario Ten Shared Line: Phone A has video enabled, Phone B has video disabled and Phone B' has video enabled. B and B' is in User1's control list. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscotermInServiceEv TermB CiscotermInServiceEv TermB' User1 adds terminal observers on Phone B and Phone B' CiscoAddrInServiceEv B CiscoAddrInServiceEv B' User1 adds call observes on the address B and B' Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1551 Message Sequence Charts Scenario Ten

Page 1615 diagram

Page 1616

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B The API returns 1, indicating video capable device (CiscoMultiMediaCapabilityInfo. ENABLED) for TermA App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo. ).getVideoCapability() on GC1. The API returns 1, indicating video capable device (CiscoMultiMediaCapabilityInfo. DISABLED) for TermB' App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo. .getCallingTerminalVideoCapability() on GC1. GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1552 Message Sequence Charts Message Sequence Charts

Page 1616 diagram

Page 1617

Call Info Events Action The API returns 1, indicating video capable device (CiscoMultiMediaCapabilityInfo. ENABLED) for TermA App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo. ).getVideoCapability() on GC1. Application will receive the following incorrect data: The API returns 1, indicating not video capable device(CiscoMultiMediaCapabilityInfo. ENABLED) for Term B. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo. ).getCallingTerminalVideoCapability() on GC1. Scenario Eleven Basic Video call: Phone A is video enabled, Telepresence enabled and has 1 screen. Phone B has video disabled, Telepresence disabled and has 0 screens. Phone A is in User1's control list, Phone A is observed. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscotermInServiceEv TermA CiscotermInServiceEv TermB User1 adds terminal observers on Phone A and Phone B CiscoAddrInServiceEv A CiscoAddrInServiceEv B User1 adds call observes on the address A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1553 Message Sequence Charts Scenario Eleven

Page 1617 diagram

Page 1618

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B The API returns -1, indicating video capability is not known ( UKNOWN) for TermA App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getVideoCapability() on GC1. The API returns -1, indicating telepresence capability is not known (UKNOWN) for TermA App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getTelepresenceInfo() on GC1. The API returns -1, indicating screen count capability is not known TermA App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo.getScreenCount() on GC1. The API returns -1, indicating video capability is not known (UKNOWN) for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1554 Message Sequence Charts Message Sequence Charts

Page 1618 diagram

Page 1619

Call Info Events Action The API returns -1, indicating telepresence capability is not known (UKNOWN) for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getTelepresenceInfo() on GC1. The API returns -1, indicating screen count capability is not known TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo.getScreenCount() on GC1. GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call The API returns 1, indicating video capable device (CiscoMultiMediaCapabilityInfo. ENABLED) for TermA App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getVideoCapability() on GC1. The API returns 1, indicating telepresenc capable device (CiscoMultiMedia CapabilityInfo. TELEPRESENCEINTEROP_ENABLED) for TermA App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getTelepresenceInfo() on GC1. The API returns 1, indicating device has 1 screen, for TermA App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo.getScreenCount() on GC1. The API returns 0, indicating video capable device (CiscoMultiMedia CapabilityInfo.DISABLED) for Term B. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1555 Message Sequence Charts Message Sequence Charts

Page 1619 diagram

Page 1620

Call Info Events Action The API returns 0, indicating device is not telepresence capable (TELEPRESENCEINTEROP_ DISABLED) for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getTelepresenceInfo() on GC1. The API returns 0, indicating device has 0 screens, for TermB App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo.getScreenCount() on GC1. Scenario Twelve MultiMedia Streams: Phone A and B have video enabled, and both phones are in User1's control list. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds observer CiscotermInServiceEv TermA CiscotermInServiceEv TermB User1 adds terminal observers on Phone A and Phone B CiscoAddrInServiceEv A CiscoAddrInServiceEv B User1 adds callObserves on the address A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1556 Message Sequence Charts Scenario Twelve

Page 1620 diagram

Page 1621

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call The API returns port number from which media will be directed. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getReceptionAddress() on Terminal A The API returns port number from which media will be directed. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getReceptionPort() on Terminal A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1557 Message Sequence Charts Message Sequence Charts

Page 1621 diagram

Page 1622

Call Info Events Action The API returns port number from which media will be directed. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getTransmissionAddress() on Terminal A The API returns the payload format. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getTransmissionPort() on Terminal A The API returns the maximum bit rate. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getPayloadType() on Terminal A The API returns 0(TRANSMIT_AND_RECEIVE) CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getMaxBitRate() on Terminal A The API returns 2(MAIN_VIDEO) CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaConnectionMode() on Terminal A CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaType() on Terminal A The API returns False CiscoMultiMediaStreamsInfoEv. getProperties(). isKeyInfoPresent() on Terminal A The API returns NULL. CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaEncryptionKeyInfo() on Terminal A The API returns 3(MEDIA_ENCRYPTED_KEYS _UNAVAILABLE) CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaSecurityIndicator() on Terminal A The API returns IP address to which media will be directed. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getReceptionAddress() on Terminal B The API returns port number to which media will be directed. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getReceptionPort() on Terminal B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1558 Message Sequence Charts Message Sequence Charts

Page 1622 diagram

Page 1623

Call Info Events Action The API returns IP address from which media will be directed. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getTransmissionAddress() on Terminal B The API returns port number from which media will be directed. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getTransmissionPort() on Terminal B The API returns the payload format. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getPayloadType() on Terminal B The API returns the maximum bit rate. CiscoMultiMediaStreamsInfoEv. getProperties(). getRTPProperties(). getMaxBitRate() on Terminal B The API returns 0(TRANSMIT_AND_RECEIVE) CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaConnectionMode() on Terminal B The API returns 2(MAIN_VIDEO) CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaType() on Terminal B The API returns False CiscoMultiMediaStreamsInfoEv. getProperties(). isKeyInfoPresent() on Terminal B The API returns NULL. CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaEncryptionKeyInfo() on Terminal B The API returns 3(MEDIA_ENCRYPTED_KEYS _UNAVAILABLE) CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaSecurityIndicator() on Terminal B B holds the call. The API returns 3(INACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaConnectionMode() on Terminal A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1559 Message Sequence Charts Message Sequence Charts

Page 1623 diagram

Page 1624

Call Info Events Action The API returns 3(INACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaConnectionMode() on Terminal B B unholds the call. The API returns 0(TRANSMIT_AND_RECEIVE) CiscoMultiMediaStreamsInfoEv. getCallingTerminalVideoCapability() on GC1. The API returns 0(TRANSMIT_AND_RECEIVE) CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaConnectionMode() on Terminal B Scenario Thirteen Redirect: Phone A, B, and C have video enabled, and A, B phones are in User1's control list, and Phone C is in User2's control list. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds observer CiscotermInServiceEv TermA CiscotermInServiceEv TermB CiscotermInServiceEv TermC User1 adds terminal observers on Phone A and Phone B User2 adds terminal observers on Phone C. CiscoAddrInServiceEv A CiscoAddrInServiceEv B CiscoAddrInServiceEv C User1 adds callObserves on the address A and B User2 adds callObserves on the address C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1560 Message Sequence Charts Scenario Thirteen

Page 1624 diagram

Page 1625

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call The API returns 0(TRANSMIT_AND_RECEIVE) CiscoMultiMediaStreamsInfoEv. getProperties() .getMultiMediaConnectionMode() on Terminal A The API returns 2(MAIN_VIDEO) CiscoMultiMediaStreamsInfoEv. getProperties().getMultiMediaType() on Terminal A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1561 Message Sequence Charts Message Sequence Charts

Page 1625 diagram

Page 1626

Call Info Events Action The API returns False CiscoMultiMediaStreamsInfoEv. getProperties().isKeyInfoPresent() on Terminal A The API returns 0(TRANSMIT_AND_RECEIVE) CiscoMultiMediaStreamsInfoEv. getProperties() .getMultiMediaConnectionMode() on Terminal B The API returns 2(MAIN_VIDEO) CiscoMultiMediaStreamsInfoEv. getProperties().getMultiMediaType() on Terminal B The API returns False CiscoMultiMediaStreamsInfoEv. getProperties().isKeyInfoPresent() on Terminal B The API returns NULL. CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaEncryptionKeyInfo() on Terminal B The API returns 2(MAIN_VIDEO) 3(MEDIA_ENCRYPTED _KEYS_UNAVAILABLE) CiscoMultiMediaStreamsInfoEv. getProperties(). getMultiMediaSecurityIndicator() on Terminal B B redirects the call to C. C answers The API returns 3(INACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties() .getMultiMediaConnectionMode() on Terminal B The API returns 0(ACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties() .getMultiMediaConnectionMode() on Terminal C The API returns 0(ACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties() .getMultiMediaConnectionMode() on Terminal A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1562 Message Sequence Charts Message Sequence Charts

Page 1626 diagram

Page 1627

Call Info Events Action The API returns 1, indicating video capability is enabled (CiscoMultiMediaCapabilityInfo.ENABLED) for TermA (far-end party). App does CiscoCall. getCallingTerminal VideoCapability() on GC1. The API returns 1, indicating video capability is enabled (CiscoMultiMedia CapabilityInfo.ENABLED) for TermC (far-end party). App does CiscoCall. getCalledTerminalMult iMediaCapabilityInfo() on GC2. The API returns 1, indicating video capability is enabled (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA (far-end party). App does CiscoCall. getCallingTerminal VideoCapability() on GC1. The API returns 1, indicating video capability is enabled (CiscoMultiMedia CapabilityInfo.ENABLED) for TermC (far-end party). CiscoMultiMediaStreamsInfoEv. getCalledTerminalMult iMediaCapabilityInfo on GC2. Scenario Fourteen Transfer: Phone A, B and C have video enabled, and A, B phones are in User1's control list and C is in User2's control list, A, B and C are in cluster1. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds observer CiscotermInServiceEv TermA CiscotermInServiceEv TermB CiscotermInServiceEv TermC User1 adds terminal observers on Phone A and Phone B User2 adds terminal observers on Phone C. CiscoAddrInServiceEv A CiscoAddrInServiceEv B CiscoAddrInServiceEv C User1 adds callObserves on the address A and B User2 adds callObserves on the address C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1563 Message Sequence Charts Scenario Fourteen

Page 1627 diagram

Page 1628

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call The API returns 0 (TRANSMIT_AND_RECEIVE) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaConnectionMode () on Terminal A The API returns 2 (MAIN_VIDEO) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaType () on Terminal A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1564 Message Sequence Charts Message Sequence Charts

Page 1628 diagram

Page 1629

Call Info Events Action The API returns False CiscoMultiMediaStreamsInfoEv. getProperties ().isKeyInfoPresent () on Terminal A The API returns 0 (TRANSMIT_AND_RECEIVE) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaConnectionMode () on Terminal B The API returns 2 (MAIN_VIDEO) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaType () on Terminal B The API returns False CiscoMultiMediaStreamsInfoEv. getProperties ().isKeyInfoPresent () on Terminal B The API returns NULL. CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaEncryptionKeyInfo () on Terminal B The API returns 3 (MEDIA_ENCRYPTED_ KEYS_UNAVAILABLE) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaSecurityIndicator () on Terminal B B does a consult call to C. C answers The API returns 0 (ACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaType () on Terminal B The API returns 0 (ACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaConnectionMode () on Terminal C The API returns 1, indicating video capability is known (CiscoMultiMedia CapabilityInfo.ENABLED ) for TermC ( far-end party). App does CiscoCall. getCalledTerminalMultiMediaCapabilityInfo () on GC2. The API returns 1, indicating video capability is known (CiscoMultiMedia CapabilityInfo.ENABLED ) for TermB ( far-end party). App does CiscoCall. getCallingTerminalMultiMediaCapabilityInfo on GC2. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1565 Message Sequence Charts Message Sequence Charts

Page 1629 diagram

Page 1630

Call Info Events Action B does GC1.transfer (GC2). C answers The API returns 3 (INACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaConnectionMode () on Terminal B The API returns 0 (ACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaConnectionMode () on Terminal C The API returns 0 (ACTIVE) CiscoMultiMediaStreamsInfoEv. getProperties ().getMultiMediaConnectionMode () on Terminal A The API returns 1, indicating video capability is known (CiscoMultiMedia CapabilityInfo.ENABLED ) for TermC ( far-end party). App does CiscoCall. getCalledTerminal MultiMediaCapabilityInfoon GC2. The API returns 1, indicating video capability is known (CiscoMultiMedia CapabilityInfo.ENABLED ) for TermA ( far-end party). App does CiscoCall. getCallingTerminalMultiMediaCapabilityInfo () on GC2. The API returns 1, indicating video capability is known (CiscoMultiMedia CapabilityInfo.ENABLED ) for TermC ( far-end party). App does CiscoCall. getCalledTerminalMultiMediaCapabilityInfo ().getCallingTerminalVideoCapability () onGC1. The API returns 1, indicating video capability is known (CiscoMultiMedia CapabilityInfo.ENABLED ) for TermA ( far-end party). App does CiscoCall. getCallingTerminalMultiMediaCapabilityInfo () on GC1. Scenario Fifteen Negotiated video capability will be reported to the called party across a cluster call (over SIP – ICT trunk) using early offer (Phone A is a video disabled SIP Phone in cluster 1 and Phone B is a video enabled SIP Phone in cluster 2). User1 has Phone A in the control list, Phone A is observed. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1566 Message Sequence Charts Scenario Fifteen

Page 1630 diagram

Page 1631

Call Info Events Action CiscotermInServiceEv TermA CiscotermInServiceEv TermB User1 adds terminal observers on Phone A and Phone B CiscoAddrInServiceEv A CiscoAddrInServiceEv B User1 adds callObserves on the address A and B GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call The API returns 0, indicating not a video capable device (CiscoMultiMedia CapabilityInfo.DISABLED) for TermA. App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getVideoCapability() on GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1567 Message Sequence Charts Message Sequence Charts

Page 1631 diagram

Page 1632

Call Info Events Action The API returns 0, indicating not a video capable device (CiscoMultiMedia CapabilityInfo.DISABLED) for TermB. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. The API returns 1, indicating video capable device(CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. Variation 1: A and B are SIP Phone and have video enabled. User1 makes a call from A to B. B answers the call. App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getVideoCapability() on GC1. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1 Scenario Sixteen Multiple redirects over SIP trunk (A, B, C and D are video enabled SIP Phones, A is in cluster 1 and B, C, D are in cluster 2). Phone A, B, C and D are in User1’s control list, Phone A, B, C and D are observed. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscotermInServiceEv TermA CiscotermInServiceEv TermB CiscotermInServiceEv TermC CiscotermInServiceEv TermD User1 adds terminal observers on Phone A B, C, and D CiscoAddrInServiceEv A CiscoAddrInServiceEv B CiscoAddrInServiceEv C CiscoAddrInServiceEv D User1 adds callObserves on the address A, B, C, and D Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1568 Message Sequence Charts Scenario Sixteen

Page 1632 diagram

Page 1633

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getVideoCapability() on GC1. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermB. App does CiscoCall. getCalledTermina lMultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1569 Message Sequence Charts Message Sequence Charts

Page 1633 diagram

Page 1634

Call Info Events Action B redirects the call to C. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermC. App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getVideoCapability() on GC1. App does CiscoCall. getCalledTermina lMultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermC. C redirects the call to D. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. The API returns 1, indicating video capable device(CiscoMultiMedia CapabilityInfo.ENABLED) for TermD. App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getVideoCapability() on GC1. App does CiscoCall. getCalledTermina lMultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. Scenario Seventeen Redirect over SIP trunk (Phone A is video enabled SIP Phone, and Phone B and C have video disabled. Phone A is in cluster 1 and Phone B and C are in cluster 2). Phone A and B are in User1’s control list and Phone C is in User2’s control list, Phone A, B and C are observed. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscotermInServiceEv TermA CiscotermInServiceEv TermB User1 adds terminal observers on Phone A and Phone B CiscoAddrInServiceEv A CiscoAddrInServiceEv B User1 adds call Observes on the address A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1570 Message Sequence Charts Scenario Seventeen

Page 1634 diagram

Page 1635

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call The API returns 0, indicating not a video capable device (CiscoMultiMedia CapabilityInfo.DISABLED) for TermA. App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo(). getVideoCapability() on GC1. The API returns 0, indicating not a video capable device (CiscoMultiMedia CapabilityInfo. DISABLED) for TermC. App does CiscoCall. getCalledTerminal MultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1571 Message Sequence Charts Message Sequence Charts

Page 1635 diagram

Page 1636

Call Info Events Action The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo. ENABLED) for TermA. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo. ENABLED) for TermC. Variation 1: A and B have video enabled, C has video disabled App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo(). getVideoCapability() on GC1. App does CiscoCall. getCalledTerminal MultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. Scenario Eighteen Shared Line – Hold and Resume scenario over SIP trunk (Phone A and C are video enabled SIP Phones and Phone B is video disabled, Phone A is in cluster 1 and Phone B and C are in cluster 2. Phone B and C are shared lines). Phone A and B are in User1’s control list, Phone A and B are observed. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscotermInServiceEv TermA CiscotermInServiceEv TermB User1 adds terminal observers on Phone A and Phone B CiscoAddrInServiceEv A CiscoAddrInServiceEv B User1 adds call Observes on the address A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1572 Message Sequence Charts Scenario Eighteen

Page 1636 diagram

Page 1637

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call B redirects the call to C. C answers The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermC. App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo() .getVideoCapability() on GC1. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo() .getCallingTerminal VideoCapability() on GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1573 Message Sequence Charts Message Sequence Charts

Page 1637 diagram

Page 1638

Call Info Events Action The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. The API returns 0, indicating not a video capable device (CiscoMultiMedia CapabilityInfo.DISABLED) for TermC. Variation 1: A and B have video enabled, C has video disabled App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo() .getVideoCapability() on GC1. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo() .getCallingTerminal VideoCapability() on GC1. Scenario Nineteen Multiple redirects over H323 ICT trunk (A, B, C and D are video enabled SIP Phones, A is in cluster 1 and B, C, D are in cluster 2). Phone A, B, C and D are in User1’s control list, Phone A, B, C and D are observed. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscotermInServiceEv TermA CiscotermInServiceEv TermB CiscotermInServiceEv TermC CiscotermInServiceEv TermD User1 adds terminal observers on Phone A B, C, and D CiscoAddrInServiceEv A CiscoAddrInServiceEv B CiscoAddrInServiceEv C CiscoAddrInServiceEv D User1 adds call Observes on the address A B, C, and D Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1574 Message Sequence Charts Scenario Nineteen

Page 1638 diagram

Page 1639

Page 1639 diagram

Page 1640

Page 1640 diagram

Page 1641

Page 1641 diagram

Page 1642

Call Info Events Action The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermD. The API returns -1, indicating telepresence is UNKNOWN for TermA. The API returns -1, indicating telepresence is UNKNOWN for TermC. The API returns -1, indicating screen count is UNKNOWN for TermA. The API returns -1, indicating screen count is UNKNOWN for TermC. App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getVideoCapability() on GC1. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo(). getTelepresenceInfo() on GC1. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo(). getTelepresenceInfo() on GC1. App does CiscoCall. getCallingTerminalMulti MediaCapabilityInfo.getScreenCount() on GC1. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo.getScreenCount() on GC1. Scenario Twenty Redirect over H323 trunk (Phone A is video enabled SIP Phone and Phone B and C have video disabled, Phone A is in cluster 1 and Phone B and C are in cluster 2). Phone A and B are in User1’s control list and Phone C is in user2’s control list, Phone A, B and C are observed. Call Info Events Action ProvInServiceEv User1 Opens Provider and adds a provider observer CiscotermInServiceEv TermA CiscotermInServiceEv TermB User1 adds terminal observers on Phone A and Phone B CiscoAddrInServiceEv A CiscoAddrInServiceEv B User1 adds call Observes on the address A and B Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1578 Message Sequence Charts Scenario Twenty

Page 1642 diagram

Page 1643

Call Info Events Action GC1: CallActiveEv GC1: ConnCreatedEv A GC1:ConnConnectedEv A GC1:CallCtlConnInitiatedEv A GC1:TermConnCreatedEv TermA GC1:TermConnActiveEv TermA GC1:CallCtlTermConnTalkingEv TermA GC1:CallCtlConnDialingEv A GC1CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 ConnInProgressEv B GC1 CallCtlConnOfferedEv B GC1 ConnAletingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv B GC1 TermConnRingingEv B GC1CallCtlTermConnRingingEv Impl B User1 makes a call from A to B GC1 ConnConnectedEv B GC1 CallCtlConnEstablishedEv B GC1 TermConnActiveEv B GC1 CallCtlTermConnTalkingEv B CiscoRTPInputStartedEv TermA CiscoRTPInputStartedEv TermB CiscoRTPOutputStartedEv TermA CiscoRTPOutputStartedEv TermB B answers the call B redirects the call to C. C answers The API returns 1, indicating not a video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo(). getVideoCapability() on GC1. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1579 Message Sequence Charts Message Sequence Charts

Page 1643 diagram

Page 1644

Call Info Events Action The API returns 0, indicating not a video capable device (CiscoMultiMedia CapabilityInfo.DISABLED) for TermC. App does CiscoCall. getCalledTerminal MultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermC. Variation 1: A and B have video enabled, C has video disabled App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo(). getVideoCapability() on GC1. App does CiscoCall. getCalledTerminal MultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. C redirects the call to D. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1580 Message Sequence Charts Message Sequence Charts

Page 1644 diagram

Page 1645

Call Info Events Action The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermA. The API returns 1, indicating video capable device (CiscoMultiMedia CapabilityInfo.ENABLED) for TermD. The API returns -1, indicating telepresence is UNKNOWN for TermA. The API returns -1, indicating telepresence is UNKNOWN for TermC. The API returns -1, indicating screen count is UNKNOWN for TermA. The API returns -1, indicating screen count is UNKNOWN for TermC. App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo(). getVideoCapability() on GC1. App does CiscoCall. getCalledTerminal MultiMediaCapabilityInfo(). getCallingTerminalVideoCapability() on GC1. App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo(). getTelepresenceInfo() on GC1. App does CiscoCall. getCalledTerminal MultiMediaCapabilityInfo(). getTelepresenceInfo() on GC1. App does CiscoCall. getCallingTerminal MultiMediaCapabilityInfo.getScreenCount() on GC1. App does CiscoCall. getCalledTerminalMulti MediaCapabilityInfo. getScreenCount() on GC1. Video On Hold Pre-conditions to all video on hold use cases, unless specified otherwise: • Provider is in IN_SERVICE state • All addresses and terminals are already in service. • Device A (IP Phone – Name: “SEP2401C7824EA3”, Line A1 (dn: 9000)) • Device B (IP Phone – Name: “SEP2401C7824EAE”, Line B1 (dn: 9001)) • The content id corresponding to VoH stream is contentID1. • User1 has in its control list: Devices A and B. All devices and lines are observed. Scenario One Invoke hold() on basic call between two ip phones to stream video to the held party Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1581 Message Sequence Charts Video On Hold

Page 1645 diagram

Page 1646

Call information / Notes Events Action ProvInServiceEv User1 opens Provider and adds a provider observer. GC1: CallActiveEv GC1: ConnCreatedEv 9000 GC1: ConnConnectedEv 9000 GC1: CallCtlConnInitiatedEv 9000 GC1: TermConnCreatedEv SEP2401C7824EA3 GC1: TermConnActiveEv SEP2401C7824EA3 GC1: CallCtlTermConnTalkingEv SEP2401C7824EA3 GC1: CallCtlConnDialingEv 9000 GC1: CallCtlConnEstablishedEv 9000 GC1: ConnCreatedEv 9001 GC1: ConnInProgressEv 9001 GC1: CallCtlConnOfferedEv 9001 GC1: ConnAlertingEv 9001 GC1: CallCtlConnAlertingEv 9001 GC1: TermConnCreatedEv SEP2401C7824EAE GC1: TermConnRingingEv SEP2401C7824EAE GC1: CallCtlTermConnRingingEv SEP2401C7824EAE User1 invokes Call.connect("SEP2401C7824EA3", "9000", "9001"). GC1: ConnConnectedEv 9001 GC1: CallCtlConnEstablishedEv 9001 GC1: TermConnActiveEv SEP2401C7824EAE GC1: CallCtlTermConnTalkingEv SEP2401C7824EAE Device B answers the call. GC1: CallCtlTermConnHeldEv SEP2401C7824EA3 Note You are able to see video streamed to the device that is placed on hold. User1 invokes hold("contentID1") on terminal connection of Device A. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1582 Message Sequence Charts Message Sequence Charts

Page 1646 diagram

Page 1647

Call information / Notes Events Action GC1: TermConnDroppedEv SEP2401C7824EA3 GC1: CallCtlTermConnDroppedEv SEP2401C7824EA3 GC1: ConnDisconnectedEv 9000 GC1: CallCtlConnDisconnectedEv 9000 GC1: TermConnDroppedEv SEP2401C7824EAE GC1: CallCtlTermConnDroppedEv SEP2401C7824EAE GC1: ConnDisconnectedEv 9001 GC1: CallCtlConnDisconnectedEv 9001 GC1: CallInvalidEv GC1: CallObservationEndedEv A disconnects the call. Verification Involving PSTN Reachability Scenario 1 A calls B in other cluster ( Normal Call ); application is observing A Call info Result Action GC1: CallActiveEv ConnCreatedEv -A ConnConnectedEv - A CallCtlConnDialingEv - A TermConnCreatedEv - TA TermConnActiveEv -TA CallCtlTermConnTalkingEv - TA ConnCreatedEv B ConnConnectedEv B CallCtlConnNetworkReachedEv CallCtlConnNetworkAlertingEv A dials B, B rings. Scenario 2 A calls B in other cluster (VIPR Call - Call gets routed through IP trunk); application is observing A Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1583 Message Sequence Charts Verification Involving PSTN Reachability

Page 1647 diagram

Page 1648

Call info Result Action GC1: CallActiveEv ConnCreatedEv -A ConnConnectedEv - A CallCtlConnDialingEv - A TermConnCreatedEv - TA TermConnActiveEv -TA CallCtlTermConnTalkingEv - TA ConnCreatedEv B ConnConnectedEv B CallCtlConnNetworkReachedEv CallCtlConnNetworkAlertingEv A dials B, B rings Scenario 3 A calls B, within same cluster. B redirects the call to external party C, the redirected call goes through IP Trunk due to VIPR feature; application is observing both A and B. Call info Result Action GC1: CallActiveEv ConnCreatedEv A ConnConnectedEv A CallCtlConnInitiatedEv A TermConnCreatedEv TA TermConnActiveEv TA CallCtlTermConnTalkingEv TA CallCtlConnEstablishedEv A ConnCreatedEv B CallCtlConnOfferedEv B ConnAlertingEv B CallCtlConnAlertingEv B TermConnCreatedEv TB TermConnRingingEv TB CallCtlTermConnRingingEv TB A calls B withis same cluster Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1584 Message Sequence Charts Message Sequence Charts

Page 1648 diagram

Page 1649

Call info Result Action CiscoFeatureReason = CiscoFeatureReason.REASON_REDIRCT CallCtlCause = CallCtlEv.CAUSE_REDIRECTED CiscoFeatureReason.REASON_REDIRECT GC1: TermConnDroppedEv TB CallCtlTermConnDroppedEv TB ConnDisconnectedEv B CallCtlConnDisconnectedEv B ConnCreatedEv C ConnConnectedEv C CallCtlConnNetworkReachedEv CallCtlConnNetworkAlertingEv B redirects the call to external party C Scenario 4 A calls external party B; call goes through IP trunk but later call quality degrades and VIPR PSTN Fallback happens; application is observing A. Call info Result Action GC1: CallActiveEv ConnCreatedEv -A ConnConnectedEv - A CallCtlConnDialingEv - A TermConnCreatedEv - TA TermConnActiveEv -TA CallCtlTermConnTalkingEv - TA ConnCreatedEv B ConnConnectedEv B CallCtlConnNetworkReachedEv CallCtlConnNetworkAlertingEv A dials B(VIPR Call), B rings TA: CiscoRTPInputStartedEv CiscoRTPOutputStartedEv B answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1585 Message Sequence Charts Message Sequence Charts

Page 1649 diagram

Page 1650

Call info Result Action TA: CiscoRTPInputStoppedEv CiscoRTPOutputStoppedEv CiscoRTPInputStartedEv CiscoRTPOutputStartedEv Call Quality Degrades and call falls back to PSTN network Scenario 5 A calls B, B transfers the call to external Party C; Transferred call goes through IP trunk due to VIPR feature; application is observing both A and B. Call info Result Action GC1 CallActiveEv GC1 ConnCreatedEv A GC1 ConnConnectedEv A GC1 CallCtlConnInitiatedEv A GC1 TermConnCreatedEv TA GC1 TermConnActiveEv TA GC1 CallCtlTermConnTalkingEv TA GC1 CallCtlConnDialingEv A GC1 CallCtlConnEstablishedEv A GC1 ConnCreatedEv B GC1 CallCtlConnOfferedEv B GC1 ConnAlertingEv B GC1 CallCtlConnAlertingEv B GC1 TermConnCreatedEv TB GC1 TermConnRingingEv TB GC1 CallCtlTermConnRingingEvImpl TB GC1: CallCtlConnEstablishedEv for A GC1: ConnConnectedEv for B GC1: CallCtlConnEstablishedEv for B A calls B; B answers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1586 Message Sequence Charts Message Sequence Charts

Page 1650 diagram

Page 1651

Call info Result Action GC2: ConsultCallActiveEv GC2: ConnCreatedEv B GC2: ConnConnectedEv B GC2: CallCtlConnInitiatedEv B GC2: TermConnCreatedEv TB GC2: TermConnActiveEv TB GC2: CallCtlTermConnTalkingEv TB GC2: CallCtlConnEstablishedEv B GC2: ConnCreatedEv C GC2: ConnConnectedEv for C GC2: CallCtlConnNetworkReachedEv GC2: CallCtlConnNetworkAlertingEv B makes a consult call to external party C. CiscoFeatureReason = CiscoFeatureReason. REASON_TRANSFEREDCALL GC1 CiscoTermConnSelectChangedEv B GC2 CiscoTermConnSelectChangedEv B GC1 CiscoTransferStartedEv GC2 CiscoCallChangedEv GC1 ConnCreatedEv C GC1: ConnConnectedEv for C GC2 ConnDisconnectedEv for C GC2 CallCtlConnDisconnectedEv C GC1 TermConnDroppedEv B GC1 CallCtlTermConnDroppedEv B GC1 ConnDisconnectedEv B GC1 CallCtlConnDisconnectecEv B GC2 TermConnDroppedEv B GC2 CallCtlTermConnDroppedEv B GC2 ConnDisconnectedEv B GC2 CallCtlConnDisconnectecEv B GC2 CallInvalidEv GC1 CiscoTransferEndEv B completes the transfer; Two calls are transferred; A and C get connected over IP trunk due to VIPR feature Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1587 Message Sequence Charts Message Sequence Charts

Page 1651 diagram

Page 1652

Scenario 6 A calls B, within the same cluster. B has CFA set to Forward all the calls to external party C, the forwarded call goes through IP Trunk due to VIPR feature. Application is observing A. Call info Result Action GC1: CallActiveEv ConnCreatedEv A ConnConnectedEv A CallCtlConnInitiatedEv A TermConnCreatedEv TA TermConnActiveEv TA CallCtlTermConnTalkingEv TA CallCtlConnEstablishedEv A A calls B within the same cluster CiscoFeatureReason = CiscoFeatureReason.REASON_FORWARDALL CallCtlCause = CallCtlEv.CAUSE_REDIRECTED GC1: CallCtlConnNetworkReachedEv CallCtlConnNetworkAlertingEv ConnCreatedEv C ConnConnectedEv C CallCtlConnNetworkReachedEv CallCtlConnNetworkAlertingEv Call at B gets forwarded to external party C Whisper Coaching Use Case One - Monitoring with Mode as WHISPER Start and Stop Whisper monitor: A is monitor target, B is monitor initiator. X calls A, A answers the call GC1 (CI1). B calls start monitor using GC2. The application has a call observer on both A and B. The monitoring capability enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1588 Message Sequence Charts Whisper Coaching

Page 1652 diagram

Page 1653

Call information Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called:A CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL GC1: ConnConnectedEv X… GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv CiscoRTPInputStartedEv A answers GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1589 Message Sequence Charts Message Sequence Charts

Page 1653 diagram

Page 1654

Call information Events Action GC2: Calling: B Called: A LRP: null Current calling: B Current called:A GC2:CallActive Cause: CAUSE_NORMAL GC2: ConnCreatedEv for B Cause: CAUSE_NORMAL GC2: CallCtlConnInitiatedEv GC2: TermConnCreatedEv TB GC2: TermConnActiveEv TB GC2: CallCtlTermConnTalkingEv TB B Cause: CAUSE_NORMAL GC2: CallCtlConnDialingEv for B GC2: CallCtlConnEstablishedEv for B Cause: CAUSE_NORMAL GC2: ConnCreatedEv A , here A.getType() = MONITORING_TARGET GC2: ConnInProgressEv A GC2: CallCtlConnOfferedEv A, GC2: ConnAlertingEv A GC2: CallCtlConnAlertingEv A GC2: ConnConnectedEv A GC2: CallCtlConnEstablishedEv A GC2: CiscoRTPInputStartedEv TB GC2: CiscoRTPOutputStartedEv TB getCiscoFeatureReason() = CiscoFeatureReason.REASON_CALL_MONITORING GC2:CiscoTermConnMonitorTargetInfoEv TB Cause: CAUSE_NORMAL address:A, here A.getType() = MONITORING_TARGET, terminal name: TA, rtphandle = CI1 CiscoMonitorTagetInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR [Note: Above connection is not created on Observered address A, rather an another Address object of type MONITORING_TARGET.] GC1: CiscoTermConnMonitoringStartEv TA getMonitorType() = CiscoCall.WHISPER_MONITORGC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_NORMAL address:B, device name: TBCiscoMonitorInitiatorInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR B calls start monitor using GC2 giving CI1, A and TermA in GC1 and mode as Whisper GC1: CallCtlTermConnHeldEv TA GC2:CiscoRTPInputStoppedEv TB GC2: CiscoRTPOutputStoppedEv TB GC1: CiscoRTPOutputStoppedEv TA GC1: CiscoRTPInputStoppedEv TA A puts the call with X on hold Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1590 Message Sequence Charts Message Sequence Charts

Page 1654 diagram

Page 1655

Call information Events Action GC1: CallCtlTermConnTalking TA GC1: CiscoRTPOutputStartedEv TA GC1: CiscoRTPInputStartedEv TA GC2: CiscoRTPOutputStartedEv TB GC2:CiscoRTPInputStartedEv TB A resumes the call GC2: CallCtlTermConnDroppedEv TB GC2: TermConnDroppedEv TB GC2: ConnDisconnectedEvB GC2: CallCtlConnDisconnectedEv B GC2: ConnDisconnectedEv A GC2: CallCtlConnDisconnectedEv A GC2: CallInvalidEv GC1: CiscoTermConnMonitorEndEv TA B calls drop() on GC2 to stop monitoring Use Case Two - Snapshot Use Case for Whisper Monitoring • A is monitor target. B is monitor initiator. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2. Another application adds call observer on A after monitoring session is established. Call information Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called:A CallActiveEv for callID = GC1 Cause: CAUSE_SNAPSHOT GC1:ConnCreatedEv for A Cause: CAUSE_SNAPSHOT GC1:ConnConnectedEv for A Cause: CAUSE_SNAPSHOT GC1: ConnConnectedEv X GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_SNAPSHOT GC1: CiscoTermConnMonitoringStartEv TA Cause: CAUSE_SNAPSHOT getMonitorType() = CiscoCall.WHISPER_MONITOR GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_SNAPSHOT address:B, device name: TB CiscoMonitorInitiatorInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR • A is monitor target and B is monitor initiator. Caller X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2. Another application adds call observer on B after monitoring sessions are established. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1591 Message Sequence Charts Message Sequence Charts

Page 1655 diagram

Page 1656

Call information Events Action GC1: Calling: B Called: A LRP: null Current calling: B Current called:A GC2:CallActive Cause: CAUSE_SNAPSHOT GC2: ConnCreatedEv for B Cause: : CAUSE_SNAPSHOT GC2: ConnConnectedEv B GC2: CallCtlConnEstablishedEv for B Cause: : CAUSE_SNAPSHOT GC2: TermConnCreatedEv TB GC2: TermConnActiveEv TB GC2: CallCtlTermConnTalkingEv TB B Cause: : CAUSE_SNAPSHOT GC2: ConnCreatedEv A , here A.getType() = MONITORING_TARGET GC2: ConnConnectedEv A GC2: CallCtlConnEstablishedEv A GC2:CiscoTermConnMonitorTargetInfoEv TB Cause: CAUSE_NORMAL address:A, here A.getType() = MONITORING_TARGET, terminal name: TA, rtphandle = CI1 CiscoMonitorInitatorInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR [Note: Above connection is not created on Observered address A, rather an another Address object of type MONITORING_TARGET.] Use Case Three Start Silent Monitoring then update the monitorType to Whisper mode followed by redirect and the updateMonitorType back to Silent monitor. Whisper monitor: A is monitor target, B is monitor initiator. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2(mode = silent). Application has call observer on both A and B. Application has monitoring capability enabled. App updates the monitor mode to Whisper. B redirects the monitoring call to observed party C. App updates the monitor mode to silent and later drops monitoring call to stop monitoring. Call information Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called:A CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL GC1: ConnConnectedEv X GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv CiscoRTPInputStartedEv A answers GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1592 Message Sequence Charts Message Sequence Charts

Page 1656 diagram

Page 1657

Call information Events Action GC2: Calling: B Called: A LRP: null Current calling: B Current called:A GC2:CallActive Cause: CAUSE_NORMAL GC2: ConnCreatedEv for B Cause: CAUSE_NORMAL GC2: CallCtlConnInitiatedEv GC2: TermConnCreatedEv TB GC2: TermConnActiveEv TB GC2: CallCtlTermConnTalkingEv TB B Cause: CAUSE_NORMAL GC2: CallCtlConnDialingEv for B GC2: CallCtlConnEstablishedEv for B Cause: CAUSE_NORMAL GC2: ConnCreatedEv A , here A.getType() = MONITORING_TARGET GC2: ConnInProgressEv A GC2: CallCtlConnOfferedEv A, GC2: ConnAlertingEv A GC2: CallCtlConnAlertingEv A GC2: ConnConnectedEv A GC2: CallCtlConnEstablishedEv A GC2: CiscoRTPInputStartedEv TB getCiscoFeatureReason() = CiscoFeatureReason.REASON_CALL_MONITORING GC2:CiscoTermConnMonitorTargetInfoEv TB Cause: CAUSE_NORMAL address:A, here A.getType() = MONITORING_TARGET, terminal name: TA, rtphandle = CI1 CiscoMonitorTagetInfo.getMonitorType() = CiscoCall.SILENT_MONITOR [Note: Above connection is not created on Observered address A, rather an another Address object of type MONITORING_TARGET.] GC1: CiscoTermConnMonitoringStartEv TA getMonitorType() = CiscoCall.SILENT_MONITOR GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_NORMAL address:B, device name: TB CiscoMonitorInitiatorInfo.getMonitorType() = CiscoCall.SILENT_MONITOR B calls start monitor using GC2 giving CI1, A and TermA from GC1 and mode as Silent GC2: CiscoTermConnMonitorUpdatedEv TA GC2: CiscoTermConnMonitorUpdatedEv TB getMonitorType() = CiscoCall.WHISPER_MONITOR getTransactionID() = X GC2: CiscoRTPOutputStartedEv TB The application calls updateMonitorType() API on TermConn of B with mode as Whisper. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1593 Message Sequence Charts Message Sequence Charts

Page 1657 diagram

Page 1658

Call information Events Action GC2: ConnCreatedEv C GC2: ConnConnectedEv C GC2: CallCtlConnOfferedEv C GC2: TermConnCreatedEv TC GC2: TermConnActiveEv TC GC2: CallCtlTermConnTalkingEv for TC GC2: TermConnDroppedEv TB GC2: CallCtlTermConnDroppedEv TB GC2: ConnDisconnectedEv TB GC2: CallCtlConnDisconnectedEv TB GC2: CiscoTermConnMonitorTargetInfoEv TC CAUSE_NORMAL address:A, here A.getType() = MONITORING_TARGET, terminal name: TA, rtphandle = CI1 CiscoMonitorTagetInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR GC2; CiscoTermConnMonitorInitatorInfoEv TA Cause: CAUSE_NORMAL address:C, device name: TC CiscoMonitorInitiatorInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR B redirects the call to C and C answers. GC2: CiscoTermConnMonitorUpdatedEv TA GC2: CiscoTermConnMonitorUpdatedEv TC getMonitorType() = CiscoCall.SILENT_MONITOR getTransactionID() = X GC2: CiscoRTPOutputStoppedEv TC The application calls updateMonitorType() API on TermConn of C with mode as Silent GC2: CallCtlTermConnDroppedEv TC GC2: TermConnDroppedEv TC GC2: ConnDisconnectedEv C GC2: CallCtlConnDisconnectedEv C GC2: ConnDisconnectedEv A GC2: CallCtlConnDisconnectedEv A GC2: CallInvalidEv GC1: CiscoTermConnMonitorEndEv TA C calls drop on GC2 to stop monitoring Use Case Four Secured Whisper Monitoring followed by redirect to non-secured supervisor Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1594 Message Sequence Charts Message Sequence Charts

Page 1658 diagram

Page 1659

Whisper monitor: A is monitor target, B is monitor initiator. Both A and B are Encrypted devices. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2(mode = whisper). Application has call observer on both A and B. Application has monitoring capability enabled. B redirects to observed party C which is non-secured. Call information Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called:A CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL GC1: ConnConnectedEv X GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv CiscoRTPInputStartedEv A answers GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1595 Message Sequence Charts Message Sequence Charts

Page 1659 diagram

Page 1660

Call information Events Action GC2: Calling: B Called: A LRP: null Current calling: B Current called:A GC2:CallActive Cause: CAUSE_NORMAL GC2: ConnCreatedEv for B Cause: CAUSE_NORMAL GC2: CallCtlConnInitiatedEv GC2: TermConnCreatedEv TB GC2: TermConnActiveEv TB GC2: CallCtlTermConnTalkingEv TB B Cause: CAUSE_NORMAL GC2: CallCtlConnDialingEv for B GC2: CallCtlConnEstablishedEv for B Cause: CAUSE_NORMAL GC2: ConnCreatedEv A , here A.getType() = MONITORING_TARGET GC2: ConnInProgressEv A GC2: CallCtlConnOfferedEv A, GC2: ConnAlertingEv A GC2: CallCtlConnAlertingEv A GC2: ConnConnectedEv A GC2: CallCtlConnEstablishedEv A GC2: CiscoRTPInputStartedEv TB GC2: CiscoRTPOutputStartedEv TB getCiscoFeatureReason() = CiscoFeatureReason.REASON_CALL_MONITORING GC2:CiscoTermConnMonitorTargetInfoEv TB Cause: CAUSE_NORMAL address:A, here A.getType() = MONITORING_TARGET, terminal name: TA, rtphandle = CI1 CiscoMonitorTagetInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR [Note: Above connection is not created on Observered address A, rather an another Address object of type MONITORING_TARGET.] GC1: CiscoTermConnMonitoringStartEv TA getMonitorType() = CiscoCall.WHISPER_MONITOR GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_NORMAL address:B, device name: TB CiscoMonitorInitiatorInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR B calls start monitor using GC2 giving CI1, A and TermA from GC1 and mode as whisper Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1596 Message Sequence Charts Message Sequence Charts

Page 1660 diagram

Page 1661

Call information Events Action GC2: ConnCreatedEv C GC2: ConnConnectedEv C GC2: CallCtlConnOfferedEv C GC2: TermConnCreatedEv TC GC2: TermConnActiveEv TC GC2: CallCtlTermConnTalkingEv for TC GC2: TermConnDroppedEv TB GC2: CallCtlTermConnDroppedEv TB GC2: ConnDisconnectedEv TB GC2: CallCtlConnDisconnectedEv TB GC2: CiscoTermConnMonitorTargetInfoEv TC Cause: CAUSE_NORMAL address:A, here A.getType() = MONITORING_TARGET, terminal name: TA, rtphandle = CI1 CiscoMonitorTagetInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR [Note: Above connection is not created on Observered address A, rather an another Address object of type MONITORING_TARGET.] GC2: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_NORMAL address:C, device name: TC CiscoMonitorInitiatorInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR GC2: ConnFailedEv C GC2: CallCtlConnFailedEv C cause : CAUSE_BCNAUTHORISED GC2: CallInvalidEv GC2: CiscoAddrMonitorTerminatedEv B cause : CAUSE_BCNAUTHORISED B redirects the call to C and C answers Use Case Five Agent greeting is played and the application initiates the monitoring request (Silent/Whisper). JTAPI throws InvalidStateException with error "CTIERR_RESOURCE_NOT_AVAILABLE" when the application sends a monitor request and when an agent greeting is played at that time. Use Case Six - Tone Direction Interaction Use Cases 1. Service Parameter = PLAYTONE_NOLOCAL_OR_REMOTE; API Request (startMonitor/updateMonitorType) = PLAYTONE_NOLOCAL_OR_REMOTE • If Mode is Silent, then Effective Tone Direction = PLAYTONE_NOLOCAL_OR_REMOTE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1597 Message Sequence Charts Message Sequence Charts

Page 1661 diagram

Page 1662

• If Mode is Whisper, then Effective Tone Direction = PLAYTONE_NOLOCAL_OR_REMOTE 2. Service Parameter = PLAYTONE_NOLOCAL_OR_REMOTE; API Request (startMonitor/updateMonitorType) = PLAYTONE_LOCALONLY • If Mode is Silent, then Effective Tone Direction = PLAYTONE_LOCALONLY • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_NOLOCAL_OR_REMOTE 3. Service Parameter = PLAYTONE_NOLOCAL_OR_REMOTE; API Request (startMonitor/updateMonitorType) = PLAYTONE_REMOTEONLY • If Mode is Silent, then Effective Tone Direction = PLAYTONE_REMOTEONLY • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_REMOTEONLY 4. Service Parameter = PLAYTONE_NOLOCAL_OR_REMOTE; API Request (startMonitor/updateMonitorType) = PLAYTONE_BOTHLOCALANDREMOTE • If Mode is Silent, then Effective Tone Direction = PLAYTONE_BOTHLOCALANDREMOTE • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_REMOTEONLY 5. Service Parameter = PLAYTONE_LOCALONLY; API Request (startMonitor/updateMonitorType) = PLAYTONE_NOLOCAL_OR_REMOTE • If Mode is Silent, then Effective Tone Direction = PLAYTONE_LOCALONLY • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_NOLOCAL_OR_REMOTE 6. Service Parameter = PLAYTONE_LOCALONLY; API Request (startMonitor/updateMonitorType) = PLAYTONE_LOCALONLY • If Mode is Silent, then Effective Tone Direction = PLAYTONE_LOCALONLY • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_NOLOCAL_OR_REMOTE 7. Service Parameter = PLAYTONE_LOCALONLY; API Request (startMonitor/updateMonitorType) = PLAYTONE_REMOTEONLY • If Mode is Silent, then Effective Tone Direction = PLAYTONE_BOTHLOCALANDREMOTE • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_REMOTEONLY 8. Service Parameter = PLAYTONE_LOCALONLY; API Request (startMonitor/updateMonitorType) = PLAYTONE_BOTHLOCALANDREMOTE • If Mode is Silent, then Effective Tone Direction = PLAYTONE_BOTHLOCALANDREMOTE • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_REMOTEONLY 9. Service Parameter = PLAYTONE_REMOTEONLY; API Request (startMonitor/updateMonitorType) = PLAYTONE_NOLOCAL_OR_REMOTE • If Mode is Silent, then Effective Tone Direction = PLAYTONE_REMOTEONLY • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_REMOTEONLY 10. Service Parameter = PLAYTONE_REMOTEONLY; API Request (startMonitor/updateMonitorType) = PLAYTONE_LOCALONLY • If Mode is Silent, then Effective Tone Direction = PLAYTONE_BOTHLOCALANDREMOTE • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_REMOTEONLY 11. Service Parameter = PLAYTONE_REMOTEONLY; API Request (startMonitor/updateMonitorType) = PLAYTONE_REMOTEONLY Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1598 Message Sequence Charts Message Sequence Charts

Page 1662 content

Page 1663

• If Mode is Silent, then Effective Tone Direction = PLAYTONE_REMOTEONLY • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_REMOTEONLY 12. Service Parameter = PLAYTONE_REMOTEONLY; API Request (startMonitor/updateMonitorType) = PLAYTONE_BOTHLOCALANDREMOTE • If Mode is Silent, then Effective Tone Direction = PLAYTONE_BOTHLOCALANDREMOTE • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_REMOTEONLY 13. Service Parameter = PLAYTONE_BOTHLOCALANDREMOTE; API Request (startMonitor/updateMonitorType) = Any tone • If Mode is Silent, then Effective Tone Direction = PLAYTONE_BOTHLOCALANDREMOTE • If Mode is Whisper, then Effective Tone Direction = PLAYTONE_REMOTEONLY Use Case Seven Supervisor B is a shared line and supervisor updates monitorType from silent to whisper. Address B is a shared line configured on terminal T1(initiator) and T2. Whisper monitor: A is monitor target, B(T1) is monitor initiator. X calls A, A answers the call GC1 (ci1). B(T1) calls start monitor using GC2(mode = silent). Application has call observer on all A, B(T1) and B(T2_. Application has monitoring capability enabled. App updates the monitor type to Whisper and later drops monitoring call to stop monitoring. Call information Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called:A CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL GC1: ConnConnectedEv X GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv CiscoRTPInputStartedEv A answers GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1599 Message Sequence Charts Message Sequence Charts

Page 1663 diagram

Page 1664

Call information Events Action GC2: Calling: B Called: A LRP: null Current calling: B Current called:A GC2:CallActive Cause: CAUSE_NORMAL GC2: ConnCreatedEv for B Cause: CAUSE_NORMAL GC2: CallCtlConnInitiatedEv GC2: TermConnCreatedEv B(T1) GC2: TermConnActiveEv B(T1) GC2: TermConnCreatedEv for B(T2) GC2: TermConnPassiveEv for B(T2) GC2: CallCtlTermConnTalkingEv B(T1) B Cause: CAUSE_NORMAL GC2: CallCtlConnDialingEv for B GC2: CallCtlConnEstablishedEv for B Cause: CAUSE_NORMAL GC2: ConnCreatedEv A , here A.getType() = MONITORING_TARGET GC2: ConnInProgressEv A GC2: CallCtlConnOfferedEv A, GC2: ConnAlertingEv A GC2: CallCtlConnAlertingEv A GC2: ConnConnectedEv A GC2: CallCtlConnEstablishedEv A GC2: CiscoRTPInputStartedEv B(T1) getCiscoFeatureReason() = CiscoFeatureReason.REASON_CALL_MONITORING GC2:CiscoTermConnMonitorTargetInfoEv B(T1) Cause: CAUSE_NORMAL address:A, here A.getType() = MONITORING_TARGET, terminal name: TA, rtphandle = CI1 CiscoMonitorTagetInfo.getMonitorType() = CiscoCall.SILENT_MONITOR [Note: Above connection is not created on Observered address A, rather an another Address object of type MONITORING_TARGET.] GC1: CiscoTermConnMonitoringStartEv TAgetMonitorType() = CiscoCall.SILENT_MONITOR GC1: CiscoTermConnMonitorInitiatorInfoEv TA Cause: CAUSE_NORMAL address:B, device name: B(T1) CiscoMonitorInitiatorInfo.getMonitorType() = CiscoCall.SILENT_MONITOR B calls start monitor using GC2 giving CI1, A and TermA from GC1 and mode as Silent Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1600 Message Sequence Charts Message Sequence Charts

Page 1664 diagram

Page 1665

Call information Events Action GC2: CiscoTermConnMonitorUpdatedEv TA GC2: CiscoTermConnMonitorUpdatedEv B(T1) getMonitorType() = CiscoCall.WHISPER_MONITOR getTransactionID() = X GC2: CiscoRTPOutputStartedEv B(T1) The application calls updateMonitorType() API on TermConn of B with mode as Whisper GC2: CallCtlTermConnDroppedEv BT(1) GC2: TermConnDroppedEv B(T1) GC2: CallCtlTermConnDroppedEv BT(2) GC2: TermConnDroppedEv B(T2) GC2: ConnDisconnectedEv B GC2: CallCtlConnDisconnectedEv B GC2: ConnDisconnectedEv A GC2: CallCtlConnDisconnectedEv A GC2: CallInvalidEv GC1: CiscoTermConnMonitorEndEv TA B calls drop on GC2 to stop monitoring Use Case Eight Agent is shared line. After monitoring Agent holds and its shared line resumes. A(T1) is monitor target and shares a line with Terminal T2 , B is monitor initiator. X calls A, A answers the call GC1 (ci1). B calls start monitor using GC2. Application has call observer on all A(T1), A(T2) and B. Application has monitoring capability enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1601 Message Sequence Charts Message Sequence Charts

Page 1665 diagram

Page 1666

Call information Events Action GC1: Calling: X Called: A LRP: null Current calling: X Current called:A GC2: Calling: B Called: A LRP: null Current calling: B Current called:A A(T1) answers GC1B calls start monitor using GC2 giving CI1, A and TermA(T1) in GC1 and mode as Whisper Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1602 Message Sequence Charts Message Sequence Charts

Page 1666 diagram

Page 1667

Call information Events Action CallActiveEv for callID = GC1 Cause: CAUSE_NEW_CALL GC1:ConnCreatedEv for A Cause: CAUSE_NORMAL GC1:ConnConnectedEv for A Cause: CAUSE_NORMAL GC1: ConnConnectedEv X GC1:CallCrlTermConnRingingEv TA Cause: CAUSE_NORMAL GC1:CallCrlTermConnTalkingEv TA Cause: CAUSE_NORMAL CiscoRTPOutputStartedEv T1 CiscoRTPInputStartedEv T1 GC2:CallActive Cause: CAUSE_NORMAL GC2: ConnCreatedEv for B Cause: CAUSE_NORMAL GC2: CallCtlConnInitiatedEv GC2: TermConnCreatedEv TB GC2: TermConnActiveEv TB GC2: CallCtlTermConnTalkingEv TB B Cause: CAUSE_NORMAL GC2: CallCtlConnDialingEv for B GC2: CallCtlConnEstablishedEv for B Cause: CAUSE_NORMAL GC2: ConnCreatedEv A , here A.getType() = MONITORING_TARGET GC2: ConnInProgressEv A GC2: CallCtlConnOfferedEv A, GC2: ConnAlertingEv A GC2: CallCtlConnAlertingEv A GC2: ConnConnectedEv A GC2: CallCtlConnEstablishedEv A GC2: CiscoRTPInputStartedEv TB GC2: CiscoRTPOutputStartedEv TB getCiscoFeatureReason() = CiscoFeatureReason.REASON_CALL_MONITORING GC2:CiscoTermConnMonitorTargetInfoEv TB Cause: CAUSE_NORMAL address:A, here A.getType() = MONITORING_TARGET, terminal name: TA, rtphandle = CI1 CiscoMonitorTagetInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR [Note: Above connection is not created on Observered address A, rather an another Address object of type MONITORING_TARGET.] GC1: CiscoTermConnMonitoringStartEv T1(A) getMonitorType() = CiscoCall.WHISPER_MONITOR Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1603 Message Sequence Charts Message Sequence Charts

Page 1667 diagram

Page 1668

Call information Events Action GC1: CiscoTermConnMonitorInitiatorInfoEv T1(A) Cause: CAUSE_NORMAL address:B, device name: TB CiscoMonitorInitiatorInfo.getMonitorType() = CiscoCall.WHISPER_MONITOR GC1: CallCtlTermConnHeldEv A(T1) GC1: CallCtlTermConnActiveEv A(T2) GC1: CallCtlTermConnHeldEv A(T2) GC2:CiscoRTPInputStoppedEv TB GC2: CiscoRTPOutputStoppedEv TB GC1: CiscoRTPOutputStoppedEv A(T1) GC1: CiscoRTPInputStoppedEv A(T1) A(T1) puts the call on hold GC1: CallCtlTermConnTalkingEv A(T2) GC1: CallCtlTermConnPassiveEv A(T1) GC1: CiscoRTPOutputStartedEv A(T2) GC1: CiscoRTPInputStartedEv A(T2) GC2: CallCtlTermConnDroppedEv TB GC2: TermConnDroppedEv TB GC2: ConnDisconnectedEvB GC2: CallCtlConnDisconnectedEv B GC2: ConnDisconnectedEv A GC2: CallCtlConnDisconnectedEv A GC2: CallInvalidEv GC1: CiscoTermConnMonitorEndEv TA A(T2) resumes the call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1604 Message Sequence Charts Message Sequence Charts

Page 1668 diagram

Page 1669

A P P E N D I X B Cisco Unified JTAPI Classes and Interfaces This appendix contains a listing of all classes and interfaces that are available in the Cisco Unified JTAPI implementation: • Cisco Unified JTAPI Version 1.2 Classes and Interfaces, on page 1605, which lists all the JTAPI v 1.2 classes and methods. The supported classes and methods have a check mark in the Cisco Unified JTAPI Support column. • Cisco Unified JTAPI Extension Classes and Interfaces, on page 1623, which lists the Cisco Unified JTAPI extension classes and methods. • Cisco Trace Logging Classes and Interfaces, on page 1628, which lists the error tracing classes and methods. • Cisco Unified JTAPI Version 1.2 Classes and Interfaces, on page 1605 • Cisco Unified JTAPI Extension Classes and Interfaces, on page 1623 • Cisco Trace Logging Classes and Interfaces, on page 1628 Cisco Unified JTAPI Version 1.2 Classes and Interfaces This section includes the following: • Core Package, on page 1606 • Call Center Package, on page 1609 • Call Center Capabilities Package, on page 1611 • Call Center Events Package, on page 1612 • Call Control Package, on page 1614 • Call Control Capabilities Package, on page 1616 • Call Control Events Package, on page 1618 • Capabilities Package, on page 1619 • Events Package, on page 1620 • Media Package, on page 1621 • Media Capabilities Package, on page 1622 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1605

Image 1 from page 1669

Page 1669 content

Page 1670

• Media Events Package, on page 1622 • Unsupported Packages, on page 1622 Core Package The following table lists each JTAPI interface in the JTAPI Core Package followed by the associated method (s) and whether the classes are supported by the Cisco Unified JTAPI implementation. Comments CiscoUnified JTAPI support Method names Class names Yes addCallObserver Address Yes addressObserver Yes getAddressCapabilities Yes getCallObservers Yes getCapabilities Yes getConnections Yes getName Yes getObservers Yes getProvider Yes getTerminals Yes removeCallObserver Yes removeObserver Yes addressChangedEvent AddressObserver Yes addObserver Call A CallObserver must exist for the Terminal or Address originating the call. The FeaturePriority parameter is not supported. Yes connect Yes getCallCapabilities Yes getCapabilities Yes getConnections Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1606 Cisco Unified JTAPI Classes and Interfaces Core Package

Page 1670 diagram

Page 1671

Comments CiscoUnified JTAPI support Method names Class names Yes getObservers Yes getProvider Yes getState Yes removeObserver Yes callChangedEvent CallObserver Yes disconnect Connection Yes getAddress Yes getCall Yes getCapabilities Yes getConnectionCapabilities Yes getState Yes getTerminalConnections Yes getName JtapiPeer Yes getProvider Yes getServices Yes getJtapiPeer JtapiPeerFactory Yes addObserver Provider Yes createCall Yes getAddress Yes getAddressCapabilities () Yes getAddressCapabilities (Terminal) Yes getAddresses Yes getCallCapabilities () Yes getCallCapabilities (Terminal, Address) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1607 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1671 diagram

Page 1672

Comments CiscoUnified JTAPI support Method names Class names This method returns calls only when there are CallObservers attached to Addresses or Terminals, when a RouteAddress is registered for routing, or when a CiscoMediaTerminal is registered. Yes getCalls Yes getCapabilities Yes getConnectionCapabilities () Yes getConnectionCapabilities (Terminal, Address) Yes getName Yes getObservers Yes getProviderCapabilities () Yes getProviderCapabilities (Terminal) Yes getState Yes getTerminal Yes getTerminalCapabilities () Yes getTerminalCapabilities (Terminal) Yes getTerminalConnectionCapabilities () Yes getTerminalConnectionCapab ilities (Terminal) Yes getTerminals Yes removeObserver Yes shutdown Yes providerChangedEvent ProviderObserver Yes addCallObserver Terminal Yes addObserver Yes getAddresses Yes getCallObservers Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1608 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1672 diagram

Page 1673

Comments CiscoUnified JTAPI support Method names Class names Yes getCapabilities Yes getName Yes getObservers Yes getProvider Yes getTerminalCapabilities Yes getTerminalConnections Yes removeCallObserver Yes removeObserver Yes answer TerminalConnection Yes getCapabilities Yes getConnection Yes getState Yes getTerminal Yes getTerminalConnectionCapabilities Yes terminalChangedEvent TerminalObserver Call Center Package The following table lists each JTAPI interface in the JTAPI Call Center Package followed by the associated method(s) and whether the classes are supported by the Cisco Unified JTAPI implementation. CiscoUnifiedJTAPI support Method names Class names getACDManagerAddress ACDAddress getLoggedOnAgents getNumberQueued getOldestCallQueued getQueueWaitTime getRelativeQueueLoad ACDAddressObserver Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1609 Cisco Unified JTAPI Classes and Interfaces Call Center Package

Page 1673 diagram

Page 1674

CiscoUnifiedJTAPI support Method names Class names getACDManagerConnection ACDConnection getACDAddresses ACDManagerAddress getACDConnections ACDManagerConnection getACDAddress Agent getAgentAddress getAgentID getAgentTerminal getState setState addAgent AgentTerminal getAgents removeAgents setAgents AgentTerminalObserver addCallObserver CallCenterAddress connectPredictive CallCenterCall getApplicationData getTrunks setApplicationData CallCenterCallObserver getACDAddresses CallCenterProvider getACDManagerAddresses getRouteableAddresses getCall CallCenterTrunk getName getState getType Yes cancelRouteCallback RouteAddress Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1610 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1674 diagram

Page 1675

CiscoUnifiedJTAPI support Method names Class names Yes getActiveRouteSessions Yes getRouteCallback Yes registerRouteCallback Yes reRouteEvent RouteCallback Yes routeCallbackEndedEvent Yes routeEndEvent Yes routeEvent Yes routeUsedEvent Yes endRoute RouteSession Yes getCause Yes getRouteAddress Yes getState Yes selectRoute Call Center Capabilities Package The following table lists each JTAPI interface in the JTAPI Call Center Capabilities Package followed by the associated method(s), and whether the classes are supported by the Cisco Unified JTAPI implementation. CiscoUnifiedJTAPI support Method names Class names canGetACDManagerAddress ACDAddressCapabilities canGetLoggedOnAgents canGetNumberQueued canGetOldestCallQueued canGetQueueWaitTime canGetRelativeQueueLoad canGetACDManagerConnection ACDConnectionCapabilities canGetACDAddresses ACDManagerAddressCapabilities canGetACDConnections ACDManagerConnectionCapabilities canHandleAgents AgentTerminalCapabilities Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1611 Cisco Unified JTAPI Classes and Interfaces Call Center Capabilities Package

Page 1675 diagram

Page 1676

CiscoUnifiedJTAPI support Method names Class names canAddCallObserver CallCenterAddressCapabilities canConnectPredictive CallCenterCallCapabilities canGetTrunks canHandleApplicationData Yes canGetACDAddresses CallCenterProviderCapabilities Yes canGetACDManagerAddresses Yes canGetRouteableAddresses Yes canRouteCalls RouteAddressCapabilities Call Center Events Package The following table lists each JTAPI interface in the JTAPI Call Center Events Package followed by the associated method(s), and whether the classes are supported by the Cisco Unified JTAPI implementation. CiscoUnifiedJTAPI support Method names Class names ACDAddrBusyEv getAgent ACDAddrEv getAgentAddress getAgentTerminal getState getTrunks ACDAddrLoggedOffEv ACDAddrLoggedOnEv ACDAddrNotReadyEv ACDAddrReadyEv ACDAddrUnknownEv ACDAddrWorkNotReadyEv ACDAddrWorkReadyEv AgentTermBusyEv getACDAddress AgentTermEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1612 Cisco Unified JTAPI Classes and Interfaces Call Center Events Package

Page 1676 diagram

Page 1677

CiscoUnifiedJTAPI support Method names Class names getAgent getAgentAddress getAgentID getState AgentTermLoggedOffEv AgentTermLoggedOnEv AgentTermNotReadyEv AgentTermReadyEv AgentTermUnknownEv AgentTermWorkNotReadyEv AgentTermWorkReadyEv getApplicationData CallCentCallAppDataEv getCalledAddress CallCentCallEv getCallingAddress getCallingTerminal getLastRedirectedAddress getTrunks CallCentConnEv CallCentConnInProgressEv getCallCenterCause CallCentEv getTrunk CallCentTrunkEv CallCentTrunkInvalidEv CallCentTrunkValidEv Yes ReRouteEvent Yes getRouteAddress RouteCallbackEndedEvent Yes RouteEndEvent Yes getCallingAddress RouteEvent Yes getCallingTerminal Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1613 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1677 diagram

Page 1678

CiscoUnifiedJTAPI support Method names Class names Yes getCurrentRouteAddress Yes getRouteSelectAlgorithm Yes getSetupInformation Yes getRouteSession RouteSessionEvent Yes getCallingAddress RouteUsedEvent Yes getCallingTerminal Yes getDomain Yes getRouteUsed Call Control Package The following table lists each JTAPI interface in the JTAPI Call Control Package followed by the associated method(s) and whether the classes are supported by the Cisco Unified JTAPI Implementation. Comments CiscoUnifiedJTAPI support Method names Class names Only for Call Forward All Yes cancelForwarding CallControlAddress getDoNotDisturb Only for Call Forward All Yes getForwarding getMessageWaiting setDoNotDisturb Only for Call Forward All Yes setForwarding setMessageWaiting addParty CallControlCall In a consult conference scenario, only OriginalCall.conference (ConsultCall ) is supported. ConsultCall.conference (OriginalCall) is not supported. Yes conference Yes consult(TerminalConnection) Yes consult(TerminalConnection, String) Yes drop Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1614 Cisco Unified JTAPI Classes and Interfaces Call Control Package

Page 1678 diagram

Page 1679

Comments CiscoUnifiedJTAPI support Method names Class names Yes getCalledAddress Yes getCallingAddress Yes getCallingTerminal Yes getConferenceController Yes getConferenceEnable Yes getLastRedirectedAddress Yes getTransferController Yes getTransferEnable Yes offHook Yes setConferenceController Yes setConferenceEnable Yes setTransferController Yes setTransferEnable In a consult transfer scenario, only OriginalCall.transfer (ConsultCall) is supported. ConsultCall.transfer (OriginalCall) is not supported. Yes transfer(Call) Yes transfer(String) Yes CallControlCallObserver Yes accept CallControlConnection Yes addToAddress Yes getCallControlState Yes park Redirect allows a connection in the CallControlConnection. ESTABLISHED state to be redirected. Yes redirect Yes reject getDestinationAddress CallControlForwarding getFilter Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1615 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1679 diagram

Page 1680

Comments CiscoUnifiedJTAPI support Method names Class names getSpecificCaller getType getDoNotDisturb CallControlTerminal pickup (Address, Address) pickup (Connection, Address) pickup (TerminalConnection, Address) pickupFromGroup(Address) pickupFromGroup(String, Address) setDoNotDisturb Yes getCallControlState CallControlTerminalConnection Yes hold Only implemented for CiscoIntercomAddresses Yes join leave Yes unhold CallControlTerminalObserver Call Control Capabilities Package The following table lists each JTAPI interface in the JTAPI Call Control Capabilities Package followed by the associated method(s) and whether the classes are supported by the Cisco Unified JTAPI implementation. CiscoUnifiedJTAPI support Method names Class names Yes canCancelForwarding CallControlAddressCapabilities Yes canGetDoNotDisturb Yes canGetForwarding Yes canGetMessageWaiting Yes canSetDoNotDisturb Yes canSetForwarding Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1616 Cisco Unified JTAPI Classes and Interfaces Call Control Capabilities Package

Page 1680 diagram

Page 1681

CiscoUnifiedJTAPI support Method names Class names Yes canSetMessageWaiting Yes canAddParty CallControlCallCapabilities Yes canConference Yes canConsult Yes canConsult(TerminalConnection) Yes canConsult(TerminalConnection, String) Yes canDrop Yes canOffHook Yes canSetConferenceController Yes canSetConferenceEnable Yes canSetTransferController Yes canSetTransferEnable Yes canTransfer Yes canTransfer(Call) Yes canTransfer(String) Yes canAccept CallControlConnectionCapabilities Yes canAddToAddress Yes canPark Yes canRedirect Yes canReject Yes canGetDoNotDisturb CallControlTerminalCapabilities Yes canPickup Yes canPickup(Address, Address) Yes canPickup(Connection, Address) Yes canPickup(TerminalConnection, Address) Yes canPickupFromGroup Yes canPickupFromGroup(Address) Yes canPickupFromGroup(String, Address) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1617 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1681 diagram

Page 1682

CiscoUnifiedJTAPI support Method names Class names Yes canSetDoNotDisturb Yes canHold CallControlTerminalConnectionCapabilities Yes canJoin Yes canLeave Yes canUnhold Call Control Events Package The following table lists each JTAPI interface in the JTAPI Call Control Events Package followed by the associated method(s) and whether the classes are supported by the Cisco Unified JTAPI implementation. Comments CiscoUnifiedJTAPI support Method names Class names getDoNotDisturbState CallCtlAddrDoNotDisturbEv CallCtlAddrEv Yes getForwarding CallCtlAddrForwardEv getMessageWaitingState CallCtlAddrMessageWaitingEv Yes getCalledState CallCtlCallEv Yes getCallingAddress Yes getCallingTerminal Yes getLastRedirectedAddress Yes CallCtlConnAlertingEv Yes getDigits CallCtlConnDialingEv Yes CallCtlConnDisconnectedEv Yes CallCtlConnEstablishedEv Yes CallCtlConnEv Yes CallCtlConnFailedEv Yes CallCtlConnInitiatedEv Yes CallCtlConnNetworkAlertingEv Yes CallCtlConnNetworkReachedEv Yes CallCtlConnOfferedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1618 Cisco Unified JTAPI Classes and Interfaces Call Control Events Package

Page 1682 diagram

Page 1683

Comments CiscoUnifiedJTAPI support Method names Class names Yes getNumberInQueue CallCtlConnQueuedEv Yes CallCtlConnUnknownEv Yes getCallControlCause CallCtlEv CallCtlTermConnBridgedEv Yes CallCtlTermConnDroppedEv Yes CallCtlTermConnEv Yes CallCtlTermConnHeldEv CallCtlTermConnInUseEv Yes CallCtlTermConnRingingEv Yes CallCtlTermConnTalkingEv Yes CallCtlTermConnUnknownEv CallCtlTermDoNotDisturbEv CallCtlTermEv Capabilities Package The following table lists each JTAPI interface in the JTAPI Capabilities Package followed by the associated method(s) and whether the classes are supported by the Cisco Unified JTAPI implementation. Comments CiscoUnifiedJTAPI support Method names Class names Yes isObservable AddressCapabilities Yes canConnect CallCapabilities Yes isObservable Yes canDisconnect ConnectionCapabilities Yes isObservable ProviderCapabilities Yes isObservable TerminalCapabilities Yes canAnswer TerminalConnectionCapabilities Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1619 Cisco Unified JTAPI Classes and Interfaces Capabilities Package

Page 1683 diagram

Page 1684

Events Package The following table lists each JTAPI interface in the JTAPI Events Package followed by the associated method(s) and whether the classes are supported by the Cisco Unified JTAPI Implementation. CiscoUnifiedJTAPI support Method names Class names Yes getAddress AddrEv Yes AddrObservationEndedEv Yes CallActiveEv Yes getCall CallEv Yes CallInvalidEv Yes getEndedObject CallObservationEndedEv Yes ConnAlertingEv Yes ConnConnectedEv Yes ConnCreatedEv Yes ConnDisconnectedEv Yes getConnection ConnEv Yes ConnFailedEv Yes ConnInProgressEv Yes ConnUnknownEv Yes getCause Ev Yes getID Yes getMetaCode Yes getObserved Yes isNewMetaEvent Yes getProvider ProvEv Yes ProvInServiceEv Yes ProvObservationEndedEv Yes ProvOutOfServiceEv Yes ProvShutdownEv Yes TermConnActiveEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1620 Cisco Unified JTAPI Classes and Interfaces Events Package

Page 1684 diagram

Page 1685

CiscoUnifiedJTAPI support Method names Class names Yes TermConnCreatedEv Yes TermConnDroppedEv Yes TermConnEvgetTerminalConnection TermConnPassiveEv Yes TermConnRingingEv Yes TermConnUnknownEv Yes getTerminal TermEv Yes TermObservationEndedEv Media Package The following table lists each JTAPI interface from the JTAPI Media Package followed by the associated method(s) and whether the classes are supported by the Cisco Unified JTAPI implementation. Comments CiscoUnifiedJTAPI support Method names Class names Yes MediaCallObserver Yes generateDtmf MediaTerminalConnection getMediaAvailability getMediaState Yes setDtmfDetection startPlaying startRecording stopPlaying stopRecording useDefaultMicrophone useDefaultSpeaker usePlayURL useRecordURL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1621 Cisco Unified JTAPI Classes and Interfaces Media Package

Page 1685 diagram

Page 1686

Media Capabilities Package The following table lists each JTAPI interface in the JTAPI Media Capabilities Package followed by the associated method(s) and whether the classes are supported by the Cisco Unified JTAPI implementation. Comments CiscoUnifiedJTAPI support Method names Class names Yes canDetectDtmf MediaTerminalConnection Capabilities Yes canGenerateDtmf Yes canStartPlaying Yes canStartRecording Yes canStopPlaying Yes canStopRecording Yes canUseDefaultMicrophone Yes canUseDefaultSpeaker Yes canUsePlayURL Yes canUseRecordURL Media Events Package The following table lists each JTAPI interface in the JTAPI Media Events Package followed by the associated method(s) and whether the classes are supported by the Cisco Unified JTAPI implementation. Comments CiscoUnifiedJTAPI support Method names Class names Yes getMediaCause MediaEv MediaTermConnAvailableEv Yes getDtmfDigit MediaTermConnDtmfEv Yes MediaTermConnEv getMediaState MediaTermConnStateEv MediaTermConnUnavailableEv Unsupported Packages The following table shows the JTAPI packages that are not supported by the Cisco Unified JTAPI implementation. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1622 Cisco Unified JTAPI Classes and Interfaces Media Capabilities Package

Page 1686 diagram

Page 1687

Unsupported JTAPI packages JTAPI Phone Package JTAPI Phone Capabilities Package JTAPI Phone Events Package JTAPI Private Data Package JTAPI Private Data Capabilities Package JTAPI Private Data Events Package Cisco Unified JTAPI Extension Classes and Interfaces Cisco Unified JTAPI Extension Classes Table 356: Cisco Unified JTAPI Extension Classes Method names Cisco extension classes getMaxFramesPerPacket() getPayloadType() toString() CiscoMediaCapability CiscoG711MediaCapability getBitRate() toString() CiscoG723MediaCapability CiscoGSMMediaCapability RegistrationException UnregistrationException Cisco Unified JTAPI Extension Interfaces Table 357: Cisco Unified JTAPI Extension Interfaces and Their Methods Method names Cisco extension interfaces getAddress() CiscoAddrCreatedEv getType() CiscoAddress Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1623 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Extension Classes and Interfaces

Page 1687 diagram

Page 1688

Method names Cisco extension interfaces CiscoAddressObserver CiscoAddrEv CiscoAddrInService CiscoAddrOutOfService getCallID() CiscoCall CiscoCallEv getCall() intValue() CiscoCallID getConferenceCall() getFinalCall() getHeldConferenceController() getTalkingConferenceController() CiscoConferenceEndEv getConferenceCall() getFinalCall() getHeldConferenceController() getTalkingConferenceController() CiscoConferenceStartEv getConnectionID() getReason() redirect(String destinationAddress, int mode, int callingSearchSpace, int calledAddressOption, String preferredOriginalCalledParty, String facCode, String cmcCode, int featurePriority, byte[] applicationXMLData) CiscoConnection getConnection() intValue() CiscoConnectionID getConsultingTerminalConnection() CiscoConsultCall getHeldTerminalConnection() CiscoConsultCallActiveEv CiscoEv CiscoJtapiPeer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1624 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1688 diagram

Page 1689

Method names Cisco extension interfaces getRTPInputProperties() getRTPOutputProperties() register(InetAddress, int) unregister() CiscoMediaTerminal CiscoProvEv getCallbackGuardEnabled() getMediaTerminal() getMediaTerminals() setCallbackGuardEnabled() getRemoteTerminals() getRemoteTerminal(String name) CiscoProvider CiscoProvConnToLeastPriorCtiServerEv CiscoProvFallbackToPrimNwCompltdEv getReachableCtiServers() CiscoProvPrimNwReachableEv CiscoProviderObserver getTerminal() getRemoteDestinations() isMyAppLastToSetActiveRD() getIPAddressingMode() getIPV4Address() getIPV6Address() CiscoProvTerminalRemoteDestinationChangedEv getRecordingType() CiscoRecorderInfo getRemoteDestinationName() getRemoteDestinationNumber() getIsActiveRD() CiscoRemoteDestinationInfo Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1625 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1689 diagram

Page 1690

Method names Cisco extension interfaces getAllRemoteDestinations() getActiveRemoteDestinations() setActiveRemoteDestination(String remoteDestinationNumber, boolean isActiveRD) addRemoteDestination(String remoteDestinationName, String remoteDestinationNumber, boolean isActiveRD) removeRemoteDestination(String remoteDestinationNumber) removeAllRemoteDestinations() updateRemoteDestinationName(StringremoteDestinationNumber, String remoteDestinationName) updateRemoteDestinationNumber(String remoteDestinationNumber, StringnewRemoteDestinationNumber) updateRemoteDestination(String remoteDestinationNumber, String remoteDestinationName, String newRemoteDestinationNumber, boolean isActiveRD) isRegisteredByThisApp() Cisco Extend & Connect (CTI Remote Device) getRegistrationType() isMyAppLastToSetActiveRD() CiscoRemoteTerminal getCall() selectRoute(String[] routeSelected, int callingSearchSpace, String[] modifyingCallingNumber, String[] preferedOriginalCalledNumber, int[] preferedOriginalCalledOption, String[] facCode, String[] cmcCode, int featurePriority, byte[][] applicationXMLData) CiscoRouteSession getBitRate() getEchoCancellation() getLocalAddress() getLocalPort() getPacketSize() getPayloadType() CiscoRTPInputProperties getRTPInputProperties() CiscoRTPInputStartedEv CiscoRTPInputStoppedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1626 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1690 diagram

Page 1691

Method names Cisco extension interfaces getBitRate() getMaxFramesPerPacket() getPacketSize() getPayloadType() getPrecedenceValue() getRemoteAddress() getRemotePort() CiscoRTPOutputProperties getRTPOutputProperties() CiscoRTPOutputStartedEv CiscoRTPOutputStoppedEv CiscoSynronousObserver getTerminal() CiscoTermCreatedEv CiscoTermEv getRegistrationState() register() unregister() getType() getTypeName() CiscoTerminal startRecording(int playToneDirection, int invocationType) stopRecording(int invocationType) CiscoTerminalConnection CiscoTerminalObserver CiscoTermInServiceEv CiscoTermOutOfServiceEv getFinalCall() getTransferController() getTransferredCall() CiscoTransferEndEv getFinalCall() getTransferController() getTransferredCall() CiscoTransferStartEv getObject() setObject() ObjectContainer Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1627 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1691 diagram

Page 1692

Method names Cisco extension interfaces RTPBitRate RTPPayload Cisco Trace Logging Classes and Interfaces Cisco Trace Logging Classes Table 358: Cisco Trace Logging Classes Method names Cisco Trace Logging class close() flush() getCurrentFile() getFileExtension() getFileNameBase() getMaxFiles() getMaxFileSize() write(byte[], int, int) write(int) LogFileOutputStream close() flush() getEnabled() print(String) println(String) NullTraceWriter close() flush() getEnabled() print(String) println(String) setOutputStream(OUputStream OutputStreamTraceWriter Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1628 Cisco Unified JTAPI Classes and Interfaces Cisco Trace Logging Classes and Interfaces

Page 1692 diagram

Page 1693

Method names Cisco Trace Logging class getModules() registerModule(String) registerModule(TraceModule) registerModule(TraceModule, OutputStream) TraceManagerFactory Cisco Trace Logging Interfaces Table 359: Cisco Trace Logging Interfaces Method names Cisco Trace Logging interfaces disable() enable() ConditionalTrace append(Object) append(String) getName() isEnabled() print(Object) print(String) print(String, Object) print(String, String) println(Object) println(String) println(String, Object) println(String, String) setDefaultMnemonic(String) Trace Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1629 Cisco Unified JTAPI Classes and Interfaces Cisco Trace Logging Interfaces

Page 1693 diagram

Page 1694

Method names Cisco Trace Logging interfaces disableAll() disableTimeStamp() enableAll() enableTimeStamp() getConditionalTrace(String) getConditionalTrace(String, String) getName() getOutputStream() getSubFacilities() getTraces() getTraceWriter() getUnconditionalTrace(String) getUnconditionalTrace(String, String) removeTrace(String) removeTrace(Trace) setOutputStream(OutputStream) setSubFacilities() setTraceWriter() TraceManager getTraceManager() getTraceModuleName() TraceModule TRACETYPE close() flush() getEnabled() print(String) println(String) TraceWriter UnconditionalTrace Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1630 Cisco Unified JTAPI Classes and Interfaces Cisco Unified JTAPI Classes and Interfaces

Page 1694 diagram

Page 1695

A P P E N D I X C Troubleshooting Cisco Unified JTAPI This appendix contains CTI Error Codes, CiscoEvent IDs, and other information to assist with troubleshooting efforts. • CTI Error Codes, on page 1631 • CiscoEventIDs, on page 1641 • Reason Codes, on page 1645 • Cause Codes, on page 1646 • Additional Troubleshooting Information, on page 1651 CTI Error Codes Description Error code This error indicates that the request is issued on a line, which is not open ASSOCIATED_LINE_NOT_OPEN This error indicates that another call already exists on the line CALL_ALREADY_EXISTS The call dropped after the feature request (hold, unhold, transfer, or conference) but before the request was completed. CALL_DROPPED 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 This error indicates that attempt to redirect call that was unknown to line control CALLHANDLE_UNKNOWN_TO_LINECONTROL This error indicates that device open failed because the associated device is unregistering CANNOT_OPEN_DEVICE 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 This error indicates that attempt to set CFWALL while it is already set CFWDALL_ALREADY_SET Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1631

Image 1 from page 1695

Page 1695 diagram

Page 1696

Description Error code This error indicates that attempt to CFWALL to an invalid destination CFWDALL_DESTN_INVALID This error indicates that link to one of the cisco unified communications managers failed in the cluster (network error) CLUSTER_LINK_FAILURE This error indicates that device does not support the command. COMMAND_NOT_IMPLEMENTED_ON_DEVICE This error indicates that attempt to conference a party that is already in conference CONFERENCE_ALREADY_PRESENT This error indicates that conference completion was not successful. CONFERENCE_FAILED This error indicates that all conference bridges are busy. CONFERENCE_FULL This error indicates that attempt to complete conference while consult conference is not active CONFERENCE_INACTIVE This error indicates that an attempt to conference to self or an invalid participant CONFERENCE_INVALID_PARTICIPANT This error indicates that the access to device is denied. CTIERR_ACCESS_TO_DEVICE_DENIED This error indicates that the application softkeys are already controlled by another application CTIERR_APP_SOFTKEYS_ALREADY_CONTROLLED This error indicates that application data size has exceeded limit CTIERR_APPLICATION_DATA_SIZE_EXCEEDED This error indicates built in bridge is not configured CTIERR_BIB_NOT_CONFIGURED This error indicates that built in bridge resource not available CTIERR_BIB_RESOURCE_NOT_AVAILABLE This error indicates that Communications Manager is not available currently CTIERR_CALL_MANAGER_NOT_AVAILABLE This error indicates that call does not exist CTIERR_CALL_NOT_EXISTED This error indicates no call park DN CTIERR_CALL_PARK_NO_DN This error indicates call request already outstanding CTIERR_CALL_REQUEST_ALREADY_OUTSTANDING This error indicates that call unpark did not succeed CTIERR_CALL_UNPARK_FAILED This error indicates that capabilities do not match CTIERR_CAPABILITIES_DO_NOT_MATCH This error indicates that the close delay is not supported with this registration type CTIERR_CLOSE_DELAY_NOT_SUPPORTED_WITH_REG_TYPE This error indicates that conference already exists CTIERR_CONFERENCE_ALREADY_EXISTED This error indicates that conference does not exist CTIERR_CONFERENCE_NOT_EXISTED This error indicates application is trying to connect to invalid port CTIERR_CONNECTION_ON_INVALID_PORT Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1632 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1696 diagram

Page 1697

Description Error code This error indicates consult call failure CTIERR_CONSULT_CALL_FAILURE This error indicates that consult call already outstanding CTIERR_CONSULTCALL_ALREADY_OUTSTANDING This error indicates that there is an issue with creating a persistent call. CTIERR_CREATE_PERSISTENT_CALL_FAILED This error indicates that device registration failed as device crypto algorithms does not match with current device registration CTIERR_CRYPTO_CAPABILITY_MISMATCH This error indicates that CTIHandler process creation failed CTIERR_CTIHANDLER_PROCESS_CREATION_FAILED This error indicates DB initialization error CTIERR_DB_INITIALIZATION_ERROR This error indicates that device is already opened CTIERR_DEVICE_ALREADY_OPENED Device registration failed as device is already registered in Non-Extend mode. CTIERR_DEVICE_ALREADY_REGISTERED_NONEXTEND This error indicates that device is not yet opened CTIERR_DEVICE_NOT_OPENED_YET This error indicates that there is a device registration failure CTIERR_DEVICE_OWNER_ALIVE_TIMER_STARTED 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 This error indicates that the device is restricted CTIERR_DEVICE_RESTRICTED This error indicates that device is shutting down CTIERR_DEVICE_SHUTTING_DOWN This error indicates that there is a directory login time out CTIERR_DIRECTORY_LOGIN_TIMEOUT This error indicates that the request to disconnect the persistent call failed because there is an active customer call. Only when there are no active calls present, can the persistent call be disconnected. CTIERR_DISCONNECT_PERSISTENT_CALL_FAILED_ CALL_ACTIVE This error indicates duplicate call reference CTIERR_DUPLICATE_CALL_REFERENCE Duplicated Remote Destination Number with an existing Remote Destination Number. CTIERR_DUPLICATE_REMOTE_DESTINATION_NUMBER This indicates registration failure when Cisco Media/Route Tterminal is already registered with different Addressing mode CTIERR_DYNREG_IPADDRMODE_MISMATCH Enduser is not associated with the device. CTIERR_ENDUSER_NOT_ASSOCIATED_WITH_DEVICE Client Matter Code (CMC) entered is invalid CTIERR_FAC_CMC_REASON_CMC_INVALID CMC is required to offer the call CTIERR_FAC_CMC_REASON_CMC_NEEDED Forced Authorization Code (FAC) and CMC are required to offer call CTIERR_FAC_CMC_REASON_FAC_CMC_NEEDED Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1633 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1697 diagram

Page 1698

Description Error code FAC entered is invalid CTIERR_FAC_CMC_REASON_FAC_INVALID FAC is required to offer the call CTIERR_FAC_CMC_REASON_FAC_NEEDED This error indicates feature already registered CTIERR_FEATURE_ALREADY_REGISTERED This error indicates feature data reject CTIERR_FEATURE_DATA_REJECT This error indicates that feature select failed CTIERR_FEATURE_SELECT_FAILED This error indicates that the device type is illegal CTIERR_ILLEGAL_DEVICE_TYPE This error indicates that auto install protocol version is incompatible CTIERR_INCOMPATIBLE_AUTOINSTALL_PROTOCOL_ VERSION This error indicates that device registration failed due to incorrect media capability CTIERR_INCORRECT_MEDIA_CAPABILITY This error indicates that information is not available CTIERR_INFORMATION_NOT_AVAILABLE 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 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 This error indicates that intercomm request failed as intercom target value in not in the intercom group CTIERR_INTERCOM_SPEEDDIAL_DESTN_INVALID This error indicates that intercom talk back request is already pending CTIERR_INTERCOM_TALKBACK_ALREADY_PENDING This error indicates that talkback request failed for some reason CTIERR_INTERCOM_TALKBACK_FAILURE This error indicates there is a CTI internal failure CTIERR_INTERNAL_FAILURE This error indicates the call ID is invalid CTIERR_INVALID_CALLID This error indicates that the device name is not valid CTIERR_INVALID_DEVICE_NAME Play DTMF request failed because it is an invalid DTMF digit CTIERR_INVALID_DTMFDIGITS This error indicates that filter size is invalid CTIERR_INVALID_FILTER_SIZE This error indicates that the media device is not valid CTIERR_INVALID_MEDIA_DEVICE This error indicates media parameter is invalid CTIERR_INVALID_MEDIA_PARAMETER This error indicates that there is an invalid media process CTIERR_INVALID_MEDIA_PROCESS This error indicates media resource ID is not valid CTIERR_INVALID_MEDIA_RESOURCE_ID This error indicates that the header info is not valid CTIERR_INVALID_MESSAGE_HEADER_INFO Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1634 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1698 diagram

Page 1699

Description Error code This error indicates that message length is invalid CTIERR_INVALID_MESSAGE_LENGTH This error indicates monitoring request failed due to invalid monitoring destination CTIERR_INVALID_MONITOR_DESTN This error indicates an invalid monitor DN type CTIERR_INVALID_MONITOR_DN_TYPE This error indicates monitor request failed due to an invalid monitor mode CTIERR_INVALID_MONITORMODE This error indicates that the parameter is not valid CTIERR_INVALID_PARAMETER This error indicates that the DN is an invalid park DN CTIERR_INVALID_PARK_DN This error indicates that the handle is an invalid park registration handle CTIERR_INVALID_PARK_REGISTRATION_HANDLE This error indicates that a persistent call already exists. CTIERR_PERSISTENT_CALL_EXISTS This error indicates an Invalid Remote Destination Name. CTIERR_INVALID_REMOTE_DESTINATION_NAME This error indicates an Invalid Remote Destination Number. CTIERR_INVALID_REMOTE_DESTINATION_NUMBER This error indicates an invalid resource type CTIERR_INVALID_RESOURCE_TYPE This indicates the registration failure due to IP Addressing Mode mismatch. CTIERR_IPADDRMODE_MISMATCH This error indicates that line is out of service. CTIERR_LINE_OUT_OF_SERVICE This er ror indicates that the line is restricted CTIERR_LINE_RESTRICTED This error indicates that maximum call limit has reached CTIERR_MAXCALL_LIMIT_REACHED This error indicates that device registration failed as device is registered with Dynamic media termination CTIERR_MEDIA_ALREADY_TERMINATED_DYNAMIC Device registration failed as device is already registered in Extend mode. CTIERR_MEDIA_ALREADY_TERMINATED_EXTEND This error indicates that device registration failed as device is already registered with media termination none CTIERR_MEDIA_ALREADY_TERMINATED_NONE This error indicates that device registration failed as device is registered with Static media termination CTIERR_MEDIA_ALREADY_TERMINATED_STATIC This error indicates that device registration failed as media capability of device does not match with current device registration CTIERR_MEDIA_CAPABILITY_MISMATCH This error indicates that media resource name size has exceeded limit CTIERR_MEDIA_RESOURCE_NAME_SIZE_EXCEEDED This error indicates that media registration types do not match CTIERR_MEDIAREGISTRATIONTYPE_DO_NOT_MATCH Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1635 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1699 diagram

Page 1700

Description Error code This error indicates that message is too big CTIERR_MESSAGE_TOO_BIG This error indicates that there are more active calls than reserved CTIERR_MORE_ACTIVE_CALLS_THAN_RESERVED This error indicates there are no existing calls CTIERR_NO_EXISTING_CALLS This error indicates that there is no existing conference CTIERR_NO_EXISTING_CONFERENCE This error indicates recording request failed as there is no recording session CTIERR_NO_RECORDING_SESSION This error indicates no response from media resource CTIERR_NO_RESPONSE_FROM_MP This error indicates that the call is not preserved CTIERR_NOT_PRESERVED_CALL This error indicates that feature unavailable for this call due to temporary failure CTIERR_OPERATION_FAILED_QUIETCLEAR This error indicates that this operation is not allowed CTIERR_OPERATION_NOT_ALLOWED This indicates that the specified operation is not allowed on a persistent call. CTIERR_OPERATION_NOT_ALLOWED_ON_ PERSISTENT_CALL This error indicates out of bandwidth error CTIERR_OUT_OF_BANDWIDTH This error indicates a failure during registering the device CTIERR_OWNER_NOT_ALIVE This error indicates that there is a pending accept or answer request CTIERR_PENDING_ACCEPT_OR_ANSWER_REQUEST This error indicates there is a pending start monitoring request CTIERR_PENDING_START_MONITORING_REQUEST This error indicates there is a pending start recording request CTIERR_PENDING_START_RECORDING_REQUEST This error indicates there is a pending stop recording request CTIERR_PENDING_STOP_RECORDING_REQUEST This error indicates that the request failed because a persistent call is already being set up. CTIERR_PERSISTENT_CALL_BEING_SETUP This error indicates that primary call in monitoring request in invalid or gone idle CTIERR_PRIMARY_CALL_INVALID This error indicates that primary call in monitoring request is in invalid state CTIERR_PRIMARY_CALL_STATE_INVALID This error indicates recording request failed that recording is already in progress CTIERR_RECORDING_ALREADY_INPROGRESS This error indicates recording configuration does not match CTIERR_RECORDING_CONFIG_NOT_MATCHING Stop recording failed because the recording invocation type did not match. CTIERR_RECORDING_INVOCATION_TYPE_NOT_MATCHING This error indicates recording request failed because recording session is inactive CTIERR_RECORDING_SESSION_INACTIVE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1636 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1700 diagram

Page 1701

Description Error code This error indicates a redirect unauthorized command usage CTIERR_REDIRECT_UNAUTHORIZED_COMMAND_USAGE This error indicates that register feature activation failed CTIERR_REGISTER_FEATURE_ACTIVATION_FAILED Register feature application was already registered CTIERR_REGISTER_FEATURE_APP_ALREADY_REGISTERED Register feature provider was not registered. CTIERR_REGISTER_FEATURE_PROVIDER_NOT_REGISTERED The active remote destination is not set. CTIERR_REMOTE_DEVICE_REQUEST_FAILED_ ACTIVE_RD_NOT_SET The number of Remote Destinations has exceeded the max number limit. CTIERR_REMOTEDESTINATION_LIMIT_EXCEEDED This error indicates that resource is not available to fulfill the request CTIERR_RESOURCE_NOT_AVAILABLE This error indicates that start monitoring request failed CTIERR_START_MONITORING_FAILED This error indicates that start recording request failed CTIERR_START_RECORDING_FAILED This error indicates that there is a station shutdown CTIERR_STATION_SHUT_DOWN This error indicates CTI system error CTIERR_SYSTEM_ERROR This error indicates UDP data passthrough not supported CTIERR_UDP_PASS_THROUGH_NOT_SUPPORTED This error indicates an unknown exception occured CTIERR_UNKNOWN_EXCEPTION This error indicates that call park type is not supported CTIERR_UNSUPPORTED_CALL_PARK_TYPE This error indicates that the call forward type is unsupported CTIERR_UNSUPPORTED_CFWD_TYPE This error indicates user is not authorized for secure connection CTIERR_USER_NOT_AUTH_FOR_SECURITY This error indicates that there is an internal call processing error: DaRes invalid request type DARES_INVALID_REQ_TYPE This error indicates that XML data object size is bigger than allowed. DATA_SIZE_LIMIT_EXCEEDED This error indicates that the device query contained an illegal device type DB_ERROR This error indicates illegal device type in DB DB_ILLEGAL_DEVICE_TYPE This error is no longer used. DB_NO_MORE_DEVICES This error indicates that destination is busy DESTINATION_BUSY This error indicates that destination is not found DESTINATION_UNKNOWN This error indicates that device registration attempt failed, because the device is already registered DEVICE_ALREADY_REGISTERED Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1637 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1701 diagram

Page 1702

Description Error code 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 This error indicates that device is out of service. DEVICE_OUT_OF_SERVICE This error indicates that digit generation is already in progress. DIGIT_GENERATION_ALREADY_IN_PROGRESS This error indicates that call state is invalid to continue. DIGIT_GENERATION_CALLSTATE_CHANGED This error indicates that call handle is invalid and call may be gone. DIGIT_GENERATION_WRONG_CALL_HANDLE This error indicates that call state is not valid to generate digits. DIGIT_GENERATION_WRONG_CALL_STATE This error indicates that directory login failed: directory not initialized DIRECTORY_LOGIN_FAILED This error indicates that directory login failed DIRECTORY_LOGIN_NOT_ALLOWED This error indicates that directory is temporarily unavailable. DIRECTORY_TEMPORARY_UNAVAILABLE This error indicates that there is already a device controlling media. EXISTING_FIRSTPARTY This error indicates that the hold was rejected by line control or call control layers HOLDFAILED This error indicates that an attempt was made to originate call using a calling party that is not on the device ILLEGAL_CALLINGPARTY This error indicates line is not in a legal state to invoke the request ILLEGAL_CALLSTATE This error indicates the handle is not valid ILLEGAL_HANDLE This error indicates that there is a QBE protocol error ILLEGAL_MESSAGE_FORMAT This error indicates that JTAPI and CTI versions are not compatible : CTI Error Protocol version not supported INCOMPATIBLE_PROTOCOL_VERSION This error indicates that attempt to perform a line operation on an invalid line handle. INVALID_LINE_HANDLE This error indicates that the ring option is invalid INVALID_RING_OPTION This error indicates that line is greater than the maximum available lines on this device LINE_GREATER_THAN_MAX_LINE This error indicates that line information does not exist in the database. LINE_INFO_DOES_NOT_EXIST This error indicates that internal error returned from call control. LINE_NOT_PRIMARY This error indicates line control refuses to allow a new call to be initiated because of its current state. LINECONTROL_FAILURE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1638 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1702 diagram

Page 1703

Description Error code The maximum number of CTI connections was reached. MAX_NUMBER_OF_CTI_CONNECTIONS_REACHED This error indicates that attempt to set message waiting lamp for an invalid DN; Message Waiting Destination not found. MSGWAITING_DESTN_INVALID This error indicates there is no active device for thirdparty NO_ACTIVE_DEVICE_FOR_THIRDPARTY This error indicates that no conference bridge available NO_CONFERENCE_BRIDGE This error indicates that attempt is made to open a provider before CTI initialization completes NOT_INITIALIZED Internal error returned from call control PROTOCOL_TIMEOUT This error indicates that an attempt is made to reopen provider PROVIDER_ALREADY_OPEN This error indicates an attempt to close provider while it is already closed PROVIDER_CLOSED This error indicates that device list incomplete or device list query timeout or query aborted PROVIDER_NOT_OPEN This error indicates that internal error is returned from call control REDIRECT_CALL_CALL_TABLE_FULL This error indicates that the redirect destination is busy REDIRECT_CALL_DESTINATION_BUSY This error indicates that redirect destination is out of order REDIRECT_CALL_DESTINATION_OUT_OF_ORDER This error indicates a digit analyss time out, this is an internal error returned from call control REDIRECT_CALL_DIGIT_ANALYSIS_TIMEOUT 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 This error indicates that internal error is returned from call control REDIRECT_CALL_INCOMPATIBLE_STATE This error indicates media connection failure, this is an internal error returned from call control REDIRECT_CALL_MEDIA_CONNECTION_FAILED This error indicates that redirect failed because of normal call clearing REDIRECT_CALL_NORMAL_CLEARING This error indicates that far end hung up on the call being redirected REDIRECT_CALL_ORIGINATOR_ABANDONED This error indicates that internal error is returned from call control REDIRECT_CALL_PARTY_TABLE_FULL This error indicates that internal error is returned from call control REDIRECT_CALL_PENDING_REDIRECT_TRANSACTION This error indicates a protocol error, this is an internal error returned from call control REDIRECT_CALL_PROTOCOL_ERROR This error indicates that an attempt is made to redirect to an unknown destination REDIRECT_CALL_UNKNOWN_DESTINATION Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1639 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1703 diagram

Page 1704

Description Error code This error indicates that internal error is returned from call control REDIRECT_CALL_UNKNOWN_ERROR This error indicates an unknown party is detected, this is an internal error returned from call control REDIRECT_CALL_UNKNOWN_PARTY This error indicates that internal error is returned from call control REDIRECT_CALL_UNRECOGNIZED_MANAGER This error indicates that internal error is returned from call control REDIRECT_CALLINFO_ERR This error indicates that internal error is returned from call control REDIRECT_ERR This error indicates that retrieval of call was rejected by line control or call control RETRIEVEFAILED 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 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 This error indicates that the request has timed out. TIMEOUT This error indicates that attempt to complete transfer, while consult tranfer is not there TRANSFER_INACTIVE This error indicates that the transfer failed probably because one of the call legs was hung up or disconnected from the far end TRANSFERFAILED This error indicates that expected response from call control not received during a transfer TRANSFERFAILED_CALLCONTROL_TIMEOUT This error indicates that an attempt is made to transfer call to a busy destination TRANSFERFAILED_DESTINATION_BUSY This error indicates an attempt is made to to transfer call to a directory number that is not registered TRANSFERFAILED_DESTINATION_UNALLOCATED This error indicates that existing transfer is still in progress TRANSFERFAILED_OUTSTANDING_TRANSFER This error indicates that the line that was specified, is not found on the device UNDEFINED_LINE This error indicates that the global call handle is unknown UNKNOWN_GLOBAL_CALL_HANDLE This error indicates that there is a QBE protocol error UNRECOGNIZABLE_PDU This error indicates that an unspecified error has occurred. UNSPECIFIED Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1640 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1704 diagram

Page 1705

CiscoEventIDs This section includes the following events: • Provider Events, on page 1641 • Terminal Events, on page 1642 • Address Events, on page 1642 • Call Events, on page 1643 • RTP Events, on page 1644 • TermConn Events, on page 1644 Provider Events Event number Event name 0x40000008 CiscoProvFeatureUnRegisteredEv 0x40000009 CiscoRestrictedEv 0x40000010 CiscoAddrRestrictedEv 0x40000011 CiscoTermRestrictedEv 0x40000012 CiscoAddrActivatedEv 0x40000013 CiscoTermActivatedEv 0x40000014 CiscoAddrActivatedOnTerminalEv 0x40000015 CiscoAddrRestrictedOnTerminalEv 0x40000016 CiscoProviderCapabilityChangedEv 0x40000017 CiscoProvTerminalCapabilityChangedEv 0x40000018 CiscoProvTerminalRegisteredEv 0x40000019 CiscoProvTerminalUnRegisteredEv 0x40000020 CiscoProvTerminalRemoteDestinationChangedEv 0x40000021 CiscoProvTerminalIPAddressChangedEv 0x40000022 CiscoProvTerminalMultiMediaCapabilityChangedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1641 Troubleshooting Cisco Unified JTAPI CiscoEventIDs

Page 1705 diagram

Page 1706

Terminal Events Event number Event name 0x40001001 CiscoTermCreatedEv 0x40001002 CiscoTermDataEv 0x40001003 CiscoTermInServiceEv 0x40001004 CiscoTermOutOfServiceEv 0x40001005 CiscoTermRemovedEv 0x40001006 CiscoTermDeviceActiveStatusEv 0x40001007 CiscoTermDeviceAlertingStatusEv 0x40001008 CiscoTermDeviceHoldStatusEv 0x40001009 CiscoTermDeviceIdleStatusEv 0x40001010 CiscoTermButtonPressedEv 0x40001011 CiscoTermRegistraionFailedEv 0x40001014 CiscoTermDNDStatusChangedEv 0x40001015 CiscoTermDeviceStateWhisperEv 0x40001016 CiscoTermDNDOptionChangedEv 0x40001017 CiscoMultiMediaStreamsInfoEv Address Events Event number Event name 0x40002001 CiscoAddrCreatedEv 0x40002002 CiscoAddrInServiceEv 0x40002003 CiscoAddrOutOfServiceEv 0x40002004 CiscoAddrRemovedEv 0x40002005 CiscoOutOfServiceEv 0x40002006 CiscoAddrAddedToTerminalEv 0x40002007 CiscoAddrRemovedFromTerminalEv 0x40002008 CiscoAddrAutoAcceptStatusChangedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1642 Troubleshooting Cisco Unified JTAPI Terminal Events

Page 1706 diagram

Page 1707

Event number Event name 0x40002009 CiscoAddrIntercomInfoChangedEv 0x40002010 CiscoAddrIntercomInfoRestorationFailedEv 0x40002011 CiscoAddrRecordingConfigChangedEv 0x40002012 CiscoAddrParkStatusEv 0x40002013 CiscoAddrVoiceMailPilotChangedEv 0x40002014 CiscoAddrPickupGroupChangedEv 0x4000200A CiscoAddrMonitoringTerminatedEv Call Events Event number Event name 0x40003001 CiscoProvCallParkEv 0x40003002 CiscoConferenceEndEv 0x40003003 CiscoConferenceStartEv 0x40003004 CiscoConsultCallActiveEv 0x40003005 CiscoTransferEndEv 0x40003006 CiscoTransferStartEv 0x40003007 CiscoToneChangedEv 0x40003008 CiscoCallChangedEv 0x40003009 CiscoConferenceChainAddedEv 0x40003010 CiscoConferenceChainRemovedEv 0x40003011 CiscoCallSecurityStatusChangedEv 0x40003012 CiscoCallFeatureCancelledEv 0x40003013 CiscoProvPickupCallAlertEv 0x40003014 CiscoProvPickupNotificationRegistrationClosedEv 0x40003015 CiscoCallInfoChangedEv 0x40003016 CiscoProvAuthenticationInfoEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1643 Troubleshooting Cisco Unified JTAPI Call Events

Page 1707 diagram

Page 1708

RTP Events Event number Event name 0x40004001 CiscoRTPInputStartedEv 0x40004002 CiscoRTPInputStoppedEv 0x40004003 CiscoRTPOutputStartedEv 0x40004004 CiscoRTPOutputStoppedEv 0x40004005 CiscoMediaOpenLogicalChannelEv 0x40004006 CiscoRTPInputKeyEv 0x40004007 CiscoRTPOutputKeyEv 0x40004008 CiscoMediaOpenIPPortEv TermConn Events Event number Event name 0x40005001 CiscoTermConnPrivacyChangedEv 0x40005002 CiscoCallCtlTermConnHeldReversionEv 0x40005003 CiscoTermConnSelectChangedEv 0x40005004 CiscoTermConnRecordingStartEv 0x40005005 CiscoTermConnRecordingEndEv 0x4000500E CiscoTermConnRecordingFailedEv 0x40005006 CiscoTermConnMonitoringStartEv 0x40005007 CiscoTermConnMonitoringEndEv 0x40005008 CiscoTermConnRecordingTargetInfoEv 0x40005009 CiscoTermConnMonitorInitiatorInfoEv 0x4000500A CiscoTermConnMonitorTargetInfoEv 0x4000500B CiscoTermConnMonitorUpdatedEv 0x4000500C CiscoMediaStreamStartedEv 0x4000500D CiscoMediaStreamEndedEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1644 Troubleshooting Cisco Unified JTAPI RTP Events

Page 1708 diagram

Page 1709

Conn Events Event number Event name 0x40006001 CiscoConnectionUniqueIDChangedEv 0x40006002 CiscoHuntConnCreatedEv Reason Codes The following codes are defined in CiscoFeatureReason interface. Reason code Reason code name 2 REASON_TRANSFER 3 REASON_FORWARDNOANWSER 4 REASON_FORWARDBUSY 5 REASON_FORWARDALL 6 REASON_REDIRECT 7 REASON_BLINDTRANSFER 9 REASON_CONFERENCE 10 REASON_PARK 11 REASON_CALLPICKUP 12 REASON_NORMAL 15 REASON_PARKREMINDER 16 REASON_UNPARK 20 REASON_BARGE 21 REASON_IMMDIVERT 22 REASON_FAC_CMC 23 REASON_QSIG_PR 24 REASON_REFER 25 REASON_REPLACE 26 REASON_CCM_REDIRECTION 27 REASON_DPARK_CALLPARK Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1645 Troubleshooting Cisco Unified JTAPI Conn Events

Page 1709 diagram

Page 1710

Reason code Reason code name 28 REASON_DPARK_REVERSION 29 REASON_DPARK_UNPARK 31 REASON_SILENTMONITORING 33 REASON_MOBILITY 34 REASON_MOBILITY_IVR 35 REASON_MOBILITY_CELLPICKUP 36 REASON_MOBILITY_HANDIN 37 REASON_MOBILITY_HANDOUT 38 REASON_MOBILITY_FOLLOWME 39 REASON_CLICK_TO_CONFERENCE 40 REASON_FORWARD_NO_RETRIEVE 42 REASON_EXTERNALCALLCONTROL 43 REASON_SAF_CCD_PSTN_FAILOVER 44 REASON_MEDIA_STREAMING Cause Codes Cause code Cause code name 0X00 (0) CAUSE_NOERROR 0X01 (1) CAUSE_UNALLOCATEDNUMBER 0X02 (2) CAUSE_NOROUTETOTRANSITNET 0X03 (3) CAUSE_NOROUTETODDESTINATION 0X06 (6) CAUSE_CHANUNACCEPTABLE 0X07 (7) CAUSE_CALLBEINGDELIVERED 0X08 (8) CAUSE_CTIPREEMPTNOREUSE 0X09 (9) CAUSE_CTIPREEMPTFORREUSE 0X10 (16) CAUSE_NORMALCALLCLEARING 0X11 (17) CAUSE_USERBUSY Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1646 Troubleshooting Cisco Unified JTAPI Cause Codes

Page 1710 diagram

Page 1711

Cause code Cause code name 0X12 (18) CAUSE_NOUSERRESPONDING 0X13 (19) CAUSE_NOANSWERFROMUSER 0X14 (20) CAUSE_SUBSCRIBERABSENT 0X15 (21) CAUSE_CALLREJECTED 0X16 (22) CAUSE_NUMBERCHANGED 0X19 (25) CAUSE_EXCHANGEROUTINGERROR 0X1A (26) CAUSE_NONSELECTEDUSERCLEARING 0X1B (27) CAUSE_DDESTINATIONOUTOFORDER 0X1C (28) CAUSE_INVALIDNUMBERFORMAT 0X1D (29) CAUSE_FACILITYREJECTED 0X1E (30) CAUSE_RESPONSETOSTATUSENQUIRY 0X1F (31) CAUSE_NORMALUNSPECIFIED 0X22 (34) CAUSE_NOCIRCAVAIL 0X26 (38) CAUSE_NETOUTOFORDER 0X29 (41) CAUSE_TEMPORARYFAILURE 0X2A (42) CAUSE_SWITCHINGEQUIPMENTCONGESTION 0X2B (43) CAUSE_ACCESSINFORMATIONDISCARDED 0X2C (44) CAUSE_REQCIRCNAVIL 0X2E (46) CAUSE_CTIPRECEDENCECALLBLOCKED 0X2F (47) CAUSE_RESOURCESNAVAIL 0X31 (49) CAUSE_QUALOFSERVNAVAIL 0X32 (50) CAUSE_REQFACILITYNOTSUBSCRIBED 0X35 (53) CAUSE_SERVOPERATIONVIOLATED 0X36 (54) CAUSE_INCOMINGCALLBARRED 0X39 (57) CAUSE_BCNAUTHORIZED 0X3A (58) CAUSE_BCBPRESENTLYAVAIL 0X3F (63) CAUSE_SERVNOTAVAILUNSPECIFIED 0X41 (65) CAUSE_BEARERCAPNIMPL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1647 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1711 diagram

Page 1712

Cause code Cause code name 0X42 (66) CAUSE_CHANTYPENIMPL 0X45 (69) CAUSE_REQFACILITYNIMPL 0X46 (70) CAUSE_ONLYRDIVEARERCAPAVAIL 0X4F (79) CAUSE_SERVOROPTNAVAILORIMPL 0X51 (81 ) CAUSE_INVALIDCALLREFVALUE 0X52 (82) CAUSE_IDENTIFIEDCHANDOESNOTEXIST 0X53 (83) CAUSE_SUSPCALLBUTNOTTHISONE 0X54 (84) CAUSE_CALLIDINUSE 0X55 (85) CAUSE_NOCALLSUSPENDED 0X56 (86) CAUSE_REQCALLIDHASBEENCLEARED 0X58 (88) CAUSE_INCOMPATABLEDDESTINATION 0X5A (90) CAUSE_DESTNUMMISSANDDCNOTSUB 0X5B (91) CAUSE_INVALIDTRANSITNETSEL 0X5F (95) CAUSE_INVALIDMESSAGEUNSPECIFIED 0X60 (96) CAUSE_MANDATORYIEMISSING 0X61 (97) CAUSE_MSGTYPENIMPL 0X62 (98) CAUSE_MSGTYPENCOMPATWCS 0X63 (99) CAUSE_IENIMPL 0X64 (100) CAUSE_INVALIDIECONTENTS 0X65 (101) CAUSE_MSGNCOMPATABLEWCS 0X66 (102) CAUSE_RECOVERYONTIMEREXPIRY 0X6F (111) CAUSE_PROTOCOLERRORUNSPECIFIED 0X7A (122) CAUSE_CTIPRECEDENCELEVELEXCEEDED 0X7B (123) CAUSE_CTIDEVICENOTPREEMPTABLE 0X7D (125) CAUSE_OUTOFBANDWIDTH 0X7F (127) CAUSE_INTERWORKINGUNSPECIFIED 0X81 (129) CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH 0XC9 (200) CAUSE_REDIRECTED Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1648 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1712 diagram

Page 1713

Cause code Cause code name 0X1F4 (500) CAUSE_INTERNALCAUSE 0X1F5 (501) CAUSE_OUTBOUND_TRANSFER 0X1F6 (502) CAUSE_OUTBOUND_CONFERENCE 0X1F7 (503) CAUSE_INBOUND_TRANSFER 0X1F8 (504) CAUSE_INBOUND_CONFERENCE 0X1F9 (505) CAUSE_INBOUND_BLINDTRANSFER 0x1FB (507) CAUSE_CTIMANAGER_FAILURE 0x1FC (508) CAUSE_CALLMANAGER_FAILURE 0x1FD(509) CAUSE_BARGE 0x1FE (510) CAUSE_FAC_CMC 0x1FF (511) CAUSE_QSIG_PR 0x200 (512) CAUSE_DPARK 0x201 (513) CAUSE_DPARK_UNPARK 0x202 (514) CAUSE_DPARK_REMINDER 0x203 (515) CAUSE_QUIET_CLEAR 0X40000 + CAUSE_NOERROR CAUSE_CTICONFERENCEFULL 0X60000 + CAUSE_NOERROR CAUSE_CALLSPLIT 0X70000 + CAUSE_NOERROR CAUSE_CTIDROPCONFEREE 0X1000000 + CAUSE_TEMPORARYFAILURE CAUSE_CTICCMSIP400BADREQUEST 0X2000000 + CAUSE_CALLREJECTED CAUSE_CTICCMSIP401UNAUTHORIZED 0X3000000 + CAUSE_CALLREJECTED CAUSE_CTICCMSIP402PAYMENTREQUIRED 0X4000000 + CAUSE_CALLREJECTED CAUSE_CTICCMSIP403FORBIDDEN 0X5000000 + CAUSE_UNALLOCATEDNUMBER CAUSE_CTICCMSIP404NOTFOUND 0X6000000 + CAUSE_SERVNOTAVAILUNSPECIFIED CAUSE_CTICCMSIP405METHODNOTALLOWED 0X7000000 + CAUSE_SERVOROPTNAVAILORIMPL CAUSE_CTICCMSIP406NOTACCEPTABLE 0X8000000 + CAUSE_CALLREJECTED CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED 0X9000000 + CAUSE_RECOVERYONTIMEREXPIRY CAUSE_CTICCMSIP408REQUESTTIMEOUT 0XB000000 + CAUSE_NUMBERCHANGED CAUSE_CTICCMSIP410GONE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1649 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1713 diagram

Page 1714

Cause code Cause code name 0XC000000 + CAUSE_INTERWORKINGUNSPECIFIED CAUSE_CTICCMSIP411LENGTHREQUIRED 0XE000000 + CAUSE_INTERWORKINGUNSPECIFIED CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG 0XF000000 + CAUSE_INTERWORKINGUNSPECIFIED CAUSE_CTICCMSIP414REQUESTURITOOLONG 0X10000000 + CAUSE_SERVOROPTNAVAILORIMPL CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE 0X11000000 + CAUSE_INTERWORKINGUNSPECIFIED CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME 0X15000000 + CAUSE_INTERWORKINGUNSPECIFIED CAUSE_CTICCMSIP420BADEXTENSION 0X16000000 + CAUSE_INTERWORKINGUNSPECIFIED CAUSE_CTICCMSIP421EXTENSTIONREQUIRED 0X18000000 + CAUSE_INTERWORKINGUNSPECIFIED CAUSE_CTICCMSIP423INTERVALTOOBRIEF 0X40000000 + CAUSE_NOUSERRESPONDING CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE 0X41000000 + CAUSE_TEMPORARYFAILURE CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST 0X42000000 + CAUSE_EXCHANGEROUTINGERROR CAUSE_CTICCMSIP482LOOPDETECTED 0X43000000 + CAUSE_EXCHANGEROUTINGERROR CAUSE_CTICCMSIP483TOOMANYHOOPS 0X44000000 + CAUSE_INVALIDNUMBERFORMAT CAUSE_CTICCMSIP484ADDRESSINCOMPLETE 0X45000000 + CAUSE_UNALLOCATEDNUMBER CAUSE_CTICCMSIP485AMBIGUOUS 0X46000000 + CAUSE_USERBUSY CAUSE_CTICCMSIP486BUSYHERE 0X47000000 + CAUSE_NORMALUNSPECIFIED CAUSE_CTICCMSIP487REQUESTTERMINATED 0X48000000 + CAUSE_NORMALUNSPECIFIED CAUSE_CTICCMSIP488NOTACCEPTABLEHERE 0X4B000000 + CAUSE_USERBUSY CAUSE_CTICCMSIP491REQUESTPENDING 0X4D000000 + CAUSE_USERBUSY CAUSE_CTICCMSIP493UNDECIPHERABLE 0X54000000 + CAUSE_TEMPORARYFAILURE CAUSE_CTICCMSIP500SERVERINTERNALERROR 0X55000000 + CAUSE_SERVOROPTNAVAILORIMPL CAUSE_CTICCMSIP501NOTIMPLEMENTED 0X56000000 + CAUSE_NETOUTOFORDER CAUSE_CTICCMSIP502BADGATEWAY 0X57000000 + CAUSE_TEMPORARYFAILURE CAUSE_CTICCMSIP503SERVICEUNAVAILABLE 0X58000000 + CAUSE_RECOVERYONTIMEREXPIRY CAUSE_CTICCMSIP504SERVERTIMEOUT 0X59000000 + CAUSE_INTERWORKINGUNSPECIFIED CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED 0X5A000000 + CAUSE_INTERWORKINGUNSPECIFIED CAUSE_CTICCMSIP513MESSAGETOOLARGE 0XA1000000 + CAUSE_USERBUSY CAUSE_CTICCMSIP600BUSYEVERYWHERE 0XA2000000 + CAUSE_CALLREJECTED CAUSE_CTICCMSIP603DECLINE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1650 Troubleshooting Cisco Unified JTAPI Troubleshooting Cisco Unified JTAPI

Page 1714 diagram

Page 1715

Cause code Cause code name 0XA3000000 + CAUSE_UNALLOCATEDNUMBER CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE 0XA4000000 + CAUSE_NORMALUNSPECIFIED CAUSE_CTICCMSIP606NOTACCEPTABLE 0xA5000000 + NORMALUNSPECIFIED CAUSE_CTICCMSIP200CALLCOMPLETEDELSEWHERE 0xA7000000 + SERVNOTAVAILUNSPECIFIED CAUSE_CTICCMSIP503SERVICENOTAVAILABLE Additional Troubleshooting Information Viewing JTAPI Debug Output To view JTAPI debug output, use the JTPREFS application to change the trace settings. The JTPREFS application allows you to enable or disable various kinds of tracing. JTPREFS is installed in the %SystemRoot%\java\lib directory along with the JTAPI classes. Cisco JTAPI Preferences is installed by default in Program Files\JTAPITools. To open the Cisco JTAPI Preferences utility, choose Start > Programs > Cisco JTAPI > JTAPI Preferences. The following trace levels are defined: • WARNING - warning events • INFORMATIONAL - status events • DEBUG - debugging events If DEBUG is enabled, JTPREFS allows you to enable or disable various debugging levels. The following debugging levels are defined: • TAPI_DEBUGGING - to trace JTAPI methods and events • TAPI_IMPLDEBUGGING - internal JTAPI implementation trace • CTI_DEBUGGING - to trace Cisco Unified Communications Manager events that are sent to the JTAPI implementation • CTIIMPL_DEBUGGING - internal CTICLIENT implementation trace • PROTOCOL_DEBUGGING - full CTI protocol decoding • MISC_DEBUGGING - miscellaneous low-level debug trace Traces can be directed to a specific path and folder rather than to the application directory by default. The same trace folder could be used for successive or more than one simultaneous launch of JTAPI. Different launches of JTAPI would also send the traces to different folders. This allows simultaneous JTAPI instances to maintain independent trace destinations Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1651 Troubleshooting Cisco Unified JTAPI Additional Troubleshooting Information

Page 1715 diagram

Page 1716

Traces can be directed to a specific path and folder rather than to the application directory by default. The same trace folder could be used for successive or more than one simultaneous launch of JTAPI. Different launches of JTAPI would also send traces to different folders. This allows simultaneous JTAPI instances to maintain independent trace destinations. The application directory in this case is not that of the JTAPI client itself, but of the application that is integrating/using the JTAPI client. Note Log Files for JTAPI Client Installer In order to detect the error which might occur during the installation and uninstallation process, two log files will be generated. These files will be in the same location from which the installer is executed. • ismpInstall.log – to track events during installation. • ismpUninstall.log – to track events during uninstallation. The error messages will contain the information about the wizard beans that were executed as a part of the install procedure and if there were any exceptions. Troubleshooting Tips for ISMP Installer Solution Cause Problem Description SN The uninstaller needs to be invoked from at least one level above the install directory. Directory from which uninstaller is invoked. ISMP Uninstall does not remove the target directories installed. 1 Please report this problem immediately to the support personnel to suggest the change or error in message. Locale Files not proper. Proper language details are not displayed during installation 2 The installer comes with a built in JVM which also gets installed if the target machine does not have a JVM. In case you face this error - manual removal of the files needs to be done. The JVM has been either removed or replaced with an incompatible version Uninstaller/Installer throws error. 3 Ensure that proper write permissions are there for the destination folder. This problem can occur on UNIX platforms. Permissions Installer goes through fine, but the files have not been copied. 4 Refer to the log files generated to get an idea of which step caused the error. version name problem / folder name problem. Installer/Uninstaller throws exception or crashes during the installation process. 5 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1652 Troubleshooting Cisco Unified JTAPI Log Files for JTAPI Client Installer

Image 1 from page 1716

Page 1716 diagram

Page 1717

Solution Cause Problem Description SN This file is where the current jtapi install details are located. If this is accidently removed then, upgrade/reinstall will have display issues. In the case of an upgrade/reinstall or downgrade failure, the user will have to manually remove the files from the .jtapi/bin and .jtapi/lib folders and then try the installer in order to ensure proper installation during the next time. .jtapiver.ini missing. Upgrade does not show “upgrade” message during installation of an upgrade version. 6 Unable to Create Provider Directory Login Timeout This error occurs when there is no authentication response from CTI for the ProviderOpenRequest. It could fail because of: • LDAP connectivity problems • Database delays • The CTIManager being busy for some other reason and therefore unable to honor the request The solution is that the application must try again. If the ProviderOpenRequest fails on repeated attempts, modify the ProviderOpenRequest. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1653 Troubleshooting Cisco Unified JTAPI Unable to Create Provider Directory Login Timeout

Page 1717 diagram

Page 1718

Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1654 Troubleshooting Cisco Unified JTAPI Unable to Create Provider Directory Login Timeout

Page 1718 content

Page 1719

A P P E N D I X D Cisco Unified JTAPI Operations by Release This section lists supported, unsupported, changed, and “under consideration or review” features for Cisco Unified JTAPI by Cisco Unified Communications Manager release. The details can be found in the Cisco Unified Communications Manager JTAPI Developers Guide at http://www.cisco.com/en/US/products/sw/voicesw/ps556/products\_programming\_reference\_guides\_list.html. • JTAPI Operations-by-Release, on page 1655 JTAPI Operations-by-Release Table legend: s: supported, N: not supported, M: Modified, UCR: Under Consideration or Review. Table 360: JTAPI Features by Cisco Unified Communications Manager Release 10.0 9.0 8.6 8.5 8.0 7.1.3 7.1 7.0 6.1 6.0 5.1 5.0 4.3 4.2 4.1 4.0 3.3 3.2 3.1 JTAPI features s s s s s s s s s s s s s s s s s s s CTI Manager and Support for fault tolerance s s s s s s s s s s s s s s s s s s s Support for Cisco CallManager Extension Mobility s s s s s s s s s s s s s s s M s s s Blind Transfer (using Redirect) s s s s s s s s s s s s s s s s s s s Support Forward s s s s s s s s s s s s s s s s s s s Reset the Original Called Party with Redirect s s s s s s s s s s s s s s s s s s M CiscoAddr InServiceEv or CiscoAddr OutOFServiceEv Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1655

Image 1 from page 1719

Page 1719 diagram

Page 1720

10.0 9.0 8.6 8.5 8.0 7.1.3 7.1 7.0 6.1 6.0 5.1 5.0 4.3 4.2 4.1 4.0 3.3 3.2 3.1 JTAPI features s s s s s s s s s s s s s s s M s s N Localization / Internationalization s s s s s s s s s s s s s s s s M N N User Deletion from Directory s s s s s s s s s s s s s s s s s N N Park and Unpark s s s s s s s s s s s s s s s s s N N Monitoring Call Park Numbers s s s s s s s s s s s s s s s s M N N Call Reason Enhancements s s s s s s s s s s s s s s s s s N N Device Data Passthrough s s s s s s s s s s s s s s s s N N N CiscoJTAPI Auto Install s s s s s s s s s s s s s s s s N N N Multiple Calls per DN s s s s s s s s s s s s s s s s N N N Shared Line Support s s s s s s s s s s s s s s s M s s s Transfer s s s s s s s s s s s s s s s s N N N Direct Transfer s s s s s s s s s s s s s s s M s s s Conference s s s s s s s s s s s s s s s s N N N Join s s s s s s s s s s s s s s s s N N N Privacy Release s s s s s s s s s s s s s s s s N N N Barge and cBarge s s s s s s s s s s s s s s s s N N N Dynamic Port Registration s s s s s s s s s s s s s s s s N N N Media Termination at Route Points s s s s s s s s s s s s s s s s N N N Transfer to VoiceMail s s s s s s s s s s s s s s s s N N N Modifying Calling Number s s s s s s s s s s M s s s s s N N N Support for Presentation Indication s s s s s s s s s s s s s s s N N N N QSIG-PR Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1656 Cisco Unified JTAPI Operations by Release Cisco Unified JTAPI Operations by Release

Page 1720 diagram

Page 1721

10.0 9.0 8.6 8.5 8.0 7.1.3 7.1 7.0 6.1 6.0 5.1 5.0 4.3 4.2 4.1 4.0 3.3 3.2 3.1 JTAPI features s s s s s s s s s s s s s s s N N N N FAC/CMC Support s s s s s s s s s s s s s s s N N N N Device State Server s s s s s s s s s s s s s s s N N N N SuperProvider Functionality s s s s s s s s s s s s s s s N N N N Windows 2003 Support s s s s s s s s s s s s s s N N N N N Directed PARK s s s s s s s s s s s s s s N N N N N Forward on NoBandWidth and Unregister s s s s s s s s s s s s s s N N N N N VoiceMailBox Support s s s s s s s s s s s s s s N N N N N Privacy on Hold s s s s s s s s s s s s s s N N N N N Hold Reversion (4.2.1.SR1) s s s s s s s s s s s s s M s s s s s Support for MLPP (4.2.2) s s s s s s s s s s N N s s N N N N N Conference Enhancement-Add Participants to Conf by Non-controller (4.2.2) s s s s s s s s s s N N s s N N N N N Conference Chaining (4.2.2) s s s s s s s s s s N N s s N N N N N CiscoRTPHandle Interface (4.2.2) s s s s s s s s s s s M s M s s N N N CiscoTermRegistration FailedEv- New Error Code (4.2.3) s s s s s s s s s s s M s s s s s s s Network events s s s s s s s s s s s s N N N N N N N BWC Enhancement s s s s s s s s s s s s N N N N N N N Hairpin Support s s s s s s s s s s s s N N N N N N N Unicode Support s s s s s s s s s s s s N N N N N N N SRTP support Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1657 Cisco Unified JTAPI Operations by Release Cisco Unified JTAPI Operations by Release

Page 1721 diagram

Page 1722

10.0 9.0 8.6 8.5 8.0 7.1.3 7.1 7.0 6.1 6.0 5.1 5.0 4.3 4.2 4.1 4.0 3.3 3.2 3.1 JTAPI features s s s s s s s s s s s s N N N N N N N Partition Support s s s s s s s s s s s s N N N N N N N Security (TLS) support s s s s s s s s s s s s N N N N N N N Alternate Script Support s s s s s s s s s s s s N N N N N N N SIP Features Refer/Replaces s s s s s s s s s s s s N N N N N N N SIP End Point Support s s s s s s s s s s s s N N N N N N N Change Notification of SuperProvider and CallParkDN Monitoring capability s s s s s s s s s s s s N N N N N N N 3XX s s s s s s s s s s s s N N N N N N N Call Select Status s s s s s s s s s s s s N N N N N N N QoS support s s s s s s s s s s s s N N N N N N N Linux and Solaris Installer s s s s s s s s s s N N N N N N N N N Intercom Support s s s s s s s s s s N N N N N N N N N Secure Conferencing Support s s s s s s s s s s N N N N N N N N N Monitoring & Recording s s s s s s s s s s N N N N N N N N N Arabic and Hebrew Language Support s s s s s s s s s s N N N N N N N N N Do-Not_Disturb Support s s s s s s s s s N s s N N N N N N N Join AcrossLine (SCCP) s s s s s s s s s N N N N N N N N N N Certificate Download API Enhancement s s s s s s s s s N N N N N N N N N N Intercom Support for Extension Mobility s s s s s s s s N N N N N N N N N N N Join Across Line (SIP phone support) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1658 Cisco Unified JTAPI Operations by Release Cisco Unified JTAPI Operations by Release

Page 1722 diagram

Page 1723

10.0 9.0 8.6 8.5 8.0 7.1.3 7.1 7.0 6.1 6.0 5.1 5.0 4.3 4.2 4.1 4.0 3.3 3.2 3.1 JTAPI features s s s s s s s s N N N N N N N N N N N Locale Infrastructure Enhancement s s s s s s s s N N N N N N N N N N N DND-CallReject (DND-R) s s s s s s s s N N N N N N N N N N N Call Party Normalization (CPN) s s s s s s s s N N N N N N N N N N N Click-To-Conference s s s s s s s s N N N N N N N N N N N IPv6 Support s s s s s s s s s s s s s s N N N N N Windows Vista Support s s s s s s s s N N N N N N N N N N N EMLogin UserName API s s s s s s s s N N N N N N N N N N N SetJtapiProperties API on CiscoJTAPIPeer s s s s s s s N N N N N N N N N N N N DropAnyParty from Conference s s s s s s s N N N N N N N N N N N N Swap/Cancel - Transfer/Conference Behavior Change s s s s s s s N N N N N N N N N N N N Direct Transfer Across Lines s s s s s s s N N N N N N N N N N N N Park Monitoring enhancements s s s s s s s N N N N N N N N N N N N Assisted DPark s s s s s s s N N N N N N N N N N N N Enhanced MWI s s s s s s s N N N N N N N N N N N N Logical Partitioning s s s s s s s N N N N N N N N N N N N Rollover Support (6921 and 7931) s s s s s s N N N N N N N N N N N N N Address and Terminal Settings (max calls, voice mail, busy trigger etc.) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1659 Cisco Unified JTAPI Operations by Release Cisco Unified JTAPI Operations by Release

Page 1723 diagram

Page 1724

10.0 9.0 8.6 8.5 8.0 7.1.3 7.1 7.0 6.1 6.0 5.1 5.0 4.3 4.2 4.1 4.0 3.3 3.2 3.1 JTAPI features s s s s s N N N N N N N N N N N N N N End to End Call Tracing s s s s s N N N N N N N N N N N N N N Extension Mobility Cross Cluster s s s s s N N N N N N N N N N N N N N Hunt List Support s s s s s N N N N N N N N N N N N N N Call Pickup Invocation s s s s s N N N N N N N N N N N N N N External Call Control s s s s s N N N N N N N N N N N N N N CallFwdAll Key Press Notification s s s s N N N N N N N N N N N N N N N Agent Greeting s s s s N N N N N N N N N N N N N N N Whisper Coaching s s s s N N N N N N N N N N N N N N N Agent Zip Tone s s s s N N N N N N N N N N N N N N N Early Offer (Session Manager) s s s s N N N N N N N N N N N N N N N Single Sign On (SSO) s s s s N N N N N N N N N N N N N N N Energywise (Deep Sleep) s s s N N N N N N N N N N N N N N N N UCR 2008 / FIPS Compliance s s s s N N N N N N N N N N N N N N N Windows 7 Support s s s N N N N N N N N N N N N N N N N 64-Bit Support s s N N N N N N N N N N N N N N N N N Cisco Extend & Connect (CTI Remote Device) s s N N N N N N N N N N N N N N N N N Recording Key Enhancement s s N N N N N N N N N N N N N N N N N Native Queuing s s N N N N N N N N N N N N N N N N N E911 Teleworker s s N N N N N N N N N N N N N N N N N Cius Persistency s N N N N N N N N N N N N N N N N N N CTI Video Support s N N N N N N N N N N N N N N N N N N Gateway Recording Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1660 Cisco Unified JTAPI Operations by Release Cisco Unified JTAPI Operations by Release

Page 1724 diagram

Page 1725

A P P E N D I X E CTI Supported Devices The following table provides information about CTI supported devices. You can see the latest list of Cisco CTI Supported Devices at http://developer.cisco.com/web/jtapi/wikidocs • CTI Supported Devices Table, on page 1661 CTI Supported Devices Table Table legend: : supported, : not supported, NA: Not Applicable. Table 361: CTI Supported Device Matrix Comments SIP SCCP Device/Phone model You can find information on the limitations of this device in Cisco JTAPI Developer Guide for Cisco Unified CallManager 4.1(3) . Analog Phone End of Software Maintenance Release 2001 Cisco 30 SP+ SIP devices require firmware update 9.1(1) available on Cisco.com Cisco 6901 SIP devices require firmware update 9.1(1) available on Cisco.com Cisco 6911 PhoneSetDisplay() interface is not supported. SIP devices require firmware update 9.1(1) available on Cisco.com. Cisco 6921 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1661

Image 1 from page 1725

Page 1725 diagram

Page 1726

Comments SIP SCCP Device/Phone model PhoneSetDisplay() interface is not supported. SIP devices require firmware update 9.1(1) available on Cisco.com. Cisco 6941 PhoneSetDisplay() interface is not supported. SIP devices require firmware update 9.1(1) available on Cisco.com. Cisco 6945 PhoneSetDisplay() interface is not supported. SIP devices require firmware update 9.1(1) available on Cisco.com. Cisco 6961 Cisco 7906 Cisco 7911 End of Software Maintenance Release 2010 Cisco 7914 Sidecar Cisco 7915 Sidecar Cisco 7916 Sidecar Cisco CKEM Sidecar Cisco 7921 Cisco 7925 & 7925-EX CTI supported only if rollover is disabled. Starting withrelease 7.1 this device is supported when corresponding role is added to user. Cisco 7931 End of Software Maintenance Release 2011 Cisco 7936 Cisco 7937 End of Software Maintenance Release 2011 Cisco 7940 Cisco 7941 End of Software Maintenance Release 2009 Cisco 7941G-GE Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1662 CTI Supported Devices CTI Supported Devices

Page 1726 diagram

Page 1727

Comments SIP SCCP Device/Phone model Cisco 7942 Cisco 7945 End of Software Maintenance Release 2011 Cisco 7960 Cisco 7961 End of Software Maintenance Release 2009 Cisco 7961G-GE Cisco 7962 Cisco 7965 End of Software Maintenance Release 2009 Cisco 7970 End of Software Maintenance Release 2009 Cisco 7971 Cisco 7975 End of Software Maintenance Release 2011 Cisco 7985 8811 phones are CTI controlled Cisco 8811 Cisco 8941 Cisco 8945 phoneSetDisplay() interface is not supported Cisco 8961 phoneSetDisplay() interface is not supported Cisco 9951 phoneSetDisplay() interface is not supported Cisco 9971 You can find information on the limitations of this device in Cisco JTAPI Developer Guide for Cisco Unified CallManager 4.1(3) . Cisco ATA 186 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1663 CTI Supported Devices CTI Supported Devices

Page 1727 diagram

Page 1728

Comments SIP SCCP Device/Phone model CTI support added in release 8.5(1) phoneSetDisplay() interface is not supported XSI interface is not supported. Silent Monitoring/Recording is not supported Cisco Cius CTI support added in release 7.1(2) Cisco IP Communicator Requires Jabber 9.0 Cisco Jabber for Windows (Softphone Mode) Supports CTI. Requires CUCM 9.1(1a) and Jabber 9.1(2) Cisco Jabber for Windows (Extend/Connect Mode) Refer to the device model under remote control to determine CTI support. Click-to-Answer requires device speakerphone support. — — Cisco Jabber for Windows (Remote Desktop Control Mode) Requires CUCM 8.6(1) Cisco Jabber for Mac (Softphone Mode) Support for CTI event monitoring added in CUCM 12.5 su1 for WiFi mode only. Does not support invoking call control/feature requests. See Release Notes for details Cisco Jabber for iPhone & iPad Support for CTI event monitoring added in CUCM 12.5 su1 for WiFi mode only. Does not support invoking call control/feature requests. See Release Notes for details Cisco Jabber for Android CTI support added in release 8.5(1) Cisco Unified Personal Communicator - Softphone Mode Refer to the device model under remote control to determine CTI support. Click-to-Answer requires device speakerphone support. — — Cisco Unified Personal Communicator - Remote Desktop Control Mode Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1664 CTI Supported Devices CTI Supported Devices

Page 1728 diagram

Page 1729

Comments SIP SCCP Device/Phone model CTI support added in release 8.5(2) Cisco Unified Communicator Integration for Microsoft Office Communicator/Lync - Softphone Mode Refer to the device model under remote control to determine CTI support. Click-to-Answer requires device speakerphone support. — — Cisco Unified Communicator Integration for Microsoft Office Communicator/Lync - Remote Desktop Control Mode Not a CTI supported device. — — Cisco Web Communicator for Quad - Softphone Mode Refer to the device model under remote control to determine CTI support. Click-to-Answer requires device speakerphone support. — — Cisco Web Communicator for Quad - Remote Desktop Control Mode Not a CTI supported device. — — Cisco Unified Communications Integration for Webex Connect

Softphone Mode Refer to the device model under remote control to determine CTI support. Click-to-Answer requires device speakerphone support. — — Cisco Unified Communications Integration for Webex Connect
Remote Desktop Control Mode Cisco VGC Phone Not a CTI supported device. — — VG224 You can find information on the limitations of this device in Cisco JTAPI Developer Guide for Cisco Unified CallManager 4.1(3) . VG248 CTI supported device that does not use SCCP or SIP. — — CTI Port CTI supported device that does not use SCCP or SIP. — — CTI Remote Device CTI supported device that does not use SCCP or SIP. — — CTI Route Point Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1665 CTI Supported Devices CTI Supported Devices

Page 1729 diagram

Page 1730

Comments SIP SCCP Device/Phone model CTI supported device that does not use SCCP or SIP. — — CTI Route Point (Pilot Point) Not a CTI supported device. — — ISDN BRI Phone Not supported by CTI — — Cisco Spark remote device Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1666 CTI Supported Devices CTI Supported Devices

Page 1730 diagram

Page 1731

A P P E N D I X F Constant Field Values This appendix lists the static final fields and their values. • com.cisco.*, on page 1667 com.cisco.* CiscoAddrActivatedEv com.cisco.jtapi.extensions.CiscoAddrActivatedEv 1073741842 ID public static final int CiscoAddrActivatedOnTerminalEv com.cisco.jtapi.extensions.CiscoAddrActivatedOnTerminalEv 1073741844 ID public static final int CiscoAddrAddedToTerminalEv com.cisco.jtapi.extensions.CiscoAddrAddedToTerminalEv 1073750022 ID public static final int CiscoAddrAutoAcceptStatusChangedEv com.cisco.jtapi.extensions.CiscoAddrAutoAcceptStatusChangedEv 1073750024 ID public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1667

Image 1 from page 1731

Page 1731 diagram

Page 1732

CiscoAddrCreatedEv com.cisco.jtapi.extensions.CiscoAddrCreatedEv 1073750017 ID public static final int CiscoAddress com.cisco.jtapi.extensions.CiscoAddress 1 AUTO_RECORDING public static final int 0 AUTOACCEPT_OFF public static final int 1 AUTOACCEPT_ON public static final int 0 AUTOANSWER_OFF public static final int 3 AUTOANSWER_UNKNOWN public static final int 1 AUTOANSWER_WITHHEADSET public static final int 2 AUTOANSWER_WITHSPEAKERSET public static final int 2 EXTERNAL public static final int 3 EXTERNAL_UNKNOWN public static final int 1 IN_SERVICE public static final int 1 INTERNAL public static final int 5 MONITORING_TARGET public static final int 0 NO_RECORDING public static final int 0 OUT_OF_SERVICE public static final int 0 RINGER_DEFAULT public static final int 1 RINGER_DISABLE public static final int 2 RINGER_ENABLE public static final int 2 SELECTIVE_RECORDING public static final int 4 UNKNOWN public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1668 Constant Field Values CiscoAddrCreatedEv

Page 1732 diagram

Page 1733

CiscoAddrInServiceEv com.cisco.jtapi.extensions.CiscoAddrInServiceEv 1073750018 ID public static final int CiscoAddrIntercomInfoChangedEv com.cisco.jtapi.extensions.CiscoAddrIntercomInfoChangedEv 1073750025 ID public static final int CiscoAddrIntercomInfoRestorationFailedEv com.cisco.jtapi.extensions.CiscoAddrIntercomInfoRestorationFailedEv 1073750032 ID public static final int CiscoAddrOutOfServiceEv com.cisco.jtapi.extensions.CiscoAddrOutOfServiceEv 1073750019 ID public static final int CiscoAddrRecordingConfigChangedEv com.cisco.jtapi.extensions.CiscoAddrRecordingConfigChangedEv 1073750033 ID public static final int CiscoAddrRemovedEv com.cisco.jtapi.extensions.CiscoAddrRemovedEv 1073750020 ID public static final int CiscoAddrRemovedFromTerminalEv com.cisco.jtapi.extensions.CiscoAddrRemovedFromTerminalEv 1073750023 ID public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1669 Constant Field Values CiscoAddrInServiceEv

Page 1733 diagram

Page 1734

CiscoAddrRestrictedEv com.cisco.jtapi.extensions.CiscoAddrRestrictedEv 1073741840 ID public static final int CiscoAddrRestrictedOnTerminalEv com.cisco.jtapi.extensions.CiscoAddrRestrictedOnTerminalEv 1073741845 ID public static final int CiscoCall com.cisco.jtapi.extensions.CiscoCall 2 CALL_RECORDING_TYPE_APPLICATION_INITIATED_SILENT public static final int 1 CALL_RECORDING_TYPE_AUTOMATIC public static final int 0 CALL_RECORDING_TYPE_NONE public static final int 4 CALL_RECORDING_TYPE_USER_INITIATED_FROM_APPLICATION public static final int 3 CALL_RECORDING_TYPE_USER_INITIATED_FROM_DEVICE public static final int 2 CALLSECURITY_AUTHENTICATED public static final int 3 CALLSECURITY_ENCRYPTED public static final int 1 CALLSECURITY_NOTAUTHENTICATED public static final int 0 CALLSECURITY_UNKNOWN public static final int 128 CFWD_ALL_CLEAR public static final int 0 CFWD_ALL_NONE public static final int 64 CFWD_ALL_SET public static final int 3 FEATUREPRIORITY_EMERGENCY public static final int 1 FEATUREPRIORITY_NORMAL public static final int 2 FEATUREPRIORITY_URGENT public static final int 2 PLAYTONE_BOTHLOCALANDREMOTE public static final int 0 PLAYTONE_LOCALONLY public static final int 3 PLAYTONE_NOLOCAL_OR_REMOTE public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1670 Constant Field Values CiscoAddrRestrictedEv

Page 1734 diagram

Page 1735

com.cisco.jtapi.extensions.CiscoCall 1 PLAYTONE_REMOTEONLY public static final int 1 SILENT_MONITOR public static final int CiscoCallChangedEv com.cisco.jtapi.extensions.CiscoCallChangedEv 1073754120 ID public static final int CiscoCallCtlTermConnHeldReversionEv com.cisco.jtapi.extensions.CiscoCallCtlTermConnHeldReversionEv 1073762306 ID public static final int CiscoCallEv com.cisco.jtapi.extensions.CiscoCallEv 43 CAUSE_ACCESSINFORMATIONDISCARDED public static final int 509 CAUSE_BARGE public static final int 58 CAUSE_BCBPRESENTLYAVAIL public static final int 57 CAUSE_BCNAUTHORIZED public static final int 65 CAUSE_BEARERCAPNIMPL public static final int 7 CAUSE_CALLBEINGDELIVERED public static final int 84 CAUSE_CALLIDINUSE public static final int 508 CAUSE_CALLMANAGER_FAILURE public static final int 21 CAUSE_CALLREJECTED public static final int 393216 CAUSE_CALLSPLIT public static final int 66 CAUSE_CHANTYPENIMPL public static final int 6 CAUSE_CHANUNACCEPTABLE public static final int 16777257 CAUSE_CTICCMSIP400BADREQUEST public static final int 33554453 CAUSE_CTICCMSIP401UNAUTHORIZED public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1671 Constant Field Values CiscoCallChangedEv

Page 1735 diagram

Page 1736

com.cisco.jtapi.extensions.CiscoCallEv 50331669 CAUSE_CTICCMSIP402PAYMENTREQUIRED public static final int 67108885 CAUSE_CTICCMSIP403FORBIDDEN public static final int 83886081 CAUSE_CTICCMSIP404NOTFOUND public static final int 100663359 CAUSE_CTICCMSIP405METHODNOTALLOWED public static final int 117440591 CAUSE_CTICCMSIP406NOTACCEPTABLE public static final int 134217749 CAUSE_CTICCMSIP407PROXYAUTHENTICATIONREQUIRED public static final int 150995046 CAUSE_CTICCMSIP408REQUESTTIMEOUT public static final int 184549398 CAUSE_CTICCMSIP410GONE public static final int 201326719 CAUSE_CTICCMSIP411LENGTHREQUIRED public static final int 234881151 CAUSE_CTICCMSIP413REQUESTENTITYTOOLONG public static final int 251658367 CAUSE_CTICCMSIP414REQUESTURITOOLONG public static final int 268435535 CAUSE_CTICCMSIP415UNSUPPORTEDMEDIATYPE public static final int 285212799 CAUSE_CTICCMSIP416UNSUPPORTEDURISCHEME public static final int 352321663 CAUSE_CTICCMSIP420BADEXTENSION public static final int 369098879 CAUSE_CTICCMSIP421EXTENSTIONREQUIRED public static final int 402653311 CAUSE_CTICCMSIP423INTERVALTOOBRIEF public static final int 1073741842 CAUSE_CTICCMSIP480TEMPORARILYUNAVAILABLE public static final int 1090519081 CAUSE_CTICCMSIP481CALLLEGDOESNOTEXIST public static final int 1107296281 CAUSE_CTICCMSIP482LOOPDETECTED public static final int 1124073497 CAUSE_CTICCMSIP483TOOMANYHOOPS public static final int 1140850716 CAUSE_CTICCMSIP484ADDRESSINCOMPLETE public static final int 1157627905 CAUSE_CTICCMSIP485AMBIGUOUS public static final int 1174405137 CAUSE_CTICCMSIP486BUSYHERE public static final int 1191182367 CAUSE_CTICCMSIP487REQUESTTERMINATED public static final int 1207959583 CAUSE_CTICCMSIP488NOTACCEPTABLEHERE public static final int 1258291217 CAUSE_CTICCMSIP491REQUESTPENDING public static final int 1291845649 CAUSE_CTICCMSIP493UNDECIPHERABLE public static final int 1409286185 CAUSE_CTICCMSIP500SERVERINTERNALERROR public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1672 Constant Field Values Constant Field Values

Page 1736 diagram

Page 1737

com.cisco.jtapi.extensions.CiscoCallEv 1426063439 CAUSE_CTICCMSIP501NOTIMPLEMENTED public static final int 1442840614 CAUSE_CTICCMSIP502BADGATEWAY public static final int 1459617833 CAUSE_CTICCMSIP503SERVICEUNAVAILABLE public static final int 1476395110 CAUSE_CTICCMSIP504SERVERTIMEOUT public static final int 1493172351 CAUSE_CTICCMSIP505SIPVERSIONNOTSUPPORTED public static final int 1509949567 CAUSE_CTICCMSIP513MESSAGETOOLARGE public static final int -1593835503 CAUSE_CTICCMSIP600BUSYEVERYWHERE public static final int -1577058283 CAUSE_CTICCMSIP603DECLINE public static final int -1560281087 CAUSE_CTICCMSIP604DOESNOTEXISTANYWHERE public static final int -1543503841 CAUSE_CTICCMSIP606NOTACCEPTABLE public static final int 262144 CAUSE_CTICONFERENCEFULL public static final int 123 CAUSE_CTIDEVICENOTPREEMPTABLE public static final int 458752 CAUSE_CTIDROPCONFEREE public static final int 507 CAUSE_CTIMANAGER_FAILURE public static final int 46 CAUSE_CTIPRECEDENCECALLBLOCKED public static final int 122 CAUSE_CTIPRECEDENCELEVELEXCEEDED public static final int 129 CAUSE_CTIPRECEDENCEOUTOFBANDWIDTH public static final int 9 CAUSE_CTIPREEMPTFORREUSE public static final int 8 CAUSE_CTIPREEMPTNOREUSE public static final int 27 CAUSE_DESTINATIONOUTOFORDER public static final int 90 CAUSE_DESTNUMMISSANDDCNOTSUB public static final int 512 CAUSE_DPARK public static final int 514 CAUSE_DPARK_REMINDER public static final int 513 CAUSE_DPARK_UNPARK public static final int 25 CAUSE_EXCHANGEROUTINGERROR public static final int 510 CAUSE_FAC_CMC public static final int 29 CAUSE_FACILITYREJECTED public static final int 82 CAUSE_IDENTIFIEDCHANDDOESNOTEXIST public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1673 Constant Field Values Constant Field Values

Page 1737 diagram

Page 1738

com.cisco.jtapi.extensions.CiscoCallEv 99 CAUSE_IENIMPL public static final int 505 CAUSE_INBOUNDBLINDTRANSFER public static final int 504 CAUSE_INBOUNDCONFERENCE public static final int 503 CAUSE_INBOUNDTRANSFER public static final int 54 CAUSE_INCOMINGCALLBARRED public static final int 88 CAUSE_INCOMPATABLEDESTINATION public static final int 127 CAUSE_INTERWORKINGUNSPECIFIED public static final int 81 CAUSE_INVALIDCALLREFVALUE public static final int 100 CAUSE_INVALIDIECONTENTS public static final int 95 CAUSE_INVALIDMESSAGEUNSPECIFIED public static final int 28 CAUSE_INVALIDNUMBERFORMAT public static final int 91 CAUSE_INVALIDTRANSITNETSEL public static final int 96 CAUSE_MANDATORYIEMISSING public static final int 101 CAUSE_MSGNCOMPATABLEWCS public static final int 98 CAUSE_MSGTYPENCOMPATWCS public static final int 97 CAUSE_MSGTYPENIMPL public static final int 38 CAUSE_NETOUTOFORDER public static final int 19 CAUSE_NOANSWERFROMUSER public static final int 85 CAUSE_NOCALLSUSPENDED public static final int 34 CAUSE_NOCIRCAVAIL public static final int 0 CAUSE_NOERROR public static final int 26 CAUSE_NONSELECTEDUSERCLEARING public static final int 16 CAUSE_NORMALCALLCLEARING public static final int 31 CAUSE_NORMALUNSPECIFIED public static final int 3 CAUSE_NOROUTETODDESTINATION public static final int 2 CAUSE_NOROUTETOTRANSITNET public static final int 18 CAUSE_NOUSERRESPONDING public static final int 22 CAUSE_NUMBERCHANGED public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1674 Constant Field Values Constant Field Values

Page 1738 diagram

Page 1739

com.cisco.jtapi.extensions.CiscoCallEv 70 CAUSE_ONLYRDIVEARERCAPAVAIL public static final int 502 CAUSE_OUTBOUNDCONFERENCE public static final int 501 CAUSE_OUTBOUNDTRANSFER public static final int 125 CAUSE_OUTOFBANDWIDTH public static final int 111 CAUSE_PROTOCOLERRORUNSPECIFIED public static final int 511 CAUSE_QSIG_PR public static final int 49 CAUSE_QUALOFSERVNAVAIL public static final int 515 CAUSE_QUIET_CLEAR public static final int 102 CAUSE_RECOVERYONTIMEREXPIRY public static final int 200 CAUSE_REDIRECTED public static final int 86 CAUSE_REQCALLIDHASBEENCLEARED public static final int 44 CAUSE_REQCIRCNAVIL public static final int 69 CAUSE_REQFACILITYNIMPL public static final int 50 CAUSE_REQFACILITYNOTSUBSCRIBED public static final int 47 CAUSE_RESOURCESNAVAIL public static final int 30 CAUSE_RESPONSETOSTATUSENQUIRY public static final int 63 CAUSE_SERVNOTAVAILUNSPECIFIED public static final int 53 CAUSE_SERVOPERATIONVIOLATED public static final int 79 CAUSE_SERVOROPTNAVAILORIMPL public static final int 20 CAUSE_SUBSCRIBERABSENT public static final int 83 CAUSE_SUSPCALLBUTNOTTHISONE public static final int 42 CAUSE_SWITCHINGEQUIPMENTCONGESTION public static final int 41 CAUSE_TEMPORARYFAILURE public static final int 1 CAUSE_UNALLOCATEDNUMBER public static final int 17 CAUSE_USERBUSY public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1675 Constant Field Values Constant Field Values

Page 1739 diagram

Page 1740

CiscoCallSecurityStatusChangedEv com.cisco.jtapi.extensions.CiscoCallSecurityStatusChangedEv 1073754129 ID public static final int CiscoConferenceChainAddedEv com.cisco.jtapi.extensions.CiscoConferenceChainAddedEv 1073754121 ID public static final int CiscoConferenceChainRemovedEv com.cisco.jtapi.extensions.CiscoConferenceChainRemovedEv 1073754128 ID public static final int CiscoConferenceEndEv com.cisco.jtapi.extensions.CiscoConferenceEndEv 1073754114 ID public static final int CiscoConferenceStartEv com.cisco.jtapi.extensions.CiscoConferenceStartEv 1073754115 ID public static final int CiscoConnection com.cisco.jtapi.extensions.CiscoConnection 2 ADDRESS_SEARCH_SPACE public static final int 0 CALLED_ADDRESS_DEFAULT public static final int 2 CALLED_ADDRESS_SET_TO_PREFERREDCALLEDPARTY public static final int 1 CALLED_ADDRESS_SET_TO_REDIRECT_DESTINATION public static final int 0 CALLED_ADDRESS_UNCHANGED public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1676 Constant Field Values CiscoCallSecurityStatusChangedEv

Page 1740 diagram

Page 1741

com.cisco.jtapi.extensions.CiscoConnection 1 CALLINGADDRESS_SEARCH_SPACE public static final int 0 DEFAULT_SEARCH_SPACE public static final int 1 REASON_DIRECTCALL public static final int 5 REASON_FORWARDALL public static final int 4 REASON_FORWARDBUSY public static final int 3 REASON_FORWARDNOANSWER public static final int 99 REASON_OUTBOUND public static final int 6 REASON_REDIRECT public static final int 2 REASON_TRANSFERREDCALL public static final int 1 REDIRECT_DROP_ON_FAILURE public static final int 2 REDIRECT_NORMAL public static final int CiscoConnectionUniqueIDChangedEv com.cisco.jtapi.extensions.CiscoConsultCallActiveEv 1073754116 ID public static final int CiscoConsultCallActiveEv com.cisco.jtapi.extensions.CiscoConsultCallActiveEv 1073754116 ID public static final int CiscoFeatureReason com.cisco.jtapi.extensions.CiscoFeatureReason 20 REASON_BARGE public static final int 7 REASON_BLINDTRANSFER public static final int 11 REASON_CALLPICKUP public static final int 26 REASON_CCM_REDIRECTION public static final int 39 REASON_CLICK_TO_CONFERENCE public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1677 Constant Field Values CiscoConnectionUniqueIDChangedEv

Page 1741 diagram

Page 1742

com.cisco.jtapi.extensions.CiscoFeatureReason 9 REASON_CONFERENCE public static final int 27 REASON_DPARK_CALLPARK public static final int 28 REASON_DPARK_REVERSION public static final int 29 REASON_DPARK_UNPARK public static final int 22 REASON_FAC_CMC public static final int 5 REASON_FORWARDALL public static final int 4 REASON_FORWARDBUSY public static final int 3 REASON_FORWARDNOANSWER public static final int 21 REASON_IMMDIVERT public static final int 33 REASON_MOBILITY public static final int 35 REASON_MOBILITY_CELLPICKUP public static final int 38 REASON_MOBILITY_FOLLOWME public static final int 36 REASON_MOBILITY_HANDIN public static final int 37 REASON_MOBILITY_HANDOUT public static final int 34 REASON_MOBILITY_IVR public static final int 12 REASON_NORMAL public static final int 10 REASON_PARK public static final int 15 REASON_PARKREMAINDER public static final int 15 REASON_PARKREMINDER public static final int 23 REASON_QSIG_PR public static final int 6 REASON_REDIRECT public static final int 24 REASON_REFER public static final int 25 REASON_REPLACE public static final int 31 REASON_SILENTMONITORING public static final int 2 REASON_TRANSFER public static final int 16 REASON_UNPARK public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1678 Constant Field Values Constant Field Values

Page 1742 diagram

Page 1743

CiscoG711MediaCapability com.cisco.jtapi.extensions.CiscoG711MediaCapability 60 FRAMESIZE_SIXTY_MILLISECOND_PACKET public static final int 30 FRAMESIZE_THIRTY_MILLISECOND_PACKET public static final int 20 FRAMESIZE_TWENTY_MILLISECOND_PACKET public static final int CiscoG723MediaCapability com.cisco.jtapi.extensions.CiscoG723MediaCapability 60 FRAMESIZE_SIXTY_MILLISECOND_PACKET public static final int 30 FRAMESIZE_THIRTY_MILLISECOND_PACKET public static final int 20 FRAMESIZE_TWENTY_MILLISECOND_PACKET public static final int CiscoG729MediaCapability com.cisco.jtapi.extensions.CiscoG729MediaCapability 60 FRAMESIZE_SIXTY_MILLISECOND_PACKET public static final int 30 FRAMESIZE_THIRTY_MILLISECOND_PACKET public static final int 20 FRAMESIZE_TWENTY_MILLISECOND_PACKET public static final int CiscoGSMMediaCapability com.cisco.jtapi.extensions.CiscoGSMMediaCapability 80 FRAMESIZE_EIGHTY_MILLISECOND_PACKET public static final int CiscoJtapiException com.cisco.jtapi.extensions.CiscoJtapiException -1932787685 ASSOCIATED_LINE_NOT_OPEN public static final int -1932787705 CALL_ALREADY_EXISTS public static final int -1932787564 CALL_DROPPED public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1679 Constant Field Values CiscoG711MediaCapability

Page 1743 diagram

Page 1744

com.cisco.jtapi.extensions.CiscoJtapiException -1932787702 CALLHANDLE_NOTINCOMINGCALL public static final int -1932787644 CALLHANDLE_UNKNOWN_TO_LINECONTROL public static final int -1932787647 CANNOT_OPEN_DEVICE public static final int -1932787690 CANNOT_TERMINATE_MEDIA_ON_PHONE public static final int -1932787597 CFWDALL_ALREADY_SET public static final int -1932787596 CFWDALL_DESTN_INVALID public static final int -1932787612 CLUSTER_LINK_FAILURE public static final int -1932787559 COMMAND_NOT_IMPLEMENTED_ON_DEVICE public static final int -1932787588 CONFERENCE_ALREADY_PRESENT public static final int -1932787590 CONFERENCE_FAILED public static final int -1932787642 CONFERENCE_FULL public static final int -1932787587 CONFERENCE_INACTIVE public static final int -1932787589 CONFERENCE_INVALID_PARTICIPANT public static final int -1932787688 CTIERR_ACCESS_TO_DEVICE_DENIED public static final int -1932787679 CTIERR_APP_SOFTKEYS_ALREADY_CONTROLLED public static final int -1932787675 CTIERR_APPLICATION_DATA_SIZE_EXCEEDED public static final int -1932787476 CTIERR_BIB_NOT_CONFIGURED public static final int -1932787489 CTIERR_BIB_RESOURCE_NOT_AVAILABLE public static final int -1932787689 CTIERR_CALL_MANAGER_NOT_AVAILABLE public static final int -1932787533 CTIERR_CALL_NOT_EXISTED public static final int -1932787579 CTIERR_CALL_PARK_NO_DN public static final int -1932787577 CTIERR_CALL_REQUEST_ALREADY_OUTSTANDING public static final int -1932787583 CTIERR_CALL_UNPARK_FAILED public static final int -1932787518 CTIERR_CAPABILITIES_DO_NOT_MATCH public static final int -1932787673 CTIERR_CLOSE_DELAY_NOT_SUPPORTED_WITH_REG_TYPE public static final int -1932787535 CTIERR_CONFERENCE_ALREADY_EXISTED public static final int -1932787534 CTIERR_CONFERENCE_NOT_EXISTED public static final int -1932787503 CTIERR_CONNECTION_ON_INVALID_PORT public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1680 Constant Field Values Constant Field Values

Page 1744 diagram

Page 1745

com.cisco.jtapi.extensions.CiscoJtapiException -1932787576 CTIERR_CONSULT_CALL_FAILURE public static final int -1932787640 CTIERR_CONSULTCALL_ALREADY_OUTSTANDING public static final int -1932787500 CTIERR_CRYPTO_CAPABILITY_MISMATCH public static final int -1932787515 CTIERR_CTIHANDLER_PROCESS_CREATION_FAILED public static final int -1932787494 CTIERR_DB_INITIALIZATION_ERROR public static final int -1932787552 CTIERR_DEVICE_ALREADY_OPENED public static final int 0X8CCC0127 CTIERR_DEVICE_ALREADY_REGISTERED_NONEXTEND public static final int -1932787551 CTIERR_DEVICE_NOT_OPENED_YET public static final int -1932787517 CTIERR_DEVICE_OWNER_ALIVE_TIMER_STARTED public static final int -1932787490 CTIERR_DEVICE_REGISTRATION_FAILED_NOT_SUPPORTED_MEDIATYPE public static final int -1932787502 CTIERR_DEVICE_RESTRICTED public static final int -1932787558 CTIERR_DEVICE_SHUTTING_DOWN public static final int -1932787595 CTIERR_DIRECTORY_LOGIN_TIMEOUT public static final int -1932787529 CTIERR_DUPLICATE_CALL_REFERENCE public static final int 0X8CCC0122 CTIERR_DUPLICATE_REMOTE_DESTINATION_NUMBER public static final int -1932787468 CTIERR_DYNREG_IPADDRMODE_MISMATCH public static final int 0X8CCC0126 CTIERR_ENDUSER_NOT_ASSOCIATED_WITH_DEVICE public static final int -1932787506 CTIERR_FAC_CMC_REASON_CMC_INVALID public static final int -1932787509 CTIERR_FAC_CMC_REASON_CMC_NEEDED public static final int -1932787508 CTIERR_FAC_CMC_REASON_FAC_CMC_NEEDED public static final int -1932787507 CTIERR_FAC_CMC_REASON_FAC_INVALID public static final int -1932787510 CTIERR_FAC_CMC_REASON_FAC_NEEDED public static final int -1932787575 CTIERR_FEATURE_ALREADY_REGISTERED public static final int -1932787565 CTIERR_FEATURE_DATA_REJECT public static final int -1932787514 CTIERR_FEATURE_SELECT_FAILED public static final int -1932787578 CTIERR_ILLEGAL_DEVICE_TYPE public static final int -1932787629 CTIERR_INCOMPATIBLE_AUTOINSTALL_PROTOCOL_VERSION public static final int -1932787560 CTIERR_INCORRECT_MEDIA_CAPABILITY public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1681 Constant Field Values Constant Field Values

Page 1745 diagram

Page 1746

com.cisco.jtapi.extensions.CiscoJtapiException -1932787677 CTIERR_INFORMATION_NOT_AVAILABLE public static final int -1932787475 CTIERR_INTERCOM_SPEEDDIAL_ALREADY_CONFIGURED public static final int -1932787493 CTIERR_INTERCOM_SPEEDDIAL_ALREADY_SET public static final int -1932787492 CTIERR_INTERCOM_SPEEDDIAL_DESTN_INVALID public static final int -1932787474 CTIERR_INTERCOM_TALKBACK_ALREADY_PENDING public static final int -1932787491 CTIERR_INTERCOM_TALKBACK_FAILURE public static final int -1932787568 CTIERR_INTERNAL_FAILURE public static final int -1932787487 CTIERR_INVALID_CALLID public static final int -1932787678 CTIERR_INVALID_DEVICE_NAME public static final int -1932787561 CTIERR_INVALID_DTMFDIGITS public static final int -1932787625 CTIERR_INVALID_FILTER_SIZE public static final int -1932787674 CTIERR_INVALID_MEDIA_DEVICE public static final int -1932787554 CTIERR_INVALID_MEDIA_PARAMETER public static final int -1932787519 CTIERR_INVALID_MEDIA_PROCESS public static final int -1932787557 CTIERR_INVALID_MEDIA_RESOURCE_ID public static final int -1932787627 CTIERR_INVALID_MESSAGE_HEADER_INFO public static final int -1932787628 CTIERR_INVALID_MESSAGE_LENGTH public static final int -1932787486 CTIERR_INVALID_MONITOR_DESTN public static final int -1932787580 CTIERR_INVALID_MONITOR_DN_TYPE public static final int -1932787473 CTIERR_INVALID_MONITORMODE public static final int -1932787532 CTIERR_INVALID_PARAMETER public static final int -1932787582 CTIERR_INVALID_PARK_DN public static final int -1932787581 CTIERR_INVALID_PARK_REGISTRATION_HANDLE public static final int 0X8CCC0130 CTIERR_INVALID_REMOTE_DESTINATION_NAME public static final int 0X8CCC0121 CTIERR_INVALID_REMOTE_DESTINATION_NUMBER public static final int -1932787530 CTIERR_INVALID_RESOURCE_TYPE public static final int -1932787469 CTIERR_IPADDRMODE_MISMATCH public static final int -1932787594 CTIERR_LINE_OUT_OF_SERVICE public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1682 Constant Field Values Constant Field Values

Page 1746 diagram

Page 1747

com.cisco.jtapi.extensions.CiscoJtapiException -1932787501 CTIERR_LINE_RESTRICTED public static final int -1932787516 CTIERR_MAXCALL_LIMIT_REACHED public static final int -1932787548 CTIERR_MEDIA_ALREADY_TERMINATED_DYNAMIC public static final int 0X8CCC0128 CTIERR_MEDIA_ALREADY_TERMINATED_EXTEND public static final int -1932787550 CTIERR_MEDIA_ALREADY_TERMINATED_NONE public static final int -1932787549 CTIERR_MEDIA_ALREADY_TERMINATED_STATIC public static final int -1932787553 CTIERR_MEDIA_CAPABILITY_MISMATCH public static final int -1932787676 CTIERR_MEDIA_RESOURCE_NAME_SIZE_EXCEEDED public static final int -1932787567 CTIERR_MEDIAREGISTRATIONTYPE_DO_NOT_MATCH public static final int -1932787626 CTIERR_MESSAGE_TOO_BIG public static final int -1932787531 CTIERR_MORE_ACTIVE_CALLS_THAN_RESERVED public static final int -1932787512 CTIERR_NO_EXISTING_CALLS public static final int -1932787527 CTIERR_NO_EXISTING_CONFERENCE public static final int -1932787479 CTIERR_NO_RECORDING_SESSION public static final int -1932787526 CTIERR_NO_RESPONSE_FROM_MP public static final int -1932787528 CTIERR_NOT_PRESERVED_CALL public static final int -1932787566 CTIERR_OPERATION_FAILED_QUIETCLEAR public static final int -1932787555 CTIERR_OPERATION_NOT_ALLOWED public static final int -1932787498 CTIERR_OUT_OF_BANDWIDTH public static final int -1932787547 CTIERR_OWNER_NOT_ALIVE public static final int -1932787520 CTIERR_PENDING_ACCEPT_OR_ANSWER_REQUEST public static final int -1932787485 CTIERR_PENDING_START_MONITORING_REQUEST public static final int -1932787483 CTIERR_PENDING_START_RECORDING_REQUEST public static final int -1932787482 CTIERR_PENDING_STOP_RECORDING_REQUEST public static final int -1932787471 CTIERR_PRIMARY_CALL_INVALID public static final int -1932787470 CTIERR_PRIMARY_CALL_STATE_INVALID public static final int -1932787480 CTIERR_RECORDING_ALREADY_INPROGRESS public static final int -1932787477 CTIERR_RECORDING_CONFIG_NOT_MATCHING public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1683 Constant Field Values Constant Field Values

Page 1747 diagram

Page 1748

com.cisco.jtapi.extensions.CiscoJtapiException -1932787478 CTIERR_RECORDING_SESSION_INACTIVE public static final int -1932787513 CTIERR_REDIRECT_UNAUTHORIZED_COMMAND_USAGE public static final int -1932787585 CTIERR_REGISTER_FEATURE_ACTIVATION_FAILED public static final int -1932787523 CTIERR_REGISTER_FEATURE_APP_ALREADY_REGISTERED public static final int -1932787524 CTIERR_REGISTER_FEATURE_PROVIDER_NOT_REGISTERED public static final int 0X8CCC0124 CTIERR_REMOTE_DEVICE_REQUEST_FAILED_ACTIVE_RD_NOT_SET public static final int 0X8CCC0123 CTIERR_REMOTEDESTINATION_LIMIT_EXCEEDED public static final int -1932787536 CTIERR_RESOURCE_NOT_AVAILABLE public static final int -1932787484 CTIERR_START_MONITORING_FAILED public static final int -1932787481 CTIERR_START_RECORDING_FAILED public static final int -1932787574 CTIERR_STATION_SHUT_DOWN public static final int -1932787525 CTIERR_SYSTEM_ERROR public static final int -1932787638 CTIERR_UDP_PASS_THROUGH_NOT_SUPPORTED public static final int -1932787556 CTIERR_UNKNOWN_EXCEPTION public static final int -1932787584 CTIERR_UNSUPPORTED_CALL_PARK_TYPE public static final int -1932787511 CTIERR_UNSUPPORTED_CFWD_TYPE public static final int -1932787504 CTIERR_USER_NOT_AUTH_FOR_SECURITY public static final int -1932787591 DARES_INVALID_REQ_TYPE public static final int -1932787681 DATA_SIZE_LIMIT_EXCEEDED public static final int -1932787691 DB_ERROR public static final int -1932787692 DB_ILLEGAL_DEVICE_TYPE public static final int -1932787694 DB_NO_MORE_DEVICES public static final int -1897005054 DESTINATION_BUSY public static final int -1897005055 DESTINATION_UNKNOWN public static final int -1932787693 DEVICE_ALREADY_REGISTERED public static final int -1932787686 DEVICE_NOT_OPEN public static final int -1932787593 DEVICE_OUT_OF_SERVICE public static final int -1932787610 DIGIT_GENERATION_ALREADY_IN_PROGRESS public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1684 Constant Field Values Constant Field Values

Page 1748 diagram

Page 1749

com.cisco.jtapi.extensions.CiscoJtapiException -1932787607 DIGIT_GENERATION_CALLSTATE_CHANGED public static final int -1932787609 DIGIT_GENERATION_WRONG_CALL_HANDLE public static final int -1932787608 DIGIT_GENERATION_WRONG_CALL_STATE public static final int -1932787616 DIRECTORY_LOGIN_FAILED public static final int -1932787617 DIRECTORY_LOGIN_NOT_ALLOWED public static final int -1932787618 DIRECTORY_TEMPORARY_UNAVAILABLE public static final int -1932787709 EXISTING_FIRSTPARTY public static final int -1932787697 HOLDFAILED public static final int -1932787706 ILLEGAL_CALLINGPARTY public static final int -1932787703 ILLEGAL_CALLSTATE public static final int -1932787708 ILLEGAL_HANDLE public static final int -1932787630 ILLEGAL_MESSAGE_FORMAT public static final int -1932787632 INCOMPATIBLE_PROTOCOL_VERSION public static final int -1932787599 INVALID_LINE_HANDLE public static final int -1932787680 INVALID_RING_OPTION public static final int -1932787606 LINE_GREATER_THAN_MAX_LINE public static final int -1932787611 LINE_INFO_DOES_NOT_EXIST public static final int -1932787598 LINE_NOT_PRIMARY public static final int -1932787704 LINECONTROL_FAILURE public static final int -1932787641 MAX_NUMBER_OF_CTI_CONNECTIONS_REACHED public static final int -1932787592 MSGWAITING_DESTN_INVALID public static final int -1932787710 NO_ACTIVE_DEVICE_FOR_THIRDPARTY public static final int -1932787639 NO_CONFERENCE_BRIDGE public static final int -1932787613 NOT_INITIALIZED public static final int -1091584273 PROTOCOL_TIMEOUT public static final int -1932787614 PROVIDER_ALREADY_OPEN public static final int -559038737 PROVIDER_CLOSED public static final int -1932787615 PROVIDER_NOT_OPEN public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1685 Constant Field Values Constant Field Values

Page 1749 diagram

Page 1750

com.cisco.jtapi.extensions.CiscoJtapiException -1932787662 REDIRECT_CALL_CALL_TABLE_FULL public static final int -1932787649 REDIRECT_CALL_DESTINATION_BUSY public static final int -1932787648 REDIRECT_CALL_DESTINATION_OUT_OF_ORDER public static final int -1932787659 REDIRECT_CALL_DIGIT_ANALYSIS_TIMEOUT public static final int -1932787683 REDIRECT_CALL_DOES_NOT_EXIST public static final int -1932787654 REDIRECT_CALL_INCOMPATIBLE_STATE public static final int -1932787658 REDIRECT_CALL_MEDIA_CONNECTION_FAILED public static final int -1932787651 REDIRECT_CALL_NORMAL_CLEARING public static final int -1932787656 REDIRECT_CALL_ORIGINATOR_ABANDONED public static final int -1932787657 REDIRECT_CALL_PARTY_TABLE_FULL public static final int -1932787653 REDIRECT_CALL_PENDING_REDIRECT_TRANSACTION public static final int -1932787661 REDIRECT_CALL_PROTOCOL_ERROR public static final int -1932787660 REDIRECT_CALL_UNKNOWN_DESTINATION public static final int -1932787652 REDIRECT_CALL_UNKNOWN_ERROR public static final int -1932787655 REDIRECT_CALL_UNKNOWN_PARTY public static final int -1932787650 REDIRECT_CALL_UNRECOGNIZED_MANAGER public static final int -1932787664 REDIRECT_CALLINFO_ERR public static final int -1932787663 REDIRECT_ERR public static final int -1932787695 RETRIEVEFAILED public static final int -1932787600 RETRIEVEFAILED_ACTIVE_CALL_ON_LINE public static final int -1932787684 SSAPI_NOT_REGISTERED public static final int -1932787711 TIMEOUT public static final int -1932787586 TRANSFER_INACTIVE public static final int -1932787698 TRANSFERFAILED public static final int -1932787645 TRANSFERFAILED_CALLCONTROL_TIMEOUT public static final int -1932787699 TRANSFERFAILED_DESTINATION_BUSY public static final int -1932787701 TRANSFERFAILED_DESTINATION_UNALLOCATED public static final int -1932787646 TRANSFERFAILED_OUTSTANDING_TRANSFER public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1686 Constant Field Values Constant Field Values

Page 1750 diagram

Page 1751

com.cisco.jtapi.extensions.CiscoJtapiException -1932787707 UNDEFINED_LINE public static final int -1932787687 UNKNOWN_GLOBAL_CALL_HANDLE public static final int -1932787631 UNRECOGNIZABLE_PDU public static final int 0 UNSPECIFIED public static final int CiscoJtapiProperties com.cisco.jtapi.extensions.CiscoJtapiProperties 0 TLS_V1_0 public static final int 1 TLS_V1_1 public static final int 2 TLS_V1_2 public static final int 3 TLS_V1_3 public static final int CiscoLocales com.cisco.jtapi.extensions.CiscoLocales 47 LOCALE_ARABIC_ALGERIA public static final int 48 LOCALE_ARABIC_BAHRAIN public static final int 49 LOCALE_ARABIC_EGYPT public static final int 50 LOCALE_ARABIC_IRAQ public static final int 51 LOCALE_ARABIC_JORDAN public static final int 38 LOCALE_ARABIC_KUWAIT public static final int 52 LOCALE_ARABIC_LEBANON public static final int 53 LOCALE_ARABIC_MOROCCO public static final int 36 LOCALE_ARABIC_OMAN public static final int 54 LOCALE_ARABIC_QATAR public static final int 37 LOCALE_ARABIC_SAUDI_ARABIA public static final int 55 LOCALE_ARABIC_TUNISIA public static final int 35 LOCALE_ARABIC_UNITED_ARAB_EMIRATES public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1687 Constant Field Values CiscoJtapiProperties

Page 1751 diagram

Page 1752

com.cisco.jtapi.extensions.CiscoLocales 56 LOCALE_ARABIC_YEMEN public static final int 27 LOCALE_BULGARIAN_BULGARIA public static final int 32 LOCALE_CATALAN_SPAIN public static final int 24 LOCALE_CHINESE_HONG_KONG public static final int 28 LOCALE_CROATIAN_CROATIA public static final int 26 LOCALE_CZECH_CZECH_REPUBLIC public static final int 12 LOCALE_DANISH_DENMARK public static final int 8 LOCALE_DUTCH_NETHERLAND public static final int 33 LOCALE_ENGLISH_UNITED_KINGDOM public static final int 1 LOCALE_ENGLISH_UNITED_STATES public static final int 22 LOCALE_FINNISH_FINLAND public static final int 2 LOCALE_FRENCH_FRANCE public static final int 3 LOCALE_GERMAN_GERMANY public static final int 16 LOCALE_GREEK_GREECE public static final int 39 LOCALE_HEBREW_ISRAEL public static final int 14 LOCALE_HUNGARIAN_HUNGARY public static final int 7 LOCALE_ITALIAN_ITALY public static final int 13 LOCALE_JAPANESE_JAPAN public static final int 21 LOCALE_KOREAN_KOREA public static final int 9 LOCALE_NORWEGIAN_NORWAY public static final int 15 LOCALE_POLISH_POLAND public static final int 23 LOCALE_PORTUGUESE_BRAZIL public static final int 10 LOCALE_PORTUGUESE_PORTUGAL public static final int 30 LOCALE_ROMANIAN_ROMANIA public static final int 5 LOCALE_RUSSIAN_RUSSIA public static final int 41 LOCALE_SERBIAN_REPUBLIC_OF_MONTENEGRO public static final int 40 LOCALE_SERBIAN_REPUBLIC_OF_SERBIA public static final int 20 LOCALE_SIMPLIFIED_CHINESE_CHINA public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1688 Constant Field Values Constant Field Values

Page 1752 diagram

Page 1753

com.cisco.jtapi.extensions.CiscoLocales 25 LOCALE_SLOVAK_SLOVAKIA public static final int 29 LOCALE_SLOVENIAN_SLOVENIA public static final int 6 LOCALE_SPANISH_SPAIN public static final int 11 LOCALE_SWEDISH_SWEDEN public static final int 42 LOCALE_THAI_THAILAND public static final int 19 LOCALE_TRADITIONAL_CHINESE_CHINA public static final int CiscoMediaConnectionMode com.cisco.jtapi.extensions.CiscoMediaConnectionMode 0 NONE public static final int 1 RECEIVE_ONLY public static final int 3 TRANSMIT_AND_RECEIVE public static final int 2 TRANSMIT_ONLY public static final int CiscoMediaEncryptionAlgorithmType com.cisco.jtapi.extensions.CiscoMediaEncryptionAlgorithmType 1 AES_128_COUNTER public static final int CiscoMediaOpenLogicalChannelEv com.cisco.jtapi.extensions.CiscoMediaOpenLogicalChannelEv 1073758213 ID public static final int CiscoMediaSecurityIndicator com.cisco.jtapi.extensions.CiscoMediaSecurityIndicator 0 MEDIA_ENCRYPT_KEYS_AVAILABLE public static final int 2 MEDIA_ENCRYPT_KEYS_UNAVAILABLE public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1689 Constant Field Values CiscoMediaConnectionMode

Page 1753 diagram

Page 1754

com.cisco.jtapi.extensions.CiscoMediaSecurityIndicator 1 MEDIA_ENCRYPT_USER_NOT_AUTHORIZED public static final int 3 MEDIA_NOT_ENCRYPTED public static final int CiscoOutOfServiceEv com.cisco.jtapi.extensions.CiscoOutOfServiceEv 1001 CAUSE_CALLMANAGER_FAILURE public static final int 1007 CAUSE_CTIMANAGER_FAILURE public static final int 1004 CAUSE_DEVICE_FAILURE public static final int 1008 CAUSE_DEVICE_RESTRICTED public static final int 1005 CAUSE_DEVICE_UNREGISTERED public static final int 1009 CAUSE_LINE_RESTRICTED public static final int 1003 CAUSE_NOCALLMANAGER_AVAILABLE public static final int 1002 CAUSE_REHOME_TO_HIGHER_PRIORITY_CM public static final int 1006 CAUSE_REHOMING_FAILURE public static final int 1073750021 ID public static final int CiscoPartyInfo com.cisco.jtapi.extensions.CiscoPartyInfo 6 ABBREVIATED_NUMBER public static final int 1 INTERNATIONAL_NUMBER public static final int 2 NATIONAL_NUMBER public static final int 3 NET_SPECIFIC_NUMBER public static final int 7 RESERVED_FOR_EXTENSION public static final int 4 SUBSCRIBER_NUMBER public static final int 0 UNKNOWN_NUMBER public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1690 Constant Field Values CiscoOutOfServiceEv

Page 1754 diagram

Page 1755

CiscoProvCallParkEv com.cisco.jtapi.extensions.CiscoProvCallParkEv 1073754113 ID public static final int 2 PARK_STATE_ACTIVE public static final int 1 PARK_STATE_IDLE public static final int 1 REASON_CALLPARK public static final int 3 REASON_CALLPARKREMAINDER public static final int 3 REASON_CALLPARKREMINDER public static final int 2 REASON_CALLUNPARK public static final int CiscoProvFeatureID com.cisco.jtapi.extensions.CiscoProvFeatureID 1234 MONITOR_CALLPARK_DN public static final int CiscoProviderCapabilityChangedEv com.cisco.jtapi.extensions.CiscoProviderCapabilityChangedEv 1073741846 ID public static final int 32 MODIFY_CGPN public static final int 64 MONITOR_PARKDN public static final int 16 SUPERPROVIDER public static final int CiscoProvTerminalCapabilityChangedEv com.cisco.jtapi.extensions.CiscoProvTerminalCapabilityChangedEv 1073741847 ID public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1691 Constant Field Values CiscoProvCallParkEv

Page 1755 diagram

Page 1756

CiscoRemoteTerminal com.cisco.jtapi.extensions.CiscoRemoteTerminal 8 EXTEND_MEDIA_REGISTRATION public static final int 0 NO_EXTEND_MEDIA_REGISTRATION public static final int CiscoRestrictedEv com.cisco.jtapi.extensions.CiscoRestrictedEv 0 CAUSE_UNKNOWN public static final int 3 CAUSE_UNSUPPORTED_DEVICE_CONFIGURATION public static final int 2 CAUSE_UNSUPPORTED_PROTOCOL public static final int 1 CAUSE_USER_RESTRICTED public static final int 1073741833 ID public static final int CiscoRouteSession com.cisco.jtapi.extensions.CiscoRouteSession public static final int 1 CALLINGADDRESS_SEARCH_SPACE public static final int -1932787506 CAUSE_CTIERR_FAC_CMC_REASON_CMC_INVALID public static final int -1932787509 CAUSE_CTIERR_FAC_CMC_REASON_CMC_NEEDED public static final int -1932787508 CAUSE_CTIERR_FAC_CMC_REASON_FAC_CMC_NEEDED public static final int -1932787507 CAUSE_CTIERR_FAC_CMC_REASON_FAC_INVALID public static final int -1932787510 CAUSE_CTIERR_FAC_CMC_REASON_FAC_NEEDED public static final int 0 DEFAULT_SEARCH_SPACE public static final int 0 DONOT_RESET_ORIGINALCALLED public static final int 7 ERROR_INVALID_STATE public static final int 6 ERROR_NO_CALLBACK public static final int 4 ERROR_NONE public static final int 5 ERROR_ROUTESELECT_TIMEOUT public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1692 Constant Field Values CiscoRemoteTerminal

Page 1756 diagram

Page 1757

com.cisco.jtapi.extensions.CiscoRouteSession 1 RESET_ORIGINALCALLED public static final int 2 ROUTEADDRESS_SEARCH_SPACE public static final int CiscoRouteTerminal com.cisco.jtapi.extensions.CiscoRouteTerminal 2 DYNAMIC_MEDIA_REGISTRATION public static final int 0 NO_MEDIA_REGISTRATION public static final int CiscoRTPBitRate com.cisco.jtapi.extensions.CiscoRTPBitRate 1 R5_3 public static final int 2 R6_4 public static final int CiscoRTPInputKeyEv com.cisco.jtapi.extensions.CiscoRTPInputKeyEv 1073758214 ID public static final int CiscoRTPInputStartedEv com.cisco.jtapi.extensions.CiscoRTPInputStartedEv 1073758209 ID public static final int CiscoRTPInputStoppedEv com.cisco.jtapi.extensions.CiscoRTPInputStoppedEv 1073758210 ID public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1693 Constant Field Values CiscoRouteTerminal

Page 1757 diagram

Page 1758

CiscoRTPOutputKeyEv com.cisco.jtapi.extensions.CiscoRTPOutputKeyEv 1073758215 ID public static final int CiscoRTPOutputStartedEv com.cisco.jtapi.extensions.CiscoRTPOutputStartedEv 1073758211 ID public static final int CiscoRTPOutputStoppedEv com.cisco.jtapi.extensions.CiscoRTPOutputStartedEv 1073758212 ID public static final int CiscoRTPPayload com.cisco.jtapi.extensions.CiscoRTPPayload 81 ACTIVEVOICE public static final int 15 ACY_G729AASSN public static final int 33 DATA56 public static final int 32 DATA64 public static final int 3 G711ALAW56K public static final int 2 G711ALAW64K public static final int 5 G711ULAW56K public static final int 4 G711ULAW64K public static final int 8 G722_48K public static final int 7 G722_56K public static final int 6 G722_64K public static final int 9 G7231 public static final int 10 G728 public static final int 11 G729 public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1694 Constant Field Values CiscoRTPOutputKeyEv

Page 1758 diagram

Page 1759

com.cisco.jtapi.extensions.CiscoRTPPayload 12 G729ANNEXA public static final int 80 GSM public static final int 13 IS11172AUDIOCAP public static final int 14 IS13818AUDIOCAP public static final int 1 NONSTANDARD public static final int 25 WIDEBAND_256K public static final int CiscoTermActivatedEv com.cisco.jtapi.extensions.CiscoTermActivatedEv 1073741843 ID public static final int CiscoTermButtonPressedEv com.cisco.jtapi.extensions.CiscoTermButtonPressedEv 10 CHARA public static final int 11 CHARB public static final int 12 CHARC public static final int 13 CHARD public static final int 8 EIGHT public static final int 5 FIVE public static final int 4 FOUR public static final int 1073745936 ID public static final int 9 NINE public static final int 1 ONE public static final int 15 POUND public static final int 7 SEVEN public static final int 6 SIX public static final int 14 STAR public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1695 Constant Field Values CiscoTermActivatedEv

Page 1759 diagram

Page 1760

com.cisco.jtapi.extensions.CiscoTermButtonPressedEv 3 THREE public static final int 2 TWO public static final int 0 ZERO public static final int CiscoTermConnMonitoringEndEv com.cisco.jtapi.extensions.CiscoTermConnMonitoringEndEv 1073762311 ID public static final int CiscoTermConnMonitoringStartEv com.cisco.jtapi.extensions.CiscoTermConnMonitoringStartEv 1073762310 ID public static final int CiscoTermConnMonitorInitiatorInfoEv com.cisco.jtapi.extensions.CiscoTermConnMonitorInitiatorInfoEv 1073762313 ID public static final int CiscoTermConnMonitorTargetInfoEv com.cisco.jtapi.extensions.CiscoTermConnMonitorTargetInfoEv 1073762314 ID public static final int CiscoTermConnPrivacyChangedEv com.cisco.jtapi.extensions.CiscoTermConnPrivacyChangedEv 1073762305 ID public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1696 Constant Field Values CiscoTermConnMonitoringEndEv

Page 1760 diagram

Page 1761

CiscoTermConnRecordingEndEv com.cisco.jtapi.extensions.CiscoTermConnRecordingEndEv 1073762309 ID public static final int CiscoTermConnRecordingStartEv com.cisco.jtapi.extensions.CiscoTermConnRecordingStartEv 1073762308 ID public static final int CiscoTermConnRecordingTargetInfoEv com.cisco.jtapi.extensions.CiscoTermConnRecordingTargetInfoEv 1073762312 ID public static final int CiscoTermConnSelectChangedEv com.cisco.jtapi.extensions.CiscoTermConnSelectChangedEv 1073762307 ID public static final int CiscoTermCreatedEv com.cisco.jtapi.extensions.CiscoTermCreatedEv 1073745921 ID public static final int CiscoTermDataEv com.cisco.jtapi.extensions.CiscoTermDataEv 1073745922 ID public static final int CiscoTermDeviceStateActiveEv com.cisco.jtapi.extensions.CiscoTermDeviceStateActiveEv 1073745926 ID public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1697 Constant Field Values CiscoTermConnRecordingEndEv

Page 1761 diagram

Page 1762

CiscoTermDeviceStateAlertingEv com.cisco.jtapi.extensions.CiscoTermDeviceStateAlertingEv 1073745927 ID public static final int CiscoTermDeviceStateHeldEv com.cisco.jtapi.extensions.CiscoTermDeviceStateHeldEv 1073745928 ID public static final int CiscoTermDeviceStateIdleEv com.cisco.jtapi.extensions.CiscoTermDeviceStateIdleEv 1073745929 ID public static final int CiscoTermDeviceStateWhisperEv com.cisco.jtapi.extensions.CiscoTermDeviceStateWhisperEv 1073745941 ID public static final int CiscoTermDNDOptionChangedEv com.cisco.jtapi.extensions.CiscoTermDNDOptionChangedEv 1073745942 ID public static final int CiscoTermDNDStatusChangedEv com.cisco.jtapi.extensions.CiscoTermDNDStatusChangedEv 1073745940 ID public static final int CiscoTerminal com.cisco.jtapi.extensions.CiscoTerminal 2 ASCII_ENCODING public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1698 Constant Field Values CiscoTermDeviceStateAlertingEv

Page 1762 diagram

Page 1763

com.cisco.jtapi.extensions.CiscoTerminal 1 DEVICESTATE_ACTIVE public static final int 2 DEVICESTATE_ALERTING public static final int 3 DEVICESTATE_HELD public static final int 0 DEVICESTATE_IDLE public static final int 4 DEVICESTATE_UNKNOWN public static final int 5 DEVICESTATE_WHISPER public static final int 0 CiscoTerminal.DEVICETYPE_UNKNOWN public static final int 30027 CiscoTerminal.DEVICETYPE_ANALOG_PHONE public static final int 547 CiscoTerminal.DEVICETYPE_CISCO_6901 public static final int 548 CiscoTerminal.DEVICETYPE_CISCO_6911 public static final int 495 CiscoTerminal.DEVICETYPE_CISCO_6921 public static final int 496 CiscoTerminal.DEVICETYPE_CISCO_6941 public static final int 564 CiscoTerminal.DEVICETYPE_CISCO_6945 public static final int 497 CiscoTerminal.DEVICETYPE_CISCO_6961 public static final int 369 CiscoTerminal.DEVICETYPE_CISCO_7906 public static final int 6 CiscoTerminal.DEVICETYPE_TELECASTER_BID public static final int 307 CiscoTerminal.DEVICETYPE_CISCO_7911 public static final int 124 CiscoTerminal.DEVICETYPE_14_BUTTON_SIDECAR public static final int 227 CiscoTerminal.DEVICETYPE_7915_12_BUTTON_SIDECAR public static final int 228 CiscoTerminal.DEVICETYPE_7915_24_BUTTON_SIDECAR public static final int 229 CiscoTerminal.DEVICETYPE_7916_12_BUTTON_SIDECAR public static final int 230 CiscoTerminal.DEVICETYPE_7916_24_BUTTON_SIDECAR public static final int 232 CiscoTerminal.DEVICETYPE_CKEM_36_BUTTON public static final int 365 CiscoTerminal.DEVICETYPE_CP7921 public static final int 484 CiscoTerminal.DEVICETYPE_CISCO_7925 public static final int 577 CiscoTerminal.DEVICETYPE_CISCO_7926 public static final int 348 CiscoTerminal.DEVICETYPE_7931 public static final int 9 CiscoTerminal.DEVICETYPE_IP_CONFERENCE_PHONE public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1699 Constant Field Values Constant Field Values

Page 1763 diagram

Page 1764

com.cisco.jtapi.extensions.CiscoTerminal 30019 CiscoTerminal.DEVICETYPE_CISCO_7936 public static final int 431 CiscoTerminal.DEVICETYPE_CISCO_7937 public static final int 8 CiscoTerminal.DEVICETYPE_TELECASTER_BUSINESS public static final int 115 CiscoTerminal.DEVICETYPE_CISCO_7941 public static final int 309 CiscoTerminal.DEVICETYPE_CISCO_7941G_GE public static final int 434 CiscoTerminal.DEVICETYPE_CISCO_7942 public static final int 435 CiscoTerminal.DEVICETYPE_CISCO_7945 public static final int 7 CiscoTerminal.DEVICETYPE_TELECASTER_MGR public static final int 30018 CiscoTerminal.DEVICETYPE_CISCO_7961 public static final int 308 CiscoTerminal.DEVICETYPE_CISCO_7961G_GE public static final int 404 CiscoTerminal.DEVICETYPE_CISCO_7962 public static final int 436 CiscoTerminal.DEVICETYPE_CISCO_7965 public static final int 30006 CiscoTerminal.DEVICETYPE_CISCO_7970 public static final int 119 CiscoTerminal.DEVICETYPE_CISCO_7971 public static final int 437 CiscoTerminal.DEVICETYPE_CISCO_7975 public static final int 302 CiscoTerminal.DEVICETYPE_CISCO_7989 public static final int 586 CiscoTerminal.DEVICETYPE_CISCO_8941 public static final int 585 CiscoTerminal.DEVICETYPE_CISCO_8945 public static final int 540 CiscoTerminal.DEVICETYPE_CISCO_8961 public static final int 537 CiscoTerminal.DEVICETYPE_9951 public static final int 493 CiscoTerminal.DEVICETYPE_CISCO_9971 public static final int 12 CiscoTerminal.DEVICETYPE_ATA_186 public static final int 550 CiscoTerminal.DEVICETYPE_CISCO_ATA_187 public static final int 593 CiscoTerminal.DEVICETYPE_CISCO_CIUS public static final int 632 CiscoTerminal.DEVICETYPE_CISCO_CIUS_SP public static final int 30016 CiscoTerminal.DEVICETYPE_CISCO_SOFTPHONE_SE_M public static final int 358 CiscoTerminal.DEVICETYPE_CISCO_UNIFIED_COMMUNICATOR public static final int 468 CiscoTerminal.DEVICETYPE_CISCO_UNIFIED_MOBILE_COMMUNICATOR public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1700 Constant Field Values Constant Field Values

Page 1764 diagram

Page 1765

com.cisco.jtapi.extensions.CiscoTerminal 648 CiscoTerminal.DEVICETYPE_CISCO_UNIFIED_COMMUNICATIONS_FOR_RTX public static final int 503 CiscoTerminal.DEVICETYPE_CLIENT_SERVICES_FRAMEWORK public static final int 10 CiscoTerminal.DEVICETYPE_VGC_PHONE public static final int 72 CiscoTerminal.DEVICETYPE_CTI_PORT public static final int 73 CiscoTerminal.DEVICETYPE_CTI_ROUTE_POINT public static final int 71 CiscoTerminal.DEVICETYPE_DEVICE_PILOT public static final int 30028 CiscoTerminal.DEVICETYPE_ISDN_BRI_PHONE public static final int 635 CiscoTerminal.DEVICETYPE_CTI_REMOTE_DEVICE public static final int 2 DND_OPTION_CALL_REJECT public static final int 0 DND_OPTION_NONE public static final int 1 DND_OPTION_RINGER_OFF public static final int 1 IN_SERVICE public static final int 0 IP_ADDRESSING_MODE_IPV4 public static final int 2 IP_ADDRESSING_MODE_IPV4_V6 public static final int 1 IP_ADDRESSING_MODE_IPV6 public static final int 3 IP_ADDRESSING_MODE_UNKNOWN public static final int 4 IP_ADDRESSING_MODE_UNKNOWN_ANATRED public static final int 1 NOT_APPLICABLE public static final int 0 OUT_OF_SERVICE public static final int 3 UCS2UNICODE_ENCODING public static final int 0 UNKNOWN_ENCODING public static final int CiscoTerminalConnection com.cisco.jtapi.extensions.CiscoTerminalConnection 1 CISCO_SELECTEDLOCAL public static final int 0 CISCO_SELECTEDNONE public static final int 2 CISCO_SELECTEDREMOTE public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1701 Constant Field Values CiscoTerminalConnection

Page 1765 diagram

Page 1766

com.cisco.jtapi.extensions.CiscoTerminalConnection 3 PROTOCOL_CTI_REMOTE_DEVICE public static final int 0 RECORDING_INVOCATION_TYPE_SILENT public static final int 1 RECORDING_INVOCATION_TYPE_USER public static final int CiscoTerminalProtocol com.cisco.jtapi.extensions.CiscoTerminalProtocol 0 PROTOCOL_NONE public static final int 1 PROTOCOL_SCCP public static final int 2 PROTOCOL_SIP public static final int CiscoTermInServiceEv com.cisco.jtapi.extensions.CiscoTermInServiceEv 1073745923 ID public static final int CiscoTermOutOfServiceEv com.cisco.jtapi.extensions.CiscoTermOutOfServiceEv 1073745924 ID public static final int CiscoTermRegistrationFailedEv com.cisco.jtapi.extensions.CiscoTermRegistrationFailedEv 15 DB_INITIALIZATION_ERROR public static final int 1073745937 ID public static final int 19 IP_ADDRESSING_MODE_MISMATCH public static final int 8 MEDIA_ALREADY_TERMINATED_DYNAMIC public static final int 6 MEDIA_ALREADY_TERMINATED_NONE public static final int 7 MEDIA_ALREADY_TERMINATED_STATIC public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1702 Constant Field Values CiscoTerminalProtocol

Page 1766 diagram

Page 1767

com.cisco.jtapi.extensions.CiscoTermRegistrationFailedEv 10 MEDIA_CAPABILITY_MISMATCH public static final int 11 OWNER_NOT_ALIVE public static final int 0 UNKNOWN public static final int CiscoTermRemovedEv com.cisco.jtapi.extensions.CiscoTermRemovedEv 1073745925 ID public static final int CiscoTermRestrictedEv com.cisco.jtapi.extensions.CiscoTermRestrictedEv 1073741841 ID public static final int CiscoTermSnapshotCompletedEv com.cisco.jtapi.extensions.CiscoTermSnapshotCompletedEv 1073745939 ID public static final int CiscoTermSnapshotEv com.cisco.jtapi.extensions.CiscoTermSnapshotCompletedEv 1073745938 ID public static final int CiscoTone com.cisco.jtapi.extensions.CiscoTone 49 ZIPZIP public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1703 Constant Field Values CiscoTermRemovedEv

Page 1767 diagram

Page 1768

CiscoToneChangedEv com.cisco.jtapi.extensions.CiscoToneChangedEv 1 CMC_REQUIRED public static final int 2 FAC_CMC_REQUIRED public static final int 0 FAC_REQUIRED public static final int 1073754119 ID public static final int CiscoTransferEndEv com.cisco.jtapi.extensions.CiscoTransferEndEv 1073754117 ID public static final int CiscoTransferStartEv com.cisco.jtapi.extensions.CiscoTransferStartEv 1073754118 ID public static final int CiscoUrlInfo com.cisco.jtapi.extensions.CiscoUrlInfo 1 TRANSPORT_TYPE_TCP public static final int 2 TRANSPORT_TYPE_UDP public static final int 1 URL_TYPE_SIP public static final int 2 URL_TYPE_TEL public static final int 0 URL_TYPE_UNKNOWN public static final int CiscoWideBandMediaCapability com.cisco.jtapi.extensions.CiscoWideBandMediaCapability 10 FRAMESIZE_TEN_MILLISECOND_ PACKET public static final int Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1704 Constant Field Values CiscoToneChangedEv

Page 1768 diagram

Page 1769

Alarm com.cisco.services.alarm.Alarm 1 ALERTS public static final int 2 CRITICAL public static final int 7 DEBUGGING public static final int 0 EMERGENCIES public static final int 3 ERROR public static final int 7 HIGHEST_LEVEL public static final int 6 INFORMATIONAL public static final int 0 LOWEST_LEVEL public static final int -1 NO_SEVERITY public static final int 5 NOTIFICATION public static final int “UNK” UNKNOWN_MNEMONIC public static final java.lang.String 4 WARNING public static final int LogFileTraceWriter com.cisco.services.tracing.LogFileTraceWriter “trace” DEFAULT_FILE_NAME_BASE public static final java.lang.String “log” DEFAULT_FILE_NAME_EXTENSION public static final java.lang.String 95 DIR_BASE_NAME_NUM_SEPERATOR public static final char 10240 MIN_FILE_SIZE public static final int 2 MIN_FILES public static final int 1024 ROLLOVER_THRESHOLD public static final int Trace com.cisco.services.tracing.Trace 1 ALERTS public static final int “ALERTS” ALERTS_TRACE_NAME public static final java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1705 Constant Field Values Alarm

Page 1769 diagram

Page 1770

com.cisco.services.tracing.Trace 2 CRITICAL public static final int “CRITICAL” CRITICAL_TRACE_NAME public static final java.lang.String 7 DEBUGGING public static final int “DEBUGGING” DEBUGGING_TRACE_NAME public static final java.lang.String 0 EMERGENCIES public static final int “EMERGENCIES” EMERGENCIES_TRACE_NAME public static final java.lang.String 3 ERROR public static final int “ERROR” ERROR_TRACE_NAME public static final java.lang.String 7 HIGHEST_LEVEL public static final int 6 INFORMATIONAL public static final int “INFORMATIONAL” INFORMATIONAL_TRACE_NAME public static final java.lang.String 0 LOWEST_LEVEL public static final int 5 NOTIFICATION public static final int “NOTIFICATION” NOTIFICATION_TRACE_NAME public static final java.lang.String 4 WARNING public static final int “WARNING” WARNING_TRACE_NAME public static final java.lang.String Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1706 Constant Field Values Constant Field Values

Page 1770 diagram

Page 1771

A P P E N D I X G Caveats This appendix provides details of the JTAPI caveats that are common across releases and those that are release-specific. • Caveats for All Releases, on page 1707 • Caveats for Release 9.1(1), on page 1712 • Caveats for Release 8.6(1), on page 1714 • Caveats for Release 8.5(1), on page 1714 • Caveats for Release 8.0(1), on page 1716 • Caveats for Release 7.0.1, on page 1717 • Caveats for Release 6.0.1, on page 1719 • Caveats for Release 5.0, on page 1719 • Caveats for Release 4.1, on page 1723 • Caveats for 4.0, on page 1724 Caveats for All Releases This section lists the caveats that are common for all JTAPI releases and contains these topics: • Translation Pattern Support, on page 1709 • DT24+ Limitation with PRI NI2 Trunk, on page 1709 • Connection for Park Number Not Created, on page 1710 • Inconsistency Between SIP and SCCP Phone, on page 1710 • Failure to Route Calls Across Destinations, on page 1710 • Incorrect Return Value for getCallingAddress(), on page 1710 • Call Fails to Disconnect Held Shared Line, on page 1711 • Limitation with sendData() API on CiscoTerminal, on page 1711 • Limitation in Using ; (Semi-Colon) and = (Equal) in User ID and Password, on page 1711 • Connection to Unknown Address When Unparking a Conference Call, on page 1711 • CTI Redirect to Voice Mail Wont Work with QSIG, on page 1712 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1707

Image 1 from page 1771

Page 1771 content

Page 1772

• Unsupported CTI Events for SIP Phones, on page 1712 Single Versus Multiple CallObserver Clarification There are two primary ways to observe addresses with Cisco JTAPI's CallObservers: an application can observe all of the addresses with a single CallObserver object or it can have a separate CallObserver object for each of address. These two approaches cause slightly different events to be seen, mostly with regard to reason codes. When an application uses a single CallObserver to observe all the addresses, they are connected with one object. When A calls B, both the events at A and at B are sent to the same CallObserver object. If B redirects to C, and C was observed with the same object, all its events are delivered to the same observer. The application observes the CallCtlConnOfferedEv to C with reason REDIRECT, because the observer at C knew all about the previous events on the call. Conversely, when an application uses an independent CallObserver for each Address, this information is not so easily shared. When A calls B, call events of A go to the observer for A, and B's go to the observer for B. They each know about the other end, for example A will know that B is ringing, but they are no longer the same observer. When B redirects the call to C, the observer at C knows absolutely nothing about the call. The observer at C was not involved in the original call at all, and does not know who is on it, what events had happened previously. This information has to be made up by JTAPI to build an accurate call model at C. All the call events for a basic call between A and B have to be simulated so that the call model, from C's perspective makes sense. This is done by using a snapshot event. JTAPI looks at the call, in this case the one between A and B, and figures out what events have to have happened for the call to exist the way it does. This makes up up the basic call events required, and give them to the observer on C, so that it can build a proper call model. Since this event set is made up by JTAPI, the reason codes are not available. For example, if A had originally called D, and D redirected to B, the made up snapshot event set would not be concerned with the redirect at all. JTAPI does not store this information anywhere, and when it generates a snapshot, it creates the simplest event set possible to recreate the call model, and reports all the events with reason NORMAL. So, when A calls B, and then B redirects to C, the observer on C gets a snapshot event that allows it to recreate the call model for a basic call from A to B. Also in this snapshot event is the CallCtlConnOfferedEv for C. As part of the snapshot, this event comes in with reason NORMAL, even though it is the result of a redirect. CallObservers on A or B will see the CallCtlConnOfferedEv for C with reason REDIRECT, but there is no way for the observer at C to know that. This creates a noticeable difference in the reason codes available to applications depending on how they implement their CallObservers. There have not been any issues regarding this from the customer side. This is the way it has been since Cisco JTAPI's inception and this is a clarification of the existing behavior. SIPandSCCPDialingDifferenceswithOverlappingDirectoryNumberPatterns An overlapping Directory Number Pattern is when one Directory Number is a part of a longer Directory Number. For example, a Directory Number 1000 overlaps a Directory Number 10001. Cisco Unified Communications Manager (Cisco Unified CM) and JTAPI both support overlapping Directory Number patterns, but there are some important things to note regarding this. When you dial 1000 from a normal phone, there is a delay. The Cisco Unified CM does not know if you want to dial 1000 or 10001, so it waits for you to make a choice. This Digit Analyzer waits for 15 seconds if you press nothing else. During this time, nothing happens, no call is extended, and it just sounds like a dead call Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1708 Caveats Single Versus Multiple CallObserver Clarification

Page 1772 content

Page 1773

for the calling party. This can be short circuited by hitting # to let Cisco Unified CM know that you actually intend to call 1000. The 15 second wait is a configurable service parameter, known as T302 Timer, and can be set as low as 3 seconds. JTAPI using SCCP phones avoid the Digit Analyzer entirely by communicating directly with Cisco Unified CM. JTAPI sends the intended Directory Number when it is making a call, and if it sends 1000, it means only that, and Cisco Unified CM knows it will not be dialing any more digits. JTAPI using SIP phones is quite different. JTAPI communicates with the phone, which then communicates with the Cisco Unified CM. The phone takes care of the dialing, and JTAPI will pass it the digits 1000 to dial. Due to this, JTAPI cannot avoid the Digit Analyzer, and is subject to the T302 wait outlined above. JTAPI sits idly and waits while the Digit Analyzer figures out that the SIP phone actually wants to dial 1000. Apart from this, by default the JTAPI CTI Postcondition value is also set to 15 seconds. This means that when JTAPI sends a request to the CTI layer, it waits for 15 seconds before it assumes something has gone wrong, and throws a timeout exception. This means that the delay for Digit Analysis for overlapping DN patterns is very likely to cause JTAPI to time out. The Digit Analysis delay cannot be completely removed for SIP phones, but this problem can be greatly mitigated through the use of service or jtapi.ini parameters. As noted above, the T302 Timer for Digit Analysis can be set as low as three seconds, which is much lower than the 15 it takes JTAPI to time out. You can also increase the JTAPI CTI Postcondition timeout to 20 seconds in the jtapi.ini file. This issue can also be avoided by not having overlapping DNs. Translation Pattern Support If the callingparty transformation mask is configured for a Translation Pattern that is applied to the controlled addresses of JTAPI application, the application may observe some extra connections being created and disconnected when the application observes both calling and called party. Otherwise, a connection is created for the transformed callingparty and CiscoCall.getCurrentCallingParty() returns the transformed calling party address when the application observes only the called party. In general, JTAPI has a problem in creating an appropriate call connection and may not be able to provide correct callinfo such as currentCalling, currentCalled, calling, called, and lastRedirecting parties. For example, Translation Pattern X is configured with calling party transformation mask Y and calledparty transformation mask B; A calls X, and call goes to B. In this scenario: • If the application observes only B, JTAPI creates connection for Y and B, and CiscoCall.getCurrentCallingParty() returns Address Y. • If the application observes both A and B, connections for A and B are created, connection for Y is temporarily created and dropped, and CiscoCall.getCurrentCallingParty() returns Address Y. Other inconsistencies could occur in callinfo if more features are used for basic call. It is recommended that you do not configure callingparty transformation mask for Translation Pattern which might get applied to JTAPI Application controlled Addresses. DT24+ Limitation with PRI NI2 Trunk When a PRI NI2 trunk used by DT24+ gateway is involved in a call scenario between two clusters, for example, A from cluster-1 calls B in cluster-2 via DT24+ PRI NI2 trunk, the LastRedirectAddress and CalledAddress may not be accurate on B’s side. Besides, if there are any changes for A’s side of the call in cluster-1 due to redirect, transfer, or forward, the changed information is not propagated to B’s side due to protocol limitation of PRI NI2 truck. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1709 Caveats Translation Pattern Support

Page 1773 content

Page 1774

Connection for Park Number Not Created JTAPI does not create a Queued state connection for Park Number if the call is parked across the gateway. There are two possibilities here: 1. If CLI is configured, application sees an Unknown connection 2. If CLI is not configured, the calling does not see any Unknown connection. For Example, If A calls B across gateway (with CLI configured) and B parks the call then A sees an unknown connection instead of a connection (with STATE = QUEUED) for Park Number. But, if A calls B across gateway (with no CLI configured) and B parks the call then A does not see any new connection. Inconsistency Between SIP and SCCP Phone sendData() API on CiscoTerminal is used to send data to the phone. In case of SIP phones, if invalid byte data is sent by the application, the method throws PlatformException. However, in case of SCCP phones, the byte data sent in the request is not validated, and would return successfully without throwing an exception. Failure to Route Calls Across Destinations When a call is redirected to a device outside the cluster over an H323 gateway that is out of service, before call control can determine the Out-of-Service status of H323 gateway, the call is disconnected. This is because the default value of the service parameter CTI NewCallAccept timer is four seconds where as call control takes five seconds to determine that the gateway is out of service, so calls are disconnected due to expiration of CTI NewCallAccept timeout. Implications of the above behavior is seen in JTAPI selectRoute() API which internally uses CTI redirect API to route the call. If applications specify multiple destinations with selectRoute() and the first destination is across an out-of-service H323 gateway, the call fails before JTAPI can route the call to the second destination. Hence JTAPI, cannot route the call to the second route specified in selectRoute() interface call. To avoid this, the value of CTI New Call Accept Timer service parameter can be set as greater than H225 TCP Timer service parameter. Incorrect Return Value for getCallingAddress() In a transfer scenario, where caller and transferController are not observed, that is, where A calls B and transfers the call to C and the application is observing only C then before the transfer, JTAPI will not have any information about the first call (that is, call from A to B). So, when the transfer feature is invoked, the calling and called address are B and C respectively. On completing the transfer, application updates callInfo and JTAPI exposes the correct parties through getCurrentCallingAddress(), getCurrentCalledAddress(), getModifiedCallingAddress(), and getModifiedCalledAddress(). However, getCallingAddress() API which should return the original calling address still reports B, that is, the original calling party of B to C call. To avoid this issue, application can observe the controller as well, so that JTAPI expose the correct party (that is A, in this case) with getCallingAddress() API. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1710 Caveats Connection for Park Number Not Created

Page 1774 content

Page 1775

Call Fails to Disconnect Held Shared Line In a scenario where A calls B (B is a shared line present on terminals T1 and T2); privacy is set as ON for T1 and initially CUCM service parameter Enforce Privacy Settings on held calls is set to True. B(T1) answers and goes to Talking state while B(T2) goes to Passive state (TermConn = Passive; CallCtlTermConn = InUse). B(T1) puts the call on hold, since Enforce Privacy Setting on held calls is set to True, B(T2) remains in passive state (TermConn = Passive; CallCtlTermConn = InUse). Now the service parameter Enforce Privacy Settings on held calls is set to False. This does not trigger any change in the state of TerminalConnection, so B(T2) still remains Passive-InUse (TermConn = Passive; CallCtlTermConn = InUse). At this point, if the application sets the requestController as B(T1) and disconnects the call at B, the connection of B is not disconnected and call does not go IDLE. Even on the phones, the call on A remains in Established state while the other party in call is B(T2) which remains in Passive-InUse (TermConn = Passive; CallCtlTermConn = InUse) state. Call is cleared when A disconnects the call. Limitation with sendData() API on CiscoTerminal If JTAPI applications make simultaneous back to back requests for sendData() API on the same CiscoTerminal, without any delay between requests, then some of these requests may fail. Applications cannot determine whether a request was successful or not, as Cisco JTAPI API returns successfully as soon as the phone receives data and does not wait for a response from the phone. Also, the IP phone might display a blank screen on sending simultaneous requests to send data. To avoid these issues, JTAPI applications should ensure some time delay between two successive sendData() requests while pushing XSI data to the IP phones via Cisco JTAPI. Limitation in Using ; (Semi-Colon) and = (Equal) in User ID and Password Sun JTAPI 1.2 specification does not support use of the semicolon ';' and equals ' = ' characters when populating the Host Name, UserID, and Password fields in string used as parameter in getProvider() method. If ';' or ' = ' are used in these fields, items such as 'pass = word' or 'pass;word' are treated as 'pass' and your request could fail and you must not use these characters in userid and password fields. Connection to Unknown Address When Unparking a Conference Call When a conference call is parked, JTAPI call will have connection to the remaining parties in the call. When this call is unparked using the UnPark API or connect API, connections to unknown address will be temporarily created. This connection to unknown address will be disconnected when un park is completed. The following will be seen in JTAPI traces: 2002 : (P1-InProv) 103023/1 ConnCreatedEv Unknown:null:4 187 Cause:100 CallCtlCause:0 CiscoCause:31 FeatReason:10 CAUSE_NORMAL .... 2002 : (P1-InProv) 103023/1 ConnDisconnectedEv Unknown:null:4 187 Cause:100 CallCtlCause:0 CiscoCause:31 FeatReason:10 CAUSE_NORMAL Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1711 Caveats Call Fails to Disconnect Held Shared Line

Page 1775 content

Page 1776

CTI Redirect to Voice Mail Wont Work with QSIG When applications redirect a call to voice mail through a QSIG trunk, voice mail will not play the voice prompt of the redirecting party. A generic prompt asking the user to enter the voice mail box is played. This is due to the fact that CTI redirect doesn't pass correct original called party and redirecting party to the voice mail system. Applications can work around this by using a SIP trunk. Phone A calls Phone B (CUCILYNC in Deskphone mode). Toast popup of "envelope" appears for incoming call. User clicks on the envelope, redirecting the call across an H.323 trunk with QSIG tunneling. Unity/Unity Connection won't recognize original called party, so call will not go to user's voice mailbox. This is because Re-direct/Original Called Party information not carried across the trunk when CTI redirect is used. CiscoAddress.getForwarding() Returns Correct Value Only for In-Service Addresses Although the Sun JTAPI 1.2 specification does not specify any preconditions for CallControlAddress.getForwarding(), the implementation of this method in Cisco JTAPI will return a correct value only if the address is in service. When invoked on an out of service address this method will just return a NULL value. Unsupported CTI Events for SIP Phones The following CTI events are not generated for SIP phones. Third party applications that expect these call events should use SCCP phones: • CallOpenLogicalChannelEvent • CallRingEvent • DeviceLampModeChangedEvent • DeviceModeChangedEvent • DeviceDisplayChangedEvent • DeviceFeatureButtonPressedEvent • DeviceKeyPressedEvent • DeviceLampModeChangedEvent • DeviceRingModeChangedEvent Caveats for Release 9.1(1) This section lists the JTAPI caveats for Release 9.1(1). • Connection for Park DN While UnPark, on page 1713 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1712 Caveats CTI Redirect to Voice Mail Wont Work with QSIG

Page 1776 content

Page 1777

Connection for Park DN While UnPark Cisco JTAPI will no longer create the temporary connections for the Park/DPark number in the final call when a parked call is unparked. This change in behavior will be seen in and above the following Cisco JTAPI versions - 8.5.1.10000-10, 8.6.1.10000-4, 8.6.2.10000-2 and 8.6.2.98000-2 Scenario: GC1: A calls B, B parks a call is parked at 1000 GC2: B unparks “Preserve globalCallId for Parked Calls” is set to false Previous behavior on unpark: GC2 CallActiveEvGC2 ConnCreatedEv B GC2 ConnCreatedEv 1000 GC2 CallCtlConnEstablishedEv B GC2 ConnCreatedEv A GC2 ConnDisconnetedEv 1000 GC2 CallCtlConnEstablishedEv A GC1 CallChangedEv GC1 ConnDisconenctedEv 1000 GC1 ConnDisconenctedEv A GC1 CallInvalidEv Current behavior on unpark: Connection for 1000 will not be created in GC2 GC2 CallActiveEvGC2 ConnCreatedEv B GC2 CallCtlConnEstablishedEv B GC2 ConnCreatedEv A GC2 CallCtlConnEstablishedEv A GC1 CallChangedEv GC1 ConnDisconenctedEv 1000 GC1 ConnDisconenctedEv A GC1 CallInvalidEv "Preserve globalCallId for Parked Calls" is set to true Previous behavior on unpark: GC2 CallActiveEvGC2 ConnCreatedEv B GC2 ConnCreatedEv 1000 GC2 CallCtlConnEstablishedEv B Gc2 CallChangedEv GC2 ConnDisconnetedEv 1000 GC2 CallCtlConnDisconnectedEv 1000 GC2 ConnDisconnetedEv B GC2 CallCtlConnDisconnectedEv B GC2 CallInvalidEv GC1 ConnCreatedEv 1000 GC1 ConnCreatedEv B Gc2 ConnDisconnectedEv 1000 GC1 CallCtlConnEstablishedEv B Current behavior on unpark: Connection for 1000 will not be created in GC1 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1713 Caveats Connection for Park DN While UnPark

Page 1777 content

Page 1778

GC2 CallActiveEvGC2 ConnCreatedEv B GC2 CallCtlConnEstablishedEv B GC1 ConnDisconnectedEv 1000 GC1 CallCtlConnDisconnectedEv 1000 Gc2 CallChangedEv GC1 ConnCreatedEv B GC1 ConnConnectedEv B GC1 CallCtlCallEstablishedEv B GC2 ConnDisconnetedEv B GC2 CallCtlConnDisconnectedEv B GC2 CallInvalidEv Caveats for Release 8.6(1) This section lists the JTAPI caveats for Release 8.6(1). • Limitation While Using a Cisco Telepresense MCU, on page 1714 Limitation While Using a Cisco Telepresense MCU In scenarios, where a conference chaining is done across cluster, the number of connection seen by the application might not be correct and application may not see the connection for the external conference bridge getting created. Example: A, B and B' are in Cluster 1D is in cluster 2 Application is observing D GC1: A calls D; Call offered on D and D answers GC2: D consults B; B answers B' CBarges into the call D completes conference - GC1.conference(GC2) After the conference is complete the application will see only the connection for A and D but not that of the conference bridge. Caveats for Release 8.5(1) This section lists the JTAPI caveats for Release 8.5(1). • Discouraged Use of JTAPIProperties.updateCertificate(), on page 1714 • Delete SecurityProperties Before Re-Use, on page 1715 • No ConnDisconnectedEv Event When Call Is Rejected, on page 1715 Discouraged Use of JTAPIProperties.updateCertificate() Applications are encouraged to move away from using the JTAPIProperties.updateCertificate() method to download certificates. The JTAPIProperties.setSecurityPropertyForInstance() method is superior for most applications, as it will store the security information in the jtapi.ini file, giving all the information to JTAPI Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1714 Caveats Caveats for Release 8.6(1)

Page 1778 content

Page 1779

whenever the application chooses to connect securely later. This information is critical for JTAPI to use the correct settings to create a secure connection, and if an application chooses to use the JTAPIProperties.updateCertificate() method, then the information will not be stored in the jtapi.ini file. Applications that have no reason not to, should move to setSecurityPropertyForInstance(). If an application is intentionally using the updateCertificate() method to avoid the use of jtapi.ini configurations, then the application must provide the information in the JTAPI Provider String, when it is first initializing JTAPI. The required fields are: • InstanceID • CertStorePassphrase • CAPF • CAPFPort • TFTP • TFTPPort • CertPath If an application chooses to use the updateCertificate() method and chooses not to provide the required security information in the Provider String, the behavior of JTAPI is not guaranteed. Delete SecurityProperties Before Re-Use The JTAPIProperties.setSecurityPropertyForInstance() method downloads certificates to disk, and stores security information related to them in the jtapi.ini file. If an application is interested in downloading new certificates to disk, changing the security information for the certificates, or both, is it recommended that they invoke JTAPIProperties.deleteSecurityPropertyForInstance() before doing so. This method will delete the certificates from disk, and remove the related SecurityProperty from the jtapi.ini file. This will ensure a fresh start for the new set of certificates, and help to eliminate any errors that could arise from "stale" certificates lingering around on disk. No ConnDisconnectedEv Event When Call Is Rejected For CUCM version 8.5.1 and later versions, when a call is made from A (observed) to B (unobserved) from application and if call is rejected for any reason, application will get the ConnFailedEv/CallCtlConnFailedEv events for the calling party, but there might be just one connection created in JTAPI for the calling party and there might not be any ConnDisconnectedEv/CallCtlConnDisconnectedEv events for called party. In addition, the ConnDisconnectedEv/CallCtlConnDisconnectedEv events for the calling party would be generated only after the calling party device/phone clears the call which itself can take 30 secs or more. Therefore, if application does not want to wait for the Disconnect events, upon getting the Failed events, it can simply clear the call directly after catching the failure from its call.connect() request as 'PlatformExceptionImpl caught: Could not meet post conditions of connect()'. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1715 Caveats Delete SecurityProperties Before Re-Use

Page 1779 content

Page 1780

Caveats for Release 8.0(1) This section lists the JTAPI caveats for Release 8.0(1). • Globalized Calling Party Number, on page 1716 • Conference Interaction with Chaperone Results in Unsupported Conference Chaining, on page 1716 • Wildcard Routepoint Interaction, on page 1717 • Inconsistent Address Type of ModifiedCalledAddress When a Call Is Made to a Hunt Pilot, on page 1717 Globalized Calling Party Number This caveat is a further clarification for Globalized Calling Party Number. With 8.0(1), there have been changes to the Call Processing and CTI layers that reflect the globalized calling party values that you see on the station more accurately. There are still some serious limitations with globalized parties: • The Globalized Calling Party Number is available on the called side. • The Globalized Calling Party Number is determined only when the call is offered. This applies to basic calls and for calls involving features. • The Globalized Calling Party Number does not change, even if the calling party changes. This is a clarification for the existing caveat Globalized Calling Party Number. • Globalized Calling Party will be applicable if the call is redirected, whether performed prior to call being connected or after call is connected. • Globalized Calling Party will not be provided after the these features are completed: Transfer, Conference, Unpark, Auto Call Pickup. Conference Interaction with Chaperone Results in Unsupported Conference Chaining If both caller and Chaperone complete conference, where caller completes conference before chaperone then the scenario results in Conference Chaining. As of release 8.0(1), such scenarios are not supported by JTAPI and currently connections for all the parties along with ConferenceChain connection are shown in a single call. For example, A calls B; call is intercepted by Chaperone (C1) which further consults B for conference. Before Chaperone completes conference, Caller(A) goes ahead and consults X for conference and completes the conference. After this, Chaperone(C1) completes the conference. This scenario would result in unexpected behavior from JTAPI Perspective. JTAPI could send CiscoConferenceStartedEv along with CiscoChainAddedEv. Also, after the conference, JTAPI shows connections for two Conference chains, A(caller), B, X, and C1(Chaperone) in the same call. This will be fixed in future releases by having connections of caller and X in one call which is chained to a different call with connections for C1 and B. The fix requires changes in multiple components which are tracked with CDETS: CSCtc76213(CTI), CSCtc76222(TSP), CSCtc76223(Conference) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1716 Caveats Caveats for Release 8.0(1)

Page 1780 content

Page 1781

Wildcard Routepoint Interaction Before 8.0(1), Wildcard Routepoint scenarios were not supported by JTAPI. This behavior is maintained in this release, in the spirit of Backward Compatibility, but is still unsupported. A new Service Parameter has been introduced in 8.0(1), WildCardDN as Called Party, which fixes several issues in the call model for Wildcard Routepoint scenarios. When this service parameter is turned on, Wildcard Routepoints are fully supported by JTAPI. Inconsistent Address Type of ModifiedCalledAddress When a Call Is Made to a Hunt Pilot When a call is made to a Hunt Pilot, although the API call.getCurrentCallingAddress() will return an address of type CiscoAddress.HUNT_PILOT, the address type of the address returned by the API call.getModifiedCalledAddress() will not be CiscoAddress.HUNT_PILOT. This is because the modified address, as the name suggests, might be modified by application and getType() on modified address would return CiscoAddress.UNKNOWN or CiscoAddress.INTERNAL and JTAPI currently has no way to determine if that corresponds to a Hunt Pilot or not. Caveats for Release 7.0.1 This section lists the JTAPI caveats for Release 7.0.1. • Inconsistency in getModifiedCallingAddress(), on page 1717 • Conference Behavior for Selected and Active Calls, on page 1717 • Change in GlobalizedCallingParty Behavior, on page 1718 Inconsistency in getModifiedCallingAddress() When a call is made to a shared DN (Address shared) on two Terminals (A and B), configured with different Calling Party Transformation CSS, and try to transform the Calling Party differently through two different Calling Party Transformation Patterns, then JTAPI does not provide modifiedCallingParty consistently. In such a scenario, both devices send localization signals to call control to transform the calling party number and the one picked by call control first is used to transform the same and JTAPI returns that through getModifiedCallingAddress(). For Example, +918055552222 (Globalized Calling Party) calls JTAPI observed shared Line 3100 on Terminals A and B. Device A is configured to transform the calling party by removing International escape character where as, B is configured to transform the calling party by removing International Escape Character and country code 91. Then JTAPI cannot guarantee whether getModifiedCallingAddress(), that is, the Localized Calling Party, will return 918055552222 or 8055552222. Conference Behavior for Selected and Active Calls Following is the behavior when application issues conference request but selected and active calls are not part of the conference request: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1717 Caveats Wildcard Routepoint Interaction

Page 1781 content

Page 1782

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 B1 and B2 are addresses on same terminal 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 conference with GC1, although call with D was not part of the conference request. 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 scenario, the application specified primary call is cleared after the conference. 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 conference is over. Consider B1 and B2 are addresses on the same terminal and conf1 is a conference call with A-B1-C in conference with B1 as the controller B1 --> D - GC1 (on hold) conf1 - GC2 (active call) B2 --> E - GC3 (on hold) The 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 same behavior applies for user selected calls that are not part of the conference request, but become part of the resulting conference as mentioned above. The same behavior would apply to a regular conference with common controller. Consider A, B, C, D as lines on different terminals A-->B - GC1 C-->B - GC2 D-->B - GC3 (active call) The application requests GC1.conference(GC2). This results in A-B-C-D in conference with GC1. Although direct call with D was not part of the conference request, D will join the conference Change in GlobalizedCallingParty Behavior getGlobalizedCallingParty() returns the correct globalized calling number only in case of a basic call. In a scenario where A calls B, B answers. A and B are connected. In this case, if application requests for getGlobalizedCallingParty(), the API returns the globalized number for A. In case of features such as transfer or redirect where any of the party gets updated, getGlobalizedCallingParty() may not return the correct globalized number. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1718 Caveats Change in GlobalizedCallingParty Behavior

Page 1782 content

Page 1783

Caveats for Release 6.0.1 This section lists the JTAPI caveats for Release 6.0.1: • Call History Might Get Lost When AAR Routes Over QSIG Trunk, on page 1719 • Different Event Order If Consult Call Initiated on SIP Device, on page 1719 Call History Might Get Lost When AAR Routes Over QSIG Trunk When a call is forwarded due to insufficient bandwidth (Call Forward No Bandwidth - CFNB) to another cluster over a trunk or gateway using QSIG, call history might get lost. 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 on the trunk/gateway, then the original called party and the last redirecting party might not get passed to the destination party. Different Event Order If Consult Call Initiated on SIP Device Scenario: Terminal A initiates a call to the shared line B/B' and which Initiates a consult call to Terminal C. • If the Shared Line is SIP device then the call events are : • B (active) receives: CallCtlTermConnHeldEv > CiscoTermConnSelectChangedEv > CallActive • B' (remote-in-use) receives: CiscoTermConnSelectChangedEv > CallActive > CallCtlTermConnHeldEv • If the Shared Line is SCCP device then the call events are: • CiscoTermConnSelectChangedEv > CallCtlTermConnHeldEv > CallActive on both the Terminals. Caveats for Release 5.0 This section lists the JTAPI caveats for Release 5.0: • SRTP Support, on page 1720 • Partition Support, on page 1720 • TLS Security, on page 1720 • CiscoFeatureReason, on page 1720 • Unicode Issue in Calls Involving SIP Trunks, on page 1720 • Join Across Lines: Conference Two or More Addresses on Same Terminal, on page 1721 • JTAPI Exposes Incorrect Information with getCallingAddress() and getCalledAddress(), on page 1722 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1719 Caveats Caveats for Release 6.0.1

Page 1783 content

Page 1784

SRTP Support The default sRTP policy used by IPPhones is different from the one published (standard) as part of libSRTP code. libSRTP code is a free download, available at http://srtp.sourceforge.net/download.html. If the correct srtp policy is not used, the end result is no audio at both ends. The srtp_policy is used by media terminating endpoint to create a crypto context. It should match to encrypt and decrypt packets sent/received by IPPhones/CTIPorts. Phone is using one hardcoded srtp_policy for all phone types including sip phones. policy->cipher_type

AES_128_ICM;policy->cipher_key_len

30; policy->auth_type

HMAC_SHA1; policy->auth_key_len

20; policy->auth_tag_len

4 ; // changed to 4 from 10; policy->sec_serv

sec_serv_conf_and_auth; JTAPI clients doing their own media termination with SRTP, must use the above policy to create a crypto context. The default policy published as part of libSRTP (the standard policy documented as part of RFC) is not same as used by Cisco Unified IP Phone. Phones use the modified one to optimize the bandwidth. The sRTP policy must be part of negotiation between the endpoints but right now only one is supported and ccm does not support the negotiation, hence applications need to use the above policy to terminate media. Partition Support When same Directory Number with different partitions exist in a CallManager, getAddress(String number) API in JTAPI normally returns the first matching Address object which has the same Directory Number. This is done to maintain BWC in case of no partitions configured in the system. TLS Security When client certificate is installed, server certificates are also downloaded from CallManager TFTP server. However, server certificate is only verified for currect signature and server trust is not established. Hence it is recomented that first time download of certificate is done in trusted network. CiscoFeatureReason When a call redirectred across a GW is offered at an address, getCiscoFeatureReason() returns REASON_FORWARDNOANSWER. Within the same cluster when a call is redirected, the redirect destination sees REASON_REDIRECT as the CiscoFeatureReason. However, when a call is redirected across a cluster, through a Q.931 trunk, at the redirect destination getCiscoFeatureReason() returns REASON_FORWARDNOANSWER(as per Q.931 standard). Scenario: A, B and C are registered to 3 clusters. A calls B, B answers and redirects the call to C. When call is offered at C, getCiscoFeatureReason() will return REASON_FORWARDNOANSWER. Unicode Issue in Calls Involving SIP Trunks In SIP call scenarios, where the call comes back to the call manager from the SIP proxy over a SIP trunk, since the call manager is totally dependent on the SIP, messages to populate any names and since the SIP protocol has no way of populating both ASCII and Unicode, the passed-in name is just ASCII and the same Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1720 Caveats SRTP Support

Page 1784 content

Page 1785

gets sent to JTAPI. Hence, in such call scenarios, the user will not be able to see Unicode names since this is not under the control of JTAPI. As a result the following APIs on CiscoCall interface will return only ASCII values instead of Unicode in such scenarios. public String getCurrentCalledPartyUnicodeDisplayName();public String getCurrentCallingPartyUnicodeDisplayName(); For SIP phone specific issues please refer to differences in SIP support section. Join Across Lines: Conference Two or More Addresses on Same Terminal For Unified Communications Manager releases 6.x and 5.x, if applications try to conference two or more addresses on the same terminal, based on the order of participants in the request, application may receive CiscoJtapiException.CONFERENCE_INVALID_PARTICIPANT for the conference request and later the conference may be created successfully with some of the participants. In such a case, there is no guarantee which one of them joins the conference. But the conference is created with only one of the address on a terminal and others are ignored. This depends on how this feature request is processed in different CUCM releases. Below are the details of two scenarios affected: This issue has been resolved in 7.x using CSCsj06488 and CSCsj06533. Note 1. Consider B1 and B2 are different address on the same terminal TB. A ->B1 - GC1 A ->B2 - GC2 A ->C - GC3 Application issues a conference request GC1.conference(GC2, GC3) In 5.x and 6.x, application will receive CiscoJtapiException.CONFERENCE_INVALID_PARTICIPANT, however A, B1, C come into conference, and the normal set of events delivered in a conference scenario are seen like mentioned below: GC1 CiscoConferenceStartEv GC2 TermConnDroppedEv TB GC2 CallCtlTermConnDroppedEv TB GC2 ConnDisconnectedEv B1 GC2 CallCtlConnDisconnectedEv B1 GC1 CallCtlTermConnTalkingEv TB GC2 CiscoCallChangedEv GC1 ConnCreatedEv C GC1 ConnConnectedEv C Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1721 Caveats Join Across Lines: Conference Two or More Addresses on Same Terminal

Image 1 from page 1785

Page 1785 content

Page 1786

GC1 CallCtlConnEstablishedEv C GC1 TermConnCreatedEv TC GC1 TermConnActiveEv TC GC1 CallCtlTermConnTalkingEv TC GC2 TermConnDroppedEv TC GC2 CallCtlTermConnDroppedEv TC GC2 ConnDisconnectedEv C GC2 CallCtlConnDisconnectedEv C GC2 CallInvalidEv GC1 CiscoConferenceEndEv 2. Consider B1 and B2 are different address on the same terminal TB. A ->B1 - GC1 A ->B2 - GC2 A ->C - GC3 Application issues a conference request GC3.conference(GC1, GC2) In 5.x, Application will not receive any exception and the request would be procressed successfully. A, C, B1 would be in conference along with the regular set of conference events. In 6.x, Application will receive CiscoJtapiException.CONFERENCE_INVALID_PARTICIPANT, however A, C, B1 come into conference, and the normal set of events delivered in a conference JTAPI Exposes Incorrect Information with getCallingAddress() and getCalledAddress() In some scenarios where feature works on multiple calls (pickup, transfer, conference and so on) depending on Event Order or the parties observed, JTAPI may end up reporting incorrect call information to the applications. These scenarios are ones where surviving call is initially not there in JTAPI's provider domain or in scenarios where SurvivingCall goes invalid and is recreated in the middle of the feature operation. For such survivingCalls, JTAPI does not report correct information with getCallingAddress() and getCalledAddress(). Some of these scenarios are: 1. Transfer - A calls B; B transfers the call to C and application is observing only C 2. HuntList Transfer - In 8.x release if transfer is done, then surviving call can go invalid and recreated if caller is not observed. 3. PickUp scenario where survivingCall goes invalid and is recreated in middle of the feature 4. UnPark scenarios where caller is not observed and service parameter, Preserve globalCallId for Parked Calls, is set to true. In general, this issue can happen with scenario where survivingCall is not in provider's domain initially or if is there and goes Invalid(CallInvalidEv is sent) and is recreated(CallActiveEv is sent) during the feature operation. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1722 Caveats JTAPI Exposes Incorrect Information with getCallingAddress() and getCalledAddress()

Page 1786 content

Page 1787

Caveats for Release 4.1 This section lists the JTAPI caveats for Release 4.1: • FAC-CMC, on page 1723 • setConferenceController, on page 1723 • Interval During DTMF Digits, on page 1724 • Shared Lines Support, on page 1724 • CP Requires Previous Calls on the Device to Be in Connected Call State , on page 1724 • CallInfo for Calls on QSIG Trunk, on page 1724 FAC-CMC 1. Forwarding should not be configured to a DN that requires FAC-CMC code. Forwarding requests will be successful, but calls will not be forwarded to these DNs and will be rejected. 2. Application should always terminate the code with #, otherwise system waits for T302 timer before extending the call. For these cases, application could get postConditionTimeOut exception for call.connect() or call.consult() but call may actually be offered. If apps need to avoid this, either all the digits with # terminated string are entered with post condition timeout (which is by default 15 sec in JTAPI Prefs UI) in the PlatformException or increase the postcondition timeout. 3. Two identical CiscoToneChangedEvents are sent to applications and second one needs to be ignored if both the codes are entered with # separated upon receiving the first event. setConferenceController The party that starts a conference by adding a new party acts as the original conference controller. Only the original conference controller can add new parties into the conference. If the original conference controller drops out of the conference, no other party in that particular conference call can add a new party. Although the conference controller cannot be changed while a conference call is going on, applications can determine which TerminalConnection acts as the conference controller when initially setting up a conference call via the CallControlCall.setConferenceController() method. The CallControlCall.getConferenceController() method returns the current conference controller, or null if there is none. If no conference controller is set, the implementation chooses a suitable TerminalConnection when the conferencing feature is invoked." Consider the following scenario as an example: A, B, C, and D belong to a conference call and all are in the TALKING state. A acts as the conference controller. A attempts to use the SetConferenceController API to change the conference controller to B, gets no error, and drops out of the conference. B then tries to add a new party, E, into the conference but cannot do so. conference(Call[]) Applications can control which TerminalConnection acts as the conference controller when setting up a conference call via the CallControlCall.setConferenceController() method. The CallControlCall.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 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1723 Caveats Caveats for Release 4.1

Page 1787 content

Page 1788

when the conferencing feature is invoked. Only the original conference controller can add new parties to a conference call. Attempting to change the conference controller while a conference is going on will not take effect; however, no error gets thrown in the setConferenceController API Interval During DTMF Digits As per fix for CSCef05359, Change PlayDTMF to allow applications specify the time delay, now applications can configure the time delay during DTMF digits through Admin page, Service pameter, generate DTMF delay, for call Manager. Shared Lines Support Cisco JTAPI does not support configuration of same Directory Number from different partitions on the same or any device but configuration of different Directory Number from different partitions on the same device as well as different devices is supported. CP Requires Previous Calls on the Device to Be in Connected Call State CP requires previous calls on the device to be in connected call state before answering further calls on the same device. If calls are answered without checking for the call state of previous calls on the same device, then CTI might return a successful answer response but the call will not go to connected state and needs to be answered again. See DDTS CSCee17001 for more details. CallInfo for Calls on QSIG Trunk Call info on a call across a QSIG gateway is not consistent. Due to the limitations in the protocol, application would see inconsistent values for call.getLastRedirectingAddress() and call.getCalledAddress() for calls across QSIG trunks. Refer to CSCee74730, CSCee59084, CSCee70747 and CSCsk62441 for details. Caveats for 4.0 This section lists the JTAPI caveats for Release 4.0: • Extra Connection with Wild Card DN, on page 1725 • CallInfo in Barge Scenario, on page 1725 • CallInfo Issues When Caller Redirects Call, on page 1725 • Translation Pattern and Presentation Indication Interaction, on page 1725 • Extra TermConnHeld Events, on page 1725 • Transfer and Conference Interaction, on page 1725 • Dropping a Call on Shared Lines, on page 1726 • Barge Call, on page 1726 Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1724 Caveats Interval During DTMF Digits

Page 1788 content

Page 1789

• Null lastRedirectingAddress, on page 1726 • Devices Configured with Same CLI, on page 1726 • Current Called Address, on page 1727 Extra Connection with Wild Card DN JTAPI may create extra connection when Call is made wild card DN. See the release note of DDTS CSCeb57849 for scenarios. CallInfo in Barge Scenario CallInfo is not updated when Barge Initiator Drops the Call. See the release note of DDTS CSCec23359 for scenarios. CallInfo Issues When Caller Redirects Call In this scenario A calls B, A redirects to C and application is monitoring only C, the calling and called address would be B and C and the calling terminal would be terminal A. Translation Pattern and Presentation Indication Interaction JTAPI has getCalledAddressPI and getCurrentCalledAddressPi interfaces to receive the PIs of the originalCalled and Called parties. While making a call through a Translation Pattern, if the pattern modifies the PIs of the CalledParty, the getCalledAddressPI continues to reflect the earlier PI while the getCurrentCalledAddressPI shows the PI as set at the pattern. Refer DDTS CSCec58085 for more details. Extra TermConnHeld Events Applications may some times see an extra TermConnHeld Event on Controller during Transfer and Conference scenario. For transfer scenario this extra TermConnHeldEvent is sent on controller before TermConnDropped is sent. For conference scenario, for primary controller which remains in the call, this event is sent before TermConnTalking is sent, and for controller which is dropped from conference, it is sent before TermConnDropped is sent. Refer DDTS CSCec55257 for more details. Transfer and Conference Interaction • 9.1.6.1—in JTAPI whenever transfer is done to connect a normal call to a ConferenceCall, the GlobalCallId of Conference Call always survives irrespective of how the transfer is performed (whether on Call1 or Call2). • 9.1.6.2—during transferring of conference scenario, it is possible External Connection creation events are delivered before CiscoTransferStartedEv, however, Call Merge events are still delivered within CiscoTransferStart and CiscoTransferEnd boundry. • 9.1.6.3—during transferring of conference scenario, if transfer-destination is not observed by the JTAPI Application, the LastRedirectingParty is not updated. For example, if A, B, C are in conference, C (Transfer controller) transfers call to D, and D (Transfer-destination) is not observed by JTAPI, then Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1725 Caveats Extra Connection with Wild Card DN

Page 1789 content

Page 1790

LastRedirectingParty of the call remains unchanged after Transfer is completed. Ideally after Transfer is completed, LastRedirectingParty is updated to Transfer controller. Dropping a Call on Shared Lines If there is heldCall on SharedAddress (SharedLine) and application is not observing all the terminals of SharedLine, then Connection.disconnect() using SharedAddress's connection does not drop the call. The is left with connections of OtherParty in the call. To drop the call, the application must use either Call.drop() or manually disconnect call from non observered terminals. In other words, if there is HeldCall on SharedAddress, then for the terminals that is not in Application's control, callmust be dropped manually. For detais, refer DDTS CSCed06910. Barge Call In a Barge Call, when 1. Barge target holds 2. Barge target does a consult conference or arbitrary Conference 3. The OtherParty drops the call 4. Barge target initiate transfer, arbitrary transfer or BlindTransfer 5. Barge target parks the call 6. Barge target Idiverts the call 7. Barge target redirects call Then, Initiators TerminalConnection/CallCtlTerminalConnection is dropped as result of above operations. However, CallCtlCause for these TermConnDropp/CallCtlTermConnDrop would be Cause_Normal. JTAPI is unable to provide specific cause such as Cause_Redirect for #7 above. Initiator is the party that presses the Barge key to barge into a call. Target is where Initiator Barges, OtherParty is address which not Initiator/Target. For details, refer DDTS CSCed07230. Note Null lastRedirectingAddress Call.getLastRedirectingAdress() returns null when only the redirecting address is observed. The call goes to INVALID state after redirect request and if application calls the above interface after redirecting the call it would see null. For details, refer CSCee92111. Devices Configured with Same CLI In a conference scenario, where conference controller is observed by JTAPI and other two calls are from devices configured with same the CLI (Directory Number), JTAPI creates one connection. So, when conference is completed, it has only two connections in the call instead of three. If the conference is completed using conference() API, a post condition timeout exception is thrown. For details, refer DDTS CSCeh05723. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1726 Caveats Dropping a Call on Shared Lines

Image 1 from page 1790

Page 1790 content

Page 1791

Current Called Address CiscoCall.getCurrentCalledAddress() returns null before the call is offered to the called address. In earlier releases, this used to return Unknown address. Applications must handle null or Unknown address returned for CiscoCall.getCurrentCalledAddress(). Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1727 Caveats Current Called Address

Page 1791 content

Page 1792

Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1728 Caveats Current Called Address

Page 1792 content

Page 1793

A P P E N D I X H Deprecated API This appendix lists lists the APIs, fields, and methods that have been deprecated. A deprecated API is not recommended for use, generally due to improvements, and a replacement API is usually given. Deprecated APIs may be removed in future implementations. • Deprecated Interfaces, on page 1729 • Deprecated Fields, on page 1729 • Deprecated Methods, on page 1730 Deprecated Interfaces com.cisco.jtapi.extensions.CiscoRouteAddress This interface has not been implemented. Deprecated Fields Deprecated fields com.cisco.jtapi.extensions.CiscoAddress.APPLICATION_CONTROLLED_RECORDING com.cisco.jtapi.extensions.CiscoAddress.DEVICE_CONTROLLED_RECORDING These constants 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. com.cisco.jtapi.extensions.CiscoProviderCapabilityChangedEv.MODIFY_CGPN This constant is not returned by any interface, should not be used by application. com.cisco.jtapi.extensions.CiscoProviderCapabilityChangedEv.MONITOR_PARKDN This constant is not returned by any interface, should not be used by application. com.cisco.jtapi.extensions.CiscoProvCallParkEv.REASON_CALLPARKREMAINDER This interface is deprecated due to a spelling error. Use the new interface REASON_CALLPARKREMINDER. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1729

Image 1 from page 1793

Page 1793 diagram

Page 1794

Deprecated fields com.cisco.jtapi.extensions.CiscoFeatureReason.REASON_PARKREMAINDER Use REASON_PARKREMINDER. com.cisco.jtapi.extensions.CiscoProviderCapabilityChangedEv.SUPERPROVIDER This constant is not returned by any interface, should not be used by application. Deprecated Methods Deprecated methods com.cisco.jtapi.extensions.CiscoTermDataEv.getData() Use byte[] getTermData com.cisco.jtapi.extensions.CiscoJtapiException.getErrorDescription(int) Use String getErrorDescription (); instead. com.cisco.jtapi.extensions.CiscoJtapiException.getErrorName(int) Use String getErrorName (); instead. com.cisco.jtapi.extensions.CiscoConsultCallActiveEv.getHeldTerminalConnection() Replaced by CiscoConsultCall.getConsultingTerminalConnection() com.cisco.jtapi.extensions.CiscoCall.getLastRedirectingPartyInfo()

use getLastRedirectedPartyInfo(); com.cisco.jtapi.extensions.CiscoAddress.getRegistrationState() This method has been replaced by the getState() method. com.cisco.jtapi.extensions.CiscoTerminal.getRegistrationState() This method has been replaced by the getState() method. com.cisco.jtapi.extensions.CiscoMediaTerminal.register(InetAddress, int) com.cisco.jtapi.extensions.CiscoTerminal.sendData(String) com.cisco.jtapi.extensions.CiscoJtapiProperties.setSecurityPropertyForInstance(String, String, String, String, String, String, String, String, boolean) This method is replace by overloaded method setSecurityPropertyForInstance which takes an extra parameter certStorePassphrase, a passphrase for java key store. This method might have some security vulnerability. com.cisco.services.tracing.TraceManager.setSubFacilities(String[]) and replaced with TraceManager.addSubFacilities method Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1730 Deprecated API Deprecated Methods

Page 1794 diagram

Page 1795

Deprecated methods com.cisco.services.tracing.implementation.TraceManagerImpl.setSubFacilities(String[]) replaced by addSubFacilties(String[]) com.cisco.services.tracing.TraceManager.setSubFacility(String) and replaced with TraceManager.addSubFacility method com.cisco.services.tracing.implementation.TraceManagerImpl.setSubFacility(String) replaced by addSubFacility(String) com.cisco.jtapi.extensions.CiscoJtapiProperties.updateCertificate(String, String, String, String, String, String, String, String) This method is replace by overloaded method updateCertifcate which takes an extra parameter certStorePassphrase, a passphrase for java key store. This method might have some security vulnerability. com.cisco.jtapi.extensions.CiscoJtapiProperties.updateServerCertificate(String, String, String, String, String) This method is replace by overloaded method updateServerCertifcate which takes an extra parameter certStorePassphrase, a passphrase for java key store. This method might have some security vulnerability. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1731 Deprecated API Deprecated API

Page 1795 diagram

Page 1796

Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1732 Deprecated API Deprecated API

Page 1796 content