2026-06-02

Bucle de autenticación RTSP: solución de errores 401 no autorizados, de autenticación implícita y de inicio de sesión de la cámara

Una guía práctica para bucles no autorizados RTSP 401, autenticación implícita, autenticación básica, respuestas nonce obsoletas, usuarios de cámara incorrectos y problemas de credenciales URL.

Uno de los problemas más comunes de la cámara RTSP parece simple al principio: "el cliente se conecta, la cámara responde, pero la transmisión nunca comienza. El registro repite "401 No autorizado", el espectador solicita una contraseña nuevamente o la aplicación dice que la URL RTSP es incorrecta aunque el nombre de usuario y la contraseña parecen correctos." Este es un bucle de autenticación RTSP. Ocurre cuando la cámara desafía al cliente, el cliente envía credenciales y la cámara las rechaza o vuelve a preguntar. La causa principal puede ser una contraseña incorrecta, pero también puede ser una falta de coincidencia en la autenticación implícita, manejo de nonce obsoleto, permisos de cuenta, caracteres especiales en la URL, una ruta de transmisión incorrecta o una cámara que requiere autenticación en DESCRIBE, SETUP y PLAY por separado.

RTSP Inspector es útil aquí porque la evidencia importante se encuentra en el intercambio de control RTSP. Un reproductor multimedia a menudo oculta los detalles del desafío y el reintento detrás de un único error de inicio de sesión. Una vista de diagnóstico de protocolo puede mostrar si la falla ocurrió en OPTIONS, DESCRIBE, SETUP o PLAY, y si la cámara devolvió WWW-Authenticate, stale=true o un desafío de dominio repetido.

Qué significa una respuesta no autorizada RTSP 401

En RTSP, "401 no autorizado" generalmente significa "autenticación requerida" en lugar de "el servidor es inaccesible". Una cámara puede responder a una solicitud no autenticada como esta:

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

Un cliente correcto debería volver a intentarlo con el nuevo nonce. Si el cliente no comprende el manejo del nonce obsoleto, es posible que la transmisión nunca pase de la autenticación.

Este problema es especialmente común con cámaras detrás de servidores proxy, capas de retransmisión de NVR o firmware que implementa la autenticación Digest de forma flexible. También puede aparecer cuando un cliente reutiliza una sesión RTSP antigua de manera demasiado agresiva.

Autenticación en DESCRIBIR, CONFIGURAR y JUGAR

Algunas cámaras solo cuestionan la solicitud inicial "DESCRIBIR". Otros desafían múltiples métodos. Una transmisión puede fallar así:

DESCRIBE tiene éxito después de la autenticación.
SETUP recibe otro 401 no autorizado.
El cliente no reenvía las credenciales para "SETUP".
La reproducción nunca comienza.

Lo mismo puede suceder en PLAY. Una cámara puede requerir encabezados de "Autorización" en todas las solicitudes protegidas. Si el cliente autentica solo la primera solicitud, puede mostrar un error confuso de "no se puede reproducir la transmisión" en lugar de un error de autenticación.

RTSP Inspector hace que esto sea más fácil de ver porque trata la secuencia del método RTSP como evidencia de primera clase. La pregunta no es sólo "¿funcionó el inicio de sesión?" pero "¿qué método fue cuestionado y respondió correctamente el cliente?"

Lista de verificación para bucles de autenticación RTSP 401

Utilice este orden al depurar:

Confirme el nombre de usuario y la contraseña exactos con una cuenta de cámara conocida.
Caracteres especiales codificados en URL en la URL RTSP.
Pruebe si la cámara requiere autenticación Digest o Básica.
Inspeccione el encabezado WWW-Authenticate en busca de indicadores de dominio, nonce, algoritmo y obsoleto.
Verifique si el cliente envía "Autorización" en "DESCRIBE", "SETUP" y "PLAY".
Verifique que la cuenta tenga RTSP y permiso de canal, no solo permiso de interfaz de usuario web.
Pruebe las rutas de transmisión principal y secundaria por separado.
Compare el URI utilizado en la solicitud RTSP con el URI utilizado en el cálculo de la respuesta del resumen.
Compruebe si el firmware de la cámara ha cambiado el comportamiento de autenticación.
Evite diagnosticar códecs multimedia hasta que se haya completado la autenticación RTSP.

Lo que suelen significar las búsquedas en Google

Cuando alguien busca "cámara IP no autorizada RTSP 401", normalmente necesita saber si la credencial es incorrecta. Cuando buscan "bucle de autenticación RTSP Digest", generalmente ya probaron la contraseña y necesitan evidencia de protocolo. Cuando buscan "la cámara RTSP solicita la contraseña repetidamente", deben inspeccionar el desafío y volver a intentar la secuencia.

La respuesta útil no es simplemente "restablecer la contraseña". La respuesta útil es:

¿La cámara cuestionó la solicitud?
¿El cliente respondió con el esquema de autenticación esperado?
¿La cámara aceptó la respuesta?
¿Volvió a fallar un método RTSP posterior?
¿Falló la ruta de transmisión o el permiso de la cuenta después de iniciar sesión?

Es por eso que una herramienta orientada al protocolo es mejor que una prueba exclusiva para el jugador para este tipo de problemas.

Diagnóstico final

Un bucle de autenticación RTSP se resuelve haciendo coincidir credenciales, codificación de URL, esquema de autenticación, URI de solicitud, permiso de cuenta y comportamiento de autorización a nivel de método. Si el seguimiento muestra respuestas repetidas "401 no autorizadas" con nonces cambiantes, inspeccione el manejo del resumen. Si muestra un éxito de autenticación seguido de errores de transmisión, continúe con la ruta URL, SDP, transporte, RTP y diagnóstico de códec.

RTSP Inspector está diseñado para ese flujo de trabajo que prioriza la evidencia: confirme la ruta de control RTSP antes de asumir que la cámara, el reproductor, el códec o la red tienen la culpa.

Evidencia reproducible para «Bucle de autenticación RTSP: solución de errores 401 no autorizados, de autenticación implícita y de inicio de sesión de la 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 «Bucle de autenticación RTSP: solución de errores 401 no autorizados, de autenticación implícita y de inicio de sesión de la 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 «Bucle de autenticación RTSP: solución de errores 401 no autorizados, de autenticación implícita y de inicio de sesión de la cámara» es: Una guía práctica para bucles no autorizados RTSP 401, autenticación implícita, autenticación básica, respuestas nonce obsoletas, usuarios de cámara incorrectos 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: Bucle de autenticación RTSP: solución de errores 401 no autorizados, de autenticación impl

Cierre «Bucle de autenticación RTSP: solución de errores 401 no autorizados, de autenticación implícita y de inicio de sesión de la cámara» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 2: Una guía práctica para bucles no autorizados RTSP 401, autenticación implícita, autenticac

Para «Una guía práctica para bucles no autorizados RTSP 401, autenticación implícita, autenticación básica, respuestas nonce obsoletas, usuarios de cámara i», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 3: Qué significa una respuesta no autorizada RTSP 401

Cierre «Qué significa una respuesta no autorizada RTSP 401» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 4: Basic authentication vs Digest authentication

Para «Basic authentication vs Digest authentication», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 5: Special characters in RTSP URL credentials

Cierre «Special characters in RTSP URL credentials» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 6: Account permissions can block RTSP even when web login works

Para «Account permissions can block RTSP even when web login works», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 7: Wrong stream path can look like wrong credentials

Cierre «Wrong stream path can look like wrong credentials» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 8: Stale nonce and repeated Digest challenges

Para «Stale nonce and repeated Digest challenges», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 9: Autenticación en DESCRIBIR, CONFIGURAR y JUGAR

Cierre «Autenticación en DESCRIBIR, CONFIGURAR y JUGAR» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 10: Lista de verificación para bucles de autenticación RTSP 401

Para «Lista de verificación para bucles de autenticación RTSP 401», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Bucle de autenticación RTSP: solución de errores 401 no autorizados, de autenticación implícita y de inicio de sesión de	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Una guía práctica para bucles no autorizados RTSP 401, autenticación implícita, autenticación básica, respuestas nonce o	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Qué significa una respuesta no autorizada RTSP 401	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Basic authentication vs Digest authentication	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Special characters in RTSP URL credentials	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Account permissions can block RTSP even when web login works	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: