RTSP vs UDP : pourquoi RTSP se connecte mais la vidéo est noire – RTP bloqué par le pare-feu, le NAT et le VPN

L'un des problèmes RTSP les plus intentionnels est simple à décrire: "la caméra se connecte, mais il n'y a pas de vidéo. Dans de nombreux cas, le contrôle RTSP fonctionne via TCP, mais les paquets multimédias UDP RTP n'atteignent jamais le client. L'utilisateur voit une connexion réussie, SDP, peut-être même « PLAY 200 OK », puis un délai d'attente. Des recherches telles que « RTSP se connecte mais pas de vidéo », « RTP UDP bloqué pare-feu », « RTSP fonctionne sur LAN pas sur VPN », « caméra RTSP NAT pas de vidéo » et « RTSP TCP entrelacé correctif » pointent toutes vers cette division de couche."

RTSP n'est pas un flux de données. Le canal de contrôle et le canal multimédia peuvent utiliser des chemins de transport différents. Si le canal de contrôle fonctionne et que le chemin multimédia échoue, un lecteur peut afficher le même écran noir qu'en cas de panne de codec. Les preuves en paquets sont différentes.

RTSP Inspector est utile car il sépare le succès du contrôle RTSP de la livraison des médias RTP.

Le contrôle fonctionne ne signifie pas que les médias fonctionnent

Un flux RTP UDP normal peut ressembler à :

1. Le client ouvre la connexion RTSP TCP au port de caméra 554.
2. Le client envoie « DESCRIBE ».
3. La caméra renvoie SDP.
4. Le client envoie SETUP avec les ports client UDP.
5. La caméra renvoie les ports du serveur UDP.
6. Le client envoie « PLAY ».
7. La caméra envoie des paquets RTP aux ports UDP clients.

Si les étapes 1 à 6 réussissent et que l'étape 7 échoue, le flux ne constitue pas un problème de connexion RTSP. C'est un problème de cheminement médiatique.

L'en-tête de transport révèle le plan du port

La requête SETUP peut inclure :

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

The camera may answer:

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

La caméra doit envoyer RTP/RTCP aux ports UDP du client. Les pare-feu doivent autoriser ce trafic. Les appareils NAT doivent le mapper correctement. Les VPN doivent le transporter. Dans le cas contraire, le contrôle RTSP peut sembler sain alors que le média est silencieux.

Pannes courantes de pare-feu et de NAT

Les causes courantes incluent :

• Le pare-feu autorise TCP 554 mais bloque la plage de ports UDP RTP.
• NAT transfère le port RTSP mais pas les ports RTP.
• La caméra envoie du RTP à partir de ports sources inattendus.
• Le client annonce des ports UDP privés inaccessibles depuis la caméra.
• Le VPN autorise TCP mais abandonne UDP.
• Le pare-feu d'entreprise bloque les ports UDP élevés.
• La caméra est derrière le double NAT.
• Les paquets RTP retournent à la mauvaise interface.

Le symptôme visible est souvent « pas de vidéo après PLAY ».

Pourquoi TCP entrelacé fonctionne souvent

RTSP sur TCP entrelacé transporte RTP et RTCP à l'intérieur de la connexion RTSP TCP. Cela évite les trous d'épingle UDP séparés.

Si le mode UDP échoue et que l'entrelacement TCP fonctionne, cela constitue une preuve solide que le codec et la caméra fonctionnent probablement correctement. Le problème vient probablement du transport multimédia UDP.

Cependant, TCP entrelacé a ses propres exigences d'analyse, y compris le mappage des canaux. Il s'agit d'une solution de contournement aux problèmes de chemin UDP, et non d'une preuve que chaque couche est saine.

RTCP peut aider à prouver le chemin

Si RTP est bloqué mais que RTCP arrive, ou vice versa, inspectez les paires de ports. Certains pare-feu gèrent les deux directions différemment. Les rapports du récepteur RTCP peuvent également indiquer la perte de paquets et la gigue si le média arrive partiellement.

Enregistrer:

• Nombre de paquets RTP.
• Nombre de paquets RTCP.
• IP et port source RTP.
• IP et port de destination RTP.
• Lacunes dans les numéros de séquence.
• Temps entre « PLAY » et le premier paquet.

Liste de contrôle de débogage

Utilisez ce flux de travail :

1. Confirmez que RTSP DESCRIBE, SETUP et PLAY réussissent.
2. Inspectez l’en-tête « Transport » et les ports UDP client/serveur.
3. Vérifiez si les paquets RTP arrivent après « PLAY ».
4. Vérifiez si les paquets RTCP arrivent.
5. Comparez le test LAN et le test VPN/WAN.
6. Testez le transport entrelacé TCP.
7. Vérifiez les règles de pare-feu pour la plage de ports UDP RTP.
8. Vérifiez la redirection de port NAT et le comportement du port source.
9. Vérifiez les ports UDP accessibles annoncés par le client.
10. Ne déboguez pas le codec tant que les charges utiles RTP n'arrivent pas.

Diagnostic final

Lorsque RTSP se connecte mais que UDP RTP est bloqué, la caméra peut être parfaitement accessible alors que les médias n'arrivent jamais. Le correctif concerne l'accessibilité du port UDP, le comportement NAT, la politique de pare-feu, les règles VPN ou le passage à TCP entrelacé.

RTSP Inspector aide en affichant ensemble la séquence de contrôle RTSP et les preuves de paquets RTP, de sorte que « pas de vidéo » devient un diagnostic de transport concret.