{"id":82490,"date":"2026-09-23T09:32:32","date_gmt":"2026-09-23T12:32:32","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=82490"},"modified":"2026-09-23T09:32:32","modified_gmt":"2026-09-23T12:32:32","slug":"secure-streaming-onvif-profile-t-https-rtsps-srtp-2","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/es-es\/contenido\/articulos-tecnicos\/secure-streaming-onvif-profile-t-https-rtsps-srtp-2\/","title":{"rendered":"Secure Streaming en ONVIF: Profile T, HTTPS, RTSPS y SRTP"},"content":{"rendered":"\n

Secure Streaming, en el contexto de ONVIF Profile T<\/strong>, debe interpretarse a partir de la funci\u00f3n de transporte definida por el propio profile: streaming sobre RTP\/RTSP\/HTTPS\/TCP<\/strong>. En la especificaci\u00f3n Profile T v1.0, publicada en septiembre de 2018, esta funci\u00f3n se clasifica como condicional<\/strong>. Por lo tanto, la conformidad de un equipo con Profile T no permite concluir, por s\u00ed sola, que soporte esta modalidad de streaming protegido.<\/p>\n\n\n\n

Esta definici\u00f3n tampoco debe confundirse con SRTP \u2014 Secure Real-time Transport Protocol<\/strong>. En las especificaciones ONVIF m\u00e1s recientes existe una capacidad distinta denominada SecureRTSPStreaming<\/code>, asociada a RTSPS y SRTP<\/strong>. La diferencia es arquitect\u00f3nica: en el HTTPS streaming referenciado por Profile T, la protecci\u00f3n es proporcionada por TLS en el canal HTTPS<\/strong>; en SecureRTSPStreaming moderno, el control RTSP utiliza TLS y el medio puede protegerse directamente mediante SRTP.<\/p>\n\n\n\n

Esta distinci\u00f3n es especialmente importante en dise\u00f1os, especificaciones t\u00e9cnicas, procurement y homologaci\u00f3n de c\u00e1maras y VMS. Exigir \u00fanicamente \u00abONVIF Profile T\u00bb no es lo mismo que exigir la feature de HTTPS streaming; del mismo modo, encontrar \u00abSecure Streaming\u00bb en la declaraci\u00f3n de conformidad de un producto Profile T no debe interpretarse autom\u00e1ticamente como prueba de soporte de SRTP.<\/p>\n\n\n\n\n

\u00bfPor Qu\u00e9 el T\u00e9rmino Secure Streaming Causa Confusi\u00f3n en ONVIF?<\/h2>\n\n\n\n

\u00abSecure Streaming\u00bb es una expresi\u00f3n intuitiva, pero t\u00e9cnicamente amplia. Fuera de un contexto normativo, puede utilizarse para describir pr\u00e1cticamente cualquier mecanismo que proteja un flujo de medios en tr\u00e1nsito. Dentro del ecosistema ONVIF, sin embargo, es necesario identificar qu\u00e9 especificaci\u00f3n, profile, capability o funci\u00f3n<\/strong> se est\u00e1 considerando.<\/p>\n\n\n\n

El primer punto es que Secure Streaming no es el nombre de un protocolo de red<\/strong>. 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\u00e1s recientes, SRTP.<\/p>\n\n\n\n

El segundo punto es que un ONVIF Profile tampoco es un protocolo<\/strong>. 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.<\/p>\n\n\n\n

Por ello, tres expresiones que parecen similares deben mantenerse separadas:<\/p>\n\n\n\n

Expresi\u00f3n<\/td>Significado t\u00e9cnico<\/td><\/tr>
ONVIF Profile T<\/strong><\/td>Profile ONVIF orientado a funcionalidades avanzadas de video IP e interoperabilidad entre device y client<\/td><\/tr>
Streaming over RTP\/RTSP\/HTTPS\/TCP<\/strong><\/td>Funci\u00f3n de transporte protegido por HTTPS\/TLS referenciada por Profile T<\/td><\/tr>
SecureRTSPStreaming<\/strong><\/td>Capability m\u00e1s reciente de Media2 para streaming seguro mediante RTSPS y SRTP<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Mezclar estas tres capas conduce a errores de especificaci\u00f3n. El m\u00e1s com\u00fan es afirmar que \u00abSecure Streaming de Profile T es SRTP\u00bb. Esa afirmaci\u00f3n no corresponde a la forma en que Profile T v1.0 define su funci\u00f3n de streaming seguro.<\/p>\n\n\n\n\n

\u00bfQu\u00e9 Establece ONVIF Profile T sobre Secure Streaming?<\/h2>\n\n\n\n

Profile T fue publicado para sistemas de video basados en IP e incluye funcionalidades relacionadas con H.264\/H.265, configuraci\u00f3n de imagen, eventos, metadata streaming y otras capacidades de video. Para comprender Secure Streaming, sin embargo, la referencia m\u00e1s importante es la secci\u00f3n 7.9 \u2014 Video streaming<\/strong> de la especificaci\u00f3n Profile T v1.0.<\/p>\n\n\n\n

Para un device, la especificaci\u00f3n establece, entre otros requisitos, soporte de streaming mediante RTP\/UDP<\/strong> y mediante RTP\/RTSP\/HTTP\/TCP<\/strong>. A continuaci\u00f3n establece que, si se soporta<\/strong>, el device debe ser capaz de transmitir video mediante RTP\/RTSP\/HTTPS\/TCP<\/strong> utilizando el Media Profile seleccionado.<\/p>\n\n\n\n

En la Function List de Profile T, la diferencia aparece de forma expl\u00edcita:<\/p>\n\n\n\n

Funci\u00f3n de streaming<\/td>Device Profile T<\/td><\/tr>
Streaming over RTP\/UDP<\/td>M \u2014 Mandatory<\/strong><\/td><\/tr>
Streaming over RTP\/RTSP\/HTTP\/TCP<\/td>M \u2014 Mandatory<\/strong><\/td><\/tr>
Streaming over RTP\/RTSP\/HTTPS\/TCP<\/td>C \u2014 Conditional<\/strong><\/td><\/tr>
Streaming over RTP\/UDP Multicast<\/td>M \u2014 Mandatory<\/strong><\/td><\/tr>
Streaming over RTP\/RTSP\/TCP\/WebSocket<\/td>C \u2014 Conditional<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Para los clients, Streaming over RTP\/RTSP\/HTTPS\/TCP<\/code> tambi\u00e9n aparece como funci\u00f3n condicional<\/strong>.<\/p>\n\n\n\n

Esto produce una consecuencia pr\u00e1ctica importante: Profile T y soporte de HTTPS streaming no son equivalentes<\/strong>. Un producto puede ser conforme con Profile T sin que esta funci\u00f3n condicional est\u00e9 presente. Cuando el requisito del dise\u00f1o es utilizar efectivamente el flujo protegido, es necesario verificar la declaraci\u00f3n de conformidad y las features aplicables al modelo y firmware<\/strong> ofertados.<\/p>\n\n\n\n

\u00bfQu\u00e9 Significa \u00abConditional\u00bb en Profile T?<\/h3>\n\n\n\n

La propia especificaci\u00f3n define los niveles de requisito. Una feature o funci\u00f3n 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\u00f3n obligatoria para todos los productos Profile T.<\/p>\n\n\n\n

Esto es diferente de una funci\u00f3n marcada como M \u2014 Mandatory<\/strong>, que forma parte del m\u00ednimo necesario para la conformidad correspondiente.<\/p>\n\n\n\n

Para la ingenier\u00eda de especificaci\u00f3n, esta distinci\u00f3n es decisiva. Una frase como \u00abel equipo deber\u00e1 ser ONVIF Profile T\u00bb no demuestra el cumplimiento de toda capacidad condicional existente en el profile.<\/p>\n\n\n\n\n

Antes de la Seguridad: \u00bfC\u00f3mo se Organiza el Streaming de Video?<\/h2>\n\n\n\n

Para comprender d\u00f3nde act\u00faan HTTPS, TLS y SRTP, es necesario separar codificaci\u00f3n, transporte, control de sesi\u00f3n y protecci\u00f3n criptogr\u00e1fica<\/strong>.<\/p>\n\n\n\n

H.264 y H.265 son formatos de codificaci\u00f3n de video. Definen c\u00f3mo se comprime y representa la informaci\u00f3n visual, pero no son responsables de transportar el video por la red ni de establecer una sesi\u00f3n entre c\u00e1mara y VMS.<\/p>\n\n\n\n

El transporte en tiempo real normalmente se realiza mediante RTP \u2014 Real-time Transport Protocol<\/strong>Por su parte, RTSP \u2014 Real Time Streaming Protocol<\/strong> se utiliza para controlar la sesi\u00f3n de streaming. En una representaci\u00f3n simplificada:<\/p>\n\n\n\n

Imagen capturada \u2193 H.264 \/ H.265 \u2193 RTP \u2193 control por RTSP \u2193 red IP<\/code><\/pre>\n\n\n\n
RTP \u2014 Transporte del Medio<\/h3>\n\n\n\n
RTP organiza la transmisi\u00f3n de medios en tiempo real. Su encabezado incluye informaci\u00f3n utilizada para interpretar el flujo, como n\u00famero de secuencia, timestamp y payload type. En sistemas de video IP, es el protocolo que efectivamente transporta el medio encapsulado seg\u00fan los formatos aplicables.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
RTCP \u2014 Control Asociado a RTP<\/h3>\n\n\n\n
RTCP es el protocolo de control asociado a RTP y puede transportar informaci\u00f3n de calidad y sincronizaci\u00f3n de la sesi\u00f3n. No debe confundirse con RTSP.<\/p>\n\n\n\n
RTCP y RTSP son protocolos diferentes.<\/strong> RTCP acompa\u00f1a la operaci\u00f3n RTP; RTSP se utiliza para establecer y controlar la sesi\u00f3n de streaming.<\/p>\n\n\n\n
RTSP \u2014 Control de la Sesi\u00f3n<\/h3>\n\n\n\n
RTSP permite operaciones como establecimiento, descripci\u00f3n, reproducci\u00f3n y cierre de sesiones. M\u00e9todos como DESCRIBE<\/code>, SETUP<\/code>, PLAY<\/code> y TEARDOWN<\/code> forman parte de esta l\u00f3gica.<\/p>\n\n\n\n
Por lo tanto, decir simplemente que \u00abRTSP transporta el video\u00bb es una simplificaci\u00f3n imprecisa. En una sesi\u00f3n convencional, RTSP controla la sesi\u00f3n mientras RTP transporta el medio.<\/p>\n\n\n\n\n
Principales Formas de Transporte Consideradas por ONVIF<\/h2>\n\n\n\n
Las ONVIF Streaming Specifications describen diferentes formas de transporte para atender distintos escenarios de red.<\/p>\n\n\n\n
RTP sobre UDP<\/h3>\n\n\n\n
RTP puede utilizar UDP directamente. Esta disposici\u00f3n tiene bajo overhead y es especialmente adecuada para la naturaleza temporal del audio y el video, pero no proporciona, por s\u00ed sola, confidencialidad criptogr\u00e1fica.<\/p>\n\n\n\n
RTP \u2193 UDP \u2193 IP<\/code><\/pre>\n\n\n\n
RTP Interleaved en RTSP\/TCP<\/h3>\n\n\n\n
Tambi\u00e9n es posible transportar medios RTP dentro del propio canal TCP asociado a RTSP, utilizando el mecanismo de datos binarios interleaved.<\/p>\n\n\n\n
RTP \u2193 RTSP \/ TCP \u2193 IP<\/code><\/pre>\n\n\n\n
RTP\/RTSP sobre HTTP\/TCP<\/h3>\n\n\n\n
ONVIF tambi\u00e9n especifica tunneling mediante HTTP, tradicionalmente \u00fatil para atravesar entornos en los que el tr\u00e1fico HTTP es permitido con mayor facilidad por firewalls y proxies.<\/p>\n\n\n\n
RTP \u2193 RTSP \u2193 HTTP \u2193 TCP<\/code><\/pre>\n\n\n\n
RTP\/RTSP sobre HTTPS\/TCP<\/h3>\n\n\n\n
Cuando este tunneling se realiza mediante HTTPS, la conexi\u00f3n HTTP pasa a estar protegida por TLS:<\/p>\n\n\n\n
Video \/ audio \/ metadatos \u2193 RTP \u2193 RTSP \u2193 HTTP tunneling \u2193 HTTPS \u2193 TLS \u2193 TCP \u2193 IP<\/code><\/pre>\n\n\n\n
Esta es la disposici\u00f3n \u2014 RTP\/RTSP\/HTTPS\/TCP<\/strong> \u2014 que debe asociarse con la funci\u00f3n condicional de secure\/HTTPS streaming de Profile T.<\/p>\n\n\n\n\n
\u00bfD\u00f3nde Est\u00e1 la Seguridad en RTP\/RTSP\/HTTPS\/TCP?<\/h2>\n\n\n\n
En el mecanismo referenciado por Profile T, la protecci\u00f3n no procede de transformar RTP en SRTP. Procede del TLS utilizado por HTTPS<\/strong>.<\/p>\n\n\n\n
HTTPS puede entenderse, de forma simplificada, como HTTP operando sobre una sesi\u00f3n TLS. TLS proporciona mecanismos de protecci\u00f3n para los datos que atraviesan ese canal, incluida confidencialidad e integridad en tr\u00e1nsito, adem\u00e1s de mecanismos de autenticaci\u00f3n del endpoint seg\u00fan la configuraci\u00f3n de certificados y confianza utilizada.<\/p>\n\n\n\n
Esto significa que el modelo arquitect\u00f3nico es distinto de proteger cada paquete RTP directamente mediante SRTP.<\/p>\n\n\n\n
TLS No Es un Algoritmo de Cifrado<\/h3>\n\n\n\n
Otro error frecuente es tratar TLS como sin\u00f3nimo de AES. TLS es un protocolo de seguridad<\/strong> que establece una sesi\u00f3n protegida y negocia los mecanismos criptogr\u00e1ficos aplicables. AES puede formar parte de las cipher suites utilizadas, pero no es correcto definir \u00abTLS = AES\u00bb.<\/p>\n\n\n\n
Del mismo modo, no debe concluirse que la simple presencia de la palabra HTTPS demuestra una cipher suite espec\u00edfica sin verificar la versi\u00f3n y configuraci\u00f3n de TLS efectivamente utilizadas por los endpoints.<\/p>\n\n\n\n
Certificados y Confianza<\/h3>\n\n\n\n
La seguridad de una sesi\u00f3n TLS tambi\u00e9n depende de c\u00f3mo el client valida la identidad del endpoint. Los certificados digitales, la cadena de confianza y las pol\u00edticas de validaci\u00f3n forman parte del dise\u00f1o de una implantaci\u00f3n segura.<\/p>\n\n\n\n
Un certificado self-signed puede proporcionar cifrado, pero exige un modelo de confianza coherente para que el client sepa que se est\u00e1 comunicando con el dispositivo previsto. En entornos corporativos, la gesti\u00f3n de certificados debe tratarse como parte de la arquitectura de seguridad, no \u00fanicamente como una opci\u00f3n de la interfaz web de la c\u00e1mara.<\/p>\n\n\n\n\n
Secure Streaming de Profile T No Es Sin\u00f3nimo de SRTP<\/h2>\n\n\n\n
Esta es la distinci\u00f3n m\u00e1s importante del tema.<\/p>\n\n\n\n
En Profile T v1.0, la funci\u00f3n condicional de transporte seguro se describe como:<\/p>\n\n\n\n
Streaming over RTP\/RTSP\/HTTPS\/TCP<\/strong>.<\/p>\n\n\n\n
No se describe como \u00abSRTP\u00bb. El medio RTP permanece dentro de la arquitectura de tunneling RTSP\/HTTP, mientras TLS protege el canal HTTPS.<\/p>\n\n\n\n
En una representaci\u00f3n simplificada:<\/p>\n\n\n\n
Profile T v1.0: TLS protege el canal HTTPS que transporta RTP\/RTSP<\/title>