Call signalling: QSS

_images/qss_icon.png

The Quobis Signaling Server (QSS) is a service of the Quobis WAC that orchestrates the setup of the voice and video calls. Its main rol is to control the video SFU and the audio MCU in order to create the conference rooms according to the type of service that wants to be implemented. It includes tasks such a create conference room, destroy a conference room, add/remove participants to a conference room ACL, etc… Because of that, the QSS has visibility of the status of each user connection (wether a user has joined a conference room, is put on hold, left the room, etc…)

We use the term signaling, which comes from the VoIP world, to refer to the messages used to let the system know where a specific user is registered and can be found, and all the requests and answers needed to establish calls. For example, when Alice calls Bob, Bob receives a specific type of message called invite which will trigger an event in Bob’s SDK when the call is received so that this can be answered by him.

_images/conference_room_basic.png

QSS features

As the orchestrator of the Quobis WAC calls, the QSS services provides a number of features that developers can leverage to implement a number of different and complex use cases. Some of these features require the interaction of several QSS micro services, while other rely solely on one microservice. These functionalities are exposed in the SDK so the developers can make use of them.

  • Basic conference room management: these are the basic functionalities that provide low-level control of the conference room. It is suitable when the developers wants to implement a specific use case that is not covered in the standard ones shown below.

  • One to one calls: this functionality is provided to simulate the telephony use cases, and it’s based in the QSS.invite services.

  • Meetings: this functionality is useful when the call is expected to be scheduled at a certain date and limited to a number of participants.

  • Quick conferences:: this functionality is useful when we want to create a conference room without any restriction, so it can be reachable by any user at any time.

QSS micro services list

The implementation of the QSS has been made using micro services that communicate between them and with other services via a message broker. Each of these services is responsible for an specific task. In other words, there is no “QSS service” but a handful of “QSS micro services”. Being said that, in some cases we just refer to the QSS as the entity that groups them all for the sake of simplicity. The list of the QSS micro services available in the current version is:

  1. Service QSS.audiomixer-io: manages the connection with one or more audiomixer instances.

  2. Service QSS.audioStatus: sends mute/unmute requests to remote participants and tracks user mute/unmute status (introduced in v5.6.0)

  3. Service QSS.callTransfer: handles unattended call transfer between users.

  4. Service QSS.conferenceState: handles the state of a conference room to decide when it must be destroyed and if a user can be invited.

  5. Service QSS.dtmfAgentProcess: handles DTMFs generated in a SIP call and, when a combination of tones is reached, calls an user registered in sippo-server and QSS

  6. QSS.invites: notifies an user that another one wants to invite him to a conference room.

  7. Service QSS.io-websockets: exposes a Websocket server that the WebRTC clients can connect to.

  8. Service QSS.log-conference: generates and sends conference objects to sippo-server service

  9. Service QSS.meeting: allow users to join a meeting if every constrains are met.

  10. Service QSS.peer-jt: translates and routes messages between different services.

  11. QSS.quickconference: allow users to join a quick conference.

  12. Service QSS.registry-authenticated: authenticates and maintains the user sessions.

  13. Service QSS.resolver: utils for getting more information about a resource, i.e: resolve a user associated with an arbitrary address, get the sip mapping for a user, etc.

  14. QSS.rooms: manages the creation/update/removal of conference rooms.

  15. QSS.trunk: : manages the business logic related with conferences coming/going to/from the SIP network (including the parallel-SIP feature).

  16. QSS.watchdog-invites:: removes invitations which are no longer valid.

  17. Service QSS.watchdog-registry: removes expired register entries and implements a ping-pong mechanism with the clients to know if they are still logged into the QSS.

QSS scalability

Beyond these services, the QSS also interacts with other two internal services, a dispatcher of conferences and a SFU wrapper, in other to properly setup the conference rooms. These services are needed in order to horizontally scale the number of concurrent conferences and to be able to route traffic to several audio MCUs and video SFU. The details of the communication messages interchanged between the QSS and these services are not relevant neither to a system administrator nor to a application developer, so they are not documented here.

More information about QSS micro services: