RTSP-nicht passender Transport in Server-Antwort: Debuggen von Kamera-SETUP-Antworten und RTP-Modus-Nichtübereinstimmung

Einige RTSP-Fehler geben keinen sauberen „461 Unsupported Transport“ zurück. Stattdessen meldet der Client „nicht passender Transport in der Serverantwort“, „ungültiger Transportheader“, „Server hat mit anderem Transport geantwortet“ oder „RTP-Transport stimmt nicht überein“. Dies geschieht häufig, wenn eine Kamera „SETUP“ akzeptiert, aber mit einem „Transport“-Header antwortet, der nicht mit den Anforderungen des Clients übereinstimmt oder mit dem übereinstimmt, was der Client analysieren kann.

Benutzer suchen nach „Nicht übereinstimmender RTSP-Transport in Serverantwort“, „Nicht übereinstimmender ffmpeg-Transport“, „Nicht übereinstimmender RTSP SETUP-Transport“ und „Ungültiger Kamera-Transport-Header“, da der Stream möglicherweise in einem Player funktioniert und in einem anderen fehlschlägt. Die Kamera ist nicht einfach unerreichbar. Die RTSP-Transportaushandlung ist inkonsistent.

RTSP Inspector ist nützlich, da die Anforderungs- und Antwortheader direkt verglichen werden müssen.

Wie ein passender SETUP-Austausch aussieht

Client fordert TCP-Interleaved an:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1

Server replies with compatible TCP interleaved transport:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=12345678

Client fordert UDP an:

Transport: RTP/AVP;unicast;client_port=50000-50001

Server replies with UDP ports:

Transport: RTP/AVP;unicast;client_port=50000-50001;server_port=6970-6971

Wenn der Server den Transportmodus ändert, erforderliche Felder auslässt oder fehlerhafte Werte zurückgibt, schlagen strikte Clients möglicherweise fehl.

Häufige Fälle von Nichtübereinstimmung

Häufige Beispiele sind:

• Der Client fordert TCP an, der Server antwortet UDP.
• Der Client fordert UDP an, der Server antwortet TCP.
• Der Server lässt „interleaved=“ weg.
• Der Server gibt die falschen Kanalnummern zurück.
• Der Server gibt „client_port“-Werte zurück, die sich von der Anfrage unterscheiden.
• Der Server lässt „server_port“ für UDP weg.
• Der Server gibt Multicast zurück, wenn der Client Unicast angefordert hat.
• Der Server gibt mehrere Transportalternativen in einem nicht unterstützten Format zurück.
• Der Proxy schreibt die Anfrage neu, nicht jedoch die Antwort.

Manche Kunden tolerieren diese Macken. Andere lehnen sie ab.

Warum ein Spieler funktioniert und ein anderer scheitert

RTSP-Implementierungen variieren. Ein toleranter Spieler kann eine fehlerhafte oder unerwartete Transportantwort akzeptieren und fortfahren. Ein strengeres Tool kann scheitern, weil die Reaktion seine Erwartungen verletzt.

Das bedeutet nicht automatisch, dass der strikte Client falsch ist. Das bedeutet, dass das Verhalten der Kamera oder des Proxys überprüft werden muss.

Bewahren Sie für eine professionelle Diagnostik auf:

• Der angeforderte Transport-Header.
• Die Transportantwort des Servers.
• URL verfolgen.
• Sitzungs-ID.
• Ob danach RTP-Pakete ankommen.

Proxy- und Relay-Umschreibung

RTSP-fähige Relays können Transportheader neu schreiben, um UDP- und TCP-Pfade zu überbrücken. Wenn das Umschreiben unvollständig ist, sieht der Downstream-Client eine Antwort, die nicht mit seiner Anfrage übereinstimmt.

Beispiele:

• Der Client fordert TCP vom Relay an.
• Relay fordert UDP von der Kamera an.
• Das Relay leitet versehentlich die UDP-Transport-Antwort der Kamera weiter.

Der Kunde meldet einen nicht übereinstimmenden Transport, obwohl die Kamera und das Relais jeweils etwas teilweise gültiges getan haben.

Debug-Checkliste

Verwenden Sie diesen Prozess:

1. Erfassen Sie die „SETUP“-Anfrage.
2. Erfassen Sie die „SETUP“-Antwort.
3. Vergleiche Transportprotokoll: UDP, TCP interleaved, Multicast.
4. Vergleichen Sie Unicast/Multicast.
5. Vergleichen Sie Client-Ports, Server-Ports und verschachtelte Kanäle.
6. Prüfen Sie, ob sich im Pfad ein Proxy/Restreamer befindet.
7. Überprüfen Sie, ob spätere RTP-Pakete der Antwortzuordnung folgen.
8. Vergleichen Sie einen toleranten Spieler und einen strengen Kunden anhand von Paketbeweisen.
9. Testen Sie nach Möglichkeit die direkte Kamera-URL.
10. Melden Sie dem Anbieter das genaue Transportpaar.

Endgültige Diagnose

„Nicht übereinstimmender Transport in Serverantwort“ bedeutet, dass die „SETUP“-Aushandlung zu einer inkompatiblen oder fehlerhaften Transportantwort geführt hat. Möglicherweise ändert die Kamera oder das Relay den RTP-Modus, lässt Felder aus oder gibt Werte zurück, die der Client nicht sicher verwenden kann.

Der RTSP-Inspektor hilft, indem er das Transportanforderungs-/Antwortpaar sichtbar macht. Dies ist die einzige zuverlässige Möglichkeit, diese Klasse von RTSP-Fehlern zu diagnostizieren.