[Solved] After setting secure domain -> "CONFERENCE FAILED: conference.videobridgeNotAvailable"

Hello, my first post here.

Today I set up Jitsi Meet on my VPS (fresh install, Debian 10) following the latest quick install manual.

Setting up the server went well like a charm. With my desktop and MacBook I confirmed that a conference room was established and it was working. During the set up I purchased SSL certificate and installed it manually, which also worked fine.

Description of the issue:

tl:dr; After setting secure domain, I cannot log in with the conference room anonymously due to the error CONFERENCE FAILED: conference.videobridgeNotAvailable. By opening the conference room URL with a different browser than one which logged in the room as a host, the conference fails with the error on both host and anonymous user.

(As an example I am going to set [your-hostname]as jitsi-123.com)

After completeing the quick install I proceeded to setting secure domain to limit who can start a conference, following the manual on the latest README.md (Secure Domain) which is available at https://github.com/jitsi/jicofo.

On SSH console I opened /etc/prosody/conf.avail/jitsi-123.com.cfg.lua and enabled authentication on my main domain.

VirtualHost "jitsi-123.com"
    authentication = "internal_plain"

Also I added new virtual host with anonymous login method for guests on the same file.

VirtualHost "guest.jitsi-123.com"
    authentication = "anonymous"
    c2s_require_encryption = false

And then I opened /etc/jitsi/meet/jitsi-123.com-config.js to configure anonymousdomain follwing the instruction:

            domain: 'jitsi-123.com',
            anonymousdomain: 'guest.jitsi-123.com',

After that I stopped jicofo with sudo service jicofo stop to configure /etc/jitsi/jicofo/sip-communicator.properties:


and created a user (“exampleUser”) with prosodyctl register exampleUser jitsi-123.com exampleUserPass.

After doing these steps I restarted the machine with sudo shutdown -r now.

After starting up the machine I opened https://jitsi-123.com, and started a conference named temp (https://jitsi-123.com/temp).

On the page a pop-up saying Waiting for the host was displayed. I clicked I am the host to input exampleUser to the username field and exampleUserPass to the password field, and clicked OK.

After the conference room was established with the user account, I opened the same URL https://jitsi-123.com/temp with another browser to see if anonymous user cannot start a new conference.


Expected result:

The anonymous browser should log in with the conference room.


Actual result:

The anonymous browser cannot log in. The conference fails not only on the anonymous user but also on the host.

Both browsers console prompt the error CONFERENCE FAILED: conference.videobridgeNotAvailable.

After closing the anonymous user browser, the conference is established again.

I am new to jitsi and not familiar with linux. Any help would be appreciated. Thanks in advance!

The issue was related with the SSL certificate which does not include chain certs.

After adding them with my site cert and restarting nginx, the issue was fixed.

SOLVED: Android immediately disconnects, always

EDIT: too slow — you’ve fixed!

Probably this. I’d suggest either going for a Let’s Encrypt certificate, or else making sure you have the full certificate chain set up for your own certificate.

1 Like

The reason why I didn’t chose Let’s Encrypt was I wanted to use Android / iOS apps. :smiley:

I haven’t tried Android, but iOS works fine with Let’s Encrypt certs (I have a Let’s Encrypt cert on my jitsi installation, and I connect to it from an iOS client).

iOS (and perhaps Android) won’t work with self-signed certs.

Ah maybe I misunderstood here https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md#generate-a-lets-encrypt-certificate-optional-recommended

Note: Jitsi Meet mobile apps require a valid certificate signed by a trusted Certificate Authority and will not be able to connect to your server if you choose a self-signed certificate.

If I used Let’s Encrypt from the first, the issue above would have not happened at all… Now that everything works well, I am not going to think about that too much :expressionless:


LE certs have a trusted root provider.

Self-signed certs don’t.

1 Like