2026-06-02

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

Cómo solucionar problemas de fallas de autenticación RTSP Digest, bucles 401 no autorizados, valores nonce obsoletos, discrepancias de reino, configuración de cámara básica versus implícita y problemas de credenciales URL.

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:

El cliente envía DESCRIBE sin autorización.
La cámara devuelve "401 no autorizado".
La cámara incluye WWW-Authenticate: Digest....
El cliente vuelve a calcular la respuesta del resumen.
El cliente envía DESCRIBE nuevamente con Autorización: Resumen....
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:

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.

Evidencia reproducible para «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»

La respuesta directa es que una avería de vídeo no se demuestra con una ventana negra ni con un solo código de estado. Un diagnóstico fiable conecta la petición y la respuesta RTSP, el transporte negociado, una sesión válida y después los números de secuencia RTP, las marcas de tiempo y las señales RTCP. Para «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», empieza por la capa más cercana al síntoma visible, pero conserva una cronología común para no mezclar un fallo de control con uno de red o decodificación.

Antes de cambiar la cámara, el firewall o el VMS, crea una prueba base pequeña. Anota la URL RTSP sin contraseña, la hora, la ruta, el transporte solicitado, la respuesta del servidor y el instante del primer paquete multimedia. Prueba UDP y TCP interleaved por separado cuando el equipo ofrezca ambos. No cambies ruta, credenciales y transporte a la vez; si el segundo intento funciona, necesitas saber qué variable produjo la diferencia.

Capa	Evidencia que se debe guardar	Pregunta de decisión
RTSP	método, estado, cabeceras, CSeq y Session	¿El servidor aceptó exactamente la operación?
SDP	control, payload type, clock rate y codec	¿El servidor describió la pista esperada?
Transport	client_port, server_port o interleaved	¿Ambos extremos usan el mismo canal?
RTP	SSRC, secuencia, timestamp y marker	¿Las unidades llegan en un orden explicable?
RTCP	sender report, CNAME y BYE	¿Se pueden relacionar reloj, identidad y final?
Decoder	SPS/PPS/VPS y packetization mode	¿El payload recibido permite iniciar el decoder?

Separa «no llega multimedia» de «llega multimedia que no se puede decodificar». Si no aparece RTP después de SETUP y PLAY correctos, revisa UDP, NAT, firewall y una respuesta Transport distinta de la oferta. RTP con huecos de secuencia prueba pérdida o reordenación. Una secuencia continua sin imagen desplaza la investigación hacia payload type, clock rate, límites de cuadro y parámetros H.264 o H.265. Esta frontera es más útil que el mensaje general del reproductor.

¿Cómo se redacta una respuesta que pueda citarse?

Usa tres frases: última operación correcta, primera evidencia que falla y siguiente prueba que separa dos causas. Ejemplo: «DESCRIBE, SETUP y PLAY terminan correctamente; no llega RTP a los puertos anunciados por el cliente; repetir por TCP interleaved separará el bloqueo UDP de una ruta multimedia incorrecta». No atribuyas el fallo a la cámara o a la red sin una respuesta o un paquete que marque ese límite.

¿Qué hace reproducible el caso?

Guarda OPTIONS, DESCRIBE, SETUP y PLAY, el SDP, la respuesta Transport y el identificador Session saneado. Para RTP registra SSRC, primer y último número de secuencia, clock rate, huecos y duración. Indica si VLC u otro VMS funciona, pero úsalo como comparación controlada, no como prueba de que el cliente exitoso interpreta todas las reglas de forma correcta.

¿Cuándo se investiga el servidor y cuándo el cliente?

Mira el servidor si rechaza un método, entrega un control URL inexistente, responde con un transporte incompatible o cambia SSRC o reloj sin transición. Mira el cliente si reutiliza un nonce caducado, pierde Session, solicita UDP sin abrir los puertos o interpreta cada final NAL como final de access unit. Si el límite está entre ambos, conserva paquete y hora en cada afirmación.

¿Cómo se revisa el informe?

Repite desde una conexión nueva y compara las dos cronologías solo hasta la primera diferencia. Elimina contraseñas y valores Authorization completos. Relaciona cada conclusión con CSeq, secuencia o timestamp. Continúa con la guía RTSP relacionada y usa RTSP Inspector para probar un stream RTSP y recoger evidencia de forma local, sin subir el vídeo de la cámara a un servicio público.

Respuesta directa y límite de aceptación

La respuesta breve a «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» es: Cómo solucionar problemas de fallas de autenticación RTSP Digest, bucles 401 no autorizados, valores nonce obsoletos, discrepancias de reino, configuración de cámara básica versus implícita y problemas de credenciales URL. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en RTSP Inspector.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Depuración de autenticación implícita RTSP: 401 no autorizado, Nonce, Realm, Basic vs Dige

Compruebe «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» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 2: Cómo solucionar problemas de fallas de autenticación RTSP Digest, bucles 401 no autorizado

Si «Cómo solucionar problemas de fallas de autenticación RTSP Digest, bucles 401 no autorizados, valores nonce obsoletos, discrepancias de reino, configur» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 3: Por qué la autenticación RTSP es confusa

Compruebe «Por qué la autenticación RTSP es confusa» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 4: Configuración de cámara básica vs resumen

Si «Configuración de cámara básica vs resumen» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 5: Desajustes de reino

Compruebe «Desajustes de reino» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 6: Problemas de nonce y nonce obsoleto

Si «Problemas de nonce y nonce obsoleto» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 7: No coincide el URI dentro de la autenticación implícita

Compruebe «No coincide el URI dentro de la autenticación implícita» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 8: La contraseña no es la única causa

Si «La contraseña no es la única causa» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Punto de control 9: Caracteres especiales en URL RTSP

Compruebe «Caracteres especiales en URL RTSP» con la entrada representativa más pequeña. Mantenga iguales los ajustes no relacionados, repita la misma acción y revise el resultado después de reabrir o reconectar. Una captura aislada es más débil que un registro con entrada, ajuste, acción, salida y hora.

Punto de control 10: What to capture

Si «What to capture» es ambiguo, compare un caso bueno y otro fallido bajo condiciones equivalentes. Marque la primera diferencia significativa en vez de enumerar todos los síntomas posteriores. Ese límite suele producir una consulta más clara y un experimento más seguro.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Depuración de autenticación implícita RTSP: 401 no autorizado, Nonce, Realm, Basic vs Digest y bucles de inicio de sesió	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo solucionar problemas de fallas de autenticación RTSP Digest, bucles 401 no autorizados, valores nonce obsoletos, di	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Por qué la autenticación RTSP es confusa	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Configuración de cámara básica vs resumen	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Desajustes de reino	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Problemas de nonce y nonce obsoleto	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: