Pérdida de paquetes en CCTV: 5 errores de red habituales

Esta suposición tiene consecuencias directas sobre el coste de explotación de cualquier instalación, porque dispara las solicitudes de garantía, multiplica las visitas técnicas y, sobre todo, puede dejar sin evidencia útil los momentos más críticos: un acceso no autorizado a la zona de carga, un siniestro en horario nocturno o la manipulación de un proceso industrial.

La pérdida de paquetes en cámaras IP suele estar relacionada con la red que transporta el vídeo, pero no conviene convertir esa observación en una regla absoluta. También pueden intervenir el sensor, la óptica, el firmware, el codificador, la alimentación o incluso un problema localizado en el propio equipo. La diferencia está en diagnosticar antes de sustituir. Cuando un flujo de vídeo se degrada, hay que determinar si los paquetes se pierden en el trayecto, si llegan correctamente al grabador pero no se procesan a tiempo o si la cámara ya está generando una señal defectuosa.

En instalaciones para administradores de fincas, responsables de mantenimiento y equipos de facility management, la pauta se repite: switches mal dimensionados, cableado deteriorado, configuraciones incompatibles, NVR sobrecargados y decisiones de protocolo tomadas por defecto explican una parte importante de los fallos de red CCTV. No son las únicas causas, pero sí algunas de las más fáciles de pasar por alto porque el sistema continúa funcionando de manera aparentemente normal.

La pérdida de paquetes en cámaras IP no apunta automáticamente al sensor: obliga a comprobar todo el camino entre la cámara, la red y el grabador.

A partir de aquí conviene revisar cinco puntos críticos. Cada uno puede degradar por sí solo la calidad de la imagen; combinados, generan ese efecto de «todo va mal sin que sepamos por qué» que tanto cuesta diagnosticar. La ventaja es que muchos de estos problemas se pueden localizar con las estadísticas de los equipos, una certificación de cableado y una captura de tráfico bien planteada, sin empezar por cambiar cámaras que quizá estén funcionando correctamente.

1. Saturación de red: cuando los búferes no aguantan el ritmo

La congestión es una de las primeras hipótesis que conviene comprobar cuando aparecen problemas de transmisión de vídeo IP. Una cámara no envía únicamente una sucesión uniforme de imágenes. El caudal depende de la resolución, la frecuencia de imagen, el códec, el nivel de compresión, la escena y el perfil de grabación. Una zona vacía y estable puede consumir mucho menos que un acceso con personas, vehículos, sombras, reflejos o movimientos constantes.

Los switches reciben esos flujos y los mantienen temporalmente en sus búferes antes de reenviarlos por el puerto correspondiente. Si llegan más datos de los que el enlace de salida puede transportar, el búfer termina llenándose. En ese momento el equipo puede descartar tramas. El resultado visible suele ser una combinación de imagen pixelada, congelaciones puntuales, saltos en la reproducción o pérdida de fotogramas. El cliente lo percibe como un fallo de la cámara porque el síntoma aparece en pantalla, aunque el origen esté en un punto intermedio de la red.

El problema no siempre está en el ancho de banda total del switch. Puede concentrarse en un único enlace: el uplink que conecta un switch de planta con el armario principal, el puerto que lleva varios flujos hacia el NVR o el enlace compartido con otros servicios. Una red puede tener capacidad suficiente en sus puertos de acceso y, sin embargo, sufrir un cuello de botella en el tramo que agrupa todo el tráfico.

También hay que observar qué más circula por esa infraestructura. Voz sobre IP, control de accesos, automatización, climatización, sistemas de gestión energética y otros dispositivos IoT pueden competir con el vídeo. No es necesario que la red esté completamente saturada para que una cámara empiece a mostrar microcortes en momentos concretos. Una ráfaga breve, una copia de seguridad o la conexión simultánea de varios usuarios puede bastar para poner de manifiesto una configuración que hasta entonces parecía estable.

La segmentación mediante VLAN puede ayudar a ordenar el tráfico y a limitar la propagación de ciertos problemas, pero no crea ancho de banda por sí sola. Separar las cámaras en una VLAN mejora el control y facilita la aplicación de políticas, aunque el enlace físico seguirá necesitando capacidad para transportar los flujos. Del mismo modo, activar QoS no corrige un diseño insuficiente: permite decidir qué tráfico debe tratarse con prioridad cuando existe competencia, pero no sustituye a un cálculo razonable del caudal.

Antes de tocar la configuración, conviene revisar:

• La utilización de los puertos de acceso y de los enlaces ascendentes.
• Los contadores de descartes, errores y paquetes rechazados en los switches.
• La suma de los flujos principales y secundarios de las cámaras.
• Las variaciones de tráfico durante escenas con movimiento.
• Las conexiones de visualización remota y las exportaciones de vídeo.
• La presencia de otros servicios en los mismos enlaces.
• La capacidad real de los puertos, especialmente en equipos antiguos o mezclados.

La tasa configurada en la cámara tampoco debe confundirse con el consumo real. En CBR, el caudal se mantiene más controlado, aunque puede resultar menos eficiente en escenas sencillas. En VBR, la cámara adapta la tasa a la complejidad de la imagen y puede generar picos. Para una instalación pequeña y poco cambiante, ese comportamiento quizá no sea problemático. En una red compartida o con enlaces ajustados, sí puede ser determinante.

La solución puede pasar por ampliar un enlace, reorganizar la topología, separar servicios, revisar la compresión o limitar los flujos secundarios. En otros casos será suficiente con corregir una ruta concreta. Lo importante es identificar dónde se produce el descarte, no aplicar QoS o comprar un switch más rápido como respuesta automática.

2. Capa física: el cobre que dice una cosa y hace otra

Cuando la congestión no explica el problema, la siguiente parada es la capa física. Es la parte que más pereza da revisar y, precisamente por eso, una de las que más diagnósticos equivocados provoca. Un conector mal terminado o un cable sometido a tensión puede mantener el enlace activo y, al mismo tiempo, generar errores intermitentes que aparecen solo bajo carga.

Los defectos más habituales son:

• Cables Ethernet dañados por aplastamiento, humedad, exposición a la intemperie o dobleces pronunciados.
• Latiguillos de baja calidad o con una categoría inadecuada para las condiciones de la instalación.
• Conectores RJ45 mal crimpados, con conductores fuera de orden o contactos que no presionan correctamente.
• Rosetas, cajas de conexión o paneles de parcheo con terminales flojos.
• Tiradas de cobre demasiado largas o instaladas cerca de fuentes de interferencias.
• Enlaces PoE con una caída de tensión que afecta a la estabilidad de la cámara.
• Conexiones exteriores sin la protección adecuada frente al agua y la condensación.

Un enlace puede negociar velocidad y aparecer como «activo» en el switch aunque esté acumulando errores. Por eso el indicador luminoso del puerto no es una prueba suficiente. Hay que consultar los contadores de errores CRC, paquetes descartados, errores de alineación y renegociaciones. Si esos valores aumentan en un puerto concreto, el cableado y sus terminaciones merecen atención antes de culpar al NVR.

La alimentación mediante PoE añade otra capa de diagnóstico. Una cámara puede reiniciarse, perder conectividad o comportarse de forma irregular si el presupuesto de potencia del switch está demasiado ajustado, si el inyector no es adecuado o si el cableado introduce pérdidas. En ese caso el síntoma puede parecer una pérdida de paquetes, pero el origen no es necesariamente la transmisión de datos: puede tratarse de un reinicio del equipo o de una interrupción breve de la alimentación.

La distancia también importa. El cobre Ethernet tiene una longitud de canal recomendada y no conviene prolongarlo de forma improvisada con empalmes, adaptadores o tramos que no han sido certificados. Cuando una tirada se aproxima al límite práctico de la tecnología, la fibra suele ser una alternativa más limpia para salvar distancia, aislar edificios o evitar problemas de interferencias. Eso no significa que cualquier conversor de medios vaya a resolver la instalación por sí solo: hay que comprobar compatibilidad de velocidad, alimentación, transceptores y gestión del enlace.

Para una revisión seria, el informe de mantenimiento debería incluir una certificación del cableado con un comprobador adecuado. No basta con un dispositivo que indique continuidad. Una prueba de certificación puede revelar problemas de longitud, diafonía, pérdidas, pares invertidos o terminaciones deficientes que una comprobación básica no detecta.

Un enlace que permanece encendido no es necesariamente un enlace sano. La estabilidad se comprueba en los contadores, en la certificación y en el comportamiento bajo carga.

La sustitución de un latiguillo puede resolver una incidencia concreta, pero no debe convertirse en una estrategia de ensayo y error. Si el problema se repite, hay que comprobar el tramo completo: panel, roseta, latiguillo, puerto del switch, cámara y alimentación. En instalaciones exteriores, además, conviene inspeccionar las cajas de conexión después de episodios de lluvia o de cambios importantes de temperatura. La humedad intermitente produce algunos de los fallos más difíciles de reproducir en una visita técnica.

3. Desajuste de dúplex: la colisión invisible

El desajuste de velocidad o de dúplex es menos frecuente en redes modernas que en infraestructuras antiguas, pero cuando aparece puede resultar especialmente engañoso. La cámara funciona, el switch funciona y el enlace parece negociado. Sin embargo, los dos extremos no están trabajando con los mismos parámetros o uno de ellos interpreta de manera incorrecta el modo de funcionamiento del otro.

En ese escenario pueden aparecer colisiones, errores de transmisión, retransmisiones y una latencia irregular. El flujo de vídeo no desaparece necesariamente; llega de forma degradada, con cortes que se manifiestan cuando coinciden varios streams o aumenta la actividad de la escena. En una visualización en directo, el usuario lo describe como un vídeo que «va a tirones». En la grabación, puede traducirse en huecos, saltos o segmentos incompletos.

La forma más rápida de iniciar la comprobación es consultar las estadísticas de puerto del switch y, cuando sea posible, las de la cámara. Los contadores de colisiones tardías, errores CRC, fragmentos y cambios de estado aportan más información que la simple indicación de enlace activo. También es conveniente comprobar si el puerto ha renegociado velocidad recientemente o si muestra una velocidad distinta de la esperada.

La configuración manual no es siempre la opción más segura. Fijar un extremo y dejar el otro en negociación automática puede crear un desajuste tan problemático como el que se pretendía evitar. Si se decide establecer velocidad y dúplex de forma estática, los dos extremos deben coincidir y la elección debe ser compatible con el hardware. En equipos actuales, la auto-negociación suele ser el comportamiento previsto por el fabricante; en dispositivos antiguos, mezclas de marcas o enlaces con antecedentes de inestabilidad, puede ser necesario revisar el caso con más detalle.

Esta es una comparación orientativa, no una regla universal:

La documentación sí es importante, pero documentar una configuración no garantiza la interoperabilidad entre marcas. Una cámara, un switch y un NVR pueden cumplir estándares comunes y aun así presentar diferencias en funciones PoE, perfiles de vídeo, negociación, gestión o analítica. La compatibilidad debe validarse en el contexto real de la instalación, preferiblemente con una prueba previa o con una matriz de compatibilidad del fabricante.

En proyectos pequeños, la auto-negociación puede ser suficiente si los equipos son recientes y los contadores permanecen limpios. En despliegues con varios armarios, dispositivos de distintas generaciones o antecedentes de incidencias, conviene fijar un criterio homogéneo y dejar constancia de cada excepción. La decisión debe responder a las características del enlace, no a un número arbitrario de cámaras ni a la idea de que la configuración manual siempre es superior.

4. Sobrecarga del NVR: el grabador que se ahoga

Hay un detalle que muchos proyectos presupuestan mal: el NVR no es solo un disco duro con conectores de red. Es un sistema que recibe streams, los descodifica cuando corresponde, escribe en almacenamiento, genera índices, atiende a los clientes de visualización y, en algunos casos, ejecuta analítica de vídeo. Cuando se le piden más tareas de las que sus recursos pueden asumir, puede empezar a descartar tráfico o a procesarlo con retraso.

La sobrecarga puede proceder de varias fuentes:

• Demasiados streams principales y secundarios activos al mismo tiempo.
• Visualización simultánea de muchas cámaras en alta resolución.
• Analítica ejecutada en el propio NVR en lugar de en la cámara.
• Búsquedas forenses o exportaciones mientras continúa la grabación.
• Discos con una latencia elevada o con un rendimiento insuficiente para la carga.
• Base de datos e índices que crecen sin una política de mantenimiento adecuada.
• Servicios adicionales habilitados aunque no sean necesarios para la explotación.

El síntoma puede confundirse con un problema de red. El vídeo llega al NVR, pero el equipo no lo incorpora al proceso de grabación a tiempo. También puede ocurrir lo contrario: el almacenamiento responde con retraso y el sistema deja de atender correctamente a los flujos entrantes. Por eso no basta con revisar la conectividad entre cámara y grabador. Hay que observar la carga de CPU, memoria, red, discos y procesos de analítica durante el periodo en el que aparece la incidencia.

Las cifras de capacidad que figuran en la caja del NVR deben interpretarse con cautela. Un fabricante puede indicar un número máximo de cámaras o un ancho de banda de entrada, pero ese dato suele depender de la resolución, el códec, la frecuencia de imagen, la grabación continua, el tipo de analítica y las funciones de visualización. La capacidad de grabar no equivale necesariamente a la capacidad de visualizar, analizar y exportar todos los canales a la vez.

El dimensionamiento debería contemplar, como mínimo:

• El caudal de entrada de cada cámara y sus posibles picos.
• El número de streams que se graban, visualizan y consultan simultáneamente.
• La carga adicional de la analítica, especialmente si se ejecuta de forma centralizada.
• El rendimiento sostenido del almacenamiento, no solo su capacidad total.
• El comportamiento durante exportaciones, copias de seguridad y búsquedas.
• La reserva necesaria para ampliaciones y cambios de configuración.
• La compatibilidad entre los perfiles de vídeo de las cámaras y el NVR.

Un grabador que funciona cerca de su límite puede parecer estable durante semanas y fallar justo cuando se produce una escena compleja o cuando varios usuarios acceden a la plataforma. Ese patrón explica por qué algunas instalaciones solo presentan problemas en horario laboral, durante cambios de turno o cuando el equipo de seguridad revisa varias cámaras a la vez.

También conviene separar los problemas de almacenamiento de los de red. Si los contadores del switch son normales, pero el NVR muestra colas de escritura, tiempos de respuesta elevados o procesos saturados, cambiar el cableado no resolverá la incidencia. Si, por el contrario, el grabador tiene recursos disponibles y los descartes se concentran en un puerto o enlace, el origen probablemente se encuentre antes de la llegada del flujo.

No hay que olvidar la configuración de grabación. Reducir la resolución o la tasa de imagen puede aliviar el sistema, pero puede comprometer el valor de la evidencia. Una intervención correcta no consiste en bajar parámetros a ciegas, sino en decidir qué cámaras necesitan máxima calidad, qué escenas pueden grabarse con un perfil secundario y qué analítica debe ejecutarse en el borde, en la propia cámara, en vez de cargarla sobre el grabador.

5. UDP, TCP y los picos de tráfico de las cámaras VBR

La elección del protocolo de transporte influye en la manera en que el sistema reacciona a la pérdida de paquetes. UDP prioriza la inmediatez: envía los datos sin esperar a que cada paquete sea confirmado. Si un paquete se pierde, normalmente no se recupera a tiempo para la visualización en directo. El resultado puede ser pixelación, un salto breve o una pérdida de fotogramas, pero la imagen continúa avanzando con una latencia reducida.

TCP utiliza confirmaciones y retransmisiones. Esto puede mejorar la integridad del flujo cuando la red presenta pérdidas moderadas, pero introduce una consecuencia evidente: si faltan datos, el receptor espera a que lleguen. En una reproducción o en una descarga, esa recuperación puede ser aceptable. En una visualización en vivo, puede provocar retrasos, acumulación de latencia o congelaciones más largas que las producidas por un flujo UDP.

No existe una elección universalmente correcta. Para monitorización en tiempo real puede interesar una respuesta rápida aunque se pierdan algunos paquetes. Para determinadas funciones de grabación o acceso remoto, la prioridad puede ser recuperar los datos. Además, muchos sistemas no exponen esta decisión de la misma manera: la gestión depende de la cámara, del NVR, del servidor VMS y del método utilizado para transportar el stream.

La red debe estar preparada para la opción elegida. TCP no arregla una congestión severa; las retransmisiones pueden añadir tráfico a un enlace que ya está bajo presión. UDP tampoco es una solución mágica para reducir el consumo. Si el caudal supera la capacidad disponible, ambos protocolos terminarán mostrando síntomas, aunque de forma distinta.

El comportamiento VBR añade otra dificultad. Una cámara con tasa de bits variable aumenta el caudal cuando la escena contiene más movimiento, detalle o cambios de iluminación. Un acceso con tránsito continuo, una zona con vegetación movida por el viento, lluvia intensa, reflejos o una iluminación inestable pueden generar picos que no aparecen al calcular el consumo a partir de una escena tranquila.

Por esa razón, el diseño no debería basarse únicamente en el valor medio observado en la puesta en marcha. Es necesario comprobar cómo responde el sistema durante las escenas de mayor actividad y en los momentos en los que coinciden varios canales. El caudal medio sirve para estimar el almacenamiento; los picos son los que ponen a prueba los enlaces y los búferes.

En este punto, QoS puede ser útil si se configura con criterio. Una política de calidad de servicio permite priorizar el tráfico de vídeo frente a servicios menos sensibles al retraso, siempre que los equipos de la red marquen y reconozcan los flujos de manera coherente. DSCP puede formar parte de esa estrategia, pero su eficacia depende de que la cámara, los switches, los routers y el NVR apliquen las mismas reglas. Activarlo en un solo elemento no garantiza ningún resultado.

También se puede establecer una tasa máxima en las cámaras o ajustar el perfil VBR. Esa limitación debe respetar el nivel de detalle que requiere la escena. Si se fija demasiado baja, el sistema puede ahorrar ancho de banda a costa de perder información en momentos de movimiento. Si se deja demasiado alta, los picos pueden trasladar el problema al enlace, al NVR o al almacenamiento.

La revisión debería incluir:

• El protocolo utilizado en directo, grabación y acceso remoto.
• La latencia que aparece antes y después de cada cambio.
• El comportamiento de los streams ante pérdidas controladas o congestión.
• La tasa media y los picos de tráfico por cámara.
• Las reglas de QoS aplicadas en cada tramo.
• La forma en que se marcan y priorizan los paquetes.
• La relación entre calidad de imagen, caudal y capacidad de almacenamiento.

Cómo pasar del diagnóstico a una intervención útil

El diagnóstico eficaz no empieza cambiando la cámara que presenta la imagen pixelada. Empieza aislando el punto en el que se deteriora el flujo. Para ello, conviene avanzar desde lo más general hacia lo más concreto y registrar cada resultado. Una incidencia que desaparece después de reiniciar un switch no está resuelta: solo ha dejado de manifestarse durante un tiempo.

Una secuencia razonable de trabajo sería la siguiente:

1. Definir el síntoma. Hay que distinguir entre pixelación, congelación, pérdida de conexión, reinicio de la cámara, retraso creciente y ausencia de grabación. No todos esos síntomas apuntan al mismo componente.

2. Comparar directo y grabación. Si el directo falla y la grabación permanece íntegra, la causa puede estar en la visualización o en el enlace hacia el puesto de operador. Si ambos fallan, hay que revisar el camino completo hasta el NVR.

3. Consultar los contadores de los switches. Los errores CRC, descartes, renegociaciones y cambios de estado ayudan a separar una incidencia física de una saturación o de un problema situado más adelante.

4. Revisar el cableado y la alimentación. La certificación del enlace, la inspección de conectores y la comprobación del presupuesto PoE deben formar parte del diagnóstico, especialmente en cámaras exteriores o alejadas del armario.

5. Medir el tráfico en momentos representativos. Una captura en un puerto espejo o las estadísticas del sistema pueden mostrar si el problema coincide con picos de VBR, exportaciones, visualizaciones múltiples u otros servicios.

6. Comprobar el NVR. Hay que revisar CPU, memoria, almacenamiento, procesos de analítica y capacidad de entrada. Un NVR puede recibir los datos correctamente y no tener recursos para procesarlos con puntualidad.

7. Modificar una variable cada vez. Cambiar simultáneamente el códec, el protocolo, la QoS y la velocidad del puerto impide saber qué intervención ha funcionado. En sistemas críticos, cada cambio debe quedar documentado y validarse con una prueba posterior.

8. Observar el sistema después de la intervención. Una prueba breve puede no capturar los picos que provocan el fallo. La duración del seguimiento debe adaptarse a la frecuencia de la incidencia y a la importancia del servicio.

La documentación aquí no es burocracia. Una tabla con puertos, cámaras, velocidades negociadas, alimentación, VLAN, perfil de vídeo y ubicación permite detectar patrones cuando se repite una incidencia. También evita que, después de sustituir un equipo, se herede una configuración antigua que vuelva a introducir el mismo problema.

La compatibilidad entre marcas merece una atención específica. Que una cámara sea visible para el NVR no significa que todas sus funciones estén disponibles. El vídeo básico puede funcionar mientras fallan el audio, los eventos, el control PTZ, la analítica, los perfiles de compresión o la recuperación ante pérdidas. La interoperabilidad debe comprobarse función por función y versión por versión cuando el sistema dependa de prestaciones concretas.

La escalabilidad de un sistema CCTV no se mide por el número de cámaras que admite sobre el papel, sino por su capacidad para conservar la imagen cuando aumentan el tráfico, la analítica y las necesidades de operación.

La red como parte del sistema de seguridad

La videovigilancia no termina en la cámara. El sensor captura la escena, el codificador la convierte en datos, la red los transporta, el NVR los procesa y el almacenamiento los conserva. Si uno de esos elementos trabaja fuera de sus condiciones, la evidencia puede degradarse aunque los demás componentes sean de buena calidad.

Por eso el ancho de banda CCTV no debe calcularse únicamente sumando las tasas nominales de las cámaras. Hay que considerar los flujos secundarios, la visualización simultánea, la exportación de grabaciones, la gestión remota, los picos de las escenas complejas y el tráfico de otros servicios. Tampoco basta con mirar la capacidad teórica de un puerto: el diseño real incluye los uplinks, los armarios intermedios, los enlaces inalámbricos si los hubiera y los equipos que procesan el tráfico.

En una instalación estable, los registros deberían permitir responder a preguntas concretas:

• ¿En qué puerto aparecen los errores?
• ¿El problema afecta a una cámara, a un armario o a todo el sistema?
• ¿La incidencia coincide con un aumento de tráfico?
• ¿La cámara se reinicia o mantiene la conexión?
• ¿El NVR recibe los paquetes pero no consigue escribirlos?
• ¿La pixelación aparece en directo, en grabación o en ambos?
• ¿Qué cambió en la instalación antes de que empezaran los fallos?

Si no se pueden contestar esas preguntas, todavía no hay diagnóstico, solo una lista de sospechosos. Cambiar una cámara puede ocultar el síntoma durante un tiempo y generar un coste innecesario. Reiniciar el NVR puede vaciar temporalmente las colas, pero no corrige una congestión persistente ni un disco con latencia elevada. Forzar el dúplex puede estabilizar un enlace concreto, pero también puede crear un desajuste si no se aplica en los dos extremos.

La intervención más rentable suele ser la que elimina la incertidumbre: medir, comparar y aislar. A veces el resultado será sustituir un cable. En otros casos habrá que reorganizar los enlaces, cambiar un switch, trasladar una función analítica a la cámara o ampliar el almacenamiento. También puede ocurrir que la cámara sí esté defectuosa. La ventaja de un diagnóstico ordenado es que permite llegar a esa conclusión con evidencias y no por descarte improvisado.

Si una instalación presenta microcortes recurrentes, mi recomendación es comenzar por el camino completo del vídeo: cámara, alimentación, cableado, puerto, switch, enlace ascendente, NVR y almacenamiento. La red suele ser una parte importante del problema, pero no conviene convertirla en una explicación automática. En seguridad, la precisión del diagnóstico es tan importante como la calidad de la imagen. La confianza del cliente se construye cuando el sistema no solo muestra vídeo, sino que conserva de forma íntegra aquello que debía registrar.