Flux de caméras multidiffusion RTSP et UDP : pourquoi la découverte fonctionne mais le média n'arrive pas

Les réseaux de caméras mélangent souvent RTSP unicast, RTP multicast, découverte ONVIF, VLAN, commutateurs PoE, pare-feu et NVR. Le symptôme peut prêter à confusion: "la caméra est découverte, l'URL RTSP est valide, DESCRIBE renvoie SDP, mais les paquets multimédia n'arrivent jamais." Il s’agit d’une limite protocolaire classique. La découverte n'est pas un média. Le contrôle RTSP n'est pas une livraison RTP. L’accessibilité en multidiffusion n’est pas la même que l’accessibilité en monodiffusion.

La découverte ONVIF est une conversation UDP différente

La découverte ONVIF utilise généralement la multidiffusion UDP sur une adresse et un port de découverte. Si la découverte réussit, cela prouve qu'au moins un chemin de contrôle de style multidiffusion a fonctionné pour la découverte. Cela ne prouve pas que les groupes de multidiffusion RTP sont autorisés, joints, acheminés ou transférés.

Erreurs courantes :

• en supposant que la découverte ONVIF prouve le chemin du média RTP
• test à partir d'un VLAN différent de celui du NVR
• autorisant TCP 554 mais bloquant les ports multimédias UDP
• bloquer le trafic du groupe de multidiffusion au niveau du commutateur
• oublier la surveillance IGMP ou le comportement du demandeur
• tester l'URL directe de la caméra pendant que le NVR utilise un chemin différent

Le rapport doit nommer le type de trafic : découverte, contrôle RTSP, média RTP ou retour RTCP.

La multidiffusion nécessite une appartenance à un groupe

Pour le RTP multicast, le récepteur doit rejoindre le groupe multicast. Les commutateurs et les routeurs peuvent nécessiter un comportement IGMP pour transférer correctement le trafic. Si la multidiffusion est désactivée, filtrée ou mal configurée, le contrôle RTSP peut toujours fonctionner alors que le média n'arrive jamais.

Preuve utile :

• SDP déclare une adresse de multidiffusion ou un transport unicast
• L'en-tête de transport SETUP confirme le mode demandé
• interface récepteur et VLAN
• adresse du groupe de multidiffusion
• si les paquets RTP atteignent le point de capture
• si RTCP apparaît
• si le mode unicast se comporte différemment

Si le RTP unicast fonctionne mais pas le multicast, le problème vient probablement de la configuration du réseau multicast, et non du H.264.

Les médias UDP peuvent être bloqués pendant le fonctionnement du contrôle TCP

Les pare-feu autorisent souvent TCP 554 ou 8554 mais bloquent les ports UDP. NAT peut également casser les médias UDP. Cela crée un modèle commun :

• La connexion TCP réussit
• DESCRIBE réussit
• SETUP réussit
• PLAY réussit
• aucun RTP n'arrive

Le passage à TCP entrelacé est une comparaison utile. Si TCP entrelacé fonctionne, le serveur RTSP et le codec sont probablement fonctionnels. Le chemin multimédia UDP nécessite une attention particulière.

Que capturer

Pour les cas de multidiffusion et UDP, capturez :

• En-têtes de requête et de réponse RTSP
• Adresse média SDP et informations de suivi
• en-tête de transport de SETUP
• ports client et serveur
• groupe de multidiffusion
• Arrivée ou absence du paquet RTP
• Arrivée ou absence du paquet RTCP
• même test sur TCP entrelacé

Ces preuves aident l'équipe réseau à corriger le routage, le pare-feu ou le transfert multidiffusion au lieu de demander au fournisseur de la caméra de modifier les paramètres du codec.

Où s’adapte l’inspecteur RTSP

RTSP Inspector est conçu pour les preuves de protocole, et non pour les suppositions visuelles. Dans les cas de multidiffusion et UDP, sa valeur indique l'endroit où le flux s'est arrêté :

• la découverte a fonctionné mais RTSP a échoué
• RTSP a fonctionné mais RTP n'est jamais arrivé
• UDP a échoué mais TCP entrelacé a fonctionné
• le groupe de multidiffusion a été déclaré mais aucun paquet n'a atteint le client
• RTP est arrivé mais la préparation du codec a échoué

Ce sont des échecs différents. Une fenêtre de lecteur ne peut pas les distinguer de manière fiable. Un rapport protocolaire peut le faire.