OpenTalk RoomServer: Streamlined architecture for scalable open-source video conferencing
A meeting is in progress: participants are chatting, raising their hands, voting and drawing together on the whiteboard. All of this flows through the Controller – which simultaneously manages user accounts, stores recordings and whiteboard files, and, in cluster mode, synchronises the meeting status across multiple instances. These are tasks that have little to do with one another, yet were long bundled together within a single service.
With the OpenTalk RoomServer, we’re changing that. This article introduces the new component, which from release 26.2 onwards will handle all meeting logic – and explains why this separation makes OpenTalk more scalable, robust and easier to operate.
Scaling through separation: Controller and RoomServer working together
OpenTalk has made a number of architectural decisions in recent years. The most visible was the switch from Janus to LiveKit, which has since taken over video and audio. The next change is now underway – and it concerns the Controller.
Previously, several Controller instances shared responsibility for ongoing meetings – which meant they had to constantly synchronise their current status: Who is in the room? Who has the floor? What is the status of the vote? Every event in the meeting had to be synchronised across all instances to ensure they were all in the same state. The resulting network overhead made the code complex – and introduced a whole class of errors that exist solely because multiple instances must constantly agree with one another.
One meeting, one RoomServer – the new architectural principle
The RoomServer does things differently. Each meeting runs on exactly one instance – the entire state is held in one place, without the need for synchronisation with other instances. This not only simplifies the code considerably, but also makes the system more robust: an entire class of errors that can only arise from distributed state simply no longer exists.
Multiple meetings can run on the same RoomServer without any issues. And if you need more capacity, you simply start additional RoomServers – the meetings are then distributed across the available instances. Controllers and RoomServers can be scaled independently of one another: a higher meeting load means more RoomServers; more dashboard traffic means more controller instances.
What’s inside the RoomServer: modules and a clear principle
The RoomServer is written in Rust and uses Axum as its HTTP framework. What makes its architecture interesting is its module system: every feature in a meeting is a standalone module – chat, show of hands, polls, whiteboard, subroom audio, recording and end-to-end encryption. Even things that you might not recognise as ‘modules’ at first glance are in fact modules: the meeting minutes, for example, or the attendance report for training sessions. Each module handles exactly one task – and only that one.
Communication works in two directions. Events within the meeting, such as a show of hands or a new chat message, arrive at the RoomServer via WebSocket and are processed by the relevant module. Externally – that is, with the Controller or other internal services – the RoomServer communicates via a REST API. The types and data structures transmitted over the network are defined in separate packages and clearly separated from the logic – this ensures the interfaces are stable and can be developed independently of one another.
This offers a practical advantage for operators: administrators can, for example, restrict screen sharing to moderators or globally disable certain features via the controller configuration.
What else is changing with Release 26.2: Tile view, reactions, guest access and more
A new development always offers the chance to rethink and correct things. Alongside the new RoomServer, OpenTalk 26.2 also introduces further changes:
- Tile view: The tile view has been expanded and now displays up to 24 participants simultaneously per page. The layout can also be customised more extensively. Active participants are more clearly visible in the tile view. Anyone who is currently speaking or has their video enabled is automatically placed on the first page.
- Emoji reactions: Participants can provide quick feedback during a call without interrupting the conversation. This makes it easier for moderators to recognise whether there is agreement, questions or a general mood in the room.
- Guest access: Guest access can now be specifically enabled or disabled. Previously, meetings were generally open to guests; with the new setting, access control is clearer. In addition, meetings can still be password-protected. The waiting room can be enabled either for all participants or for guests only.
- Whiteboard: We have replaced SpaceDeck with Excalidraw. Excalidraw is more stable, faster and more intuitive to use – an active open-source community is continuously driving its further development.
- Audio output device: In the audio settings, you can now select not only the input device but also the output device – such as speakers or headphones.
- OpenCloud for shared folders: OpenCloud will now also be available as a provider for shared folders.
- Outlook add-in: Calendar integration has been expanded: the Outlook add-in is now also available to SaaS customers.
More articles
From choice to digital sovereignty
Digital sovereignty, in particular, warrants closer examination: what scope for action does open-source code provide?
Implementing hybrid working effectively - technology, culture, processes
At first glance, implementing hybrid working models seems straightforward: staff work partly in the office and partly remotely, supported