/mcpwhenever 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