Vamos a ponerte de nuevo en línea.

Si las desconexiones ocurren a intervalos constantes (por ejemplo, cada 60 o 120 segundos), casi siempre es la infraestructura de red (firewall, switches) - no el dispositivo VMS:

• Los firewalls, proxies y sistemas de detección de intrusos suelen cortar conexiones inactivas. Pide a tu equipo de TI que permita conexiones persistentes hacia *.viam.com.
• Si tu firewall hace inspección SSL/TLS, exime *.viam.com y *.viam.cloud - el equipo usa certificate pinning, que la inspección rompe.
• Un conflicto de direcciones IP (otro dispositivo usando la misma IP estática) causa el mismo síntoma - tu equipo de TI puede buscar duplicados.
• Prueba otro puerto del switch desde el inicio - un puerto en mal estado puede tirar el dispositivo donde ningún cambio del lado del dispositivo ayuda.
• Designa a un contacto en sitio que pueda revisar la luz de estado, reconectar el Ethernet y reiniciar el dispositivo - una desconexión que nadie nota puede durar semanas hasta que alguien pide video.

El VMS detecta automáticamente las cámaras en la red local. Si faltan algunas o todas:

• Verifica que las cámaras estén en la misma subred que el dispositivo - la detección funciona solo dentro de la misma subred y no cruza VLANs ni límites enrutados. Las cámaras en otra subred necesitan IPs documentadas y enrutamiento, o mover el dispositivo a un puerto de la red de cámaras.
• Detrás de un bridge de Eagle Eye, las cámaras son invisibles para todo lo demás hasta que el soporte de Eagle Eye habilita QL Stream (RTSP local por cámara en su grabador (CMVR) - su soporte lo hace en minutos).
• Las cámaras analógicas por coaxial detrás de un DVR nunca se van a detectar - revisa si el propio DVR expone RTSP antes de seguir con otra cosa.
• Confirma que el streaming RTSP esté habilitado en cada cámara - suele venir desactivado, especialmente en Verkada (se activa en Command) y Meraki MV (se activa por cámara en el panel).
• Verifica que el modelo de cámara realmente soporte RTSP. Las cámaras a batería y de consumo (Ring, Arlo, Blink, Nest) no lo soportan - consulta la tabla de compatibilidad.

Casi siempre son las credenciales o un límite de streams:

• Vuelve a verificar el usuario y la contraseña RTSP que compartiste con CompScience - el acceso de la cámara suele ser distinto del acceso al NVR, a la app móvil y a cualquier cuenta en la nube.
• Si la contraseña contiene caracteres especiales (!, @, #, *, ...), envíanosla tal cual y avísanos - los caracteres especiales requieren manejo cuidadoso en las URL de stream.
• Si las credenciales se cambiaron recientemente, envíanos las nuevas para actualizar el equipo de forma remota.
• Las cámaras cableadas directamente a un NVR a veces no son visibles en la red - puede que el NVR deba configurarse para exponer los streams RTSP a la LAN. Podemos guiar a tu proveedor.
• Los NVR a menudo sirven RTSP en un puerto no estándar - revisa el puerto RTSP en la configuración de red del NVR. Con frecuencia no es el 554 predeterminado, y nunca es el puerto de la interfaz web.
• Las cámaras Verkada permiten máximo 2 streams RTSP simultáneos, y su servicio RTSP arranca bajo demanda - es normal que un primer intento falle y el reintento funcione.
• Meraki MV usa el puerto TCP 9000 para RTSP en lugar del estándar 554 - verifica que nada en la LAN lo bloquee.
• ¿Todos los streams fallan la autenticación justo después de arreglar una interrupción? Las credenciales suelen rotarse durante la reparación - vuelve a confirmarlas antes de dar el sitio por sano.
• Las flotas de un solo fabricante suelen compartir un mismo juego de credenciales, así que rotar la contraseña de una cámara rompe a todos los usuarios. No rotes - pide a TI crear un usuario VMS dedicado con alcance solo a nuestras cámaras.
• Una lista de cámaras misteriosamente corta suele significar que el grupo de seguridad del usuario VMS está incompleto.
• Los proxies de re-transmisión rara vez usan el 554: DW Spectrum usa 7001 por defecto, Eagle Eye QL Stream es 8554 y solo local, los NVR UNV suelen usar 9090, y UniFi Protect usa 7441 con un token generado en la interfaz de Protect.
• El endpoint de alta resolución de Verkada puede transmitir HEVC, que se ve como frames grises - usa el endpoint de baja resolución H.264.

Si VLC en una laptop reproduce el stream pero el dispositivo da timeout, la diferencia está en quién pregunta - los dos no tienen la misma identidad de red. Dos causas, a menudo juntas:

• Dos rangos de IP en un mismo switch. Cámaras en un rango (192.168.0.x), el router de internet en otro (192.168.1.x), el mismo cable físico. Si el dispositivo solo obtuvo dirección en el rango del router, no puede llegar a las cámaras. Podemos configurarle doble dirección de forma remota - solo dinos ambos rangos.
• Whitelists de IP en el NVR. Muchos NVRs descartan en silencio las conexiones de cualquier IP que no esté en su whitelist: el NVR se ve totalmente inalcanzable para el dispositivo mientras funciona bien para las PC aprobadas. Pide al administrador del NVR agregar la IP del dispositivo al whitelist.

El dispositivo recibe varios streams de cámara a la vez, así que el ancho de banda local importa más que la velocidad de internet:

• Confirma al menos 100 Mbps de capacidad en la red local entre el equipo y las cámaras.
• Revisa si el dispositivo o las cámaras están en switches antiguos de 10/100 o en enlaces encadenados.
• Revisa la velocidad de enlace negociada en el puerto del switch del dispositivo - atascada en 10 Mbps con equipo gigabit, y sin arreglo cambiando cables, apunta al puerto o al switch mismo.
• Configura los streams en 1080p o 2K - el 4K sobrecarga la conexión, y un 720p limpio se analiza mejor que un 1080p con artefactos. La resolución del stream es independiente de la grabación local.
• En capturas de varios días, el 4K también satura el almacenamiento del dispositivo - el síntoma es un ciclo de reinicios más fallas de subida a medio camino. Bajar todos los streams a 1080p lo arregla.

• Las exportaciones necesitan al menos 10 Mbps de subida a internet. Si tu enlace es más lento, las subidas se retrasarán respecto a la grabación.
• Dinos tu horario real de operación y alineamos ambas ventanas - grabar en horario laboral, subir después. El VMS sigue el horario que le convenga a tu operación.
• Los sitios con un solo enlace delgado (digamos, una línea de 10 Mbps para toda la instalación) pueden usar una ventana estrictamente nocturna - subidas de 20:00 a 5:00 y nada durante el día.

La conexión de administración del dispositivo usa WebRTC. En redes muy restringidas:

• Un relay TURN de respaldo mantiene todo el tráfico saliente incluso cuando WebRTC directo está bloqueado - en la mayoría de los casos no se necesitan cambios de firewall.
• Como último recurso, abrir el puerto entrante 8080 hacia el dispositivo restaura el acceso de administración.
• Señal típica en sitios estrictos: el dispositivo aparece EN LÍNEA pero las sesiones remotas se quedan colgadas para siempre - las conexiones largas las corta una política de inactividad o de inspección. Si lo ves, avísanos.
• Los proxies, las subredes de cámaras aisladas y el filtrado de salida estricto tienen solución, pero necesitan revisión de ingeniería - escríbenos antes del día de instalación para planear el enfoque.

En redes multi-sitio (MPLS, SD-WAN), la causa clásica es que el dispositivo esté recibiendo cámaras del sitio equivocado - los streams RTSP corren de forma continua, así que los feeds entre sitios agregan Mbps sostenidos. El síntoma: descarga constante y pesada en el firewall más un sitio completo lento.

• Mantén cada dispositivo en el mismo gateway y red local que las cámaras que recibe, para que el tráfico de cámaras nunca salga del sitio.
• Vuelve a verificar la asignación dispositivo-cámaras después de cualquier renombre o reconfiguración - nombres de dispositivos intercambiados que mandan silenciosamente las cámaras de un sitio al dispositivo de otro es exactamente como pasa esto.
• Si de todos modos un enlace entre sitios está congestionado, avísanos - podemos limitar el ancho de banda del dispositivo o fijarlo a un enlace de respaldo mientras se corrigen las asignaciones.

Al VMS no le molesta mudarse, pero dos cosas suelen romperse:

• Nueva subred: si el dispositivo ya no comparte subred con las cámaras, la detección y el streaming se detienen hasta configurar el enrutamiento.
• Nuevo firewall: vuelve a confirmar las reglas salientes del checklist de TI en la nueva red.
• Reinicia el dispositivo después de cualquier cambio de puerto de switch o de VLAN, aunque la configuración se vea bien - el estado viciado del switch puede bloquear el alcance de red y ningún cambio del lado del dispositivo lo arregla.

Después de moverlo, solo vuelve a conectarlo - corriente y luego Ethernet - y se reconecta automáticamente en cuanto la red lo permita.