2026-06-02

RTSP-Stream stoppt nach 30 Sekunden: Keepalive, Sitzungs-Timeout, NAT und Kamera-Leerlauf-Verbindungsabbrüche

Warum RTSP-Streams nach 30 Sekunden, 60 Sekunden oder ein paar Minuten stoppen und wie man Keepalive-Anfragen, Sitzungs-Timeout, NAT, RTP-Stille und Kameraabbrüche debuggt.

Ein RTSP-Stream, der erfolgreich startet und dann nach 30 Sekunden stoppt, stellt ein anderes Problem dar als ein Stream, der nie startet. Die Authentifizierung hat funktioniert. SDP wurde zurückgegeben. „SETUP“ und „PLAY“ waren wahrscheinlich erfolgreich. Die Medien sind möglicherweise schon seit einiger Zeit eingetroffen. Dann schloss die Kamera die Sitzung, RTP wurde gestoppt, der Player fror ein oder die Verbindung war abgelaufen.

Suchanfragen wie „RTSP-Stream stoppt nach 30 Sekunden“, „RTSP-Keepalive-Timeout“, „Kamera-Stream wird nach einer Minute getrennt“ und „RTSP-Sitzungstimeout“ deuten normalerweise auf ein Problem mit der Sitzungslebensdauer hin. Der Stream benötigt möglicherweise Keepalive-Anfragen, die NAT-Zuordnung läuft möglicherweise ab, die Kamera schließt möglicherweise inaktive RTSP-Sitzungen, UDP-Medien werden möglicherweise nach einer Pfadänderung blockiert oder RTCP zeigt möglicherweise einen Medienverlust an, bevor die Verbindung getrennt wird.

RTSP Inspector ist hier nützlich, da die Zeitachse wichtig ist. Sie müssen wissen, was bei Sekunde 0, Sekunde 30, Sekunde 60 passiert ist und wann genau der Stream gestoppt wurde.

Warum RTSP nach dem Start stoppen kann

Zu den häufigsten Ursachen gehören:

Der Client sendet kein RTSP-Keepalive.
Die Kamera erwartet „GET_PARAMETER“-Keepalive.
Die Kamera erwartet „OPTIONS“-Keepalive.
Die Zeitüberschreitung der RTSP-Sitzung ist kürzer als erwartet.
NAT- oder Firewall-Status läuft ab.
UDP RTP stoppt, während RTSP TCP offen bleibt.
Die Kamera schließt die TCP-Verbindung nach Medienstille.
Der Client hat eine falsche Aggregatkontroll-URL verwendet.
Die Kamera-Firmware weist einen Fehler bei der Sitzungsbereinigung auf.
RTCP meldet Paketverlust oder Jitter, bevor der Stream einfriert.

Die Fehlerbehebung hängt davon ab, welche Schicht zuerst gestoppt wurde: RTSP-Steuerung, RTP-Medien, RTCP-Feedback oder der zugrunde liegende TCP/UDP-Pfad.

RTSP-Sitzungsheader und Timeout

Nach „SETUP“ gibt die Kamera normalerweise einen „Session“-Header zurück:

RTSP/1.0 200 OK
Session: 12345678;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

OPTIONS vs GET_PARAMETER keepalive

Two common keepalive methods are:

OPTIONS rtsp://camera/stream RTSP/1.0
Session: 12345678

Und:

GET_PARAMETER rtsp://camera/stream RTSP/1.0
Session: 12345678

When debugging, check:

Aggregate control URL problems

This can create subtle behavior:

NAT and firewall idle timeout

Symptoms:

Camera idle disconnects

Look for:

RTP silence vs RTSP disconnect

Checklist for streams that stop after 30 seconds

Use this process:

A useful report includes:

Final diagnosis

Reproduzierbarer Nachweis für „RTSP-Stream stoppt nach 30 Sekunden: Keepalive, Sitzungs-Timeout, NAT und Kamera-Leerlauf-Verbindungsabbrüche“

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 „RTSP-Stream stoppt nach 30 Sekunden: Keepalive, Sitzungs-Timeout, NAT und Kamera-Leerlauf-Verbindungsabbrüche“ 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 „RTSP-Stream stoppt nach 30 Sekunden: Keepalive, Sitzungs-Timeout, NAT und Kamera-Leerlauf-Verbindungsabbrüche“ lautet: Warum RTSP-Streams nach 30 Sekunden, 60 Sekunden oder ein paar Minuten stoppen und wie man Keepalive-Anfragen, Sitzungs-Timeout, NAT, RTP-Stille und Kameraabbrüche 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: RTSP-Stream stoppt nach 30 Sekunden: Keepalive, Sitzungs-Timeout, NAT und Kamera-Leerlauf-

Trennen Sie bei „RTSP-Stream stoppt nach 30 Sekunden: Keepalive, Sitzungs-Timeout, NAT und Kamera-Leerlauf-Verbindungsabbrüche“ 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 2: Warum RTSP-Streams nach 30 Sekunden, 60 Sekunden oder ein paar Minuten stoppen und wie man

Schließen Sie „Warum RTSP-Streams nach 30 Sekunden, 60 Sekunden oder ein paar Minuten stoppen und wie man Keepalive-Anfragen, Sitzungs-Timeout, NAT, RTP-Stille und K“ 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 3: Warum RTSP nach dem Start stoppen kann

Trennen Sie bei „Warum RTSP nach dem Start stoppen kann“ 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: RTSP-Sitzungsheader und Timeout

Schließen Sie „RTSP-Sitzungsheader und Timeout“ 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 5: OPTIONS vs GETPARAMETER keepalive

Trennen Sie bei „OPTIONS vs GETPARAMETER keepalive“ 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 6: Aggregate control URL problems

Schließen Sie „Aggregate control URL problems“ 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: NAT and firewall idle timeout

Trennen Sie bei „NAT and firewall idle timeout“ 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 8: Camera idle disconnects

Schließen Sie „Camera idle disconnects“ 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 9: RTP silence vs RTSP disconnect

Trennen Sie bei „RTP silence vs RTSP disconnect“ 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: Checklist for streams that stop after 30 seconds

Schließen Sie „Checklist for streams that stop after 30 seconds“ 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.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
RTSP-Stream stoppt nach 30 Sekunden: Keepalive, Sitzungs-Timeout, NAT und Kamera-Leerlauf-Verbindungsabbrüche	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Warum RTSP-Streams nach 30 Sekunden, 60 Sekunden oder ein paar Minuten stoppen und wie man Keepalive-Anfragen, Sitzungs-	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Warum RTSP nach dem Start stoppen kann	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
RTSP-Sitzungsheader und Timeout	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
OPTIONS vs GETPARAMETER keepalive	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Aggregate control URL problems	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.