2026-06-02

RTSP Digest Authentication Debugging: 401 Unauthorized, Nonce, Realm, Basic vs Digest und Camera Login Loops

So beheben Sie RTSP-Digest-Authentifizierungsfehler, nicht autorisierte 401-Schleifen, veraltete Nonce-Werte, Bereichskonflikte, Basic- und Digest-Kameraeinstellungen und Probleme mit URL-Anmeldeinformationen.

RTSP-Authentifizierungsfehler gehören zu den häufigsten Supportfällen für IP-Kameras. Benutzer suchen nach „RTSP 401 Unauthorized“, „RTSP Digest-Authentifizierung fehlgeschlagen“, „Kamera funktioniert in VLC, aber nicht in NVR“, „RTSP Basic vs Digest“, „stale nonce“, „falscher Bereich“ und „IP-Kamera-Anmeldeschleife“, weil das Symptom einfach ist, die Ursache jedoch in den Anforderungs- und Antwortheadern verborgen ist.

RTSP Inspector wurde genau für diese Problemklasse entwickelt. Ein Spieler darf nur „Authentifizierung fehlgeschlagen“ sagen. Ein Protokollinspektor kann das erste nicht authentifizierte „DESCRIBE“, die „WWW-Authenticate“-Herausforderung, die „Authorization“-Antwort des Clients, den Nonce-Wert, den Bereich, den in der Digest-Berechnung verwendeten URI und ob die Kamera die zweite Anfrage ablehnt, anzeigen.

Warum die RTSP-Authentifizierung verwirrend ist

Viele Kameras akzeptieren keine Zugangsdaten auf die erste Anfrage. Der normale Digest-Ablauf ist:

Der Client sendet „DESCRIBE“ ohne Autorisierung.
Die Kamera gibt „401 Unauthorized“ zurück.
Die Kamera enthält „WWW-Authenticate: Digest ...“.
Der Client berechnet die Digest-Antwort neu.
Der Client sendet erneut „DESCRIBE“ mit „Authorization: Digest ...“.
Die Kamera akzeptiert entweder die Anfrage oder gibt eine weitere „401“ zurück.

Das erste „401“ ist nicht unbedingt ein Fehler. Der wiederholte „401“ nach dem Senden der Digest-Anmeldeinformationen durch den Client ist der wichtige Beweis.

Grundlegende vs. Digest-Kameraeinstellungen

Einige Kameras machen eine Einstellung sichtbar wie:

Basisauthentifizierung
Digest-Authentifizierung
Basic und Digest
Nur Digest
Keine Authentifizierung

Wenn der Client nur Basic unterstützt, die Kamera jedoch Digest benötigt, schlägt der Stream fehl. Wenn der Client Digest sendet, die Kamera jedoch für eine herstellerspezifische Variante konfiguriert ist, schlägt der Stream möglicherweise ebenfalls fehl.

Suchbegriffe, die diesen Fall häufig beschreiben:

„RTSP Basic-Authentifizierungskamera“
„RTSP Digest Authentifizierungskamera“
„VLC funktioniert, aber die App erhält 401“
„Authentifizierung der NVR-Kamera fehlgeschlagen“
„ONVIF funktioniert, aber die RTSP-Anmeldung schlägt fehl“

Die Lösung besteht darin, das Passwort nicht erneut zu erraten. Überprüfen Sie zunächst, welches Authentifizierungsschema die Kamera tatsächlich ankündigt.

Reichskonflikte

Der Digest-„Bereich“ ist Teil der Authentifizierungsberechnung. Wenn der Client die Antwort mit einem anderen Realm als dem von der Kamera bereitgestellten berechnet, schlägt die Authentifizierung fehl.

Dies kann passieren, wenn:

Ein Proxy schreibt die Herausforderung neu.
Die Firmware ändert den Kamerabereich nach dem Upgrade.
Der Client speichert eine frühere Herausforderung zwischen.
Mehrere Kameras teilen sich über einen Reverse-Proxy einen Hostnamen.
Die App verwendet ein gespeichertes Profil eines anderen Kameramodells.

RTSP Inspector sollte den Bereich sichtbar machen, damit der Fehler konkret wird. Die Frage lautet nicht: „Ist das Passwort falsch?“ aber „welcher genaue Bereich und URI wurden verwendet, als die Digest-Antwort generiert wurde?“

Nonce- und veraltete Nonce-Probleme

Die Digest-Nonce ist ein vom Server bereitgestellter Wert. Bei einigen Kameras läuft es schnell ab. Einige Kameras verwenden es für eine Sitzung wieder. Einige Kameras lehnen alte Nonces nach einem Neustart, einem Firmware-Update, einer Zeitverschiebung oder zu vielen Fehlversuchen ab.

Nützliche Beweise:

Enthält die Kamera „stale=true“?
Versucht der Client es erneut mit einer neuen Nonce?
Sendet die Kamera nach jedem „401“ eine andere Nonce?
Funktioniert die Authentifizierung einmal und schlägt dann später fehl?
Schlägt dieselbe URL fehl, nachdem die Kamera inaktiv war?

Wenn die Kamera eine neue Herausforderung zurückgibt, der Client jedoch weiterhin die alte Nonce sendet, liegt der Fehler am clientseitigen Caching. Wenn die Kamera wiederholt Aufforderungen ohne sinnvollen Fortschritt zurückgibt, liegt das Problem möglicherweise an der Kamera-Firmware, an der Sperrrichtlinie oder an einer Nichtübereinstimmung der Anmeldeinformationen.

URI-Konflikt innerhalb der Digest-Authentifizierung

Die Digest-Authentifizierung umfasst den angeforderten URI. Eine subtile Diskrepanz kann dazu führen, dass die Anmeldung unterbrochen wird:

Der Client stellt eine Verbindung zu „rtsp://192.168.1.10/stream1“ her.
Die Digest-Antwort wird für „/stream1“ berechnet.
Die Kamera erwartet „rtsp://192.168.1.10:554/stream1“.
Proxy leitet „/live/stream1“ weiter.
Der Client versucht es erneut mit einer normalisierten URL.

Aus diesem Grund sind rohe Anforderungszeilen wichtig. Der „DESCRIBE“-URI, der „Authorization“-Header-URI und der endgültige Kamerapfad sollten verglichen werden.

Das Passwort ist nicht die einzige Ursache

Support-Teams setzen Passwörter oft zu früh zurück. Wiederholtes „401 Unauthorized“ kann auch bedeuten:

Falsches Authentifizierungsschema.
Digest-Realm-Konflikt.
Abgestandene Nonce.
URL-Pfad stimmt nicht überein.
Das Kamerakonto verfügt über keine RTSP-Berechtigung.
Nach fehlgeschlagenen Anmeldeversuchen wird das Konto gesperrt.
Sonderzeichen im Benutzernamen oder Passwort sind nicht URL-kodiert.
Der Client hat Anmeldeinformationen von der umgeleiteten oder erneut versuchten URL entfernt.
Für die Kamera ist vor dem RTSP-Zugriff die Erstellung eines ONVIF-Benutzers erforderlich.

Der beste SEO-Artikel sollte dies klar zum Ausdruck bringen, da viele Suchanfragen mit der Annahme beginnen, dass das Passwort falsch ist.

Sonderzeichen in RTSP-URLs

RTSP-URLs enthalten häufig Inline-Anmeldeinformationen:

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.

Reproduzierbarer Nachweis für „RTSP Digest Authentication Debugging: 401 Unauthorized, Nonce, Realm, Basic vs Digest und Camera Login Loops“

Die direkte Antwort lautet: Eine Kamerastream-Störung wird nicht durch ein einzelnes Player-Fenster oder einen Statuscode bewiesen. Die belastbare Diagnose verbindet RTSP-Anfrage und Antwort, die ausgehandelte Transportart, eine gültige Session und anschließend RTP-Sequenznummern, Zeitstempel sowie RTCP-Belege. Beginnen Sie bei „RTSP Digest Authentication Debugging: 401 Unauthorized, Nonce, Realm, Basic vs Digest und Camera Login Loops“ an der Schicht, die dem sichtbaren Symptom am nächsten liegt, behalten Sie aber eine gemeinsame Zeitleiste, damit Steuerungs-, Netzwerk- und Decoderfehler nicht vermischt werden.

Erstellen Sie vor Änderungen an Kamera, Firewall oder VMS einen kleinen Ausgangstest. Notieren Sie die bereinigte RTSP-URL, Uhrzeit, Pfad, angeforderten Transport, Serverantwort und den Zeitpunkt des ersten Medienpakets. Testen Sie UDP und TCP interleaved getrennt, sofern das Gerät beides anbietet. Ändern Sie nicht gleichzeitig Pfad, Zugangsdaten und Transport. Sonst zeigt ein erfolgreicher zweiter Versuch nicht, welche Variable den Fehler beseitigt hat.

Prüfschicht	Zu sichernder Nachweis	Entscheidungsfrage
RTSP	Methode, Status, Header, CSeq und Session	Hat der Server genau diese Operation akzeptiert?
SDP	control, Payload-Typ, Clock Rate und Codec	Beschreibt der Server den erwarteten Medientrack?
Transport	client_port, server_port oder interleaved	Verwenden beide Seiten denselben Kanal?
RTP	SSRC, Sequenz, Timestamp und Marker	Kommen Medieneinheiten in erklärbarer Reihenfolge an?
RTCP	Sender Report, CNAME und BYE	Sind Uhr, Identität und Sitzungsende nachvollziehbar?
Decoder	SPS/PPS/VPS und Packetization Mode	Lassen sich die angekommenen Nutzdaten initialisieren?

Trennen Sie „keine Medien angekommen“ von „Medien angekommen, aber nicht decodierbar“. Fehlt RTP nach erfolgreichem SETUP und PLAY, prüfen Sie UDP-Pfad, NAT, Firewall und einen abweichenden Transport-Reply. RTP mit Sequenzlücken belegt Verlust oder Reordering. Eine lückenlose Folge ohne Bild verschiebt die Prüfung auf Payload-Typ, Clock Rate, Frame-Grenzen und H.264-/H.265-Parameter. Diese Grenze ist aussagekräftiger als eine allgemeine Player-Meldung.

Wie formuliert man eine zitierfähige Kurzantwort?

Nennen Sie in drei Sätzen die letzte erfolgreiche Operation, den ersten fehlgeschlagenen Beleg und den nächsten trennenden Test. Beispielstruktur: „DESCRIBE, SETUP und PLAY waren erfolgreich. An den angekündigten Client-Ports kam kein RTP an. Ein Test über TCP interleaved trennt UDP-Blockierung von einem falschen Medienpfad.“ Behaupten Sie keinen Kamera- oder Netzwerkdefekt ohne passende Antwort oder Paketbeleg.

Welche Angaben machen den Fehler reproduzierbar?

Sichern Sie OPTIONS, DESCRIBE, SETUP und PLAY samt SDP, Transport-Antwort und bereinigter Session-ID. Für Medien genügen zunächst SSRC, erste und letzte Sequenznummer, Clock Rate, Lückenanzahl und Aufnahmedauer. Vermerken Sie, ob VLC oder ein anderes VMS funktioniert. Das ist ein Differenztest, aber kein Beweis, dass der erfolgreiche Client jede Protokollgrenze korrekt behandelt.

Wann liegt der nächste Test auf Server- oder Clientseite?

Prüfen Sie den Server, wenn er eine Methode klar ablehnt, einen nicht vorhandenen control-Pfad liefert, das Transportangebot widersprüchlich beantwortet oder SSRC beziehungsweise Clock Rate ohne erklärten Übergang wechselt. Prüfen Sie den Client, wenn er einen alten Nonce wiederverwendet, Session-Header verliert, UDP anfordert ohne Ports zu öffnen oder jedes NAL-Ende als Access-Unit-Ende behandelt. Für Zwischenfehler bleiben Zeitstempel und Paketfolge unverzichtbar.

Wie wird der Bericht vor der Übergabe geprüft?

Wiederholen Sie den Test mit einer frischen Verbindung und vergleichen Sie beide Abläufe nur bis zur ersten Abweichung. Entfernen Sie Passwörter und vollständige Authorization-Werte. Verknüpfen Sie jede Aussage mit CSeq, Sequenznummer oder Timestamp. Der passende RTSP-Leitfaden erklärt angrenzende Schritte; RTSP Inspector dient als lokaler Arbeitsbereich zum Testen eines RTSP-Streams und zum Sammeln der Belege, ohne den Kamerastream zu einem öffentlichen Dienst hochzuladen.

Direkte Antwort und Abnahmegrenze

Die kurze Antwort zu „RTSP Digest Authentication Debugging: 401 Unauthorized, Nonce, Realm, Basic vs Digest und Camera Login Loops“ lautet: So beheben Sie RTSP-Digest-Authentifizierungsfehler, nicht autorisierte 401-Schleifen, veraltete Nonce-Werte, Bereichskonflikte, Basic- und Digest-Kameraeinstellungen und Probleme mit URL-Anmeldeinformationen. Behandeln Sie diese Aussage als zu prüfendes Ergebnis und nicht als Versprechen für jede Eingabe, jedes Gerät, jedes Projekt oder jede Umgebung. Ein vollständiges Ergebnis dokumentiert Ausgangszustand, exakte Aktion, sichtbare Ausgabe und die Bedingung, die den Abschluss in RTSP Inspector belegt.

Evidenzorientiertes Vorgehen

Beginnen Sie mit einem kleinen, wiederholbaren Fall, bevor Sie ein vollständiges Projekt verändern. Protokollieren Sie Anwendungsversion, Betriebssystem, Eingabe- oder Geräteidentität, relevante Einstellungen und erwartetes Ergebnis. Führen Sie eine bewusste Aktion aus, bewahren Sie den ersten unerwarteten Übergang und vergleichen Sie möglichst mit einem bekannten guten Lauf. Mehrere gleichzeitige Änderungen verdecken, welche Bedingung den Fehler erzeugt oder behoben hat.

Prüfpunkt 1: RTSP Digest Authentication Debugging: 401 Unauthorized, Nonce, Realm, Basic vs Digest und

Prüfen Sie „RTSP Digest Authentication Debugging: 401 Unauthorized, Nonce, Realm, Basic vs Digest und Camera Login Loops“ mit der kleinsten repräsentativen Eingabe. Lassen Sie unabhängige Einstellungen unverändert, wiederholen Sie dieselbe Aktion und kontrollieren Sie das Ergebnis nach erneutem Öffnen oder Verbinden. Ein Bild ist schwächer als ein Nachweis mit Eingabe, Einstellung, Aktion, Ausgabe und Zeitpunkt.

Prüfpunkt 2: So beheben Sie RTSP-Digest-Authentifizierungsfehler, nicht autorisierte 401-Schleifen, ver

Ist „So beheben Sie RTSP-Digest-Authentifizierungsfehler, nicht autorisierte 401-Schleifen, veraltete Nonce-Werte, Bereichskonflikte, Basic- und Digest-Kam“ mehrdeutig, vergleichen Sie einen bekannten guten und einen fehlerhaften Fall unter gleichen Bedingungen. Markieren Sie die erste relevante Abweichung statt aller späteren Symptome. Diese Grenze führt meist zu einer klareren Supportanfrage und einem sichereren Experiment.

Prüfpunkt 3: Warum die RTSP-Authentifizierung verwirrend ist

Prüfen Sie „Warum die RTSP-Authentifizierung verwirrend ist“ mit der kleinsten repräsentativen Eingabe. Lassen Sie unabhängige Einstellungen unverändert, wiederholen Sie dieselbe Aktion und kontrollieren Sie das Ergebnis nach erneutem Öffnen oder Verbinden. Ein Bild ist schwächer als ein Nachweis mit Eingabe, Einstellung, Aktion, Ausgabe und Zeitpunkt.

Prüfpunkt 4: Grundlegende vs. Digest-Kameraeinstellungen

Ist „Grundlegende vs. Digest-Kameraeinstellungen“ mehrdeutig, vergleichen Sie einen bekannten guten und einen fehlerhaften Fall unter gleichen Bedingungen. Markieren Sie die erste relevante Abweichung statt aller späteren Symptome. Diese Grenze führt meist zu einer klareren Supportanfrage und einem sichereren Experiment.

Prüfpunkt 5: Reichskonflikte

Prüfen Sie „Reichskonflikte“ mit der kleinsten repräsentativen Eingabe. Lassen Sie unabhängige Einstellungen unverändert, wiederholen Sie dieselbe Aktion und kontrollieren Sie das Ergebnis nach erneutem Öffnen oder Verbinden. Ein Bild ist schwächer als ein Nachweis mit Eingabe, Einstellung, Aktion, Ausgabe und Zeitpunkt.

Prüfpunkt 6: Nonce- und veraltete Nonce-Probleme

Ist „Nonce- und veraltete Nonce-Probleme“ mehrdeutig, vergleichen Sie einen bekannten guten und einen fehlerhaften Fall unter gleichen Bedingungen. Markieren Sie die erste relevante Abweichung statt aller späteren Symptome. Diese Grenze führt meist zu einer klareren Supportanfrage und einem sichereren Experiment.

Prüfpunkt 7: URI-Konflikt innerhalb der Digest-Authentifizierung

Prüfen Sie „URI-Konflikt innerhalb der Digest-Authentifizierung“ mit der kleinsten repräsentativen Eingabe. Lassen Sie unabhängige Einstellungen unverändert, wiederholen Sie dieselbe Aktion und kontrollieren Sie das Ergebnis nach erneutem Öffnen oder Verbinden. Ein Bild ist schwächer als ein Nachweis mit Eingabe, Einstellung, Aktion, Ausgabe und Zeitpunkt.

Prüfpunkt 8: Das Passwort ist nicht die einzige Ursache

Ist „Das Passwort ist nicht die einzige Ursache“ mehrdeutig, vergleichen Sie einen bekannten guten und einen fehlerhaften Fall unter gleichen Bedingungen. Markieren Sie die erste relevante Abweichung statt aller späteren Symptome. Diese Grenze führt meist zu einer klareren Supportanfrage und einem sichereren Experiment.

Prüfpunkt 9: Sonderzeichen in RTSP-URLs

Prüfen Sie „Sonderzeichen in RTSP-URLs“ mit der kleinsten repräsentativen Eingabe. Lassen Sie unabhängige Einstellungen unverändert, wiederholen Sie dieselbe Aktion und kontrollieren Sie das Ergebnis nach erneutem Öffnen oder Verbinden. Ein Bild ist schwächer als ein Nachweis mit Eingabe, Einstellung, Aktion, Ausgabe und Zeitpunkt.

Prüfpunkt 10: What to capture

Ist „What to capture“ mehrdeutig, vergleichen Sie einen bekannten guten und einen fehlerhaften Fall unter gleichen Bedingungen. Markieren Sie die erste relevante Abweichung statt aller späteren Symptome. Diese Grenze führt meist zu einer klareren Supportanfrage und einem sichereren Experiment.

Abnahmematrix

Prüfpunkt	Aufzubewahrender Nachweis	Passkriterium
RTSP Digest Authentication Debugging: 401 Unauthorized, Nonce, Realm, Basic vs Digest und Camera Login Loops	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
So beheben Sie RTSP-Digest-Authentifizierungsfehler, nicht autorisierte 401-Schleifen, veraltete Nonce-Werte, Bereichsko	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Warum die RTSP-Authentifizierung verwirrend ist	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Grundlegende vs. Digest-Kameraeinstellungen	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Reichskonflikte	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren
Nonce- und veraltete Nonce-Probleme	Ausgangszustand, eine Aktion und Ergebniszustand	Eine zweite Person kann das Ergebnis reproduzieren

Fehlerisolierung, Recovery und Übergabe

Stoppen Sie beim ersten fehlerhaften Übergang. Bewahren Sie Quelle, Projekt, Session oder Capture und erstellen Sie vor destruktiven Änderungen eine Kopie. Ändern Sie pro Experiment nur eine Variable. Ein kompletter erneuter Lauf nach mehreren Änderungen kann anders enden, ohne die Ursache zu erklären.

Unterscheiden Sie fehlende Evidenz von Evidenz für ein Fehlen. Eine leere Ansicht kann auf falsche Eingabe, Scope, Filter, Berechtigung, Gerät, Zeitbereich oder Projektzustand hinweisen. Beweisen Sie Aufnahme oder Import, bevor Sie Decoder, Editor, Bericht oder Export interpretieren.

Öffnen Sie vor der Übergabe das dauerhafte Artefakt erneut und prüfen Sie Anfang, Entscheidungsstelle und Ende. Dokumentieren Sie Version, Plattform, Konfiguration, Erwartung, Beobachtung und kleinste Reproduktion. Entfernen oder schwärzen Sie sensible Daten und prüfen Sie die Berechtigung des Empfängers.

Fragen und Antworten

Wie beginnt man am schnellsten zuverlässig?

Verwenden Sie den kleinsten repräsentativen Fall, notieren Sie das erwartete Ergebnis und ändern Sie nur eine Variable. Beweisen Sie den Grundpfad, bevor Filter, Effekte, Bearbeitungen, Automatisierung oder größere Quellen hinzukommen.

Welche Evidenz sollte gespeichert werden?

Bewahren Sie Eingabeidentität, Version, Plattform, Einstellungen, exakte Aktion, ersten unerwarteten Übergang und Endausgabe. Projekt, Session, Bericht oder Export müssen geschlossen und erneut geöffnet werden.

Wann sollte das Verfahren wiederholt werden?

Wiederholen Sie es nach relevanten Änderungen an Anwendung, Betriebssystem, Treiber, Firmware, Modell, Quelle oder Workflow. Behalten Sie den früher akzeptierten Fall als unveränderte Vergleichsbasis.

Wann ist die Aufgabe übergabefähig?

Wenn eine autorisierte zweite Person Eingabe und Aktion erkennt, dasselbe Ergebnis reproduziert, verbleibende Grenzen versteht und das gespeicherte Artefakt ohne undokumentierten lokalen Zustand öffnen kann.