2026-06-03

RTSP Aggregate Control URL-Debugging: SDP-Steuerung:*, URLs verfolgen, SETUP 404 und PLAY schlägt fehl

So beheben Sie Fehler bei RTSP-Aggregatsteuerungs-URLs, SDP-Steuerung:*-Attributen, Steuerungspfaden auf Spurebene, SETUP 404-Fehlern, PLAY-Fehlern und Kamera-URL-Konstruktionsfehlern.

RTSP-Kamera-URLs schlagen häufig fehl, weil der Client aus SDP die falsche Steuer-URL erstellt. Benutzer suchen nach „RTSP SETUP 404“, „SDP Control Star“, „RTSP Aggregate Control URL“, „RTSP Track URL falsch“, „DESCRIBE funktioniert, aber SETUP schlägt fehl“ und „PLAY schlägt nach SETUP fehl“, wenn eine Kamera SDP erfolgreich zurückgibt, die Medien jedoch nie starten.

RTSP Inspector ist nützlich, da es bei diesem Fehler nicht darum geht, ob der Player Videos zeichnen kann. Es geht darum, ob der RTSP-Client die „Kontroll“-Attribute auf Sitzungs- und Medienebene richtig interpretiert hat.

Das häufigste Symptom

Ein typischer Trace sieht so aus:

DESCRIBE rtsp://camera/live
200 OK
SDP contains a=control:*
SDP video media contains a=control:trackID=1
SETUP rtsp://camera/trackID=1
404 Not Found

The camera did not necessarily reject RTSP. The client may have constructed SETUP with the wrong base URL.

Session-level and media-level control

SDP can contain control attributes at different levels:

a=control:*
m=video 0 RTP/AVP 96
a=control:trackID=1
m=audio 0 RTP/AVP 97
a=control:trackID=2

Die Steuerung auf Sitzungsebene kann die Gesamtressource identifizieren, die für „PLAY“ und „PAUSE“ verwendet wird. Die Steuerung auf Medienebene identifiziert jeden für „SETUP“ verwendeten RTP-Track.

Wenn ein Client jeden „Kontroll“-Wert als absoluten Pfad behandelt, kann er ungültige URLs erstellen.

Relative vs. absolute Kontroll-URLs

RTSP-SDP-Steuerwerte können sein:

Absolute RTSP-URLs.
Relative Pfade.
Verfolgen Sie Identifikatoren.
* Aggregatsteuerung.
Herstellerspezifische Pfade.

Beispiele:

a=control:rtsp://192.168.1.10/live/trackID=1
a=control:trackID=1
a=control:streamid=0
a=control:video
a=control:*

The client must combine relative track control values with the correct base URL. A tiny difference such as /live/trackID=1 vs /trackID=1 can turn a working camera into a 404 Not Found.

DESCRIBE succeeds but SETUP fails

This is one of the strongest search patterns for this article. DESCRIBE proves the camera accepted the main URL and returned SDP. SETUP failure points to transport negotiation, track URL construction, unsupported media track, or camera firmware behavior.

Evidence to collect:

Original DESCRIBE URL.
Content-Base header if present.
Content-Location header if present.
Session-level a=control.
Media-level a=control for each track.
Exact SETUP URL.
SETUP response status.
Transport header used by SETUP.

Without the SETUP URL, the diagnosis is incomplete.

Content-Base and Content-Location

Some cameras include Content-Base or Content-Location headers in the DESCRIBE response. These headers can affect how relative SDP control paths should be resolved.

Failure patterns:

Client ignores Content-Base.
Client uses the original DESCRIBE URL when camera intended a different base.
Camera returns a base URL with trailing slash differences.
Proxy rewrites the RTSP URL but not SDP.
Client normalizes away a path component needed by the camera.

These details are exactly why protocol evidence matters.

PLAY uses aggregate control

After SETUP succeeds for one or more tracks, PLAY may need to target the aggregate control URL instead of a single track URL. Some cameras accept either. Others are strict.

Search symptoms:

"RTSP SETUP works but PLAY fails"
"RTSP 460 Only Aggregate Operation Allowed"
"RTSP PLAY 404"
"RTSP track SETUP OK no video"

If PLAY targets the wrong URI, the RTP stream may never start even though SETUP returned 200 OK.

Multi-track audio and video

The bug is easier to see when both audio and video exist:

m=video ...
a=control:trackID=1
m=audio ...
a=control:trackID=2

Der Client muss beide Tracks mit ihren eigenen Kontroll-URLs EINRICHTEN und dann die richtige aggregierte URL SPIELEN. Wenn der Client nur Video einrichtet, PLAY jedoch auf Audio abzielt, oder wenn er beide Spuren in einer SETUP-URL zusammenführt, gibt die Kamera möglicherweise einen Fehler zurück, der scheinbar nichts damit zu tun hat.

ONVIF-Profil-URL vs. RTSP-Track-URL

ONVIF kann Stream-URIs melden, die von den endgültigen SDP-Track-URLs abweichen. Ein Stream-URI von ONVIF ist möglicherweise für DESCRIBE gültig, aber nicht direkt für jede SETUP-Anfrage.

Dadurch entsteht der allgemeine Supportsatz: „ONVIF funktioniert, aber die RTSP-URL schlägt fehl.“ Der nächste Diagnoseschritt besteht darin, das SDP und die abgeleiteten SETUP-URLs zu überprüfen und nicht ständig neue ONVIF-URLs zu generieren.

Debug-Checkliste

Verwenden Sie diesen Workflow:

Erfassen Sie die DESCRIBE-Antwort.
Speichern Sie „Content-Base“ und „Content-Location“.
Extrahieren Sie „a=control“ auf Sitzungsebene.
Extrahieren Sie jede Medienebene „a=control“.
Erstellen Sie die erwartete SETUP-URL manuell.
Vergleichen Sie es mit der SETUP-URL des Clients.
Überprüfen Sie, ob SETUP mit 404, 461 oder 500 fehlschlägt.
Bestätigen Sie, ob PLAY auf aggregierte URLs oder Track-URLs abzielt.
Überprüfen Sie das Mehrspur-Audio-/Videoverhalten.
Behalten Sie die genauen RTSP-Anfragezeilen für den Anbietersupport bei.

Endgültige Diagnose

Fehler bei der RTSP-Aggregatsteuerung verbergen sich in der SDP-Interpretation. Eine Kamera kann DESCRIBE akzeptieren und dennoch SETUP oder PLAY ablehnen, wenn der Client die falsche Spur oder Aggregatsteuerungs-URL erstellt.

RTSP Inspector hilft dabei, die SDP-Steuerattribute, Content-Base-Header, SETUP-URLs und PLAY-Ziele offenzulegen, sodass Ingenieure nachweisen können, ob es sich um die URL-Konstruktion, die Kamerastriktheit, das Proxy-Umschreiben oder die clientseitige SDP-Verarbeitung handelt.

Reproduzierbarer Nachweis für „RTSP Aggregate Control URL-Debugging: SDP-Steuerung:*, URLs verfolgen, SETUP 404 und PLAY schlägt fehl“

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 Aggregate Control URL-Debugging: SDP-Steuerung:*, URLs verfolgen, SETUP 404 und PLAY schlägt fehl“ 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 Aggregate Control URL-Debugging: SDP-Steuerung:, URLs verfolgen, SETUP 404 und PLAY schlägt fehl“ lautet: So beheben Sie Fehler bei RTSP-Aggregatsteuerungs-URLs, SDP-Steuerung:-Attributen, Steuerungspfaden auf Spurebene, SETUP 404-Fehlern, PLAY-Fehlern und Kamera-URL-Konstruktionsfehlern. 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 Aggregate Control URL-Debugging: SDP-Steuerung:, URLs verfolgen, SETUP 404 und PLAY s

Ist „RTSP Aggregate Control URL-Debugging: SDP-Steuerung:*, URLs verfolgen, SETUP 404 und PLAY schlägt fehl“ 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 2: So beheben Sie Fehler bei RTSP-Aggregatsteuerungs-URLs, SDP-Steuerung:-Attributen, Steueru

Prüfen Sie „So beheben Sie Fehler bei RTSP-Aggregatsteuerungs-URLs, SDP-Steuerung:*-Attributen, Steuerungspfaden auf Spurebene, SETUP 404-Fehlern, PLAY-Fehlern un“ 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: Das häufigste Symptom

Ist „Das häufigste Symptom“ 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 4: Session-level and media-level control

Prüfen Sie „Session-level and media-level control“ 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 5: Relative vs. absolute Kontroll-URLs

Ist „Relative vs. absolute Kontroll-URLs“ 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: DESCRIBE succeeds but SETUP fails

Prüfen Sie „DESCRIBE succeeds but SETUP fails“ 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 7: Content-Base and Content-Location

Ist „Content-Base and Content-Location“ 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 8: PLAY uses aggregate control

Prüfen Sie „PLAY uses aggregate control“ 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: Multi-track audio and video

Ist „Multi-track audio and video“ 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 10: ONVIF-Profil-URL vs. RTSP-Track-URL

Prüfen Sie „ONVIF-Profil-URL vs. RTSP-Track-URL“ 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.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
RTSP Aggregate Control URL-Debugging: SDP-Steuerung:, URLs verfolgen, SETUP 404 und PLAY schlägt fehl	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
So beheben Sie Fehler bei RTSP-Aggregatsteuerungs-URLs, SDP-Steuerung:-Attributen, Steuerungspfaden auf Spurebene, SETUP	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Das häufigste Symptom	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Session-level and media-level control	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Relative vs. absolute Kontroll-URLs	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
DESCRIBE succeeds but SETUP fails	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.