Giving up on NextCloud Talk. No matter what, I can not get a call connected. Been trying for two days now, noping out HARD now.

What's a self-hosted solution for multi-person (video-)calls? XMPP can do 1-on-1 but not multiple.

@homelab

@blindcoder @homelab

Do you have access to a STUN/TURN server off of your home network? It's pretty needed to help negotiate connectivity between NAT devices.

The two other main FOSS alternatives are Jitsi or Bigbluebutton.

Both of which are harder to install then Nextcloud Talk

@alienghic @homelab I have a coturn server that works fine with Conversations. Configured it in Talk as well, but no dice.
@blindcoder tried it myself with Nextcloud call. Without High Performance backend it is useless for calls with more than two members. @alienghic @homelab
@bjoern @alienghic @homelab Did have the HPB, 2.0.2-docker, configuration in Admin -> Talk was fine. Still could not connect two Android phones, or an Android and a Desktop browser.
@blindcoder @bjoern @alienghic @homelab for me it works. I just deployed the HPB and configured it (2.0.3~docker) in admin->talk. I used the prefilled STUN(stun.nextcloud.com:443) and also added the HPB as TURN server. Are you sure, that the firewall is configured correctly and all ports are open on the server (on the firewall, on the OS and also in the docker definition)? And do you have TURN correctly set up in admin->talk?
@blindcoder @bjoern @alienghic @homelab wait, another thought, as you mentioned Android devices: Do you have End-to-End-Encryption enabled? Because the mobile apps won't work with that IIRC.
@elvith @homelab E2E disabled, stun.nextcloud.com:443 as stun server, my own coturn as turn server. The coturn works for Conversations and turnserver_uclient also succeeded.
@elvith @homelab Adding a few screenshot.
@elvith @homelab OKay, some more testing. I REMOVED the HPB and calls instantly connected.
Now, how do I debug the HPB?

@elvith @homelab So if anyone has a great idea, here's a topic I made with all the logs and setup details. I have zero clues why the clients keep disconnecting and reconnecting but never actually connecting to the call when the signalling server is configured.
https://help.nextcloud.com/t/talk-calls-do-not-connect-with-signalling-server-configured/240830/2

#NextCloud #Talk

Talk calls do not connect with signalling server configured

Some more information as that might help diagnosing: Nextcloud is installed in an apache webserver running mod_php, in a LXC on proxmox with a public IPv4 address. That server hosts many applications, like other websites, mailserver, jabber server, also coturn for TURN. Next to that LXC is another LXC which hosts docker containers maintained through portainer. In that second LXC I run nextcloud/aio-talk which the nextcloud instance from the first LXC connects to. The docker container is front...

Nextcloud community
@blindcoder @elvith @homelab what I have understood by trying to configure a Jitsi server, is the mobile phone companies block or time out port 3478 and 5479. It leads to clients disconnections. The solution is to use signaling server on port 443.
In case it could help you.
@squidf @homelab Good question. It does work without the signalling server, immediately. I'll try and see if I can get a spare v4 address for 443 somewhere.
@blindcoder @elvith @homelab
Das sieht sehr nach einem Problem mit Janus aus. Signaling Server und coturn melden "OK" an NC (Admin UI), aber Calls kommen nicht zustande. Da würde ich mal drauf tippen, dass Janus beim Start des Dienstes abschmiert, weil der coturn (aus welchen Gründen auch immer) nicht erreichbar ist. Janus als WebRTC-Server kommt erst bei Verbindungsaufbau zum Tragen, daher die Vermutung.

@DecaTec @homelab Von innerhalb des Containers ist coturn erreichbar:
3923f8ac8998:/$ nc -vz cloud.anderdonau.de 3478
Connection to cloud.anderdonau.de (46.4.73.92) 3478 port [tcp/*] succeeded!

Wonach muesste ich bei janus Ausschau halten?

@blindcoder @homelab Einfach mal prüfen, ob der Dienst läuft. Wenn ja, dann als nächstes mal die Logs checken.
@DecaTec @homelab Der Dienst laeuft, die logs vom HPB Container hab ich im Ticket angehangen. Wonach sollte ich da Ausschau halten?
https://forge.anderdonau.de/blindcoder/nextcloud-logs/src/branch/main/nextcloud-aio-talk_logs.txt
nextcloud-logs/nextcloud-aio-talk_logs.txt at main

nextcloud-logs

Forgejo: Beyond coding. We Forge.
@blindcoder @homelab Das sind leider nur die Logs von NC und vom Webserver. Interessanter wären hier die Logs von Janus und ggf. vom Signaling Server.

@DecaTec @homelab Doch, das sind die von Janus, steht sogar in der ersten Zeile.

Ich bin aber nen Schritt weiter. Habe jetzt den AIO-Talk container von nem LXC raus und direkt auf den Proxmox Host gepackt. Damit kann ich jetzt den TURN Server vom Container exposen. DAMIT funktioniert der Call.

Finde ich jetzt nicht super-prickelnd, weil ich jetzt entweder zwei TURN Server habe oder Prosody mit dem AIO-Talk TURN Server verbinden muss, aber hey. Es funktioniert.

@blindcoder @homelab Stimmt, da habe ich falsch geguckt (habe im Forum Post nachgesehen).
Janus lief, aber die Meldung "...but you didn't specify any STUN server..." hat den Fehler eigentlich gut beschrieben.
Toll, dass es nun funktioniert. Ist vielleicht auch die bessere Variante, denn Docker in LXC ist meistens keine gute Idee und führt oftmals zu komischen Nebeneffekten.

@DecaTec @homelab Okay, ich sollte die Logs vielleicht auch selber vernuenftig lesen...
Zumindest das erscheint mir unlogisch, denn im NextCloud -> Admin -> Talk habe ich den STUN Server ja angegeben. Anscheinend muss ich den auch im HPB irgendwo konfigurieren...

Bin noch relativ neu in Docker, bislang hat mit dem Setup alles funktioniert. Aber ja, ich schau mal, ob es sinnvoll ist, von Docker im LXC zu Docker auf Blech umzuziehen.

@blindcoder @homelab Aus der NC Admin-UI konfigurierst du STUN/TURN "für extern". Intern (Signaling -> Janus) wird das aber ebenso benötigt. Wird normalerweise in der Janus-Config hinterlegt und der Signaling Server greift dann über Janus/API darauf zu.

Umstieg "auf Blech" ist hier aber gar nicht notwendig. Statt eines LXCs einfach eine richtige VM nutzen, da gibt es solche Probleme nicht.