RTSP-Timeout: Wann sollte man TCP Interleaved, UDP Unicast ausprobieren oder den Netzwerkpfad reparieren?

So diagnostizieren Sie RTSP-Timeout, RTP-Timeout, Verbindungsverweigerung und Kamera-Stream-Störungen durch den Vergleich von UDP- und TCP-Interleaved-Transportnachweisen.

RTSP, Timeout, UDP, TCP interleaved, RTP

„RTSP-Timeout“ ist einer der gebräuchlichsten Begriffe zur Fehlerbehebung bei Kameras. Dies kann bedeuten, dass die TCP-Verbindung zum RTSP-Server abgelaufen ist. Dies kann bedeuten, dass „DESCRIBE“ langsam zurückgegeben wird. Dies kann bedeuten, dass „PLAY“ erfolgreich war, aber RTP-Pakete nie angekommen sind. Dies kann bedeuten, dass UDP-Ports blockiert wurden, dass NAT etwas falsch umgeschrieben hat oder dass eine Firewall den Kontrollverkehr, aber keinen Medienverkehr zugelassen hat.

Der Satz ist vage. Der Beweis muss nicht sein.

Trennen Sie das Steuerungs-Timeout vom Medien-Timeout

Die RTSP-Steuerung erfolgt normalerweise über TCP. RTP-Medien können über UDP übertragen oder über die RTSP-TCP-Verbindung verschachtelt werden. Die erste Diagnoseaufteilung ist:

  • Wurde die RTSP-TCP-Verbindung geöffnet?
  • Hat der Server mit „OPTIONS“ geantwortet?
  • Hat „DESCRIBE“ SDP zurückgegeben?
  • War „SETUP“ erfolgreich?
  • war „PLAY“ erfolgreich?
  • Kam RTP nach „PLAY“ an?

Wenn die TCP-Verbindung selbst fehlschlägt, überprüfen Sie Host, Port, Routing, Firewall, VPN und ob der RTSP-Dienst aktiviert ist. Wenn die RTSP-Steuerung erfolgreich ist, RTP jedoch nicht ankommt, überprüfen Sie die Transportverhandlung und den Medienpfad.

Warum UDP oft fehlschlägt, während TCP funktioniert

UDP RTP kann fehlschlagen, selbst wenn die RTSP-Steuerung funktioniert. Der Client und die Kamera handeln während des „SETUP“ Ports aus. Firewalls, NAT-Geräte, VLAN-Richtlinien und Cloud-Routing können den Medienpfad blockieren. Eine Kamera sendet möglicherweise RTP an einen Port, den der Client nicht empfangen kann. Ein Sicherheitsgateway lässt möglicherweise TCP 554 zu, lässt jedoch UDP fallen.

Symptome:

  • „DESCRIBE“ ist erfolgreich
  • „SETUP“ ist erfolgreich
  • „PLAY“ ist erfolgreich
  • Es kommen keine RTP-Pakete an
  • Der Player meldet schließlich eine Zeitüberschreitung oder einen schwarzen Bildschirm

In diesem Fall ist der Wechsel zu TCP Interleaved ein sinnvoller Test. Es sendet RTP innerhalb der RTSP-TCP-Verbindung. Wenn TCP-Interleaved funktioniert und UDP nicht, ist der Codec wahrscheinlich nicht der erste Verdacht. Der Netzwerkmedienpfad ist.

TCP Interleaved ist ein Test, nicht immer die endgültige Antwort

RTSP über TCP interleaved kann über Firewalls und NAT hinweg einfacher sein, da die Kontrolle und die Medien auf derselben Verbindung bleiben. Es kann auch die Latenz erhöhen und das Leistungsverhalten ändern. Für die Felddiagnose wird es am besten als Vergleichspunkt behandelt.

Vergleichen:

  • UDP-Unicast-RTP: Kommen Medien an?
  • TCP interleaved RTP: Kommt das Medium an?
  • RTCP: Sind Absenderberichte sichtbar?
  • Paketverlust: Zeigt UDP Sequenzlücken?
  • Latenz: Kommt TCP unter Bandbreitendruck zum Stillstand?

Wenn die Bereitstellung UDP erwartet, validiert der TCP-Erfolg die Site nicht vollständig. Es identifiziert die Netzwerkgrenze, an der gearbeitet werden muss.

„Verbindung verweigert“ unterscheidet sich von „Zeitüberschreitung“.

„Verbindung abgelehnt“ bedeutet normalerweise, dass der Host die TCP-Verbindung aktiv abgelehnt hat. Häufige Ursachen:

  • RTSP-Dienst deaktiviert
  • wrong port
  • Die Kamera-Firmware stellt RTSP nicht zur Verfügung
  • Der NVR-Anschluss unterscheidet sich vom Kameraanschluss
  • Firewall lehnt ab statt Drops

Timeout bedeutet, dass keine Antwort eingegangen ist, bevor der Client aufgegeben hat. Häufige Ursachen:

  • Routing-Problem
  • Firewall-Drop
  • nicht erreichbares Netzwerk
  • Falsche öffentliche Portzuordnung
  • Kamera offline
  • Problem mit dem VPN-Pfad

Fassen Sie diese nicht in derselben Support-Notiz zusammen. Ablehnungen und Zeitüberschreitungen weisen auf verschiedene Eigentümer hin.

Was in einem Timeout-Bericht erfasst werden soll

Ein nützlicher RTSP-Timeout-Bericht sollte Folgendes enthalten:

  • Zielhost und Port
  • whether TCP connected
  • letzte gesendete RTSP-Methode
  • Antwortstatus, falls vorhanden
  • SDP zurückgegeben oder nicht
  • ausgewählten Transportkopf
  • ausgehandelte Client/Server-Ports
  • ob RTP angekommen ist
  • ob RTCP angekommen ist
  • TCP-Interleaved-Vergleich
  • UDP-Vergleich

Dies ist der Beweis, den ein Netzwerktechniker benötigt. „Es kommt zu einer Zeitüberschreitung“ reicht nicht aus.

Wo RTSP Inspector passt

RTSP Inspector hilft, indem es die RTSP-Kontrolle, die Transportaushandlung, die RTP-Zustellung, den RTCP-Nachweis und die Codec-Bereitschaft in einem Diagnoseablauf zusammenhält. Es geht nicht darum, der Spieler zu sein, der den Unterschied verbirgt.

Bei RTSP-Timeout-Suchen ist die stärkste Ausgabe ein kurzes Urteil:

  • Steuerungs-Timeout vor SDP
  • Medien-Timeout nach erfolgreichem „PLAY“.
  • UDP blockiert, aber TCP-Interleaved funktioniert
  • TCP wurde am RTSP-Port abgelehnt
  • RTP geliefert, aber Codec nicht dekodierbereit

Jedes Urteil hat eine andere Lösung. Das Suchwort mag „RTSP-Timeout“ sein, aber die eigentliche Antwort liegt an der Grenze zwischen Kontrolle und Medien.