Resposta direta
Reconecte rapidamente uma vez e, em seguida, use a espera exponencial limitada com jitter. Redefina o atraso somente depois que o fluxo permanecer íntegro por uma janela de estabilidade definida.
Por que isso acontece
Tentativas infinitas imediatas podem sobrecarregar uma câmera reinicializada e sincronizar centenas de clientes em uma tempestade de reconexão. No entanto, uma nova tentativa fixa muito lenta deixa interrupções de rotina sem solução por muito tempo.
A visualização confiável da câmera depende de novas tentativas limitadas, integridade observável e uma política deliberada de fluxo principal/substream.
Um teste controlado
Defina estados para conectar, reproduzir, travar, recuar e parar, com um proprietário de timer por stream.
Altere uma variável de cada vez. Mantenha registrado o modelo da câmera, firmware, endpoint e conta; em seguida, teste a acessibilidade da rede, a resposta do protocolo, o transporte de mídia e a decodificação como camadas separadas.
Use uma conta dedicada somente para visualização e uma ferramenta de diagnóstico local confiável. Edite credenciais, endereços privados e dados de identificação antes de compartilhar resultados.
Sequência de diagnóstico
| Verificar | Ação | Evidência de progresso |
|---|---|---|
| Primeira tentativa | Permita uma nova tentativa imediata para uma breve interrupção do caminho. | Interrupções curtas se recuperam rapidamente. |
| Recuo | Aumente o atraso após falhas repetidas e adicione jitter. | Os clientes não tentam novamente em sincronia. |
| Redefinição de integridade | Redefina a contagem de tentativas após uma boa reprodução sustentada. | Um pacote bom não apaga uma falha persistente. |
| Regra de parada | Parar ou alertar após o limite operacional. | Uma câmera morta fica visível em vez de ser repetida silenciosamente para sempre. |
Evidências para manter
Número da tentativa de registro, motivo, atraso e tempo desde o último quadro válido. Isso oferece suporte às operações e à análise da causa raiz.
Limite e nota de segurança
A lógica de reconexão não deve ignorar falhas de autenticação, acesso revogado ou parada explícita do operador.
Para visualização remota, use um VPN gerenciado em vez de expor RTSP ou portas de administração de câmera diretamente à Internet pública.
SmartRTSP
SmartRTSP é um visualizador RTSP e ONVIF focado na câmera para dispositivos Apple, Windows e Android. Ele se adapta à visualização direta, descoberta e verificações de múltiplas câmeras; mantenha um NVR ou VMS dedicado quando for necessário registro contínuo, exportação de evidências ou controles corporativos centralizados.
Perguntas frequentes
Qual é uma boa estratégia de reconexão?
Uma primeira tentativa rápida seguida por uma espera exponencial limitada com jitter e uma parada explícita ou limite de alerta.
Quando o backoff deve ser reiniciado?
Após um período definido de reprodução saudável, não imediatamente após a abertura do soquete.
Os erros 401 devem tentar novamente automaticamente?
Falhas repetidas de autenticação devem parar ou alertar, em vez de martelar a câmera com a mesma credencial rejeitada.
Referências primárias
- IETF RFC 7826 — Protocolo de streaming em tempo real 2.0
- CISA — Orientação Secure by Design
- SmartRTSP — plataforma oficial e informações do produto
Guia SmartRTSP relacionado
Abrir guia relacionadoProjete novas tentativas limitadas, instabilidade e estados de conexão visíveis para câmeras que são reinicializadas ou perdem a rede brevemente.