Guia LivSmart
Protocolo

RTSP

Para controlar a entrega de áudio e vídeo sem incorporar o fluxo de mídia ao próprio protocolo, RTSP oferece comandos semelhantes aos de um controle de reprodução. RTSP 2.0 é definido pela RFC 7826, de 2016, e substitui a RFC 2326. Comparado a HTTP, mantém estado de sessão e métodos como SETUP e PLAY; comparado a RTP, controla a sessão em vez de transportar amostras. Exige servidor e cliente compatíveis, e muitos dispositivos ainda implementam apenas RTSP 1.0.

📖Definição aprofundada

RTSP é um protocolo de aplicação destinado ao controle de sessões de mídia com propriedades de tempo real. Ele funciona como uma camada de comando: o cliente localiza uma apresentação, obtém sua descrição, negocia os transportes de cada trilha, inicia a reprodução, pausa, reposiciona e encerra a sessão. O fluxo de áudio ou vídeo normalmente não é carregado dentro das mensagens RTSP. Em muitas implementações, as amostras são transportadas por RTP sobre UDP, acompanhadas por RTCP; em outras, RTP e RTCP são intercalados na própria conexão TCP usada pelo RTSP. Essa separação permite que o protocolo de controle evolua sem definir cada codec. Uma câmera IP pode expor `rtsp://192.168.10.40:554/stream1`. O cliente envia DESCRIBE e recebe uma descrição SDP com codecs, payload types, endereços e parâmetros. Em seguida, envia SETUP para cada trilha, indicando se quer UDP unicast, multicast ou interleaved TCP. O servidor devolve um identificador de sessão. PLAY inicia a entrega. PAUSE interrompe sem destruir todos os recursos quando suportado. TEARDOWN encerra. OPTIONS anuncia métodos. GET_PARAMETER e SET_PARAMETER podem ser usados em extensões ou manutenção de sessão. RTSP 1.0 foi definido na RFC 2326 em 1998. RTSP 2.0, RFC 7826 de 2016, revisou a especificação, corrigiu ambiguidades, modernizou requisitos e tornou o comportamento mais consistente. Apesar disso, o mercado de câmeras de consumo permanece fortemente baseado em RTSP 1.0. O cliente precisa interrogar e tolerar diferenças. O uso prático em casa inteligente ocorre principalmente em câmeras, NVRs, servidores de mídia, intercomunicadores e gateways. Home Assistant, Frigate, VLC, FFmpeg e muitos NVRs conseguem consumir URLs RTSP. ONVIF pode fornecer a URL correta por meio de serviços padronizados, enquanto RTSP transporta o controle da sessão. ONVIF e RTSP não são sinônimos. Um equipamento pode oferecer RTSP sem ONVIF, ou ONVIF com perfis que apontam a streams RTSP. O protocolo não resolve autenticação moderna de forma universal. Muitas câmeras usam Basic ou Digest Authentication. Basic só deve ser usado sobre transporte protegido porque codifica credenciais, não as cifra. RTSP sobre TLS existe como `rtsps`, mas o suporte é desigual. Em redes locais, a mitigação comum é segmentar câmeras, impedir acesso externo direto e permitir apenas NVR e controladores. Expor a porta 554 à Internet é inadequado. Acesso remoto deve passar por VPN, serviço seguro ou gateway. O protocolo também não garante baixa latência sozinho. Codec, GOP, buffers, jitter, transporte, retransmissão e processamento dominam. H.264 com GOP de 2 s pode levar até dois segundos para permitir decodificação após entrada no stream. TCP interleaved evita bloqueios de UDP em NAT e firewall, mas perdas no TCP podem causar head-of-line blocking. UDP reduz latência, mas pode perder pacotes e exige portas adicionais. A escolha depende da rede. Em Wi‑Fi estável e LAN, UDP costuma oferecer boa latência; em túneis e redes restritivas, TCP é mais fácil. RTSP não possui uma experiência de navegador nativa moderna. Navegadores normalmente não reproduzem RTSP diretamente; é preciso converter para WebRTC, HLS, MSE ou outro formato. Esse gateway aumenta recursos e latência. O protocolo continua valioso porque câmeras e gravadores o implementam amplamente, sua semântica é previsível e ferramentas maduras existem. A limitação principal é a fragmentação entre versões, autenticação e extensões de fabricantes. O integrador deve testar URL, codec, perfil, transporte, áudio, reconexão e comportamento após reinício. Uma URL que abre no VLC não prova que ficará estável por 30 dias num NVR. Sessões precisam de timeout, keepalive e reconexão. O servidor pode encerrar por ociosidade. O cliente deve usar OPTIONS ou GET_PARAMETER conforme o produto. Logs precisam distinguir falha de autenticação, ausência de trilha, timeout, perda RTP e codec incompatível.

Arquitetura e Funcionamento
Métodos de controle e máquina de estados
DESCRIBE solicita uma descrição da apresentação, geralmente SDP. SETUP reserva recursos e negocia o transporte de uma trilha. PLAY muda a sessão para reprodução; PAUSE mantém a sessão sem fluxo quando suportado; TEARDOWN libera recursos. OPTIONS anuncia capacidades. Cada método possui cabeçalhos, códigos e condições. O identificador `Session` liga requisições posteriores ao estado no servidor. Um cliente não deve enviar PLAY antes de SETUP quando a apresentação exige. Em RTSP 2.0, a máquina de estados foi refinada. Em câmeras legadas, respostas podem ser incompletas. O cliente precisa tratar 401, 404, 454, 455, 461 e outros códigos. Um 200 ao PLAY significa que o servidor aceitou, não que o primeiro quadro chegou. O monitoramento deve verificar pacotes RTP e decodificação. Timeouts de sessão precisam ser lidos e o keepalive enviado antes do prazo. Após perda de TCP ou mudança de IP, reconstruir a sessão, não reutilizar cegamente o ID antigo.
Negociação de transporte RTP/RTCP
O cabeçalho Transport negocia UDP unicast, multicast ou RTP/AVP/TCP interleaved. Em UDP, o cliente indica portas para RTP e RTCP, e o servidor devolve portas de origem e SSRC quando disponível. Firewalls e NAT precisam permitir. Em TCP interleaved, quadros RTP e RTCP são encapsulados com marcador `$`, canal e comprimento na mesma conexão. Isso simplifica travessia, mas mistura controle e mídia e herda bloqueio do TCP. Multicast é eficiente para muitos consumidores na mesma rede, mas exige IGMP/MLD, switches e roteamento configurados. Câmeras residenciais raramente oferecem multicast bem testado. RTCP fornece estatísticas, sincronização e feedback; alguns dispositivos o omitem. O cliente deve tolerar, mas perde diagnóstico. A escolha de transporte é um critério: UDP para menor latência em LAN controlada; TCP para redes que bloqueiam portas dinâmicas; multicast para distribuição planejada a muitos receptores.
SDP, codecs e perfis de câmera
A resposta DESCRIBE costuma usar `application/sdp`. Linhas `m=` descrevem mídia; `a=rtpmap` associa payload type ao codec e clock rate; `a=fmtp` leva parâmetros; `a=control` informa URL relativa ou absoluta da trilha. H.264 usa parâmetros como `sprop-parameter-sets`, `packetization-mode` e profile-level-id. H.265 possui outros. Áudio pode ser AAC, G.711, Opus ou proprietário. O cliente precisa resolver URLs relativas corretamente. Uma câmera pode oferecer main stream 4K e substream 640×360 em caminhos diferentes. O NVR escolhe. Perfis altos exigem decodificador. Um navegador não consome diretamente. FFmpeg pode remuxar sem recodificar quando o codec de destino aceita, economizando CPU. Para WebRTC, H.264 compatível pode ser encaminhado; H.265 frequentemente exige transcodificação. O SDP descreve a oferta, mas não comprova que a câmera entregará todos os parâmetros. Testar. Atualizações podem mudar o caminho.
Autenticação, sessão e operação contínua
Câmeras usam Basic ou Digest. Credenciais devem ser individuais e guardadas em cofre. URLs com `usuario:senha@host` podem vazar em logs, histórico e processos; preferir configuração separada. Digest legado possui variantes e algoritmos. TLS é preferível quando suportado. Na ausência, isolar a VLAN e impedir captura. O cliente precisa reconectar com backoff após falha. Não abrir dezenas de sessões desnecessárias, porque a câmera tem limite de encoders e clientes. Um proxy de mídia como go2rtc pode manter uma sessão e distribuir a vários consumidores. Isso reduz carga. Keepalive evita timeout, mas intervalo excessivo gera tráfego. O servidor pode indicar `timeout=60`; enviar antes. O NVR precisa detectar congelamento: conexão TCP pode ficar aberta sem quadros. Medir timestamp RTP e idade do último frame. Após reinício, redescobrir. Senha alterada deve ser atualizada. Logs não devem expor. A automação pode alertar quando stream falha por mais de 30 s, mas não reiniciar a câmera em loop sem limite.
Análise Técnica
✓ Vantagens
  • Separa controle de sessão do transporte de mídia, permitindo usar RTP, RTCP e múltiplos codecs sem redefinir cada comando.
  • É amplamente implementado por câmeras IP, NVRs, FFmpeg, VLC, Frigate, Home Assistant e sistemas ONVIF.
  • Oferece comandos explícitos de descrição, negociação, reprodução, pausa, posicionamento e encerramento.
  • Suporta UDP, multicast e mídia intercalada sobre TCP, adaptando-se a redes locais e ambientes com firewall restritivo.
  • Permite obter múltiplas trilhas e perfis de uma mesma câmera, incluindo stream principal, substream e áudio.
✗ Desvantagens
  • Grande parte do mercado ainda usa RTSP 1.0 com extensões e comportamentos divergentes, limitando a interoperabilidade ideal da RFC 7826.
  • Criptografia não é padrão em muitas câmeras; RTSP sem TLS expõe credenciais e mídia a nós capazes de capturar o tráfego.
  • Navegadores modernos não reproduzem RTSP diretamente, exigindo gateway para WebRTC, HLS ou MSE e adicionando latência ou CPU.
  • TCP interleaved pode aumentar atraso em perda, enquanto UDP exige portas e tolerância a pacotes perdidos.
  • O protocolo não garante segurança do dispositivo, estabilidade do encoder, baixa latência nem confirmação de que a imagem está sendo decodificada.
💡 Cenário Prático: RTSP para câmeras locais sem exposição direta
As câmeras ficam numa VLAN própria, sem acesso iniciado à rede administrativa. O NVR e o servidor de automação recebem permissão explícita para porta 554 ou a porta configurada. Cada câmera usa senha única. UPnP e port forwarding ficam desativados. O NVR obtém perfis por ONVIF quando disponível, mas armazena a URL RTSP e testa main e substream. O main stream grava em alta resolução; o substream alimenta detecção para reduzir CPU. O transporte começa por UDP numa LAN cabeada e muda para TCP se a rede bloqueia ou perde excessivamente. Um proxy local consolida sessões para que painel, Frigate e Home Assistant não abram três encoders. O monitoramento mede último frame, taxa e reconexões. Após 30 s sem quadros, reconecta com backoff; só reinicia PoE após tentativas limitadas. Acesso remoto usa VPN ou aplicativo seguro do NVR. Nenhuma URL com senha é escrita em logs. Para exibir no navegador, o proxy converte RTSP para WebRTC com codec compatível. A latência é medida. O projeto documenta codec, resolução, FPS, GOP e bitrate. Atualizações de firmware são testadas porque podem alterar autenticação ou URL.