Dentro de “¿funcionarán juntos?” se esconden dos preguntas. La primera es si el grabador aceptará la cámara siquiera — descubrimiento, un flujo, una imagen en pantalla. La segunda, que decide si el sistema es agradable de tener, es si todo lo que hace la cámara sobrevive al viaje: eventos, control PTZ, el subflujo que usa el mosaico, la programación de grabación. Los estándares abiertos responden a la primera pregunta con fiabilidad y a la segunda solo en parte, y saber cuál es cuál es lo que impide que un sistema mixto se convierta en un problema de mantenimiento.
El caso de mezclar marcas es corriente y no exótico. Un edificio se amplía y el ala nueva recibe cámaras modernas; un grabador llega al final de su vida útil pero las cámaras de las paredes tienen tres años y funcionan; un cliente quiere cambiar de marca sin recablear cinco plantas. En cada caso la pregunta es la misma: cuánto del sistema existente se queda, y qué hay que aceptar como distinto.
¿Qué es ONVIF y qué no es?
ONVIF es un estándar de interoperabilidad: define cómo se describe un dispositivo en la red y cómo otro dispositivo le pide un flujo, mueve una cabeza PTZ o se suscribe a eventos. Un dispositivo que lleva la marca de conformidad ha pasado una prueba para el perfil que declara. Eso es una garantía significativa: significa que dos dispositivos de fabricantes distintos comparten un idioma común y un conjunto común de comandos.
Lo que no garantiza es la paridad de funciones. El estándar define interfaces, no implementaciones: una cámara puede exponer PTZ por ONVIF y un grabador puede aceptarlo, mientras que la analítica de la propia cámara o las funciones del fabricante basadas en su propia aplicación nunca aparecen en el grabador de terceros. La conformidad tiene que ver con la conversación, no con todas las frases que cada parte pueda decir.
¿Qué perfiles ONVIF importan en un sistema de edificio?
| Perfil | Qué cubre | Dónde se encuentra |
|---|---|---|
| Profile S | Streaming: configuración, descubrimiento, video y audio en vivo | La base para que una cámara aparezca en el grabador de otra marca |
| Profile T | Streaming avanzado: H.265, multistream y metadatos | Cámaras modernas que ofrecen un flujo principal y un subflujo a un grabador de terceros |
| Profile G | Control de grabación y almacenamiento en el lado del dispositivo | Donde las grabaciones y su recuperación se gestionan en la cámara o en su propio almacenamiento |
Para un sistema de edificio, la hipótesis de trabajo es sencilla: asuma Profile S, compruebe Profile T si piensa grabar el códec moderno a través de un grabador de terceros, y trate Profile G como una pregunta sobre el almacenamiento en el borde y no sobre el grabador del armario.
¿Por qué RTSP es la puerta que suele estar abierta?
Donde ONVIF es un idioma, RTSP suele ser la ruta directa: una URL que pide un flujo a la cámara, en forma de dirección, puerto y ruta. El puerto es convencionalmente 554; la ruta es específica del firmware de cada fabricante y se publica en la documentación de esa cámara. De ahí se derivan dos consecuencias para un sistema mixto. Primera: RTSP funciona donde la integración más rica no lo hace, lo que lo convierte en el recurso que mantiene vivo un sistema mixto. Segunda: como la ruta es específica del fabricante, se documenta cámara por cámara en lugar de darse por supuesta.
Las cámaras del tipo que fabricamos exponen un flujo principal y un subflujo a través de esa interfaz. El flujo principal es el que merece la pena grabar a 5 MP; el subflujo es el que deberían usar el mosaico en vivo y el cliente móvil, porque un muro de ventanas en miniatura no necesita la resolución completa y no debería pagarla en ancho de banda. Un sistema mixto en el que el subflujo se deja desactivado es un sistema mixto que se siente lento por razones que no tienen nada que ver con las marcas.
¿Qué sobrevive a un sistema mixto y qué no?
| Capacidad | A través de interfaces abiertas | La advertencia honesta |
|---|---|---|
| Vista en vivo y grabación | Sí | El caso habitual, y para el que se escribió el estándar |
| Control PTZ | Sí, donde la cámara lo expone | Los presets y los recorridos pueden comportarse de forma distinta entre clientes |
| Eventos de movimiento | Movimiento básico, normalmente | El cruce de línea, la intrusión y analíticas similares suelen quedarse dentro del cliente del propio fabricante |
| Audio bidireccional | A veces | Depende de que ambos extremos admitan la misma ruta de audio |
| Aplicación móvil y cliente | No | La aplicación de cada fabricante ve su propio hardware; un sistema mixto suele significar dos aplicaciones, o un grabador que publique una |
| Firmware y actualizaciones | No | Siempre separados, siempre por marca |
¿Cuáles son las tres formas de gestionar un sistema mixto?
- Conservar las cámaras y cambiar el grabador. La migración más habitual y la más barata de planificar: los grabadores de nuestra gama hablan ONVIF, RTSP, GB28181 y P2P, así que las cámaras existentes que expongan cualquiera de esas interfaces se pueden registrar y grabar. Sustituya el grabador, conserve el plan de cámaras y el cableado no cambia.
- Conservar el grabador y cambiar las cámaras. Registre las cámaras nuevas en el grabador existente por ONVIF o RTSP, canal a canal. Las cámaras antiguas siguen en servicio hasta que cada posición esté lista, lo que significa que el edificio no queda ciego en ningún momento durante el cambio.
- Mantener ambos durante la transición. El grabador antiguo y el nuevo en la misma red durante un periodo, para no perder nada mientras se verifica el cambio. Requiere direcciones libres y alguien que entienda qué sistema graba qué — merece la pena donde una reclamación pudiera presentarse en la ventana de cambio.
¿Dónde fallan los sistemas mixtos en la práctica?
Los fallos rara vez tienen que ver con las marcas y casi siempre con la configuración. Un subflujo que se deja desactivado, así que el grabador tira del flujo principal para cada canal y el techo de ancho de banda llega pronto — en nuestros grabadores mayores el ancho de banda de entrada es de 64 Mbps, cómodo para un edificio y algo con lo que uno se topa en torno al canal número treinta si todo se graba a plena tasa. Desajustes de códec, cuando un extremo ofrece H.265 y el otro espera H.264. Direcciones duplicadas, cuando dos servidores DHCP comparten una red durante una migración y una cámara responde a una dirección que alguien más reclamó. Deriva del reloj, que vuelve la línea de tiempo poco fiable en silencio hasta que alguien activa NTP en todas partes. Credenciales y límites de sesión, cuando un grabador pide a una cámara más flujos simultáneos de los que su firmware permite.
¿Qué incluye una lista de comprobación para la migración?
- Enumere qué se queda y qué cambia, y anote cuál de los cinco eslabones — cámara, switch, cable, grabador, cliente — toca el cambio.
- Confirme las interfaces en ambos extremos: perfil ONVIF, disponibilidad de RTSP y el códec que graba cada parte.
- Compruebe el ancho de banda de entrada del grabador contra el número de canales y la resolución que se va a grabar, no solo contra el número de cámaras.
- Configure NTP en todos los dispositivos antes de la puesta en marcha, para que la línea de tiempo sea fiable desde el primer día.
- Migre primero un canal y obsérvelo durante una noche entera antes de comprometer el resto.
- Mantenga el acceso al sistema antiguo disponible hasta que se firme la prueba de recepción.
La compatibilidad no es una propiedad de sí o no de una marca; es una lista de interfaces y ajustes que encajan o no. Recórrala canal a canal y un sistema mixto resulta anodino — que es justamente la idea.
