RTSP 401 não autorizado e 404 não encontrado: diagnosticando URL da câmera e falhas de autenticação

Dois erros RTSP aparecem repetidamente em tickets de suporte: "401 Unauthorized e 404 Not Found. Eles parecem simples. Um parece um problema de login, o outro parece um URL incorreto. Em implantações reais de câmeras, ambos podem ser mais sutis." Uma câmera pode aceitar as mesmas credenciais na UI da web, mas rejeitar o RTSP. Um gravador pode expor caminhos diferentes para o fluxo principal e o fluxo secundário. Uma varredura ONVIF pode descobrir um URL que muda posteriormente. Um fornecedor pode exigir um número de canal, sufixo de stream ou token de perfil. Algumas câmeras também retornam códigos de status enganosos quando o caminho é muito longo, o fluxo está desabilitado ou um modo de autenticação é incompatível com o cliente.

Para pesquisas no Google, a consulta do usuário geralmente é direta: “Câmera não autorizada RTSP 401”, “RTSP 404 não encontrada”, “VLC funciona, mas NVR diz que não há sinal” ou “URL RTSP da câmera ONVIF não funciona”. Um artigo útil não deve fingir que existe um URL mágico. Deve mostrar como coletar evidências.

Comece com o método RTSP que falhou

Não registre apenas o erro final. Registre qual método RTSP o retornou:

• OPÇÕES
• DESCREVA
• CONFIGURAÇÃO
• JOGAR

Se OPTIONS falhar com 401, a autenticação ou política do servidor está bloqueando a sessão antes que os metadados sejam solicitados. Se DESCRIBE falhar com 401, a câmera poderá aceitar a conexão, mas rejeitar o acesso a esse caminho de fluxo. Se DESCRIBE retornar 404, o caminho geralmente não é mapeado para um perfil de fluxo. Se SETUP falhar após um DESCRIBE bem-sucedido, o URL pode ser válido, mas o caminho de controle de trilha, modo de transporte ou perfil de mídia tem um problema.

Esta distinção é importante porque a próxima ação muda. As correções de credenciais não repararão um caminho de fluxo ausente. Alterar o sufixo do URL não reparará uma incompatibilidade de autenticação de resumo.

Separar credenciais do caminho do stream

Uma matriz de solução de problemas limpa é semelhante a esta:

• o mesmo nome de usuário/senha funciona na interface da web da câmera
• O serviço RTSP está ativado
• A porta RTSP está aberta na rede do cliente
• O caminho do URL corresponde ao padrão de stream principal ou secundário do fornecedor
• o perfil de stream está ativado na câmera
• o modo de autenticação é compatível com o cliente
• caracteres especiais na senha são codificados corretamente

Password characters are a frequent source of false failures. A password that contains @, :, /, ?, #, or spaces may need URL encoding when embedded in an RTSP URL. A better test is to use a client that sends credentials separately rather than relying on an inline URL.

Por que 404 geralmente significa perfil ou caminho, não rede

404 Not Found significa que o servidor foi alcançado e entendeu a solicitação o suficiente para rejeitar o recurso. Para fluxos de câmera, isso geralmente aponta para um destes:

• número de canal errado
• sufixo de fluxo errado
• fluxo principal desativado
• substream desativado
• o caminho do gravador difere do caminho da câmera
• Token de perfil ONVIF alterado
• nome de acesso específico do fornecedor necessário
• stream existe somente após ativar o RTSP nas configurações

A evidência mais útil é o URI da solicitação DESCRIBE e o status da resposta. Se a câmera retornar 404 antes do SDP, ainda não há sessão de mídia. Não pule para perda de RTP ou depuração de codec antes de confirmar se o URL está mapeado para um fluxo real.

ONVIF Discovery ajuda, mas não é o mesmo que prova

A descoberta ONVIF pode fornecer URIs de fluxo e informações de perfil, mas o URI RTSP descoberto ainda precisa ser testado. Alguns sistemas expõem o ONVIF corretamente, enquanto a autenticação RTSP ou o comportamento do caminho são diferentes. Outros retornam um URI válido apenas para um perfil que posteriormente será desativado ou alterado.

A sequência de diagnóstico deve ser:

1. descubra ou insira o URL RTSP
2. execute OPTIONS e DESCRIBE
3. capturar códigos de status e cabeçalhos
4. inspecionar se o SDP foi retornado
5. só então inspecione SETUP, PLAY, RTP e evidências de codec

Essa ordem evita que um engenheiro trate cada falha como um problema de “câmera offline”.

Como o inspetor RTSP deve ser usado

O RTSP Inspector não é um player, um gerenciador ONVIF ou um produto de descoberta de câmera. Sua função é tornar a transação RTSP visível o suficiente para explicar o que aconteceu. Para os casos 401 e 404, a saída útil é:

• solicitar URI
• método falhado
• código de status
• limite de autenticação
• se o SDP foi devolvido
• se a falha aconteceu antes da negociação com a mídia
• próximo proprietário recomendado: credenciais, perfil da câmera, formato de URL do fornecedor, porta de rede ou ativação de stream

Essa é exatamente a evidência que um integrador de campo ou engenheiro de plataforma de vídeo precisa antes de escalar para o fornecedor da câmera ou alterar cegamente as configurações do gravador.

Quando um ticket de suporte disser "RTSP não funciona", solicite o método, o código de status e o limite do SDP. Isso transforma uma reclamação genérica em um caso solucionável.