Connection issue from outside the network after a few seconds

I’m not sure if this particular problem has been addressed before or not but I couldn’t find a solution for it.

I installed Jitsi Meet via apt packages on Ubuntu Ubuntu Server 18.04.3 LTS using the quick install guide.
We tested the video stream with two, three, and four participants, all withing the same LAN. There are no big issues.
Whenever someone connects from the outside though they can see the video for a few seconds and then lose connection.
Sometimes they can see the webcam video but it’s grey, sometimes it’s grey and frozen, sometimes the video is in colour but frozen, sometimes one video of a participant works for a prolonged time while others don’t even show up in the first place.
Using the iOS App and connecting through mobile internet the participant could see the thumbnails of his own video and of one participant with a webcam. The thumbnails for two desktop shares showed the default avatar. When tapping on them, one showed the actual video stream while the other didn’t.
There is no real pattern here.

The Jitsi instance can be found here: https://meeting.interaktiv.de/test

Configurations:
(As I am a new user I had to modify the “links” as I’m only allowed to post two)

ifconfig output

enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.188.85 netmask 255.255.255.0 broadcast 192.168.188.255
inet6 fe80::b62e:99ff:fe4f:80d4 prefixlen 64 scopeid 0x20
inet6 2001:4dd0:388b:0:b62e:99ff:fe4f:80d4 prefixlen 64 scopeid 0x0
ether b4:2e:99:4f:80:d4 txqueuelen 1000 (Ethernet)
RX packets 18557797 bytes 13099690015 (13.0 GB)
RX errors 0 dropped 2274558 overruns 0 frame 0
TX packets 17240480 bytes 7595321783 (7.5 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 11404713 bytes 25558374515 (25.5 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11404713 bytes 25558374515 (25.5 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

/etc/jitsi/videobridge/sip-communicator.properties

org.jitsi.videobridge.AUTHORIZED_SOURCE_REGEXP=focus@auth.meeting.interaktiv(dot)de/.*
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=192.168.188.85
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=87.79.74.52
org.jitsi.videobridge.DISABLE_AWS_HARVESTER=true
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443
org.jitsi.videobridge.TCP_HARVESTER_MAPPED_PORT=4443
org.ice4j.ipv6.DISABLED

/etc/jitsi/jicofo/config

JICOFO_HOST=localhost
JICOFO_HOSTNAME=meeting.interaktiv(dot)de
JICOFO_SECRET=[redacted]
JICOFO_PORT=5347
JICOFO_AUTH_DOMAIN=auth.meeting.interaktiv(dot)de
JICOFO_AUTH_USER=focus
JICOFO_AUTH_PASSWORD=[redacted]
JICOFO_OPTS=""
JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=jicofo -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/jicofo/logging.properties"

/etc/jitsi/videobridge/config

JVB_HOSTNAME=meeting.interaktiv(dot)de
JVB_HOST=
JVB_PORT=5347
JVB_SECRET=[redacted]
JVB_OPTS=""
JAVA_SYS_PROPS="-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/videobridge/logging.properties"

p2p in /etc/jitsi/meet/meeting.interaktiv.de-config.js has ‘enabled: false,’

Forwarded Ports:
jitsi-ports

The description given seems to me like bandwidth problems to the server.
What browser are you testing with and what is the bandwidth upload and download available to your videobridge?
Also, I tested and I was directly connected to tcp, have you opened and forwarded udp 10000? Using tcp is not recommended and should always be a fallback as it decreases quality a lot.

Thanks for the reply.

Forwarded are pots 4443/tcp and 10000/udp. Do I need to forward 4443/udp aswell/instead?
I tested using Firefox 70.0 and Chrome 78.0.3904.87.

This is the output of the connection info tab in Chrome when sharing an empty Sublime Text window:
jitsi-bandwidth
Both participants of the meeting (Chrome and Firefox on the same machine) were in the same LAN.

Maybe you have to unblock 10000 udp on some firewall or your forwarding is not working … seems that your local client also use TCP which is not so good.

You were right. It seems that I forgot to open port 10000/udp on the Jisti machine and only 4443/tcp was allowed.
I will do some further test in the coming days with participants from outside our LAN and report back if I have further issues.

Thanks for your help!