2026-06-02

A transmissão RTSP é interrompida após 30 segundos: manutenção de atividade, tempo limite de sessão, NAT e desconexão de câmera ociosa

Por que os fluxos RTSP param após 30 segundos, 60 segundos ou alguns minutos e como depurar solicitações de manutenção de atividade, tempo limite de sessão, NAT, silêncio RTP e desconexões de câmera.

Um fluxo RTSP que inicia com êxito e para após 30 segundos é um problema diferente de um fluxo que nunca inicia. A autenticação funcionou. O SDP foi devolvido. SETUP e PLAY provavelmente foram bem-sucedidos. A mídia pode ter chegado há algum tempo. Então a câmera fechou a sessão, o RTP parou, o player congelou ou a conexão expirou.

Pesquisas como "O fluxo RTSP para após 30 segundos", "Tempo limite de manutenção de atividade RTSP", "O fluxo da câmera é desconectado após um minuto" e "Tempo limite da sessão RTSP" geralmente apontam para um problema de duração da sessão. O fluxo pode precisar de solicitações de manutenção de atividade, o mapeamento NAT pode expirar, a câmera pode fechar sessões RTSP ociosas, a mídia UDP pode ser bloqueada após uma mudança de caminho ou o RTCP pode revelar perda de mídia antes da desconexão.

O RTSP Inspector é útil aqui porque o cronograma é importante. Você precisa saber o que aconteceu no segundo 0, no segundo 30, no segundo 60 e no momento exato em que o fluxo parou.

Por que o RTSP pode parar depois de iniciado

As causas comuns incluem:

O cliente não envia keepalive RTSP.
A câmera espera GET_PARAMETER keepalive.
A câmera espera manter a atividade OPTIONS.
O tempo limite da sessão RTSP é menor que o esperado.
O estado do NAT ou do firewall expira.
O UDP RTP para enquanto o RTSP TCP permanece aberto.
A câmera fecha a conexão TCP após o silêncio da mídia.
O cliente usou um URL de controle agregado incorreto.
O firmware da câmera possui um bug de limpeza de sessão.
O RTCP relata perda de pacotes ou jitter antes que o fluxo congele.

A correção depende de qual camada parou primeiro: controle RTSP, mídia RTP, feedback RTCP ou caminho TCP/UDP subjacente.

Cabeçalho e tempo limite da sessão RTSP

Após SETUP, a câmera geralmente retorna um cabeçalho Session:

RTSP/1.0 200 OK
Session: 12345678;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

OPTIONS vs GET_PARAMETER keepalive

Two common keepalive methods are:

OPTIONS rtsp://camera/stream RTSP/1.0
Session: 12345678

GET_PARAMETER rtsp://camera/stream RTSP/1.0
Session: 12345678

When debugging, check:

Aggregate control URL problems

This can create subtle behavior:

NAT and firewall idle timeout

Symptoms:

Camera idle disconnects

Look for:

RTP silence vs RTSP disconnect

Checklist for streams that stop after 30 seconds

Use this process:

A useful report includes:

Final diagnosis

Evidência reproduzível para “A transmissão RTSP é interrompida após 30 segundos: manutenção de atividade, tempo limite de sessão, NAT e desconexão de câmera ociosa”

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 “A transmissão RTSP é interrompida após 30 segundos: manutenção de atividade, tempo limite de sessão, NAT e desconexão de câmera ociosa”, 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 “A transmissão RTSP é interrompida após 30 segundos: manutenção de atividade, tempo limite de sessão, NAT e desconexão de câmera ociosa”, 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.

Registro da mudança e teste de regressão

Transforme a correção em registro repetível: valor anterior e novo, local da configuração, hora da reconexão e efeito esperado nos pacotes. Em TCP interleaved não basta “a imagem apareceu”; a mídia deve deixar de depender de portas UDP e surgir nos canais negociados. Se control URL mudou, SETUP deve usar o caminho novo e PLAY e keepalive devem preservar a mesma Session.

Quando for seguro, faça um controle negativo. Restaure o valor anterior em ambiente de teste ou compare uma captura antiga com entradas iguais; a mesma fronteira deve falhar. Isso evita confundir reinício, cache ou mudança de rede não documentada com a solução. Em câmera de produção, use evidência histórica e não provoque a queda.

Mantenha a conexão além de keepalive e Session timeout. Observe OPTIONS ou GET_PARAMETER e a coerência de CSeq e Session. Em RTP compare perda, duplicatas e reordenação em janelas iguais antes e depois. Para codec abra conexão nova e espere o primeiro IDR; decoder já inicializado pode esconder parâmetros iniciais ausentes.

Limite a afirmação: “main stream TCP verificado dez minutos com este cliente” é melhor que “RTSP corrigido”. Informe faixa, transporte, codec, cliente e duração. Áudio, sub stream e reconexão após perda de rede ficam abertos se não foram testados.

Separe fatos e recomendação. Fatos são respostas, pacotes e medidas; recomendação propõe mudança em câmera, firewall ou cliente. Outra equipe deve aceitar os fatos mesmo escolhendo outra solução. Termine com responsável, próxima ação e critério, entregando o intervalo pela guia de relatórios RTSP.