Unable to run jibri setup successfully on separate instance

We have two EC2 instance…In first instance(A) we installed jitsi meet and jibri…It is working fine. Now we have second instance(B) , we installed jibri…
In second instance our jibri.conf as below

    xmpp {
    environments = [{
    name = "eb-environment"
    xmpp-server-hosts = ["instance A domain"]
    xmpp-domain = "instance A domain"

    control-muc {
      domain = "internal.auth.instance A domain"
      room-name = "JibriBrewery"
      nickname = "different nickname for instance B"
    }

    control-login {
      domain = "auth.instance A domain"
      username = "jibri2"
      password = "__PASSWD1__"
    }

    call-login {
      domain = "recorder.instance A domain"
      username = "recorder2"
      password = "__PASSWD2__"
    }

The /etc/prosody/prosody.cfg.lua in intsance A domain
– internal muc component, meant to enable pools of jibri and jigasi clients
Component “internal.auth.instance A domain” “muc”
modules_enabled = {
“ping”;
}
– storage should be “none” for prosody 0.10 and “memory” for prosody 0.11
storage = “memory”
muc_room_cache_size = 1000
— VirtualHost
VirtualHost “recorder.instance A domain”
modules_enabled = {
“ping”;
}
authentication = “internal_plain”

prosodyctl register jibri2 auth.instance A domain PASSWD1
prosodyctl register recorder2 recorder.instance A domain PASSWD2

org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.instance A domain
org.jitsi.jicofo.jibri.PENDING_TIMEOUT=90

hiddenDomain: ‘recorder.instance A domain’,

Is there anything we failed to do? Can somebody help us resolve this?

  • Is TCP/5222 publicly open on JMS?
  • Can the additional jibri resolv Jitsi-meet FQDN?
  • Is the additional jibri in the same network or not…?

Is TCP/5222 publicly open on JMS? Yes

Output when giving sudo ufw status verbose


80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN Anywhere
10000/udp ALLOW IN Anywhere
22/tcp ALLOW IN Anywhere
3478/udp ALLOW IN Anywhere
5349/tcp ALLOW IN Anywhere
22,80,443,5222,5347/tcp ALLOW IN Anywhere
5222/tcp ALLOW IN Anywhere
5281 ALLOW IN Anywhere
80/tcp (v6) ALLOW IN Anywhere (v6)
443/tcp (v6) ALLOW IN Anywhere (v6)
10000/udp (v6) ALLOW IN Anywhere (v6)
22/tcp (v6) ALLOW IN Anywhere (v6)
3478/udp (v6) ALLOW IN Anywhere (v6)
5349/tcp (v6) ALLOW IN Anywhere (v6)
22,80,443,5222,5347/tcp (v6) ALLOW IN Anywhere (v6)
5222/tcp (v6) ALLOW IN Anywhere (v6)
5281 (v6) ALLOW IN Anywhere (v6)

Can the additional jibri resolv Jitsi-meet FQDN?

We have setup the FQDN.But have not installed jitsi-meet.

1.sudo hostnamectl set-hostname instance B

2.Added in etc/hosts
#YOUR_LOCAL_IP_IF_BEHID_NAT YOUR_JIBRI_DOMAIN YOUR_HOST_NICK
PubicIp of EC2instance instance B name nickname
127.0.0.1 localhost instance B name

Is the additional jibri in the same network or not…?
Instance A and Instance B are in the same AWS account…but are in different region(Ohio and Mumbai)

  • ‘ufw’ output doesn’t mean it’s open

  • Can jibri resolv the JMS address (instance A FQDN)?

service jibri status
● jibri.service - Jibri Process
Loaded: loaded (/etc/systemd/system/jibri.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-11-22 14:31:15 UTC; 4s ago
Process: 27024 ExecStop=/opt/jitsi/jibri/graceful_shutdown.sh (code=exited, status=0/SUCCESS)
Main PID: 27030 (java)
Tasks: 44 (limit: 4584)
CGroup: /system.slice/jibri.service
└─27030 /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java -Djava.util.logging.config.file=/etc/jitsi/jibri/logging.properties -Dconfig.file=/etc/jit

Nov 22 14:31:15 instanceA systemd[1]: jibri.service: Main process exited, code=exited, status=143/n/a
Nov 22 14:31:15 instanceA systemd[1]: jibri.service: Failed with result ‘exit-code’.
Nov 22 14:31:15 instanceA systemd[1]: Stopped Jibri Process.
Nov 22 14:31:15 instanceA systemd[1]: Started Jibri Process.
Nov 22 14:31:17 instanceA launch.sh[27030]: SLF4J: Failed to load class “org.slf4j.impl.StaticLoggerBinder”.
Nov 22 14:31:17 instanceA launch.sh[27030]: SLF4J: Defaulting to no-operation (NOP) logger implementation
Nov 22 14:31:17 instanceA launch.sh[27030]: SLF4J: See SLF4J Error Codes for further details.

Looking for other answers and will reply soon

‘ufw’ output doesn’t mean it’s open

on executing netstat -ltnp | grep -w LISTEN

tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 15981/nginx: worker
tcp 0 0 0.0.0.0:5280 0.0.0.0:* LISTEN 24106/lua5.2
tcp 0 0 172.31.38.127:5349 0.0.0.0:* LISTEN 1053/turnserver
tcp 0 0 127.0.0.1:5349 0.0.0.0:* LISTEN 1053/turnserver
tcp 0 0 172.31.38.127:5349 0.0.0.0:* LISTEN 1053/turnserver
tcp 0 0 127.0.0.1:5349 0.0.0.0:* LISTEN 1053/turnserver
tcp 0 0 0.0.0.0:5222 0.0.0.0:* LISTEN 24106/lua5.2
tcp 0 0 172.31.38.127:5350 0.0.0.0:* LISTEN 1053/turnserver
tcp 0 0 127.0.0.1:5350 0.0.0.0:* LISTEN 1053/turnserver
tcp 0 0 172.31.38.127:5350 0.0.0.0:* LISTEN 1053/turnserver
tcp 0 0 127.0.0.1:5350 0.0.0.0:* LISTEN 1053/turnserver
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 15981/nginx: worker
tcp 0 0 0.0.0.0:5269 0.0.0.0:* LISTEN 24106/lua5.2
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 825/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1026/sshd
tcp6 0 0 :::443 :::* LISTEN 15981/nginx: worker
tcp6 0 0 :::5280 :::* LISTEN 24106/lua5.2
tcp6 0 0 :::9090 :::* LISTEN 24126/java
tcp6 0 0 :::3333 :::* LISTEN 27030/java
tcp6 0 0 ::1:5349 :::* LISTEN 1053/turnserver
tcp6 0 0 ::1:5349 :::* LISTEN 1053/turnserver
tcp6 0 0 :::5222 :::* LISTEN 24106/lua5.2
tcp6 0 0 ::1:5350 :::* LISTEN 1053/turnserver
tcp6 0 0 ::1:5350 :::* LISTEN 1053/turnserver
tcp6 0 0 :::2222 :::* LISTEN 27030/java
tcp6 0 0 127.0.0.1:8080 :::* LISTEN 24126/java
tcp6 0 0 :::80 :::* LISTEN 15981/nginx: worker
tcp6 0 0 :::5269 :::* LISTEN 24106/lua5.2
tcp6 0 0 :::22 :::* LISTEN 1026/sshd
tcp6 0 0 :::8888 :::* LISTEN 24083/java

Is TCP/5222 publicly open on JMS…if not please help how to fix it?

Able to connect from jibri server to jitsi server
curl http://jitsiservername:5222

<?xml version='1.0'?>

but not able to connect from jitsi server to jibri server
curl http://jibri.co:5222
curl: (6) Could not resolve host: jibri.co

It seems that tcp/5222 is OK

Is this the whole jibri.conf?

jibri.conf file

jibri {
id = “”
single-use-mode = false

recording {
recordings-directory = “/srv//recordings”
#finalize-script = “/usr/local/bin/finalize_recording.sh”
}

streaming {
rtmp-allow-list = [
“.*”
]
}

chrome {
flags = [
// “–ignore-certificate-errors”,
“–use-fake-ui-for-media-stream”,
“–start-maximized”,
“–kiosk”,
“–enabled”,
“–disable-infobars”,
“–autoplay-policy=no-user-gesture-required”
]
}

ffmpeg {
resolution = “1920x1080”
audio-source = “alsa”
audio-device = “plug:bsnoop”
}

api {
http {
internal-api-port = 2222
external-api-port = 2222
}

xmpp {
  environments = [{
    name = "eb-environment"
    xmpp-server-hosts = ["instance A domain name"]
    xmpp-domain = "instance A domain name"

    control-muc {
      domain = "instance A domain name"
      room-name = "JibriBrewery"
      nickname = "jibri-nickname"
    }

    control-login {
      domain = "auth.instance A domain name"
      username = "jibri2"
      password = "__PASSWD1__"
    }

    call-login {
      domain = "recorder.instance A domain name"
      username = "recorder2"
      password = "__PASSWD2__"
    }

    strip-from-room-domain = "conference."
    usage-timeout = 0
    trust-all-xmpp-certs = true
  }]
}

}

stats {
enable-stats-d = true
}

call-status-checks {
no-media-timeout = 30 seconds
all-muted-timeout = 10 minutes
default-call-empty-timeout = 30 seconds
}
}

Can jibri resolv the JMS address (instance A FQDN)? How to check it

the etc/hosts in instance A
127.0.0.1 localhost
PublicIP EC2AWSinstance A instanceA domain name