Recording multiple conferences

Hi there!

I have been tasked to evaluate ways to record Jitsi conferences.

Our problem with the recommended solution Jibri is that it requires a seperate instance per conference that needs recording and it does so using a virtual X-server (if I understood it correctly). This seems very inefficient and may even be an added security risk.

What we’d like is for a recording solution baked into jitsi-videobridge component, like it seems it was implemented already a long time ago but depricated and removed from there in 2017. Can you tell us what the reasoning behind that decision was?

I also found this interesting quite recent article about recording Jitsi conferences:
http :// blog.radiumz .org/en/article/local-recording-jitsi-meet
But sadly it does this using the Jitsi Meet client code running in a browser instead of on the server, which does not meet our requirements.

Can somebody give me further leads or comments on my findings so far or even suggestions how to to achieve our goal?

Thanks a lot for this great open source software suite! :slight_smile:

Why you think it my add a security risk?

Because it is inefficient and time-consuming. The bridge must record audio and video per channel, bringing down bridge performance by a lot, requiring bridge to have a lot of storage space. Moving those files from there to some post-processing node increases bridge required bandwidth bringing down live streams performance. Then you need a lot of post-processing power for decoding all the video and audio, merging it into usable video stream where all the complexity comes and then encoding. What if UI changes, you need to modify that video composing every time that happens. Will you handle dominant speaker changes? What about follow me? What about cascading geo-located bridges and transferring data between regions?

This is audio only recording.

We had experimented with first recording in the bridge, then recording with a component that enters the conference like client and saves decomposed video and again is hit by the post-processing complexity to come to the todays solution to be the best in terms of complexity, performance and flexible to all future changes and the least cost of all other solutions.


Hello @damencho!

Thanks a lot for your great answer!

On the question of why we see Jibri as an increased security risk compared to recording within jitsi-videobridge:

It requires an X server and a Chrome browser running on the server to act as a dummy client to do the recording. Both a browser and X server increase the attack surface, in that if there is any exploit of Jitsi itself that allows for injection, the underlying server-side browser could possibly be reached, then fooled into running that code, in turn opening up a whole realm of attack vectors. While speculation, it is a viable threat model.

Besides that, we think Jibri is an impractical solution since most of our meetings occur unplanned and without administrators involvement. Often we have several meetings occurring concurrently and it’s difficult to predict how many of them may want to record their conference.

If we have to go with Jibri, then so be it. We will just need to be undertake a large audit of the whole stack, once installed on a staging server. But how we then work it such that we automatically spawn new instances for each user-defined recording is a new challenge of its own.