RTSP vs. UDP: Warum RTSP eine Verbindung herstellt, aber das Video schwarz ist – RTP wird durch Firewall, NAT und VPN blockiert

Eines der schwerwiegendsten RTSP-Probleme lässt sich einfach beschreiben: "Die Kamera stellt eine Verbindung her, aber es gibt kein Video. In vielen Fällen funktioniert die RTSP-Steuerung über TCP, UDP-RTP-Medienpakete erreichen jedoch nie den Client. Der Benutzer sieht eine erfolgreiche Anmeldung, SDP, vielleicht sogar „PLAY 200 OK“ und dann eine Zeitüberschreitung. Suchanfragen wie „RTSP stellt Verbindung her, aber kein Video“, „RTP UDP blockiert Firewall“, „RTSP funktioniert im LAN, nicht über VPN“, „Kamera RTSP NAT kein Video“ und „RTSP TCP interleaved fix“ deuten alle auf diese Ebenenaufteilung hin." RTSP ist kein einzelner Datenstrom. Der Steuerkanal und der Medienkanal können unterschiedliche Transportwege nutzen. Wenn der Steuerkanal funktioniert und der Medienpfad ausfällt, zeigt ein Player möglicherweise denselben schwarzen Bildschirm wie bei einem Codec-Fehler an. Der Paketbeweis ist unterschiedlich.

Der RTSP-Inspektor ist nützlich, da er den Erfolg der RTSP-Steuerung von der RTP-Medienbereitstellung trennt.

Kontrollarbeiten bedeuten nicht, dass Medien funktionieren

Ein normaler UDP-RTP-Fluss könnte wie folgt aussehen:

1. Der Client öffnet eine RTSP-TCP-Verbindung zum Kamera-Port 554.
2. Der Client sendet „DESCRIBE“.
3. Die Kamera gibt SDP zurück.
4. Der Client sendet „SETUP“ mit UDP-Client-Ports.
5. Die Kamera gibt UDP-Server-Ports zurück.
6. Der Client sendet „PLAY“.
7. Die Kamera sendet RTP-Pakete an Client-UDP-Ports.

Wenn die Schritte 1 bis 6 erfolgreich sind und Schritt 7 fehlschlägt, handelt es sich bei dem Stream nicht um ein RTSP-Anmeldeproblem. Es handelt sich um ein Medienpfadproblem.

Der Transport-Header zeigt den Hafenplan

Die „SETUP“-Anfrage kann Folgendes umfassen:

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

The camera may answer:

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

Die Kamera sollte RTP/RTCP an die UDP-Ports des Clients senden. Firewalls müssen diesen Datenverkehr zulassen. NAT-Geräte müssen es korrekt zuordnen. VPNs müssen es tragen. Wenn nicht, kann die RTSP-Steuerung fehlerfrei erscheinen, während die Medien stumm sind.

Häufige Firewall- und NAT-Fehler

Zu den häufigsten Ursachen gehören:

• Die Firewall lässt TCP 554 zu, blockiert jedoch den UDP-RTP-Portbereich.
• NAT leitet den RTSP-Port weiter, aber keine RTP-Ports.
• Die Kamera sendet RTP von unerwarteten Quellports.
• Der Client gibt an, dass private UDP-Ports von der Kamera aus nicht erreichbar sind.
• VPN erlaubt TCP, verzichtet jedoch auf UDP.
• Die Unternehmensfirewall blockiert hohe UDP-Ports.
• Die Kamera befindet sich hinter doppeltem NAT.
• RTP-Pakete kehren zur falschen Schnittstelle zurück.

Das sichtbare Symptom ist oft „Kein Video nach der Wiedergabe“.

Warum TCP Interleaved oft funktioniert

RTSP über TCP interleaved überträgt RTP und RTCP innerhalb der RTSP-TCP-Verbindung. Dadurch werden separate UDP-Pinholes vermieden.

Wenn der UDP-Modus fehlschlägt und TCP-Interleaved funktioniert, ist das ein starker Beweis dafür, dass Codec und Kamera wahrscheinlich in Ordnung sind. Das Problem ist wahrscheinlich der UDP-Medientransport.

Allerdings hat TCP Interleaved seine eigenen Parsing-Anforderungen, einschließlich der Kanalzuordnung. Es handelt sich um eine Problemumgehung für UDP-Pfadprobleme und nicht um einen Beweis dafür, dass jede Ebene fehlerfrei ist.

RTCP kann helfen, den Weg zu beweisen

Wenn RTP blockiert ist, RTCP jedoch eintrifft oder umgekehrt, überprüfen Sie die Portpaare. Einige Firewalls behandeln die beiden Richtungen unterschiedlich. RTCP-Empfängerberichte können auch Paketverluste und Jitter anzeigen, wenn Medien teilweise ankommen.

Aufzeichnen:

• Anzahl der RTP-Pakete.
• Anzahl der RTCP-Pakete.
• RTP-Quell-IP und -Port.
• RTP-Ziel-IP und -Port.
• Lücken in der Sequenznummer.
• Zeit vom „PLAY“ bis zum ersten Paket.

Debug-Checkliste

Verwenden Sie diesen Workflow:

1. Bestätigen Sie, dass RTSP „DESCRIBE“, „SETUP“ und „PLAY“ erfolgreich sind.
2. Überprüfen Sie den „Transport“-Header und die Client/Server-UDP-Ports.
3. Überprüfen Sie, ob RTP-Pakete nach „PLAY“ ankommen.
4. Prüfen Sie, ob RTCP-Pakete ankommen.
5. Vergleichen Sie den LAN-Test mit dem VPN/WAN-Test.
6. Testen Sie den TCP-Interleaved-Transport.
7. Überprüfen Sie die Firewall-Regeln für den UDP-RTP-Portbereich.
8. Überprüfen Sie die NAT-Portweiterleitung und das Verhalten des Quellports.
9. Überprüfen Sie die vom Client angekündigten erreichbaren UDP-Ports.
10. Debuggen Sie den Codec erst, wenn die RTP-Nutzdaten tatsächlich eintreffen.

Endgültige Diagnose

Wenn RTSP eine Verbindung herstellt, UDP RTP jedoch blockiert ist, kann die Kamera perfekt erreichbar sein, während Medien nie ankommen. Die Lösung liegt in der Erreichbarkeit des UDP-Ports, dem NAT-Verhalten, der Firewall-Richtlinie, den VPN-Regeln oder dem Wechsel zu TCP Interleaved.

RTSP Inspector hilft, indem es die RTSP-Kontrollsequenz und den RTP-Paketnachweis zusammen anzeigt, sodass „kein Video“ zu einer konkreten Transportdiagnose wird.