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

« 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.