Not able to access Jitsi server hosted on CentOS


We did a Jitsi Meet installation on our CentOS 7 server as per the steps outlined in below link -

When we do docker -ps, we see Jitsi-Meet process running.

However, when we try to access it from outside we get “page cannot be reached” error. Even if we do a curl from inside CentOS, we get error "curl: (35) Encountered end of file "

We use CSF for firewall and have enabled all ports stated in the tutorial. Please let us know if you have faced a similar issue and what we might be doing wrong.

We don’t recommend using a git checkout but getting an actual release: Self-Hosting Guide - Docker | Jitsi Meet

Thanks. We did that and could finally install it but now facing constant disconnection while starting a meeting. SImilar to what was reported in this Stackoverflow question -

The entry for PUBLIC_URL is set to Domain name and that for DOCKER_HOST_ADDRESS is set to private IP, yet the error persists. Please let me know what is wrong.

Found this entry as the fix in some other discussion, added it to .env file and it worked.


That likely means something else is wrong though. Did PUBLIC_URL look like a real URL ( and DOCKER_HOST_ADDRESS like a real public IP?

Do you have a valid TLS certificate?

We have been able to narrow down the behaviour after more iterations. It looks to be a Configuration issue where Screenshare works for 2 participants in P2P mode and gets closed when 3rd one joins. When 3rd participant drops off, participant 2 can again see the screen shared by participant 1.

This is the latest, reproducible behaviour -


Participant 1: On Chrome, Participant 2: On Edge, Participant 3: On Chrome mobile

Test condition

  1. Participants 1 and 2 join. Participant 1 shares screen and Participant 2 is able to review
  2. Participant 3 joins. Screenshare of Participant 2 breaks, shows just a black box
  3. Participant 3 disconnects. Within a few seconds, Participant 2 is AGAIN able to see the screenshare.

Found some entries in browser console log -

When Participant 3 joined, this was the log entry in Participant 2 (who lost Screenshare from participant1)

Logger.js:154 2022-09-06T04:18:22.313Z [modules/xmpp/ChatRoom.js] <Sr.onPresence>: entered {isReplaceParticipant: 0, affiliation: ‘none’, role: ‘participant’, jid: ‘1xme6mfg3654uwx6awxxzdtu@meet.jitsi/cz_4NFayu6ig’, isFocus: false, …}
index.js:154 2022-09-06T04:18:22.384Z [conference.js] <r.>: USER 25379860 connected: kn {_jid: ‘’, _id: ‘25379860’, _conference: Mh, _displayName: ‘KrishnanMobile’, _supportsDTMF: false, …}
Logger.js:154 2022-09-06T04:18:22.387Z [JitsiConference.js] <Mh._maybeStartOrStopP2P>: Will stop P2P with:
Logger.js:154 2022-09-06T04:18:22.388Z [JitsiConference.js] <Mh._resumeMediaTransferForJvbConnection>: Resuming media transfer over the JVB connection…
Logger.js:154 2022-09-06T04:18:22.390Z [modules/xmpp/JingleSessionPC.js] <jo.setMediaTransferActive>: JingleSessionPC[session=JVB,initiator=false,sid=47f32opn7p9sp] Queued make video active, audio active task
Logger.js:154 2022-09-06T04:18:22.390Z [JitsiConference.js] <Mh._stopP2PSession>: Stopping remote stats for P2P connection
Logger.js:154 2022-09-06T04:18:22.391Z [JitsiConference.js] <Mh._stopP2PSession>: Stopping CallStats for P2P connection
Logger.js:154 2022-09-06T04:18:22.392Z [modules/xmpp/JingleSessionPC.js] <jo.terminate>: JingleSessionPC[session=P2P,initiator=false,sid=9f9e22c28fc1] Sending session-terminate
Logger.js:154 2022-09-06T04:18:22.394Z [modules/xmpp/JingleSessionPC.js] <jo.onTerminated>: JingleSessionPC[session=P2P,initiator=false,sid=9f9e22c28fc1] Session terminated undefined undefined
Logger.js:154 2022-09-06T04:18:22.396Z [JitsiConference.js] <Mh._setP2PStatus>: Peer to peer connection closed!
Logger.js:154 2022-09-06T04:18:22.527Z [modules/RTC/TPCUtils.js] <Od.setMediaTransferActive>: TPC[id=1,type=JVB] Enabling audio media transfer.
Logger.js:154 2022-09-06T04:18:22.528Z [modules/RTC/TPCUtils.js] <Od.setMediaTransferActive>: TPC[id=1,type=JVB] Enabling video media transfer.
Logger.js:154 2022-09-06T04:18:22.530Z [modules/RTC/TraceablePeerConnection.js] <Ld.close>: TPC[id=2,type=P2P] Closing peerconnection
Logger.js:154 2022-09-06T04:18:22.560Z [JitsiConference.js] Resumed media transfer over the JVB connection!
Logger.js:154 2022-09-06T04:18:22.598Z [modules/xmpp/JingleSessionPC.js] <peerconnection.onnegotiationneeded>: JingleSessionPC[session=JVB,initiator=false,sid=47f32opn7p9sp] onnegotiationneeded fired on TPC[id=1,type=JVB]
Logger.js:154 2022-09-06T04:18:22.617Z [modules/RTC/TraceablePeerConnection.js] <Ld._remoteTrackAdded>: TPC[id=1,type=JVB] ignored remote ‘stream added’ event for non-user stream[id=mixedmslabel]
Logger.js:154 2022-09-06T04:18:22.618Z [modules/RTC/TraceablePeerConnection.js] <Ld._remoteTrackAdded>: TPC[id=1,type=JVB] ignored remote ‘stream added’ event for non-user stream[id=mixedmslabel]
Logger.js:154 2022-09-06T04:18:23.511Z [modules/xmpp/strophe.jingle.js] <Bo.onJingle>: invalid session id: 9f9e22c28fc1

ENTRY IN .env file


Without above entry, Jitsi meet is constantly disconnecting and trying to reconnect
TLS certificate was taken from Lets Encrypt, it is valid till 4th Dec.

Please let me know what other configuration settings do you want me to check and share, I will do that.

We have finally been able to make Jitsi Meet work - do multi-cast Screen share and Video with multiple participants. Thank all of you very much for regularly providing your inputs !

This is the summary -

OS: CentOS 7
Jitsi version: Docker Jitsi unstable-2022-08-30 of all 10 repositories

Problems faced and solution for each

Problem 1
Jitsi Meet was continuously disconnecting and trying to reconnect
Add this line to .env file

Problem 2
Screen share works between two participants using Chrome or Edge but fails when 3rd participant joins
a) Set up a valid TLS certificate
b) If Jitsi meet is being hosted on a port other than default, append that port number also to url in PUBLIC_URL value in .env file
c) Simultcast is set to true by default I believe but you could set the flag explicitly in docker-compose.yml

With above configuration changes, we could get multiple screen share and video to work. Thanks again to all of you for regular suggestions and helping us to resolve this.


This shouldn’t be needed. Do you have a proxy in front of the Docker setup? Does it proxy WS correctly?

That can’t be it, since it already defaults to true.

We have just landed a fix for that screen-share issue. It will be part of the next stable release, or you can switch to the unstable / nightly images if you want it now :slight_smile:

No, we don’t have a proxy in front of Docker setup. Not sure why connection was failing without that line in .env file

“That can’t be it, since it already defaults to true”
Yes you are right, that is why I mentioned that the default is true but we anyway set the flag explicitly.

Please let us know which version are you referring to with fix for screenshare, we will try that. Let us also know what configuration to set/not set from the points I listed above.

You can switch the images to “unstable”. There is a config for it in the sample .env file. You’d then need to pull the images again, and re-create the containers.

Config wise, as I said something is breaking those WS connections, but I don’t really know what :-/

What does this mean? Did you build the images yourself? Have you tried the latest stable images?