Our full-remote story: how we had to rethink our videoconferencing needs

Published in

Quarkslab

7 min readJun 4, 2020

Choosing a videoconferencing solution that suits your organisation and is secure can be a complex task. The pandemic has forced a lot of organisations including ours to rethink its videoconferencing needs. We have identified few questions that we hope will help you pick the right solution for your organisation.

Introduction

In the middle of March, the French government, alongside several other countries, decided to put in place social distancing measures to contain the spread of the novel coronavirus, named as COVID-19.

For those who could, working remotely, away from the office, was strongly encouraged by the government to reduce contacts with other people, as a containment measure for the virus.

For a lot of companies, passing overnight almost all of their workforce to full remote represented a strong technical challenge, in putting in place the means to allow people to continue working.

Videoconferencing suddenly took extreme importance as it allowed remote workers to continue holding meetings, conference calls and more generally keeping social links between teams.

If we look at our case, we were fortunate enough to already have tools implemented to ensure that remote work could exist. Indeed, Quarkslab has a very distributed workforce: two offices in France, a subsidiary in Argentina, combined with remote workers.

However, with now all of the employees using the videoconferencing system, issues that were overlooked before were now more present and more strain was put on systems than before.

After the start of the lockdown, we then began to look for a long-lasting and sustainable videoconferencing solution and we looked more closely at several solutions in order to choose the one that would best match both our functional and security needs.

We wanted to share this approach in this blog article: we do not intend here to make a complete comparison of the existing solutions on the market, but rather show the process of selecting a videoconferencing software adapted to a cyber security company such as ours.

Context

Before delving into the characteristics of the solutions we surveyed, it is important to define the context in which we are situated and the selection criteria. Indeed, this step is essential in order to avoid ending up with a solution that does not correspond at all to our expectations. To do so, the following questions have helped us define our key criteria:

Our previous installment

Before the lockdown measures, we already had some tools in place to communicate internally and externally, with a jitsi instance in our local network for meetings, a mumble server, and an RTMP server to stream one to many meetings such as our company wide weekly meeting.

However, these had issues:

Our jitsi version had performance issues when several people connected to a room;
Sometimes, when connecting to a jitsi room, the microphone was not detected;
Mumble can be quite tricky to configure the first time, and does not support video;
RTMP is intended for one to many, and is unidirectional.

As we mentioned in the introduction, these issues were precedingly overlooked as we used them occasionally when physical meetings were not possible.

We then decided to improve on this situation and start to look for a better alternative.

The first step was to elaborate our criteria and then select a few solutions to evaluate. Our choices were the following:

Upgrade to a newer version of Jitsi (both video bridge and meet)
BigBlueButton with the greenlight plugin
RTMP
Using a commercial solution, such as Zoom or WebEx

RTMP was eliminated right away as a videoconferencing solution as it does not allow for bidirectional communication.

Commercial solutions were also eliminated as it would not allow for us to self-host, allowing us to preserve communication confidentiality. Besides, our preference for open source software is very pronounced : ).

BigBlueButton

BigBlueButton was already tested internally before, but at the time (2016) it used Flash for its interface, which has now been changed to HTML5.

Our test showed interesting results, here is a resume of pros and cons:

Pros

Software is open source and the solution can be self-hosted
Have a solid set of features:

Slide-sharing, screen-sharing, webcam, audio, chat, polls, white-board with drawing and text capabilities

Designed for one to many, so it scales really well

Slide-sharing is efficient. You first push your .pdf to the server, then it is broadcasted to every attendee. When you switch slides, it only needs to notify the other users, so it’s well synchronized and almost bandwidth-free
People can join as listeners only
People join with their webcam off by default, except the presenter

Supports NxN

Everybody can put his webcam on if necessary

User management and access control

There is a lot of available functionalities: profiles can be created, or bind the instance with a LDAP server. Everybody can create rooms, and if they do so, they can choose to be the only moderator, or allow everybody to have all the rights.
An access code can be configured which users have to enter before entering a room
You can forward the “presenter” token to the people of your choice (or everybody)
You can mute users that are noisy (and they can just unmute themselves if they need to speak)

A lot of parameters and configuration possibilities (even LDAP integration)

Cons

Supported only on Ubuntu-16–04 (some people seem to run it on other distributions, but lots of concerns around stability)
Bare metal hardware recommended for production, VM are discouraged
Has a lot of dependancies
Maybe too many parameters (and you can get lost tweaking them)
Screen sharing doesn’t support dual screen

Missing functionalities:

In the end, there are always missing functionalities, but they were deemed non-essential in our evaluation and could sometimes be obtained through other software such as:

A whiteboard
Session recordings

Jitsi

Jitsi was already in use in our environment, and we decided for our test to upgrade to the latest version available.

Pros

Open source software and can be self-hosted
Essential feature set: screen-sharing, video feed, audio, chat
The interface is minimalist, easy to understand and intuitive
Supports NxN

Everybody can put his webcam on if necessary

Once jitsi is installed and correctly containerized, maintenance is much less complicated
jitsi development is active and it seems to have good future perspectives:

the Firefox issue[i] is in the process of being fixed and there is the possibility to install a jitsi client (based on Electron)[ii];

2. end-to-end encryption is planned in the future[iii].

In order to achieve a better user experience, we upgraded the configuration of the server which it was running on (more vCPU and more RAM), as well as some tweaks in its original configuration to allow more people in one room without issues, learning from our experience with BigBlueButton:

Only the video streams of the last ten people who spoke is sent to others
Every people who enters a room is automatically muted
Webcam is disabled by default

Cons

Limited user management and authentication
Performance issue with the Firefox browser
No restriction to the usage of the solution
Hard limit to 75 people in a room[iv], performance issues can arise with more than 45 people in a room

Missing functionalities:

In the end, there are always missing functionalities, but they were deemed non-essential in our evaluation and could sometimes be obtained through other software such as:

A whiteboard
Session recordings => accessible with another jitsi component called Jibri

What about the security status of jitsi?

Jitsi security status is openly discussed by its developers on a dedicated page[v], in order to show what security features are available and the state of those still in development.

Jitsi is a collection of components, Meet is the name for both the WebUI and the videoconferencing solution as a whole. Components are mainly developed in Java and JavaScript and source code is available on GitHub at the following address: https://github.com/jitsi

As it is open source, anyone can review the code and report found vulnerabilities to the development team.

As for user management and access control, there are no restrictions to the use of the solution, meaning everyone which has access to the URL can create a room. This solution is then not really recommended to be installed on an external server if you wish to restrict access to your employees only. You can, of course, consider using two solutions, one internally, the other one for external meetings.

The first person to enter a Jitsi room obtains moderators rights, allowing this user to set a password to the room in use. This feature allows to restrict unknown users in joining a discussion.

Conclusion

In the end, we did not go too far from our starting point and stayed with jitsi once upgraded, as it matched with our criteria.

Even though BigBlueButton showed a more solid feature set and more granularity with its access controls parameters, maintenance was easier with jitsi, its community seems larger and future development along with new features seemed more promising.

It allowed for all of our videoconferencing use cases while maintaining our selected level of confidentiality for our meetings. Updating to the last version showed better performance than before as we now use it on a weekly basis with more than 50 people in a room!

As we said in the introduction, the goal here was not to make a complete comparison of the videoconferencing solutions on the market but rather to show our logic and the choices that come with it. One size does not fit all, and a solution which is perfect for our needs might not be the best one for your organization.

If you are in a situation like this today, i.e. evaluating a videoconferencing solution, the questions that helped us choosing the most adequate solution can help you by constituting an assessment framework: