Loop de autenticação RTSP: corrigindo falhas 401 não autorizadas, Digest Auth e login da câmera

Um dos problemas mais comuns da câmera RTSP parece simples à primeira vista: "o cliente se conecta, a câmera responde, mas o stream nunca inicia. O log repete 401 Unauthorized, o visualizador pede uma senha novamente ou o aplicativo diz que o URL RTSP está errado, mesmo que o nome de usuário e a senha pareçam corretos." Este é um loop de autenticação RTSP. Acontece quando a câmera desafia o cliente, o cliente envia credenciais e a câmera as rejeita ou pede novamente. A causa raiz pode ser uma senha incorreta, mas também pode ser uma incompatibilidade de autenticação Digest, tratamento de nonce obsoleto, permissões de conta, caracteres especiais na URL, um caminho de transmissão incorreto ou uma câmera que requer autenticação em DESCRIBE, SETUP e PLAY separadamente.

O RTSP Inspector é útil aqui porque a evidência importante está na troca de controle RTSP. Um reprodutor de mídia geralmente oculta os detalhes do desafio e da nova tentativa por trás de um único erro de login. Uma visualização de diagnóstico de protocolo pode mostrar se a falha ocorreu em OPTIONS, DESCRIBE, SETUP ou PLAY e se a câmera retornou WWW-Authenticate, stale=true ou um desafio de reino repetido.

O que significa uma resposta RTSP 401 não autorizada

No RTSP, 401 Unauthorized geralmente significa "autenticação necessária" em vez de "o servidor está inacessível". Uma câmera pode responder a uma solicitação não 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

Um cliente correto deve tentar novamente com o novo nonce. Se o cliente não entender o tratamento de nonce obsoleto, o fluxo poderá nunca progredir além da autenticação.

Esse problema é especialmente comum com câmeras atrás de proxies, camadas de retransmissão NVR ou firmware que implementa a autenticação Digest de maneira flexível. Também pode aparecer quando um cliente reutiliza uma sessão RTSP antiga de forma muito agressiva.

Autenticação em DESCRIBE, SETUP e PLAY

Algumas câmeras desafiam apenas a solicitação inicial DESCRIBE. Outros desafiam vários métodos. Um fluxo pode falhar assim:

1. DESCRIBE é bem-sucedido após a autenticação.
2. SETUP recebe outro 401 Unauthorized.
3. O cliente não reenvia credenciais para SETUP.
4. A reprodução nunca começa.

O mesmo pode acontecer em PLAY. Uma câmera pode exigir cabeçalhos Autorização em todas as solicitações protegidas. Se o cliente autenticar apenas a primeira solicitação, poderá mostrar um erro confuso "não é possível reproduzir o stream" em vez de um erro de autenticação.

O RTSP Inspector torna isso mais fácil de ver porque trata a sequência do método RTSP como evidência de primeira classe. A questão não é apenas "o login funcionou?" mas "qual método foi desafiado e o cliente respondeu corretamente?"

Lista de verificação para loops de autenticação RTSP 401

Use esta ordem ao depurar:

1. Confirme o nome de usuário e a senha exatos com uma conta de câmera conhecida.
2. Caracteres especiais de codificação de URL no URL RTSP.
3. Teste se a câmera requer autenticação Digest ou Básica.
4. Inspecione o cabeçalho WWW-Authenticate para domínio, nonce, algoritmo e sinalizadores obsoletos.
5. Verifique se o cliente envia Autorização em DESCRIBE, SETUP e PLAY.
6. Verifique se a conta tem permissão de RTSP e de canal, não apenas permissão de UI da web.
7. Teste os caminhos do stream principal e do stream secundário separadamente.
8. Compare o URI usado na solicitação RTSP com o URI usado no cálculo da resposta Digest.
9. Verifique se o firmware da câmera alterou o comportamento de autenticação.
10. Evite diagnosticar codecs de mídia até que a autenticação RTSP seja realmente concluída.

O que as pesquisas do Google geralmente significam

Quando alguém pesquisa por “Câmera IP não autorizada RTSP 401”, geralmente precisa saber se a credencial está errada. Quando procuram por "loop de autenticação RTSP Digest", geralmente já tentaram a senha e precisam de evidências de protocolo. Quando pesquisam por “a câmera RTSP pede senha repetidamente”, eles precisam inspecionar o desafio e tentar novamente a sequência.

A resposta útil não é apenas “redefinir a senha”. A resposta útil é:

• A câmera contestou o pedido?
• O cliente respondeu com o esquema de autenticação esperado?
• A câmera aceitou a resposta?
• Um método RTSP posterior falhou novamente?
• O caminho do stream ou a permissão da conta falharam após o login?

É por isso que uma ferramenta orientada a protocolo é melhor do que um teste somente para jogadores para esse tipo de problema.

Diagnóstico final

Um loop de autenticação RTSP é resolvido combinando credenciais, codificação de URL, esquema de autenticação, URI de solicitação, permissão de conta e comportamento de autorização em nível de método. Se o rastreamento mostrar respostas repetidas 401 Unauthorized com alteração de nonces, inspecione o tratamento do Digest. Se mostrar sucesso de autenticação seguido de erros de fluxo, vá para caminho de URL, SDP, transporte, RTP e diagnóstico de codec.

O RTSP Inspector foi projetado para esse fluxo de trabalho que prioriza a evidência: confirme o caminho de controle RTSP antes de assumir que a falha é da câmera, do player, do codec ou da rede.