2026-06-02

ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da câmera

Por que a descoberta ONVIF pode funcionar enquanto o fluxo RTSP falha e como depurar perfis de câmera, URLs de mídia, autenticação, transporte e evidências SDP.

É comum que uma câmera IP apareça corretamente na descoberta ONVIF enquanto a URL RTSP ainda falha. O dispositivo fica visível na rede, o nome e o modelo da câmera são detectados, talvez até os perfis sejam listados, mas o fluxo de vídeo real não abre. Os usuários pesquisam “ONVIF funciona, mas o RTSP falha”, “câmera descoberta, mas não há vídeo RTSP” ou “como encontrar o URL RTSP do ONVIF” porque o sucesso da descoberta parece garantir o sucesso do streaming.

Isso não acontece.

ONVIF e RTSP estão relacionados em muitos fluxos de trabalho de câmeras, mas não são o mesmo protocolo e não provam a mesma coisa. O ONVIF pode informar que existe uma câmera e pode fornecer um perfil de mídia. O RTSP ainda deve autenticar, descrever o fluxo, negociar o transporte, configurar trilhas RTP e entregar pacotes de mídia.

O RTSP Inspector concentra-se na segunda metade: o que realmente acontece quando um URL RTSP específico é usado.

O que o ONVIF prova

A descoberta do ONVIF pode provar que:

A câmera responde ao WS-Discovery.
A câmera expõe um endpoint de serviço ONVIF.
O cliente pode acessar a interface de gerenciamento da câmera.
A câmera pode ter um ou mais perfis de mídia.
O dispositivo pode relatar URIs de fluxo por meio de serviços de mídia ONVIF.

Isso é útil, mas não é o mesmo que provar que o fluxo RTSP funciona. A descoberta ONVIF pode usar uma porta diferente, um comportamento de autenticação diferente e um caminho de serviço diferente do RTSP.

Uma câmera pode passar na descoberta ONVIF e ainda assim falhar no RTSP porque:

O RTSP está desativado nas configurações da câmera.
A conta ONVIF não possui permissão RTSP.
O URI do fluxo retornado está incompleto ou é apenas interno.
A porta RTSP está bloqueada por um firewall.
A câmera requer transporte intercalado TCP, mas o cliente tenta UDP.
O perfil aponta para H.265 mas o cliente espera H.264.
O caminho do canal NVR está errado.
A câmera retorna SDP, mas não envia pacotes RTP.

O URI do fluxo ONVIF pode não ser diretamente utilizável

Algumas câmeras retornam um URI RTSP por meio do ONVIF que parece utilizável, mas ainda precisa de modificação. Por exemplo:

rtsp://192.168.1.50/Streaming/Channels/101

The real usable URL may need:

ONVIF profile does not guarantee codec support

The symptom may be:

RTSP Inspector helps by separating the layers:

RTSP transport can fail after ONVIF succeeds

This is common when:

Authentication can differ between ONVIF and RTSP

You may see:

RTSP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="IP Camera", nonce="..."

mesmo que a descoberta do ONVIF tenha funcionado. Isso significa que o serviço RTSP está solicitando credenciais. Se o cliente enviar credenciais e a câmera continuar retornando 401, verifique as permissões da conta, autenticação Digest, codificação de URL e direitos do canal.

Os NVRs tornam isso mais confuso porque o dispositivo ONVIF pode ser o NVR, enquanto o caminho do fluxo RTSP faz referência a um canal de câmera atrás do NVR. A conta pode ter permissão para consultar o NVR, mas não transmitir o fluxo principal do canal 1.

Confusão de stream principal e substream

Muitas câmeras expõem vários perfis:

Fluxo principal: alta resolução, alta taxa de bits, geralmente H.265.
Sub-stream: resolução mais baixa, taxa de bits mais baixa, geralmente H.264.
Fluxo móvel: tamanho de quadro pequeno e taxa de quadros mais baixa.

ONVIF pode retornar um desses perfis por padrão. O URL RTSP copiado de um fórum ou PDF de fornecedor pode apontar para outro. Se o fluxo principal for H.265, mas o cliente suportar apenas H.264, o fluxo secundário poderá funcionar enquanto o fluxo principal falhar.

Pesquisas como "O fluxo principal RTSP não funciona, o fluxo secundário funciona" geralmente pertencem a esta categoria. O problema não é a descoberta. É seleção de perfil, seleção de codec, taxa de bits ou comportamento de transporte.

Como depurar ONVIF funciona, mas o RTSP falha

Use uma lista de verificação em camadas:

Confirme se o serviço RTSP da câmera está ativado.
Confirme se a porta RTSP, geralmente 554, pode ser acessada pelo cliente.
Obtenha o perfil de mídia ONVIF e transmita o URI.
Normalize o URL RTSP para o caminho de rede que você está realmente usando.
Adicione credenciais com cuidado e codifique caracteres especiais em URL.
Execute RTSP OPTIONS e DESCRIBE.
Inspecione desafios e respostas de autenticação.
Inspecione o SDP para codec, tipo de carga útil, taxa de clock e URLs de controle de rastreamento.
Compare o transporte intercalado UDP e TCP.
Confirme se os pacotes RTP chegam após PLAY.
Verifique a continuidade da sequência RTP, carimbos de data/hora e tipo de carga útil.
Teste o stream principal e o stream secundário separadamente.

Esta lista de verificação evita um erro comum: tratar o sucesso da descoberta do ONVIF como prova de que o streaming de mídia deve funcionar automaticamente.

O que o rastreamento RTSP deve mostrar

Um fluxo RTSP saudável geralmente se parece com:

OPTIONS rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

DESCRIBE rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK
Content-Type: application/sdp

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
RTSP/1.0 200 OK
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

PLAY rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

Final diagnosis

Evidência reproduzível para “ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da câmera”

A resposta direta é que uma tela preta ou um único código não prova a origem da falha. Um diagnóstico confiável liga pedido e resposta RTSP, transporte negociado, sessão válida e depois números de sequência RTP, timestamps e sinais RTCP. Em “ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da câmera”, comece pela camada mais próxima do sintoma, mas mantenha uma cronologia comum para não confundir controle, rede e decodificação.

Antes de alterar câmera, firewall ou VMS, crie um teste de referência pequeno. Registre URL RTSP sem senha, horário, caminho, Transport solicitado, resposta do servidor e chegada do primeiro pacote de mídia. Teste UDP e TCP interleaved separadamente quando disponíveis. Não mude caminho, credenciais e transporte juntos; caso a segunda tentativa funcione, será necessário identificar a variável decisiva.

Camada	Evidência a preservar	Pergunta
RTSP	método, estado, cabeçalhos, CSeq e Session	O servidor aceitou exatamente a operação?
SDP	control, payload type, clock rate e codec	A faixa esperada foi descrita?
Transport	client_port, server_port ou interleaved	Os dois lados usam o mesmo canal?
RTP	SSRC, sequência, timestamp e marker	As unidades chegam em ordem explicável?
RTCP	sender report, CNAME e BYE	Relógio, identidade e fim são rastreáveis?
Decoder	SPS/PPS/VPS e packetization mode	O payload recebido inicializa o decoder?

Separe “nenhuma mídia chegou” de “a mídia chegou, mas não decodifica”. Se RTP falta depois de SETUP e PLAY bem-sucedidos, verifique UDP, NAT, firewall e resposta Transport. Lacunas de sequência provam perda ou reordenação. Uma sequência contínua sem imagem desloca a investigação para payload type, clock rate, limites de frame e parâmetros H.264 ou H.265. Essa fronteira é mais útil que a mensagem genérica do player.

Como escrever uma resposta citável?

Use três frases: última operação bem-sucedida, primeira evidência com falha e próximo teste que separa duas causas. Exemplo: “DESCRIBE, SETUP e PLAY funcionam; nenhum RTP chega às portas anunciadas; um teste TCP interleaved separará bloqueio UDP de caminho de mídia errado”. Não atribua a falha à câmera ou rede sem resposta ou pacote que demonstre o limite.

Quais dados tornam o caso reproduzível?

Preserve OPTIONS, DESCRIBE, SETUP e PLAY, SDP, resposta Transport e Session sem segredos. Para RTP registre SSRC, primeira e última sequência, clock rate, lacunas e duração. Informe se VLC ou outro VMS funciona, mas trate isso como comparação controlada, não como prova de que o cliente bem-sucedido interpreta corretamente todas as regras.

Quando examinar servidor ou cliente?

Examine o servidor quando recusar método, fornecer control URL ausente, responder com transporte incompatível ou mudar SSRC ou relógio sem transição. Examine o cliente quando reutilizar nonce vencido, perder Session, solicitar UDP sem abrir portas ou tratar todo fim de NAL como fim de access unit. Se o problema estiver entre os dois, pacote e horário devem acompanhar cada conclusão.

Como revisar o relatório?

Repita a partir de uma conexão nova e compare as cronologias até a primeira diferença. Remova senhas e valores Authorization completos. Ligue cada conclusão a CSeq, sequência ou timestamp. Siga o guia RTSP relacionado e use RTSP Inspector para testar um stream RTSP e coletar evidências localmente, sem enviar o vídeo para um serviço público.

Da observação ao veredito por camada

Em “ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da câmera”, escreva primeiro a observação e depois a interpretação. Outra pessoa deve localizar a observação na captura: estado RTSP ligado a CSeq, valor SDP, resposta Transport, lacuna de sequência, mudança de SSRC ou diferença entre RTP timestamp e RTCP sender report. “O servidor está lento” ou “o codec é incompatível” continua hipótese até que uma prova específica a explique melhor que as alternativas.

Divida o fluxo em fronteiras. Primeiro TCP abre; depois OPTIONS ou DESCRIBE é aceito. SDP deve descrever faixa utilizável, control URL, payload type e clock rate. SETUP precisa de resposta Transport compatível e PLAY de Session válida. Só então vêm chegada RTP, ordem, tempo e preparo do decoder. Pare na primeira fronteira sem prova de sucesso.

Mantenha fonte e intervalo constantes nas comparações. UDP contra TCP interleaved usa caminho e credenciais iguais. Main stream contra sub stream preserva cliente e transporte. Ao comparar VLC com VMS, registre métodos, cabeçalhos e URL reais. Diferença em control URL, Authorization, Session ou keepalive pode explicar o resultado melhor que o nome do programa.

Matriz de exclusão

Comece com duas hipóteses. Sem mídia, UDP pode estar bloqueado ou o servidor pode enviar a outras portas. TCP interleaved testa a primeira; comparar oferta e resposta Transport, IP e portas testa a segunda. Para imagem corrompida, RTP sequence separa perda de inicialização incompleta, enquanto SPS/PPS/VPS antes do primeiro frame testa os parâmetros codec.

Para cada hipótese anote prova favorável e prova que pode refutá-la. Uma afirmação que nenhum pacote consegue negar é ampla demais. “NAT descarta UDP” é refutada por RTP na porta do cliente. “Faltam parâmetros H.264” é refutada por SPS e PPS válidos antes de IDR. Assim o relatório mantém prioridade.

Não misturar relógios

RTSP CSeq ordena transações, RTP sequence ordena pacotes, RTP timestamp expressa tempo de amostra e capture clock expressa chegada ao ponto observado. Não são o mesmo relógio. Variação de chegada não prova drift; salto timestamp não prova perda sem sequência. RTCP sender report liga relógios RTP de áudio e vídeo a uma referência comum.

Pacote de aceitação

Encerre quando a correção se repetir em conexão nova com uma mudança documentada. O relatório informa entradas, última fronteira correta, primeira prova falha, alteração, resultado e testes abertos. Anexe transcript curto ou estatísticas focadas. Oculte segredos, mas preserve CSeq, Session limpa, SSRC e intervalo.

Use a solução de problemas RTSP para reconstruir o fluxo e os relatórios do RTSP Inspector para entregar a fronteira à equipe de câmera, rede ou VMS.