Basic IP telephony involves encoded RTP audio streams exchanged directly between 2 parties somewhere on the network. A call between two IP Phones, for example, involves setup communication with the CallManager; however, once the call is established, all communication occurs between the two IP Phones directly, rather than being relayed via the CallManager.

In a conference situation, however, there are (at least) three media streams involved, and they must be combined and distributed to all participants. This requires that all the parties? audio streams be directed to a central resource, where the streams are mixed. This resource is a ?conference bridge? signal processor, which can be implemented in software on the CallManager machine itself (using CPU resources) or in hardware DSPs on various Cisco gateway/routers.

Establishing a conference via TAPI is done in the following way:

A------B A and B are connected. B is under application control
(A)-----B B calls lineSetupConference. A goes on hold.
(A)-----B------? - Also a new consult call is created
(A)-----B------C B calls lineDial() and is connected to C
A------B------C B calls lineAddToConference() to complete the conference

1) Starting with a call established between, for example, an IP Phone (Party A) and an IP Phone under application control (Party B.)
2) The application calls the lineSetupConference() function:

LONG WINAPI lineSetupConference(
HCALL hCall,
HLINE hLine,
LPHCALL lphConfCall,
LPHCALL lphConsultCall,
DWORD dwNumParties,
LPLINECALLPARAMS const lpCallParams
);

The hCall parameter is the handle to the established call (A-B.) The hLine parameter can be null, and is ignored. Also, the dwNumParties value is ignored (Cisco TSP will allocate resources as necessary.) The result of the lineSetupConference() is that party A is placed on hold, and a new consult call is created (lphConsultCall.)

Party A is in a special hold state: onHoldPendingConference. This indicates that the CallManager has invoked the conference bridge, and redirected the RTP audio stream there. The lphConfCall, or ?conference parent? call returned can be thought of as a call handle to the conference bridge. This handle will be used later on by lineAddToConference (and linePrepareAddToConference.)

Party B will now be hearing dial tone, as lineSetupConference results in Party A on hold and a new consult call being created. If this call is abandoned (via lineDrop) the call will revert to a two-party call.

3) The application calls lineDial(), passing the phone number of the intended conference participant. Once the call has completed successfully?
4) The application can call lineAddToConference(), specifying the handle of the consult call (call to Party C) and the handle of the conference parent obtained in step 2)

Once the conference is established, the application can continue to add participants by first calling linePrepareAddToConference(), which results in the conference call being placed on ?hold? and a new consult call, followed by an additional lineAddToConference specifying the new consult call.

Only the conference controller (the application, Party B in this example) can add new conference participants. Even if the controller drops from the conference, and it continues with the remaining participants, other participants will not have the ability to add new parties. In addition, once the conference bridge has been invoked, the call becomes a conference from then on: transferring the call, dropping down to two parties, etc. does not remove the conference bridge and conferencing resources will continue to be occupied; also, secondary/tertiary parties will no be able to add conference participants if the conference is transferred ?downstream.?

Other types/models of conference setup are not supported at this time, including ?arbitrary? conferencing, call-joining (A-B to C-D conference,) and transfer-conferences