Guia LivSmart
Protocolo

WebRTC

Padronizado pelo W3C e pela IETF, WebRTC combina APIs de captura e conexão com ICE, STUN, TURN, SDP, RTP/RTCP, DTLS-SRTP e SCTP. A recomendação W3C WebRTC 1.0 foi publicada em 2021; as RFCs principais amadureceram no mesmo período. Comparado a RTSP, é nativo em navegadores e exige criptografia, mas a negociação e a travessia de NAT são mais complexas. Para câmeras residenciais, entrega baixa latência, desde que exista sinalização e servidor TURN quando o caminho direto falha.

📖Definição aprofundada

WebRTC é um ecossistema de APIs, protocolos e perfis para comunicação interativa de áudio, vídeo e dados entre navegadores, aplicativos e dispositivos. Não é um único protocolo de fio. A camada de aplicação usa APIs como `getUserMedia`, `RTCPeerConnection` e `RTCDataChannel`. A sinalização que troca ofertas, respostas e candidatos não é definida pelo WebRTC; pode usar WebSocket, HTTP, SIP, MQTT ou um serviço proprietário. Depois da sinalização, ICE testa caminhos de conectividade. STUN ajuda descobrir endereços públicos e comportamento do NAT. TURN retransmite mídia quando não existe caminho direto. DTLS autentica os endpoints e deriva chaves para SRTP, que protege áudio e vídeo. RTP e RTCP transportam mídia e feedback. SCTP sobre DTLS oferece data channels confiáveis ou parcialmente confiáveis. SDP, no modelo offer/answer, descreve codecs, extensões, direções, fingerprints e parâmetros. O resultado é uma pilha robusta, mas complexa. O W3C publicou WebRTC 1.0 como Recomendação em janeiro de 2021. A IETF publicou a arquitetura RTCWeb e várias RFCs relacionadas entre 2018 e 2021, incluindo ICE RFC 8445, JSEP RFC 8829, WebRTC Security Architecture RFC 8827, RTP usages RFC 8834, data channels RFC 8831 e DTLS-SRTP RFC 5764. A especificação continua evoluindo por extensões e revisões. Em casa inteligente, WebRTC é usado para visualizar câmeras e videoporteiros com baixa latência no navegador ou aplicativo. Home Assistant, go2rtc, Frigate e plataformas de fabricantes podem converter RTSP para WebRTC. O gateway recebe H.264/Opus ou outros codecs e encaminha. Se o codec é compatível, faz remux ou repacketization com pouco CPU. Se a câmera usa H.265 e o navegador não suporta, precisa transcodificar, aumentando latência e consumo. A seleção do codec é central. Navegadores devem suportar codecs mínimos conforme perfis. Opus é comum para áudio; VP8 e H.264 são amplamente usados. Suporte a AV1, VP9 e outros varia. WebRTC usa feedback RTCP para estimar banda, perda e atraso. O emissor adapta bitrate. PLI solicita keyframe. NACK solicita retransmissão rápida. FEC pode ajudar. Congestion control é obrigatório para compartilhar a Internet. A baixa latência vem de buffers menores e adaptação, não de ausência de confiabilidade. Pacotes podem ser retransmitidos quando ainda úteis. A criptografia é obrigatória. Não existe WebRTC de mídia aberta no perfil normal. DTLS usa certificados efêmeros ou gerados e fingerprints trocados na sinalização. A sinalização precisa ser autenticada; se um atacante altera fingerprints, pode intermediar. HTTPS/WSS, tokens e autorização são necessários. Uma câmera não deve aceitar qualquer offer. O servidor precisa verificar que o usuário tem permissão. A identidade do dispositivo e do usuário não vem automaticamente do DTLS. ICE gera candidatos host, server-reflexive, peer-reflexive e relay. Candidatos host podem revelar endereços locais; navegadores usam mDNS e políticas de privacidade. STUN não é relay. TURN é. Esse erro comum causa falhas: um servidor STUN não resolve NAT simétrico ou firewall restritivo. TURN precisa de credenciais, capacidade e largura de banda. Um stream de 2 Mbit/s relay usa aproximadamente 2 Mbit/s de entrada e saída no servidor, além de overhead. Dez câmeras simultâneas consomem. TURN sobre UDP é preferido; TCP/TLS 443 serve fallback. A conexão pode ser peer-to-peer, SFU ou MCU. Em uma casa, navegador pode conectar ao gateway local. Em cloud, um SFU distribui vídeo. MCU transcodifica e compõe. O projeto precisa escolher. WebRTC DataChannel permite eventos, comandos e telemetria, mas não substitui APIs autorizadas. É possível definir ordered/unordered e maxRetransmits. SCTP preserva mensagens e múltiplos streams. Dados críticos precisam de idempotência. A interoperabilidade depende de SDP, codecs, BUNDLE, rtcp-mux, ICE, DTLS e extensões. Navegadores são compatíveis, mas dispositivos embarcados podem implementar subconjunto. Testes cruzados são essenciais. O protocolo não define gravação. Um NVR precisa receber stream separado ou gravar no servidor. WebRTC é excelente para visualização ao vivo, não necessariamente para arquivo contínuo. RTSP pode ser mais simples no backend. A arquitetura híbrida usa RTSP câmera→gateway e WebRTC gateway→browser. Essa comparação concreta explica a escolha. A limitação é operação: sinalização, TURN, certificados, autenticação, métricas e compatibilidade exigem manutenção. Um link “funcionou na LAN” não prova acesso remoto.

Arquitetura e Funcionamento
ICE, STUN, TURN e travessia de NAT
ICE reúne candidatos de interfaces locais, STUN e TURN. Cada par recebe prioridade. Connectivity checks usam STUN autenticado. O par vencedor transporta. Trickle ICE envia candidatos conforme aparecem, reduzindo setup. STUN informa endereço mapeado; não encaminha mídia. TURN aloca endereço relay e encaminha. Credenciais TURN devem ser temporárias, não embutidas. REST API de TURN gera usuário com expiração e HMAC em soluções como coturn. Firewalls podem permitir UDP; fallback TCP/TLS 443 ajuda, mas aumenta latência. ICE restart recupera mudança de rede. Em celular passando de Wi‑Fi para 4G, novos candidatos são necessários. O servidor de sinalização coordena. O cliente deve mostrar conectando, conectado, desconectado e falho. Um peer conectado por relay não é erro; é custo. Métricas de candidate type mostram. Se 80% usa TURN, investigar NAT ou firewall. Em LAN, host candidate direto é ideal. Entre VLANs, firewall precisa permitir ou o TURN local pode servir.
DTLS-SRTP, identidade e autorização
Cada peer gera certificado DTLS e coloca fingerprint no SDP. Após ICE, executa handshake DTLS. O fingerprint recebido pela sinalização verifica o certificado. As chaves exportadas alimentam SRTP e SRTCP. A mídia é cifrada, autenticada e protegida contra replay. Isso é obrigatório. A sinalização precisa de HTTPS/WSS e autenticação; senão o atacante troca fingerprint. Um token deve limitar câmera, residência e duração. O gateway verifica. DTLS protege o canal peer-to-peer, mas um SFU termina ou encaminha conforme arquitetura e pode ver metadados; E2EE adicional pode ser implementado com insertable streams, mas aumenta complexidade. Não declarar E2EE apenas porque usa WebRTC. Se servidor termina SRTP ou transcodifica, ele tem acesso. Para morador, a consequência é que a câmera pode ser vista no navegador sem plugin e com mídia cifrada, mas a conta e o serviço continuam críticos. MFA, logs e revogação são necessários.
RTP, codecs e adaptação de qualidade
WebRTC usa RTP/RTCP com perfil seguro. SDP negocia codecs. BUNDLE reúne múltiplas mídias numa conexão de transporte; rtcp-mux reúne RTP e RTCP. SSRCs identificam. Simulcast envia várias resoluções; o SFU escolhe. Scalable Video Coding permite camadas. RTCP feedback inclui NACK, PLI e transport-wide congestion control. O emissor adapta bitrate à banda. Se a rede cai de 5 Mbit/s para 1 Mbit/s, reduz resolução ou FPS. Um stream fixo de câmera RTSP pode não adaptar, então o gateway transcodifica ou descarta. Keyframes grandes causam pico. Intervalo de 1–2 s melhora entrada. Áudio Opus ajusta bitrate e FEC. Jitter buffer é dinâmico. A latência fim a fim pode ficar abaixo de 500 ms em boa rede, mas processamento e cloud aumentam. Não prometer número universal. O dashboard deve permitir substream. Em várias câmeras, limitar sessões. Hardware decode ajuda. O codec precisa ser suportado no navegador de destino, não apenas no servidor.
DataChannel e topologias de distribuição
RTCDataChannel usa SCTP sobre DTLS. Preserva mensagens e permite múltiplos streams. Pode ser ordered ou unordered, com retransmissão ilimitada, tempo máximo ou número máximo. Telemetria de presença pode tolerar perda; comando de fechadura não. O protocolo de aplicação deve autenticar e validar, mesmo dentro do canal. Em peer-to-peer, dois peers trocam diretamente. Um SFU recebe streams e encaminha sem compor, eficiente para vários visualizadores. Um MCU decodifica, mistura e codifica, com mais CPU e controle. Para uma casa, um gateway local funciona como peer e conecta cada navegador. Para cloud, SFU evita que a câmera envie uma cópia por usuário. Gravação pode ser feita no SFU ou por stream RTSP paralelo. Cada topologia altera privacidade. A documentação deve dizer onde a mídia é acessível. O TURN relay não precisa descriptografar SRTP, mas vê endereços e volume. Um SFU normalmente participa da sessão e pode processar. E2EE adicional muda.
Análise Técnica
✓ Vantagens
  • Oferece áudio, vídeo e dados de baixa latência diretamente em navegadores e aplicativos sem plugin RTSP.
  • Exige criptografia de mídia por DTLS-SRTP e inclui proteção contra replay, elevando a base de segurança.
  • ICE, STUN e TURN permitem conectar endpoints através de NATs e firewalls em redes residenciais e móveis.
  • RTP/RTCP, feedback e congestion control adaptam qualidade a perda, jitter e largura de banda disponível.
  • Suporta peer-to-peer, gateway local, SFU e data channels, cobrindo videoporteiros, câmeras e comunicação bidirecional.
✗ Desvantagens
  • Não define sinalização; cada plataforma precisa construir autenticação, troca de SDP/candidatos, autorização e estado de sessão.
  • TURN é necessário para confiabilidade em muitos cenários e consome largura de banda, infraestrutura e custo operacional.
  • A interoperabilidade depende de codecs, SDP, extensões e versões; H.265 de câmeras costuma exigir gateway ou transcodificação.
  • A pilha ICE+DTLS+SRTP+RTP+SCTP é complexa para firmware embarcado e difícil de diagnosticar sem métricas detalhadas.
  • Criptografia de transporte não equivale automaticamente a E2EE quando SFU, gateway ou cloud termina ou processa a mídia.
💡 Cenário Prático: WebRTC para exibir câmeras RTSP no painel da casa
As câmeras continuam enviando RTSP local para um gateway go2rtc ou serviço equivalente. O gateway mantém uma sessão por câmera e oferece WebRTC ao navegador. A sinalização usa HTTPS e token curto vinculado à câmera e ao usuário. Na LAN, ICE escolhe host candidate direto. No acesso remoto, usa TURN com credenciais temporárias e TLS 443 de fallback. Nenhuma porta de câmera é exposta. O gateway prioriza H.264 e Opus para evitar transcodificação. Se a câmera só fornece H.265, cria substream H.264. O bitrate é limitado para celular. O painel fecha sessões invisíveis para não sobrecarregar. Métricas registram tempo de conexão, tipo de candidato, RTT, perda, bitrate e frames. O sistema solicita keyframe ao abrir. O NVR grava o stream principal separadamente. A conta usa MFA. Revogação de usuário invalida tokens de sinalização. O TURN tem limites por usuário e alertas de banda. Entre VLANs, firewall permite apenas o gateway. O resultado é latência baixa e compatibilidade de navegador sem entregar acesso direto às câmeras.