RTSP-Multicast- und UDP-Kamerastreams: Warum die Erkennung funktioniert, aber die Medien nicht ankommen

Kameranetzwerke kombinieren häufig Unicast-RTSP, Multicast-RTP, ONVIF-Erkennung, VLANs, PoE-Switches, Firewalls und NVRs. Das Symptom kann verwirrend sein: "Die Kamera wird erkannt, die RTSP-URL ist gültig, „DESCRIBE“ gibt SDP zurück, aber Medienpakete kommen nie an." Dies ist eine klassische Protokollgrenze. Entdeckung ist kein Medium. Bei der RTSP-Steuerung handelt es sich nicht um eine RTP-Zustellung. Multicast-Erreichbarkeit ist nicht dasselbe wie Unicast-Erreichbarkeit.

Die ONVIF-Erkennung ist ein anderes UDP-Gespräch

Die ONVIF-Erkennung verwendet normalerweise UDP-Multicast für eine Erkennungsadresse und einen Erkennungsport. Wenn die Erkennung erfolgreich ist, beweist dies, dass mindestens ein Multicast-Steuerungspfad für die Erkennung funktioniert hat. Es beweist nicht, dass RTP-Multicast-Gruppen zugelassen, beigetreten, weitergeleitet oder weitergeleitet werden.

Häufige Fehler:

• unter der Annahme, dass die ONVIF-Erkennung den RTP-Medienpfad beweist
• Testen von einem anderen VLAN als dem NVR
• Ermöglicht TCP 554, blockiert jedoch UDP-Medienports
• Blockieren des Multicast-Gruppenverkehrs am Switch
• Vergessen von IGMP-Snooping oder Abfrageverhalten
• Testen der direkten Kamera-URL, während der NVR einen anderen Pfad verwendet

Der Bericht sollte den Verkehrstyp benennen: Erkennung, RTSP-Steuerung, RTP-Medien oder RTCP-Feedback.

Multicast erfordert eine Gruppenmitgliedschaft

Für Multicast-RTP muss der Empfänger der Multicast-Gruppe beitreten. Switches und Router benötigen möglicherweise IGMP-Verhalten, um den Datenverkehr korrekt weiterzuleiten. Wenn Multicast deaktiviert, gefiltert oder falsch konfiguriert ist, funktioniert die RTSP-Steuerung möglicherweise immer noch, während Medien nie ankommen.

Nützliche Beweise:

• SDP deklariert Multicast-Adresse oder Unicast-Transport
• Der Transportheader „SETUP“ bestätigt den angeforderten Modus
• Empfängerschnittstelle und VLAN
• Multicast-Gruppenadresse
• ob RTP-Pakete den Erfassungspunkt erreichen
• ob RTCP erscheint
• ob sich der Unicast-Modus anders verhält

Wenn Unicast-RTP funktioniert und Multicast nicht, liegt das Problem wahrscheinlich an der Netzwerk-Multicast-Konfiguration und nicht an H.264.

UDP-Medien können blockiert werden, während die TCP-Steuerung funktioniert

Firewalls erlauben oft TCP 554 oder 8554, blockieren aber UDP-Ports. NAT kann auch UDP-Medien beschädigen. Dadurch entsteht ein gemeinsames Muster:

• Die TCP-Verbindung ist erfolgreich
• „DESCRIBE“ ist erfolgreich
• „SETUP“ ist erfolgreich
• „PLAY“ ist erfolgreich
• es kommt kein RTP an

Der Wechsel zu TCP Interleaved ist ein nützlicher Vergleich. Wenn TCP Interleaved funktioniert, sind der RTSP-Server und der Codec wahrscheinlich funktionsfähig. Der UDP-Medienpfad erfordert Aufmerksamkeit.

Was zu erfassen ist

Erfassen Sie für Multicast- und UDP-Fälle Folgendes:

• RTSP-Anfrage- und Antwortheader
• SDP-Medienadresse und Titelinformationen
• Transport-Header aus „SETUP“.
• Client- und Server-Ports
• Multicast-Gruppe
• Ankunft oder Abwesenheit von RTP-Paketen
• Ankunft oder Abwesenheit von RTCP-Paketen
• Gleicher Test über TCP interleaved

Diese Beweise helfen dem Netzwerkteam, Routing, Firewall oder Multicast-Weiterleitung zu korrigieren, anstatt den Kamerahersteller aufzufordern, die Codec-Einstellungen zu ändern.

Wo RTSP Inspector passt

RTSP Inspector ist für Protokollbeweise und nicht für visuelle Vermutungen konzipiert. In Multicast- und UDP-Fällen zeigt sein Wert an, wo der Stream gestoppt wurde:

• Die Erkennung hat funktioniert, aber RTSP ist fehlgeschlagen
• RTSP funktionierte, aber RTP kam nie an
• UDP schlug fehl, aber TCP-Interleaved funktionierte
• Es wurde eine Multicast-Gruppe deklariert, aber keine Pakete haben den Client erreicht
• RTP ist angekommen, aber die Codec-Bereitschaft ist fehlgeschlagen

Das sind verschiedene Misserfolge. Ein Spielerfenster kann sie nicht zuverlässig unterscheiden. Ein Protokollbericht kann.