Communication setup
This section explains the basics of the mechanisms used by Quobis WAC to setup a real-time media connection between users. Let’s analyze first the type of scenarios that are supported.
Call-oriented scenarios
In telephony systems where user A wants to call user B, a direct connection is just setup directly between both parties. This is the traditional concept of a “call”, inherited from the old telephony times. The caller is the call initiator. The calle is notified of any incoming call. The callee can reject or answer the call. The caller expects a dialtone while the call is ringing and that the call finishes when either him or the callee hang up. This is also the basics of SIP signaling and VoIP telephony.
A number of call management functions are available in these systems, such as call transfer, three-way calling, call holding, call forwarding, call parking, call redirection, call pickup, ringing groups, etc. These call management functionalities are provided by the endpoint itself, by the PBX or both. As such, a number of vendors provide a specific SDK and business logic for the “call-oriented scenario”.
Besides that, in these scenarios we need to let the users know when there is an incoming call for them, so a method to notify the users need to be put in place as well. This is done in Quobis WAC via a set of push notification services.
Conference-oriented scenarios
On the other hand, when the use case requires to connect multiple users together, the common approach is to make use of a common space that the users join (let’s call that space “a conference”). From a high level point of view, this “conference” scenario looks quite different to the “basic call” scenario described above, as there are no “caller” or “callee” roles but a new role of “conference participant”. In this scenario, all the participants join the same conference room so they can talk & see each other. For example, in a traditional SIP-based video conferencing systems, every participant dials into a media server which mixes all the audio and video streams together. There is no dial tone and no need for transfers, forwarding, etc… such in the call-oriented scenario.
In this scenario, depending on the use case, there might a participant who has specific permissions (usually referred to as “owner”) or there might be also users that join the conference room from other networks via a traditional PSTN or SIP call. Participants can also join or leave the conference room at anytime, with or without constrains. In addition, it’s up to the users to join the conference room at the agreed time.
Quobis approach
As described above, these two scenarios (call and conference) look like two separate ones in terms of requirements. Because of that, most UC vendors provide separate services, SDKs and APIs for the two scenarios indicated above, each of them having its own business logic and constrains. Hence, the developers cannot mix the both cases together, or event a subset of functionalities. Quobis wac provides an innovative approach that covers both scenarios with the same infrastructure. There is no need to know in advance how many users a communication will have, wether it will include or not SIP users or users with mixed audio and video configuration. The architecture to support this approach is based on three main elements:
a signaling server (Quobis Signalling Server, or QSS in short)
and media server which contains:
a voice MCU and SIP gateway, to handle the audio streams
a video SFU to handle the video streams
Every audio or video connection made with Quobis wac is managed via these three internal components, regardless of the number of users and thus providing the same set of functionalities. These three components are responsible of the setup of “conferences” to communicate users. This conference-centric approach with support to call-oriented scenarios is one of the key benefits of the platform and eases the design and implementation of a wide range of use cases thanks to its flexibility.
The beauty of the Quobis SDK lies in this special architecture, where every connection is handled by the same internal components and managed from the QSS. In the case of call-oriented scenarios, where there might be only two users, the QSS notifies the conference room and the users to “mimic” the telephony events such as ringing, answering, busy-tone, etc… The users perceive that they are in a regular one to one call and the fact that they are joining a conference room is transparent to them. This approach provides a strong foundation to developers that gives them freedom to create basic but also quite complex use cases, such as:
having mixed SIP and WebRTC users
upgrade/downgrade an audio call to a video call
allow external user to join the conference but also requests users to join a conference
move a user to another conference, or to a SIP destination
support to N-way calling (managing more than one conference at the same type for each user)
automatic calling to N users so they join a conference room when answering
join users who are offline via desktop and mobile push-notifications
plus all the telephony features expected for call-oriented scenarios
There are a number of methods exposed in the Quobis SDKs in order to setup a voice or video communication, all of them built around this same “conference room” concept. There is more information about each these methods in the following sections:
Setup a basic one-to-one call
Setup a conference with multiple participants
Setup a meeting
Note
Please check section Media management for further information and details on how the voice and media streams are actually managed in a conference
Summary
The main takeaways of this section are:
A conference is a logic entity composed of a audio room and a video room, managed from a signalling service
Every connection between users in Quobis WAC is made through a conference room, regardless of the number of participants and/or the functionalities needed.
Quobis WAC provides several services to setup different use cases: calls, meetings and quick meetings.