Debug dell'autenticazione del digest RTSP: 401 cicli non autorizzati, Nonce, Realm, Basic vs Digest e accesso alla fotocamera

Gli errori di autenticazione RTSP sono alcuni dei casi più comuni di supporto delle telecamere IP. Gli utenti cercano "RTSP 401 Unauthorized", "Autenticazione RTSP Digest non riuscita", "la telecamera funziona in VLC ma non NVR", "RTSP Basic vs Digest", "nonce stantio", "reame sbagliato" e "loop di accesso della telecamera IP" perché il sintomo è semplice ma la causa è nascosta nelle intestazioni di richiesta e risposta.

RTSP Inspector è progettato per questa esatta classe di problemi. Un giocatore può solo dire "autenticazione fallita". Un ispettore del protocollo può mostrare il primo "DESCRIBE" non autenticato, la sfida "WWW-Authenticate", la risposta "Autorizzazione" del client, il valore nonce, il realm, l'URI utilizzato nel calcolo del digest e se la telecamera rifiuta la seconda richiesta.

Perché l'autenticazione RTSP crea confusione

Molte fotocamere non accettano le credenziali alla prima richiesta. Il normale flusso del Digest è:

1. Il client invia "DESCRIBE" senza autorizzazione.
2. La fotocamera restituisce "401 Non autorizzato".
3. La fotocamera include "WWW-Authenticate: Digest ...".
4. Il client ricalcola la risposta Digest.
5. Il client invia nuovamente "DESCRIBE" con "Autorizzazione: Digest ...".
6. La fotocamera accetta la richiesta o restituisce un altro "401".

Il primo "401" non è necessariamente un errore. Il ripetuto "401" dopo che il client ha inviato le credenziali Digest è la prova importante.

Impostazioni della fotocamera di base e Digest

Alcune fotocamere espongono un'impostazione come:

• Autenticazione di base
• Autenticazione del digest
• Base e Digest
• Solo digerire
• Nessuna autenticazione

Se il client supporta solo Basic ma la telecamera richiede Digest, lo streaming non riesce. Se il client invia Digest ma la telecamera è configurata per una variante specifica del fornitore, anche lo streaming potrebbe non riuscire.

Termini di ricerca che spesso descrivono questo caso:

• "Telecamera con autenticazione RTSP Basic"
• "Telecamera di autenticazione RTSP Digest"
• "VLC funziona ma l'app ottiene 401"
• "Autenticazione telecamera NVR fallita"
• "ONVIF funziona ma l'accesso RTSP non riesce"

La soluzione è non indovinare nuovamente la password. Per prima cosa controlla quale schema di autenticazione è effettivamente pubblicizzato dalla fotocamera.

Discrepanze tra i regni

Il "reame" del Digest fa parte del calcolo dell'autenticazione. Se il client calcola la risposta con un realm diverso da quello della telecamera fornita, l'autenticazione fallisce.

Ciò può accadere quando:

• Una delega riscrive la sfida.
• Il firmware cambia l'ambito della fotocamera dopo l'aggiornamento.
• Il client memorizza nella cache una sfida precedente.
• Più telecamere condividono un nome host tramite un proxy inverso.
• L'app utilizza un profilo salvato da un modello di fotocamera diverso.

L'ispettore RTSP dovrebbe rendere visibile il regno in modo che il fallimento diventi concreto. La domanda non è "la password è sbagliata?" ma "quale dominio e URI esatti sono stati utilizzati quando è stata generata la risposta Digest?"

Problemi relativi al nonce e al nonce obsoleto

Il Digest nonce è un valore fornito dal server. Alcune fotocamere scadono rapidamente. Alcune fotocamere lo riutilizzano per una sessione. Alcune fotocamere rifiutano i vecchi nonce dopo il riavvio, l'aggiornamento del firmware, la deriva temporale o troppi tentativi falliti.

Prove utili:

• La fotocamera include stale=true?
• Il client riprova con un nuovo nonce?
• La fotocamera invia un nonce diverso dopo ogni "401"?
• L'autenticazione funziona una volta e poi fallisce?
• Lo stesso URL fallisce dopo che la fotocamera è rimasta inattiva?

Se la fotocamera restituisce una nuova richiesta ma il client continua a inviare il vecchio nonce, l'errore è dovuto alla memorizzazione nella cache lato client. Se la fotocamera restituisce richieste ripetute senza progressi utili, il problema potrebbe essere il firmware della fotocamera, la policy di blocco o la mancata corrispondenza delle credenziali.

Mancata corrispondenza dell'URI all'interno dell'autenticazione Digest

L'autenticazione del digest include l'URI richiesto. Una sottile discrepanza può interrompere l'accesso:

• Il client si connette a "rtsp://192.168.1.10/stream1".
• La risposta digest viene calcolata per "/stream1".
• La fotocamera si aspetta rtsp://192.168.1.10:554/stream1.
• Il proxy inoltra "/live/stream1".
• Il client riprova con un URL normalizzato.

Questo è il motivo per cui le linee di richiesta non elaborate sono importanti. È necessario confrontare l'URI "DESCRIBE", l'URI dell'intestazione "Autorizzazione" e il percorso finale della telecamera.

La password non è l'unica causa

I team di supporto spesso reimpostano le password troppo presto. "401 Non autorizzato" ripetuto può anche significare:

• Schema di autenticazione errato.
• Digest mancata corrispondenza del regno.
• Nonce stantio.
• Mancata corrispondenza del percorso URL.
• L'account della fotocamera non dispone dell'autorizzazione RTSP.
• L'account viene bloccato dopo tentativi di accesso falliti.
• I caratteri speciali nel nome utente o nella password non sono codificati nell'URL.
• Il client ha rimosso le credenziali dall'URL reindirizzato o riprovato.
• La telecamera richiede la creazione dell'utente ONVIF prima dell'accesso RTSP.

Il miglior articolo per la SEO dovrebbe dirlo chiaramente perché molte ricerche iniziano con il presupposto che la password sia sbagliata.

Caratteri speciali negli URL RTSP

Gli URL RTSP spesso contengono credenziali in linea:

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.