After Installing Jitsi no Participants from different Networks are able to join a meeting

I managed to Setup a new Jitsi Server on a hosted VM (Ubuntu 18.0.4), following this Guide,
Meeting-Url is meet.dr-bit-online.de
https://www.digitalocean.com/community/tutorials/how-to-install-jitsi-meet-on-ubuntu-18-04-de
Certificates (Let’s Encrypt) seem to be fine.
Participants from same Wifi Network can connect flawlessly, but trying to Join a meeting from other Network (different Provider) makes the participant showing up with no audio or video.
For them it’s the same thing vice-versa. the only see their own audio/video information, but nothing from the moderator.

What can I do?

1 Like

jvb.log says strange things:

stream:error>This server does not serve auth.meet.dr-bit-online.de</stream:error>
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1064)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:1000)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1016)
at java.lang.Thread.run(Thread.java:748)
2020-11-02 22:23:27.729 INFO: [20] HealthChecker.run#170: Performed a successful health check in PT0S. Sticky failure: false
2020-11-02 22:23:28.268 INFO: [15] [hostname=localhost id=shard] MucClient$1.connected#271: Connected.
2020-11-02 22:23:28.268 INFO: [15] [hostname=localhost id=shard] MucClient.lambda$getConnectAndLoginCallable$7#680: Logging in.
2020-11-02 22:23:28.412 INFO: [15] [hostname=localhost id=shard] MucClient$MucWrapper.join#788: Joined MUC: jvbbrewery@internal.auth.meet.dr-bit-online.de
2020-11-02 22:23:37.727 INFO: [20] HealthChecker.run#170: Performed a successful health check in PT0S. Sticky failure: false
2020-11-02 22:23:47.727 INFO: [20] HealthChecker.run#170: Performed a successful health check in PT0S. Sticky failure: false
2020-11-02 22:23:57.727 INFO: [20] HealthChecker.run#170: Performed a successful health check in PT0S. Sticky failure: false
2020-11-02 22:24:07.727 INFO: [20] HealthChecker.run#170: Performed a successful health check in PT0S. Sticky failure: false
2020-11-02 22:24:17.727 INFO: [20] HealthChecker.run#170: Performed a successful health check in PT0S. Sticky failure: false
2020-11-02 22:24:17.796 INFO: [19] VideobridgeExpireThread.expire#140: Running expire()

You need to open port 10000/UDP.

Also, check the advanced configuration section in the guide, it that doesn’t immediately fix it for you, or if you have it open and forwarded already.

1 Like

Hey, I checked this, but it didn’t solve it.
It’s always the same. Clients from the same network can sucessfully join the meeting with working audio/video, clients from different IP-Ranges can’t.

Besides, my hosts file looks like this. Is this alright?:

127.0.0.1 localhost
87.106.170.215 meet.dr-bit-online.de

These are the latest jvb.log messages:

local_ufrag=2e15u1emcotf6m] ConnectivityCheckClient$PaceMaker.run#922: Pair failed: 87.106.170.215:10000/udp/host -> 10.46.241.154:54797/udp/host (stream-9fad07f1.RTP)
2020-11-05 17:57:54.654 INFO: [19] HealthChecker.run#170: Performed a successful health check in PT0S. Sticky failure: false
2020-11-05 17:57:54.676 INFO: [38] [confId=7339026cb4a0c0b5 epId=dcdb141a gid=330008 stats_id=Earl-u0c conf_name=test@conference.meet.dr-bit-online.de] AbstractEndpoint.expire#246: Expiring.
2020-11-05 17:57:54.677 INFO: [38] [confId=7339026cb4a0c0b5 epId=dcdb141a gid=330008 stats_id=Earl-u0c conf_name=test@conference.meet.dr-bit-online.de] Transceiver.teardown#311: Tearing down
2020-11-05 17:57:54.677 INFO: [38] [confId=7339026cb4a0c0b5 epId=dcdb141a gid=330008 stats_id=Earl-u0c conf_name=test@conference.meet.dr-bit-online.de] RtpReceiverImpl.tearDown#312: Tearing down
2020-11-05 17:57:54.677 INFO: [38] [confId=7339026cb4a0c0b5 epId=dcdb141a gid=330008 stats_id=Earl-u0c conf_name=test@conference.meet.dr-bit-online.de] RtpSenderImpl.tearDown#290: Tearing down
2020-11-05 17:57:54.678 INFO: [113] [confId=7339026cb4a0c0b5 gid=330008 conf_name=test@conference.meet.dr-bit-online.de] Conference.dominantSpeakerChanged#420: ds_change ds_id=9fad07f1
2020-11-05 17:57:54.678 INFO: [38] [confId=7339026cb4a0c0b5 epId=dcdb141a gid=330008 stats_id=Earl-u0c conf_name=test@conference.meet.dr-bit-online.de] DtlsTransport.stop#184: Stopping
2020-11-05 17:57:54.678 INFO: [38] [confId=7339026cb4a0c0b5 epId=dcdb141a local_ufrag=871db1emcot2qk gid=330008 stats_id=Earl-u0c conf_name=test@conference.meet.dr-bit-online.de] IceTransport.stop#235: Stopping
2020-11-05 17:57:54.678 INFO: [38] [confId=7339026cb4a0c0b5 gid=330008 stats_id=Earl-u0c conf_name=test@conference.meet.dr-bit-online.de ufrag=871db1emcot2qk epId=dcdb141a local_ufrag=871db1emcot2qk] Agent.setState#923: ICE state changed from Running to Terminated.
2020-11-05 17:57:54.678 INFO: [38] [confId=7339026cb4a0c0b5 epId=dcdb141a local_ufrag=871db1emcot2qk gid=330008 stats_id=Earl-u0c conf_name=test@conference.meet.dr-bit-online.de] IceTransport.iceStateChanged#321: ICE state changed old=Running new=Terminated
2020-11-05 17:57:54.678 INFO: [38] [confId=7339026cb4a0c0b5 gid=330008 stats_id=Earl-u0c componentId=1 conf_name=test@conference.meet.dr-bit-online.de ufrag=871db1emcot2qk name=stream-dcdb141a epId=dcdb141a local_ufrag=871db1emcot2qk] MergingDatagramSocket.close#142: Closing.
2020-11-05 17:57:54.678 INFO: [38] [confId=7339026cb4a0c0b5 epId=dcdb141a gid=330008 stats_id=Earl-u0c conf_name=test@conference.meet.dr-bit-online.de] Endpoint.expire#783: Expired.
2020-11-05 17:57:55.729 WARNING: [25] ColibriWebSocketServlet.createWebSocket#138: Received request for a nonexistent endpoint: dcdb141a(conference 7339026cb4a0c0b5
2020-11-05 17:57:57.731 WARNING: [24] ColibriWebSocketServlet.createWebSocket#138: Received request for a nonexistent endpoint: dcdb141a(conference 7339026cb4a0c0b5
2020-11-05 17:58:01.730 WARNING: [25] ColibriWebSocketServlet.createWebSocket#138: Received request for a nonexistent endpoint: dcdb141a(conference 7339026cb4a0c0b5
2020-11-05 17:58:03.733 WARNING: [113] [confId=7339026cb4a0c0b5 epId=9fad07f1 gid=330008 stats_id=Lexie-bag conf_name=test@conference.meet.dr-bit-online.de] EndpointMessageTransport.endpointMessage#574: Unable to find endpoint to send EndpointMessage to: dcdb141a

Any hints?
Thanks in Advance Guys
Julian

I think I have the same problem, did you solve this @dr.bit ?

I have the same problem also. I have port forward - 80, 443, 10000 - on router and dns linked to home ip address but nobody can connect through android app or web browser!!

I just installed latest jitsi-meet on a digital ocean droplet and opened the UDP port 10000, and tested with three participants video call without any issues.

root@ubuntu:~# ufw status
Status: active

To Action From


22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
3478/udp ALLOW Anywhere
10000/udp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
3478/udp (v6) ALLOW Anywhere (v6)
10000/udp (v6) ALLOW Anywhere (v6)

I have all those ports open on server and I have port forwarded on the router for 80, 443, and 10000 but nobody can join. Do you think it could be the use of ubuntu on rpi as opposed to using debian arm edition?

Why do you need to make change on the router? Where is the router located? DigitalOcean droplet can give you a public IP address for the server.

I am running it from my home so it is on a rpi connected to my router.

Can you run a TCP dump on the machine that hosts Jitsi server and see if there is any UDP packets coming to port 10000?

I checked and port 10,000 is open and udp packets are arriving, here is the pcap: http://chagai.website/jitsi.pcap

it still does not show any participants, I installed using the docker compose guide:
Self-Hosting Guide - Docker · Jitsi Meet Handbook

here you can test:

# Directory where all configuration will be stored
CONFIG=~/.jitsi-meet-cfg

# Exposed HTTP port
HTTP_PORT=8000

# Exposed HTTPS port
HTTPS_PORT=443

# System time zone
TZ=Europe/Amsterdam

# Public URL for the web service (required)
PUBLIC_URL=https://dev89.aarenet.com

# IP address of the Docker host
# See the "Running behind NAT or on a LAN environment" section in the Handbook:
# https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker#running-behind-nat-or-on-a-lan-environment
DOCKER_HOST_ADDRESS=185.150.4.89