Black screen for more than two people at a time


I use the following Debian packages in a Debian 9 container:

ii  jicofo                 1.0-458-1           amd64  JItsi Meet COnference FOcus
ii  jitsi-meet             1.0.3548-1          all    WebRTC JavaScript video conferences
ii  jitsi-meet-prosody     1.0.3216-1          all    Prosody configuration for Jitsi Meet
ii  jitsi-meet-web         1.0.3216-1          all    WebRTC JavaScript video conferences
ii  jitsi-meet-web-config  1.0.3216-1          all    Configuration for web serving of Jitsi Meet
ii  jitsi-videobridge      1109-1              amd64  WebRTC compatible Selective Forwarding Unit (SFU)
ii  prosody                0.9.12-2+deb9u2     amd64  Lightweight Jabber/XMPP server
ii  prosody-modules        0.0~hg20170123.3ed  all    Selection of community modules for Prosody

One-to-one video works fine, third person in conference leads to black screens everywhere.
CPU is not used much, so that is most likely not yet a bottleneck.
There are no Java exceptions nor errors in /var/log/jitsi/jicofo.log or jvb.log.
Prosody is configured to use the “secure domain” configuration.
LE certificates are used for Nginx and Jitsi, while Prosody seems to use some adhoc certificates and keys for both domains.

Any ideas? Thanks in advance!


Check out the advanced config section from the quick install guide. Normally this is problem with not forwarding ports or not configuring jvb to announce correct addresses.


I believe, that all relevant ports (80/tcp, 443/tcp, 4443/tcp, 10000/udp) are forwarded to the container. is set to the correct public IPv4 address, there is no local address, because the machine is in a data center.

Are there any other ports, that are only relevant for multi-party calls?

Also, where do the keys and certs of prosody come from? They are not the LE certs used by Nginx and Jitsi. Can this be related to the problem?


Nope, that is it.

Not at all.

Can you provide an URL so we can test or you can open chrome://webrtc-internals and open 3 tabs, then in the webrtc-internals you need to find those peer connection that is responsible for jvb connection and check in remote description whether jvb is advertising the correct address.


chrome://webrtc-internals looks powerful. Where would I find the advertized IP address?
In the browser window itself, in webrtc_internals_dump or in event_log?

Also, I see, that STUN servers with port 19302/udp are used, but I can access them from my PC.

(If I can’t find it, I’ll send you the link by PM, many thanks for offering that help!)


In the tab for jvb peer connection you should have something like this:


OK, mine is wrong: twice, which is one of the containers internal IPs. First ssltcp with port 4443 and then udp with port 10000.

Setting in /etc/jitsi/videobridge/ is not enough, it seems? Which setting did I miss?


You need to set both public and private.

And restart jvb after doing that.


Interesting! :slight_smile:

Now two ssltcp and udp addresses are there, but both are internal container addresses ( and a link local one 169.254.x.y), not the address I configured. I tried both the correct IP as both LOCAL and REMOTE, but also the correct one as REMOTE and as LOCAL. Both variants have the forementioned result.


Are you using docker container?
There stun servers are used to discover the public address, not sure why that would not work for you


I’m using very basic containers, just systemd-nspawn on a chroot. No docker, lxc/lxd, rkt…

I can reach UDP port 19302 of the STUN servers from within the container, and also from my PC.
Tested with nc -vz -u 19302.


So you are not using docker-jitsi-meet. So I don’t know, normally both should work either setting up private and public address with those variables and restarting jvb.
Or you can try adding this and restart jvb:,,


That was it. Many thanks! Three party call works!