2026-06-02

Délai d'expiration RTSP : quand essayer TCP Interleaved, UDP Unicast ou corriger le chemin réseau

Comment diagnostiquer les délais d'attente RTSP, RTP, connexion refusée et blocage du flux de caméra en comparant les preuves de transport entrelacées UDP et TCP.

« Délai d'expiration RTSP » est l'une des expressions de dépannage les plus larges de l'appareil photo. Cela peut signifier que la connexion TCP au serveur RTSP a expiré. Cela peut signifier que « DESCRIBE » est revenu lentement. Cela peut signifier que « PLAY » a réussi mais que les paquets RTP ne sont jamais arrivés. Cela peut signifier que les ports UDP ont été bloqués, que NAT a réécrit quelque chose de manière incorrecte ou qu'un pare-feu a autorisé le trafic de contrôle mais pas le trafic multimédia.

L'expression est vague. Il n’est pas nécessaire que la preuve l’existe.

Séparer le délai d'expiration du contrôle du délai d'expiration du média

Le contrôle RTSP s'effectue généralement via TCP. Les médias RTP peuvent circuler via UDP ou peuvent être entrelacés via la connexion RTSP TCP. La première division de diagnostic est :

la connexion RTSP TCP s'est-elle ouverte ?
le serveur a-t-il répondu « OPTIONS » ?
« DESCRIBE » a-t-il renvoyé SDP ?
est-ce que SETUP a réussi ?
« PLAY » a-t-il réussi ?
le RTP est-il arrivé après « PLAY » ?

Si la connexion TCP elle-même échoue, inspectez l'hôte, le port, le routage, le pare-feu, le VPN et vérifiez si le service RTSP est activé. Si le contrôle RTSP réussit mais que RTP n'arrive pas, inspectez la négociation de transport et le chemin multimédia.

Pourquoi UDP échoue souvent alors que TCP fonctionne

UDP RTP peut échouer même lorsque le contrôle RTSP fonctionne. Le client et la caméra négocient les ports pendant la configuration. Les pare-feu, les périphériques NAT, la politique VLAN et le routage cloud peuvent bloquer le chemin multimédia. Une caméra peut envoyer RTP vers un port que le client ne peut pas recevoir. Une passerelle de sécurité peut autoriser TCP 554 mais abandonner UDP.

Symptômes:

DESCRIBE réussit
SETUP réussit
PLAY réussit
aucun paquet RTP n'arrive
le joueur signale finalement un délai d'attente ou un écran noir

Dans ce cas, passer à TCP entrelacé est un test utile. Il envoie RTP à l’intérieur de la connexion RTSP TCP. Si TCP entrelacé fonctionne mais pas UDP, le codec n'est probablement pas le premier suspect. Le chemin du support réseau est.

TCP Interleaved est un test, pas toujours la réponse finale

RTSP sur TCP entrelacé peut être plus facile à travers les pare-feu et NAT car il conserve le contrôle et les médias sur la même connexion. Cela peut également augmenter la latence et modifier le comportement en matière de performances. Pour les diagnostics sur le terrain, il est préférable de le considérer comme un point de comparaison.

Comparer:

RTP unicast UDP : les médias arrivent-ils ?
RTP entrelacé TCP : les médias arrivent-ils ?
RTCP : les rapports de l'expéditeur sont-ils visibles ?
perte de paquets : UDP affiche-t-il des écarts de séquence ?
latence : TCP crée-t-il des blocages sous la pression de la bande passante ?

Si le déploiement attend UDP, le succès TCP ne valide pas entièrement le site. Il identifie la limite du réseau qui nécessite des travaux.

La connexion refusée est différente du délai d'attente

« Connexion refusée » signifie généralement que l'hôte a activement rejeté la connexion TCP. Causes courantes :

Service RTSP désactivé
mauvais port
le micrologiciel de la caméra n'expose pas RTSP
Le port NVR diffère du port de la caméra
le pare-feu rejette au lieu de supprimer

Le délai d'attente signifie qu'aucune réponse n'est arrivée avant que le client n'abandonne. Causes courantes :

problème de routage
suppression du pare-feu
réseau inaccessible
mauvaise cartographie des ports publics
caméra hors ligne
Problème de chemin VPN

Ne les regroupez pas dans la même note d’assistance. Refusé et délai expiré pointent vers différents propriétaires.

Que capturer dans un rapport de délai d'attente

Un rapport de délai d'attente RTSP utile doit inclure :

hôte et port cible
si TCP est connecté
dernière méthode RTSP envoyée
état de la réponse le cas échéant
SDP retourné ou non
en-tête de transport sélectionné
ports client/serveur négociés
si RTP est arrivé
si RTCP est arrivé
Comparaison entrelacée TCP
Comparaison UDP

C’est la preuve dont un ingénieur réseau a besoin. "Il expire" ne suffit pas.

Où s’adapte l’inspecteur RTSP

RTSP Inspector aide en gardant le contrôle RTSP, la négociation de transport, la livraison RTP, la preuve RTCP et la préparation du codec dans un seul flux de diagnostic. Il ne s’agit pas d’essayer d’être le joueur qui cache la distinction.

Pour les recherches de délai d'attente RTSP, le résultat le plus puissant est un court verdict :

délai d'expiration du contrôle avant SDP
délai d'attente du média après un « PLAY » réussi
UDP bloqué mais TCP entrelacé fonctionne
TCP refusé sur le port RTSP
RTP livré mais le codec n'est pas prêt à être décodé

Chaque verdict a une solution différente. Le mot-clé de recherche est peut-être « RTSP timeout », mais la vraie réponse se situe à la frontière entre contrôle et média.

Preuve reproductible pour « Délai d'expiration RTSP : quand essayer TCP Interleaved, UDP Unicast ou corriger le chemin réseau »

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 « Délai d'expiration RTSP : quand essayer TCP Interleaved, UDP Unicast ou corriger le chemin réseau », 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 à « Délai d'expiration RTSP : quand essayer TCP Interleaved, UDP Unicast ou corriger le chemin réseau » est la suivante : Comment diagnostiquer les délais d'attente RTSP, RTP, connexion refusée et blocage du flux de caméra en comparant les preuves de transport entrelacées UDP et TCP. 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 : Délai d'expiration RTSP : quand essayer TCP Interleaved, UDP Unicast ou corriger le chemin

Ne fermez « Délai d'expiration RTSP : quand essayer TCP Interleaved, UDP Unicast ou corriger le chemin réseau » 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 2 : Comment diagnostiquer les délais d'attente RTSP, RTP, connexion refusée et blocage du flux

Pour « Comment diagnostiquer les délais d'attente RTSP, RTP, connexion refusée et blocage du flux de caméra en comparant les preuves de transport entrelacées », 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 3 : Séparer le délai d'expiration du contrôle du délai d'expiration du média

Ne fermez « Séparer le délai d'expiration du contrôle du délai d'expiration du média » 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 4 : Pourquoi UDP échoue souvent alors que TCP fonctionne

Pour « Pourquoi UDP échoue souvent alors que TCP fonctionne », 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 5 : TCP Interleaved est un test, pas toujours la réponse finale

Ne fermez « TCP Interleaved est un test, pas toujours la réponse finale » 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 6 : La connexion refusée est différente du délai d'attente

Pour « La connexion refusée est différente du délai d'attente », 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 7 : Que capturer dans un rapport de délai d'attente

Ne fermez « Que capturer dans un rapport de délai d'attente » 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 8 : Où s’adapte l’inspecteur RTSP

Pour « Où s’adapte l’inspecteur RTSP », 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 9 : Preuve reproductible pour « Délai d'expiration RTSP : quand essayer TCP Interleaved, UDP U

Ne fermez « Preuve reproductible pour « Délai d'expiration RTSP : quand essayer TCP Interleaved, UDP Unicast ou corriger le chemin réseau » » 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 10 : Comment rédiger une réponse directement réutilisable ?

Pour « Comment rédiger une réponse directement réutilisable ? », 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.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Délai d'expiration RTSP : quand essayer TCP Interleaved, UDP Unicast ou corriger le chemin réseau	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment diagnostiquer les délais d'attente RTSP, RTP, connexion refusée et blocage du flux de caméra en comparant les pr	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Séparer le délai d'expiration du contrôle du délai d'expiration du média	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pourquoi UDP échoue souvent alors que TCP fonctionne	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
TCP Interleaved est un test, pas toujours la réponse finale	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
La connexion refusée est différente du délai d'attente	É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 :