Secure Streaming no ONVIF não é sinônimo automático de SRTP. Entenda o significado no Profile T, o transporte RTP/RTSP/HTTPS/TCP e a evolução para SecureRTSPStreaming com RTSPS e SRTP.
Confira!
Secure Streaming, no contexto do ONVIF Profile T, deve ser interpretado a partir da função de transporte definida pelo próprio profile: streaming sobre RTP/RTSP/HTTPS/TCP. Na especificação Profile T v1.0, publicada em setembro de 2018, essa função é classificada como condicional. Portanto, a conformidade de um equipamento com o Profile T não permite concluir, por si só, que ele suporta essa modalidade de streaming protegido.
Essa definição também não deve ser confundida com SRTP — Secure Real-time Transport Protocol. Nas especificações ONVIF mais recentes existe uma capacidade distinta, denominada SecureRTSPStreaming, associada a RTSPS e SRTP. A diferença é arquitetural: no HTTPS streaming referenciado pelo Profile T, a proteção é fornecida pelo TLS no canal HTTPS; no SecureRTSPStreaming moderno, o controle RTSP utiliza TLS e a mídia pode ser protegida diretamente por SRTP.
Essa distinção é especialmente importante em projetos, especificações técnicas, procurement e homologação de câmeras e VMS. Exigir apenas “ONVIF Profile T” não é o mesmo que exigir a feature de HTTPS streaming; da mesma forma, encontrar “Secure Streaming” na declaração de conformidade de um produto Profile T não deve ser interpretado automaticamente como comprovação de SRTP.
Por que o termo Secure Streaming no ONVIF causa confusão?
“Secure Streaming” é uma expressão intuitiva, mas tecnicamente ampla. Fora de um contexto normativo, ela pode ser usada para descrever praticamente qualquer mecanismo que proteja um fluxo de mídia em trânsito. Dentro do ecossistema ONVIF, porém, é necessário identificar qual especificação, profile, capability ou função está sendo considerada.
O primeiro ponto é que Secure Streaming não é o nome de um protocolo de rede. Os mecanismos utilizados pelo ONVIF são construídos sobre protocolos e serviços existentes, como RTP, RTCP, RTSP, HTTP, HTTPS, TCP, UDP, TLS e, nas especificações mais recentes, SRTP.
O segundo ponto é que um ONVIF Profile também não é um protocolo. Um profile define um conjunto fixo de funcionalidades para permitir que devices e clients de fabricantes diferentes tenham uma base previsível de interoperabilidade. As funções subjacentes são detalhadas nas ONVIF Network Interface Specifications.
Por isso, três expressões que parecem semelhantes precisam ser mantidas separadas:
| Expressão | Significado técnico |
| ONVIF Profile T | Profile ONVIF voltado a funcionalidades avançadas de vídeo IP e interoperabilidade entre device e client |
| Streaming over RTP/RTSP/HTTPS/TCP | Função de transporte protegido por HTTPS/TLS referenciada pelo Profile T |
| SecureRTSPStreaming | Capability mais recente de Media2 para streaming seguro via RTSPS e SRTP |
Misturar essas três camadas leva a erros de especificação. O mais comum é afirmar que “Secure Streaming do Profile T é SRTP”. Essa afirmação não corresponde à forma como o Profile T v1.0 define sua função de streaming seguro.
O que o ONVIF Profile T estabelece sobre Secure Streaming?
O Profile T foi publicado para sistemas de vídeo baseados em IP e inclui funcionalidades relacionadas a H.264/H.265, configuração de imagem, eventos, metadata streaming e outras capacidades de vídeo. Para entender Secure Streaming, entretanto, a referência mais importante é a seção 7.9 — Video streaming da especificação Profile T v1.0.
Para um device, a especificação determina, entre outros requisitos, suporte a streaming por RTP/UDP e por RTP/RTSP/HTTP/TCP. Em seguida, estabelece que, se suportado, o device deve ser capaz de transmitir vídeo por RTP/RTSP/HTTPS/TCP utilizando o Media Profile selecionado.
Na Function List do Profile T, a diferença aparece de forma explícita:
| Função de streaming | Device Profile T |
| Streaming over RTP/UDP | M — Mandatory |
| Streaming over RTP/RTSP/HTTP/TCP | M — Mandatory |
| Streaming over RTP/RTSP/HTTPS/TCP | C — Conditional |
| Streaming over RTP/UDP Multicast | M — Mandatory |
| Streaming over RTP/RTSP/TCP/WebSocket | C — Conditional |
Para clients, Streaming over RTP/RTSP/HTTPS/TCP também aparece como função condicional.
Isso produz uma consequência prática importante: Profile T e suporte a HTTPS streaming não são equivalentes. Um produto pode ser conformante ao Profile T sem que essa função condicional esteja presente. Quando o requisito do projeto é efetivamente utilizar o fluxo protegido, é necessário verificar a declaração de conformidade e as features aplicáveis ao modelo e firmware ofertados.
O que significa “Conditional” no Profile T?
A própria especificação define os níveis de requisito. Uma feature ou função condicional deve ser implementada conforme o ONVIF quando o device ou client suporta aquela funcionalidade nas condições definidas pelo profile. Ela não é simplesmente convertida em uma função obrigatória para todos os produtos Profile T.
Isso é diferente de uma função marcada como M — Mandatory, que integra o mínimo necessário à conformidade correspondente.
Para engenharia de especificação, essa distinção é decisiva. Uma frase como “o equipamento deverá ser ONVIF Profile T” não prova o atendimento a toda capacidade condicional existente no profile.
Antes da segurança: como o streaming de vídeo é organizado?
Para compreender onde HTTPS, TLS e SRTP atuam, é necessário separar codificação, transporte, controle da sessão e proteção criptográfica.
H.264 e H.265 são formatos de codificação de vídeo. Eles definem como a informação visual é comprimida e representada, mas não são responsáveis por transportar o vídeo pela rede nem por estabelecer uma sessão entre câmera e VMS.
O transporte em tempo real é normalmente realizado por RTP — Real-time Transport Protocol. Já o RTSP — Real Time Streaming Protocol é utilizado para controle da sessão de streaming. Em uma representação simplificada:
Imagem capturada
↓
H.264 / H.265
↓
RTP
↓
controle por RTSP
↓
rede IPRTP — transporte da mídia
O RTP organiza a transmissão de mídia em tempo real. Seu cabeçalho inclui informações utilizadas na interpretação do fluxo, como número de sequência, timestamp e payload type. Em sistemas de vídeo IP, ele é o protocolo que efetivamente carrega a mídia encapsulada conforme os formatos aplicáveis.
RTP, isoladamente, não deve ser tratado como um mecanismo de criptografia. Um fluxo RTP convencional não adquire confidencialidade simplesmente porque está sendo transportado em uma rede IP fechada.
RTCP — controle associado ao RTP
RTCP é o protocolo de controle associado ao RTP e pode transportar informações de qualidade e sincronização da sessão. Ele não deve ser confundido com RTSP.
RTCP e RTSP são protocolos diferentes. RTCP acompanha a operação RTP; RTSP é utilizado para estabelecer e controlar a sessão de streaming.
RTSP — controle da sessão
RTSP permite operações como estabelecimento, descrição, reprodução e encerramento de sessões. Métodos como DESCRIBE, SETUP, PLAY e TEARDOWN participam dessa lógica.
Portanto, dizer simplesmente que “RTSP transporta o vídeo” é uma simplificação imprecisa. Em uma sessão convencional, o RTSP controla a sessão enquanto o RTP transporta a mídia.
Principais formas de transporte consideradas pelo ONVIF
As ONVIF Streaming Specifications descrevem diferentes formas de transporte para atender cenários de rede distintos.
RTP por UDP
O RTP pode utilizar UDP diretamente. Esse arranjo possui baixo overhead e é particularmente adequado à natureza temporal de áudio e vídeo, mas não fornece, por si só, confidencialidade criptográfica.
RTP
↓
UDP
↓
IPRTP interleaved em RTSP/TCP
Também é possível transportar mídia RTP no próprio canal TCP associado ao RTSP, utilizando o mecanismo de dados binários interleaved.
RTP
↓
RTSP / TCP
↓
IPRTP/RTSP sobre HTTP/TCP
O ONVIF também especifica tunneling via HTTP, tradicionalmente útil para atravessar ambientes em que o tráfego HTTP é mais facilmente permitido por firewalls e proxies.
RTP
↓
RTSP
↓
HTTP
↓
TCPRTP/RTSP sobre HTTPS/TCP
Quando esse tunneling é realizado por HTTPS, a conexão HTTP passa a ser protegida por TLS:
Vídeo / áudio / metadados
↓
RTP
↓
RTSP
↓
HTTP tunneling
↓
HTTPS
↓
TLS
↓
TCP
↓
IPÉ esse arranjo — RTP/RTSP/HTTPS/TCP — que deve ser associado à função condicional de secure/HTTPS streaming do Profile T.
Onde está a segurança no RTP/RTSP/HTTPS/TCP?
No mecanismo referenciado pelo Profile T, a proteção não decorre de uma transformação do RTP em SRTP. Ela decorre do TLS utilizado pelo HTTPS.
HTTPS pode ser entendido, de forma simplificada, como HTTP operando sobre uma sessão TLS. O TLS fornece mecanismos de proteção para os dados que atravessam aquele canal, incluindo confidencialidade e integridade em trânsito, além de mecanismos de autenticação do endpoint conforme a configuração de certificados e confiança utilizada.
Isso significa que o modelo arquitetural é diferente de proteger cada pacote RTP diretamente por SRTP.
TLS não é um algoritmo de criptografia
Outro erro frequente é tratar TLS como sinônimo de AES. TLS é um protocolo de segurança que estabelece uma sessão protegida e negocia os mecanismos criptográficos aplicáveis. AES pode participar das cipher suites utilizadas, mas não é correto definir “TLS = AES”.
Da mesma forma, não se deve concluir que a simples presença da palavra HTTPS comprova uma determinada cipher suite específica sem verificar a versão e a configuração de TLS efetivamente utilizadas pelos endpoints.
Certificados e confiança
A segurança de uma sessão TLS depende também da forma como o client valida a identidade do endpoint. Certificados digitais, cadeia de confiança e políticas de validação fazem parte do desenho de uma implantação segura.
Um certificado self-signed pode fornecer criptografia, mas exige um modelo de confiança coerente para que o client saiba que está se comunicando com o dispositivo pretendido. Em ambientes corporativos, a gestão de certificados deve ser tratada como parte da arquitetura de segurança, não apenas como uma opção de interface web da câmera.
Secure Streaming do Profile T não é sinônimo de SRTP
Essa é a distinção mais importante do tema.
No Profile T v1.0, a função condicional de transporte seguro é descrita como:
Streaming over RTP/RTSP/HTTPS/TCP.
Ela não é descrita como “SRTP”. A mídia RTP permanece dentro da arquitetura de tunneling RTSP/HTTP, enquanto o TLS protege o canal HTTPS.
Em uma representação simplificada:
Já o SRTP opera de forma diferente:
Nos dois casos existe proteção de mídia em trânsito, mas o ponto em que essa proteção é aplicada e a arquitetura dos protocolos não são os mesmos.
Por isso, a expressão “Profile T com Secure Streaming” não deve ser usada como prova automática de suporte a SRTP.
O que é SecureRTSPStreaming nas especificações ONVIF mais recentes?
A evolução das ONVIF Network Interface Specifications incorporou uma capacidade distinta chamada SecureRTSPStreaming.
Na Media2 Service Specification 26.06, a capability é descrita como indicação de suporte a live media streaming via RTSPS and SRTP. Essa definição separa de maneira clara o mecanismo moderno do HTTPS streaming referenciado pelo Profile T.
A Media2 também distingue diferentes capacidades de streaming, como:
RTSPStreaming— live streaming via RTSP;SecureRTSPStreaming— live streaming via RTSPS e SRTP;RTPMulticast— suporte a multicast UDP;RTP_RTSP_TCP— suporte a RTP/RTSP/TCP;RTSPWebSocketUri— suporte ao transporte RTSP/RTP sobre WebSocket, conforme especificação aplicável.
A diferença de nomenclatura é relevante: SecureRTSPStreaming é uma capability específica, não uma simples forma alternativa de escrever a função condicional HTTPS do Profile T.
O que é RTSPS?
RTSPS representa RTSP operando sobre uma conexão protegida por TLS.
De forma simplificada:
RTSP
↓
TLS
↓
TCPNas especificações atuais de secure streaming com SRTP, o canal RTSP seguro é importante porque as informações de estabelecimento e gerenciamento da sessão não podem ser transmitidas de forma insegura enquanto se pretende construir uma mídia criptograficamente protegida.
A ONVIF Streaming Specification 26.06 estabelece que TLS deve ser utilizado para RTSP quando SRTP é utilizado. A especificação também determina que um device não deve retornar RTP/SAVP ou informações MIKEY no SDP se o canal RTSP não estiver seguro.
Esse detalhe demonstra que existem duas superfícies distintas de proteção:
- control plane — comandos e negociação RTSP protegidos por TLS;
- media plane — mídia RTP protegida por SRTP.
Como funciona o SRTP?
SRTP — Secure Real-time Transport Protocol é uma extensão de segurança para RTP. Em vez de depender de um túnel TLS externo para proteger a mídia, o SRTP aplica mecanismos criptográficos ao próprio fluxo RTP.
Conceitualmente:
RTP convencional
↓
proteção SRTP
↓
SRTP / UDP
↓
rede IPA função do SRTP inclui proteção de confidencialidade, integridade/autenticação da mídia conforme o algoritmo negociado e mecanismos relacionados à proteção contra replay. O protocolo associado de controle, SRTCP, aplica proteção correspondente ao tráfego de controle do RTP.
RTP/AVP e RTP/SAVP
Em sessões RTP convencionais pode ser utilizado o perfil RTP/AVP. Para sessões protegidas por SRTP aparece RTP/SAVP, indicando o uso do Secure Audio/Video Profile.
Essa diferenciação é relevante na negociação SDP de uma sessão segura.
Algoritmos de SRTP previstos pela especificação ONVIF 26.06
A Streaming Specification 26.06 define mecanismos para negociação dos algoritmos criptográficos utilizados pelo SRTP. Entre os algoritmos listados estão:
| Identificador | Proteção principal |
AES_CM_128_HMAC_SHA1_80 | AES em counter mode + HMAC-SHA-1 com authentication tag de 80 bits |
AEAD_AES_128_GCM | AES-128-GCM em modo AEAD |
AEAD_AES_256_GCM | AES-256-GCM em modo AEAD |
NONE | caso de configuração sem proteção SRTP da mídia, conforme condições previstas pela especificação |
Aqui é necessário evitar outro erro comum: a existência de NONE não significa que o ONVIF esteja classificando mídia sem qualquer proteção como equivalente a SRTP seguro. A especificação admite cenários em que o RTSP seguro continua operando e em que a mídia pode percorrer um canal TLS, dependendo do transporte selecionado.
Portanto, a análise de uma implementação deve considerar capability, transporte efetivamente selecionado e algoritmo negociado, e não apenas um rótulo de interface.
MIKEY: gerenciamento de chaves para SRTP
Para criptografar mídia com SRTP, device e client precisam compartilhar ou estabelecer o material de chave utilizado pela sessão. O ONVIF utiliza MIKEY — Multimedia Internet KEYing para essa finalidade dentro da arquitetura definida para Secure RTSP Streaming.
A Streaming Specification atual estabelece suporte a MIKEY para key exchange e key management em devices que sinalizam SecureRTSPStreaming.
O fluxo conceitual pode ser representado assim:
A especificação também trata de renovação de chaves durante a sessão. Isso é importante em operações de longa duração, nas quais a gestão do ciclo de vida das chaves não deve depender de uma única configuração inicial estática.
Comparativo: streaming convencional, HTTPS streaming e SecureRTSPStreaming
A tabela abaixo resume as arquiteturas que não devem ser confundidas.
| Arquitetura | Controle | Transporte da mídia | Camada principal de proteção | Relação ONVIF |
| RTP/RTSP/UDP | RTSP | RTP/UDP | sem proteção criptográfica inerente | streaming convencional |
| RTP/RTSP/TCP | RTSP | RTP interleaved/TCP | sem proteção criptográfica inerente | streaming convencional |
| RTP/RTSP/HTTPS/TCP | RTSP tunneled | RTP tunneled | TLS no HTTPS | função condicional referenciada pelo Profile T |
| RTSPS + SRTP | RTSP sobre TLS | SRTP, tipicamente sobre UDP | TLS no controle + SRTP na mídia | SecureRTSPStreaming nas especificações atuais |
Essa tabela é a forma mais segura de interpretar o termo em documentação técnica: primeiro se identifica qual arquitetura está em uso; depois se avaliam as propriedades de segurança daquela arquitetura.
O que “Secure Streaming: Yes” significa em uma declaração ONVIF?
Ao avaliar um equipamento no banco de produtos conformantes, é comum encontrar a informação de que determinado modelo suporta Profile T e, separadamente, uma feature identificada como Secure Streaming.
No contexto do conjunto de features do Profile T, essa informação deve ser correlacionada à função de HTTPS streaming definida no profile, isto é, RTP/RTSP/HTTPS/TCP.
A existência de duas informações separadas é intencionalmente importante para procurement:
Profile T: conforme
+
Secure Streaming: Yesnão é a mesma afirmação que:
Profile T: conformeisoladamente.
Do mesmo modo, Secure Streaming: Yes no contexto do Profile T não deve ser transformado em:
SRTP: comprovadosem evidência técnica adicional da capability moderna correspondente.
Como verificar corretamente a conformidade de uma câmera ou VMS
A ONVIF orienta que a base oficial de Conformant Products seja utilizada para confirmar a conformidade dos produtos. Não é suficiente uma referência comercial genérica de que a marca “é ONVIF”.
A análise deve considerar pelo menos:
1. fabricante; 2. modelo exato; 3. versão de firmware associada à declaração; 4. profiles declarados; 5. features condicionais relevantes; 6. documentação de capabilities e implementação; 7. suporte correspondente no client/VMS.
Essa última etapa é frequentemente negligenciada. Interoperabilidade é uma propriedade da relação entre device e client. A câmera pode oferecer uma modalidade segura que o VMS não implementa, ou o VMS pode implementar a função sem que o device ofertado a disponibilize.
Em termos de engenharia:
suporte do device
+
suporte do client
+
configuração compatível
=
funcionalidade operacionalComo especificar Secure Streaming em projeto, memorial ou Termo de Referência
Quando o objetivo técnico é proteger o transporte entre câmera e VMS, a especificação deve declarar a capacidade pretendida. Utilizar apenas o nome do profile pode produzir uma exigência incompleta.
Uma especificação que diga somente:
> “A câmera deverá possuir ONVIF Profile T.”
estabelece um requisito relevante de interoperabilidade, mas não demonstra especificamente a presença de RTP/RTSP/HTTPS/TCP, porque essa função é condicional no Profile T.
Quando o projeto precisa da função de HTTPS streaming, a exigência deve ser formulada de forma mais precisa, por exemplo:
> O equipamento deverá possuir conformidade ONVIF Profile T e suportar streaming sobre RTP/RTSP/HTTPS/TCP, com comprovação pela documentação oficial de conformidade e/ou features aplicáveis ao modelo e firmware ofertados.
Essa redação deve ser adaptada ao contexto da contratação e ao modelo de comprovação adotado no documento.
Quando o requisito é especificamente SRTP
Se a arquitetura de cybersecurity do projeto exige que a própria mídia RTP seja protegida por SRTP, não é suficiente escrever apenas “Profile T com Secure Streaming”.
Nesse caso, a especificação deve estabelecer explicitamente o requisito de RTSPS/SRTP ou SecureRTSPStreaming, juntamente com os mecanismos de comprovação e compatibilidade entre device e client.
É recomendável verificar também:
- algoritmos suportados;
- suporte a Media2/capabilities aplicáveis;
- interoperabilidade efetiva com o VMS;
- gestão de certificados TLS;
- comportamento de key management;
- impacto sobre unicast/multicast e topologia adotada;
- procedimentos de commissioning.
Secure Streaming protege o quê — e o que ele não protege?
Criptografia de transporte é uma camada importante de segurança, mas não deve ser apresentada como proteção completa do sistema de CFTV.
Confidencialidade em trânsito
Um objetivo central é reduzir a possibilidade de que a mídia seja compreendida por um terceiro que obtenha acesso ao caminho de rede, desde que a sessão e os endpoints estejam configurados corretamente.
Integridade do transporte
TLS e SRTP incluem mecanismos destinados a detectar alterações indevidas nos dados protegidos durante o transporte, dentro dos modelos de segurança de cada protocolo.
Autenticação do endpoint
TLS pode utilizar certificados para autenticação e estabelecimento de confiança. Essa propriedade depende da correta validação do certificado e da política de confiança do client.
Autenticação e autorização do usuário são outra camada
Criptografar o fluxo não substitui controles de identidade e acesso. Senhas fracas, credenciais compartilhadas, privilégios excessivos ou contas administrativas comprometidas continuam sendo riscos independentes.
| Problema de segurança | Mecanismo relacionado |
| Confidencialidade do tráfego | TLS / SRTP |
| Integridade em trânsito | TLS / SRTP |
| Identidade do endpoint | TLS/certificados, conforme implementação |
| Autenticação de usuário | mecanismos de autenticação do sistema |
| Autorização | política de privilégios e access control |
| Integridade/autenticidade da gravação armazenada | mecanismos específicos de evidência/media signing |
| Segmentação e contenção | arquitetura de rede, VLAN, ACL, firewall |
Secure Streaming não é Media Signing
Outro conceito que precisa permanecer separado é Media Signing.
Secure Streaming trata da proteção da comunicação em trânsito. Media Signing, por sua vez, está relacionado à possibilidade de verificar propriedades de autenticidade e integridade da mídia segundo a arquitetura específica de assinatura definida pelo ONVIF.
Uma gravação ter sido transmitida por um canal seguro não significa automaticamente que ela possua uma assinatura verificável capaz de demonstrar, posteriormente, sua origem ou ausência de alteração. Da mesma forma, uma solução de media signing não substitui a necessidade de proteger o transporte enquanto a mídia atravessa a rede.
São controles complementares para problemas diferentes.
Secure Streaming também não substitui a segurança da rede
Mesmo quando vídeo e controle trafegam por mecanismos criptográficos adequados, o sistema precisa continuar sendo projetado como infraestrutura ciberfísica.
Entre os controles complementares estão:
- segmentação lógica da rede;
- VLANs e políticas entre segmentos;
- ACLs e firewall;
- restrição das interfaces de gerenciamento;
- gestão de certificados;
- hardening dos dispositivos;
- atualização e lifecycle de firmware;
- desativação de serviços desnecessários;
- contas individualizadas e menor privilégio;
- monitoramento de eventos e logs.
A criptografia do caminho reduz uma categoria de risco. Ela não torna endpoints comprometidos confiáveis nem corrige uma arquitetura de rede permissiva.
Impactos de arquitetura: TLS/TCP e SRTP/UDP não são equivalentes
O desenho de transporte também possui implicações operacionais.
Uma sessão de RTP/RTSP/HTTPS/TCP utiliza TCP e TLS. Isso envolve estabelecimento de sessão, processamento criptográfico e o comportamento de entrega confiável do TCP. Em determinadas condições, perda de pacotes pode resultar em retransmissões e head-of-line blocking.
Já o SRTP pode preservar a lógica temporal do RTP sobre UDP enquanto adiciona proteção criptográfica à mídia. Isso não significa, porém, que SRTP seja universalmente “mais rápido” ou que HTTPS streaming necessariamente produza atraso perceptível.
O comportamento real depende de fatores como:
- capacidade de processamento do device;
- aceleração criptográfica;
- quantidade de streams simultâneos;
- bitrate;
- resolução e frame rate;
- condições da rede;
- arquitetura de gravação;
- capacidade do VMS;
- estratégia unicast ou multicast.
Esses fatores devem ser avaliados por dimensionamento e testes, e não por afirmações genéricas de desempenho.
Evolução do ONVIF: do HTTPS streaming ao suporte formal a SRTP
É importante interpretar a evolução das especificações sem reescrever retroativamente o significado do Profile T.
2018 — Profile T v1.0
O Profile T consolidou o uso de Media2 e incluiu Streaming over RTP/RTSP/HTTPS/TCP como função condicional de vídeo. Essa é a referência adequada quando se interpreta o Secure Streaming associado ao Profile T.
Gerações posteriores de Media2
As especificações Media2 passaram a expor a capability SecureRTSPStreaming, explicitamente relacionada a RTSPS e SRTP.
Junho de 2026 — Network Interface Specifications 26.06
O histórico oficial da ONVIF registra, na versão 26.06, a adição de suporte a SRTP na Streaming Specification. A especificação vigente passa a detalhar o transporte SRTP por UDP, a negociação dos algoritmos, o uso obrigatório de TLS no canal RTSP quando SRTP é utilizado e o gerenciamento de chaves por MIKEY.
A formulação correta, portanto, não é dizer que “o ONVIF mudou o significado do Secure Streaming do Profile T”. O correto é dizer que as Network Interface Specifications evoluíram e passaram a especificar também Secure RTSP Streaming baseado em RTSPS e SRTP, coexistindo com a função de HTTPS streaming que integra o Profile T.
Erros comuns sobre Secure Streaming e ONVIF
| Afirmação | Interpretação correta |
| “Secure Streaming é SRTP.” | Não como definição da função do Profile T. No Profile T, a referência é RTP/RTSP/HTTPS/TCP. |
| “Todo Profile T possui Secure Streaming.” | Não. A função HTTPS é condicional. |
| “Profile T + Secure Streaming comprova SRTP.” | Não. SRTP deve ser comprovado pela capability/implementação específica. |
| “HTTPS e SRTP são a mesma proteção.” | Não. HTTPS protege um canal TLS; SRTP protege a mídia RTP. |
| “RTSP é o protocolo que carrega o vídeo.” | RTSP controla a sessão; RTP é o protocolo de mídia. |
| “TLS é AES.” | TLS é um protocolo de segurança que negocia mecanismos criptográficos. |
| “Streaming criptografado garante segurança da câmera.” | Não. Endpoint, credenciais, firmware e rede permanecem dentro do threat model. |
| “Streaming seguro garante validade ou autenticidade forense da gravação.” | Não. Proteção de transporte e gestão/autenticidade da evidência são problemas distintos. |
Checklist de engenharia para aquisição e commissioning
Ao exigir Secure Streaming em um sistema de videomonitoramento, a análise não deve terminar na ficha comercial. O processo de engenharia pode utilizar o seguinte checklist:
1. confirmar o produto no banco oficial ONVIF Conformant Products; 2. verificar o modelo exato e a versão de firmware declarada; 3. confirmar o Profile T quando ele fizer parte do requisito de interoperabilidade; 4. verificar especificamente a função de HTTPS streaming quando requerida; 5. não inferir SRTP apenas a partir do Profile T; 6. para SRTP, verificar a capability SecureRTSPStreaming e documentação técnica aplicável; 7. confirmar suporte equivalente no VMS/client; 8. definir política de certificados e confiança TLS; 9. testar estabelecimento e reconexão da sessão; 10. validar o transporte efetivamente utilizado durante commissioning; 11. avaliar impactos de desempenho com a quantidade real de streams; 12. documentar configuração, firmware e evidências de teste no As Built.
Em ambientes de maior criticidade, o commissioning pode incluir captura controlada de tráfego para verificar a modalidade de transporte, sem transformar essa atividade em tentativa de contornar os controles de segurança do sistema.
Secure Streaming deve ser tratado como requisito verificável de engenharia
A principal lição é que nomes de profiles e rótulos comerciais não substituem requisitos técnicos.
No contexto do ONVIF Profile T, Secure Streaming deve ser associado à função condicional RTP/RTSP/HTTPS/TCP, em que a proteção em trânsito é fornecida pelo HTTPS/TLS. Essa função não é obrigatória em todos os devices e clients Profile T e, por isso, precisa ser verificada quando faz parte dos requisitos do projeto.
SecureRTSPStreaming, por outro lado, é uma capability mais recente das ONVIF Network Interface Specifications e está associada a RTSPS e SRTP. Nessa arquitetura, TLS protege o canal de controle RTSP e SRTP protege a mídia, com mecanismos de negociação e gerenciamento de chaves definidos pela especificação.
Em especificações de CFTV, procurement e Owner’s Engineering, a abordagem correta é exigir a capability necessária e sua comprovação, relacionando device, client, firmware, configuração e teste de interoperabilidade. Essa abordagem evita que expressões como “ONVIF Profile T”, “Secure Streaming” e “SRTP” sejam tratadas como equivalentes quando, tecnicamente, representam elementos diferentes da arquitetura.
Referências técnicas
[1] ONVIF. ONVIF Profile T Specification v1.0. Setembro de 2018. https://www.onvif.org/wp-content/uploads/2018/09/ONVIF_Profile_T_Specification_v1-0.pdf
[2] ONVIF. Profile T — For advanced video streaming. https://www.onvif.org/profiles/profile-t/
[3] ONVIF. Streaming Specification, Version 26.06. Junho de 2026. https://www.onvif.org/specs/2606/ONVIF-Streaming-Spec-v2606.pdf
[4] ONVIF. Media2 Service Specification, Version 26.06. Junho de 2026. https://www.onvif.org/specs/2606/ONVIF-Media2-Service-Spec-v2606.pdf
[5] ONVIF. Specification History — Version 26.06. https://www.onvif.org/profiles/specifications/specification-history/
[6] ONVIF. Profiles Conformance Device Test Specification 26.06. Junho de 2026. https://www.onvif.org/wp-content/uploads/2026/07/ONVIF_Profiles_Conformance_Device_Test_Specification_26.06.pdf
[7] IETF / RFC Editor. RFC 3711 — The Secure Real-time Transport Protocol (SRTP). https://www.rfc-editor.org/rfc/rfc3711
[8] IETF / RFC Editor. RFC 3830 — MIKEY: Multimedia Internet KEYing. https://www.rfc-editor.org/rfc/rfc3830
Perguntas frequentes
Não. Na especificação Profile T v1.0, Streaming over RTP/RTSP/HTTPS/TCP é uma função condicional. Por isso, a conformidade com Profile T, isoladamente, não comprova essa capacidade.
Não. No Profile T v1.0, a função associada ao streaming seguro é RTP/RTSP/HTTPS/TCP, protegida pelo TLS do HTTPS. SRTP integra a capability mais recente SecureRTSPStreaming.
Na Media2 Service Specification 26.06, SecureRTSPStreaming indica suporte a live media streaming via RTSPS e SRTP.
É RTSP operando sobre TLS. Na arquitetura ONVIF atual para SRTP, TLS protege o canal RTSP utilizado no estabelecimento e gerenciamento da sessão segura.
Não. A feature de Secure Streaming associada ao Profile T deve ser interpretada no contexto do HTTPS streaming. Se SRTP for requisito, ele deve ser verificado explicitamente na capability e na documentação aplicável.
Verifique o modelo e firmware no banco oficial ONVIF Conformant Products, os profiles declarados e as features/capabilities aplicáveis. Em projeto, também é necessário confirmar suporte correspondente do VMS/client.
Não. Streaming seguro protege a comunicação em trânsito. Integridade e autenticidade verificável da mídia armazenada envolvem outros mecanismos, como media signing e controles de gestão da evidência.
