Galène (or Galene) is a videoconference server (an “SFU”) that is easy to deploy and that requires moderate server resources. It was originally designed for lectures and conferences (where a single speaker streams audio and video to hundreds or thousands of users), but later evolved to be useful for student practicals (where users are divided into many small groups), and meetings (where a dozen users interact with each other).
Galène is used in production at two major universities (Université de Paris and Sorbonne Université) for lectures, practicals, seminars, and for staff meetings. It has been used to host two conferences (SOCS'2020 and JFLA'2021).
Galène's server side is implemented in Go, and uses the Pion implementation of WebRTC. The server is regularly tested on Linux/amd64 and Linux/arm64; it has been shown to run on Linux/armv7 and Linux/mips (OpenWRT), and even on Windows. It should in principle be portable to other systems, including Mac OS X. The client is implemented in Javascript, and works on recent versions of all major web browsers, both on desktop and mobile (but see below for caveats with specific browsers).
While traffic is encrypted and authenticated from sender to server and again from server to receiver, Galène does not perform end-to-end encryption: anyone who controls the server might, in principle, be able to access the data being exchanged. For best security, you should install your own server.
Galène's is not the only self-hosted WebRTC server. High-quality alternatives include Janus, Ion-SFU, and Jitsi.
Galène is free and open source software, subject to the MIT licence. Galène's development is supported by Nexedi, who fund Alain Takoudjou's work on the user interface.
Go to galene.org:8443 and choose public (no password required).
git clone https://github.com/jech/galene
Mailing list archives, Atom feed.
Please subscribe to the galene at lists.galene.org mailing list. This list is both for user questions and development of Galène.
Get the source code by doing
These packages are provided by users, and have not necessarily been verified by Galène's author.
Galène's protocol is designed to be shared by multiple clients. In addition to the default client, at least the following are available:
The server is reasonably complete:
The following features are currently in the source repository but haven't been released in a stable version yet:
The following server features are planned but haven't been implemented yet:
The following features would be nice to have, but need support from the browser:
I am less sure about the following features:
The frontend is very usable:
A number of features are currently only available as commands to be
typed in the chat window (type /help for help). We are
working on making them available from the GUI.
If you don't like our frontend, it should be easy to roll your own. Human-readable outline. API documentation.
For a typical lecture (less than 100 students), Galène needs roughly 1/4 of a CPU core.
For one-to-many communication (lectures), the behaviour is linear, and Galène should be able to serve about 400 participants per core. For many-to-many communication (meetings), the behaviour is quadratic (the server load grows as the square of the number of participants), expect to be able to handle on the order of 20 participants in a single meeting on one core, 40 on four cores (and of course way more if some participants don't switch their camera on — we regularly have staff meetings with fifty participants or so, but only a dozen have their cameras switched on).
Galène assumes that the server is trusted: all media is decrypted by the server and reencrypted before it is sent to the clients. This is, as far as I know, unavoidable with DTLS-SRTP, the security mechanism used by WebRTC. (Yes, I know about insertable streams.)
On the other hand, since the client is not trusted, any bugs in the client code should in principle not create security issues. Thus, it is reasonable to build user-friendly clients using the unscrutable Javascript frameworks that web developers tend to like.
Be aware however that I am neither a security specialist nor a competent system administator, and I may have gotten something wrong.
This indicates that Galène couldn't reach any TURN servers. If you're running the built-in TURN server, this may very well happen if you're behind NAT and your NAT device doesn't support hairpinning. Please don't run Galène behind NAT, or use a better NAT device, or use a TURN server that is not behind NAT.
If you are running an external TURN server, this probably indicates that there's something wrong with the TURN configuration; please check your TURN server's logs. You might get additional hints by running
PION_LOG_TRACE=ice ./galene
In order to authentify and encrypt communication between the clients and the server, Galène needs a data structure called a TLS server certificate. If a TLS certificate is not found on disk, Galène will generate one itself. This ``self-signed'' certificate is not known to the browsers, who are therefore unable to verify that it belongs to a trusted entity, and end up displaying a big red warning.
(Which is silly. Browsers don't display the warning for plain HTTP, which is completely insecure, but do display the warning for encrypted communication using self-signed certificates, which is only vulnerable to active attacks.)
In order to avoid the warning, you will need to obtain an official
certificate, registered with an entity that is trusted by the browsers, and
make it available to Galène under data/cert.pem
and data/key.pem; please see
Galène's README for
instructions. I get mine from Let's
Encrypt.
We aim to support all recent browsers that support WebRTC, on both desktop and mobile. See the list of browsers supporting WebRTC.
Go to System Preferences ⟶ Privacy and Security ⟶ Screen Recording, and grant the required permissions to your browser.
None of the currently available browsers for mobile support screen sharing. See the the list of browsers supporting screen sharing.
Safari's support for screen sharing is incomplete. Please use Firefox or Chrome for screensharing on Mac OS.
(Safari is a fine browser, a pity it has such limitations.)
This is a known
bug
in Chrome. Workarounds include downgrading to Chromium 87, and
disabling hardware acceleration for video in chrome://settings.
After you have refused access to the camera, Safari on mobile remembers your choice. You can get it to forget your choice by erasing the site's cookies (Settings⟶Safari⟶Advanced).
Safari for iOS doesn't like self-signed certificates; you will need to use a TLS certificate signed by a CA trusted by iOS. See this issue for details.
Activity detection relies on the totalAudioEnergy statistic,
which is not implemented in Firefox. Sorry.
Just pick your favourite PDF reader, scale it to a reasonable size, and share its window using the share screen button. I use µPDF. You may share multiple windows simultaneously (e.g. both a PDF with your slides and a drawing program or a text editor).
Alternatively, open the PDF in a second browser tab, and share that tab.
Just open the same group in two browser windows. Choose Present in one but not the other. Make sure you are using headphones.
Open the same group in two distinct browser windows (or tabs). In the second window, select your second camera, disable the microphone, and choose Receive: nothing.
Make sure allow-recording is set in your group
configuration. Log-in as an operator, then say /record
before you start your lecture. Don't forget to say /unrecord
at the end. You will find your recordings under
https://server.example.com/recordings/groupname/.
Subgroup's are Galène's replacement for what other
videoconferencing software calls break-out groups; we have found
them to be useful for student practicals, where students work in groups of
2 or 3 people. A subgroup of a group G is simply a group with
a name of the form G/H, i.e. the name of G followed
by a slash followed by a string H. The administrator can get the
list of all active (non-empty) subgroups of the current group with the
command
/subgroups.
There are two ways to create subgroups. The first is to create them
manually, just like ordinary groups: the subgroup G/H is defined
by the file groups/G/H.json,
i.e. file H.json in a subdirectory G/ of
the groups directory.
The second is to request that they be created automatically by
specifying 'allow-subgroups': true in G's definition
file. When this flag is specified, any subgroup of G will
automatically be created whenever somebody attempts to join it. The
automatically created subgroup's configuration is an (almost) exact copy
of the supergroup's: identical usernames, passwords and permissions.
If you sound like you're under water, you are putting too much load on the echo suppressor. This is a problem on the sender side. Please use headphones; if that is not possible, reduce your speakers' volume or your microphone gain.
If your voice occasionally sounds like a robot in an old science-fiction movie (or a vocoder), then you're suffering from more packet loss than the concealement algorithm can handle. This could be a problem on the sender side, on the receiver side, or both. Please use a wired connection, or at least avoid having a bearing wall between you and your access point.
It increases the resolution and attempts to preserve detail at the cost of framerate. Your blackboard will be legible, but your movements might become choppy.
Yes, but it's an undocumented feature, and the UI may change at any time. In the chat window, type something like
No, we don't (but thanks to all who asked). Please support your local homeless person, or make a donation to the charity of your choice (preferably a non-religious one).