Matrix und WebRTC – Voice/Video-Calls
Voice/Video-Calls mittels #WebRTC sind ja eine wunderbare Sache. Und oft funktioniert das ja “out-of-the-box”. Meine Kollegen erzählten mir, dass sie in der #Matrix-Config (/etc/matrix-synapse/homeserver.yaml) keinerlei stun/turn-Server konfiguriert haben und “keine Probleme bisher feststellten”.
Dann bat ich sie, mich anzurufen. Und es ging nicht. Ein anderes Mal ging es, dann wieder nicht. Also nix was man stabil oder verlässliche Verbindung nennen kann...
Da ich voraussichtlich die ehrenvolle Aufgabe bekommen werde, einen #POC für einen sehr großen Nutzerkreis bei mir in der Arbeit für einen Matrix-Server aufzubauen, hat mich das natürlich schwerst gewurmt, dass ich keine stabile und verlässliche Verbindung für Voice/Video-Calls auf meinem privaten Matrix-Server hinbekomme. Denn Voice/Video-Calls sind eine essentielle Anforderung für den POC bei mir in der Arbeit.
Ich hab mir dazu bei mehreren Matrix-Servern diverse Testaccounts zugelegt und alle verschiedenen Kombinationen (#Element, #Schildichat, #Nheko, #Android-App, Linux-App, auf den zwei Mobiltelefonen und am #Linux-Laptop, mit allen Accounts) durchgespielt.
Es zeigte sich immer wieder das selbe Phänomen. Von einem Client im Drei-Netz zu einem Client im A1-Netz blieb ein Voice/Video-Call immer bei “Verbindungsaufbau” hängen und brach dann ab.
Schließlich kam mir adminforge.de in die Quere. Die betreiben auch zwei STUN-Server. Mit der Erklärung, dass für die vollumfängliche Detektion welche NAT zum Einsatz kommen, zwei verschiedene #STUN-Server konfiguriert sein müssen. Ich hab das zwar schon gelesen... aber bislang nicht berücksichtigt.
STUN/TURN(S)
Ich betreibe einen eigenen coturn, der für #TURN auf Port 443 und für STUN auf Port 3478 lauscht. Ich dachte, das wird schon reichen, da es ja in vielen Fällen auch klappt.
Diesen STUN/TURN-Server verwende ich übrigens auch für meinen eigenen #PairDrop Server. Der ebenso relativ unzuverlässig die Verbindung zwischen besagten Clients in den A1- und Drei-Netzen herstellt. Mal finden sich die Clients, mal nicht...
Zurück zu adminforge.de die einen Matrix-Account für die Kontaktaufnahme auf nope.chat betreiben. Ich hab mir also nun auch auf nope.chat einen Testaccount registriert. Da ich einmal ganz billig davon ausgegangen bin, dass adminforge deswegen dort einen Account haben, da der Matrix-Server korrekt (mit stun oder gar auch turn) eingerichtet ist. Und siehe da, ein Voice/Video-Call ist damit von A1 zu Drei möglich.
Also habe ich weiter gespielt/analysiert. Hab bei meinem Matrix-Account alle stun/turn-Einträge entfernt und synapse neu gestartet.
Voila: Die Verbindung bleibt bei “connecting” hängen.
Hab in meinem Matrix-Server zwei stun-Server hinzugefügt: Ich kann erneut erfolgreich Voice/Video-Calls herstellen.
Außerdem hab ich meinem Pairdrop-Server nun einen zweiten stun-Server hinzugefügt, und damit krieg ich nun auch zuverlässig hin, dass Clients im A1- und Drei-Netz sich wechselseitig finden.
Fazit
Für eine zuverlässige Voice/Video-Verbindung zwischen Matrix-Clients in zwei vollkommen verschiedenen Netzen ist es notwendig, dass BEIDE beteiligten Matrix-Server zumindest STUN-Server konfiguriert haben. Besser noch STUN und TURN, damit auch zwischen Clients die beide hinter einem NAT sind auch Gespräche notwendig sind.
In der Datei /etc/matrix-synapse/homeserver.yaml sind dazu folgende Zeilen hinzuzufügen:
turn_uris:
- "stun:ein.stunserver.tld:443"
- "stun:zweiter.stunserver.tld:443"
- "turns:ein.turnserver.tld:443?transport=udp"
- "turns:ein.turnserver.tld:443?transport=tcp"
Ich habe für den ersten stun-Server meinen eigenen und für den zweiten den von adminforge.de eingetragen. Und für den turn-Server ist ebenfalls die Domain meines coturn.