Not Behind NAT, Followed Tutorial and Can't See Each Other

Hello,
this time, I’m desperate and I’m on the verge of dropping Jitsi and stay with Skype, in the hands of Bill Gates. I’m willing to get away of monopolies, and I’m willing to work harder to configure the bits and the bobs. I spent way too much time trying to isolate the issue on why no one can’t see each other on a videoconference involving two persons only. Two people only. Not hundreds. Yet, it’s a total failure. It’s a nightmare to fix Jitsi. Easy to setup, but a nightmare to debug when things don’t work. Server is not behind a NAT, I have authorized port 443/tcp, 4443/tcp, 10000/udp, 80/tcp, I have followed the official Jitsi tutorial, I tried stable/unstable versions. What could I possibly do to fix this once and for all. Not seeing each other is a damn recurring theme. Why do I have to spend nights and days trying to figure out what’s not working when I have followed the tutorial. I spent lots of time on forums, but apparently, my issue is so unique that no else encountered my problem? I’m exhausted.

So, the server is Ubuntu Bionic with Jitsi unstable, NIGNX, Let’s Encrypt, etc. Client 1 is a regular Mac user at home with no restriction, Client 2 is a regular PC user at work, thus using a PC laptop of the company.

Thanks for your help.

Do you use a domain name or an IP?

Sorry that I can’t provide a solution, but I experience the same problem.

current setup: Debian 10 on Strato V-Server with fixed IPV4 and IPV6 adresses, A record and AAAA record set up and working, FQDN set correctly
Nginx is installed and working correctly (I host Matrix and Riot on the same V-Server), installed jitsi via the debian packages but set jitsi-meet-turnserver on hold and instead entered three public STUN servers in /etc/jitsi/meet/$FqdnJitsiServer-config.js

I can connect to my Jitsi instance and start a conference, but I cannot connect to the server by the Android app and if I try to join the conference from another PC, I can’t see the first one.
I also failed to get the secure domain setup working.

This is my fifth try to get Jitsi running, the first three attempts were on Ubuntu 18.04 LTS, each on an fresh server installation, the last two on Debian 10. - All attempts brought the same unsatisfactory result: Two users use the same room name, but none can see the other.

I use a domain name.

jvb.log

2020-07-07 16:45:58.576 INFO: [26] Videobridge.createConference#256: create_conf, id=b4eb195fb780e7e8 gid=-1 logging=false
2020-07-07 16:45:58.600 SEVERE: [26] RecurringRunnableExecutor.run#230: The invocation of the method org.jitsi.videobridge.health.Health.run() threw an exception.
java.lang.NoClassDefFoundError: Could not initialize class org.jitsi.videobridge.sctp.SctpManager

jicofo.log

Jicofo 2020-07-07 18:14:42.288 SEVERE: [294] org.jitsi.jicofo.AbstractChannelAllocator.log() jvbbrewery@internal.auth.vc.my_domain.com/6c3cab5d-3320-470d-9ee6-a37135b70409 - failed to allocate channels, will consider the bridge faulty: Timed out waiting for a response.
org.jitsi.protocol.xmpp.colibri.exception.TimeoutException: Timed out waiting for a response.

If you don’t have a trusted TLS certificate, this can cause the issues which you are talking about

Are these clients able to communicate via https://meet.jit.si
Is your server in a private network?

Yes. Clients only use Chrome, Opera or Vivaldi. We dot not use Firefox.

No. I confirm with 100% certainty that VPS has a public IPv4 and the provider does not utilize NAT by default.

Positive, I do have valid LetsEncrypt cerificates for the FQDN, Chromium, Google Chrome, Opera and Firefox do accept them without any complaints.

In my various attempts I used the method provided by the script /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh as well as acquiring the LetsEncrypt certificates before installing Jitsi. Both ways worked concerning the certificates but in neither case I could connect to my server via the Android app.

You may take a look yourself at connect. dieges. net - I just checked with the digicert ssl checker and the results are
DNS resolves connect. dieges. net to 85.215.81.38

HTTP Server Header: nginx/1.14.2

TLS Certificate

Common Name = connect. dieges. net

Subject Alternative Names = connect. dieges. net, matrix. connect. dieges. net, riot. connect. dieges. net
Issuer = Let’s Encrypt Authority X3
Serial Number = 45230113A4DF7B837F722E0296EAD71E8CE

SHA1 Thumbprint = 6A79CE47D4318AA8EA811A166821F94D0DE7A4B7
Key Length = 2048
Signature algorithm = SHA256-RSA

Secure Renegotiation:
TLS Certificate has not been revoked

OCSP Staple: Not Enabled
OCSP Origin: Good
CRL Status: Not Enabled

TLS Certificate expiration

The certificate expires September 26, 2020 (80 days from today)

Certificate Name matches connect . dieges . net

Subject connect . dieges . net
Valid from 28/Jun/2020 to 26/Sep/2020
Issuer Let’s Encrypt Authority X3

Subject Let’s Encrypt Authority X3
Valid from 17/Mar/2016 to 17/Mar/2021
Issuer DST Root CA X3

TLS Certificate is correctly installed

Congratulations! This certificate is correctly installed.

Heartbleed Vulnerability

Server is not vulnerable to the Heartbleed Bug because heartbeats are not enabled on this server.

Protocol Support

TLSv1.2
TLSv1.3

TLS ciphers supported by the server

TLSv1.2

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLSv1.3

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

No known vulnerable Debian keys were found