Internet y redundancia para directo: bonding y failover

Vas a emitir un set y todo el proyecto depende de una sola cosa que no controlas: la conexión. La fibra contratada para la sala baja 200 Mbps de bajada y quizá 20 de subida, y esa asimetría es la que decide si puedes sostener 1080p50 a 6 Mbps con margen o si vas justo. El día del evento, una obra en la calle, una tormenta o un operador saturado bastan para que el codificador deje de entregar frames y la plataforma cierre la emisión por sí sola.

La solución no es contratar más ancho de banda, sino diseñar una arquitectura de red donde ninguna pieza sea imprescindible. Eso implica varias rutas de subida, un protocolo capaz de sobrevivir a la pérdida de paquetes y una grabación local que garantice que el material existe aunque el directo se caiga. Esta guía ordena esas decisiones de mayor a menor impacto.

Redundancia: qué falla y cómo se cubre

Antes de comprar nada, conviene separar los fallos por naturaleza, porque cada uno se cubre de forma distinta. Hay fallos de acceso (se cae el operador, cortan la fibra del edificio), fallos de equipamiento (el router se reinicia, el switch se bloquea) y fallos de calidad (el enlace sigue arriba pero con pérdidas y congestión). Solo el primero se resuelve con una segunda línea; los otros dos se resuelven con configuración y monitorización.

La regla práctica es que la segunda ruta no debe compartir ni medio ni proveedor con la primera. Una fibra principal de un operador y una línea secundaria de otro, con entrada física distinta, son redundancia real; dos servicios del mismo operador sobre el mismo cable no lo son: si cortan el cable, caen los dos. Cuando no existe segunda línea fija, la alternativa es un módem 4G/5G como ruta de respaldo, aceptando que su latencia y su estabilidad son peores.

El error más común es tratar la redundancia como una compra y no como un procedimiento. Tener dos líneas sin haber probado nunca la conmutación es tener una sola línea y una falsa sensación de seguridad.

La fibra principal y su línea secundaria

La fibra principal debe dimensionarse con cabeza. Si tu bitrate objetivo es 6 Mbps de vídeo más audio y sobrecarga, necesitas ese número cómodamente por debajo del 50 % de la subida real medida, no de la anunciada por el operador. El resto del margen absorbe picos, retransmisiones de SRT y tráfico de gestión.

La línea secundaria entra por un interfaz distinto del router o por un router propio. Si es otra fibra, comprueba que la acometida no comparte zanja ni armario con la principal. Si es 4G/5G, mide la subida real en el emplazamiento y a la hora del evento: un enlace móvil puede dar 40 Mbps a las once de la mañana y 4 Mbps a las diez de la noche, justo cuando emites.

Ambas rutas deben configurarse y documentarse antes del montaje, con sus direcciones reservadas y sus credenciales a mano. Durante el show no se improvisa red.

Bonding y dual-WAN: sumar o conmutar

Aquí se decide la arquitectura. El dual-WAN es un failover clásico: mantiene una ruta activa y guarda la otra como reserva; cuando la principal deja de responder, el router conmuta y el tráfico sale por la secundaria. La interrupción suele durar entre uno y varios segundos, suficiente para que el receptor corte si el protocolo no aguanta ese hueco.

El bonding va un paso más allá: agrega varias rutas simultáneamente y reparte el flujo entre ellas, sumando capacidades. Un encoder con bonding sobre dos módems y una línea fija puede mantener el stream aunque una de las tres vías desaparezca, porque el receptor reconstruye el flujo a partir de los paquetes que sí llegan. Es la opción natural para unidades móviles, exteriores y eventos donde no hay fibra disponible.

La contrapartida del bonding es la latencia añadida y la dependencia de un receptor compatible, normalmente el mismo fabricante o un servicio en la nube. Si el receptor no está disponible, el bonding no vale de nada. Para una sala fija, un buen dual-WAN con failover automático y un protocolo tolerante a huecos suele ser más simple y más barato.

QoS y VLAN de producción

Con dos rutas y varios servicios compartiendo la red, el tráfico de la emisión compite con todo lo demás. La QoS se encarga de que el flujo de vídeo salga primero: se marca el tráfico del encoder con la prioridad más alta y se deja el resto (actualizaciones, backups, invitados) en clases inferiores. Sin QoS, una subida de fotos por wifi puede arruinar la emisión.

La VLAN de producción separa físicamente lógica y lógicamente el tráfico crítico. En una VLAN viven el encoder, las cámaras IP y el control; en otra, el wifi de invitados y la red de oficina. Esa separación evita que un dispositivo infectado o un portátil con torrents consuma la subida que necesita el directo, y facilita aplicar reglas de QoS coherentes.

En instalaciones con audio sobre IP, la red de producción merece su propio direccionamiento y su propia política. Mezclar el tráfico de control de la realización con la navegación de oficina es pedir problemas a la hora del show.

Monitorización: ancho de banda, packet loss, jitter y latency

Empieza por la monitorización de ancho de banda: lo que no se mide no se puede defender. Antes del evento, mide la subida real de cada ruta con varias pruebas y en el horario del directo. Durante el evento, mantén un panel visible con el ancho de banda disponible por interfaz, el bitrate que entrega el codificador y el estado de cada enlace.

El umbral de alarma debe fijarse con antelación: si el margen entre el bitrate real y la capacidad medida baja del 40 %, hay que reducir bitrate o resolution antes de que la plataforma lo haga por ti. Mejor bajar de 1080p50 a 720p50 con imagen estable que mantener la resolución y entregar un directo congelado.

La monitorización no es solo técnica: alguien del equipo debe tener la responsabilidad de mirar el panel y avisar. Un gráfico que nadie lee no protege nada.

Packet loss, jitter y latency

El ancho de banda explica solo una parte del problema. El packet loss indica qué porcentaje de paquetes no llega; por encima del 1 % sostenido, la imagen empieza a mostrar artefactos y el audio a entrecortarse. El jitter mide la variación en el tiempo de llegada de los paquetes: un enlace con jitter alto obliga a buffers mayores y a más latencia.

La latency total es la suma de la codificación, el transporte, la red y la decodificación. En un directo con interacción en chat, mantenerla baja importa; en un concierto grabado para después, importa menos que la estabilidad. Cada decisión de buffer es un intercambio entre aguante y retardo.

Cuando estas tres métricas se degradan a la vez, casi siempre hay congestión en algún punto: un enlace compartido con otros usos, un router saturado o un operador con sobreventa en la zona. La respuesta correcta es reducir carga y conmutar de ruta, no subir buffers indefinidamente.

SRT para enlaces inestables

SRT está pensado exactamente para esto: transporta vídeo sobre UDP, detecta los paquetes perdidos y los retransmite de forma selectiva, con un margen de latencia que tú configuras. Eso permite atravesar enlaces móviles o congestionados sin la penalización de TCP, que ante una pérdida reduce el ritmo de toda la conexión.

En la práctica, SRT se configura con una latencia de recuperación acorde al enlace: baja en fibra estable, más alta en 4G/5G. Ese valor no es un adorno; si lo pones demasiado corto, no hay tiempo material para recuperar pérdidas y aparecen los artefactos.

RIST cubre un objetivo parecido con perfiles definidos por el foro correspondiente, y es una alternativa válida cuando el receptor lo soporta. Para salidas a plataformas de consumo, RTMP sigue siendo el estándar de entrada, pero conviene colocar SRT en el tramo entre la sala y el punto de agregación, donde sí controlas ambos extremos.

Grabación local aunque el streaming falle

Ninguna arquitectura de red es infalible, así que la última línea de defensa no está en la red: está en el disco. Graba la señal de programa en local, con calidad suficiente para publicar, y si tu switcher lo permite, graba también las ISO de cámara y el audio multipista. Esa grabación no depende de internet, del operador ni de la plataforma.

La grabación local debe arrancar antes que la emisión y verificarse en el primer minuto: comprobar que el fichero crece, que el audio está embebido y que el espacio libre cubre la duración prevista del show. Un disco lleno a mitad del set es el mismo desastre que una caída de red, solo que evitable.

Con grabación local, una caída de internet deja de ser una pérdida definitiva y pasa a ser un incidente: se pierde el directo, no el contenido. Para más detalle sobre captura de programa, ISO y audio multipista, consulta la guía de grabación multicámara y postproducción con multitrack.

Comprobar la arquitectura antes del show

Una hora antes del evento, ejecuta una lista corta y comprueba resultados, no intenciones. Mide subida en cada ruta por separado; fuerza la caída de la principal y cronometra cuánto tarda en asumir la secundaria; verifica que el bonding reparte tráfico y que el receptor reconstruye sin cortes; confirma que la QoS está aplicada y que la VLAN de producción no recibe tráfico ajeno.

Si el bitrate objetivo no cabe con margen en la peor de las rutas, baja la calidad antes de empezar. Durante el show, deja el panel de monitorización a la vista y define quién decide conmutar. Después, anota lo que pasó: los incidentes de red de un evento son la mejor documentación para el siguiente.

Para entender cómo el bitrate y el códec condicionan todo lo anterior, revisa streaming en directo: codificación, bitrate y multistream, y para las opciones de transporte entre la sala y el punto de salida, transporte de vídeo: SDI, HDMI, NDI, SRT y fibra.

Siguiente paso

Con la red resuelta, el siguiente frente es no perder nada de lo que ya tienes en la mesa: pasa a grabación multicámara y postproducción con multitrack para definir qué se graba, con qué nomenclatura y cómo se respalda antes de montar el aftermovie.