Room crashed when somebody joined

That is correct.

It is ok, it defaults to localhost.

I suffer from about the same phenomenon, but within a different setup source: docker-jitsi-meet. I get video and audio from a second participiant for 1-3 seconds, and then it crashes 100% reproducible.

That setup defines JVB_ENABLE_APIS as none. Given this discussion, it ought to be something else, and env.example carries:

#JVB_ENABLE_APIS=rest,colibri

but no combination of xmpp, rest, colibri does change the behavior. :frowning_face:

The logs are full of:

1993:jvb_1      | JVB 2020-03-25 16:40:37.191 SEVERE: [30] org.jitsi.videobridge.health.Health.log() Health check failed in 0ms:
2003:jvb_1      | JVB 2020-03-25 16:40:41.954 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2247:jvb_1      | JVB 2020-03-25 16:40:46.955 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2275:jvb_1      | JVB 2020-03-25 16:40:47.192 SEVERE: [30] org.jitsi.videobridge.health.Health.log() Health check failed in 1ms:
2347:jvb_1      | JVB 2020-03-25 16:40:51.956 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2372:jvb_1      | JVB 2020-03-25 16:40:56.957 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2396:jvb_1      | JVB 2020-03-25 16:40:57.192 SEVERE: [30] org.jitsi.videobridge.health.Health.log() Health check failed in 0ms:
2406:jvb_1      | JVB 2020-03-25 16:41:01.958 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275
2455:jvb_1      | JVB 2020-03-25 16:41:06.959 SEVERE: [36] org.jitsi.meet.ComponentMain.call().299 java.net.ConnectException: Connection refused (Connection refused), host:localhost, port:5275

but I haven’t even found a sign, what service the ominous port 5275 should be.

The docker layout is this:

          Name              Command   State                        Ports                      
----------------------------------------------------------------------------------------------
dockerjitsimeet_jicofo_1    /init     Up                                                      
dockerjitsimeet_jvb_1       /init     Up      0.0.0.0:10000->10000/udp, 0.0.0.0:4443->4443/tcp
dockerjitsimeet_prosody_1   /init     Up      5222/tcp, 5269/tcp, 5280/tcp, 5347/tcp          
dockerjitsimeet_web_1       /init     Up      0.0.0.0:8443->443/tcp, 0.0.0.0:8008->80/tcp     

The http/https posts are a little strange, but this is behind a nginx reverse proxy, that handles ssl already. Full log is available here. The log shows ICE/STUN issues as well, but I’ve not touched those values.

Full config:

CONFIG=~/.jitsi-meet-cfg
HTTP_PORT=8008
HTTPS_PORT=8443
TZ=Europe/Berlin
PUBLIC_URL=https://meet.example.org
DOCKER_HOST_ADDRESS=172.16.23.10
XMPP_DOMAIN=meet.jitsi
XMPP_SERVER=xmpp.meet.jitsi
XMPP_BOSH_URL_BASE=http://xmpp.meet.jitsi:5280
XMPP_AUTH_DOMAIN=auth.meet.jitsi
XMPP_MUC_DOMAIN=muc.meet.jitsi
XMPP_INTERNAL_MUC_DOMAIN=internal-muc.meet.jitsi
XMPP_GUEST_DOMAIN=guest.meet.jitsi
XMPP_MODULES=
XMPP_MUC_MODULES=
XMPP_INTERNAL_MUC_MODULES=
JVB_BREWERY_MUC=jvbbrewery
JVB_AUTH_USER=jvb
JVB_AUTH_PASSWORD=passw0rd
JVB_STUN_SERVERS=stun.l.google.com:19302,stun1.l.google.com:19302,stun2.l.google.com:19302
JVB_PORT=10000
JVB_TCP_HARVESTER_DISABLED=true
JVB_TCP_PORT=4443
JVB_ENABLE_APIS=xmpp,rest
JICOFO_COMPONENT_SECRET=s3cr37
JICOFO_AUTH_USER=focus
JICOFO_AUTH_PASSWORD=passw0rd
JIGASI_XMPP_USER=jigasi
JIGASI_XMPP_PASSWORD=passw0rd
JIGASI_BREWERY_MUC=jigasibrewery
JIGASI_PORT_MIN=20000
JIGASI_PORT_MAX=20050
XMPP_RECORDER_DOMAIN=recorder.meet.jitsi
JIBRI_RECORDER_USER=recorder
JIBRI_RECORDER_PASSWORD=passw0rd
JIBRI_RECORDING_DIR=/config/recordings
JIBRI_FINALIZE_RECORDING_SCRIPT_PATH=/config/finalize.sh
JIBRI_XMPP_USER=jibri
JIBRI_XMPP_PASSWORD=passw0rd
JIBRI_BREWERY_MUC=jibribrewery
JIBRI_PENDING_TIMEOUT=90
JIBRI_STRIP_DOMAIN_JID=muc
JIBRI_LOGS_DIR=/config/logs
DISABLE_HTTPS=1

Any insights are much appreciated.

Filed an issue now.

This issue is fixed now.

The magic trick that solved the issue was commenting out JVB_STUN_SERVERS for us.

1 Like

Just replying to the main topic.
I was struggling with this issue too.
Following the quick install on a debian buster VM.
The weird thing is, when I boot up the VM I the second person cannot join, with the message in jicofo.log:
SEVERE: [29] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Can not invite participant -- no bridge available.

When I restart the jicofo service others can join and also rejoin.
Rebooting the vm to reproduce, and joining is not working again.
Could this be a timing issue in the way the services start?

But how will Jitsi know the public IP?

@ashledombos

But how will Jitsi know the public IP?

Yes, that’s the culprit here. We outwit jitsi by setting DOCKER_HOST_ADDRESS to the public IP for the time being…

Just did a fresh install with the current stable repo, the issue appears to be gone.
jitsi-meet 1.0.4335-1
jitsi-videobridge2

This soled my issue.

Thanks

I use exactly the default setting at https://github.com/jitsi/docker-jitsi-meet, and always crashed if second participant joined.
Then I try restart jicofo, it works.
So why this happened? What can I do if I don’t restart jicofo every time I restart my server.

Try disable TURN

Why you reboot your server? Servers are not made to be rebooted often :confused:

Yes!
It works.Thank you.
I just remarked
JVB_STUN_SERVERS=meet-jit-si-turnrelay.jitsi.net:443
I noticed that when I remarked this out, I can’t use two kinds of browser to use the same camera on the same machine. (Although I think this is meaningless, just for test)
By the way, I don’t want to give another command to make jitsi-meet work appropriatitly.

you’re welcome

Same here on a fresh Debian, adding xmpp,rest fixed it for me.