I have a Jibri Docker instance running with a static IP on AWS and it works fine. To scale up, I set up a load balancer and added the Jibri instance. That does not seem to work. I have added the public DNS of the load balancer to Route53 as a CNAME and mapped to “recording.MYDOMAIN”, same as how it was in the Jibri instance.
When user selects “Start recording”, there is no message and recording does not start. I tested the access to instance via Load balancer with a test HTML page and am able to access that page.
I am using the same security group for the Target group as what was used for the Jibri instance, so incoming port 80 is open.
Is there any additional configuration to do on Jibri while associating with a load balancer and removing static IP of the instance ? Appreciate your help.
What is the load balancer balancing exactly?
I will spawn 30 instances under the load balancer to support multiple parallel recordings, once I get this to work. Right now, I wanted to test and fix this error, so I have kept just one instance under the target group for the load balancer.
Sorry, I still don’t understand the topology.
Jibri’s don’t receive any traffic, they just connect to a Prosody server and receive a command to start recording. Why do you have a load balancer in front of them?
If you have a sharded environment with multiple prosody and jicofo servers you’ll need to configure the jibris to connect to all of the shards in order for the recordings to work.
Let me explain what I am trying to do, please check if that makes sense or if there is a better way.
I have Jitsi + Prosody + Jicofo on one EC2 instance and Jibri Docker on another EC2 instance. As a Jibri instance can handle only one recording at a time, I need to add Jibri instances dynamically to support parallel recordings. Hence planning to use a load balancer with auto-scaling.
Currently, if Jibri instance is standalone (not on a load balancer), recording works fine. But if I add it to an Application Load Balancer, I get error message “Recording service is currently unavailable”. That is the error I am trying to find a fix for.
This means your jibri is not connecting to your shard. You can check jibri logs for that. Why do you need loadbalancer? How do you use it with jibri?
Without a load balancer, how will I support multiple parallel recordings as the demand rises ? I need to dynamically increase the number of Jibri instances as the need for parallel recordings increases.
You need something like an auto-scale group, not a load balancer AFAIK.
You are right but should I just keep an auto-scale group without load balancer ? Will Jibri work with just auto-scale ?
In Jibri Docker, where do we specify the nickname for Jibri ?
Thank you, but this seems to be the configuration where you have Jitsi and Jibri on a single machine ? If Jibri Docker is on a separate instance like my case, is jibri.conf present ? I checked my working installation and found just .env and jibri.yml, did not find jibri.conf. Did I miss something ?
This is the configuration jibri needs to run, you must have it inside the container. The link above shows that for nickname is used the env variable JIBRI_INSTANCE_ID.
And that is dynamically set with part of it the current date
So it must be your network the problem, port 5222 is not accessible from jibri to the prosody.
No, I have used a dockerised Jibri image to set up Jibri on a separate instance and I configured just .env and jibri.yml. I don’t see jibri.conf or 10-config that contains these variables. That instance has been working fine when I keep it as standalone. So does that mean the .env or jibri.yml is where I should specify the Nickname ? Shall I paste my jibri.yml here if that helps you to understand what I am missing about the nickname ?
A question on your point about not needing load balancer and use just auto-scale group. My understanding is that jicofo looks up “recording.MYDOMAIN.com” to reach Jibri. So if I need multiple Jibri instances, how can they all be reached at “recording.MYDOMAIN.com” without having an internet-facing load balancer ?
This is not a web address. It is a virtualhost (think it as a group name) in
Jibris communicate through XMPP server, they don’t need an external web address.
Understood, thank you. Will that work even if Jicofo and Prosody are on one server and Jibri Docker is on another server ? The reason I ask is that I observed this - when I assign an elastic IP to my Jibri instance, recording works but when I deassociate that elastic IP, I get message “All recorders are currently busy” and recording does not work. So does Jibri instance need an elastic IP to work if it is installed on a separate instance ?
This is the jicofo log entries when I got the message “All recorders are currently busy”. Getting this when I don’t assign an elastic IP to the Jibri instance.
Jicofo 2022-11-10 18:10:03.968 INFO:  AutoOwnerRoleManager.electNewOwner#106: Electing new owner: ChatMember[firstname.lastname@example.org.MYDOMAIN.com/bd263641, jid: null]@619811692
Jicofo 2022-11-10 18:10:29.049 INFO:  [email@example.com.MYDOMAIN.com meeting_id=cd85838a-264e-4b74-bb95-e8dd40428d36] BaseJibri.handleJibriRequest#75: Accepted jibri request:
Jicofo 2022-11-10 18:10:29.049 SEVERE:  [firstname.lastname@example.org.MYDOMAIN.com meeting_id=cd85838a-264e-4b74-bb95-e8dd40428d36] JibriSession.startInternal#307: Unable to find an available Jibri, can’t start
Jicofo 2022-11-10 18:10:29.049 INFO:  [email@example.com.MYDOMAIN.com meeting_id=cd85838a-264e-4b74-bb95-e8dd40428d36] JibriRecorder.handleStartRequest#120: Failed to start a Jibri session, all Jibris were busy
Think of jibri as your browser as it is a browser, the same way your browser connects to the meeting is what jibri does, it does not need a public address.
What it needs though is to connect to prosody on port 5222. When it connects and joins a common room, jicofo can find it and use it by sending an xmpp message to jibri. If jibri is not connecting to prosody, jicofo will not find it and will report “Unable to find an available Jibri, can’t start” and you will see the message about no recorders.