ich versuche Talk mit einem eigenen TURN Server aufzusetzen. Dabei funktionieren von verschiedenen Browsern die Verbindungen nicht.
Deutsche Glasfaser, CGNAT
Fritzbox mit Freigabe für 443 und nur IPv6
in meinem Heimnetz hoste ich die Nextcloud, AIO v10.15.0
ich habe einen VPS server mit IPv4 und IPv6, dort läuft nginx als Reverse Proxy, der meine Nextcloud im Internet verfügbar macht. SSL per LetsEncrypt Zertifikat.
bis hierhin funktioniert alles einwandfrei.
auf dem VPS läuft außerdem eturnal (ich hatte auch coturn probiert, mit dem selben Ergebnis). TCP und UDP auf 3478, TLS (mit meinem LetsEncrypt Zertifikat) auf 5349.
In Nextcloud Talk auch konfiguriert und dort von dem Check als gut befunden.
auch Trickle ICE meldet Erfolg, all Tests enden mit ‘Done’.
Jetzt versuche ich mit mehreren PCs einen Talk Anruf mit Bild und Ton herzustellen, und das klappt zwar zwischen einem Linux Rechner und einem Windows Rechner, beide mit Firefox, beide in meinem Heimnetz. Vermutlich, weil diese kein Verbindung über den TURN Server herstellen brauchen.
Sobald ich aber einen anderen Browser nutze (Chrome/ Edge), den Firefox zu einer Relay Verbindung zwinge (OCA.Talk.SimpleWebRTC.webrtc.config.peerConnectionConfig.iceTransportPolicy = 'relay'), oder ein Gerät aus einem anderen Netz nutze (Handy im Gastnetz), kann ich zwar den Anruf verbinden, und Chat Nachrichten austauschen, aber keine Bild und Ton Verbindungen herstellen.
Es scheint also, als ob die ganze TURN Verbindung nicht klappt. Und ich habe keine Ahnung, wie ich hier weiteres Troubleshooting betreiben kann.
Das ist vermutlich der Fall. Rein technisch sollte es kein Problem sein turn über ipv6 zu fahren aber ich kann mir Vorstellen der Teufel ist im Detail.
In dem Topic
hatten wir recht detailliert die Prozesse und Troubleshooting rund um TURN besprochen - ich würde schauen ob die Clients gültige srlfx/relay Adressen bekommen - sobald das der Fall ist sollte es laufen.
Ich verstehe die Aussage nicht ganz:
für TURN brauchst du kein Zertifikat - das Media wird durch Talk verschlüsselt und eine TLS Verbindung bringt höhstens theoretischen Vorteil. Konzentriere dich auf udp/3478 das ist der Standard für TURN und sollte ausreichen. tcp/443 ist nett als fallback falls UDP nicht funktioniert.. das dürfte eher kein Thema sein wenn du https auch hostest - der Port ist bereits belegt
In dem Topic … hatten wir recht detailliert die Prozesse und Troubleshooting rund um TURN besprochen
darin finde ich Hinweise auf:
about:webrtc, das kann ich zwar aufrufen, aber es fällt mir schwer, da was hilfreiches zu erkennen.
turnutils_uclient - der endet in der regel mit error 420 (Unknown Attribute)
trickleICE, damit kann ich ja testen - aber das macht ja eine andere Verbindung als Nextcloud Talk, denn NC Talk arbeitet mit dem shared Secret, während trickelICE mit username & password arbeitet. daher ist mir unklar, wie man damit eine Verbindung wie in NC Talk testen kann.
ich würde schauen ob die Clients gültige srlfx/relay Adressen bekommen - sobald das der Fall ist sollte es laufen.
das kann ich vom TURN Server bekommen. siehe unten.
5349 … für TURN brauchst du kein Zertifikat
vergessen wir den Teil - das war bloß meiner Verzweiflung geschuldet, und ich wollte probieren, ob es was ändert.
ich habe jetzt mal folgendes aufgesetzt:
STUN/TURN server mit shared Secret 8008 auf turn.ipv64.de. da läuft ein eturnal Server.
mit trickleICE kann ich zwar die STUN verbindung prüfen und erhalte srflx
aber TURN nicht, mangels username/password
wenn ich aber manuell ein solches besorge (eturnal credentials) und in trickleICE eintrage, dann erhalte ich auch ein relay.
den Server kann ja mal jemand anders nutzen, um mit zu bestaetigen, dass die STUN/TURN Server Seite korrekt aufgesetzt ist.
→ ich denke, dass der TURN Server korrekt aufgesetzt ist.
dann wird dort die Prüfung ja auch als erfolgreich angezeigt.
aber trotzdem funktionieren halt aus NC Talk keine Verbindungen.
mein Firefox zeigt mit Fehler wie WebRTC: ICE failed, see about:webrtc for more details. wenn ich dann dort in die logs gucke, finde ich hunderte von Zeilen, darunter aber auch Erfolgsmeldungen TURN(relay(IP4:172.17.0.1:43488/UDP|IP4:0.0.0.0:3478/UDP)): Succesfully allocated addr IP4:130.162.213.220:56353/UDP lifetime=599.
ich bin verzweifelt - es tut halt einfach gar nicht.
mal 'ne ganz dumme frage… wie viele Zeichen hat denn dein SECRET?
TIP: create secretpasswordkey
Make sure you create a long secretpasswordkey (min. 24 chars, better 32 chars) for each service! Note down the secretpasswordkeys as you will need them for creating the Docker stack and for configuring Nextcloud talk.
issue command in host shell and repeat for each service:
openssl rand -hex 32
1. TURN_SECRET
create a long random secretpasswordkey, issue command in host shell:
openssl rand -hex 32
2. SIGNALING_SECRET
create a long random secretpasswordkey, issue command in host shell:
openssl rand -hex 32
3. INTERNAL_SECRET
create a long random secretpasswordkey, issue command in host shell:
openssl rand -hex 32
lies mal das hier als beispiel configuration… vielleicht hilt das dem problem auf die schliche zu kommen und deine verzweiflung zu lindern?
ok, jetzt ist das Passwort e8fe68cb7e610f7b19e32dc9a2 (27 chars - nur für den Fall, dass jemand anders meinen TURN Server (turn.ipv64.de) mit seiner Nextcloud testen mag, um mir zu bestätigen, dass das Problem nicht an an dem Server liegt.
bei mir ändert sich dadurch gar nichts. es tut immer noch nicht.
resolve-dnsname ipv64.de
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
ipv64.de AAAA 3600 Answer 2a01:4f8:192:1326::bad:c0de
ipv64.de A 3600 Answer 144.76.85.238
Ich habe gerade getestet.. und vermutlich hast du mir genau das Passwort entzogen
jedenfalls man kann die Verbindung über den TURN erzwingen mit about:config> media.peerconnection.ice.relay_only: true hier und mit dieser Einstellung und deinem TURN konnte ich eine Verbindung zwischen 2 Geräten in unterschiedlichen Netzwerken herstellen (habe auch im about:webrtc gesehen dass relay candidates verwendet werden) - dein TURN ist mE OK - ich würde das Passwort ändern und ab jetzt geheim halten.
ok, danke für den Test!
das war auch meine Erwartung, dass der TURN Server korrekt funktioniert.
bleibt jetzt nur noch die kleine Frage, warum es mit meiner Nextcloud zusammen trotzdem nicht funktioniert.
ich öffne mit meinem Firefox einen Anruf. dabei zeigt die Browser Console schon Fehler: WebRTC: ICE failed, see about:webrtc for more details.
wenn ich danach mit einem zweiten Client (Talk App auf dem Handy im Gastnetz) versuche zu verbinden, sehe ich in der Firefox Console, dass da was ankommt - aber es kommt keine WebRTC Verbindung zustande.
viele failed candidates sind nicht schlimm, ich sehe auch teils über 10 Stück - das ist normal weil man mit NAT vorher nicht weis welche Verbindung möglich ist und mit ICE einfach alle möglichen Verbindungen ausprobiert..
In deinen screenshots sehe ich beim TURN nur high-ports - sind denn auch candidates mit udp/3478 dabei? vermutlich sind die high-ports nicht offen (müssen sie nicht zwingend, man kann sie aber aufmachen). Mein Test OK war - d.h. die TURN Seite ist gut - kann es sein dass dein Client warum auch immer keine Verbindung zum TURN udp/3478 machen kann? ich habe leider nicht aufgepasst welcher port bei meinem Test benutzt wurde.
$ sudo nmap -sU -v turn.ipv64.de -p 3400-3500
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-06-11 14:28 CEST
Initiating Ping Scan at 14:28
Scanning turn.ipv64.de (130.162.213.220) [4 ports]
Completed Ping Scan at 14:28, 0.03s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:28
Completed Parallel DNS resolution of 1 host. at 14:28, 0.00s elapsed
Initiating UDP Scan at 14:28
Scanning turn.ipv64.de (130.162.213.220) [101 ports]
Discovered open port 3478/udp on 130.162.213.220
Increasing send delay for 130.162.213.220 from 0 to 50 due to 11 out of 12 dropped probes since last increase.
Completed UDP Scan at 14:28, 18.48s elapsed (101 total ports)
Nmap scan report for turn.ipv64.de (130.162.213.220)
Host is up (0.018s latency).
Not shown: 100 open|filtered udp ports (no-response)
PORT STATE SERVICE
3478/udp open stun
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 18.61 seconds
Raw packets sent: 220 (6.724KB) | Rcvd: 8 (616B)
die UDP Verbindung geht durch.
so, jetzt nochmal zurück zu meinem Szenario, und was besonders bei mir ist:
Deutsche Glasfaser, CGNAT
Fritzbox mit Freigabe für 443 und nur IPv6
in meinem Heimnetz hoste ich die Nextcloud, AIO v10.15.0
ich habe einen VPS server mit IPv4 und IPv6, dort läuft nginx als Reverse Proxy, der meine Nextcloud im Internet verfügbar macht. SSL per LetsEncrypt Zertifikat.
es spielen also vier Rechner hier eine Rolle.
mein Nextcloud Host im Heimnetz.
der Reverse Proxy (nginx) auf dem VPS im Internet, der meinen Nextcloud Host überhaupt erst im Internet verfügbar macht. Hier läuft außerdem auch der TURN Server.
mein Desktop auf dem der Browser läuft, im Heimnetz.
das Handy auf dem die Nextcloud App läuft, im Gastnetz.
Wenn ich mir das Diagramm in ‘How TURN works’ ansehe, dann reden die beiden Peers jeweils mit dem TURN Server.
die beiden Peers sind mein Desktop (3) und mein Handy (4). Und beide können den TURN Server erreichen.
die Verbindung des Reverse Proxy zum Nextcloud Host funktioniert auch, denn ich kann ja das NC UI von überall öffnen und darin arbeiten. und die beiden Peers können in der Talk Unterhaltung Chat Nachrichten austauschen. Websockets sind im Reverse Proxy auch konfiguriert.
Erst dann, wenn sie Video/Audio verbinden wollen und die WebRTC Verbindung ins Spiel kommt, scheitert es. Aber welche Rolle spielt der Nextcloud Host (und damit mein Reverse Proxy) beim Initiieren der WebRTC Verbindung?
