[SOLVED] Jibri Error: "org.jivesoftware.smack.sasl.SASLErrorException:"

In another episode of “it’s probably so obvious, I’ll be embarrassed I missed it”, :man_facepalming:t5: I can’t seem to figure out how to get my Jibri back up again. I purged and reinstalled Jitsi (to take advantage of latest features), got it running fine, but have since been struggling trying to get Jibri back up. I had the old configuration (with config.json), but I’ve edited the new jibri.conf file accordingly, still no luck. I strongly suspect it’s something to do with some access credentials somewhere, but I can’t figure out what. Port 5222 is confirmed open, JVB has correct secret. Again, Jitsi runs flawlessly, but Jibri is showing me no love. Yes, I’ve searched through the forum and searched at length online, but I’m still stumped. Here are my relevant log findings:

Jibri Log:

2020-10-31 18:31:40.980 WARNING: [27] org.jitsi.xmpp.mucclient.MucClient.log() Disabling certificate verification!
2020-10-31 18:31:41.618 INFO: [27] org.jitsi.xmpp.mucclient.MucClient.log() Connected.
2020-10-31 18:31:41.619 INFO: [27] org.jitsi.xmpp.mucclient.MucClient.log() Logging in.
2020-10-31 18:31:41.642 SEVERE: [27] org.jitsi.retry.RetryStrategy.log() org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:292)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1100)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:1000)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1016)
at java.lang.Thread.run(Thread.java:748)

Jicofo Log:

Jicofo 2020-10-31 18:38:12.282 SEVERE: [37] org.jitsi.jicofo.recording.jibri.JibriSession.log() Unable to find an available Jibri, can’t start
Jicofo 2020-10-31 18:38:12.283 INFO: [37] org.jitsi.jicofo.recording.jibri.JibriRecorder.log() Failed to start a Jibri session, no Jibris available

Jvb Log:

2020-10-31 04:27:19.470 WARNING: [16] [hostname=localhost id=shard] MucClient.lambda$getConnectAndLoginCallable$7#673: [MucClient id=shard hostname=localhost] error connecting
org.jivesoftware.smack.SmackException$ConnectionException: The following addresses failed: ‘localhost:5222’ failed because: localhost/ exception: java.net.ConnectException: Connection refused

Prosody Log (removed “<” in front of “iq” to allow posting):

warn Component not connected, bouncing error for: iq to=‘focus.conference.example.com’ id=‘E0qsY-42’ from=‘focus@auth.conference.example.com/focus42754911285’ type=‘get’>"

And my Jibri.conf (relevant portion):

xmpp {
environments = [
name = “prod environment”
xmpp-server-hosts = [“conference.example.com”]
xmpp-domain = “conference.example.com

            control-muc {
                domain = "internal.auth.conference.example.com"
                room-name = "JibriBrewery"
                nickname = "jibri-nickname"

            control-login {
                domain = "auth.conference.example.com"
                username = "jibri"
                password = "Jibrip@wd"

            call-login {
                domain = "recorder.conference.example.com"
                username = "recorder"
                password = "RecorderPwd"

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


What am I missing/overlooking?

Just to eliminate one thing, in case it’s causing problems: did you delete your config.json file? If it’s there, Jibri will use values from it before checking jibri.conf.

Hi @bbaldino,

I did (after seeing your comment on another thread recommending it), but it didn’t work, so I just put it back there. The values are all the same and from what I read, it will still be supported for now, so I played safe and put it back. Still no luck.

Oh, even JVB can’t connect it seems–so this doesn’t appear to be a Jibri-specific issue?

I’m unsure about that as I was able to run a mock meeting with 4 participants without any issue. So, in my thinking, Jitsi works fine, Jibri is where I’m having an issue. For what it’s worth though, Jibri service shows as “Active”.

Did you check the prosody accounts and passwords?

cat /var/lib/prosody/recorder*/accounts/recorder.dat
cat /var/lib/prosody/auth*/accounts/jibri.dat

Hi @emrah!

Yes I did - confirmed everything matches. But I still strongly feel like it’s some credentials issue somewhere. Just can’t figure out where.

curl http://your.domain.com:5222/

on the server

And check the Java version too

Yes, I checked that too, just to be sure - Java 8 running and still set as default. Remember I had Jibri running perfectly fine before I did this Jitsi reinstall. Probably a far cry, but I wonder if the websockets thingy could be a consideration, because it’s the only thing that’s changed in the core architecture. :thinking: My previous Jitsi installation used multiplexing, I hadn’t migrated to websockets.

Did you reinstall Jibri too?

Tried to do that when it wasn’t working - reinstall over the previous installation. Didn’t help. But I never uninstalled Jibri. May have to look into doing that next.

I’ve solved this. I removed both prosody accounts and re-added them. Although the credentials are the same, that somehow fixed the problem. It’s weird, but at this point, I’m just glad it’s fixed. :man_shrugging:t5:

One thing I see as a persistent problem is that the error records Jibri throws in the log appear to be generic, for the most part. I’ve seen the same error for a range of issues. Hopefully, this is something we can fine-tune eventually. It makes it awfully tough to debug when the same error record is entered in the log for different issues, it’s like fishing in the dark.

Appreciate you guys chipping in.