Mit der Anleitung hat es jetzt tatsächlich geklappt, trotz der Jitsi Dokumentation alles so zum Laufen zu bringen, dass es auch von schlechte administrierten Netzwerken aus rein über TCP/443 läuft. Allerdings ist es jetzt bei mir so, dass leider gar keine direkte Kommunikation mehr mit der Videobridge via UDP/10000 stattfindet, und leider wird auch UDP/443 mit dem TURN Server nicht präferiert, auch wenn dies möglich wäre. Ist das Absicht?

Diese Antwort gehört in die Tagesschau. Ich hatte

realm='turn.domain.tld'

und immer die wrong realm Meldung bekommen, da die Hochkommata Teil des Namens waren.

Danke für deinen Kommentar!

Sorry, sehe gerade, Du nutzt nur STUN. Dafür braucht’s überhaupt keine Creds 🙂

Hallo Daniel,
habe es gefixt, scheinbar braucht das NW etwas mehr Zeit, zur Startzeit coturn scheint IPV6 noch nicht „aktiv“ zu sein, Lösung -für mich- Eintrag in /lib/systemd/system/coturn.service ==> ExecStartPre=/bin/sleep 10 unter [Service], danach ist das NW oben und es gibt keine Fehlermeldung mehr. Das erklärt auch warum es bei einem Durchstarten des Service an sich nie auftaucht.
Gruß,
Mike

Hallo Mike,
ist der Server via IPv6 nach dem Neustart per Ping gleich erreichbar? Am Besten parallel die IPv4-Adresse pingen um Unterschiede erkennen zu können.

Was für ein OS läuft auf deinem Server?
Erfolgt die Konfiguration der Netzwerkkeinstellungen via Netplans?

Gruß,
Daniel

Hallo Daniel,

danke für den Hinweis, so richtig schlau bin ich daraus nicht geworden. Wenn ich den Thread bis zum Ende durchlese wird es im Endeffekt auf die Cert-Permissions runtergebrochen?

Also die Zertifikate privkey.pem und fullchain.pem auf „root:turnserver + mode 640“???
Bei mir aktuell 400 und turnserver:turnserver … (ich habe die lets encrypt Zertifikate in einen extra Ordnung für Coturn kopiert, diese werden beim Zertifikats-Update immer mit angepasst als „hook-script“)

AmbientCapabilities=CAP_NET_BIND_SERVICE im service File wird bei mir nix bringen da mein Port > 1024 liegt …

….. war leider nicht die Lösung:

0: Trying to bind fd 88 to <[2003:f6:c70d:d400:ba27:ebff:3353:7777]:8346>: errno=99
0: Cannot bind DTLS/UDP listener socket to addr [2003:f6:c70d:d400:ba27:ebff:3353:7777]:8346
0: Trying to bind DTLS/UDP listener socket to addr [2003:f6:c70d:d400:ba27:ebff:3353:7777]:8346, again…

Hast Du einen Tipp?

Danke.

Gruß,
Mike

Hallo Mike,
das hört sich so an, als wäre die IPv6-Adresse beim Starten des Coturn Services noch nicht auf der Netzwerkkarte gebunden bzw. Up.
Schau mal in das Issue auf GitHub.

Gruß,
Daniel

Cannot bind TLS/TCP listener socket to addr [2003:f4:u655:c654:bz67:ebff:fe53:55jj]:8346
1: Trying to bind TLS/TCP listener socket to addr [2003:f4:u655:c654:bz67:ebff:fe53:55jj]:8346, again…

Wenn ich im laufenden Betrieb den Coturn-Server restarte kommt die obige Meldung nicht ….

Hat mir jemand einen Tipp?

Danke,
Mike

Hallo Sascha,
ich bin auch gerade dabei eine ähnliche Konfiguration wie du aufzubauen. Leider bin nicht so der Superfachmann. Muss ich denn auf den Servern mit der jeweiligen Videobridge irgendwelche Einstellungen für den Coturn-Einsatz vornehmen? Da hört es gerade ein wenig bei mir auf..
Vielleicht hast du ja ein gutes Tutorial oder einen Tipp für mich?

Und noch ein Hinweis zu einem Fehler, der mich zwei volle Tage gekostet hat:

Dem Turn-Server selbst ist der „Realm“ vollkommen egal, er nimmt alles. Auch einen Namen mit Trailing Whitespace!
Zumindest im Zusammenspiel mit Jitsi ist dieser Name aber nicht gültig! Es gibt dann übrigens auch einen entsprechenden Hinweis („wrong realm“) – und wenn man genau hinschaut, sieht man das Leerzeichen auch vor der schließenden spitzen Klammer „realm <example.org >“. Mir ist es leider erst sehr spät aufgefallen…

(Wenn man sich genau an diese Anleitung hier hält, ist das natürlich kein Problem – die bash ignoriert trailing whitespaces; ich hab meine Konfiguration halt bloß schon gehabt, und die verglichen…)

Nun habe ich das Problem dass sich dich Videobridges korrekt am Turn-Server melden, allerdings der Jicofo bekommt nichts davon mit.
Können Sie mir hier ein Tipp geben?

Hallo Jens,
entschuldige die späte Rückmeldung. Ich habe leider erst an Weihnachten Zeit gefunden, mir den Sachverhalt anzuschauen. Die Entwickler von Jitsi Meet haben in den letzten Monaten grundsätzliche Veränderungen vorgenommen. Daher habe ich meine Anleitungen durchgeabeitet und die notwendigen Anpassungen vorgenommen.

Daher empfehle ich dir nochmals deine Konfiguration abzugleichen bzw. neu zu installieren/konfiguieren. Sollte das Problem danach nach wie vor vorhanden sein, darfst du dich gerne nochmals melden.

Grüße,
Daniel

Hallo Joachim,
vielen dank für den Hinweis. Ich habe den Fehler im Artikel korrgiert.

Gruß,
Daniel

Hallo! Hier noch mal eine Ergänzung und Frage! Der Fehler liegt wohl darin, das via Ipv4 keine TCP / TLS Verbindung etabliert wird, da die Bindung nicht vorhanden ist. Deine Config beruht auf einer IpV4 und Ipv6. Ich nutze aber nur eine Ipv4 Adresse:

xxx@stun:~$ tail -f /var/log/coturn/coturn_2020-11-22.log0:

1. IPv6. SCTP listener opened on : ::1:4430:
2. IPv4. UDP listener opened on: 127.0.0.1:4430:
3. IPv6. TCP listener opened on : ::1:4430:
4. IPv4. UDP listener opened on: 17x.xx.1x.xxx:4430: (das ist OK)
5. IPv6. UDP listener opened on: ::1:4430:

Total General servers: 2:
IO method (auth thread):
epoll (with changelist)0: IO method (auth thread):
epoll (with changelist)0: IO method (admin thread):
epoll (with changelist)0: SQLite DB connection success: /var/lib/turn/turndb

Wie kann ich diese Bindung herstellen?

LG

Sie ist meines Wissen nach wohl die einzigste die Vollständig und sauber erklärt wurde, um die Einrichtung Schritt für Schritt umzusetzen.

Bei mir hat die Einrichtung gut funktioniert, ich bekomme auch eine Verbindung mit meinem Gegenüber und kann ein Gespräch führen, doch denke, das etwas noch nicht rund läuft, gerade in Bezug auf die TCP Verbindung.

Der erste Abschnitt Test (2 Zeilen) ist identisch mit Deinem, praktisch die „Halbe Miete“, allerdings habe ich im letzten Abschnitt „Test der Funktionalität“ die LOG-Datei mit Deiner verglichen und bei mir fehlen anscheinend das Zertifikat und der User.

Auch bei Trickle erhalte ich einen Fehler 701, obwohl am Ende „Done“ steht.

Da ich mir unsicher bin, ob alles korrekt ist und aus Verzweiflung von neuen starte, wollte ich kurz Deine Meinung hierzu hören. Anbei der Screenshot der LOG-Datei.

Vielleicht hast Du einen Hinweis für mich und ich erspare mir diese!

Nochmals vielen Dank!

Jens

Guten Abend Robin,
vielen Dank für den Hinweis. Da ist mir beim Testen das Kommentarzeichen abhanden gekommen. Ich habe den Fehler korrigiert.

Gruß,
Daniel

Ich weiß nicht, welche Auswirkungen das hat, wollte aber darauf hinweisen.

Moin Daniel!

Ich hab den coTurn jetzt so ins Netz gehangen.

Da ich ein wenig Paranoid bei sowas bin, bekomme ich immer etwas Bauchschmerzen.

Alles läuft soweit. Jitsi scheint keine Probleme zu haben und coTurn arbeitet ordentlich. Die ersten Tests sind erfolgreich verlaufen.

Vereinzeln treten noch  “ TLS/TCP socket buffer operation error (callback)“ – Fehler auf die ich noch nicht richtig zuordnen kann, aber das bekomme ich schon raus.

Ich habe den Jitsi & coTurn an unsere 1GigaBit Leitung gehangen, ich hoffe die Bandbreite reicht aus.

Ich möchte dir nochmals für alles Danken!

Bleib Gesund!

Grüße

Tobi

Hallo Tobi,
der TURN-Server wird in den meisten Fällen genutzt, um durch Firewalls und Proxy-Server aufbauen zu können. In diesem Fall nutzt Jitsi Meet den Port 10000/UDP. Der Port ist im Unternehmensumfeld nicht nutzbar. An diesem Punkt setzt der TURN-Server an. Durch die Nutzung von Port 443 (wird auch für HTTPS verwendet) ist die Chance groß, dass das Videosignal über Firewall/Proxy-Server übertragen werden kann. Somit ist keine Anpassung bei den evtl. Teilnehmern notwendig.

Der TURN-Server in unserer DMZ war für mich von Anfang an keine Option. Denn wir haben nicht die notwendige Brandbereite auf der bestehenden Datenleitung dafür zur Verfügung. Je nach Anzahl von parallelen Besprechungen und Anzahl der Teilnehmer kommen schnell mehrere Mbit/s zusammen. Die größte Besprechung in den lezten 30 Tagen hat 31Mbit/s benötigt.

In wie fern hast du Bauchschmerzen? Die Firewall ist aktiv und entsprechend konfiguriert.

Gruß Daniel
.

Guten Morgen Daniel,

danke für deinen Support!

Ich hab mittlerweile die Fehler soweit beheben können. Der „Bind Error“ hat sich mit diesem Artikel gut beheben können.
https://github.com/coturn/coturn/issues/421

Allerdings geht es weiter. Der Turnserver scheint zu funktionieren, denn Jitsi kann eine Verbindung zu diesem aufbauen. Allerdings ist meine Kernproblematik noch nicht damit behoben.

Zudem bekomme ich bei https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
nur „Host“-Verbindungen hin, bräuchte aber, sofern ich das richtig verstanden habe „srflx“ und „relay“ Verbindungen.

Dazu evtl. noch eine Frage. Ich habe den Turnserver ebenfalls in der DMZ stehen. Alle Ports werden entsprechend weiter geleitet.

Ich frage mich bei meinem derzeitigen Problem, ob der Turnserver überhaupt in einer DMZ mit einem NAT stehen darf. Ich habe einige dinge dazugelesen und die Meinugen waren durchwachsen und überlege den TURN Server so in die Frei Wildbahn zu hängen, bereitet mir allerdings ein wenig Bauchschmerzen.

Hast du Erfahrungen mit coTurn in einer DMZ gemacht?
Wenn ich noch einmal um einen Rat bitten dürfte wäre das ganz große Klasse!

Schönes Wocheende und nochmals vielen Dank für deine Hilfe!

Gruß
Tobi

Klingt für mich so, als würd Jitsi nichts von TURN-Server wissen. Daher vermute ich, dass in einer der Dateien ein Fehler eingeschlichen hat:
/etc/jitsi/meet/$FqdnJitsiServer-config.js
/etc/prosody/conf.avail/$FqdnJitsiServer.cfg.lua
/etc/jitsi/videobridge/sip-communicator.properties

Bitte kontrolliere diese nochmals auf Tippfehler und ob die korrekten Werte gesetzt sind.

Stehen die Server bei dir im LAN/DMZ oder bei einem Webhoster? Bei ersterem sind noch weitere Konfigurationsschritte notwendig. Da bin ich aber an der Stelle überfragt. Bisher keine Zeit gefunden dieses Szenario aufzubauen und zu dokumentieren,

Guten Abend Tobias,
ist evtl. durch ein anderer Service der Por gesperrt. Kannst du dir mit netstat -tulpen einmal anschauen.
Kontrolliere zudem ob du mit ifconfig ein Interface lo angezeigt bekommst.

Ich habe den Befehl „awk -F … /etc/turnserver.conf“ oben im Beitrag angepasst. Dieser hat die ganze ZEile ausgegeben und nicht nur das Passwort. Ab sofort wird nur noch das Passwort ausgegeben.

Gruß Daniel

Hallo Johannes, im ersten Moment hört es sich für mich so an, als hättest du in der Konfiguration /etc/turnserver.conf eine IP-Adresse angegeben, die auf dem Server nicht konfiguriert ist (ifconfig). Evtl. ein kl. Tippfehler bei der Übernahme. Gruß Daniel

0: log file opened: /var/log/turn_70603_2020-05-17.log
0: You cannot define external IP more than once in the configuration

das liegt wohl daran, dass ich wie bei Ihnen eine IPv4 und eine IPv6 konfigurieren will. Wissen Sie woran das liegt?

Hallo Daniel,
es sind unterschiedliche Server. Die FW habe ich auf beiden deaktiviert und ja der Stun lauscht auf 443.
Aber der Meet will nicht zum Stun er will innerlich den 10000 udp.

Ich verzweifle langsam.

Hallo Daniel,

Die Installation des Turnservers hat sehr gut geklappt und Trickle ICE (WebRTC) zeigt an das alles klappt!

Allerding muss dich nocheinmal um Rat fragen.

Im coturn Log bekomme ich folgenden fehler:

o: Cannot bind TLS/TCP listener socket to addr 127.0.0.1:443
0: Trying to bind TLS/TCP listener socket to addr 127.0.0.1:443, again…
0: Trying to bind fd 14 to : errno=13

Ich hab jetzt schon eniges dazu gelesen verstehe aber nicht ganz warum der bind nicht funktioniert. Evtl hast du noch eine Idee.

Und ich habe eine weitere Frage:

In der Jitsi konfiguration sprichst du von “ und .“
.habe ich durch awk -F „:“ ‚/static-auth-secret/ {print $1}‘ /etc/turnserver.conf erstetzt
Finde aber keine stelle wo ich erstetzen muss?

Gruß
Tobi