Diagnostics du flux de caméra RTSP : un flux de travail de dépannage systématique, de DESCRIBE à la lecture

Les problèmes de caméra RTSP suivent généralement un modèle : la couche de connexion, la couche de contrôle ou la couche média. Ce flux de travail de diagnostic montre quelles preuves collecter, quelle étape du protocole échoue et comment lire SDP, RTP et RTCP pour identifier l'échec exact.

diagnostics RTSP, dépannage, flux de caméra, DESCRIBE, SETUP, RTP

Les pannes de caméra RTSP ne nécessitent pas de conjectures. Le protocole est en couches: "connexion (TCP/TLS), contrôle (DESCRIBE/SETUP/PLAY) et média (RTP/RTCP). Lorsque le flux se brise, c’est l’une de ces couches qui pose problème. Votre travail consiste à trouver lequel."

Le modèle à trois couches

Chaque problème RTSP appartient à l’une des trois catégories suivantes. Commencez ici avant de plonger dans des codes d’erreur spécifiques :

Couche 1 – Connexion : Le client peut-il atteindre la caméra ? Prise de contact TCP, négociation TLS, filtrage des ports, routage VPN. Si « telnet camera-ip 554 » ne se connecte pas, rien d'autre n'a d'importance.

Couche 2 — Contrôle : La connexion fonctionne, mais les commandes RTSP échouent. DESCRIBE renvoie 400/404/401. SETUP renvoie 461. PLAY renvoie 453. Le plan de contrôle présente des problèmes au niveau du protocole : format d'URL, authentification, négociation de transport, gestion de session.

Couche 3 — Média : Le contrôle fonctionne parfaitement, mais la vidéo/l'audio sont interrompus. Les paquets RTP arrivent mais ne peuvent pas être décodés. Les horodatages dérivent. Les cadres sont corrompus. RTCP signale une perte. Le plan multimédia présente des problèmes de charge utile, de codec ou de qualité de réseau.

Table de tri rapide

Symptom Couche probable Vérifiez d'abord
"Connexion rejetée" Couche 1 Le port 554 est-il accessible ? Blocage du pare-feu ?
400 requête incorrecte sur DESCRIBE Couche 2 Format URL RTSP, encodage, en-têtes proxy
401 Non autorisé Couche 2 Paramètres d'authentification Digest, nom d'utilisateur/mot de passe
461 Transport non pris en charge Couche 2 Transport UDP vs TCP, en-tête SETUP
DÉCRIRE OK, CONFIGURATION OK, pas de vidéo Couche 3 Type de charge utile RTP, mappage de codec
La vidéo est lue, puis se fige Couche 3 Perte de paquets, keepalive, délai d'expiration de session
L'audio et la vidéo s'éloignent Couche 3 Horodatage RTP, inadéquation de fréquence d'horloge

Les preuves que vous devez recueillir

Avant de diagnostiquer un problème RTSP, capturez ces cinq éléments de preuve :

  1. La réponse DESCRIBE complète — SDP vous indique quelles pistes existent, quels codecs sont utilisés et quels types de charge utile sont attribués.
  2. La requête et la réponse SETUP — L'en-tête de transport affiche UDP par rapport à TCP, les ports client et les ID de canal entrelacés.
  3. La réponse PLAY — Confirme que la session est active et que le RTP circule.
  4. Échantillons de paquets RTP — Octet de type de charge utile, numéros de séquence, horodatages, SSRC.
  5. Rapports d'expéditeur/récepteur RTCP — Nombre de pertes de paquets, gigue, délai entre les arrivées.

Sans cela, vous devinez. Avec eux, l’échec est généralement flagrant.

Guides détaillés par erreur

Quand escalader

Si les trois couches vérifient (connexions TCP, commandes RTSP réussies, paquets RTP arrivent avec des types de charge utile corrects et des horodatages stables) mais que la vidéo semble toujours erronée, le problème vient probablement de la couche décodeur ou application, pas du transport RTSP. À ce stade, capturez un court PCAP, exportez quelques secondes de RTP et remettez-le à l'équipe de décodeur.