Depuración de autenticación implícita RTSP: 401 no autorizado, Nonce, Realm, Basic vs Digest y bucles de inicio de sesión de cámara

Las fallas de autenticación RTSP son algunos de los casos de soporte de cámaras IP más comunes. Los usuarios buscan "RTSP 401 no autorizado", "Error de autenticación RTSP Digest", "la cámara funciona en VLC pero no en NVR", "RTSP Basic vs Digest", "nonce obsoleto", "reino incorrecto" y "bucle de inicio de sesión de cámara IP" porque el síntoma es simple pero la causa está oculta dentro de los encabezados de solicitud y respuesta.

RTSP Inspector está diseñado para esta clase exacta de problema. Un jugador sólo puede decir "falló la autenticación". Un inspector de protocolo puede mostrar el primer "DESCRIBE" no autenticado, el desafío "WWW-Authenticate", la respuesta de "Autorización" del cliente, el valor nonce, el dominio, el URI utilizado en el cálculo del resumen y si la cámara rechaza la segunda solicitud.

Por qué la autenticación RTSP es confusa

Muchas cámaras no aceptan credenciales en la primera solicitud. El flujo normal de resumen es:

1. El cliente envía DESCRIBE sin autorización.
2. La cámara devuelve "401 no autorizado".
3. La cámara incluye WWW-Authenticate: Digest....
4. El cliente vuelve a calcular la respuesta del resumen.
5. El cliente envía DESCRIBE nuevamente con Autorización: Resumen....
6. La cámara acepta la solicitud o devuelve otro "401".

El primer "401" no es necesariamente un error. El "401" repetido después de que el cliente envía las credenciales de resumen es la evidencia importante.

Configuración de cámara básica vs resumen

Algunas cámaras exponen una configuración como:

• Autenticación básica
• Autenticación implícita
• Básico y resumen
• Sólo resumen
• Sin autenticación

Si el cliente solo admite Basic pero la cámara requiere Digest, la transmisión falla. Si el cliente envía un resumen pero la cámara está configurada para una variante específica del proveedor, la transmisión también puede fallar.

Términos de búsqueda que suelen describir este caso:

• "Cámara de autenticación básica RTSP"
• "Cámara de autenticación RTSP Digest"
• "VLC funciona pero la aplicación obtiene 401"
• "Error de autenticación de la cámara NVR"
• "ONVIF funciona pero falla el inicio de sesión RTSP"

La solución es no volver a adivinar la contraseña. Primero inspeccione qué esquema de autenticación anuncia realmente la cámara.

Desajustes de reino

El "reino" Digest es parte del cálculo de autenticación. Si el cliente calcula la respuesta con un dominio diferente al proporcionado por la cámara, la autenticación falla.

Esto puede suceder cuando:

• Un proxy reescribe el desafío.
• El firmware cambia el ámbito de la cámara después de la actualización.
• El cliente almacena en caché un desafío anterior.
• Varias cámaras comparten un nombre de host a través de un proxy inverso.
• La aplicación utiliza un perfil guardado de un modelo de cámara diferente.

RTSP Inspector debería hacer visible el ámbito para que la falla se vuelva concreta. La pregunta no es "¿la contraseña es incorrecta?" pero "¿qué dominio y URI exactos se utilizaron cuando se generó la respuesta del resumen?"

Problemas de nonce y nonce obsoleto

El nonce Digest es un valor proporcionado por el servidor. Algunas cámaras lo vencen rápidamente. Algunas cámaras lo reutilizan para una sesión. Algunas cámaras rechazan datos antiguos después de reiniciar, actualizar el firmware, desfase del tiempo o demasiados intentos fallidos.

Evidencias útiles:

• ¿La cámara incluye stale=true?
• ¿El cliente vuelve a intentarlo con un nuevo nonce?
• ¿La cámara envía un nonce diferente después de cada "401"?
• ¿La autenticación funciona una vez y falla más tarde?
• ¿La misma URL falla después de que la cámara ha estado inactiva?

Si la cámara devuelve un nuevo desafío pero el cliente sigue enviando el nonce anterior, la falla se debe al almacenamiento en caché del lado del cliente. Si la cámara devuelve desafíos repetidos sin ningún progreso útil, el problema puede ser el firmware de la cámara, la política de bloqueo o la falta de coincidencia de credenciales.

No coincide el URI dentro de la autenticación implícita

La autenticación implícita incluye el URI solicitado. Una discrepancia sutil puede interrumpir el inicio de sesión:

• El cliente se conecta a rtsp://192.168.1.10/stream1.
• La respuesta de resumen se calcula para /stream1.
• La cámara espera rtsp://192.168.1.10:554/stream1.
• El proxy reenvía /live/stream1.
• El cliente vuelve a intentarlo con una URL normalizada.

Por eso son importantes las líneas de solicitud sin procesar. Se deben comparar el URI DESCRIBE, el URI del encabezado Authorization y la ruta final de la cámara.

La contraseña no es la única causa

Los equipos de soporte suelen restablecer las contraseñas demasiado pronto. El "401 no autorizado" repetido también puede significar:

• Esquema de autenticación incorrecto.
• El dominio del resumen no coincide.
• Nonce rancio.
• La ruta URL no coincide.
• La cuenta de la cámara no tiene permiso RTSP.
• La cuenta se bloquea después de intentos fallidos de inicio de sesión.
• Los caracteres especiales en el nombre de usuario o la contraseña no están codificados en URL.
• El cliente eliminó las credenciales de la URL redirigida o reintentada.
• La cámara requiere la creación de un usuario ONVIF antes del acceso RTSP.

El mejor artículo sobre SEO debería decir esto claramente porque muchas búsquedas comienzan con la suposición de que la contraseña es incorrecta.

Caracteres especiales en URL RTSP

Las URL RTSP suelen contener credenciales en línea:

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.