Room crashes when anyone trys to join

Hi
Ive setup on digital ocean and have my domain available and server running.
I followed the quick guide, had some issues with Nginx with 443 but changed the Jitsi to 4443
Set up a room and when any anyone trys to join to crashes instantly.
Looks like something else needs configured thats not on the quickstart.

On jicofo log

Jicofo 2020-03-30 12:38:50.674 SEVERE: [27] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Can not invite participant – no bridge available.
Jicofo 2020-03-30 12:38:50.674 WARNING: [27] org.jitsi.jicofo.bridge.BridgeSelectionStrategy.log() Failed to select initial bridge for participantRegion=null
Jicofo 2020-03-30 12:38:50.674 SEVERE: [27] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Can not invite participant – no bridge available.

Check your bridge logs? What prosody version do you use?

Hi,

same problem here.

jitsi-meet 1.0.4335-1
jitsi-meet-prosody 1.0.3928-1
jitsi-meet-web 1.0.3928-1
jitsi-meet-web-config 1.0.3928-1
jitsi-videobridge2 2.1-157-g389b69ff-1
prosody 0.11.2-1
prosody-modules 0.0~hg20190203.b54e98d5c4a1+dfsg-1+deb10u1

Conferences are working. Now, user authentication for room creation was enabled followed

As soon as /etc/jitsi/jicofo/sip-communicator.properties was modified into
org.jitsi.jicofo.auth.URL=XMPP:FQDN

rooms crash when anyone else trys to join:

Jicofo 2020-04-02 13:36:06.914 WARNING: [31] org.jitsi.jicofo.bridge.BridgeSelectionStrategy.log() Failed to select initial bridge for participantRegion=null
Jicofo 2020-04-02 13:36:06.914 SEVERE: [31] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Can not invite participant – no bridge available.

Set the sip communicator properties to default, rooms are working (without authentication) again.

Check jvb logs.

Hi Damencho

Firstly thanks for the advice and you are doing a great job on here.

I seen on another thread to install the unstable build then remove the enabled60-jitsi-meet.conf folder from
/etc/nginx/sites-enabled/60-jitsi-meet.conf
Steps
Install from here


remember the lets encrypt part as well
/usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
goto
cd /etc/nginx/sites-enabled/
rm 60-jitsi-meet.conf
restart nginx
sudo systemctl restart nginx

Job done

Now, there was an update available:

jitsi-meet 2.0.4376-1
jitsi-meet-prosody 1.0.3962-1
jitsi-meet-web 1.0.3962-1
jitsi-meet-web-config 1.0.3962-1
jitsi-videobridge2 2.1-163-g63d2f9da-1
prosody 0.11.2-1
prosody-modules 0.0~hg20190203.b54e98d5c4a1+dfsg-1+deb10u1

The logs do not say anything:

jvb.log

2020-04-02 20:41:24.702 SEVERE: [21] Health.doRun#300: Health check failed in 0ms:
java.lang.Exception: Address discovery through STUN failed
at org.jitsi.videobridge.health.Health.doCheck(Health.java:138)
at org.jitsi.videobridge.health.Health.doRun(Health.java:266)
at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)
2020-04-02 20:41:34.703 SEVERE: [21] Health.doRun#300: Health check failed in 0ms:
java.lang.Exception: Address discovery through STUN failed
at org.jitsi.videobridge.health.Health.doCheck(Health.java:138)
at org.jitsi.videobridge.health.Health.doRun(Health.java:266)
at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

jicofo.log

Jicofo 2020-04-02 20:41:28.213 WARNING: [31] org.jitsi.jicofo.bridge.BridgeSelectionStrategy.log() Failed to select initial bridge for participantRegion=null
Jicofo 2020-04-02 20:41:28.213 SEVERE: [31] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Can not invite participant – no bridge available.
Jicofo 2020-04-02 20:41:28.214 WARNING: [31] org.jitsi.jicofo.bridge.BridgeSelectionStrategy.log() Failed to select initial bridge for participantRegion=null
Jicofo 2020-04-02 20:41:28.215 SEVERE: [31] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Can not invite participant – no bridge available

Guess it’s the same problem, for which I mentioned a solution, which worked for me:

Dear bob,

the /etc/prosody/prosody.cfg.lua provided by the current pprosody package already contains the line

Include “conf.d/*.cfg.lua”

at the end. Therefore, this line does not solve the problem.

In my case I’ve edited file /etc/jitsi/videobridge/config
JVB_HOST was empty, I’ve filled it with my FQDN
and JVB_OPTS should be JVB_OPTS="–apis=xmpp,rest"

Thx a lot for this advice. But I’m really sorry, this did not solve the problem for our system. The crash issue is absolutely the same as soon authentication is enabled in /etc/jitsi/jicofo/sip-communicator.properties :frowning:

Do you have fw for outgoing traffic, open outgoing udp 443.

I am having this issue too, but only intermittently - could it be that it has to do with ipv6? Maybe when only some clients are running over ipv6? I don’t always have this issue it seems.

Personally I run a root server with Ubuntu Linux 16.04 and jitsi-meet running in a docker container using the official docker-compose example. My root server has IPv6 and IPv4 but it seems jitsi is configured for IPv4 only by default.

I tried enabling ipv6 in the jitsi-web config.js file but still have this issue every now and then. I also noticed that when setting a fixed ip in the .env file of the docker setup that I can only specify a IPv4?

Edit: Some more info: I am running this instance behind a nginx proxy, ssl is disabled through the docker container env file, nginx is serving the https connection to the world.

Hi damencho,

it’s correct that the FW blocks outgoing traffic. IMHO, this traffic is not required. In particular, p2p is disabled:

p2p: {
    enabled: false,
    stunServers: [
        { urls: 'stun:meet-jit-si-turnrelay.jitsi.net:443' }
    ],
    preferH264: true
},

Nevertheless, this error message cannot be the reason for room crashing when authentication is enabled. On our previous system, the FW is closed, too, and authentication is working without room crashing. The used versions on this (test) system are

jitsi-meet 1.0.4101-1
jitsi-meet-prosody 1.0.3729-1
jitsi-meet-web 1.0.3729-1
jitsi-meet-web-config 1.0.3729-1
jitsi-videobridge 1124-1
prosody 0.11.2-1
prosody-modules 0.0~hg20190203.b54e98d5c4a1+dfsg-1+deb10u1

Please, do not ask, how my colleagues have installed these conflicting versions, but is works. But this should not be the base for our productive system.

I am perhaps being stupid, but if the firewall is blocking outgoing traffic, how is traffic getting from your server to clients?

This is trivial firewall handling. The firewall allows connections from all clients to the server (tcp/443, tcp/4443, udp/10000). This initializes a session and the firewall allows all (back) traffic for existing sessions.
The server will never initialize a session to the client. Therefore, a firewall rule server => client is not necessary (and fatal).

Which is slightly different to “the FW blocks outgoing traffic” :slight_smile: but it looks like the problem isn’t there… tricky!

Hi. I followed the quick guide over the weekend and I regret having done so.

It’s broken, quite possibly in more places than one, so I ended up having to dive into the depths and figure out all the components of jitsi meet.

What I discovered in the end was the the quick installer did not add this line:

Component “jitsi-videobridge.your.site.org
component_secret = “your_secret”

to the prosody config in /etc/prosody/conf.d/your.site.cfg.lua

That makes it crash whenever the 2nd person joins.

I hope that might save you some pain.

2 Likes

Thanks @kitsis

Just to clarify, how do we find the component_secret? And also, is this the correct format for the Component entry:

Component “jitsi-videobridge.example.com

1 Like

Is the component secret stored in /etc/jitsi/videobridge/config ?

1 Like

So far so good, your fix seems to be working, thanks again.

2 Likes