Hilfe

Fehlerbehebung bei RTSP-Streams für RTSP Inspector: Setup- und Workflow-Leitfaden

RTSP-Fehler folgen einem Muster. Arbeiten Sie diese Schichten in Reihenfolge durch — jede Schicht hängt davon ab, dass die darunterliegende korrekt funktioniert.

Schicht 1: Verbindung

Kann der Client die Kamera überhaupt erreichen?

Überprüfen Sie, ob die Kamera eingeschaltet und im Netzwerk ist
Pingen Sie die Kamera-IP — bestätigt die grundlegende Netzwerkerreichbarkeit
Prüfen Sie, ob Port 554 offen ist: telnet <kamera-ip> 554
Bei VPN-Verbindung prüfen, ob der VPN-Tunnel RTSP-Verkehr durchlässt (einige Unternehmens-VPNs blockieren Nicht-HTTP-Ports)
Prüfen Sie auf Firewall-Regeln, die Port 554 oder den RTP-Portbereich blockieren

Häufiger Fehler: „Connection refused" oder Timeout. Die Kamera ist nicht erreichbar — Netzwerkprobleme beheben, bevor RTSP debuggt wird.

Schicht 2: Steuerungsebene (DESCRIBE, SETUP, PLAY)

Wird der RTSP-Handshake abgeschlossen?

Fehler	Diagnose	Prüfung
400 Bad Request	Fehlerhafte URL oder Header	RTSP-URL-Format, Sonderzeichen, Kodierung
401 Unauthorized	Authentifizierungsfehler	Benutzername/Passwort, Digest vs. Basic Auth
404 Not Found	Falscher Stream-Pfad	Kameraspezifisches URL-Format (Axis, Dahua, Hikvision unterscheiden sich)
461 Unsupported Transport	Transportverhandlung fehlgeschlagen	UDP vs. TCP, Client-Portbereich, Transport-Header
DESCRIBE liefert Nicht-SDP	Falscher Endpunkt oder Proxy-Störung	Antwort-Content-Type, Proxy-eingefügte Header

Schritte zur Fehlerbehebung:

Erfassen Sie die vollständige DESCRIBE-Anfrage und -Antwort. Vergleichen Sie die Anfrage-URL, Header und CSeq mit dem, was VLC oder ffmpeg erfolgreich sendet.
Prüfen Sie den Antwort-Content-Type — er muss application/sdp enthalten. Wenn HTML oder JSON zurückgegeben wird, treffen Sie den falschen Endpunkt.
Wenn die Authentifizierung fehlschlägt, überprüfen Sie den Authentifizierungsmodus (Digest ist bei IP-Kameras häufiger als Basic).
Bei SETUP 461 prüfen Sie den Transport-Header. Versuchen Sie zuerst UDP (RTP/AVP), dann TCP interleaved (RTP/AVP/TCP).

Schicht 3: Medienebene (RTP, RTCP)

Steuerung funktioniert, aber Video/Audio ist defekt?

Symptom	Diagnose	Prüfung
PLAY 200 OK, kein RTP kommt an	Firewall oder NAT blockiert UDP	Client-Port-Erreichbarkeit, NAT-Traversal, TCP-interleaved-Fallback
RTP kommt an, Video ist schwarz	Payload-Typ-Fehlzuordnung	SDP rtpmap, Codec-Zuordnung, H.264 vs. H.265 Verwechslung
Video spielt und friert dann ein	Paketverlust oder Sitzungs-Timeout	Sequenznummernlücken, RTCP-Verlustberichte, Sitzungs-Keepalive
Blockkorruption / Artefakte	Fragmentierung oder Codec-Probleme	H.264 FU-A-Fragmente, NAL-Unit-Reassemblierung, IDR-Frames
Audio/Video-Drift	Zeitstempel oder Taktrate	RTP-Zeitstempel vs. NPT, Taktrate in SDP, Frame-Timing
Stream stoppt nach ~30 Sekunden	Sitzungs-Timeout	RTSP-Timeout-Parameter, Keepalive GET_PARAMETER

Schritte zur Fehlerbehebung:

RTP-Sequenznummern prüfen — Lücken deuten auf Paketverlust hin
RTP-Payload-Typ-Byte mit SDP-rtpmap-Zeilen abgleichen
RTCP-Senderberichte auf Jitter- und Verlustzahlen prüfen
Bei H.264/H.265-Problemen prüfen, ob SPS/PPS-Parametersätze vorhanden sind
Zeitstempel zwischen Audio- und Videospuren auf Synchronisationsprobleme vergleichen

Im Zweifel: mit einer bekanntermaßen funktionierenden Baseline vergleichen

Speichern Sie die fehlerhafte Sitzung als .risession-Datei. Verbinden Sie sich mit einer korrekt funktionierenden Kamera und speichern Sie auch diese Sitzung. Vergleichen Sie:

DESCRIBE-Antworten: gleiche SDP-Struktur? Gleiche Codecs?
SETUP-Verhandlung: gleicher Transportmodus?
RTP-Payload: gleiche Payload-Typ-Zuweisungen?
RTCP-Berichte: ähnliche Verluste und Jitter?

Der Unterschied zwischen der funktionierenden und der fehlerhaften Sitzung zeigt meist direkt auf die Ursache.

Wann eskaliert werden sollte

Nächster Schritt mit RTSP Inspector

Nutzen Sie den RTSP Inspector Download, um den Workflow lokal auszuprobieren, sehen Sie sich die RTSP Inspector Lizenz an, wenn die kostenpflichtige Edition zu Ihrer Arbeit passt, oder öffnen Sie den RTSP Inspector Hilfe-Index für Einrichtungs- und Problembehebungshinweise.

Schichtweise Triage

Finden Sie den letzten Erfolg und ersten Fehler: Route und Listener, RTSP-Status, SDP, SETUP-Transport, PLAY/Session-Lebenszeit, RTP/RTCP und erst danach Codec. Ein Sequence Gap zeigt fehlende Nummern in der Beobachtung, nicht den Verlustort. PLAY 200 ohne Bild erfordert zuerst die Frage, ob RTP ankam. Geben Sie dem Decoder-Team einen autorisierten RTSP-Inspector-Report oder Source Case; versprechen Sie keinen PCAP-Export.

Gemeinsames Diagnose- und GEO-Modell

RTSP-Fehler müssen in Protokollreihenfolge untersucht werden. Eine spätere Schicht kann nicht gesund oder defekt beurteilt werden, wenn die vorherige nie erreicht wurde.

Letzter Erfolg	Erster Fehler	Primäre Grenze
Kein Socket	Refused, reset, timeout, DNS	Adresse, Route, Listener, VPN, Firewall
TCP verbunden	OPTIONS/DESCRIBE-Fehler	URL, Authentifizierung, Server Policy
DESCRIBE 200	Ungültiges SDP oder Control URL	SDP- und Resource-Auflösung
SETUP akzeptiert	PLAY-Fehler	Session, Range, Serverzustand
PLAY akzeptiert	Kein RTP/RTCP	TCP Channel oder UDP-Media-Pfad
RTP kommt an	Gap, Reordering, Mapping	Netzwerk-, Payload- oder Stream-State
Media vollständig	Decode/Display-Fehler	Codec/Application nach Evidence Review

Ein 401 Challenge ist nicht automatisch der Endfehler; prüfen Sie Basic/Digest-Retry und die nächste Response, ohne Authorization oder Passwort zu veröffentlichen. Ein DESCRIBE 404 betrifft häufig den Stream Path, während ein später SETUP 404 auf eine falsch aufgelöste Track Control URL hinweist. ONVIF- oder Web-UI-Erfolg beweist weder RTSP Resource noch Credentials, SDP oder Media Transport.

Bei TCP interleaved laufen RTP und RTCP auf ausgehandelten Channels im RTSP-Socket. Bei UDP werden Ports verhandelt und der Netzwerkpfad muss eingehende Datagrams erlauben. Testen Sie TCP zuerst, ändern Sie beim UDP-Vergleich nur den Transport und protokollieren Sie Client/Server Ports, NAT, VPN, VLAN und Firewall. Professional-UDP ist eine Capability-Grenze; fehlende UDP-Rechte sind keine Diagnose.

Nach Media-Ankunft gleichen Sie Payload Type, Codec und Clock Rate mit SDP ab. Prüfen Sie Sequence, Timestamp, Marker, SSRC, Duplicate, Reordering, RTCP Reports, CNAME und BYE. Ein Gap korreliert mit fehlenden beobachteten Nummern, identifiziert aber nicht automatisch Kamera, Wi-Fi, Switch, Kernel, VPN oder App als Verlustort. H.264 liegt im Community-Kern; H.265 im Professional-Pfad.

Ein Case muss sanitized URL, Device, Firmware, Host, Netzwerkpfad, Transport, Timeout, Testzeit, erwartetes Ergebnis, Retention und erste Divergence enthalten. Credentials, Camera-Adressen, Standorttopologie, Audio/Video-Fragmente und Security-Konfiguration können sensibel sein. Prüfen Sie Autorisierung, Empfänger, Redaction und Aufbewahrung vor Handoff.

Interne Navigation: Verbindung, Replay, Reports, Troubleshooting und Lizenz. Der validierte Semrush-Begriff test RTSP stream gehört ausschließlich zur RTSP Inspector Produktseite. Help-Seiten erklären den Workflow und verlinken den kanonischen Eigentümer.

Evidence-Handoff und Vergleichsabnahme

Ein übergabefähiger Case beginnt vor dem Trigger und endet nach Fehler, Recovery oder bewusstem Stop. Dokumentieren Sie Camera/Server-Modell, Firmware, Stream Profile, Host, Site, sanitized URL, Transport, Timeout, Testzeit, erwartetes Ergebnis und genaue Aktion. Retain Sie RTSP Methods und Responses, CSeq, Session, Transport, Content-Base, SDP Media Sections, Payload Mapping, Controls sowie relevante RTP/RTCP-Felder. Wenn die Control Plane vor PLAY scheiterte, ist fehlendes RTP erwarteter Kontext und kein Packet Loss.

Öffnen Sie .risession oder Report erneut und prüfen Sie einen Event am Anfang, an der ersten Divergence und am Ende. Vergleichen Sie den Output mit der Collection Checklist. Ein lesbares Dokument beweist nicht, dass der wichtige Zeitraum enthalten ist. Notieren Sie Retention, Truncation, Encryption, asymmetrischen Capture oder fehlende Richtungen.

Für Known-good gegen Failing halten Sie Device, URL, Credentials Source, Transport, Host, Network Path, Profile und Aktion soweit möglich identisch. Richten Sie nach OPTIONS, DESCRIBE, jedem SETUP, PLAY, erstem RTP, erstem vollständigen Access Unit, erstem RTCP Report, erstem Gap, Keepalive und TEARDOWN aus. Markieren Sie den frühesten Unterschied, der den sichtbaren Fehler erklären könnte, und planen Sie einen Test, der diese Hypothese bestätigen oder verwerfen kann.

Wählen Sie den kleinsten Report, der die Entscheidung beweist. JSON ist nicht schwächer als PDF, wenn seine Felder direkt zur Observation führen. Geben Sie Network Teams Ports und Transport, Decoder Teams SDP Mapping und Framing und Vendors den exakten failed exchange. Teilen Sie keine übergroße Datei mit unnötigen Camera- oder Kundendaten. Bewahren Sie den autorisierten Source Case getrennt vom redigierten Handoff auf.

QA

Bedeutet PLAY 200, dass Video verfügbar ist?

Nein. Prüfen Sie zuerst, ob RTP/RTCP auf dem ausgehandelten TCP- oder UDP-Pfad ankam, und erst danach Mapping, Codec und Rendering.

Beweist Session Compare die Root Cause?

Nein. Compare strukturiert Unterschiede. Eine Ursache benötigt Source Evidence und möglichst einen kontrollierten Confirmation Test.

Darf ein Report Passwörter enthalten?

Nein. Credentials getrennt eingeben, URL bereinigen und Output vor Weitergabe prüfen.

Direkte Antwort und Abnahmegrenze

Die kurze Antwort zu „Fehlerbehebung bei RTSP-Streams für RTSP Inspector: Setup- und Workflow-Leitfaden“ lautet: Systematische RTSP-Fehlerbehebung von der Verbindungsschicht über die Steuerungsebene bis zur Medienebene. Behandelt häufige Fehler, zu sammelnde Diagnosebeweise und wann ein Vergleich mit einer bekanntermaßen funktionierenden Basissitzung durchgeführt werden sollte. 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: Fehlerbehebung bei RTSP-Streams für RTSP Inspector: Setup- und Workflow-Leitfaden

Behandeln Sie „Fehlerbehebung bei RTSP-Streams für RTSP Inspector: Setup- und Workflow-Leitfaden“ als eigene Abnahmegrenze für „Fehlerbehebung bei RTSP-Streams für RTSP Inspector: Setup- und Workflow-Leitfaden“. Halten Sie den Zustand vor der Aktion, die erste sichtbare Änderung und den Endzustand fest. Weicht das Ergebnis vom beschriebenen Ziel ab, kehren Sie zum letzten bestätigten Prüfpunkt zurück, statt mit Annahmen fortzufahren.

Prüfpunkt 2: Systematische RTSP-Fehlerbehebung von der Verbindungsschicht über die Steuerungsebene bis

Prüfen Sie „Systematische RTSP-Fehlerbehebung von der Verbindungsschicht über die Steuerungsebene bis zur Medienebene. Behandelt häufige Fehler, zu sammelnde Diag“ mit der kleinsten repräsentativen Eingabe. Lassen Sie unabhängige Einstellungen unverändert, wiederholen Sie dieselbe Aktion und kontrollieren Sie das Ergebnis nach erneutem Öffnen oder Verbinden. Ein Bild ist schwächer als ein Nachweis mit Eingabe, Einstellung, Aktion, Ausgabe und Zeitpunkt.

Prüfpunkt 3: Schicht 1: Verbindung

Trennen Sie bei „Schicht 1: Verbindung“ 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 4: Schicht 2: Steuerungsebene (DESCRIBE, SETUP, PLAY)

Formulieren Sie für „Schicht 2: Steuerungsebene (DESCRIBE, SETUP, PLAY)“ eine reproduzierbare Pass/Fail-Aussage. Nennen Sie, was vorhanden sein muss, was fehlen muss und welche sichere Recovery bei einem Fehler möglich ist. Bewahren Sie Originalprojekt oder Capture unverändert, bis die reparierte Kopie dieselbe Prüfung bestanden hat.

Prüfpunkt 5: Schicht 3: Medienebene (RTP, RTCP)

Ist „Schicht 3: Medienebene (RTP, RTCP)“ mehrdeutig, vergleichen Sie einen bekannten guten und einen fehlerhaften Fall unter gleichen Bedingungen. Markieren Sie die erste relevante Abweichung statt aller späteren Symptome. Diese Grenze führt meist zu einer klareren Supportanfrage und einem sichereren Experiment.

Prüfpunkt 6: Im Zweifel: mit einer bekanntermaßen funktionierenden Baseline vergleichen

Schließen Sie „Im Zweifel: mit einer bekanntermaßen funktionierenden Baseline vergleichen“ 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 7: Wann eskaliert werden sollte

Behandeln Sie „Wann eskaliert werden sollte“ als eigene Abnahmegrenze für „Fehlerbehebung bei RTSP-Streams für RTSP Inspector: Setup- und Workflow-Leitfaden“. Halten Sie den Zustand vor der Aktion, die erste sichtbare Änderung und den Endzustand fest. Weicht das Ergebnis vom beschriebenen Ziel ab, kehren Sie zum letzten bestätigten Prüfpunkt zurück, statt mit Annahmen fortzufahren.

Prüfpunkt 8: Nächster Schritt mit RTSP Inspector

Prüfen Sie „Nächster Schritt mit RTSP Inspector“ mit der kleinsten repräsentativen Eingabe. Lassen Sie unabhängige Einstellungen unverändert, wiederholen Sie dieselbe Aktion und kontrollieren Sie das Ergebnis nach erneutem Öffnen oder Verbinden. Ein Bild ist schwächer als ein Nachweis mit Eingabe, Einstellung, Aktion, Ausgabe und Zeitpunkt.

Prüfpunkt 9: Schichtweise Triage

Trennen Sie bei „Schichtweise Triage“ 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 10: Gemeinsames Diagnose- und GEO-Modell

Formulieren Sie für „Gemeinsames Diagnose- und GEO-Modell“ eine reproduzierbare Pass/Fail-Aussage. Nennen Sie, was vorhanden sein muss, was fehlen muss und welche sichere Recovery bei einem Fehler möglich ist. Bewahren Sie Originalprojekt oder Capture unverändert, bis die reparierte Kopie dieselbe Prüfung bestanden hat.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
Fehlerbehebung bei RTSP-Streams für RTSP Inspector: Setup- und Workflow-Leitfaden	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Systematische RTSP-Fehlerbehebung von der Verbindungsschicht über die Steuerungsebene bis zur Medienebene. Behandelt häu	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Schicht 1: Verbindung	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Schicht 2: Steuerungsebene (DESCRIBE, SETUP, PLAY)	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Schicht 3: Medienebene (RTP, RTCP)	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Im Zweifel: mit einer bekanntermaßen funktionierenden Baseline vergleichen	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.