The Flexisip conference server acts as a SIP user-agent to handle IM (group chat), audio/video conferences.

The main RFCs implemented by the conference server are:

For establishment of sessions from clients:

• SIP Call Control - Conferencing for User Agents, RFC 4579
• Conference Establishment Using Request-Contained Lists in SIP, RFC 5366

For notification of conference events to clients (users who join or leave the conference):

• SIP Event Package for Conference State, RFC 4575
• Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP), RFC 5367

From a media (RTP) standpoint, the conference server behaves as follows:

• Audio streams are decoded, mixed together and re-encoded (minus client's own contribution). Clients of the conference can then use different audio codecs.
• Video streams are forwarded without decoding, compositing or re-encoding. In other words, it acts as a Selective Forwarding Unit. This is the most scalable and efficient method.

Clients require to support multiple video streams in order to be able to render multiple participants of the conference. The available video streams are advertised through the Conference State Event Package (RFC4575), with their respective labels.

The client can then use labels within their SDP offers (thanks to a=label attributes) to request receiving specific streams. In addition, clients may send and request additional miniature streams advertised in SDP with a a=content:thumbnail attribute. Please refer to Linphone version >= 5.0 and linphone-sdk >= 5.2 for a full implementation of a SIP conference-aware client compatible with the Flexisip conference server.

In absence of any label indication, which is the case of clients that are not conference-aware, the conference server sends the "active speaker" stream, which is the video stream corresponding to the participant currently speaking in the conference.

Operation

From the system's point of view, the conference server runs as a daemon in its own process, and therefore has no adhesion with other Flexisip services from an execution standpoint. It can be started, stopped, restarted using usual systemd commands, for example:

It can of course be started from a terminal, for example:

The configuration of the conference server is read by default from /etc/flexisip/flexisip.conf, mainly from the [conference-server] section.

In order to avoid mixing services which have different criticality and usage, it is recommended to to deploy distinct instances for IM (long term chat) and audio/video conferences.

The conference server in the SIP network

The conference server itself does not perform any authentication, request integrity checking, nor DoS protection. These tasks are left to the proxy server. In addition, it listens only on SIP/TCP. It is then recommended to configure the conference server to listen on a private IP address or localhost, so that it cannot be reached directly from the internet.

The conference server receives all incoming SIP requests from a proxy server, and sends its outgoing request though a proxy server too (usually the same node).

The conference server requires an intimate relationship with the Flexisip proxy server's registrar database for the group chat feature, which must be a REDIS implementation (the "internal" registrar database implementation doesn't allow the conference server to make queries on it). This relationship is necessary for two things:

• writing into the registrar database AORs for the conference URIs it creates, so that the proxy knows how to route requested targets to a conference URI. In addition, the conference factory URI, which is the one used by clients to create new conferences, is also added to registrar database.
• querying the registrar database in order to obtain notifications about registration information of SIP users who are invited into conferences. In particular, it needs the information about devices belonging to the users, which is identified thanks to GRUU address attributed by the proxy based on "+sip.instance" parameter. The device information is necessary so that all members of a conference can receive accurate information about participants and associated devices using RFC4575 (Event package for conference state).

This dependency on registrar database implementation should be relaxed in mid-term horizon thanks to the development of an interoperable SIP-standard mechanism to query registrar database, using RFC3680 (Event Package for Registrations). Interoperability with third party proxy servers will then become possible.

This dependency to the proxy's REDIS database is not required for audio/video conference. A third-party proxy simply needs to route to the conference server instance of any SIP requests targeting the SIP factory and focus URIs (as defined in the [conference-server] configuration section). In case the REDIS back-end is available, the conference server automatically inserts special records into the Registrar database for factory and focus URIs.

Database storage

Because IM conferences (group chats) can last potentially years, and audio/video conference can be scheduled in advance, a persistent storage is required to store the state of conferences (participants, devices, conference URIs). The conference server requires a connection to a MySQL or MariaDb database where to store such conference state information. Database connection information must can be set in the 'database-connection-string' property of the [conference-server] section of flexisip.conf.