2026-06-02

Débogage de l'authentification RTSP Digest : 401 boucles non autorisées, Nonce, Realm, Basic vs Digest et de connexion à la caméra

Comment résoudre les échecs d'authentification RTSP Digest, les boucles 401 non autorisées, les valeurs occasionnelles obsolètes, les incompatibilités de domaine, les paramètres de caméra Basic vs Digest et les problèmes d'informations d'identification d'URL.

Les échecs d’authentification RTSP font partie des cas de prise en charge de caméras IP les plus courants. Les utilisateurs recherchent "RTSP 401 non autorisé", "échec de l'authentification RTSP Digest", "la caméra fonctionne dans VLC mais pas NVR", "RTSP Basic vs Digest", "nonce périmé", "mauvais domaine" et "boucle de connexion de la caméra IP" car le symptôme est simple mais la cause est cachée dans les en-têtes de demande et de réponse.

RTSP Inspector est conçu pour cette classe exacte de problèmes. Un joueur peut seulement dire « l'authentification a échoué ». Un inspecteur de protocole peut afficher le premier « DESCRIBE » non authentifié, le défi « WWW-Authenticate », la réponse « Authorization » du client, la valeur occasionnelle, le domaine, l'URI utilisé dans le calcul du résumé et si la caméra rejette la deuxième demande.

Pourquoi l'authentification RTSP prête à confusion

De nombreuses caméras n'acceptent pas les informations d'identification à la première demande. Le flux Digest normal est :

Le client envoie « DESCRIBE » sans autorisation.
La caméra renvoie « 401 non autorisé ».
La caméra inclut « WWW-Authenticate : Digest… ».
Le client recalcule la réponse Digest.
Le client envoie à nouveau « DESCRIBE » avec « Autorisation : Digest… ».
La caméra accepte la demande ou renvoie un autre « 401 ».

Le premier « 401 » n’est pas nécessairement une erreur. Le « 401 » répété après que le client envoie les informations d'identification Digest est la preuve importante.

Paramètres de base et Digest de la caméra

Certaines caméras exposent un paramètre tel que :

Authentification de base
Authentification Digest
Base et Digest
Résumé uniquement
Aucune authentification

Si le client ne prend en charge que Basic mais que la caméra nécessite Digest, le flux échoue. Si le client envoie Digest mais que la caméra est configurée pour une variante spécifique au fournisseur, le flux peut également échouer.

Termes de recherche qui décrivent souvent ce cas :

"Caméra d'authentification RTSP Basic"
"Caméra d'authentification RTSP Digest"
"VLC fonctionne mais l'application obtient 401"
"L'authentification de la caméra NVR a échoué"
"ONVIF fonctionne mais la connexion RTSP échoue"

La solution consiste à ne plus deviner le mot de passe. Vérifiez d’abord quel système d’authentification la caméra a réellement annoncé.

Inadéquations de royaume

Le « domaine » Digest fait partie du calcul de l’authentification. Si le client calcule la réponse avec un domaine différent de celui de la caméra fournie, l'authentification échoue.

Cela peut se produire lorsque :

Un proxy réécrit le défi.
Le micrologiciel modifie le domaine de la caméra après la mise à niveau.
Le client met en cache un défi précédent.
Plusieurs caméras partagent un nom d'hôte via un proxy inverse.
L'application utilise un profil enregistré d'un autre modèle d'appareil photo.

L'inspecteur RTSP doit rendre le domaine visible afin que l'échec devienne concret. La question n’est pas « le mot de passe est-il erroné ? mais "quel domaine exact et quel URI ont été utilisés lorsque la réponse Digest a été générée ?"

Problèmes occasionnels et obsolètes

Le nom occasionnel Digest est une valeur fournie par le serveur. Certaines caméras expirent rapidement. Certaines caméras le réutilisent pour une séance. Certaines caméras rejettent les anciens noms occasionnels après un redémarrage, une mise à jour du micrologiciel, une dérive temporelle ou un trop grand nombre de tentatives infructueuses.

Preuve utile :

La caméra inclut-elle « stale=true » ?
Le client réessaye-t-il avec un nouveau nom occasionnel ?
La caméra envoie-t-elle un numéro occasionnel différent après chaque « 401 » ?
L'authentification fonctionne-t-elle une fois, puis échoue-t-elle plus tard ?
La même URL échoue-t-elle une fois la caméra inactive ?

Si la caméra renvoie un nouveau défi mais que le client continue d'envoyer l'ancien nonce, l'échec est la mise en cache côté client. Si la caméra renvoie des défis répétés sans progrès utile, le problème peut être dû au micrologiciel de la caméra, à la politique de verrouillage ou à une incompatibilité d'informations d'identification.

Incompatibilité d'URI dans l'authentification Digest

L'authentification Digest inclut l'URI demandé. Une inadéquation subtile peut interrompre la connexion :

Le client se connecte à rtsp://192.168.1.10/stream1.
La réponse Digest est calculée pour /stream1.
La caméra attend rtsp://192.168.1.10:554/stream1.
Le proxy transmet /live/stream1.
Le client réessaye avec une URL normalisée.

C'est pourquoi les lignes de requête brutes sont importantes. L'URI « DESCRIBE », l'URI d'en-tête « Autorisation » et le chemin final de la caméra doivent être comparés.

Le mot de passe n'est pas la seule cause

Les équipes d'assistance réinitialisent souvent les mots de passe trop tôt. Un « 401 non autorisé » répété peut également signifier :

Mauvais schéma d'authentification.
Digérer l’inadéquation des domaines.
Rarement périmé.
Incohérence du chemin d'URL.
Le compte appareil photo n'a aucune autorisation RTSP.
Le compte est verrouillé après des tentatives de connexion infructueuses.
Les caractères spéciaux du nom d'utilisateur ou du mot de passe ne sont pas codés en URL.
Le client a supprimé les informations d'identification de l'URL redirigée ou réessayée.
La caméra nécessite la création d'un utilisateur ONVIF avant l'accès RTSP.

Le meilleur article sur le référencement devrait le dire clairement, car de nombreuses recherches partent de l’hypothèse que le mot de passe est erroné.

Caractères spéciaux dans les URL RTSP

Les URL RTSP contiennent souvent des informations d'identification en ligne :

rtsp://user:password@camera.example.local:554/stream1

If the password contains @, :, /, ?, #, or %, the URL parser may split the string incorrectly. The protocol trace can show whether the client actually sent the intended username and whether the request path was damaged.

Better diagnostics separate:

URL parsing.
Authentication challenge.
Digest calculation.
Camera authorization decision.

What to capture

For a useful RTSP authentication report, collect:

Full request method sequence: OPTIONS, DESCRIBE, SETUP, PLAY.
First 401 Unauthorized response.
WWW-Authenticate header.
Authentication scheme.
Realm.
Nonce.
Stale flag.
Client Authorization header metadata.
Request URI used for Digest.
Second or third camera response.
Timing between retries.

Do not publish passwords or full Digest response values in public support cases. For internal debugging, preserve enough header structure to prove the protocol path.

Diagnosis workflow

Use this process:

Confirm whether the first 401 is only a challenge.
Check whether the client retries with Authorization.
Compare Basic vs Digest.
Compare realm and nonce values.
Check whether stale=true appears.
Verify the URI used in the authorization header.
Check whether credentials contain reserved URL characters.
Confirm the account has RTSP permissions.
Test the same camera path after reboot or lockout window.
Save the trace for regression testing.

Final diagnosis

RTSP Digest authentication failures should be diagnosed from headers, not from player error text. The important evidence is the challenge, the retry, the nonce, the realm, the URI, and the final camera decision.

RTSP Inspector helps turn "RTSP 401 Unauthorized" into a specific finding: wrong scheme, stale nonce, realm mismatch, URL credential parsing, account permission, or camera lockout.

Preuve reproductible pour « Débogage de l'authentification RTSP Digest : 401 boucles non autorisées, Nonce, Realm, Basic vs Digest et de connexion à la caméra »

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ébogage de l'authentification RTSP Digest : 401 boucles non autorisées, Nonce, Realm, Basic vs Digest et de connexion à la caméra », 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ébogage de l'authentification RTSP Digest : 401 boucles non autorisées, Nonce, Realm, Basic vs Digest et de connexion à la caméra » est la suivante : Comment résoudre les échecs d'authentification RTSP Digest, les boucles 401 non autorisées, les valeurs occasionnelles obsolètes, les incompatibilités de domaine, les paramètres de caméra Basic vs Digest et les problèmes d'informations d'identification d'URL. 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ébogage de l'authentification RTSP Digest : 401 boucles non autorisées, Nonce, Realm, Bas

Vérifiez « Débogage de l'authentification RTSP Digest : 401 boucles non autorisées, Nonce, Realm, Basic vs Digest et de connexion à la caméra » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 2 : Comment résoudre les échecs d'authentification RTSP Digest, les boucles 401 non autorisées

Si « Comment résoudre les échecs d'authentification RTSP Digest, les boucles 401 non autorisées, les valeurs occasionnelles obsolètes, les incompatibilités » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 3 : Pourquoi l'authentification RTSP prête à confusion

Vérifiez « Pourquoi l'authentification RTSP prête à confusion » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 4 : Paramètres de base et Digest de la caméra

Si « Paramètres de base et Digest de la caméra » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 5 : Inadéquations de royaume

Vérifiez « Inadéquations de royaume » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 6 : Problèmes occasionnels et obsolètes

Si « Problèmes occasionnels et obsolètes » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 7 : Incompatibilité d'URI dans l'authentification Digest

Vérifiez « Incompatibilité d'URI dans l'authentification Digest » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 8 : Le mot de passe n'est pas la seule cause

Si « Le mot de passe n'est pas la seule cause » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Point de contrôle 9 : Caractères spéciaux dans les URL RTSP

Vérifiez « Caractères spéciaux dans les URL RTSP » avec la plus petite entrée représentative. Gardez les réglages indépendants inchangés, répétez la même action et contrôlez le résultat après réouverture ou reconnexion. Une image seule est moins forte qu’un relevé comprenant entrée, réglage, action, sortie et heure.

Point de contrôle 10 : What to capture

Si « What to capture » est ambigu, comparez un cas nominal et un cas défaillant dans des conditions identiques. Marquez la première différence utile au lieu de lister tous les symptômes suivants. Cette limite produit généralement une demande d’assistance plus claire.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Débogage de l'authentification RTSP Digest : 401 boucles non autorisées, Nonce, Realm, Basic vs Digest et de connexion à	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment résoudre les échecs d'authentification RTSP Digest, les boucles 401 non autorisées, les valeurs occasionnelles o	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Pourquoi l'authentification RTSP prête à confusion	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Paramètres de base et Digest de la caméra	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Inadéquations de royaume	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Problèmes occasionnels et obsolètes	É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 :