RTSP 401 non autorisé et 404 introuvable : diagnostic de l'URL de la caméra et des échecs d'authentification

Deux erreurs RTSP apparaissent encore et encore dans les tickets d'assistance: "« 401 Unauthorized » et « 404 Not Found ». Ils semblent simples. L’un ressemble à un problème de connexion, l’autre à une mauvaise URL. Dans les déploiements réels de caméras, les deux peuvent être plus subtils." Une caméra peut accepter les mêmes informations d'identification dans l'interface utilisateur Web mais rejeter RTSP. Un enregistreur peut exposer différents chemins pour le flux principal et le sous-flux. Une analyse ONVIF peut découvrir une URL qui change ultérieurement. Un fournisseur peut exiger un numéro de canal, un suffixe de flux ou un jeton de profil. Certaines caméras renvoient également des codes d'état trompeurs lorsque le chemin est trop long, que le flux est désactivé ou qu'un mode d'authentification est incompatible avec le client.

Pour les recherches Google, la requête de l'utilisateur est généralement directe : "Caméra RTSP 401 non autorisée", "RTSP 404 introuvable", "VLC fonctionne mais le NVR ne dit aucun signal" ou "L'URL RTSP de la caméra ONVIF ne fonctionne pas". Un article utile ne doit pas prétendre qu’il existe une URL magique. Il devrait montrer comment recueillir des preuves.

Commencez avec la méthode RTSP qui a échoué

N'enregistrez pas uniquement l'erreur finale. Enregistrez quelle méthode RTSP l'a renvoyé :

• 'OPTIONS'
• DÉCRIRE
• CONFIGURATION
• 'JOUER'

Si OPTIONS échoue avec 401, l'authentification ou la politique du serveur bloque la session avant que les métadonnées ne soient demandées. Si « DESCRIBE » échoue avec 401, la caméra peut accepter la connexion mais refuser l'accès à ce chemin de flux. Si DESCRIBE renvoie 404, le chemin ne correspond généralement pas à un profil de flux. Si SETUP échoue après un DESCRIBE réussi, l'URL peut être valide mais le chemin de contrôle de la piste, le mode de transport ou le profil multimédia a un problème.

Cette distinction est importante car la prochaine action change. Les correctifs d’informations d’identification ne répareront pas un chemin de flux manquant. La modification du suffixe de l'URL ne réparera pas une incompatibilité digest-auth.

Séparer les informations d'identification du chemin de flux

Une matrice de dépannage propre ressemble à ceci :

• le même nom d'utilisateur/mot de passe fonctionne dans l'interface utilisateur Web de la caméra
• Le service RTSP est activé
• Le port RTSP est ouvert depuis le réseau client
• Le chemin de l'URL correspond au modèle de flux principal ou de sous-flux du fournisseur.
• le profil de flux est activé sur la caméra
• le mode d'authentification est compatible avec le client
• les caractères spéciaux du mot de passe sont correctement codés

Password characters are a frequent source of false failures. A password that contains @, :, /, ?, #, or spaces may need URL encoding when embedded in an RTSP URL. A better test is to use a client that sends credentials separately rather than relying on an inline URL.

Pourquoi 404 signifie souvent profil ou chemin, pas réseau

« 404 Not Found » signifie que le serveur a été atteint et a suffisamment compris la demande pour rejeter la ressource. Pour les flux de caméra, cela renvoie souvent à l'un des éléments suivants :

• mauvais numéro de chaîne
• mauvais suffixe de flux
• flux principal désactivé
• sous-flux désactivé
• le chemin de l'enregistreur diffère du chemin de la caméra
• Jeton de profil ONVIF modifié
• nom d'accès spécifique au fournisseur requis
• le flux n'existe qu'après avoir activé RTSP dans les paramètres

La preuve la plus utile est l'URI de la requête « DESCRIBE » et l'état de la réponse. Si la caméra renvoie 404 avant SDP, il n'y a pas encore de session multimédia. Ne passez pas à la perte RTP ou au débogage du codec avant de confirmer que l'URL correspond à un flux réel.

La découverte ONVIF aide, mais ce n'est pas la même chose qu'une preuve

La découverte ONVIF peut fournir des URI de flux et des informations de profil, mais l'URI RTSP découvert doit encore être testé. Certains systèmes exposent correctement ONVIF alors que l'authentification RTSP ou le comportement du chemin est différent. D'autres renvoient un URI valide uniquement pour un profil qui est ensuite désactivé ou modifié.

La séquence diagnostique doit être :

1. découvrir ou saisir l'URL RTSP
2. exécutez OPTIONS et DESCRIBE
3. capturer les codes d'état et les en-têtes
4. vérifier si le SDP est renvoyé
5. alors seulement, inspectez les preuves SETUP, PLAY, RTP et codec

Cet ordre empêche un ingénieur de traiter chaque panne comme un problème de « caméra hors ligne ».

Comment l'inspecteur RTSP doit être utilisé

RTSP Inspector n'est pas un lecteur, un gestionnaire ONVIF ou un produit de découverte de caméra. Son rôle est de rendre la transaction RTSP suffisamment visible pour expliquer ce qui s'est passé. Pour les cas 401 et 404, le résultat utile est :

• demander l'URI
• méthode échouée
• code d'état
• limite d'authentification
• si le SDP a été renvoyé
• si l'échec s'est produit avant la négociation avec les médias
• Prochain propriétaire recommandé : informations d'identification, profil de caméra, format d'URL du fournisseur, port réseau ou activation du flux.

C’est exactement la preuve dont un intégrateur de terrain ou un ingénieur de plate-forme vidéo a besoin avant de s’adresser au fournisseur de la caméra ou de modifier aveuglément les paramètres de l’enregistreur.

Lorsqu'un ticket d'assistance indique « RTSP ne fonctionne pas », demandez la méthode, le code d'état et la limite SDP. Cela transforme une plainte générique en un cas réparable.