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