Estándar ONVIF: informe para proyectistas e integradores

Informe técnico sobre el estándar ONVIF para proyectistas e integradores

Resumen ejecutivo

ONVIF es un foro industrial abierto que define interfaces estandarizadas para lograr interoperabilidad efectiva entre productos y servicios de seguridad física basados en IP. Su propuesta técnica se materializa en un conjunto de Network Interface Specifications (especificaciones de servicios, WSDL/XSD y requisitos de comunicación) y en una capa de empaquetado llamada perfiles (Profile S/T/G/M para video; A/C/D para control de acceso), diseñada para que integradores y proyectistas puedan predecir compatibilidad entre “dispositivos” y “clientes” (p. ej., cámaras ↔ VMS) sin depender de integraciones propietarias.

Sin embargo, la interoperabilidad real en campo depende de tres factores críticos:

1. Conformidad ONVIF registrada (producto listado en la base oficial, tras pasar test tools).
2. Perfil(es) y funciones efectivamente implementadas (muchas funciones son condicionales u opcionales).
3. Calidad de implementación/firmware (cambios de firmware pueden afectar conformance; además, distintos VMS limitan o “suavizan” requisitos por compatibilidad).

En 2022 ONVIF deprecó Profile Q por requerir acceso anónimo durante el estado de fábrica (no alineado con buenas prácticas modernas). Además, Profile S está en proceso de deprecación; ONVIF anuncia como última fecha para nuevas presentaciones de conformidad 31 de marzo de 2027, recomendando migrar a Profile T para nuevas implementaciones. Esto impacta directamente el diseño: para proyectos nuevos, Profile T (y/o M/G según casos) + TLS debería ser la línea base; Profile S se mantiene como necesidad de “legado” y compatibilidad.

A nivel de integración, ONVIF se apoya en servicios SOAP (WSDL), descubrimiento WS-Discovery, RTSP/RTP para streaming, y un esquema de eventos basado en WS-BaseNotification con patrones PullPoint/Subscribe, más extensiones recientes (MQTT/JSON, WebRTC, JWT/OAuth) incorporadas en releases modernos del set de especificaciones.

Descripción general de ONVIF

Historia, objetivos y estructura organizativa

ONVIF fue fundado en 2008 por Axis Communications,Bosch y Sony, con el lanzamiento de la Core Specification 1.0 ese mismo año. Su misión declarada es “provide and promote standardized interfaces for effective interoperability of IP-based physical security products and services” (proveer y promover interfaces estandarizadas para la interoperabilidad efectiva de productos y servicios de seguridad física basados en IP) y su visión es que “all security systems share one interface” (todos los sistemas de seguridad comparten una interfaz).

A nivel de gobernanza, ONVIF opera con comités (p. ej., Technical Committee, Steering Committee) y mantiene una línea formal de trabajo: creación/mantenimiento de especificaciones, empaquetado en perfiles y add-ons, y desarrollo de test tools para validar conformidad.

Perfiles y add-ons como “contratos” de interoperabilidad

ONVIF define que un perfil es un conjunto fijo de características requerido para que un cliente y un dispositivo interoperan de forma predecible cuando ambos declaran conformidad con ese perfil.

La política de perfiles establece puntos esenciales para ingeniería de integración:

• Un perfil, una vez publicado, no cambia (no se le agregan nuevas funciones), para preservar compatibilidad hacia atrás (backward compatibility).
• Si el mercado requiere nuevas capacidades, se crea un nuevo perfil o un add-on.
• Existen niveles de requisito (mandatory/conditional/optional) que explican por qué dos productos “ambos ONVIF” pueden no comportarse igual en funciones avanzadas.

Arquitectura técnica de ONVIF

Modelo de roles: “Device” vs “Client” y mapeo a componentes reales

ONVIF describe perfiles en términos de devices (por ejemplo cámaras/encoders) y clients (por ejemplo VMS). En Profile S, el “device” envía video a un “client”; el “client” configura/solicita/controla streaming. En Profile G el “device” soporta grabación (en red o local) y el “client” controla/configura grabación y puede recibir audio/metadata si soporta esas características. En Profile M se amplía el modelo: un producto conformant puede ser un edge device o un servicio (server/cloud) con analítica que envía metadata; el “client” puede ser VMS/NVR/servicio cloud que consume metadata.

En práctica de proyecto, esto se traduce en tres capas:

• Plano de control (control plane): SOAP/HTTP(S), configuración, descubrimiento, eventos.
• Plano de medios (media plane): flujos RTSP/RTP (y pistas de metadata asociadas); multicast/unicast; transporte UDP/TCP/HTTP.
• Plano de seguridad: autenticación/autorización, TLS, políticas y configuración criptográfica (y add-ons).

Servicios ONVIF, SOAP, WSDL y el “entry point” del dispositivo

La Core Specification fija que el entry point del servicio de gestión del dispositivo está en:
/onvif/device_service

También establece requisitos base: un dispositivo ONVIF debe proveer, como mínimo, Device Management y Event Service. El dispositivo expone capacidades/servicios mediante operaciones del device service (p. ej., consulta de capacidades, red, sistema, seguridad), y mediante GetServices/GetCapabilities entrega URLs (XAddrs) para el resto de servicios.

ONVIF se basa en interfaces Web Services descritas en WSDL (con esquemas XSD), y recomienda prácticas WS-I para interoperabilidad.

Descubrimiento: WS-Discovery y consideraciones de red/NAT

ONVIF utiliza WS-Discovery como mecanismo típico de descubrimiento, donde el dispositivo anuncia y/o responde con XAddrs (direcciones del device service). En el comportamiento ONVIF, el dispositivo debe incluir el elemento <d:XAddrs> con direcciones para protocolos (http/https) y direcciones IP externas disponibles; además se sugiere publicar un entry en puerto 80 para facilitar atravesar firewalls.

A nivel de transporte, WS-Discovery define por defecto multicast con:

• Puerto 3702,
• Multicast IPv4 239.255.255.250,
• Multicast IPv6 FF02::C.

El estándar WS-Discovery también define multicast suppression vía discovery proxy y temporizadores aleatorios (APP_MAX_DELAY) para mitigar tormentas de respuestas en redes grandes, un punto relevante para escalabilidad de descubrimiento en VLANs de CCTV extensas.

Streaming: RTSP/RTP, configuración Media y codecs

La Media Service Specification define el concepto de media profile como el mapeo de fuentes (video/audio) a encoders, PTZ, analítica y metadata. Esto es central para integración: no se pide “un RTSP fijo”; se pide el stream URI asociado a un perfil.

La operación GetStreamUri solicita un URI para iniciar un stream en vivo usando RTSP como protocolo de control; el estándar indica que el URI devuelto debería permanecer válido indefinidamente (con parámetros InvalidAfterConnect/InvalidAfterReboot en false y timeout PT0S) salvo capacidades como NoRTSPStreaming.

En GetStreamUri se reconocen combinaciones típicas de transporte (resumen): RTP unicast sobre UDP, RTP sobre RTSP sobre TCP, y RTP sobre RTSP sobre HTTP/TCP. Para escenarios NAT, se explicita que si se solicita transporte HTTP, el dispositivo debe devolver una URL usando el mismo puerto que el servicio web, para facilitar traversal.

El estándar también define multicast mediante StartMulticastStreaming/StopMulticastStreaming y documenta requisitos de decodificabilidad (por ejemplo, en H.264, enviar SPS/PPS “inband”).

Respecto a codecs de interoperabilidad, la especificación de Media manda perfiles mínimos:

• soporte de JPEG QVGA,
• y G.711 μ-law si el dispositivo soporta audio.
  Y, a nivel de perfiles, Profile T enfatiza H.264/H.265, settings de imagen, eventos (motion/tampering), metadata y audio bidireccional; además incluye HTTPS streaming como parte del alcance para conformant products que soporten esa característica.

Eventos y metadatos: PullPoint, WS-BaseNotification, RTP/MQTT

La Core Specification define el manejo de eventos y provee, entre otros, el patrón Real-time Pull-Point Notification Interface con CreatePullPointSubscription y PullMessages, incluyendo diagramas de secuencia y reglas operativas (keep-alive y timeouts). Por ejemplo, se especifica que el dispositivo debe soportar Timeout de PullMessages de al menos un minuto, y comportamiento de bloqueo/respuesta cuando no hay mensajes.

ONVIF utiliza el framework WS-BaseNotification para estructura de notificaciones y faults, y contempla también eventos transmitidos en paquetes RTP como parte de metadata streaming.

En analítica moderna, Profile M extiende el ecosistema: define configuración/streaming de metadata, clasificación genérica de objetos y metadata especializada (geolocalización, vehículo, patente, rostro/cuerpo), y contempla eventos enviados por metadata stream, por el Event Service ONVIF o sobre MQTT (con payload JSON en releases recientes del set de especificaciones).

Seguridad: TLS, autenticación, roles, baseline criptográfica y lecciones de Profile Q/S

En autenticación, el ecosistema de perfiles indica que Digest Authentication es obligatoria en múltiples perfiles (según la tabla comparativa), y que también aparece WS-UsernameToken como mecanismo en algunos contextos históricos. La Core Specification ejemplifica el flujo digest (HTTP/RTSP 401 con challenges) y señala explícitamente que no existe un API ONVIF para obtener el algoritmo hash actual, por lo que los clientes deben basarse en el challenge digest de HTTP/RTSP.

En releases del set de especificaciones, ONVIF ha añadido capacidades de seguridad modernas: soporte de Sha256 digest authentication y secure RTSP streaming (22.12), ECC + JSON Web Tokens y configuración de Authorization Server con OAuth2/OpenID Connect (23.12), y transporte Uplink sobre WebSocket con JWT (24.06).

En 2024/2025 ONVIF refuerza el enfoque modular con add-ons: el TLS Configuration Add-on Specification v1.0 define el set de características para configuración de TLS entre cliente y dispositivo. Paralelamente, ONVIF publicó una Security Baseline Specification (25.12) basada en tecnología “state of the art” (referenciando NIST/BSI) e incluyendo aspectos como certificados, JWT y referencias de cifrados TLS (anexos).

Dos decisiones de “política” son especialmente relevantes para proyectistas:

• Profile Q fue deprecado el 1 de abril de 2022 porque requería acceso anónimo a todos los comandos ONVIF durante el setup en estado de fábrica, lo cual no coincide con prácticas actuales (primero setear credenciales).
• Profile S está en proceso de deprecación (última fecha para nuevas presentaciones: 31-mar-2027), y ONVIF recomienda adoptar métodos más seguros como TLS/HTTPS o Profile T.

Perfiles, versiones y compatibilidad

Perfiles vigentes y su intención de diseño

ONVIF clasifica perfiles por dominios: video (S/T/G/M) y control de acceso (A/C/D; además M puede coexistir en soluciones integradas). En síntesis funcional:

• Profile S: “basic video streaming” y configuración/controles básicos (también PTZ/audio/multicast/relays si soportados).
• Profile T: streaming avanzado (H.264/H.265), imaging, eventos motion/tamper, metadata, OSD, audio bidireccional; y cubre HTTPS streaming en conformant products que lo soporten.
• Profile G: edge storage/recording control y recuperación; soporte de audio/metadata si el client lo soporta.
• Profile M: metadata + eventos para analítica (incluye MQTT como canal posible).
• Profile C: control de puertas y gestión de eventos/alarmas en sistemas de control de acceso IP.
• Profile A: configuración de control de acceso (credenciales, schedules, reglas) y eventos estandarizados relacionados.
• Profile D: periféricos de control de acceso (lectores, biométricos, cerraduras, sensores, displays) y el flujo “captura credencial → decisión en cliente seguro → comando al periférico”.
• Profile Q: deprecado (onboarding rápido), con advertencias de seguridad por estado de fábrica.

Versionado: “Specification Set” vs “Profile” y el porqué de la retrocompatibilidad

Una fuente común de confusión en proyectos es mezclar:

• Versiones del set de especificaciones (se liberan históricamente en cadencia semestral/año-mes: 25.12, 25.06, 24.12, etc.).
• Perfiles, que por política no cambian una vez publicados (solo aclaraciones interpretativas), y mantienen interoperabilidad entre productos conformant del mismo perfil en el tiempo.

La Profile Policy dice explícitamente: “Once defined and publicly released, the Profile shall never change…” y que “New functions or features cannot be added to existing Profiles”, garantizando que productos conformant al mismo perfil interoperan independientemente de la fecha de su declaración.

Esto tiene un corolario práctico: las mejoras (p. ej., nuevos métodos de autenticación, WebRTC, MQTT/JSON) tienden a entrar por nuevas especificaciones del set y/o via nuevos perfiles o add-ons, no “actualizando Profile S/T” en el sentido de sumar funciones obligatorias.

Avances relevantes por versión del set (enfoque integrador)

A continuación se listan cambios “de arquitectura” que afectan decisiones de diseño y seguridad (no exhaustivo, pero sí de alto impacto):

Los hitos anteriores están documentados en “Specification History”.

Implicancias de compatibilidad en proyectos

ONVIF enfatiza que la compatibilidad “garantizada” se obtiene con productos registrados conformant a perfiles; además, solo los productos registrados son considerados formalmente “ONVIF conformant”. En ejecución real, el riesgo aparece cuando se trabaja con:

• productos que solo declaran “supports ONVIF” (sin registro),
• perfiles antiguos (Q deprecado; S en deprecación),
• funciones condicionales (por ejemplo, eventos/metadata/IO/HTTPS) que pueden existir o no en el modelo/firmware.

Fortalezas y debilidades del estándar desde la perspectiva de integración

Fortalezas

La principal fortaleza es reducir lock-in: ONVIF está diseñado para construir sistemas con componentes de múltiples fabricantes, soportando interoperabilidad por perfiles (y, crecientemente, por add-ons para necesidades específicas).

La estructura de conformance (test specs + test tools + declaración y registro) mejora la confiabilidad del claim: ONVIF define un “Conformance Process” y provee herramientas para dispositivos y clientes. Además, la base pública de “Conformant Products” es la fuente autoritativa para validar si un producto es oficialmente conformant y qué perfiles declara.

Debilidades y fricciones típicas

Interoperabilidad parcial por diseño de requisitos: la existencia de funciones condicionales/optativas implica que “mismo perfil” no significa “misma experiencia” si el VMS depende de features que el dispositivo no implementa (p. ej., eventos avanzados, metadata, PTZ específico).

Brecha entre conformidad y soporte operativo del VMS: un VMS puede ser conformant a un perfil y aun así limitar soporte a dispositivos probados internamente. Un ejemplo documentado: el driver ONVIF de Milestone indica que un dispositivo plenamente compliant probablemente funcione, pero no necesariamente estará soportado por soporte técnico si no fue probado específicamente.

Implementación variable y “ambigüedades” operativas: algunos puntos quedan a criterio del fabricante (p. ej., cuántos pull points simultáneos, subset de eventos, comportamiento ante características no soportadas). La Core Specification remarca, por ejemplo, la importancia de soportar múltiples pull points para permitir suscripciones con scopes precisos; si solo hay una suscripción, el cliente debería suscribirse sin restricción, forzando más carga de eventos.

Seguridad: perfiles con herencia histórica. Profile Q fue deprecado por requerir acceso anónimo en estado de fábrica; Profile S está en proceso de deprecación y se recomienda adoptar TLS/HTTPS o Profile T.

Rendimiento, latencia y operación en red

No existe una “garantía ONVIF” de latencia; pero el stack usado tiene factores conocidos:

• WS-Discovery usa multicast y temporizadores (APP_MAX_DELAY 500 ms por defecto), lo que influye en tiempos de enumeración en redes grandes.
• Los eventos PullPoint dependen del timeout/bloqueo de PullMessages y del volumen de eventos generados por el dispositivo.
• El plano de medios se apoya en RTSP/RTP con opciones TCP/UDP/HTTP, y multicast requiere configuración adecuada en el dispositivo (multicast settings válidos) y soporte en la red.

Mejores prácticas de integración y checklist de planificación

Principios de diseño para proyectos sin restricción de escala

Para cubrir desde pequeña a gran escala, una estrategia robusta es diseñar alrededor de “contratos mínimos” y “capacidades incrementales”:

1. Contrato mínimo recomendado (nuevo diseño): Profile T como baseline para video moderno (H.264/H.265, eventos, metadata, HTTPS streaming donde aplique) y, si hay analítica basada en metadata, sumar Profile M.
2. Legado/compatibilidad: aceptar Profile S para cámaras existentes, pero planificar migración y evitar nuevas dependencias sobre Profile Q (deprecado) o flows inseguros en estado de fábrica.
3. Grabación distribuida: si hay SD/NAS/edge recording, incluir Profile G para control y recuperación estandarizados.

Descubrimiento, direccionamiento y NAT

• Alinear el onboarding con el flujo ONVIF: descubrimiento WS-Discovery → obtener XAddrs del device service → consultar servicios/capacidades.
• Para entornos con firewall/NAT: considerar que ONVIF recomienda exponer el device service también por puerto 80 para traversal, y que GetStreamUri sobre HTTP debe usar el mismo puerto que el web service para facilitar NAT.

Sincronización de tiempo y consistencia de timeline

En integración VMS, la sincronización de tiempo no es un “detalle”: afecta correlación de eventos, timeline y evidencia. La documentación de terceros (por ejemplo, Axis para soporte de third-party devices) recomienda explícitamente sincronizar hora entre servidor y dispositivo antes de agregarlo al VMS.
Además, el ecosistema de perfiles incluye NTP como capacidad relevante (según matriz de funciones).

Conformance testing y gobierno de firmware

• ONVIF publica test specifications y define el proceso de conformance; provee Device Test Tool / Client Test Tool para aumentar confianza en los claims.
• ONVIF indica que lanza nuevas versiones de device test tools dos veces al año (junio y diciembre), y que una versión es válida hasta la siguiente más una “grace period” aproximada de tres meses.
• Los test tools están disponibles para miembros vía Member Portal (no siempre accesibles públicamente), por lo que integradores suelen apoyarse en: verificación contra la base “Conformant Products” + pruebas de laboratorio propias con VMS objetivo.
• Impacto de firmware: documentación de Axis advierte que cambiar firmware/software puede romper la conformance a Profile S.

Checklist de planificación de proyecto

La lista siguiente está enfocada a reducir riesgos “típicos ONVIF” en especificación, puesta en marcha y aceptación:

• Requisitos funcionales: definir qué se necesita además de “video”: PTZ, audio bidireccional, relays/IO, motion/tamper events, metadata analytics, edge recording, HTTPS. Mapear cada requisito a perfiles (T/M/G) y a funciones condicionales.
• Requisitos de seguridad: exigir digest robusto y TLS donde aplique; evitar flujos de “estado de fábrica” que impliquen acceso anónimo (lección Profile Q). Considerar TLS Configuration Add-on si se requiere gestión estandarizada de certificados/TLS.
• Descubrimiento y direccionamiento: plan de VLAN/subredes; validar WS-Discovery (3702/239.255.255.250) en el dominio de broadcast/multicast; o definir procedimiento manual si multicast está bloqueado.
• Streaming: definir transporte preferido (UDP/TCP/HTTP), y si habrá multicast; validar GetStreamUri y su estabilidad; probar “fallback” RTSP directo si el VMS lo permite.
• Eventos: probar PullPointSubscription/PullMessages con timeouts reales; verificar volumen de eventos; definir fallback (por ejemplo, motion detection del lado VMS si eventos del dispositivo son inconsistentes).
• Aceptación: incluir pruebas por perfil/función (matriz), y pruebas de regresión al actualizar firmware/cambios de red.

Ecosistema VMS y ejemplos prácticos de integración

Tabla comparativa de VMS con soporte ONVIF

Notas de lectura:

• “Conformant” implica declaración registrada/claim formal; “soporta ONVIF” puede ser integración práctica sin claim público.
• “Perfiles” aquí reflejan lo que documentan fuentes oficiales de cada fabricante (o, cuando no hay detalle de perfiles, el requisito explícito que publican).

Ejemplos prácticos: flujos típicos de integración

Flujo de descubrimiento y provisión

• WS-Discovery define multicast por defecto a 239.255.255.250:3702 (IPv4).
• ONVIF requiere que el dispositivo incluya XAddrs del device service (y recomienda exponer también por puerto 80 para traversal).
• El entry point del device service está fijo a /onvif/device_service.

Descubrimiento WS-Discovery: ejemplo de “Probe” (plantilla)

El payload exacto (namespaces/ws-addressing) varía, pero la idea es: enviar un Probe y parsear ProbeMatches para obtener XAddrs. WS-Discovery soporta SOAP 1.1 y 1.2.

<!-- Plantilla conceptual (resumida) -->
<Envelope xmlns="http://www.w3.org/2003/05/soap-envelope"
          xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
          xmlns:wsd="http://schemas.xmlsoap.org/ws/2005/04/discovery">
  <Header>
    <wsa:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</wsa:Action>
    <wsa:MessageID>uuid:...</wsa:MessageID>
    <wsa:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</wsa:To>
  </Header>
  <Body>
    <wsd:Probe>
      <!-- Opcional: Types/Scopes -->
    </wsd:Probe>
  </Body>
</Envelope>

Flujo ONVIF “mínimo viable” para levantar video + eventos

• GetStreamUri devuelve URI RTSP para iniciar stream; el estándar define que debería ser estable indefinidamente (timeout PT0S) y lista combinaciones de transporte (UDP/TCP/HTTP).
• Para eventos PullPoint, ONVIF define CreatePullPointSubscription/PullMessages y requiere Timeout de al menos un minuto en PullMessages.

Ejemplo de request SOAP: GetStreamUri (Media1)

El contenido y namespaces deben alinearse con el WSDL del dispositivo; normalmente se autentica por HTTP Digest/HTTPS según configuración del dispositivo/VMS.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
            xmlns:trt="http://www.onvif.org/ver10/media/wsdl"
            xmlns:tt="http://www.onvif.org/ver10/schema">
  <s:Body>
    <trt:GetStreamUri>
      <trt:StreamSetup>
        <tt:Stream>RTP-Unicast</tt:Stream>
        <tt:Transport>
          <tt:Protocol>RTSP</tt:Protocol>
        </tt:Transport>
      </trt:StreamSetup>
      <trt:ProfileToken>PROFILE_TOKEN_AQUI</trt:ProfileToken>
    </trt:GetStreamUri>
  </s:Body>
</s:Envelope>

Ejemplos de URLs RTSP (orientativos, no normativos)

ONVIF no estandariza una única forma de RTSP path; la URI real la entrega GetStreamUri. Aun así, para troubleshooting de campo (cuando el VMS permite fallback RTSP), se ven patrones frecuentes:

# Genérico:
rtsp://usuario:password@IP:554/...

# Ejemplos comunes por familias (solo referencia práctica; puede variar por firmware/modelo):
rtsp://IP:554/Streaming/Channels/101
rtsp://IP:554/live/ch00_00
rtsp://IP:554/onvif1

Recomendaciones de arquitectura escalable y segura

Escala pequeña (1–50 cámaras): VMS monolítico, cámara VLAN dedicada, Profile T como baseline; si no hay eventos confiables, asumir motion en VMS.

Escala media (50–500 cámaras): separar roles (servidores de grabación vs management), priorizar transportes y políticas coherentes (HTTPS cuando aplique; digest fuerte), estandarizar media profiles “ready-to-use” y validar que GetStreamUri/NAT traversal funcione según especificación (HTTP sobre puerto del web service).

Escala grande/multi-sitio (500+ cámaras): gobernar por perfiles y test matrix; considerar edge recording (Profile G) para resiliencia; definir estrategia de eventos/metadata (Profile M) y, en ecosistemas IoT, MQTT/JSON según capacidades reales.

En seguridad, el enfoque debe alinearse con la dirección del estándar: TLS add-on para configuración de TLS, y baseline criptográfica publicada por ONVIF como referencia de “state-of-the-art”, evitando prácticas heredadas (Profile Q) y planificando migración desde Profile S a T para nuevas instalaciones.

Fuentes

• ONVIF — Home / definición general del foro y su propósito.
• ONVIF Overview (June 2025) — misión/visión, timeline histórico, estructura de comités, profiles y add-ons.
• ONVIF Core Specification (Ver. 25.12) — entry point /onvif/device_service, requisitos de servicios base, discovery y event handling.
• WS-Discovery (April 2005) — multicast por defecto (239.255.255.250:3702) y modelos de descubrimiento.
• ONVIF Media Service Specification (Ver. 24.12) — media profiles, codecs mínimos, GetStreamUri, multicast y consideraciones NAT/puertos.
• Páginas oficiales de perfiles ONVIF (S/T/G/M/C/A/D/Q) — alcance y deprecaciones.
• ONVIF Profile Feature Overview v2.6 (April 2022) — matriz de features por perfil y requisitos (mandatory/conditional/optional).
• ONVIF Profile Policy v3.4 (Mar 2024) — inmutabilidad de perfiles y backward compatibility.
• ONVIF Specification History — cambios por versión (MQTT/JSON, secure RTSP, Sha256 digest, JWT/OAuth2, WebRTC, Security Baseline, roles).
• ONVIF TLS Configuration Add-on Specification v1.0 — add-on para configuración de TLS.
• ONVIF Security Baseline Specification (Ver. 25.12) — baseline criptográfica basada en NIST/BSI.
• ONVIF Conformance Process + Device Test Specifications — proceso de conformidad y cadencia de test tools.
• Milestone ONVIF Driver Documentation — conformance S/T/G/M, soporte de perfiles y limitaciones prácticas.
• Avigilon Unity Video software comparison chart (Feb 2024) — perfiles ONVIF soportados por ACC6/ACC7/Unity Video 8.
• Exacq (release pages + manual) — Profile S/M compliance (24.09), Profile T conformant (26.0), y mejoras ONVIF HTTPS.
• Dahua Integration With DSS — claim de perfiles G/S/T/M certificated.
• Bosch BVMS datasheet + knowledge base — BVMS Profile S certified; Profile T vía VSG desde BVMS 10.0.
• Axis technical papers — third-party device support y condición de conformidad Profile S según producto/versión.
• ZoneMinder docs — configuración ONVIF por monitor.
• Agent DVR docs — soporte ONVIF en tipos de fuente y guía general.