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