Unterstützt selbst gehostete Kollaborationssoftware Sprach- und Videoanrufe? Checkliste zur Netzwerkbereitschaft

Beginnen Sie mit den Anrufen, die Ihr Team tatsächlich braucht

„Unterstützt Anrufe“ ist keine vollständige Anforderung an die Bereitstellung. Bevor Sie Hosting-Optionen vergleichen, legen Sie fest, wer mit wem telefonieren soll, welche Clients dabei zum Einsatz kommen und von wo aus sich die Teilnehmenden verbinden. Für ein Team, dessen Mitglieder sich im selben Büronetzwerk befinden, können andere Einschränkungen gelten als für ein Team mit externen Gästen sowie Nutzern im Heim- oder Mobilfunknetz.

Klären Sie außerdem, welche Funktionen wichtig sind. Sprachübertragung, Video, Bildschirmfreigabe und Anrufe mit externen Teilnehmenden können unterschiedliche Anforderungen an Unterstützung oder Konfiguration haben. Der [Bereitstellungsleitfaden für Mattermost Calls](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) beschreibt Calls als selbst gehostete Funktion für Audioanrufe und Bildschirmfreigabe. Diese Beschreibung allein belegt nicht, dass alle Clients oder Nutzernetzwerke in Ihrer Umgebung funktionieren.

• Listen Sie die benötigten Anruffunktionen, Teilnehmendentypen und Clienttypen auf, etwa Browser oder native Anwendung.
• Berücksichtigen Sie die Netzwerke, die Nutzer verwenden: Büro, Zuhause, Mobilfunk sowie Gast- oder Partnernetzwerke.
• Legen Sie fest, welche Ausfälle akzeptabel sind. Reicht zum Beispiel ein Wechsel zu Audio aus, wenn keine Videoverbindung zustande kommt?

Trennen Sie Webzugriff, Signalisierung und Medienverkehr

Ein sinnvoller erster Schritt ist, die aktuelle offizielle Bereitstellungsdokumentation der Anwendung zu lesen und die Anforderungen den einzelnen Verbindungspfaden zuzuordnen. Die Weboberfläche ist das, was Nutzer laden; die Signalisierung dient dem Aufbau oder der Steuerung eines Anrufs; der Medienverkehr umfasst Audio und Video. In der Anwendungsdokumentation können diese Pfade getrennt beschrieben oder anders bezeichnet sein.

Die Möglichkeit, sich über einen Browser anzumelden, bestätigt den Webzugriff – nicht unbedingt, dass der Anrufaufbau oder die Medienübertragung in beide Richtungen funktioniert. Halten Sie die dokumentierten Anforderungen für jeden Pfad getrennt fest, statt anzunehmen, dass eine funktionierende Website die Anruffunktion bestätigt.

Die [Beschreibung von Talk durch Nextcloud](https://nextcloud.com/blog/nextcloud-talk-open-source-online-video-conferencing-software/) bezeichnet Talk als quelloffene Online-Videokonferenzsoftware mit Chats, Anrufen, Webinaren und Übertragungen. Diese Beschreibung hilft dabei, den Funktionsumfang des Produkts einzuordnen, legt aber für sich genommen nicht fest, welche Netzwerkkonfiguration Ihre Nutzer benötigen.

• Suchen Sie die Bereitstellungsdokumentation des Anbieters für genau die Anwendung und das Bereitstellungsmodell, die Sie nutzen möchten.
• Notieren Sie die dokumentierten Anforderungen für Weboberfläche, Anrufsignalisierung und Medienverkehr getrennt.
• Prüfen Sie, ob sich die Anforderungen je nach Client, Funktion oder Bereitstellungskomponente unterscheiden. Füllen Sie Informationslücken nicht mit Annahmen.

Prüfen Sie Protokolle, Ports, Firewalls, NAT und Relays

Erstellen Sie anhand der offiziellen Dokumentation eine Liste der erforderlichen Netzwerkänderungen. Halten Sie fest, welche Protokolle und Ports angegeben sind, ob eingehende, ausgehende oder beide Verbindungsrichtungen zugelassen werden müssen und welche Systeme oder Endpunkte beteiligt sind. Übernehmen Sie keine allgemeine Portliste eines anderen Kollaborationsprodukts: Die Anforderungen können sich unterscheiden, und die verfügbaren Produktbeschreibungen nennen keine konkreten Port- oder Firewallwerte.

Suchen Sie nach dokumentierten Angaben zum Verhalten, wenn sich Teilnehmende hinter NAT oder restriktiven Firewalls befinden. Prüfen Sie insbesondere, ob direkte Medienverbindungen funktionieren sollen, ob ein TURN-Relay unterstützt wird oder unter bestimmten Umständen erforderlich ist und wer dieses Relay betreibt. Falls die Dokumentation diese Fragen offenlässt, behandeln Sie sie als ungeklärte Fragen zur Bereitstellung und wenden Sie sich vor dem Rollout an den Anwendungsanbieter oder Hosting-Provider.

Ein Relay kann eine notwendige Abhängigkeit und kein optionales Detail sein. Klären Sie, ob es bereitgestellt, erreichbar und in der Anwendung konfiguriert werden muss oder separat gewartet wird. Bestätigen Sie diese Punkte anhand der Produktdokumentation, statt Annahmen zu treffen. Der [Bereitstellungsleitfaden für Mattermost Calls](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) ist ein Ausgangspunkt aus einer Primärquelle für Mattermost. Die verfügbaren Informationen zum Funktionsumfang belegen jedoch keine konkreten Anforderungen an Ports, NAT oder Relays.

• Erstellen Sie eine Tabelle mit den dokumentierten Protokollen, Ports, Übertragungsrichtungen, Zielen und Zwecken.
• Bitten Sie die Netzwerkadministration zu prüfen, ob der erforderliche Datenverkehr in den relevanten Büro- und Remote-Netzwerken zugelassen ist.
• Klären Sie das dokumentierte Verhalten bei NAT und den Einsatz von TURN – einschließlich Zuständigkeit für Betrieb und Wartung des Relays.
• Kennzeichnen Sie undokumentierte Anforderungen als ungeprüft. Eine erfolgreiche Anmeldung ist kein Beleg dafür, dass Medienverkehr zugelassen ist.

Prüfen Sie TLS, Domains und Annahmen zu Reverse-Proxys

Prüfen Sie, wie die Anwendung die öffentliche Domain, die TLS-Terminierung und gegebenenfalls einen Reverse-Proxy konfiguriert haben möchte. Ermitteln Sie, welche Komponente die einzelnen Verbindungen verarbeitet und ob die offizielle Dokumentation zusätzliche Anforderungen für Anrufe über die Weboberfläche hinaus aufführt. Gehen Sie nicht davon aus, dass eine bestimmte Proxy- oder TLS-Konfiguration für alle Anruffunktionen unterstützt wird, sofern dies nicht in der Anwendungsdokumentation steht.

Eine gültige HTTPS-Seite ist kein vollständiger Test des Anrufpfads. Sie kann bestätigen, dass der Webendpunkt erreichbar ist, während die Anforderungen an Signalisierung oder Medienverkehr ungeprüft bleiben. Wenn Ihre Architektur einen Proxy vor der Anwendung vorsieht, vergleichen Sie die dokumentierte Anrufarchitektur mit der tatsächlichen Weiterleitung und Zertifikatskonfiguration und klären Sie Unklarheiten, bevor Nutzer auf die Anruffunktion angewiesen sind.

Die [Produktinformationen von Airbip](https://airbip.com) beschreiben automatisiertes Routing und TLS-Zertifikate über Traefik und Let’s Encrypt sowie die Unterstützung einer Airbip-Subdomain oder einer kompatiblen eigenen Domain. Diese Funktionen beschreiben die Webhosting-Konfiguration. Sie belegen für sich genommen nicht, dass die Anruffunktionen oder Medienpfade einer bestimmten Anwendung in jedem Netzwerk unterstützt werden.

• Bestätigen Sie die erforderliche öffentliche Domain und das TLS-Verhalten anhand der Bereitstellungsdokumentation der Anwendung.
• Gleichen Sie die dokumentierte Architektur mit Ihrer tatsächlichen Proxy-, DNS- und Zertifikatskonfiguration ab.
• Bitten Sie den zuständigen Anbieter oder Hersteller um Klärung, wenn nicht dokumentierte Proxy- oder TLS-Anforderungen für Anrufe bestehen.

Testen Sie mit repräsentativen Nutzern, nicht nur mit dem Serverteam

Testen Sie nach Umsetzung der dokumentierten Konfiguration von den Netzwerken aus, die Ihre Nutzer tatsächlich verwenden. Ein Test im selben Büro- oder Serverumfeld kann Einschränkungen übersehen, die in Heim-, Mobilfunk-, Gast- oder Partnernetzwerken auftreten. Beziehen Sie mindestens ein restriktives Netzwerk ein, wenn Nutzer aus solchen Umgebungen zur Zielgruppe gehören.

Verwenden Sie eine wiederholbare Checkliste: Können Teilnehmende einen Anruf starten und beitreten, einander in beide Richtungen hören, bei Bedarf Video sehen und die benötigten Inhalte freigeben? Testen Sie anschließend, was passiert, wenn eine Verbindung unterbrochen und wiederhergestellt wird. Falls die Anwendung anzeigt, ob ein Relay verwendet wird, halten Sie dieses Ergebnis fest. Leiten Sie die Relay-Nutzung nicht allein aus der Anrufqualität ab.

Ein erfolgreicher Test belegt, dass die getestete Konfiguration für die getesteten Nutzer und Netzwerke zu diesem Zeitpunkt funktioniert hat. Er garantiert nicht, dass sich jedes Netzwerk oder Gerät von Teilnehmenden oder spätere Netzwerkänderungen gleich verhalten. Die oben genannten Produktbeschreibungen geben kein Verfahren für Tests in repräsentativen Netzwerken vor. Betrachten Sie diese Checkliste daher als allgemeine Anleitung zur Bereitstellung und nicht als Produktgarantie.

• Testen Sie jeden erforderlichen Clienttyp und alle Anruffunktionen, die das Team nutzen möchte.
• Testen Sie Teilnehmende in Büro-, Heim-, Mobilfunk- und anderen relevanten Netzwerken, darunter nach Möglichkeit auch restriktive Umgebungen.
• Dokumentieren Sie Anrufaufbau, Audio in beide Richtungen, Video, bei Bedarf Bildschirmfreigabe, Wiederverbindung und das dokumentierte Relay-Verhalten.
• Halten Sie Datum, Clienttyp, Netzwerkkontext und Ergebnis fest, damit Sie die Resultate nach Änderungen vergleichen können.

Wählen Sie ein Bereitstellungsmodell anhand geprüfter Anforderungen

Vergleichen Sie Hosting-Optionen erst, wenn Ihnen die dokumentierten Anforderungen der Anwendung vorliegen und Sie wissen, welche Netzwerksteuerungsmöglichkeiten Sie haben. Prüfen Sie, ob Sie die erforderlichen Firewallregeln konfigurieren, gegebenenfalls einen Relay-Dienst betreiben oder bereitstellen lassen und Fehler in den unterschiedlichen Netzwerken der Nutzer untersuchen können.

Eine verwaltete Bereitstellung der Anwendung kann Teile der Infrastruktur rund um eine Anwendung übernehmen. Das belegt jedoch nicht automatisch die Unterstützung jeder Anruffunktion oder jedes Netzwerkpfads. Die [Produktinformationen von Airbip](https://airbip.com) beschreiben Anwendungsinstanzen als Docker-Workloads auf den Cloud-Servern des Anbieters sowie die Verwaltung des Dienstlebenszyklus, DNS-Prüfungen und konfigurierbare tägliche, wöchentliche und monatliche Backups. Bewerten Sie diese Funktionen zusammen mit den anrufbezogenen Anforderungen, die Sie anhand der Anwendungsdokumentation bestätigt haben – nicht als Ersatz dafür.

Wenn Ihr Team eine erforderliche Netzwerksteuerung oder einen nötigen Relay-Dienst nicht bereitstellen oder die unterschiedlichen Netzwerke der Nutzer nicht unterstützen kann, ist möglicherweise ein anderes Bereitstellungsmodell oder ein für den Anwendungsfall konzipierter Dienst besser geeignet. Treffen Sie diese Entscheidung anhand geprüfter Anforderungen und nicht aufgrund einer Anruftaste oder einer erfolgreichen Webanmeldung.

• Ordnen Sie jeder dokumentierten Anforderung eine verantwortliche Partei zu: Ihrem Team, dem Hosting-Provider oder dem Anwendungsanbieter.
• Klären Sie Abhängigkeiten von Relays und Netzwerksteuerungen, bevor Sie sich auf eine Bereitstellung festlegen.
• Wählen Sie ein anderes Modell, wenn eine erforderliche Funktion oder betriebliche Zuständigkeit nicht abgedeckt werden kann.

Dokumentieren Sie Zuständigkeiten und testen Sie nach Änderungen erneut

Halten Sie Architektur, dokumentierte Protokolle und Ports, DNS- und TLS-Konfiguration, Proxy-Einstellungen, Relay-Abhängigkeiten sowie die Zuständigkeit für einzelne Änderungen knapp fest. Fügen Sie einen Weg zur Fehlerbehebung hinzu, damit Nutzer wissen, wo sie Probleme melden können und Administratoren zwischen Problemen mit dem Webzugriff, dem Anrufaufbau und dem Medienverkehr unterscheiden können.

Planen Sie wiederholte repräsentative Tests nach Änderungen an der Anwendung, der Hosting-Konfiguration, dem Proxy, der Firewall, dem Relay oder dem Nutzernetzwerk. Ein dokumentierter, wiederholbarer Test ist hilfreicher, als eine erfolgreiche Besprechung als dauerhafte Garantie zu betrachten.

• Notieren Sie die verwendete Dokumentationsquelle und das Prüfdatum sowie alle offenen Fragen.
• Benennen Sie die Verantwortlichen für Firewalländerungen, Relay-Betrieb, Anwendungskonfiguration und Nutzersupport.
• Wiederholen Sie die Tests nach wesentlichen Änderungen an Infrastruktur oder Netzwerk und aktualisieren Sie die Dokumentation.