2026-06-03

Depuração de URL de controle agregado RTSP: controle SDP:*, rastrear URLs, SETUP 404 e PLAY falha

Como solucionar problemas de URLs de controle agregado RTSP, atributos de controle SDP:*, caminhos de controle em nível de trilha, erros SETUP 404, falhas de PLAY e bugs de construção de URL de câmera.

URLs de câmeras RTSP geralmente falham porque o cliente cria a URL de controle errada a partir do SDP. Os usuários procuram por "RTSP SETUP 404", "estrela de controle SDP", "URL de controle agregado RTSP", "URL de rastreamento RTSP errado", "DESCRIBE funciona, mas a CONFIGURAÇÃO falha" e "PLAY falha após a CONFIGURAÇÃO" quando uma câmera retorna o SDP com sucesso, mas a mídia nunca inicia.

O RTSP Inspector é útil porque essa falha não se refere à capacidade do player de extrair vídeo. Trata-se de saber se o cliente RTSP interpretou corretamente os atributos de controle no nível da sessão e no nível da mídia.

O sintoma comum

Um traço típico é assim:

DESCRIBE rtsp://camera/live
200 OK
SDP contains a=control:*
SDP video media contains a=control:trackID=1
SETUP rtsp://camera/trackID=1
404 Not Found

The camera did not necessarily reject RTSP. The client may have constructed SETUP with the wrong base URL.

Session-level and media-level control

SDP can contain control attributes at different levels:

a=control:*
m=video 0 RTP/AVP 96
a=control:trackID=1
m=audio 0 RTP/AVP 97
a=control:trackID=2

O controle em nível de sessão pode identificar o recurso agregado usado para PLAY e PAUSE. O controle de nível de mídia identifica cada trilha RTP usada para SETUP.

Se um cliente tratar cada valor control como um caminho absoluto, ele poderá criar URLs inválidos.

URLs de controle relativo versus absoluto

Os valores de controle RTSP SDP podem ser:

URLs RTSP absolutos.
Caminhos relativos.
Rastrear identificadores.
* controle agregado.
Caminhos específicos do fornecedor.

Exemplos:

a=control:rtsp://192.168.1.10/live/trackID=1
a=control:trackID=1
a=control:streamid=0
a=control:video
a=control:*

The client must combine relative track control values with the correct base URL. A tiny difference such as /live/trackID=1 vs /trackID=1 can turn a working camera into a 404 Not Found.

DESCRIBE succeeds but SETUP fails

This is one of the strongest search patterns for this article. DESCRIBE proves the camera accepted the main URL and returned SDP. SETUP failure points to transport negotiation, track URL construction, unsupported media track, or camera firmware behavior.

Evidence to collect:

Original DESCRIBE URL.
Content-Base header if present.
Content-Location header if present.
Session-level a=control.
Media-level a=control for each track.
Exact SETUP URL.
SETUP response status.
Transport header used by SETUP.

Without the SETUP URL, the diagnosis is incomplete.

Content-Base and Content-Location

Some cameras include Content-Base or Content-Location headers in the DESCRIBE response. These headers can affect how relative SDP control paths should be resolved.

Failure patterns:

Client ignores Content-Base.
Client uses the original DESCRIBE URL when camera intended a different base.
Camera returns a base URL with trailing slash differences.
Proxy rewrites the RTSP URL but not SDP.
Client normalizes away a path component needed by the camera.

These details are exactly why protocol evidence matters.

PLAY uses aggregate control

After SETUP succeeds for one or more tracks, PLAY may need to target the aggregate control URL instead of a single track URL. Some cameras accept either. Others are strict.

Search symptoms:

"RTSP SETUP works but PLAY fails"
"RTSP 460 Only Aggregate Operation Allowed"
"RTSP PLAY 404"
"RTSP track SETUP OK no video"

If PLAY targets the wrong URI, the RTP stream may never start even though SETUP returned 200 OK.

Multi-track audio and video

The bug is easier to see when both audio and video exist:

m=video ...
a=control:trackID=1
m=audio ...
a=control:trackID=2

O cliente deve CONFIGURAR ambas as faixas com seus próprios URLs de controle e, em seguida, PLAY o URL agregado correto. Se o cliente configurar apenas o vídeo, mas o PLAY tiver como alvo o áudio, ou se mesclar as duas faixas em um URL de CONFIGURAÇÃO, a câmera poderá retornar um erro que parece não relacionado.

URL do perfil ONVIF vs URL da faixa RTSP

O ONVIF pode relatar URIs de fluxo que diferem dos URLs finais de rastreamento do SDP. Um URI de fluxo do ONVIF pode ser válido para DESCRIBE, mas não diretamente válido para todas as solicitações SETUP.

Isso cria a frase de suporte comum: “ONVIF funciona, mas o URL RTSP falha”. A próxima etapa do diagnóstico é inspecionar o SDP e os URLs de SETUP derivados, e não continuar gerando novos URLs ONVIF.

Lista de verificação de depuração

Use este fluxo de trabalho:

Capture a resposta DESCRIBE.
Salve Content-Base e Content-Location.
Extraia a=control no nível da sessão.
Extraia cada nível de mídia a=control.
Crie o URL de CONFIGURAÇÃO esperado manualmente.
Compare-o com o URL de CONFIGURAÇÃO do cliente.
Verifique se SETUP falha com 404, 461 ou 500.
Confirme se o PLAY segmenta URL agregado ou de rastreamento.
Verifique o comportamento de áudio/vídeo multitrilha.
Preserve as linhas exatas de solicitação RTSP para suporte do fornecedor.

Diagnóstico final

Bugs de controle agregado RTSP se escondem dentro da interpretação SDP. Uma câmera pode aceitar DESCRIBE e ainda rejeitar SETUP ou PLAY se o cliente criar a trilha errada ou URL de controle agregado.

O RTSP Inspector ajuda a expor os atributos de controle SDP, cabeçalhos Content-Base, URLs SETUP e destino PLAY para que os engenheiros possam provar se o problema é construção de URL, rigidez da câmera, reescrita de proxy ou manipulação de SDP do lado do cliente.

Evidência reproduzível para “Depuração de URL de controle agregado RTSP: controle SDP:*, rastrear URLs, SETUP 404 e PLAY falha”

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 “Depuração de URL de controle agregado RTSP: controle SDP:*, rastrear URLs, SETUP 404 e PLAY falha”, 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 “Depuração de URL de controle agregado RTSP: controle SDP:*, rastrear URLs, SETUP 404 e PLAY falha”, 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.