RTSP-Authentifizierungsschleife: Behebung von 401 Unauthorized-, Digest-Auth- und Kamera-Anmeldefehlern

Eines der häufigsten RTSP-Kameraprobleme sieht zunächst einfach aus: "Der Client stellt eine Verbindung her, die Kamera antwortet, aber der Stream startet nie. Das Protokoll wiederholt „401 Unauthorized“, der Viewer fragt erneut nach einem Passwort oder die Anwendung sagt, dass die RTSP-URL falsch ist, obwohl Benutzername und Passwort korrekt aussehen." Dies ist eine RTSP-Authentifizierungsschleife. Dies geschieht, wenn die Kamera den Client herausfordert, der Client Anmeldeinformationen sendet und die Kamera diese ablehnt oder erneut fragt. Die Hauptursache kann ein falsches Passwort sein, aber auch eine nicht übereinstimmende Digest-Authentifizierung, veraltete Nonce-Behandlung, Kontoberechtigungen, Sonderzeichen in der URL, ein falscher Stream-Pfad oder eine Kamera, die eine separate Authentifizierung bei „DESCRIBE“, „SETUP“ und „PLAY“ erfordert.

RTSP Inspector ist hier nützlich, da der wichtige Beweis im RTSP-Kontrollaustausch liegt. Ein Mediaplayer verbirgt häufig die Herausforderungs- und Wiederholungsdetails hinter einem einzelnen Anmeldefehler. Eine Protokolldiagnoseansicht kann anzeigen, ob der Fehler bei „OPTIONS“, „DESCRIBE“, „SETUP“ oder „PLAY“ aufgetreten ist und ob die Kamera „WWW-Authenticate“, „stale=true“ oder eine wiederholte Realm-Challenge zurückgegeben hat.

Was eine nicht autorisierte RTSP 401-Antwort bedeutet

In RTSP bedeutet „401 Unauthorized“ normalerweise „Authentifizierung erforderlich“ und nicht „Der Server ist nicht erreichbar“. Eine Kamera kann auf eine nicht authentifizierte Anfrage wie folgt antworten:

RTSP/1.0 401 Unauthorized
CSeq: 2
WWW-Authenticate: Digest realm="IP Camera", nonce="abc123"

The client must then send another request with an Authorization header. For Digest authentication, the client does not send the raw password. It computes a response from the username, password, realm, nonce, method, and URI.

If the computed response does not match what the camera expects, the camera returns another 401 Unauthorized. That repeated challenge is the authentication loop.

Basic authentication vs Digest authentication

Some older cameras support Basic authentication. Basic authentication is simpler: the client base64-encodes the username and password. It is easy to implement, but it is not ideal on untrusted networks because the credentials are not protected by the RTSP protocol itself.

Digest authentication is more common on modern IP cameras and NVRs. It avoids sending the password directly, but it is more sensitive to exact request details. A Digest response can fail if:

• The username or password is wrong.
• The client uses the wrong URI in the Digest calculation.
• The camera's realm changed after a firmware update.
• The nonce expired and the client did not retry correctly.
• The camera expects MD5 but the client tries a different algorithm.
• The stream path in the URL is not the same path used in the Authorization calculation.

When users search for "RTSP Digest auth not working" or "RTSP 401 loop camera", they often assume the camera password is the only possible problem. In practice, the method, URI, nonce, and request order matter just as much.

Special characters in RTSP URL credentials

Credentials in an RTSP URL can break when the password contains characters such as @, :, /, ?, #, %, or &.

A URL like this is ambiguous:

rtsp://admin:pa@ss@192.168.1.50:554/stream1

The second @ may be interpreted as the separator between credentials and host. The client may send the wrong password or parse the host incorrectly. The fix is to URL-encode special characters:

rtsp://admin:pa%40ss@192.168.1.50:554/stream1

This is a very common cause of "RTSP works in one app but not another." One application may encode credentials automatically, while another expects the URL to already be valid.

Account permissions can block RTSP even when web login works

Logging into the camera web interface does not always prove that RTSP access is allowed. Many cameras have separate permissions for:

• Live view
• Remote streaming
• ONVIF access
• RTSP access
• Sub-stream access
• Main stream access
• Administrator settings

A user account may work in the browser but fail for RTSP DESCRIBE or PLAY. Some NVRs also require that the account has permission for the specific channel number.

If an NVR URL contains a channel path like /Streaming/Channels/101, the account may be valid but unauthorized for that channel. The result still looks like an authentication failure.

Wrong stream path can look like wrong credentials

Not every camera returns 404 Not Found for a bad RTSP path. Some devices return 401 Unauthorized first for every protected path, even if that path does not exist. After credentials are accepted, the camera may return 404, 454 Session Not Found, or another error.

That means a 401 does not prove the URL path is valid.

Common RTSP path patterns include:

• /stream1
• /stream2
• /live
• /h264
• /h265
• /cam/realmonitor?channel=1&subtype=0
• /Streaming/Channels/101
• /profile1/media.smp

If a camera keeps challenging credentials, test both the authentication result and the stream path. A protocol trace helps separate "credentials rejected" from "credentials accepted but path failed later."

Stale nonce and repeated Digest challenges

Digest authentication can include a stale=true flag. This means the username and password may be correct, but the nonce expired or is no longer accepted.

The camera may respond with:

WWW-Authenticate: Digest realm="IP Camera", nonce="new-value", stale=true

Ein korrekter Client sollte es mit der neuen Nonce erneut versuchen. Wenn der Client die Handhabung veralteter Nonce nicht versteht, kommt der Stream möglicherweise nie über die Authentifizierung hinaus weiter.

Dieses Problem tritt besonders häufig bei Kameras hinter Proxys, NVR-Relay-Ebenen oder Firmware auf, die die Digest-Authentifizierung lose implementiert. Es kann auch auftreten, wenn ein Client eine alte RTSP-Sitzung zu aggressiv wiederverwendet.

Authentifizierung bei DESCRIBE, SETUP und PLAY

Einige Kameras fordern nur die anfängliche Anfrage „DESCRIBE“ heraus. Andere stellen mehrere Methoden in Frage. Ein Stream kann folgendermaßen fehlschlagen:

1. „DESCRIBE“ ist nach der Authentifizierung erfolgreich.
2. „SETUP“ erhält einen weiteren „401 Unauthorized“.
3. Der Client sendet die Anmeldeinformationen für „SETUP“ nicht erneut.
4. Die Wiedergabe startet nie.

Das Gleiche kann bei „PLAY“ passieren. Eine Kamera benötigt möglicherweise „Authorization“-Header für alle geschützten Anfragen. Wenn der Client nur die erste Anfrage authentifiziert, wird möglicherweise anstelle eines Authentifizierungsfehlers der verwirrende Fehler „Stream kann nicht abgespielt werden“ angezeigt.

RTSP Inspector macht dies einfacher zu erkennen, da er die RTSP-Methodensequenz als erstklassigen Beweis behandelt. Die Frage ist nicht nur: „Hat die Anmeldung funktioniert?“ aber „Welche Methode wurde angefochten und hat der Kunde richtig geantwortet?“

Checkliste für RTSP 401-Authentifizierungsschleifen

Verwenden Sie beim Debuggen diese Reihenfolge:

1. Bestätigen Sie den genauen Benutzernamen und das Passwort mit einem bekannten Kamerakonto.
2. Sonderzeichen in der RTSP-URL URL-kodieren.
3. Testen Sie, ob die Kamera Digest- oder Basic-Authentifizierung erfordert.
4. Überprüfen Sie den Header „WWW-Authenticate“ auf Realm-, Nonce-, Algorithmus- und Stale-Flags.
5. Überprüfen Sie, ob der Client „Autorisierung“ bei „DESCRIBE“, „SETUP“ und „PLAY“ sendet.
6. Stellen Sie sicher, dass das Konto über RTSP- und Kanalberechtigungen verfügt, nicht nur über Web-UI-Berechtigungen.
7. Testen Sie die Haupt-Stream- und Sub-Stream-Pfade separat.
8. Vergleichen Sie den in der RTSP-Anfrage verwendeten URI mit dem in der Digest-Antwortberechnung verwendeten URI.
9. Überprüfen Sie, ob die Kamera-Firmware das Authentifizierungsverhalten geändert hat.
10. Vermeiden Sie die Diagnose von Mediencodecs, bis die RTSP-Authentifizierung tatsächlich abgeschlossen ist.

Was Google-Suchen normalerweise bedeuten

Wenn jemand nach „RTSP 401 Unauthorized IP camera“ sucht, muss er normalerweise wissen, ob die Anmeldeinformationen falsch sind. Wenn sie nach „RTSP Digest Authentication Loop“ suchen, haben sie in der Regel bereits das Passwort ausprobiert und benötigen Protokollnachweise. Wenn sie nach „Kamera RTSP fragt wiederholt nach Passwort“ suchen, müssen sie die Challenge- und Wiederholungssequenz überprüfen.

Die nützliche Antwort lautet nicht nur „Passwort zurücksetzen“. Die nützliche Antwort lautet:

• Hat die Kamera die Anfrage abgelehnt?
• Hat der Client mit dem erwarteten Authentifizierungsschema geantwortet?
• Hat die Kamera die Antwort akzeptiert?
• Ist eine spätere RTSP-Methode erneut fehlgeschlagen?
• Ist der Stream-Pfad oder die Kontoberechtigung nach der Anmeldung fehlgeschlagen?

Aus diesem Grund ist ein protokollorientiertes Tool für diese Problemklasse besser als ein reiner Spielertest.

Endgültige Diagnose

Eine RTSP-Authentifizierungsschleife wird durch den Abgleich von Anmeldeinformationen, URL-Kodierung, Authentifizierungsschema, Anforderungs-URI, Kontoberechtigung und Autorisierungsverhalten auf Methodenebene gelöst. Wenn die Ablaufverfolgung wiederholt „401 Unauthorized“-Antworten mit sich ändernden Nonces anzeigt, überprüfen Sie die Digest-Verarbeitung. Wenn eine erfolgreiche Authentifizierung gefolgt von Stream-Fehlern angezeigt wird, fahren Sie mit der URL-Pfad-, SDP-, Transport-, RTP- und Codec-Diagnose fort.

RTSP Inspector ist für diesen evidenzorientierten Arbeitsablauf konzipiert: Bestätigen Sie den RTSP-Steuerungspfad, bevor Sie davon ausgehen, dass die Kamera, der Player, der Codec oder das Netzwerk fehlerhaft sind.