You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am having an issue with my docker jitsi deployment and am having trouble figuring out what is causing it. The issue occurred quite sometime after updating to stable-9258 in January 2024. November 2024 it was reported that users were being disconnected from the room, though we hadn't made any changes. I updated to stable-9955 since then and this is the behavior I have seen:
Users can create a room and join by themselves, no issue, however when a second user joins the room one of two things can happen :
1. (Most Common) One of the two clients has video and audio, while the other shows no video and audio for the other client - in this case after about 10 seconds both users are disconnected, the room is closed and in the jicofo container logs I see an exception:
Jicofo 2025-02-04 19:56:23.582 SEVERE: [55] [[email protected] meeting_id=12f6df13-a5a7-4f40-b885-9e82e7c8ea75] ColibriV2SessionManager.allocate#396: Failed to allocate a colibri2 endpoint for a56f6cc6: Timeout
Jicofo 2025-02-04 19:56:23.586 SEVERE: [55] [[email protected] meeting_id=12f6df13-a5a7-4f40-b885-9e82e7c8ea75 participant=a56f6cc6] ParticipantInviteRunnable.doRun#230: Failed to allocate colibri channels
org.jitsi.jicofo.bridge.colibri.ColibriAllocationFailedException: Timeout
at org.jitsi.jicofo.bridge.colibri.ColibriV2SessionManager.handleResponse(ColibriV2SessionManager.kt:435)
at org.jitsi.jicofo.bridge.colibri.ColibriV2SessionManager.allocate(ColibriV2SessionManager.kt:391)
at org.jitsi.jicofo.conference.ParticipantInviteRunnable.doRun(ParticipantInviteRunnable.java:214)
at org.jitsi.jicofo.conference.ParticipantInviteRunnable.run(ParticipantInviteRunnable.java:153)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
2. Both users have video, but no audio, they never get disconnected and there are no errors in any logs - it's almost working perfectly, but no audio.
jicofo {
authentication {
enabled = true
// The type of authentication. Supported values are XMPP or JWT.
type = JWT
login-url = "meet.jitsi"
enable-auto-login = true
authentication-lifetime = 24 hours
}
// Configuration related to jitsi-videobridge
bridge {
brewery-jid = "[email protected]"
}
// Configure the codecs and RTP extensions to be used in the offer sent to clients.
codec {
video {
}
audio {
}
rtp-extensions {
video-layers-allocation {
enabled = false
}
}
}
conference {
max-ssrcs-per-user = "20"
max-ssrc-groups-per-user = "20"
}
octo {
// Whether or not to use Octo. Note that when enabled, its use will be determined by
// $jicofo.bridge.selection-strategy. There's a corresponding flag in the JVB and these
// two MUST be in sync (otherwise bridges will crash because they won't know how to
// deal with octo channels).
enabled = false
sctp-datachannels = true
}
sctp {
enabled = true
}
xmpp {
client {
enabled = true
hostname = "xmpp.meet.jitsi"
port = "5222"
domain = "auth.meet.jitsi"
xmpp-domain = "meet.jitsi"
username = "focus"
password = "xxxxxxxxx"
conference-muc-jid = "muc.meet.jitsi"
client-proxy = "focus.meet.jitsi"
disable-certificate-verification = true
}
trusted-domains = [ ]
}
}
Here is some of the troubleshooting that I have done:
Checked jvb.log and saw this warning :
JVB 2025-02-04 22:38:06.449 WARNING: [24] [hostname=xmpp.meet.jitsi id=shard0] MucClient.setPresenceExtensions#519: Cannot set presence extension: not connected
Suggesting JVB is not connecting to Prosody - I docker exec'd into the JVB container and ran :
curl -v telnet://xmpp.meet.jitsi:5222
* Trying xxx.xx.xxx.3:5222...
* Connected to xmpp.meet.jitsi (xxx.xx.xxx.3) port 5222 (#0)
It seems it can reach prosody
Check JVB logs for errors during disconnect, none were found
Check firewall - its inactive, shouldn't be causing any issues - sudo ufw status" returned : Status:inactive
UDP port 10000 is open - having checked with iptables
I have ensured that JWT app id and JWT app token on prosody container matches corresponding values in .env
I have ensured that containers are all correctly attached to the same docker network via running - docker network ls, docker network inspect ff6a11bffc58
Checked resource consumption for jvb container : docker stats <container_id_for_jvb> - no major spikes during disconnect
All containers are running the same version 9955
Checked to see if (JVB) is communicating with the MUC (Multi-User Chat) - In the logs : from="[email protected]/focus" JVB is receiving requests
Checked to see if JVB is properly joining the MUC - prosodyctl mod_muc list | grep jvbbrewery
No output here, I tried to manually add a muc room : prosodyctl --config /config/prosody.cfg.lua addroom [email protected] and list again afterwards, but no room was being created.
Running prosodyctl --config /config/prosody.cfg.lua check revealed several issues - most prominent is : Host internal-muc.meet.jitsi does not seem to resolve to this server (IPv4/IPv6) So I added "external_addresses" the jitsi-meet.cfg.lua - No change in behavior
Noticed that the certs configured in /config/conf.d jitsi-meet.cfg.lua were expired - renewed them and restarted cluster - no fix
Configuring DOCKER_HOST_ADRESS to private ip address of machine - no fix
Added colibri configuration to jvb.conf - it was never there before when everything worked, but I added it to see - Colibri is enabled but I dont see anything in the JVB logs about Colibri when restarting jvb container
I noticed in the prosody logs the following: 2025-02-04 22:37:21 mod_http error Not listening on any ports, 'health' will be unreachable
- I added "http"; to the :enabled plugins" section and now users are disconnected instantaneously with no colibri error in the jicofo logs
I have noticed that the /etc/hosts file on the prosody container does not contain any entries for meet.jitsi, auth.meet.jitsi, muc.meet.jitsi, and internal-muc.meet.jitsi - I am working to get those added from the host machine because they get wiped with every restart of the container.
Just digging around i noticed that in my prosody.cfg.lua and my jitsi-meet.cfg.lua did not have the following settings :
I added them matching the value in my .env file which led to the same behavior after restart of the jicofo and prosody containers - that is - disconnect after about 10 seconds after the second user joins or -less frequently - no disconnect but no sound.
I added the logs that I captured during an attempt that led to a disconnect in the hopes that It may help:
I am having an issue with my docker jitsi deployment and am having trouble figuring out what is causing it. The issue occurred quite sometime after updating to stable-9258 in January 2024. November 2024 it was reported that users were being disconnected from the room, though we hadn't made any changes. I updated to stable-9955 since then and this is the behavior I have seen:
Users can create a room and join by themselves, no issue, however when a second user joins the room one of two things can happen :
1. (Most Common) One of the two clients has video and audio, while the other shows no video and audio for the other client - in this case after about 10 seconds both users are disconnected, the room is closed and in the jicofo container logs I see an exception:
2. Both users have video, but no audio, they never get disconnected and there are no errors in any logs - it's almost working perfectly, but no audio.
jvb.conf (in container):
jicofo.conf (in container):
Here is some of the troubleshooting that I have done:
Suggesting JVB is not connecting to Prosody - I docker exec'd into the JVB container and ran :
It seems it can reach prosody
Check JVB logs for errors during disconnect, none were found
Check firewall - its inactive, shouldn't be causing any issues - sudo ufw status" returned : Status:inactive
UDP port 10000 is open - having checked with iptables
I have ensured that JWT app id and JWT app token on prosody container matches corresponding values in .env
I have ensured that containers are all correctly attached to the same docker network via running - docker network ls, docker network inspect ff6a11bffc58
Checked resource consumption for jvb container : docker stats <container_id_for_jvb> - no major spikes during disconnect
All containers are running the same version 9955
Checked to see if (JVB) is communicating with the MUC (Multi-User Chat) - In the logs : from="[email protected]/focus" JVB is receiving requests
Checked to see if JVB is properly joining the MUC - prosodyctl mod_muc list | grep jvbbrewery
Noticed that the certs configured in /config/conf.d jitsi-meet.cfg.lua were expired - renewed them and restarted cluster - no fix
Configuring DOCKER_HOST_ADRESS to private ip address of machine - no fix
Added colibri configuration to jvb.conf - it was never there before when everything worked, but I added it to see - Colibri is enabled but I dont see anything in the JVB logs about Colibri when restarting jvb container
I noticed in the prosody logs the following:
2025-02-04 22:37:21 mod_http error Not listening on any ports, 'health' will be unreachable- I added "http"; to the :enabled plugins" section and now users are disconnected instantaneously with no colibri error in the jicofo logs
I have noticed that the /etc/hosts file on the prosody container does not contain any entries for meet.jitsi, auth.meet.jitsi, muc.meet.jitsi, and internal-muc.meet.jitsi - I am working to get those added from the host machine because they get wiped with every restart of the container.
and
I added them matching the value in my .env file which led to the same behavior after restart of the jicofo and prosody containers - that is - disconnect after about 10 seconds after the second user joins or -less frequently - no disconnect but no sound.
I added the logs that I captured during an attempt that led to a disconnect in the hopes that It may help:
Plesse note the last entry in the log (prosody_1) is a custom plugin that I have created.
I have tried many things to try and figure what is going on, any advice or insight would be greatly appreciated - thank you very much.
The text was updated successfully, but these errors were encountered: