2026-06-02

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

Correction de RTSP sans vidéo lorsque le contrôle se connecte mais que le RTP UDP est bloqué. Couvre les règles de pare-feu, le port du protocole RTSP, la traversée NAT, la perte VPN RTP, le repli entrelacé TCP et les ports source UDP de la caméra.

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 à :

Le client ouvre la connexion RTSP TCP au port de caméra 554.
Le client envoie « DESCRIBE ».
La caméra renvoie SDP.
Le client envoie SETUP avec les ports client UDP.
La caméra renvoie les ports du serveur UDP.
Le client envoie « PLAY ».
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 :

Confirmez que RTSP DESCRIBE, SETUP et PLAY réussissent.
Inspectez l’en-tête « Transport » et les ports UDP client/serveur.
Vérifiez si les paquets RTP arrivent après « PLAY ».
Vérifiez si les paquets RTCP arrivent.
Comparez le test LAN et le test VPN/WAN.
Testez le transport entrelacé TCP.
Vérifiez les règles de pare-feu pour la plage de ports UDP RTP.
Vérifiez la redirection de port NAT et le comportement du port source.
Vérifiez les ports UDP accessibles annoncés par le client.
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.

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

La réponse directe est qu’un écran noir ou un code isolé ne prouve pas l’origine d’une panne de caméra. Un diagnostic fiable relie requête et réponse RTSP, transport négocié, session valide, puis numéros de séquence RTP, horodatages et éléments RTCP. Pour « RTSP vs UDP : pourquoi RTSP se connecte mais la vidéo est noire – RTP bloqué par le pare-feu, le NAT et le VPN », partez de la couche la plus proche du symptôme, tout en conservant une chronologie unique afin de ne pas confondre contrôle, réseau et décodage.

Avant de modifier caméra, pare-feu ou VMS, établissez un test de référence. Notez l’URL RTSP sans mot de passe, l’heure, le chemin, le transport demandé, la réponse du serveur et l’arrivée du premier paquet média. Testez séparément UDP et TCP interleaved si l’équipement les propose. Ne changez pas à la fois chemin, identifiants et transport : un second essai réussi ne dirait pas quelle variable a corrigé l’écart.

Couche	Preuve à conserver	Question de décision
RTSP	méthode, statut, en-têtes, CSeq et Session	Le serveur accepte-t-il précisément l’opération ?
SDP	control, payload type, clock rate et codec	La piste décrite est-elle celle attendue ?
Transport	client_port, server_port ou interleaved	Les deux extrémités utilisent-elles le même canal ?
RTP	SSRC, séquence, timestamp et marker	Les unités arrivent-elles dans un ordre explicable ?
RTCP	sender report, CNAME et BYE	Horloge, identité et fin sont-elles traçables ?
Décodeur	SPS/PPS/VPS et packetization mode	Le payload reçu permet-il l’initialisation ?

Séparez « aucun média reçu » de « média reçu mais indécodable ». L’absence de RTP après SETUP et PLAY réussis dirige vers UDP, NAT, pare-feu ou une réponse Transport différente de l’offre. Des trous de séquence prouvent perte ou réordonnancement. Une séquence continue sans image déplace l’enquête vers payload type, fréquence d’horloge, limites d’image et paramètres H.264 ou H.265. Cette frontière est plus utile qu’un message générique du lecteur.

Comment rédiger une réponse directement réutilisable ?

Écrivez trois phrases : dernière opération réussie, première preuve en échec, prochain test discriminant. Exemple : « DESCRIBE, SETUP et PLAY réussissent ; aucun RTP n’arrive aux ports annoncés ; un essai TCP interleaved séparera blocage UDP et mauvais chemin média. » N’accusez ni caméra ni réseau sans réponse ou paquet qui matérialise cette limite.

Quelles données rendent le cas reproductible ?

Conservez OPTIONS, DESCRIBE, SETUP et PLAY, le SDP, la réponse Transport et l’identifiant Session nettoyé. Pour RTP, relevez SSRC, première et dernière séquence, clock rate, nombre de trous et durée. Mentionnez le résultat dans VLC ou un autre VMS comme test différentiel, pas comme preuve que le client qui fonctionne respecte toutes les frontières.

Quand tester le serveur ou le client ?

Examinez le serveur s’il refuse une méthode, fournit une URL control absente, renvoie un transport incompatible ou change SSRC ou horloge sans transition. Examinez le client s’il réutilise un nonce expiré, perd Session, demande UDP sans ouvrir les ports ou assimile chaque fin de NAL à une fin d’access unit. Entre les deux, paquet et heure doivent accompagner chaque conclusion.

Comment valider le rapport ?

Recommencez avec une connexion neuve et comparez les chronologies jusqu’à la première divergence. Retirez mots de passe et valeurs Authorization complètes. Reliez chaque conclusion à CSeq, séquence ou timestamp. La documentation RTSP associée couvre les étapes voisines ; RTSP Inspector permet de tester un flux RTSP et de collecter localement les preuves sans téléverser la vidéo vers un service public.

Réponse directe et limite d’acceptation

La réponse courte à « RTSP vs UDP : pourquoi RTSP se connecte mais la vidéo est noire – RTP bloqué par le pare-feu, le NAT et le VPN » est la suivante : Correction de RTSP sans vidéo lorsque le contrôle se connecte mais que le RTP UDP est bloqué. Couvre les règles de pare-feu, le port du protocole RTSP, la traversée NAT, la perte VPN RTP, le repli entrelacé TCP et les ports source UDP de la caméra. Considérez cette phrase comme un résultat à vérifier, et non comme une promesse valable pour toute entrée, tout appareil, tout projet ou tout environnement. Un résultat complet consigne l’état initial, l’action exacte, la sortie visible et la condition qui prouve la fin de la tâche dans RTSP Inspector.

Procédure fondée sur les preuves

Commencez par un cas petit et répétable avant de modifier un projet complet. Notez version de l’application, système, identité de l’entrée ou de l’appareil, réglages pertinents et résultat attendu. Exécutez une action volontaire, conservez la première transition inattendue et comparez-la à un cas nominal si possible. Plusieurs changements simultanés masquent la condition qui a créé ou corrigé le problème.

Point de contrôle 1 : RTSP vs UDP : pourquoi RTSP se connecte mais la vidéo est noire – RTP bloqué par le pare-f

Pour « RTSP vs UDP : pourquoi RTSP se connecte mais la vidéo est noire – RTP bloqué par le pare-feu, le NAT et le VPN », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 2 : Correction de RTSP sans vidéo lorsque le contrôle se connecte mais que le RTP UDP est bloq

Ne fermez « Correction de RTSP sans vidéo lorsque le contrôle se connecte mais que le RTP UDP est bloqué. Couvre les règles de pare-feu, le port du protocole RTSP » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 3 : Le contrôle fonctionne ne signifie pas que les médias fonctionnent

Pour « Le contrôle fonctionne ne signifie pas que les médias fonctionnent », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 4 : L'en-tête de transport révèle le plan du port

Ne fermez « L'en-tête de transport révèle le plan du port » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 5 : Pannes courantes de pare-feu et de NAT

Pour « Pannes courantes de pare-feu et de NAT », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 6 : Pourquoi TCP entrelacé fonctionne souvent

Ne fermez « Pourquoi TCP entrelacé fonctionne souvent » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 7 : RTCP peut aider à prouver le chemin

Pour « RTCP peut aider à prouver le chemin », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 8 : Liste de contrôle de débogage

Ne fermez « Liste de contrôle de débogage » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 9 : Diagnostic final

Pour « Diagnostic final », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 10 : Preuve reproductible pour « RTSP vs UDP : pourquoi RTSP se connecte mais la vidéo est noir

Ne fermez « Preuve reproductible pour « RTSP vs UDP : pourquoi RTSP se connecte mais la vidéo est noire – RTP bloqué par le pare-feu, le NAT et le VPN » » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
RTSP vs UDP : pourquoi RTSP se connecte mais la vidéo est noire – RTP bloqué par le pare-feu, le NAT et le VPN	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Correction de RTSP sans vidéo lorsque le contrôle se connecte mais que le RTP UDP est bloqué. Couvre les règles de pare-	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Le contrôle fonctionne ne signifie pas que les médias fonctionnent	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
L'en-tête de transport révèle le plan du port	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pannes courantes de pare-feu et de NAT	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pourquoi TCP entrelacé fonctionne souvent	État initial, une action et état obtenu	Une seconde personne reproduit le résultat

Isolation, reprise et transmission

Arrêtez-vous à la première limite en échec. Conservez source, projet, session ou capture, dupliquez avant toute modification destructive et changez une variable par essai. Rejouer un flux entier après plusieurs changements peut modifier le résultat sans expliquer pourquoi.

Distinguez absence de preuve et preuve d’absence. Une vue vide peut signaler mauvaise entrée, portée, filtre, permission, appareil, période ou état du projet. Vérifiez acquisition ou import avant d’interpréter décodeur, éditeur, rapport ou export.

Avant transmission, rouvrez l’artefact durable et inspectez début, point de décision et fin. Notez version, plateforme, configuration, attente, observation et reproduction minimale. Retirez ou masquez les données sensibles et confirmez l’autorisation du destinataire.

Questions et réponses

Quelle est la manière fiable la plus rapide de commencer ?

Utilisez le plus petit cas représentatif, écrivez le résultat attendu et ne changez qu’une variable. Validez le parcours de base avant d’ajouter filtres, effets, modifications, automatisation ou grande source.

Quelles preuves faut-il conserver ?

Gardez identité de l’entrée, version, plateforme, réglages, action exacte, première transition inattendue et sortie finale. Fermez puis rouvrez projet, session, rapport ou export avant de le considérer durable.

Quand faut-il répéter la procédure ?

Répétez-la après un changement pertinent d’application, système, pilote, firmware, modèle, source ou processus. Conservez le cas accepté précédent comme référence non modifiée.

Quand le résultat est-il transmissible ?

Lorsqu’une seconde personne autorisée identifie l’entrée, répète l’action, obtient le même résultat, comprend les limites et ouvre l’artefact sans état local non documenté.

Guides associés

Ces pages dans la même langue couvrent les étapes voisines sans changer le propriétaire canonique du sujet :