It seems that most people find Jibri implementation to be the most challenging of the suite of solutions. I am by no measure an expert on this, but I’ve done several installs of Jibri, purged it a number of times and reinstalled, so I thought I should share some of what I’ve gained with anyone who may find it useful. I’ll try to explain this in layman terms, so the information is not overwhelming. This is a long read, but it will save you a lot of time and a lot of headache trying to figure out what’s wrong or waiting for help in the forum. If you like, you can just jump to the Troubleshooting and Tips section.
QUICK OVERVIEW:
1. What is Jibri?
Jibri is the recording and streaming instrument for Jitsi Meet conferences. Its capabilities include:
- Record a Jitsi meeting, capturing both audio and video
- Livestream a Jitsi meeting (through any RTMP)
- Do a local (audio) recording of a Jitsi meeting
2. How does it work?
Understanding how Jibri works will help you to know what to look for when you run into problems with it.
Jibri operates just like any other participant in a meeting. It enters the meeting as a hidden user (not sending audio or video of its own) and it records the meeting (screencasting), pretty much the same way as you would use a screen recorder to record events on your screen. In fact, you can confirm the presence of Jibri if you activate “Local Recording” and then look in the speaker stats - you will see a ‘name’ (mix of characters) that shows an extra participant in your meeting. For instance, in the example below, the Participant with the name “8ae9f547” is Jibri.
Jibri does screencasting by joining the meeting just like any other participant, spinning its own ‘monitor’ (which you don’t see), and then recording the meeting from its own screen ('monitor). This is important to note, because, amongst other things, it means that just like one participant can have problems in a meeting while everyone else is fine, Jibri can also have problems, yet a Jitsi Meet conference will run successfully and other participants will not be affected.
One important thing to note: Jibri can only record one meeting at a time. This means you need an instance of Jibri for every meeting you need to record.
TROUBLESHOOTING
Now, this is the main purpose of this tutorial and probably the reason why you clicked this link. There are two messages you’re likely to get when your recording does not start as expected:
- All recorders are currently busy - This happens when all available Jibris are being used. Remember, Jibri can only record one meeting at a time, so if your available pool of Jibris is used up (in use), you will not be able to record until one becomes available. And that’s when you get this message.
- Recording unavailable - This is an error message. It is the generic message you get when something is actually wrong with Jibri - usually telling you Jibri is not properly installed or configured. It’s important to note that you will get this same error message on your screen when Jibri doesn’t work for any reason other than that the available recorders are busy. So the error message itself is not very specific. However, the timing of the error message could be very instructive.
Jibri errors (“Recording Unavailable”)
There are a few things that could go wrong, but as complicated as Jibri seems, the beautiful thing is, there are just a handful of places where those things could go wrong. This makes troubleshooting relatively not as painful.
TIPS
Recording fails immediately
Remember that Jibri is a meeting participant as well, right? So that means, the first problem Jibri could have could be with getting into the meeting room. In fact, one BIG clue that suggests this is the cause of your Jibri problem is that when you click the “Start recording” command, you INSTANTLY get that error message. If recording fails immediately, check the following:
Jibri.conf
- Take a careful look at your Jibri.conf file (/etc/jitsi/jibri/jibri.conf). This is your main configuration file for Jibri and the area where most mistakes happen. This file will pretty much be empty when you first install Jibri, so you have to populate it. If it’s not populated, Jibri will fail instantly.
- Use the sample/reference file to populate your jibri.conf. Make sure you complete the xmpp section using the example from example_xmpp. Here’s a full example of Jibri.conf you can just copy and paste, then make the necessary edits to reflect your domain and registered passwords [click arrow to reveal]:
Jibri,conf
> jibri {
> // A unique identifier for this Jibri
> // TODO: eventually this will be required with no default
> id = ""
> // Whether or not Jibri should return to idle state after handling
> // (successfully or unsuccessfully) a request. A value of 'true'
> // here means that a Jibri will NOT return back to the IDLE state
> // and will need to be restarted in order to be used again.
> single-use-mode = false
> api {
> http {
> external-api-port = 2222
> internal-api-port = 3333
> }
> xmpp {
> // See example_xmpp_envs.conf for an example of what is expected here
> environments = [
> {
> name = "prod environment"
> xmpp-server-hosts = ["your.domain.com"]
> xmpp-domain = "your.domain.com"
>
> control-muc {
> domain = "internal.auth.your.domain.com"
> room-name = "JibriBrewery"
> nickname = "jibri-nickname"
> }
>
> control-login {
> domain = "auth.your.domain.com"
> username = "jibri"
> password = "JPwd"
> }
>
> call-login {
> domain = "recorder.your.domain.com"
> username = "recorder"
> password = "RPwd"
> }
>
> strip-from-room-domain = "conference."
> usage-timeout = 0
> trust-all-xmpp-certs = true
> }]
> }
> }
> recording {
> recordings-directory = "/srv/recordings"
> # TODO: make this an optional param and remove the default
> finalize-script = "/path/to/finalize_recording.sh"
> }
> streaming {
> // A list of regex patterns for allowed RTMP URLs. The RTMP URL used
> // when starting a stream must match at least one of the patterns in
> // this list.
> rtmp-allow-list = [
> // By default, all services are allowed
> ".*"
> ]
> }
> chrome {
> // The flags which will be passed to chromium when launching
> flags = [
> "--use-fake-ui-for-media-stream",
> "--start-maximized",
> "--kiosk",
> "--enabled",
> "--disable-infobars",
> "--autoplay-policy=no-user-gesture-required"
> ]
> }
> stats {
> enable-stats-d = true
> }
> webhook {
> // A list of subscribers interested in receiving webhook events
> subscribers = []
> }
> jwt-info {
> // The path to a .pem file which will be used to sign JWT tokens used in webhook
> // requests. If not set, no JWT will be added to webhook requests.
> # signing-key-path = "/path/to/key.pem"
>
> // The kid to use as part of the JWT
> # kid = "key-id"
>
> // The issuer of the JWT
> # issuer = "issuer"
>
> // The audience of the JWT
> # audience = "audience"
>
> // The TTL of each generated JWT. Can't be less than 10 minutes.
> # ttl = 1 hour
> }
> call-status-checks {
> // If all clients have their audio and video muted and if Jibri does not
> // detect any data stream (audio or video) comming in, it will stop
> // recording after NO_MEDIA_TIMEOUT expires.
> no-media-timeout = 30 seconds
>
> // If all clients have their audio and video muted, Jibri consideres this
> // as an empty call and stops the recording after ALL_MUTED_TIMEOUT expires.
> all-muted-timeout = 10 minutes
>
> // When detecting if a call is empty, Jibri takes into consideration for how
> // long the call has been empty already. If it has been empty for more than
> // DEFAULT_CALL_EMPTY_TIMEOUT, it will consider it empty and stop the recording.
> default-call-empty-timeout = 30 seconds
> }
> }
- In the xmpp section, make sure you enter the names and passwords you chose when creating the relevant accounts for Jibri in Prosody (“jibri” and “recorder”) accurately. Verify and re-verify that you actually entered the usernames and passwords correctly! To verify:
Check the registered recorder name and password
grep password /var/lib/prosody/recorder*/accounts/recorder.dat
sed -n ‘/call.login/, /}/p’ /etc/jitsi/jibri/config.json | grep password
sed -n ‘/call.login/, /}/p’ /etc/jitsi/jibri/jibri.conf | grep password
Check the registered jibri username and password
grep password /var/lib/prosody/auth*/accounts/jibri.dat
sed -n ‘/control.login/, /}/p’ /etc/jitsi/jibri/config.json | grep password
sed -n ‘/control.login/, /}/p’ /etc/jitsi/jibri/jibri.conf | grep password
- If you previously created a config.json file (previous version of Jibri), don’t just copy and paste the contents of that file into your jibri.conf; you need to extract the actual values as the field names are slightly - but significantly - different. [Note that config.json is being deprecated, so it’s best to move your configurations to jibri.conf, if you haven’t done so already. Once you do, delete the config.json file].
Jibri log folder
This is an unusual one, but it’s worth noting. I’ve only seen it happen when I uninstalled and then re-installed Jibri, but who knows? Anyway, if you’ve confirmed that everything is fine with your jibri.conf, go to “/var/log/jitsi” and confirm that you have a directory named “jibri” there. If you don’t, create one and make sure Jibri can write to it (just make jibri the owner). If this directory is missing or if it’s present but Jibri does not have permissions to access it, Jibri will fail instantly. Also. make sure that jibri is part of all the necessary groups:
usermod -aG adm,audio,video,plugdev jibri
Recording fails after a few seconds
This differs significantly from an instant error message. In this case, you get a pop-up message advising that Jibri is “preparing to record the meeting”
But then a few seconds or several seconds later, that pop-up is replaced by the error pop-up.
In this case, it often suggests that Jibri may have been able to enter the meeting, but it wasn’t configured properly, so it’s unable to start recording. In instances like this, it’s not even unusual to have a folder created in the recording directory, but the folder will only contain a metadata.json without an actual mp4 file. When this happens, check the following:
Jibri.conf
- Yes, again, jibri.conf. If you in fact populated your jibri.conf file, but have the wrong values or made a mistake, this could be the reason. What happens is that the configuration is being read (hence the pause) and when it’s discovered that the credentials are wrong, then the error message gets kicked out. Again, do all the checks listed above under Jibri.conf and correct any errors discovered.
Sip Communicator Properties (Jicofo)
- Check your Jicofo configurations for jibri to make sure you’ve entered them correctly:
sudo nano /etc/jitsi/jicofo/sip-communicator.properties
- Confirm that you’ve added the following lines:
org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.my.domain.com
org.jitsi.jicofo.jibri.PENDING_TIMEOUT=90
- BE SURE TO CHANGE “my.domain.com” TO YOUR JITSI SUBDOMAIN NAME!!!
cfg.lua file (Prosody)
- Check your prosody (lua) configuration
nano /etc/prosody/conf.avail/my.domain.com.cfg.lua
Make sure you’ve added this block at the end of the file:
- Again, be sure to remember to edit it to reflect your Jitsi subdomain.
Recording is successful but mp4 is corrupt (cannot be opened)
This is usually due to a java version error. Jibri requires Java 8 to work properly.
- Check to make sure you’ve installed Java 8 on your system.
java -version
- If you have another (more current) version of Java installed, that’s what will be listed when you check your java version.
- To check for multiple versions of java on your system:
update-alternatives --config java
- This should list all the versions. Make sure you see the following line as one of the options:
/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java
- Now, make sure you set it as the correct java home environment variable. Open launch.sh
nano /opt/jitsi/jibri/launch.sh
replace “java” with the full path “/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java”
Finally, ALWAYS restart Jibri when you make any configuration change. This is more often the cause of errors than one would believe.
CONCLUSION
Hopefully one of these tips has helped you to solve your Jibri problem. Please, feel free to add anything else you may have discovered that could prove helpful to others. I will try to add more information as I run across them.
) on 8vCPU and 8GB Memory. After 20 minutes first it eats up all the Memory and then vCPU and finally crashed. Is there any link which I can refer to setup a jibri with optimal cofiguration which can stop this crash?