Réponse directe
Reconnectez-vous rapidement une fois, puis utilisez un intervalle exponentiel plafonné avec gigue. Réinitialisez le délai uniquement une fois que le flux reste sain pendant une fenêtre de stabilité définie.
Pourquoi cela arrive
Des tentatives infinies et immédiates peuvent surcharger une caméra qui redémarre et synchroniser des centaines de clients dans une tempête de reconnexion. Cependant, une nouvelle tentative de correction très lente laisse les pannes de routine non résolues pendant trop longtemps.
La visualisation fiable de la caméra dépend de tentatives limitées, de l’état de santé observable et d’une politique délibérée de flux principal/sous-flux.
Un test contrôlé
Définissez les états de connexion, de lecture, de blocage, de recul et d'arrêt, avec un propriétaire de minuterie par flux.
Modifiez une variable à la fois. Conservez le modèle de caméra, le micrologiciel, le point final et le compte enregistrés ; testez ensuite l'accessibilité du réseau, la réponse du protocole, le transport multimédia et le décodage en tant que couches distinctes.
Utilisez un compte dédié en lecture seule et un outil de diagnostic local fiable. Rédigez les informations d’identification, les adresses privées et les données d’identification avant de partager la sortie.
Séquence diagnostique
| Vérifier | Action | Preuve de progrès |
|---|---|---|
| Réessayez d'abord | Autoriser une nouvelle tentative rapide en cas de brève interruption du chemin. | Les pannes courtes se rétablissent rapidement. |
| Recul | Augmentez le délai après des échecs répétés et ajoutez de la gigue. | Les clients ne réessayent pas en même temps. |
| Réinitialisation de la santé | Réinitialisez le nombre de tentatives après une bonne lecture soutenue. | Un bon paquet n'efface pas un défaut persistant. |
| Règle d'arrêt | Arrêt ou alerte après la limite opérationnelle. | Une caméra morte est visible plutôt que réessayée silencieusement pour toujours. |
Des preuves à conserver
Enregistrez le numéro de tentative, la raison, le délai et le temps écoulé depuis la dernière bonne image. Cela prend en charge à la fois les opérations et l’analyse des causes profondes.
Note de délimitation et de sécurité
La logique de reconnexion ne doit pas contourner les échecs d’authentification, les accès révoqués ou un arrêt explicite de l’opérateur.
Pour la visualisation à distance, utilisez un VPN géré au lieu d'exposer RTSP ou les ports d'administration de la caméra directement à l'Internet public.
SmartRTSP
SmartRTSP est une visionneuse RTSP et ONVIF axée sur la caméra pour les appareils Apple, Windows et Android. Il convient aux contrôles de visualisation directe, de découverte et multi-caméras ; conservez un NVR ou VMS dédié lorsqu’un enregistrement continu, une exportation de preuves ou des contrôles d’entreprise centralisés sont requis.
Questions fréquemment posées
Qu'est-ce qu'une bonne stratégie de reconnexion ?
Une première tentative rapide suivie d'un recul exponentiel plafonné avec gigue et un seuil d'arrêt ou d'alerte explicite.
Quand l’intervalle de temps doit-il être réinitialisé ?
Après une période définie de lecture saine, pas immédiatement après l'ouverture du socket.
Les erreurs 401 doivent-elles réessayer automatiquement ?
Les échecs d'authentification répétés devraient s'arrêter ou alerter plutôt que de marteler la caméra avec le même identifiant rejeté.
Références principales
- IETF RFC 7826 — Protocole de diffusion en temps réel 2.0
- CISA — Conseils sur la sécurité dès la conception
- SmartRTSP — plateforme officielle et informations sur le produit
Guide SmartRTSP associé
Ouvrir le guide associéConcevez des tentatives limitées, une gigue et des états de connexion visibles pour les caméras qui redémarrent ou perdent brièvement le réseau.