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

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í:

1. DESCRIBE tiene éxito después de la autenticación.
2. SETUP recibe otro 401 no autorizado.
3. El cliente no reenvía las credenciales para "SETUP".
4. 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:

1. Confirme el nombre de usuario y la contraseña exactos con una cuenta de cámara conocida.
2. Caracteres especiales codificados en URL en la URL RTSP.
3. Pruebe si la cámara requiere autenticación Digest o Básica.
4. Inspeccione el encabezado WWW-Authenticate en busca de indicadores de dominio, nonce, algoritmo y obsoleto.
5. Verifique si el cliente envía "Autorización" en "DESCRIBE", "SETUP" y "PLAY".
6. Verifique que la cuenta tenga RTSP y permiso de canal, no solo permiso de interfaz de usuario web.
7. Pruebe las rutas de transmisión principal y secundaria por separado.
8. Compare el URI utilizado en la solicitud RTSP con el URI utilizado en el cálculo de la respuesta del resumen.
9. Compruebe si el firmware de la cámara ha cambiado el comportamiento de autenticación.
10. 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.