Secure Streaming en ONVIF no es automáticamente sinónimo de SRTP. Comprenda su significado en Profile T, el transporte RTP/RTSP/HTTPS/TCP y la evolución hacia SecureRTSPStreaming con RTSPS y SRTP.
¡Descúbrelo!
Secure Streaming, en el contexto de ONVIF Profile T, debe interpretarse a partir de la función de transporte definida por el propio profile: streaming sobre RTP/RTSP/HTTPS/TCP. En la especificación Profile T v1.0, publicada en septiembre de 2018, esta función se clasifica como condicional. Por lo tanto, la conformidad de un equipo con Profile T no permite concluir, por sí sola, que soporte esta modalidad de streaming protegido.
Esta definición tampoco debe confundirse con SRTP — Secure Real-time Transport Protocol. En las especificaciones ONVIF más recientes existe una capacidad distinta denominada SecureRTSPStreaming, asociada a RTSPS y SRTP. La diferencia es arquitectónica: en el HTTPS streaming referenciado por Profile T, la protección es proporcionada por TLS en el canal HTTPS; en SecureRTSPStreaming moderno, el control RTSP utiliza TLS y el medio puede protegerse directamente mediante SRTP.
Esta distinción es especialmente importante en diseños, especificaciones técnicas, procurement y homologación de cámaras y VMS. Exigir únicamente «ONVIF Profile T» no es lo mismo que exigir la feature de HTTPS streaming; del mismo modo, encontrar «Secure Streaming» en la declaración de conformidad de un producto Profile T no debe interpretarse automáticamente como prueba de soporte de SRTP.
¿Por Qué el Término Secure Streaming Causa Confusión en ONVIF?
«Secure Streaming» es una expresión intuitiva, pero técnicamente amplia. Fuera de un contexto normativo, puede utilizarse para describir prácticamente cualquier mecanismo que proteja un flujo de medios en tránsito. Dentro del ecosistema ONVIF, sin embargo, es necesario identificar qué especificación, profile, capability o función se está considerando.
El primer punto es que Secure Streaming no es el nombre de un protocolo de red. Los mecanismos utilizados por ONVIF se construyen sobre protocolos y servicios existentes, como RTP, RTCP, RTSP, HTTP, HTTPS, TCP, UDP, TLS y, en las especificaciones más recientes, SRTP.
El segundo punto es que un ONVIF Profile tampoco es un protocolo. Un profile define un conjunto fijo de funcionalidades para permitir que devices y clients de distintos fabricantes tengan una base previsible de interoperabilidad. Las funciones subyacentes se detallan en las ONVIF Network Interface Specifications.
Por ello, tres expresiones que parecen similares deben mantenerse separadas:
| Expresión | Significado técnico |
| ONVIF Profile T | Profile ONVIF orientado a funcionalidades avanzadas de video IP e interoperabilidad entre device y client |
| Streaming over RTP/RTSP/HTTPS/TCP | Función de transporte protegido por HTTPS/TLS referenciada por Profile T |
| SecureRTSPStreaming | Capability más reciente de Media2 para streaming seguro mediante RTSPS y SRTP |
Mezclar estas tres capas conduce a errores de especificación. El más común es afirmar que «Secure Streaming de Profile T es SRTP». Esa afirmación no corresponde a la forma en que Profile T v1.0 define su función de streaming seguro.
¿Qué Establece ONVIF Profile T sobre Secure Streaming?
Profile T fue publicado para sistemas de video basados en IP e incluye funcionalidades relacionadas con H.264/H.265, configuración de imagen, eventos, metadata streaming y otras capacidades de video. Para comprender Secure Streaming, sin embargo, la referencia más importante es la sección 7.9 — Video streaming de la especificación Profile T v1.0.
Para un device, la especificación establece, entre otros requisitos, soporte de streaming mediante RTP/UDP y mediante RTP/RTSP/HTTP/TCP. A continuación establece que, si se soporta, el device debe ser capaz de transmitir video mediante RTP/RTSP/HTTPS/TCP utilizando el Media Profile seleccionado.
En la Function List de Profile T, la diferencia aparece de forma explícita:
| Función 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 los clients, Streaming over RTP/RTSP/HTTPS/TCP también aparece como función condicional.
Esto produce una consecuencia práctica importante: Profile T y soporte de HTTPS streaming no son equivalentes. Un producto puede ser conforme con Profile T sin que esta función condicional esté presente. Cuando el requisito del diseño es utilizar efectivamente el flujo protegido, es necesario verificar la declaración de conformidad y las features aplicables al modelo y firmware ofertados.
¿Qué Significa «Conditional» en Profile T?
La propia especificación define los niveles de requisito. Una feature o función condicional debe implementarse conforme a ONVIF cuando el device o client soporta esa funcionalidad en las condiciones definidas por el profile. No se convierte simplemente en una función obligatoria para todos los productos Profile T.
Esto es diferente de una función marcada como M — Mandatory, que forma parte del mínimo necesario para la conformidad correspondiente.
Para la ingeniería de especificación, esta distinción es decisiva. Una frase como «el equipo deberá ser ONVIF Profile T» no demuestra el cumplimiento de toda capacidad condicional existente en el profile.
Antes de la Seguridad: ¿Cómo se Organiza el Streaming de Video?
Para comprender dónde actúan HTTPS, TLS y SRTP, es necesario separar codificación, transporte, control de sesión y protección criptográfica.
H.264 y H.265 son formatos de codificación de video. Definen cómo se comprime y representa la información visual, pero no son responsables de transportar el video por la red ni de establecer una sesión entre cámara y VMS.
El transporte en tiempo real normalmente se realiza mediante RTP — Real-time Transport ProtocolPor su parte, RTSP — Real Time Streaming Protocol se utiliza para controlar la sesión de streaming. En una representación simplificada:
Imagen capturada ↓ H.264 / H.265 ↓ RTP ↓ control por RTSP ↓ red IPRTP — Transporte del Medio
RTP organiza la transmisión de medios en tiempo real. Su encabezado incluye información utilizada para interpretar el flujo, como número de secuencia, timestamp y payload type. En sistemas de video IP, es el protocolo que efectivamente transporta el medio encapsulado según los formatos aplicables.
RTP, de forma aislada, no debe tratarse como un mecanismo de cifrado. Un flujo RTP convencional no adquiere confidencialidad simplemente porque se transporte por una red IP cerrada.
RTCP — Control Asociado a RTP
RTCP es el protocolo de control asociado a RTP y puede transportar información de calidad y sincronización de la sesión. No debe confundirse con RTSP.
RTCP y RTSP son protocolos diferentes. RTCP acompaña la operación RTP; RTSP se utiliza para establecer y controlar la sesión de streaming.
RTSP — Control de la Sesión
RTSP permite operaciones como establecimiento, descripción, reproducción y cierre de sesiones. Métodos como DESCRIBE, SETUP, PLAY y TEARDOWN forman parte de esta lógica.
Por lo tanto, decir simplemente que «RTSP transporta el video» es una simplificación imprecisa. En una sesión convencional, RTSP controla la sesión mientras RTP transporta el medio.
Principales Formas de Transporte Consideradas por ONVIF
Las ONVIF Streaming Specifications describen diferentes formas de transporte para atender distintos escenarios de red.
RTP sobre UDP
RTP puede utilizar UDP directamente. Esta disposición tiene bajo overhead y es especialmente adecuada para la naturaleza temporal del audio y el video, pero no proporciona, por sí sola, confidencialidad criptográfica.
RTP ↓ UDP ↓ IPRTP Interleaved en RTSP/TCP
También es posible transportar medios RTP dentro del propio canal TCP asociado a RTSP, utilizando el mecanismo de datos binarios interleaved.
RTP ↓ RTSP / TCP ↓ IPRTP/RTSP sobre HTTP/TCP
ONVIF también especifica tunneling mediante HTTP, tradicionalmente útil para atravesar entornos en los que el tráfico HTTP es permitido con mayor facilidad por firewalls y proxies.
RTP ↓ RTSP ↓ HTTP ↓ TCPRTP/RTSP sobre HTTPS/TCP
Cuando este tunneling se realiza mediante HTTPS, la conexión HTTP pasa a estar protegida por TLS:
Video / audio / metadatos ↓ RTP ↓ RTSP ↓ HTTP tunneling ↓ HTTPS ↓ TLS ↓ TCP ↓ IPEsta es la disposición — RTP/RTSP/HTTPS/TCP — que debe asociarse con la función condicional de secure/HTTPS streaming de Profile T.
¿Dónde Está la Seguridad en RTP/RTSP/HTTPS/TCP?
En el mecanismo referenciado por Profile T, la protección no procede de transformar RTP en SRTP. Procede del TLS utilizado por HTTPS.
HTTPS puede entenderse, de forma simplificada, como HTTP operando sobre una sesión TLS. TLS proporciona mecanismos de protección para los datos que atraviesan ese canal, incluida confidencialidad e integridad en tránsito, además de mecanismos de autenticación del endpoint según la configuración de certificados y confianza utilizada.
Esto significa que el modelo arquitectónico es distinto de proteger cada paquete RTP directamente mediante SRTP.
TLS No Es un Algoritmo de Cifrado
Otro error frecuente es tratar TLS como sinónimo de AES. TLS es un protocolo de seguridad que establece una sesión protegida y negocia los mecanismos criptográficos aplicables. AES puede formar parte de las cipher suites utilizadas, pero no es correcto definir «TLS = AES».
Del mismo modo, no debe concluirse que la simple presencia de la palabra HTTPS demuestra una cipher suite específica sin verificar la versión y configuración de TLS efectivamente utilizadas por los endpoints.
Certificados y Confianza
La seguridad de una sesión TLS también depende de cómo el client valida la identidad del endpoint. Los certificados digitales, la cadena de confianza y las políticas de validación forman parte del diseño de una implantación segura.
Un certificado self-signed puede proporcionar cifrado, pero exige un modelo de confianza coherente para que el client sepa que se está comunicando con el dispositivo previsto. En entornos corporativos, la gestión de certificados debe tratarse como parte de la arquitectura de seguridad, no únicamente como una opción de la interfaz web de la cámara.
Secure Streaming de Profile T No Es Sinónimo de SRTP
Esta es la distinción más importante del tema.
En Profile T v1.0, la función condicional de transporte seguro se describe como:
Streaming over RTP/RTSP/HTTPS/TCP.
No se describe como «SRTP». El medio RTP permanece dentro de la arquitectura de tunneling RTSP/HTTP, mientras TLS protege el canal HTTPS.
En una representación simplificada:
SRTP, en cambio, opera de forma diferente:
En ambos casos existe protección del medio en tránsito, pero el punto en que se aplica esa protección y la arquitectura de los protocolos no son los mismos.
Por ello, la expresión «Profile T con Secure Streaming» no debe utilizarse como prueba automática de soporte de SRTP.
¿Qué Es SecureRTSPStreaming en las Especificaciones ONVIF Más Recientes?
La evolución de las ONVIF Network Interface Specifications incorporó una capacidad distinta denominada SecureRTSPStreaming.
En la Media2 Service Specification 26.06, la capability se describe como una indicación de soporte para live media streaming via RTSPS and SRTP. Esta definición separa claramente el mecanismo moderno del HTTPS streaming referenciado por Profile T.
Media2 también distingue diferentes capacidades de streaming, como:
RTSPStreaming— live streaming via RTSP;SecureRTSPStreaming— live streaming via RTSPS y SRTP;RTPMulticast— soporte de multicast UDP;RTP_RTSP_TCP— soporte de RTP/RTSP/TCP;RTSPWebSocketUri— soporte del transporte RTSP/RTP sobre WebSocket, conforme a la especificación aplicable.
La diferencia de nomenclatura es relevante: SecureRTSPStreaming es una capability específica, no una simple forma alternativa de escribir la función condicional HTTPS de Profile T.
¿Qué Es RTSPS?
RTSPS representa RTSP operando sobre una conexión protegida por TLS.
De forma simplificada:
RTSP
↓
TLS
↓
TCPEn las especificaciones actuales de secure streaming con SRTP, el canal RTSP seguro es importante porque la información de establecimiento y gestión de la sesión no puede transmitirse de forma insegura mientras se pretende construir un medio protegido criptográficamente.
La ONVIF Streaming Specification 26.06 establece que TLS debe utilizarse para RTSP cuando se utiliza SRTP. La especificación también determina que un device no debe devolver RTP/SAVP ni información MIKEY en el SDP si el canal RTSP no es seguro.
Este detalle demuestra que existen dos superficies distintas de protección:
- control plane — comandos y negociación RTSP protegidos por TLS;
- media plane — medio RTP protegido por SRTP.
¿Cómo Funciona SRTP?
SRTP — Secure Real-time Transport Protocol es una extensión de seguridad para RTP. En lugar de depender de un túnel TLS externo para proteger el medio, SRTP aplica mecanismos criptográficos al propio flujo RTP.
Conceptualmente:
RTP convencional ↓ protección SRTP ↓ SRTP / UDP ↓ red IPLa función de SRTP incluye protección de confidencialidad, integridad/autenticación del medio según el algoritmo negociado y mecanismos relacionados con la protección contra replay. El protocolo de control asociado, SRTCP, aplica la protección correspondiente al tráfico de control de RTP.
RTP/AVP y RTP/SAVP
En sesiones RTP convencionales puede utilizarse el perfil RTP/AVP. Para sesiones protegidas por SRTP aparece RTP/SAVP, indicando el uso del Secure Audio/Video Profile.
Esta diferenciación es relevante en la negociación SDP de una sesión segura.
Algoritmos SRTP Previstos por la Especificación ONVIF 26.06
La Streaming Specification 26.06 define mecanismos para negociar los algoritmos criptográficos utilizados por SRTP. Entre los algoritmos enumerados se encuentran:
| Identificador | Protección principal |
AES_CM_128_HMAC_SHA1_80 | AES en counter mode + HMAC-SHA-1 con authentication tag de 80 bits |
AEAD_AES_128_GCM | AES-128-GCM en modo AEAD |
AEAD_AES_256_GCM | AES-256-GCM en modo AEAD |
NONE | caso de configuración sin protección SRTP del medio, conforme a las condiciones previstas por la especificación |
Aquí es necesario evitar otro error común: la existencia de NONE no significa que ONVIF esté clasificando medios sin ninguna protección como equivalentes a SRTP seguro. La especificación admite escenarios en los que RTSP seguro continúa operando y en los que el medio puede recorrer un canal TLS, dependiendo del transporte seleccionado.
Por lo tanto, el análisis de una implementación debe considerar capability, transporte efectivamente seleccionado y algoritmo negociado, y no únicamente una etiqueta de interfaz.
MIKEY: Gestión de Claves para SRTP
Para cifrar medios con SRTP, device y client necesitan compartir o establecer el material de clave utilizado por la sesión. ONVIF utiliza MIKEY — Multimedia Internet KEYing para esta finalidad dentro de la arquitectura definida para Secure RTSP Streaming.
La Streaming Specification actual establece soporte de MIKEY para key exchange y key management en devices que señalan SecureRTSPStreaming.
El flujo conceptual puede representarse así:
La especificación también trata la renovación de claves durante la sesión. Esto es importante en operaciones de larga duración, en las que la gestión del ciclo de vida de las claves no debe depender de una única configuración inicial estática.
Comparación: Streaming Convencional, HTTPS Streaming y SecureRTSPStreaming
La tabla siguiente resume las arquitecturas que no deben confundirse.
| Arquitectura | Control | Transporte del medio | Capa principal de protección | Relación ONVIF |
| RTP/RTSP/UDP | RTSP | RTP/UDP | sin protección criptográfica inherente | streaming convencional |
| RTP/RTSP/TCP | RTSP | RTP interleaved/TCP | sin protección criptográfica inherente | streaming convencional |
| RTP/RTSP/HTTPS/TCP | RTSP tunneled | RTP tunneled | TLS en HTTPS | función condicional referenciada por Profile T |
| RTSPS + SRTP | RTSP sobre TLS | SRTP, típicamente sobre UDP | TLS en el control + SRTP en el medio | SecureRTSPStreaming en las especificaciones actuales |
Esta tabla es la forma más segura de interpretar el término en documentación técnica: primero se identifica qué arquitectura está en uso; después se evalúan las propiedades de seguridad de esa arquitectura.
¿Qué Significa «Secure Streaming: Yes» en una Declaración ONVIF?
Al evaluar un equipo en la base de productos conformes, es habitual encontrar información de que determinado modelo soporta Profile T y, por separado, una feature identificada como Secure Streaming.
En el contexto del conjunto de features de Profile T, esta información debe correlacionarse con la función de HTTPS streaming definida en el profile, es decir, RTP/RTSP/HTTPS/TCP.
La existencia de dos informaciones separadas es intencionadamente importante para procurement:
Profile T: conforme + Secure Streaming: Yesno es la misma afirmación que:
Profile T: conformede forma aislada.
Del mismo modo, Secure Streaming: Yes en el contexto de Profile T no debe transformarse en:
SRTP: demostradosin evidencia técnica adicional de la capability moderna correspondiente.
Cómo Verificar Correctamente la Conformidad de una Cámara o VMS
ONVIF recomienda utilizar la base oficial de Conformant Products para confirmar la conformidad de los productos. No es suficiente una referencia comercial genérica de que la marca «es ONVIF».
El análisis debe considerar al menos:
1. fabricante; 2. modelo exacto; 3. versión de firmware asociada a la declaración; 4. profiles declarados; 5. features condicionales relevantes; 6. documentación de capabilities e implementación; 7. soporte correspondiente en el client/VMS.
Esta última etapa suele descuidarse. La interoperabilidad es una propiedad de la relación entre device y client. La cámara puede ofrecer una modalidad segura que el VMS no implemente, o el VMS puede implementar la función sin que el device ofertado la proporcione.
En términos de ingeniería:
soporte del device + soporte del client + configuración compatible = funcionalidad operativaCómo Especificar Secure Streaming en un Diseño, Memoria o Término de Referencia
Cuando el objetivo técnico es proteger el transporte entre cámara y VMS, la especificación debe declarar la capacidad pretendida. Utilizar únicamente el nombre del profile puede producir un requisito incompleto.
Una especificación que diga solamente:
> «La cámara deberá contar con ONVIF Profile T.»
establece un requisito relevante de interoperabilidad, pero no demuestra específicamente la presencia de RTP/RTSP/HTTPS/TCP, porque esta función es condicional en Profile T.
Cuando el diseño necesita la función de HTTPS streaming, el requisito debe formularse de forma más precisa, por ejemplo:
> El equipo deberá disponer de conformidad ONVIF Profile T y soportar streaming sobre RTP/RTSP/HTTPS/TCP, con comprobación mediante la documentación oficial de conformidad y/o features aplicables al modelo y firmware ofertados.
Esta redacción debe adaptarse al contexto de contratación y al modelo de comprobación adoptado en el documento.
Cuando el Requisito Es Específicamente SRTP
Si la arquitectura de cybersecurity del proyecto exige que el propio medio RTP esté protegido mediante SRTP, no es suficiente escribir únicamente «Profile T con Secure Streaming».
En ese caso, la especificación debe establecer explícitamente el requisito de RTSPS/SRTP o SecureRTSPStreaming, junto con los mecanismos de comprobación y compatibilidad entre device y client.
También se recomienda verificar:
- algoritmos soportados;
- soporte de Media2/capabilities aplicables;
- interoperabilidad efectiva con el VMS;
- gestión de certificados TLS;
- comportamiento de key management;
- impacto sobre unicast/multicast y la topología adoptada;
- procedimientos de commissioning.
¿Qué Protege Secure Streaming — y Qué No Protege?
El cifrado del transporte es una capa importante de seguridad, pero no debe presentarse como protección completa del sistema de videovigilancia.
Confidencialidad en Tránsito
Un objetivo central es reducir la posibilidad de que el medio pueda ser comprendido por un tercero que obtenga acceso a la ruta de red, siempre que la sesión y los endpoints estén configurados correctamente.
Integridad del Transporte
TLS y SRTP incluyen mecanismos destinados a detectar modificaciones indebidas en los datos protegidos durante el transporte, dentro de los modelos de seguridad de cada protocolo.
Autenticación del Endpoint
TLS puede utilizar certificados para autenticación y establecimiento de confianza. Esta propiedad depende de la validación correcta del certificado y de la política de confianza del client.
La Autenticación y Autorización del Usuario Son Otra Capa
Cifrar el flujo no sustituye los controles de identidad y acceso. Contraseñas débiles, credenciales compartidas, privilegios excesivos o cuentas administrativas comprometidas siguen siendo riesgos independientes.
| Problema de seguridad | Mecanismo relacionado |
| Confidencialidad del tráfico | TLS / SRTP |
| Integridad en tránsito | TLS / SRTP |
| Identidad del endpoint | TLS/certificados, según implementación |
| Autenticación de usuario | mecanismos de autenticación del sistema |
| Autorización | política de privilegios y access control |
| Integridad/autenticidad de la grabación almacenada | mecanismos específicos de evidencia/media signing |
| Segmentación y contención | arquitectura de red, VLAN, ACL, firewall |
Secure Streaming No Es Media Signing
Otro concepto que debe mantenerse separado es Media Signing.
Secure Streaming trata de la protección de la comunicación en tránsito. Media Signing, por su parte, está relacionado con la posibilidad de verificar propiedades de autenticidad e integridad del medio según la arquitectura específica de firma definida por ONVIF.
Que una grabación haya sido transmitida por un canal seguro no significa automáticamente que posea una firma verificable capaz de demostrar posteriormente su origen o ausencia de modificación. Del mismo modo, una solución de media signing no sustituye la necesidad de proteger el transporte mientras el medio atraviesa la red.
Son controles complementarios para problemas diferentes.
Secure Streaming Tampoco Sustituye la Seguridad de la Red
Incluso cuando video y control circulan mediante mecanismos criptográficos adecuados, el sistema debe seguir diseñándose como infraestructura ciberfísica.
Entre los controles complementarios se encuentran:
- segmentación lógica de la red;
- VLAN y políticas entre segmentos;
- ACL y firewall;
- restricción de las interfaces de gestión;
- gestión de certificados;
- hardening de los dispositivos;
- actualización y lifecycle de firmware;
- desactivación de servicios innecesarios;
- cuentas individualizadas y mínimo privilegio;
- monitoreo de eventos y logs.
El cifrado de la ruta reduce una categoría de riesgo. No convierte endpoints comprometidos en confiables ni corrige una arquitectura de red permisiva.
Impactos de Arquitectura: TLS/TCP y SRTP/UDP No Son Equivalentes
El diseño de transporte también tiene implicaciones operativas.
Una sesión RTP/RTSP/HTTPS/TCP utiliza TCP y TLS. Esto implica establecimiento de sesión, procesamiento criptográfico y el comportamiento de entrega confiable de TCP. En determinadas condiciones, la pérdida de paquetes puede provocar retransmisiones y head-of-line blocking.
SRTP, por su parte, puede preservar la lógica temporal de RTP sobre UDP mientras añade protección criptográfica al medio. Sin embargo, esto no significa que SRTP sea universalmente «más rápido» ni que HTTPS streaming produzca necesariamente un retardo perceptible.
El comportamiento real depende de factores como:
- capacidad de procesamiento del device;
- aceleración criptográfica;
- cantidad de streams simultáneos;
- bitrate;
- resolución y frame rate;
- condiciones de la red;
- arquitectura de grabación;
- capacidad del VMS;
- estrategia unicast o multicast.
Estos factores deben evaluarse mediante dimensionamiento y pruebas, no mediante afirmaciones genéricas de rendimiento.
Evolución de ONVIF: del HTTPS Streaming al Soporte Formal de SRTP
Es importante interpretar la evolución de las especificaciones sin reescribir retroactivamente el significado de Profile T.
2018 — Profile T v1.0
Profile T consolidó el uso de Media2 e incluyó Streaming over RTP/RTSP/HTTPS/TCP como función condicional de video. Esta es la referencia adecuada al interpretar Secure Streaming asociado a Profile T.
Generaciones Posteriores de Media2
Las especificaciones Media2 pasaron a exponer la capability SecureRTSPStreaming, explícitamente relacionada con RTSPS y SRTP.
Junio de 2026 — Network Interface Specifications 26.06
El historial oficial de ONVIF registra, en la versión 26.06, la incorporación de soporte de SRTP en la Streaming Specification. La especificación vigente pasa a detallar el transporte SRTP sobre UDP, la negociación de algoritmos, el uso obligatorio de TLS en el canal RTSP cuando se utiliza SRTP y la gestión de claves mediante MIKEY.
Por lo tanto, la formulación correcta no es decir que «ONVIF cambió el significado del Secure Streaming de Profile T». Lo correcto es decir que las Network Interface Specifications evolucionaron y pasaron a especificar también Secure RTSP Streaming basado en RTSPS y SRTP, coexistiendo con la función de HTTPS streaming que integra Profile T.
Errores Comunes sobre Secure Streaming y ONVIF
| Afirmación | Interpretación correcta |
| «Secure Streaming es SRTP.» | No como definición de la función de Profile T. En Profile T, la referencia es RTP/RTSP/HTTPS/TCP. |
| «Todo Profile T dispone de Secure Streaming.» | No. La función HTTPS es condicional. |
| «Profile T + Secure Streaming demuestra SRTP.» | No. SRTP debe demostrarse mediante la capability/implementación específica. |
| «HTTPS y SRTP son la misma protección.» | No. HTTPS protege un canal TLS; SRTP protege el medio RTP. |
| «RTSP es el protocolo que transporta el video.» | RTSP controla la sesión; RTP es el protocolo del medio. |
| «TLS es AES.» | TLS es un protocolo de seguridad que negocia mecanismos criptográficos. |
| «El streaming cifrado garantiza la seguridad de la cámara.» | No. Endpoint, credenciales, firmware y red permanecen dentro del threat model. |
| «El streaming seguro garantiza la validez o autenticidad forense de la grabación.» | No. La protección del transporte y la gestión/autenticidad de la evidencia son problemas distintos. |
Checklist de Ingeniería para Adquisición y Commissioning
Al exigir Secure Streaming en un sistema de videovigilancia, el análisis no debe terminar en la ficha comercial. El proceso de ingeniería puede utilizar el siguiente checklist:
1. confirmar el producto en la base oficial ONVIF Conformant Products; 2. verificar el modelo exacto y la versión de firmware declarada; 3. confirmar Profile T cuando forme parte del requisito de interoperabilidad; 4. verificar específicamente la función de HTTPS streaming cuando sea requerida; 5. no inferir SRTP únicamente a partir de Profile T; 6. para SRTP, verificar la capability SecureRTSPStreaming y la documentación técnica aplicable; 7. confirmar soporte equivalente en el VMS/client; 8. definir la política de certificados y confianza TLS; 9. probar el establecimiento y reconexión de la sesión; 10. validar el transporte efectivamente utilizado durante commissioning; 11. evaluar impactos de rendimiento con la cantidad real de streams; 12. documentar configuración, firmware y evidencias de prueba en el As-Built.
En entornos de mayor criticidad, el commissioning puede incluir captura controlada de tráfico para verificar la modalidad de transporte, sin convertir esta actividad en un intento de eludir los controles de seguridad del sistema.
Secure Streaming Debe Tratarse como un Requisito de Ingeniería Verificable
La principal lección es que los nombres de profiles y las etiquetas comerciales no sustituyen requisitos técnicos.
En el contexto de ONVIF Profile T, Secure Streaming debe asociarse con la función condicional RTP/RTSP/HTTPS/TCP, en la que la protección en tránsito es proporcionada por HTTPS/TLS. Esta función no es obligatoria en todos los devices y clients Profile T y, por ello, debe verificarse cuando forme parte de los requisitos del diseño.
SecureRTSPStreaming, por otro lado, es una capability más reciente de las ONVIF Network Interface Specifications y está asociada con RTSPS y SRTP. En esta arquitectura, TLS protege el canal de control RTSP y SRTP protege el medio, con mecanismos de negociación y gestión de claves definidos por la especificación.
En especificaciones de videovigilancia, procurement y Owner’s Engineering, el enfoque correcto es exigir la capability necesaria y su comprobación, relacionando device, client, firmware, configuración y prueba de interoperabilidad. Este enfoque evita que expresiones como «ONVIF Profile T», «Secure Streaming» y «SRTP» se traten como equivalentes cuando, técnicamente, representan elementos diferentes de la arquitectura.
Referencias Técnicas
[1] ONVIF. ONVIF Profile T Specification v1.0. Septiembre 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. Junio de 2026. https://www.onvif.org/specs/2606/ONVIF-Streaming-Spec-v2606.pdf
[4] ONVIF. Media2 Service Specification, Version 26.06. Junio 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. Junio 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
Preguntas Frecuentes
No. En la especificación Profile T v1.0, Streaming over RTP/RTSP/HTTPS/TCP es una función condicional. Por ello, la conformidad con Profile T, de forma aislada, no demuestra esta capacidad.
No. En Profile T v1.0, la función asociada al streaming seguro es RTP/RTSP/HTTPS/TCP, protegida por TLS de HTTPS. SRTP forma parte de la capability más reciente SecureRTSPStreaming.
En Media2 Service Specification 26.06, SecureRTSPStreaming indica soporte para live media streaming via RTSPS y SRTP.
Es RTSP operando sobre TLS. En la arquitectura ONVIF actual para SRTP, TLS protege el canal RTSP utilizado para establecer y gestionar la sesión segura.
No. La feature de Secure Streaming asociada a Profile T debe interpretarse en el contexto de HTTPS streaming. Si SRTP es un requisito, debe verificarse explícitamente en la capability y la documentación aplicable.
Verifique el modelo y firmware en la base oficial ONVIF Conformant Products, los profiles declarados y las features/capabilities aplicables. En el diseño, también es necesario confirmar el soporte correspondiente del VMS/client.
No. El streaming seguro protege la comunicación en tránsito. La integridad y autenticidad verificable del medio almacenado involucran otros mecanismos, como media signing y controles de gestión de evidencia.
