Eine Videosprechstunde per WebRTC sucht sich ihren Weg durchs Netz selbst: direkt, über ein Relay per UDP oder notfalls über TCP-Port 443. Ob sie in einer Klinik, einem Pflegeheim oder bei einem Träger mit zentraler IT läuft, hängt deshalb weniger an einzelnen Portfreigaben als an UDP-Sperren, Proxys und TLS-Inspection. Was die IT freigeben sollte, wie sie es testet und was die Verschlüsselung dabei schützt.

Nicht ob, sondern über welchen Weg

Vor dem Kauf eines Videodienstes oder einem Anbieterwechsel fragen Kliniken, Pflegeeinrichtungen und Beratungsstellen meist: Läuft das in unserem Netz? Die Antwort ist selten ein klares Nein. WebRTC, die Browsertechnik hinter den meisten Videodiensten, probiert mehrere Verbindungswege durch und nimmt den besten, der funktioniert. Ein restriktives Netz verhindert das Gespräch deshalb oft nicht, sondern drängt es auf einen schlechteren Weg. Dann stockt das Bild, und niemand denkt an die Firewall.

Für Vertragsärztinnen und -ärzte ist das keine reine Technikfrage. Nach § 2 Abs. 1 der Anlage 31b zum Bundesmantelvertrag-Ärzte (BMV-Ä) müssen sie in ihren Räumlichkeiten und IT-Systemen die erforderlichen technischen und organisatorischen Maßnahmen gewährleisten. Die IT gehört deshalb vor der Einführung an den Tisch.

Wie eine WebRTC-Verbindung zustande kommt

Ein Videogespräch im Browser besteht aus zwei getrennten Verbindungen.

Signalisierung: Beide Browser melden sich beim Server des Anbieters an, meist über HTTPS und eine dauerhaft offene WebSocket-Verbindung auf TCP-Port 443. Den Weg schreibt WebRTC nicht vor. Darüber tauschen sie Formate, mögliche Adressen und die Fingerabdrücke ihrer Zertifikate für die Verschlüsselung aus. Bild und Ton laufen nicht über diesen Weg.

Medien: Für Bild und Ton sammelt jeder Browser per ICE (Interactive Connectivity Establishment) mögliche Adressen, sogenannte Kandidaten:

ICE testet die Kandidatenpaare beider Seiten und wählt das beste funktionierende. UDP hat Vorrang, weil Echtzeitmedien Verzögerung schlechter vertragen als einzelne verlorene Pakete: TCP wiederholt jedes verlorene Paket und hält dabei alle nachfolgenden auf. Erst wenn UDP nirgends durchkommt, läuft das Gespräch über TURN per TCP oder TLS, meist auf Port 443. Die Architekturfrage dahinter behandelt der Beitrag Peer-to-Peer vs. Server.

Woran restriktive Netze scheitern

UDP ist gesperrt

Restriktive Firewalls lassen ausgehend oft nur TCP 80 und 443 zu. Außerdem empfehlen Firewallhersteller teils, UDP 443 zu sperren, damit Browser nicht per QUIC (HTTP/3) an der TLS-Inspection vorbei surfen. Eine Sperre, die nur den Port betrachtet, trifft auch TURN über UDP 443. Das Gespräch fällt auf TCP zurück, kommt zustande und stockt, sobald die Leitung schwankt.

TLS-Inspection und Deep Packet Inspection

Eine Inspection bricht TLS-Verbindungen auf, prüft den Inhalt und verschlüsselt neu. In TURN über TLS steckt aber kein HTTP, und Systeme, die dort Webverkehr erwarten, verwerfen solche Verbindungen je nach Konfiguration. Ähnlich wirken Regeln zur Anwendungskontrolle, die STUN und TURN an Signaturen erkennen und sperren.

Proxys mit Anmeldung

Kommt das Netz nur über einen HTTP-Proxy ins Internet, gelangt kein UDP hinaus. Dann bleibt TURN über TLS, getunnelt per HTTP CONNECT. Der WebRTC-Standard (RFC 8835) stellt Browsern diese Proxy-Unterstützung frei. Scheitern kann der Tunnel auch, wenn der Proxy CONNECT nur zu bekannten Webzielen erlaubt, den Tunnel aufbricht oder Anmeldedaten verlangt, die der Browser nicht automatisch mitschickt.

WebSocket wird blockiert

Manche Proxys lassen das WebSocket-Upgrade nicht zu oder trennen Verbindungen, über die eine Weile wenig läuft. Dann lädt die Seite, aber die Gegenseite erscheint nie oder fliegt nach einigen Minuten heraus.

Was die IT freigeben sollte

Die Anforderungen ähneln sich bei allen WebRTC-Diensten, Hostnamen und Ports unterscheiden sich je Anbieter. Verbreitet sind die Standardports 3478 (STUN und TURN) und 5349 (über TLS) aus RFC 8489 und RFC 8656, manche Anbieter legen alles auf 443.

Dazu einige Grundsätze:

• Nur ausgehend: Eingehende Portweiterleitungen braucht WebRTC nicht. Eine zustandsbehaftete Firewall lässt die Antworten auf ausgehende Pakete zurück.
• Hostnamen statt IP-Adressen: Anbieter tauschen Server aus. FQDN-Objekte in der Firewall überstehen das, fest eingetragene IP-Adressen nicht.
• Direkt oder planbar: Wer UDP zu beliebigen Zielen erlaubt, ermöglicht direkte Verbindungen. Wer nur die TURN-Server freigibt, hat wenige, klar definierte Ziele, und alle Gespräche laufen über das Relay, mit etwas mehr Latenz.
• Bandbreite: Eine Freigabe sagt nichts über die Qualität. Was ein Gespräch braucht, steht im Beitrag zu Bandbreite und Verbindungsqualität.

Gast-WLAN oder Fachnetz

Ein häufiges Muster: Im Gast-WLAN klappt der Test, im Fachnetz nicht. Gastnetze lassen oft mehr ausgehenden Verkehr zu, sind aber gedrosselt, verlangen regelmäßig eine neue Anmeldung, und die Geräte darin verwaltet niemand zentral. Das Fachnetz ist das Gegenteil: verwaltete Geräte, restriktive Regeln, teils ganz ohne Internetzugang.

Ein Tablet ins Gastnetz zu verschieben löst das technische Problem und schafft ein organisatorisches, weil dort Richtlinien und Geräteverwaltung fehlen. Tragfähiger ist ein eigenes Segment (VLAN) für Telemedizin-Geräte mit genau den Freigaben aus der Tabelle. Für Visitenwagen in Pflegeheimen gehört ein WLAN dazu, das auch in den Bewohnerzimmern trägt, siehe Televisite im Pflegeheim. Ein Mobilfunk-Hotspot taugt als Notlösung, umgeht aber alle Regeln des Hauses.

So testet die IT die Freigaben

1. Am echten Ort testen: mit dem späteren Gerät, im selben Netzsegment und Benutzerkontext, nicht vom Admin-Arbeitsplatz aus.
2. Den Verbindungstest des Anbieters nutzen, idealerweise mit denselben Servern und Zugangsdaten wie im echten Gespräch.
3. Zwei Testgespräche führen: eines mit einem Smartphone im Mobilfunknetz als Gegenstelle, eines mit beiden Seiten in restriktiven Netzen, etwa Klinik und Pflegeheim.
4. Den gewählten Weg prüfen: chrome://webrtc-internals (Edge: edge://webrtc-internals) bzw. about:webrtc in Firefox zeigt während des Gesprächs das aktive Kandidatenpaar mit Typ (host, srflx, relay) und Protokoll (UDP oder TCP).
5. STUN gezielt prüfen: Die Testseite "Trickle ICE" des WebRTC-Projekts zeigt, ob ein STUN-Server einen srflx-Kandidaten liefert, also UDP hinauskommt.
6. Firewall-Logs lesen: Verworfene UDP-Pakete zu den Servern des Anbieters erklären die meisten Rückfälle auf TCP.

Fehlerbilder jenseits des Netzes, etwa Echo oder fehlende Berechtigungen, behandelt der Beitrag zu technischen Fehlern in der Videosprechstunde.

Was Relay und Inspection zu sehen bekommen

Schwächt der Umweg über einen TURN-Server oder eine Inspection die Vertraulichkeit? Bei einer Peer-to-Peer-Verbindung nicht für die Inhalte. WebRTC verschlüsselt Bild und Ton verpflichtend per SRTP, die Schlüssel handeln die beiden Browser per DTLS untereinander aus. Der TURN-Server leitet nur Pakete weiter, die er nicht entschlüsseln kann. Bei Diensten mit Medienserver endet diese Verschlüsselung am Server, sofern der Anbieter keine zusätzliche Ende-zu-Ende-Verschlüsselung einsetzt.

Eine TLS-Inspection, die TURN über TLS aufbricht, entfernt nur die äußere Hülle. Darunter liegt weiterhin DTLS-SRTP, für das sie keine Schlüssel hat. Anlage 31b BMV-Ä verlangt ohnehin, dass sämtliche Inhalte während der gesamten Übertragung Ende-zu-Ende verschlüsselt sind und der Videodienstanbieter sie weder einsehen noch speichern kann (§ 2 Abs. 3 und 4). Mehr dazu im Beitrag zur Ende-zu-Ende-Verschlüsselung.

Anders die Signalisierung: Bricht die Inspection sie auf, liest das System Verbindungsdaten mit, je nach Dienst auch Anzeigenamen von Patientinnen und Patienten. Über sie laufen außerdem die Fingerabdrücke der Zertifikate für die Medienverschlüsselung; wer sie dort austauschen kann und zusätzlich den Medienstrom abfängt, könnte mithören (RFC 8827, Abschnitt 9.1). Das spricht dafür, die Domains des Videodienstes von der Inspection auszunehmen. Eine Freigabe von UDP 443 zu wenigen festen Hosts ist dagegen eine eng gefasste Regel.

Endgeräte und Browserrichtlinien

Auch die Gerätekonfiguration kann das Gespräch verhindern:

• Kamera und Mikrofon: In Chrome und Edge erteilen die Richtlinien VideoCaptureAllowedUrls und AudioCaptureAllowedUrls bestimmten Adressen den Zugriff vorab, in Firefox die Richtlinie Permissions. Ist VideoCaptureAllowed deaktiviert, funktioniert die Kamera nur noch auf den Adressen in VideoCaptureAllowedUrls. Auch das Betriebssystem kann den Kamerazugriff sperren.
• WebRTC-Richtlinien: Steht in Chrome WebRtcIPHandling (in Edge WebRtcLocalhostIpHandling) auf disable_non_proxied_udp (Edge: DisableNonProxiedUdp), nutzt WebRTC ohne UDP-fähigen Proxy nur TCP, jedes Gespräch läuft dann über das TCP-Relay. WebRtcUdpPortRange grenzt in Chrome und Edge den lokalen UDP-Portbereich ein, was Firewallregeln vereinfacht.
• Veraltete Browser: Eingefrorene Versionen auf Thin Clients oder älteren Tablets erzeugen Fehler, die wie Netzprobleme aussehen.
• Virtuelle Desktops: Läuft der Browser auf einem Terminalserver, müssen Kamera und Mikrofon dorthin umgeleitet werden. Ob das trägt, zeigt nur ein Test; ein lokaler Browser ist meist einfacher.

Was MeetOne im Netz braucht

MeetOne baut Videogespräche per WebRTC im Browser auf, ohne Installation, und verbindet die Teilnehmenden Peer-to-Peer, bei Bedarf über ein TURN-Relay. Stand Oktober 2026:

• Webanwendung und Signalisierung: HTTPS und WebSocket auf TCP 443 zur Domain der Instanz, im Standardfall app.meetone.io, bei Instanzen mit eigener Domain zu dieser.
• STUN und TURN: Port 443, STUN und TURN über UDP, TURN zusätzlich über TCP und TLS. Die Server liegen unter Subdomains von meetone.io, die gültigen Hostnamen nennt MeetOne bei der Abstimmung.
• Media-Relay: ausgehendes UDP auf den Ports 10000–20000 zu denselben Servern. Aus diesem Bereich vergibt der TURN-Server die Relay-Adressen, über die Bild und Ton laufen, wenn keine direkte Verbindung zustande kommt. Diese Ports nennt auch die Fehlermeldung des System-Checks.
• Zugangsdaten: Die TURN-Zugangsdaten erzeugt der Server zeitlich befristet, die IT muss kein Konto hinterlegen.

Zum Testen gibt es einen öffentlichen System-Check, ohne Anmeldung. Er prüft Kamera, Mikrofon und Lautsprecher, misst Upload, Download, Latenz und Paketverlust und testet mit derselben Serverliste wie ein echtes Gespräch, ob das Relay erreichbar ist und ob UDP durchkommt. Kommt kein UDP durch, wohl aber TCP oder TLS, meldet er eine eingeschränkte Verbindung, in der Gespräche bei schwankender Verbindung kurz stocken können. Auch die Beitrittsseite jedes Gesprächs prüft, ob die Videoserver erreichbar sind.

Lässt ein Netz weder UDP noch TCP 443 zu den TURN-Servern durch oder verwirft eine Inspection TURN über TLS, kommt in der Regel kein Gespräch zustande, daran ändert auch MeetOne nichts. Hostnamen und Portbereiche können sich mit der Infrastruktur ändern, etwa mit neuen Funktionen. Die aktuelle Liste sollte deshalb vor der Einführung abgestimmt werden.

Fazit

Ob eine Videosprechstunde im eigenen Netz läuft, entscheidet sich selten an einer einzelnen Portfreigabe, sondern daran, welchen Weg UDP-Sperren, Proxys und TLS-Inspection der Verbindung lassen. Mit ausgehendem UDP zu den Servern des Anbieters, TCP 443 als Rückfallebene und einer Ausnahme von der Inspection kommen Gespräche auch in restriktiven Netzen über einen guten Weg zustande. Welcher Weg tatsächlich gewählt wird, zeigt ein Test am echten Gerät. Bei Peer-to-Peer-Verbindungen bleiben die Inhalte auch über ein Relay Ende-zu-Ende verschlüsselt.

Dieser Artikel dient der allgemeinen Information und ersetzt keine individuelle technische oder datenschutzrechtliche Beratung. Stand: Oktober 2026.