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

---

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 :

1. Le client envoie « DESCRIBE » sans autorisation.
2. La caméra renvoie « 401 non autorisé ».
3. La caméra inclut « WWW-Authenticate : Digest… ».
4. Le client recalcule la réponse Digest.
5. Le client envoie à nouveau « DESCRIBE » avec « Autorisation : Digest… ».
6. 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:

1. Confirm whether the first 401 is only a challenge.
2. Check whether the client retries with Authorization.
3. Compare Basic vs Digest.
4. Compare realm and nonce values.
5. Check whether stale=true appears.
6. Verify the URI used in the authorization header.
7. Check whether credentials contain reserved URL characters.
8. Confirm the account has RTSP permissions.
9. Test the same camera path after reboot or lockout window.
10. 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.