2026-06-01

RTSP-Kamera-Stream-Diagnose: Ein systematischer Workflow zur Fehlerbehebung von der Beschreibung bis zur Wiedergabe

RTSP-Kameraprobleme folgen normalerweise einem Muster: der Verbindungsschicht, der Kontrollschicht oder der Medienschicht. Dieser Diagnose-Workflow zeigt, welche Beweise gesammelt werden müssen, welche Protokollstufe fehlschlägt und wie SDP, RTP und RTCP gelesen werden, um den genauen Fehler zu lokalisieren.

Ausfälle von RTSP-Kameras erfordern kein Rätselraten. Das Protokoll ist geschichtet: "Verbindung (TCP/TLS), Steuerung (DESCRIBE/SETUP/PLAY) und Medien (RTP/RTCP). Wenn der Strom unterbrochen wird, ist eine dieser Schichten das Problem. Ihre Aufgabe ist es, herauszufinden, welches."

Das Drei-Schichten-Modell

Jedes RTSP-Problem fällt in einen von drei Bereichen. Beginnen Sie hier, bevor Sie sich mit bestimmten Fehlercodes befassen:

Schicht 1 – Verbindung: Kann der Client die Kamera überhaupt erreichen? TCP-Handshake, TLS-Aushandlung, Portfilterung, VPN-Routing. Wenn „telnet camera-ip 554“ keine Verbindung herstellt, ist alles andere von Bedeutung.

Schicht 2 – Steuerung: Verbindung funktioniert, aber RTSP-Befehle schlagen fehl. DESCRIBE gibt 400/404/401 zurück. SETUP gibt 461 zurück. PLAY gibt 453 zurück. Die Steuerungsebene weist Probleme auf Protokollebene auf: URL-Format, Authentifizierung, Transportaushandlung, Sitzungsverwaltung.

Ebene 3 – Medien: Die Steuerung funktioniert einwandfrei, aber Video/Audio ist fehlerhaft. RTP-Pakete kommen an, können aber nicht dekodiert werden. Zeitstempel driften. Frames sind beschädigt. RTCP meldet Verlust. Die Medienebene weist Probleme mit der Nutzlast, dem Codec oder der Netzwerkqualität auf.

Schnell-Triage-Tabelle

Symptom	Wahrscheinlich Schicht	Überprüfen Sie zuerst
"Verbindung abgelehnt"	Schicht 1	Port 554 erreichbar? Firewall-Blockierung?
400 Ungültige Anfrage bei DESCRIBE	Schicht 2	RTSP-URL-Format, Kodierung, Proxy-Header
401 Nicht autorisiert	Schicht 2	Digest-Authentifizierungsparameter, Benutzername/Passwort
461 Nicht unterstützter Transport	Schicht 2	UDP- vs. TCP-Transport, SETUP-Header
BESCHREIBUNG OK, SETUP OK, kein Video	Schicht 3	RTP-Nutzlasttyp, Codec-Zuordnung
Das Video wird abgespielt und friert dann ein	Schicht 3	Paketverlust, Keepalive, Sitzungs-Timeout
Audio und Video driften auseinander	Schicht 3	RTP-Zeitstempel, Taktfrequenz stimmt nicht überein

Die Beweise, die Sie sammeln müssen

Bevor Sie ein RTSP-Problem diagnostizieren, erfassen Sie diese fünf Beweisstücke:

Die vollständige DESCRIBE-Antwort – SDP teilt Ihnen mit, welche Spuren vorhanden sind, welche Codecs verwendet werden und welche Nutzlasttypen zugewiesen sind.
Die SETUP-Anfrage und -Antwort – Der Transport-Header zeigt UDP vs. TCP, Client-Ports und verschachtelte Kanal-IDs.
Die PLAY-Antwort – Bestätigt, dass die Sitzung aktiv ist und RTP fließt.
RTP-Paketbeispiele – Nutzlasttyp-Byte, Sequenznummern, Zeitstempel, SSRC.
RTCP-Sender-/Empfängerberichte – Anzahl der Paketverluste, Jitter, Verzögerung zwischen Ankunft.

Ohne diese, vermuten Sie. Bei ihnen ist der Fehler meist offensichtlich.

Ausführliche Anleitungen aus Versehen

Wann eskalieren sollte

Wenn alle drei Schichten überprüft werden – TCP stellt eine Verbindung her, RTSP-Befehle sind erfolgreich, RTP-Pakete kommen mit korrekten Nutzlasttypen und stabilen Zeitstempeln an –, das Video aber immer noch falsch aussieht, liegt das Problem wahrscheinlich in der Decoder- oder Anwendungsschicht und nicht im RTSP-Transport. Erfassen Sie an diesem Punkt ein kurzes PCAP, exportieren Sie einige Sekunden RTP und übergeben Sie es dem Decoder-Team.