Conference v2 Overview
Introduction
Each Conference endpoint has an Account object associated with it. The Account object holds the credentials, necessary to access the conference API. It also has an association with a Call Flow object which will be used if you do not change this setting at the lower levels (DID group or DID). Refer to the Call Flows section for more information about the call flow routing.
The following different call flows are available with CarrierX conferences:
- secured which requires setting access keys on the Meeting Room object and entering these keys by the callers;
- open which allows setting access keys to enter specific meeting rooms, but also enables the callers to enter random access keys and create meeting rooms on the fly;
- and 'direct' call flows (direct_host and direct_participant) which do not require access codes, and all the callers automatically enter meetings where all of them become either hosts or participants.
Conferences with the direct call flows do not require to create meeting rooms and set access keys for each participant. Anyone who calls the phone number associated with such a conference will be routed into one and the same meeting room without any additional prompts. Depending on the call flow associated with this conference (direct_host or direct_participant), everyone in this conference will either be a host or a participant.
For the secured Conference endpoint to work, it must have at least one Meeting Room object associated with it. The meeting room has a list of meeting keys — key-value pairs, where the key is an access code and the value is the matching access level: host, participant, or listener.
Please note that access codes must be unique across all the meeting rooms associated with the same DID group within a single conference endpoint (i.e., no two Meeting Room objects with the identical account_sid, did_group_sid, and access_codes can exist), otherwise the routing to the conference will not be performed. Refer to the section below to learn more about the conference flow.
Each access level has settings which determine how the party is treated during a meeting. For example, settings on the Meeting Room object can determine that all listeners will be muted upon entering the meeting. You can configure these settings using the properties property at different levels.
The base call flow properties are set at the Call Flow level and are available for reading only. You can override these base settings in other conference objects. Refer to the Conference v2 Call Flow Properties section for the list of the properties which you can configure.
Conference Flow
A conference flow looks like this:
-
End-users dial a phone number associated with a conference.
-
Depending on the conference type and the call flow properties set, the conference either invites the calling party to enter an access codes, or skips this step.
-
If the conference call flow requires entering an access code (open or secured), the calling parties do it. If not (direct_host or direct_participant), the conference allows the calling parties to enter the meeting.
-
For each conference user, the system creates a temporary Call object which contains the entered access code (if the conference requires it), as well as the source and the destination phone numbers. System also associates the created Call object with the account the dialed number belongs to.
-
The call flow properties determine how the system treats each of the calling parties.
-
The system compares the entered access code to the ones stored in the Meeting Room objects to determine which meeting room to connect the caller to and what access level to grant.
-
If the code matches one of the stored ones, a temporary Meeting object, associated with the meeting room and the partner account, is created and the caller is routed to this meeting.
Call and Meeting objects are real-time elements that only exist as long as a meeting is happening and as long as there are callers in the meeting.
The call flow properties determine the start of a meeting (i.e., the creation of a Meeting object). You can override these properties by the meeting room settings. For example, a meeting can begin once a host calls in, or a meeting can start once any party calls in.
Once a meeting is finished, the Meeting object is deleted, along with all of the Call objects associated with the meeting.
Conference Flow with Prefix
Although DIDs and DID groups are exposed through the Conference API, they belong to the partner account rather than to the Conference endpoint itself. That is why it is possible to use a Conference endpoint without a DID at all.
In this case you will need to assign a prefix to the trunk group associated with the Conference endpoint. The setup will look like this:
Refer to our How It Works: Prefix Routing section for more information on how to route calls using prefixes.
The callers will have to use some SIP service to call into the conference instead of a PSTN phone. The partner will need to link the prefix to the trunk group so that when the caller dials a phone number with a certain prefix via the third-party endpoint the system routes them into the Conference endpoint even if the partner does not have any DIDs rented from CarrierX and associated with their account.
The only call flow which will be used in this case is the one associated with the partner account.
The conference flow will look like this:
Please contact our support at support@carrierx.com if you want to set up a conference using the prefix routing.
Conference vs. Conference Playback Endpoint
A Conference endpoint enables two or more parties to have a conversation in a meeting.
A Conference Playback endpoint is used to listen to saved recordings made during meetings. In order for recordings to be saved, a Conference endpoint must be created and connected to a Conference Playback endpoint. Create a Conference Playback endpoint in the same way as a Conference endpoint, by using the Core API.
Refer to the Conference Playback Quick Start to learn how to connect the endpoints.