/mcp• 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