T-Lib-Initiated 3-Way Conf Central Mixing
T-Lib–controlled three-way conferences are handled through an external multimedia conferencing unit (MCU) device that performs the audio mixing.
The call scenario begins when a call is established between UA1 and UA2. UA2 places UA1 on hold and dials a consult call to UA3. When UA2 and UA3 are ready for a conference, SIP Server re-Invites everybody to the mixing device. A DN (that is, the user part of a SIP URI) identifies a conference — all participants will use the same number to identify the conference to the mixing device.
The diagram begins with a call between UA1 and UA2 in a Held state and a call from UA2 to UA3 in an Established state. Agent UA2 invokes the T-Lib request TCompleteConference.
Here is how this process works:
- To allocate MCU resources, SIP Server starts by sending the MCU one INVITE request for each participant request without an SDP.
- SIP Server sends INVITEs without the SDP offering to get the list of codecs from the MCU.
- SIP Server does not modify any of the existing dialogs until it receives an OK for all INVITEs sent to the MCU. If any of the INVITEs fail, SIP Server rolls back to the initial state and all SIP dialogs remain intact.
- Once SIP Server receives all the OKs, it sends re-INVITE dialogs to the three participants, using the SDPs it received from the MCU.
- SIP Server uses the answer SDPs from the participants in the ACKs it sends to the MCU.
- Before the conference is completed, UA2 will have had two dialogs — one for the primary call and one for the consult call. SIP Server re-INVITEs the primary call to the MCU; it sends BYE to terminate the consult call.
Implementation Note: The scenario just described is the most efficient way to establish a three-way conference using the T-Lib API. However, some MCU devices do not support INVITE without an SDP. To accommodate these devices, SIP Server sends INVITEs to MCU with valid non-hold SDPs (the actual SDP received from the corresponding devices). After that, it re-INVITEs the devices.