2026-06-02

ONVIF funktioniert, aber die RTSP-URL schlägt fehl: Den echten Kamera-Stream-Pfad finden

Warum die ONVIF-Erkennung funktionieren kann, während der RTSP-Stream ausfällt, und wie man Kameraprofile, Medien-URLs, Authentifizierung, Transport und SDP-Beweise debuggt.

Es kommt häufig vor, dass eine IP-Kamera bei der ONVIF-Erkennung korrekt angezeigt wird, während die RTSP-URL immer noch fehlschlägt. Das Gerät ist im Netzwerk sichtbar, der Kameraname und das Modell werden erkannt, vielleicht werden sogar die Profile aufgelistet, aber der eigentliche Videostream öffnet sich nicht. Benutzer suchen nach „ONVIF funktioniert, aber RTSP schlägt fehl“, „Kamera entdeckt, aber kein RTSP-Video“ oder „So finden Sie die RTSP-URL von ONVIF“, weil der Erfolg der Erkennung den Eindruck erweckt, dass er den Streaming-Erfolg garantieren sollte.

Das ist nicht der Fall.

ONVIF und RTSP hängen in vielen Kamera-Workflows zusammen, sind jedoch nicht dasselbe Protokoll und beweisen nicht dasselbe. ONVIF kann Ihnen mitteilen, dass eine Kamera vorhanden ist, und möglicherweise ein Medienprofil bereitstellen. RTSP muss sich weiterhin authentifizieren, den Stream beschreiben, den Transport aushandeln, RTP-Tracks einrichten und Medienpakete zustellen.

RTSP Inspector konzentriert sich auf die zweite Hälfte: was tatsächlich passiert, wenn eine bestimmte RTSP-URL verwendet wird.

Was ONVIF beweist

Die Entdeckung von ONVIF kann Folgendes beweisen:

Die Kamera reagiert auf WS-Discovery.
Die Kamera stellt einen ONVIF-Dienstendpunkt bereit.
Der Client kann auf die Kameraverwaltungsschnittstelle zugreifen.
Die Kamera verfügt möglicherweise über ein oder mehrere Medienprofile.
Das Gerät kann Stream-URIs über ONVIF-Mediendienste melden.

Das ist nützlich, aber es ist nicht dasselbe wie der Nachweis, dass der RTSP-Stream funktioniert. Die ONVIF-Erkennung verwendet möglicherweise einen anderen Port, ein anderes Authentifizierungsverhalten und einen anderen Dienstpfad als RTSP.

Eine Kamera kann die ONVIF-Erkennung bestehen und dennoch RTSP nicht bestehen, weil:

RTSP ist in den Kameraeinstellungen deaktiviert.
Das ONVIF-Konto verfügt nicht über die RTSP-Berechtigung.
Der zurückgegebene Stream-URI ist unvollständig oder nur intern.
Der RTSP-Port wird durch eine Firewall blockiert.
Die Kamera benötigt TCP-Interleaved-Transport, aber der Client versucht es mit UDP.
Das Profil verweist auf H.265, aber der Client erwartet H.264.
Der NVR-Kanalpfad ist falsch.
Die Kamera gibt SDP zurück, sendet aber keine RTP-Pakete.

Der ONVIF-Stream-URI ist möglicherweise nicht direkt verwendbar

Einige Kameras geben über ONVIF einen RTSP-URI zurück, der verwendbar aussieht, aber noch geändert werden muss. Zum Beispiel:

rtsp://192.168.1.50/Streaming/Channels/101

The real usable URL may need:

ONVIF profile does not guarantee codec support

The symptom may be:

RTSP Inspector helps by separating the layers:

RTSP transport can fail after ONVIF succeeds

This is common when:

Authentication can differ between ONVIF and RTSP

You may see:

RTSP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="IP Camera", nonce="..."

obwohl die ONVIF-Erkennung funktioniert hat. Das bedeutet, dass der RTSP-Dienst nach Anmeldeinformationen fragt. Wenn der Client Anmeldeinformationen sendet und die Kamera weiterhin „401“ zurückgibt, überprüfen Sie die Kontoberechtigungen, die Digest-Authentifizierung, die URL-Kodierung und die Kanalrechte.

NVRs machen dies verwirrender, da das ONVIF-Gerät möglicherweise der NVR ist, während der RTSP-Stream-Pfad auf einen Kamerakanal hinter dem NVR verweist. Dem Konto ist es möglicherweise gestattet, den NVR abzufragen, jedoch nicht den Hauptstream von Kanal 1 zu streamen.

Verwirrung zwischen Mainstream und Substream

Viele Kameras stellen mehrere Profile zur Verfügung:

Hauptstream: hohe Auflösung, hohe Bitrate, oft H.265.
Substream: niedrigere Auflösung, niedrigere Bitrate, oft H.264.
Mobiler Stream: kleine Bildgröße und niedrigere Bildrate.

ONVIF gibt möglicherweise standardmäßig eines dieser Profile zurück. Die aus einem Forum oder einer Anbieter-PDF kopierte RTSP-URL verweist möglicherweise auf eine andere. Wenn der Hauptstream H.265 ist, der Client jedoch nur H.264 unterstützt, funktioniert der Substream möglicherweise, während der Hauptstream ausfällt.

Suchanfragen wie „RTSP-Hauptstream funktioniert nicht, Substream funktioniert“ gehören häufig zu dieser Kategorie. Das Problem ist nicht die Entdeckung. Dabei handelt es sich um Profilauswahl, Codec-Auswahl, Bitrate oder Transportverhalten.

So debuggen Sie ONVIF, aber RTSP schlägt fehl

Verwenden Sie eine mehrschichtige Checkliste:

Bestätigen Sie, dass der RTSP-Dienst der Kamera aktiviert ist.
Stellen Sie sicher, dass der RTSP-Port, normalerweise 554, vom Client aus erreichbar ist.
Holen Sie sich das ONVIF-Medienprofil und den Stream-URI.
Normalisieren Sie die RTSP-URL für den Netzwerkpfad, den Sie tatsächlich verwenden.
Fügen Sie die Anmeldeinformationen sorgfältig hinzu und kodieren Sie Sonderzeichen per URL.
Führen Sie RTSP „OPTIONS“ und „DESCRIBE“ aus.
Überprüfen Sie Authentifizierungsherausforderungen und -antworten.
Überprüfen Sie SDP auf Codec, Nutzlasttyp, Taktrate und Track-Control-URLs.
Vergleichen Sie den interleaved UDP- und TCP-Transport.
Bestätigen Sie, dass RTP-Pakete nach „PLAY“ eintreffen.
Überprüfen Sie die Kontinuität der RTP-Sequenz, die Zeitstempel und den Nutzlasttyp.
Testen Sie Haupt-Stream und Sub-Stream getrennt.

Diese Checkliste verhindert einen häufigen Fehler: den Erfolg der ONVIF-Erkennung als Beweis dafür zu betrachten, dass das Medien-Streaming automatisch funktionieren sollte.

Was der RTSP-Trace anzeigen soll

Ein gesunder RTSP-Flow sieht normalerweise so aus:

OPTIONS rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

DESCRIBE rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK
Content-Type: application/sdp

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
RTSP/1.0 200 OK
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

PLAY rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

Final diagnosis

Reproduzierbarer Nachweis für „ONVIF funktioniert, aber die RTSP-URL schlägt fehl: Den echten Kamera-Stream-Pfad finden“

Die direkte Antwort lautet: Eine Kamerastream-Störung wird nicht durch ein einzelnes Player-Fenster oder einen Statuscode bewiesen. Die belastbare Diagnose verbindet RTSP-Anfrage und Antwort, die ausgehandelte Transportart, eine gültige Session und anschließend RTP-Sequenznummern, Zeitstempel sowie RTCP-Belege. Beginnen Sie bei „ONVIF funktioniert, aber die RTSP-URL schlägt fehl: Den echten Kamera-Stream-Pfad finden“ an der Schicht, die dem sichtbaren Symptom am nächsten liegt, behalten Sie aber eine gemeinsame Zeitleiste, damit Steuerungs-, Netzwerk- und Decoderfehler nicht vermischt werden.

Erstellen Sie vor Änderungen an Kamera, Firewall oder VMS einen kleinen Ausgangstest. Notieren Sie die bereinigte RTSP-URL, Uhrzeit, Pfad, angeforderten Transport, Serverantwort und den Zeitpunkt des ersten Medienpakets. Testen Sie UDP und TCP interleaved getrennt, sofern das Gerät beides anbietet. Ändern Sie nicht gleichzeitig Pfad, Zugangsdaten und Transport. Sonst zeigt ein erfolgreicher zweiter Versuch nicht, welche Variable den Fehler beseitigt hat.

Prüfschicht	Zu sichernder Nachweis	Entscheidungsfrage
RTSP	Methode, Status, Header, CSeq und Session	Hat der Server genau diese Operation akzeptiert?
SDP	control, Payload-Typ, Clock Rate und Codec	Beschreibt der Server den erwarteten Medientrack?
Transport	client_port, server_port oder interleaved	Verwenden beide Seiten denselben Kanal?
RTP	SSRC, Sequenz, Timestamp und Marker	Kommen Medieneinheiten in erklärbarer Reihenfolge an?
RTCP	Sender Report, CNAME und BYE	Sind Uhr, Identität und Sitzungsende nachvollziehbar?
Decoder	SPS/PPS/VPS und Packetization Mode	Lassen sich die angekommenen Nutzdaten initialisieren?

Trennen Sie „keine Medien angekommen“ von „Medien angekommen, aber nicht decodierbar“. Fehlt RTP nach erfolgreichem SETUP und PLAY, prüfen Sie UDP-Pfad, NAT, Firewall und einen abweichenden Transport-Reply. RTP mit Sequenzlücken belegt Verlust oder Reordering. Eine lückenlose Folge ohne Bild verschiebt die Prüfung auf Payload-Typ, Clock Rate, Frame-Grenzen und H.264-/H.265-Parameter. Diese Grenze ist aussagekräftiger als eine allgemeine Player-Meldung.

Wie formuliert man eine zitierfähige Kurzantwort?

Nennen Sie in drei Sätzen die letzte erfolgreiche Operation, den ersten fehlgeschlagenen Beleg und den nächsten trennenden Test. Beispielstruktur: „DESCRIBE, SETUP und PLAY waren erfolgreich. An den angekündigten Client-Ports kam kein RTP an. Ein Test über TCP interleaved trennt UDP-Blockierung von einem falschen Medienpfad.“ Behaupten Sie keinen Kamera- oder Netzwerkdefekt ohne passende Antwort oder Paketbeleg.

Welche Angaben machen den Fehler reproduzierbar?

Sichern Sie OPTIONS, DESCRIBE, SETUP und PLAY samt SDP, Transport-Antwort und bereinigter Session-ID. Für Medien genügen zunächst SSRC, erste und letzte Sequenznummer, Clock Rate, Lückenanzahl und Aufnahmedauer. Vermerken Sie, ob VLC oder ein anderes VMS funktioniert. Das ist ein Differenztest, aber kein Beweis, dass der erfolgreiche Client jede Protokollgrenze korrekt behandelt.

Wann liegt der nächste Test auf Server- oder Clientseite?

Prüfen Sie den Server, wenn er eine Methode klar ablehnt, einen nicht vorhandenen control-Pfad liefert, das Transportangebot widersprüchlich beantwortet oder SSRC beziehungsweise Clock Rate ohne erklärten Übergang wechselt. Prüfen Sie den Client, wenn er einen alten Nonce wiederverwendet, Session-Header verliert, UDP anfordert ohne Ports zu öffnen oder jedes NAL-Ende als Access-Unit-Ende behandelt. Für Zwischenfehler bleiben Zeitstempel und Paketfolge unverzichtbar.

Wie wird der Bericht vor der Übergabe geprüft?

Wiederholen Sie den Test mit einer frischen Verbindung und vergleichen Sie beide Abläufe nur bis zur ersten Abweichung. Entfernen Sie Passwörter und vollständige Authorization-Werte. Verknüpfen Sie jede Aussage mit CSeq, Sequenznummer oder Timestamp. Der passende RTSP-Leitfaden erklärt angrenzende Schritte; RTSP Inspector dient als lokaler Arbeitsbereich zum Testen eines RTSP-Streams und zum Sammeln der Belege, ohne den Kamerastream zu einem öffentlichen Dienst hochzuladen.

Direkte Antwort und Abnahmegrenze

Die kurze Antwort zu „ONVIF funktioniert, aber die RTSP-URL schlägt fehl: Den echten Kamera-Stream-Pfad finden“ lautet: Warum die ONVIF-Erkennung funktionieren kann, während der RTSP-Stream ausfällt, und wie man Kameraprofile, Medien-URLs, Authentifizierung, Transport und SDP-Beweise debuggt. Behandeln Sie diese Aussage als zu prüfendes Ergebnis und nicht als Versprechen für jede Eingabe, jedes Gerät, jedes Projekt oder jede Umgebung. Ein vollständiges Ergebnis dokumentiert Ausgangszustand, exakte Aktion, sichtbare Ausgabe und die Bedingung, die den Abschluss in RTSP Inspector belegt.

Evidenzorientiertes Vorgehen

Beginnen Sie mit einem kleinen, wiederholbaren Fall, bevor Sie ein vollständiges Projekt verändern. Protokollieren Sie Anwendungsversion, Betriebssystem, Eingabe- oder Geräteidentität, relevante Einstellungen und erwartetes Ergebnis. Führen Sie eine bewusste Aktion aus, bewahren Sie den ersten unerwarteten Übergang und vergleichen Sie möglichst mit einem bekannten guten Lauf. Mehrere gleichzeitige Änderungen verdecken, welche Bedingung den Fehler erzeugt oder behoben hat.

Prüfpunkt 1: ONVIF funktioniert, aber die RTSP-URL schlägt fehl: Den echten Kamera-Stream-Pfad finden

Schließen Sie „ONVIF funktioniert, aber die RTSP-URL schlägt fehl: Den echten Kamera-Stream-Pfad finden“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 2: Warum die ONVIF-Erkennung funktionieren kann, während der RTSP-Stream ausfällt, und wie ma

Trennen Sie bei „Warum die ONVIF-Erkennung funktionieren kann, während der RTSP-Stream ausfällt, und wie man Kameraprofile, Medien-URLs, Authentifizierung, Transport u“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 3: Was ONVIF beweist

Schließen Sie „Was ONVIF beweist“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 4: Der ONVIF-Stream-URI ist möglicherweise nicht direkt verwendbar

Trennen Sie bei „Der ONVIF-Stream-URI ist möglicherweise nicht direkt verwendbar“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 5: ONVIF profile does not guarantee codec support

Schließen Sie „ONVIF profile does not guarantee codec support“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 6: RTSP transport can fail after ONVIF succeeds

Trennen Sie bei „RTSP transport can fail after ONVIF succeeds“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 7: Authentication can differ between ONVIF and RTSP

Schließen Sie „Authentication can differ between ONVIF and RTSP“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 8: Verwirrung zwischen Mainstream und Substream

Trennen Sie bei „Verwirrung zwischen Mainstream und Substream“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Prüfpunkt 9: So debuggen Sie ONVIF, aber RTSP schlägt fehl

Schließen Sie „So debuggen Sie ONVIF, aber RTSP schlägt fehl“ erst, wenn gespeichertes, exportiertes oder erneut geöffnetes Ergebnis weiterhin dem beobachteten Zustand entspricht. Vorübergehendes UI-Feedback hilft, dauerhafte Evidenz ist aber stärker. Dokumentieren Sie verbleibende Grenzen für die nächste Person.

Prüfpunkt 10: Was der RTSP-Trace anzeigen soll

Trennen Sie bei „Was der RTSP-Trace anzeigen soll“ eine Produktentscheidung von Grenzen des Betriebssystems, der Hardware, Quelldatei, Berechtigung oder Arbeitsweise. Bestätigen Sie zuerst, welche Schicht die Evidenz geliefert hat. So wird ein benachbartes Symptom nicht fälschlich zur bewiesenen Ursache.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
ONVIF funktioniert, aber die RTSP-URL schlägt fehl: Den echten Kamera-Stream-Pfad finden	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Warum die ONVIF-Erkennung funktionieren kann, während der RTSP-Stream ausfällt, und wie man Kameraprofile, Medien-URLs,	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Was ONVIF beweist	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Der ONVIF-Stream-URI ist möglicherweise nicht direkt verwendbar	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
ONVIF profile does not guarantee codec support	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
RTSP transport can fail after ONVIF succeeds	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren

Fehlerisolierung, Recovery und Übergabe

Stoppen Sie beim ersten fehlerhaften Übergang. Bewahren Sie Quelle, Projekt, Session oder Capture und erstellen Sie vor destruktiven Änderungen eine Kopie. Ändern Sie pro Experiment nur eine Variable. Ein kompletter erneuter Lauf nach mehreren Änderungen kann anders enden, ohne die Ursache zu erklären.

Unterscheiden Sie fehlende Evidenz von Evidenz für ein Fehlen. Eine leere Ansicht kann auf falsche Eingabe, Scope, Filter, Berechtigung, Gerät, Zeitbereich oder Projektzustand hinweisen. Beweisen Sie Aufnahme oder Import, bevor Sie Decoder, Editor, Bericht oder Export interpretieren.

Öffnen Sie vor der Übergabe das dauerhafte Artefakt erneut und prüfen Sie Anfang, Entscheidungsstelle und Ende. Dokumentieren Sie Version, Plattform, Konfiguration, Erwartung, Beobachtung und kleinste Reproduktion. Entfernen oder schwärzen Sie sensible Daten und prüfen Sie die Berechtigung des Empfängers.

Fragen und Antworten

Wie beginnt man am schnellsten zuverlässig?

Verwenden Sie den kleinsten repräsentativen Fall, notieren Sie das erwartete Ergebnis und ändern Sie nur eine Variable. Beweisen Sie den Grundpfad, bevor Filter, Effekte, Bearbeitungen, Automatisierung oder größere Quellen hinzukommen.

Welche Evidenz sollte gespeichert werden?

Bewahren Sie Eingabeidentität, Version, Plattform, Einstellungen, exakte Aktion, ersten unerwarteten Übergang und Endausgabe. Projekt, Session, Bericht oder Export müssen geschlossen und erneut geöffnet werden.

Wann sollte das Verfahren wiederholt werden?

Wiederholen Sie es nach relevanten Änderungen an Anwendung, Betriebssystem, Treiber, Firmware, Modell, Quelle oder Workflow. Behalten Sie den früher akzeptierten Fall als unveränderte Vergleichsbasis.

Wann ist die Aufgabe übergabefähig?

Wenn eine autorisierte zweite Person Eingabe und Aktion erkennt, dasselbe Ergebnis reproduziert, verbleibende Grenzen versteht und das gespeicherte Artefakt ohne undokumentierten lokalen Zustand öffnen kann.