ONVIF und RTSP testen: So finden Sie den Videostream einer IP-Kamera

Bei der Einrichtung unterschiedlicher IP-Kameras zeigt sich schnell, dass die Angabe „ONVIF-kompatibel“ keine Garantie für eine erfolgreiche Verbindung darstellt. Eine Kamera kann mit einem Netzwerkrekorder problemlos funktionieren und von einem anderen System abgelehnt werden. Umgekehrt lassen sich manche Kameras in UGOS Überwachung einbinden, obwohl sie mit einem älteren NVR nicht vernünftig zusammenarbeiten.

Das erwartet Sie in diesem Beitrag

ansehen/verstecken

• ONVIF und RTSP erfüllen unterschiedliche Aufgaben
• Wenn UGOS einen internen Serverfehler meldet
• Nmap auf dem Mac installieren
• Die IP-Adresse der Kamera feststellen
• Erster Portscan mit den gebräuchlichsten Ports
• Gezielt typische Kamera-Ports prüfen
• Vollständigen TCP-Portscan durchführen
• Die Dienstnamen von Nmap nicht überbewerten
• Was bedeuten „open“, „closed“ und „open|filtered“?
• UDP-Port 3702 und ONVIF-Discovery prüfen
• Ein typisches Ergebnis einer 7Links-Kamera
• Ein offener RTSP-Port verrät noch nicht die vollständige Adresse
• FOSCAM-Kameras: ungewöhnliche Ports 88 und 888
• RTSP-Adressen mit Zugangsdaten schützen
• VLC als unabhängiges Testwerkzeug
• Mainstream und Substream unterscheiden
• Video ohne Audio verwenden
• H.264 ist für Fremdsysteme oft die sicherste Wahl
• Eine unbekannte China-Kamera als Beispiel
• Port 6668 als Hinweis auf Tuya- und ELESION-Geräte
• ONVIF-Profile und RTSP-Adresse direkt auslesen
• Auch professionelle Kameras geben ihre Profile per ONVIF aus
• Der Medien-Port eines NVR ist nicht automatisch der RTSP-Port
• Typischer Diagnoseablauf für eine unbekannte Kamera
• Eine einfache Kompatibilitätsmatrix hilft beim Überblick
• Was ein guter Hersteller dokumentieren sollte
• Fazit: Erst untersuchen, dann aufgeben
• Bildquellen:

Wenn die automatische Suche oder die ONVIF-Einrichtung scheitert, ist deshalb noch längst nicht alles verloren. Viele IP-Kameras stellen zusätzlich einen direkten RTSP-Videostream zur Verfügung. Kennt man dessen Adresse, lässt sich die Kamera häufig trotzdem in eine Überwachungssoftware oder ein NAS integrieren.

In diesem Beitrag zeige ich, wie wir auf dem Mac mit Nmap, ONVIF und VLC untersucht haben, welche Netzwerkdienste eine Kamera anbietet und wie sich ein vorhandener RTSP-Stream ermitteln und überprüfen lässt.

ONVIF und RTSP erfüllen unterschiedliche Aufgaben

ONVIF soll die Zusammenarbeit zwischen IP-Kameras, Netzwerkrekordern und Überwachungssoftware verschiedener Hersteller vereinfachen.

Über ONVIF können unter anderem Informationen zu folgenden Funktionen ausgetauscht werden:

• verfügbare Videoprofile,
• Auflösungen und Codecs,
• Adressen der Videostreams,
• Audiofunktionen,
• PTZ-Steuerung beweglicher Kameras,
• Ereignismeldungen,
• Geräteinformationen.

RTSP ist im Vergleich dazu wesentlich direkter. Das Real Time Streaming Protocol dient vor allem dazu, einen Video- beziehungsweise Audiostream von der Kamera abzurufen.

Vereinfacht lässt sich der Unterschied folgendermaßen beschreiben:

ONVIF fragt die Kamera nach ihren Fähigkeiten und Einstellungen. RTSP liefert das eigentliche Bild.

Eine Kamera kann einen vollkommen funktionierenden RTSP-Stream bereitstellen, obwohl ihre ONVIF-Implementierung nicht mit der verwendeten NVR-Software harmoniert.

Genau diese Unterscheidung war bei unseren Versuchen entscheidend.

Wenn UGOS einen internen Serverfehler meldet

Mehrere Kameras wurden von UGOS Überwachung erkannt oder konnten über ihre IP-Adresse und ihren ONVIF-Port angesprochen werden. Benutzername und Passwort wurden angenommen und die Einrichtung ließ sich scheinbar vollständig vornehmen.

Beim abschließenden Speichern erschien allerdings wiederholt:

„Interner Serverfehler“.

Dieses Verhalten trat unter anderem bei mehreren FOSCAM-Kameras und verschiedenen 7Links-Modellen auf. Einige dieser Kameras funktionierten gleichzeitig per ONVIF mit dem vorhandenen FOSCAM-NVR.

Damit war klar, dass weder die Kameras noch ONVIF grundsätzlich defekt waren. Offenbar verstanden sich lediglich die jeweiligen ONVIF-Implementierungen nicht vollständig miteinander.

Die entscheidende Frage lautete daher:

Stellt die Kamera unabhängig von ONVIF einen direkt erreichbaren RTSP-Stream bereit?

Nmap auf dem Mac installieren

Um herauszufinden, welche Netzwerkdienste eine Kamera überhaupt anbietet, verwendeten wir das kostenlose Diagnosewerkzeug Nmap.

Unter macOS lässt sich Nmap bequem über Homebrew installieren:

brew install nmap

Falls Homebrew bereits für andere Werkzeuge eingerichtet wurde, ist keine weitere Grundlage notwendig. Nach der Installation kann Nmap direkt im Terminal verwendet werden.

Das aktuelle Arbeitsverzeichnis des Terminals spielt dabei keine Rolle. Der Befehl funktioniert beispielsweise auch dann, wenn man sich gerade im Verzeichnis ~/onvif-test befindet.

Die IP-Adresse der Kamera feststellen

Für einen Portscan wird zunächst die lokale IP-Adresse der Kamera benötigt. Sie lässt sich beispielsweise in der Netzwerkübersicht der FRITZ!Box ermitteln.

Geräte sollten dort nach Möglichkeit eindeutige Namen erhalten. Bei einem größeren Heimnetz mit zahlreichen Kameras, Smart-Home-Komponenten, Fernsehern, Mobilgeräten und Testgeräten verliert man sonst schnell den Überblick.

Für Kameras und andere dauerhaft verwendete Netzwerkgeräte ist es sinnvoll, in der FRITZ!Box festzulegen, dass ihnen immer dieselbe IPv4-Adresse zugewiesen wird. Dadurch bleibt die Kamera auch nach einem Neustart unter der bekannten Adresse erreichbar.

In den folgenden Befehlen muss 192.168.178.xxx jeweils durch die tatsächliche Adresse der zu untersuchenden Kamera ersetzt werden.

Erster Portscan mit den gebräuchlichsten Ports

Für eine erste Untersuchung müssen nicht sofort alle 65.535 möglichen TCP-Ports geprüft werden. Bei manchen Kameras kann ein vollständiger Scan mehrere Minuten dauern.

Ein sinnvoller erster Test der 1.000 gebräuchlichsten Ports sieht folgendermaßen aus:

nmap -sT --top-ports 1000 --stats-every 10s 192.168.178.xxx

Die Option -sT führt einen vollständigen TCP-Verbindungsaufbau durch. Das funktioniert auf dem Mac normalerweise ohne besondere Administratorrechte.

Mit

--top-ports 1000

beschränkt sich Nmap auf die 1.000 besonders häufig verwendeten TCP-Ports.

Die zusätzliche Option

--stats-every 10s

veranlasst Nmap dazu, alle zehn Sekunden einen Fortschrittsbericht auszugeben. Man sitzt dadurch nicht längere Zeit vor einer scheinbar inaktiven Terminalzeile und fragt sich, ob das Programm noch arbeitet.

Gezielt typische Kamera-Ports prüfen

Wenn es zunächst nur um eine grobe Einordnung geht, können auch ausgewählte typische Ports getestet werden:

nmap -sV --version-light -Pn -p 80,81,443,554,8000,8080,8443,8554,8899,10000,34567,37777,6668 192.168.178.xxx

Dieser Befehl prüft mehrere bei Kameras, NVRs und chinesischen OEM-Geräten häufig vorkommende Ports.

Die Optionen bedeuten:

• -sV versucht, den auf einem offenen Port angebotenen Dienst zu erkennen.
• --version-light begrenzt die Intensität dieser Diensterkennung.
• -Pn behandelt das Ziel als erreichbar, ohne sich auf einen vorherigen Ping-Test zu verlassen.
• -p legt die zu prüfenden Ports fest.

Zu den besonders interessanten Portnummern gehören:

Port	Typische Bedeutung
80	HTTP-Webinterface
443	HTTPS-Webinterface
554	RTSP-Videostream
8000	herstellerspezifischer Server- oder Verwaltungsdienst
8080	alternatives Webinterface oder HTTP-Dienst
8443	alternativer HTTPS- oder SDK-Dienst
8554	alternativer RTSP-Port
10000	bei manchen 7Links-Kameras ONVIF beziehungsweise Kameraverwaltung
6668	häufig bei Tuya-, ELESION- und verwandten OEM-Geräten zu finden

Diese Zuordnung ist lediglich ein Hinweis. Ein Hersteller kann nahezu jeden Dienst auf einer anderen Portnummer betreiben.

Vollständigen TCP-Portscan durchführen

Wenn der erste Test keine ausreichenden Ergebnisse liefert, kann ein vollständiger TCP-Portscan durchgeführt werden:

nmap -p- 192.168.178.xxx

Die Schreibweise -p- bedeutet, dass sämtliche TCP-Ports von 1 bis 65.535 geprüft werden.

Ein solcher Scan kann deutlich länger dauern. Bei einer unserer Kameras benötigte die vollständige Untersuchung etwas mehr als sieben Minuten. Bei langsam reagierenden WLAN-Kameras kann es auch wesentlich länger dauern.

Der vollständige Scan ist dennoch nützlich, weil einige Hersteller ihre Dienste auf ungewöhnlichen Portnummern betreiben. Wer nur die vermeintlich typischen Ports 80, 443, 554, 8000 und 8080 überprüft, kann wichtige Schnittstellen übersehen.

Die Dienstnamen von Nmap nicht überbewerten

Nmap zeigt neben einer offenen Portnummer häufig einen vermuteten Dienstnamen an. Diese Bezeichnung darf nicht ungeprüft als tatsächliche Funktion des Geräts verstanden werden.

Nmap kennt eine Liste mit Portnummern und den Diensten, die üblicherweise darüber angeboten werden. Wenn beispielsweise Port 10000 offen ist, kann Nmap einen Namen wie snet-sensor-mgmt anzeigen.

Das bedeutet nicht automatisch, dass die Kamera tatsächlich genau diesen Dienst betreibt. Nmap sagt damit zunächst nur:

Für diese Portnummer ist mir üblicherweise dieser Dienst bekannt.

Bei einer Kamera kann der Hersteller denselben Port für eine vollkommen andere Funktion verwenden.

Auch ein offener Port 6668 wird teilweise als irc bezeichnet. Bei einer ELESION- oder Tuya-Kamera läuft dort normalerweise kein klassischer IRC-Chatserver. Es handelt sich vielmehr um einen herstellerspezifischen Dienst auf einer Portnummer, die Nmap aus einem anderen Zusammenhang kennt.

Entscheidend sind deshalb in erster Linie:

• Portnummer,
• TCP oder UDP,
• Zustand des Ports,
• Antwortverhalten des Geräts,
• bekannte Besonderheiten des Kameramodells.

Was bedeuten „open“, „closed“ und „open|filtered“?

Nmap kann unterschiedliche Zustände anzeigen.

open bedeutet, dass auf dem geprüften Port ein Dienst Verbindungen annimmt.

closed bedeutet, dass das Gerät erreichbar ist, auf diesem Port aber kein Dienst wartet.

filtered weist darauf hin, dass Nmap wegen einer Filterung oder fehlenden Antwort nicht sicher bestimmen kann, ob der Port offen ist.

Bei UDP-Scans erscheint häufig:

open|filtered

Das bedeutet, dass keine eindeutige Antwort eingegangen ist. Der Port kann offen sein, ein Filter kann die Antwort unterdrücken oder der betreffende UDP-Dienst antwortet auf die verwendete Anfrage schlicht nicht.

UDP-Port 3702 und ONVIF-Discovery prüfen

ONVIF verwendet für die automatische Gerätesuche üblicherweise WS-Discovery über UDP-Port 3702.

Dieser Port kann gezielt getestet werden:

sudo nmap -sU -p 3702 192.168.178.xxx

Für den UDP-Scan verlangt macOS in der Regel das Administratorpasswort.

Eine mögliche Ausgabe lautet:

3702/udp open|filtered ws-discovery

Das passt zu einer ONVIF-fähigen Kamera, ist allein aber noch kein endgültiger Funktionsnachweis.

Wird UDP-Port 3702 ausdrücklich als geschlossen angezeigt und sind auch keine anderen ONVIF-Hinweise vorhanden, sinkt die Wahrscheinlichkeit, dass die Kamera über eine standardmäßige ONVIF-Suche gefunden werden kann.

Ein typisches Ergebnis einer 7Links-Kamera

Bei einer der untersuchten 7Links-Kameras ergab der Portscan folgendes Bild:

554/tcp   open
6668/tcp  open
10000/tcp open

Das war ausgesprochen aufschlussreich:

• Port 554 deutete auf einen vorhandenen RTSP-Stream hin.
• Port 10000 erwies sich als ONVIF-Port der Kamera.
• Port 6668 passte zum Tuya- beziehungsweise ELESION-Umfeld.

Ein zusätzlicher UDP-Test zeigte:

3702/udp open|filtered ws-discovery

Damit waren sowohl RTSP als auch Anzeichen für ONVIF vorhanden.

Trotzdem ließ sich die Kamera in UGOS nicht per ONVIF abspeichern. Beim abschließenden Schritt erschien erneut der bekannte interne Serverfehler.

Der offene RTSP-Port zeigte jedoch, dass noch ein anderer Weg vorhanden sein musste.

Ein offener RTSP-Port verrät noch nicht die vollständige Adresse

Wenn Nmap folgendes Ergebnis liefert:

554/tcp open rtsp

bedeutet das zunächst nur:

Auf Port 554 wartet ein RTSP-Server.

Damit ist aber noch nicht bekannt, unter welcher vollständigen Adresse der gewünschte Videostream erreichbar ist.

Eine RTSP-Adresse kann beispielsweise so aussehen:

rtsp://BENUTZER:PASSWORT@192.168.178.100:554/live/ch0

Bei einer anderen Kamera kann sie lauten:

rtsp://BENUTZER:PASSWORT@192.168.178.100:554/videoMain

Oder sie verwendet einen vollkommen anderen Pfad.

Der Teil hinter der Portnummer ist hersteller- und modellspezifisch.

Deshalb ist es selten sinnvoll, wahllos Dutzende vermeintlich gebräuchliche Stream-Adressen auszuprobieren. Besser ist es, folgende Informationsquellen zu nutzen:

• Dokumentation des Herstellers,
• Webinterface der Kamera,
• ONVIF-Medienprofile,
• Konfiguration einer bereits funktionierenden NVR-Verbindung,
• gezielte Diagnosewerkzeuge.

FOSCAM-Kameras: ungewöhnliche Ports 88 und 888

Besonders interessant wurde die Untersuchung der vorhandenen FOSCAM-Kameras.

Zunächst prüfte ich lediglich die üblichen Verdächtigen wie 80, 443, 554, 8000 und 8080. Dabei erschien teilweise nur Port 443.

Ein vollständigerer Nmap-Test zeigte bei mehreren FOSCAM-Kameras jedoch folgendes Muster:

88/tcp   open
443/tcp  open
888/tcp  open

Bei diesen Kameras sind insbesondere Port 88 und Port 888 interessant. FOSCAM verwendet abhängig vom Modell und von der Konfiguration teilweise Port 88 für Web-, ONVIF- oder RTSP-nahe Dienste.

Für den Hauptstream funktionierte bei den getesteten Kameras folgendes Schema:

rtsp://BENUTZER:PASSWORT@IP-ADRESSE:88/videoMain

Ein Beispiel mit erfundenem Passwort:

rtsp://admin:meinpasswort@192.168.178.194:88/videoMain

Für den kleineren Nebenstream kommt bei entsprechenden Modellen folgender Pfad infrage:

/videoSub

Die vollständige Adresse lautet dann beispielsweise:

rtsp://admin:meinpasswort@192.168.178.194:88/videoSub

Diese Adressen ließen sich direkt in UGOS Überwachung eintragen. Die Livebilder erschienen sofort, obwohl die ONVIF-Einrichtung derselben Kameras zuvor mit einem internen Serverfehler gescheitert war.

RTSP-Adressen mit Zugangsdaten schützen

Eine vollständige RTSP-Adresse kann Benutzername und Passwort im Klartext enthalten:

rtsp://BENUTZER:PASSWORT@IP-ADRESSE:PORT/PFAD

Solche Adressen sollten nicht unverändert in Screenshots, öffentlichen Artikeln oder Forenbeiträgen veröffentlicht werden.

Für eine Dokumentation kann stattdessen folgendes neutrale Schema verwendet werden:

rtsp://BENUTZER:PASSWORT@192.168.178.xxx:554/STREAM-PFAD

Auch lokal sollte für Kameras kein triviales Standardpasswort verwendet werden. Wenn die Kamera die Einrichtung eines gesonderten ONVIF- oder Streaming-Benutzers unterstützt, ist ein eigenes Konto mit den notwendigen und nicht darüber hinausgehenden Rechten vorzuziehen.

VLC als unabhängiges Testwerkzeug

Wer mit RTSP-Streams arbeitet, sollte den kostenlosen VLC Media Player installiert haben.

In VLC kann eine Netzwerkadresse direkt geöffnet werden. Auf dem Mac geschieht das über den Menüpunkt zum Öffnen eines Netzwerkstreams. Dort wird die vollständige RTSP-Adresse eingetragen.

Wenn das Kamerabild in VLC erscheint, steht fest, dass mehrere grundlegende Bestandteile funktionieren:

• Die Kamera ist im Netzwerk erreichbar.
• Der verwendete Port ist richtig.
• Der Stream-Pfad stimmt.
• Benutzername und Passwort werden akzeptiert.
• Die Kamera liefert tatsächlich Videodaten.

Funktioniert der Stream in VLC, aber nicht in UGOS oder einem NVR, liegt das Problem mit hoher Wahrscheinlichkeit bei der Überwachungssoftware, ihrer Konfiguration oder der Unterstützung des verwendeten Videoformats.

Damit wird die Fehlersuche erheblich übersichtlicher.

Mainstream und Substream unterscheiden

Viele Kameras stellen mindestens zwei Videostreams bereit.

Der Mainstream verwendet normalerweise die höchste Auflösung und eine höhere Bitrate. Er eignet sich für Aufzeichnungen und die großformatige Einzelansicht.

Der Substream besitzt eine geringere Auflösung und Bitrate. Er benötigt weniger Netzwerkbandbreite und Rechenleistung und eignet sich besonders für:

• Mehrfachansichten,
• Fernzugriff über langsamere Verbindungen,
• ältere Netzwerkrekorder,
• kleine Vorschaubilder,
• Geräte mit begrenzter Decoderleistung.

Ein älterer NVR kann möglicherweise den Substream darstellen, obwohl er mit der hohen Auflösung oder dem Codec des Mainstreams überfordert ist.

Deshalb sollte bei Kompatibilitätsproblemen geprüft werden, ob sich die Kamera auf H.264 umstellen und mit einer niedrigeren Auflösung, Bildrate oder Bitrate betreiben lässt.

Die Bildrate ist allerdings nicht dasselbe wie die Auflösung. Eine Reduzierung von 20 auf 15 Bilder pro Sekunde senkt die Datenmenge, verändert aber nicht die Anzahl der Bildpunkte. Für einen älteren Decoder kann die eigentliche Auflösung entscheidender sein.

Video ohne Audio verwenden

Wenn kein Ton benötigt wird, kann bei geeigneten Kameras als Videotyp ausschließlich „Video-Stream“ anstelle von „Video und Audio“ gewählt werden.

Das hat mehrere Vorteile:

• geringere Datenmenge,
• weniger mögliche Codec-Probleme,
• einfachere Kompatibilität mit älteren NVRs,
• kein unnötiges Aufzeichnen von Gesprächen oder Umgebungsgeräuschen.

Gerade bei einer Außenkamera, deren Ton nicht benötigt wird, ist ein reiner Videostream häufig die sinnvollere Einstellung.

H.264 ist für Fremdsysteme oft die sicherste Wahl

Moderne Kameras unterstützen häufig H.265 oder herstellerspezifische Erweiterungen wie H.264+ und H.265+. Diese Verfahren können Bandbreite und Speicherplatz sparen.

Bei älteren Netzwerkrekordern und gemischten Kamerasystemen bietet H.264 jedoch häufig die größte Kompatibilität.

Wenn ein NVR eine Kamera findet und sogar eine erfolgreiche Verbindung meldet, aber trotzdem kein Bild darstellt, sollten deshalb folgende Einstellungen geprüft werden:

• Videocodierung auf H.264,
• H.264+ deaktiviert,
• gegebenenfalls Hauptprofil durch ein kompatibleres Profil ersetzen,
• Auflösung des Substreams reduzieren,
• Bildrate beispielsweise auf 15 Bilder pro Sekunde senken,
• I-Frame-Intervall an die Bildrate anpassen,
• Audio abschalten, wenn es nicht benötigt wird.

Diese Änderungen garantieren keine erfolgreiche Darstellung. Sie beseitigen aber mehrere typische Ursachen für Decoderprobleme.

Eine unbekannte China-Kamera als Beispiel

Auch eine ältere chinesische Kamera erwies sich als interessantes Untersuchungsobjekt.

Nmap zeigte unter anderem:

554/tcp   open  rtsp
8080/tcp  open

Auf Port 8080 antwortete ein Webserver mit der Bezeichnung:

Private-Webs

Dieser leitete auf /index.asp um, um dort anschließend einen 404-Fehler anzuzeigen.

Willkommen in der gelegentlich etwas eigenwilligen Welt chinesischer OEM-Firmware.

Port 554 belegte immerhin, dass ein RTSP-Dienst vorhanden war. Das eigentliche Problem bestand nur noch darin, den richtigen Stream-Pfad zu ermitteln.

Bei manchen IPC365-ähnlichen Kameras kommen beispielsweise Pfade wie

/live/ch0

vor. Das muss aber für das konkrete Modell geprüft werden. Ein Pfad, der bei einer äußerlich identischen Kamera funktioniert, muss bei einer anderen Firmware nicht zwangsläufig vorhanden sein.

Port 6668 als Hinweis auf Tuya- und ELESION-Geräte

Bei mehreren Smart-Home-Geräten und Kameras aus dem Tuya- beziehungsweise ELESION-Umfeld fanden wir einen offenen TCP-Port 6668.

Ein typisches Ergebnis sah folgendermaßen aus:

PORT     STATE SERVICE
6668/tcp open  tcpwrapped

Ein solcher Fund genügt nicht, um das genaue Gerätemodell zu bestimmen. In Verbindung mit einem Gerätenamen wie ESP-..., einer Espressif-MAC-Adresse und der Verwendung im 2,4-GHz-WLAN ist er aber ein brauchbarer Hinweis auf ein Smart-Home- oder Tuya-Gerät.

Für die grobe Inventarisierung eines großen Heimnetzes kann eine solche Einordnung bereits ausreichen. Nicht jedes einzelne Leuchtmittel, Heizungsventil oder jeder Zwischenstecker muss bis auf die letzte Firmwareversion untersucht werden.

ONVIF-Profile und RTSP-Adresse direkt auslesen

Wenn eine Kamera über ONVIF erreichbar ist, kann sie nach ihren verfügbaren Medienprofilen und den dazugehörigen Stream-Adressen gefragt werden.

Das ist wesentlich zuverlässiger, als zahlreiche mögliche RTSP-Pfade auf Verdacht auszuprobieren.

Für unsere Tests richteten wir auf dem Mac ein kleines Node.js-Projekt ein. Node.js und npm wurden über Homebrew installiert. Danach wurde im Benutzerverzeichnis das Arbeitsverzeichnis angelegt:

~/onvif-test

In diesem Ordner wurde ein npm-Projekt initialisiert und das Paket onvif installiert.

Ein kleines Skript namens kamera.js stellte anschließend eine ONVIF-Verbindung zur Kamera her, fragte die vorhandenen Medienprofile ab und ließ sich die RTSP-Adressen ausgeben.

Bei einer 7Links-Kamera führte das zu folgendem Ergebnis:

ONVIF-Verbindung erfolgreich.

Gefundene Profile: 2

Profil 1
Name:  PROFILE_000
Token: PROFILE_000

Profil 2
Name:  PROFILE_001
Token: PROFILE_001

RTSP: rtsp://192.168.178.79/V_ENC_000

Damit war der bisher unbekannte Stream-Pfad eindeutig gefunden:

/V_ENC_000

Für die manuelle Einbindung in UGOS wurde daraus:

rtsp://BENUTZER:PASSWORT@192.168.178.79:554/V_ENC_000

Das Livebild erschien anschließend sofort.

Die vollständige Einrichtung des Node.js-Projekts und die erfolgreiche Integration der drei 7Links ZX-5761 werden in einem eigenen Beitrag ausführlich beschrieben.

Auch professionelle Kameras geben ihre Profile per ONVIF aus

Bei einer ANNKE I51DW funktionierte die ONVIF-Abfrage ebenfalls. Die Kamera meldete zwei Profile:

Profil 1
Name:  mainStream
Token: Profile_1

Profil 2
Name:  subStream
Token: Profile_2

Die zugehörigen RTSP-Adressen lauteten:

rtsp://192.168.178.182/Streaming/Channels/101?transportmode=unicast&profile=Profile_1

und:

rtsp://192.168.178.182/Streaming/Channels/102?transportmode=unicast&profile=Profile_2

Das entspricht der bei Hikvision- und verwandten ANNKE-Kameras üblichen Unterscheidung:

• /Streaming/Channels/101 für den Hauptstream,
• /Streaming/Channels/102 für den Substream.

Diese sauber abrufbaren Profile und die umfangreichen Konfigurationsmöglichkeiten des Webinterfaces zeigen, wie viel einfacher die Einbindung wird, wenn ein Hersteller lokale Standards vernünftig implementiert und nicht ausschließlich auf eine Cloud-App setzt.

Der Medien-Port eines NVR ist nicht automatisch der RTSP-Port

Manche Netzwerkrekorder bieten bei der Einrichtung einer ONVIF-Kamera zusätzlich die Eingabe eines Medien- oder Server-Ports an.

Dabei muss vorsichtig unterschieden werden:

• Der ONVIF-Port dient der Geräteerkennung und dem Austausch der Konfigurationsdaten.
• Der RTSP-Port transportiert normalerweise den Videostream.
• Ein herstellerspezifischer Server- oder Medien-Port kann für proprietäre Kommunikation verwendet werden.

Wenn der NVR eine Kamera über ONVIF findet, ermittelt er die Stream-Adresse normalerweise aus den ONVIF-Profilen. Das willkürliche Eintragen des RTSP-Ports in ein Feld für einen herstellerspezifischen Medien-Port hilft deshalb nicht zwangsläufig.

Ein alter NVR kann eine Kamera sogar mit einem grünen Verbindungspunkt als erfolgreich angemeldet anzeigen und trotzdem kein Bild darstellen. In diesem Fall können Anmeldung und ONVIF-Kommunikation funktionieren, während der Decoder des NVR mit Auflösung, Videoprofil oder Codec des Streams nicht zurechtkommt.

Typischer Diagnoseablauf für eine unbekannte Kamera

Aus unseren Versuchen hat sich folgender Ablauf als sinnvoll erwiesen:

1. IP-Adresse der Kamera in der FRITZ!Box feststellen.
2. Prüfen, ob die Kamera ein Webinterface besitzt.
3. Hersteller-App beziehungsweise Weboberfläche nach ONVIF- und RTSP-Einstellungen durchsuchen.
4. Gegebenenfalls ONVIF aktivieren und einen eigenen Benutzer einrichten.
5. Die gebräuchlichsten TCP-Ports mit Nmap untersuchen.
6. Bei Bedarf einen vollständigen TCP-Portscan durchführen.
7. UDP-Port 3702 auf WS-Discovery prüfen.
8. Bei offenem Port 554 den RTSP-Pfad in der Dokumentation suchen.
9. Falls ONVIF funktioniert, Profile und Stream-URI direkt auslesen.
10. Die vollständige RTSP-Adresse zunächst mit VLC testen.
11. Erst danach den geprüften Stream in UGOS oder den NVR eintragen.
12. Haupt- und Substream getrennt testen.
13. Bei Darstellungsproblemen H.264, geringere Auflösung und eine niedrigere Bildrate ausprobieren.

Dieser Ablauf ist wesentlich zielgerichteter als das wahllose Ausprobieren zahlreicher Stream-Adressen.

Eine einfache Kompatibilitätsmatrix hilft beim Überblick

Bei einem gemischten Kamerabestand lohnt es sich, die Ergebnisse zu dokumentieren.

Eine einfache Tabelle kann beispielsweise folgende Spalten enthalten:

Kamera	IP-Adresse	ONVIF-Port	RTSP-Port	Stream-Pfad	UGOS ONVIF	UGOS RTSP	vorhandener NVR
7Links ZX-5110	festgelegt	modellabhängig	vorhanden	nicht benötigt	funktioniert	nicht benötigt	problematisch
7Links ZX-5761	festgelegt	10000	554	/V_ENC_000	Serverfehler	funktioniert	funktioniert
FOSCAM-Kameras	festgelegt	modellabhängig	teilweise 88	/videoMain	Serverfehler	funktioniert	funktioniert
ANNKE I51DW	192.168.178.182	80	554	/Streaming/Channels/101	funktioniert	funktioniert	Verbindung, aber kein Bild am alten NVR
7Links ZX-5858	festgelegt	nicht gefunden	geschlossen	nicht vorhanden	nicht möglich	nicht möglich	nicht möglich

Eine solche Dokumentation erspart später viel Arbeit. Nach einigen Monaten weiß man sonst zwar noch, dass eine Kamera irgendwann eingebunden wurde, aber nicht mehr, welcher Port, welches Profil oder welcher Stream-Pfad dafür erforderlich war.

Was ein guter Hersteller dokumentieren sollte

Nach den bisherigen Versuchen würde ich eine Kamera nicht mehr allein aufgrund eines großen ONVIF-Aufdrucks kaufen.

Wesentlich interessanter sind klare Angaben zu folgenden Punkten:

• unterstütztes ONVIF-Profil,
• ONVIF-Port,
• Einrichtung eines ONVIF-Benutzers,
• RTSP-Port,
• vollständiger Pfad des Hauptstreams,
• vollständiger Pfad des Substreams,
• verfügbare Auflösungen,
• unterstützte Videocodecs,
• lokaler Betrieb ohne Cloud,
• Kompatibilität mit Fremd-NVRs.

Eine Kamera mit einem sauber dokumentierten lokalen Videostream ist für ein offenes Überwachungssystem häufig wertvoller als ein vermeintlich besonders intelligentes Modell, das praktisch nur über die Cloud-App seines Herstellers funktioniert.

Fazit: Erst untersuchen, dann aufgeben

Ein gescheiterter ONVIF-Versuch bedeutet nicht automatisch, dass eine IP-Kamera nicht mit UGOS, einem NAS oder einem anderen NVR verwendet werden kann.

Die wichtigsten Erkenntnisse unserer Tests lauten:

• ONVIF-Kompatibilität ist nicht universell.
• Eine Kamera kann mit einem NVR funktionieren und von einem anderen abgelehnt werden.
• Ein interner Serverfehler in UGOS schließt einen funktionierenden RTSP-Stream nicht aus.
• Nmap zeigt, welche TCP- und UDP-Dienste eine Kamera anbietet.
• Die von Nmap angezeigten Dienstnamen sind nur Vermutungen.
• Port 554 weist häufig auf RTSP hin, verrät aber nicht den vollständigen Stream-Pfad.
• ONVIF kann den tatsächlichen RTSP-Pfad direkt ausgeben.
• VLC eignet sich hervorragend zur unabhängigen Kontrolle eines Streams.
• H.264 und ein kleinerer Substream erhöhen die Kompatibilität mit älteren NVRs.
• Eine gute Dokumentation der ermittelten Ports und Pfade spart später viel Zeit.

Die sinnvollste Reihenfolge lautet deshalb:

Kamera untersuchen, Stream ermitteln, mit VLC testen und erst danach in die gewünschte Überwachungssoftware eintragen.

Auf diese Weise lassen sich selbst ältere, preiswerte oder zunächst widerspenstige Kameras häufig noch sinnvoll weiterverwenden.

Im nächsten Teil der Artikelserie geht es um die lokale KI-Erkennung von UGOS. Dabei analysiert nicht die Kamera, sondern das UGREEN-NAS selbst die Videostreams und unterscheidet unter anderem zwischen Personen, Fahrzeugen und Haustieren.