Videoconferencia sin cortes: por qué Hot Failover por sí solo no basta

Quien quiere proteger una videoconferencia piensa primero en la caída total: una excavadora, un corte de corriente, una avería del operador. En la práctica es el caso menos frecuente. Lo que de verdad arruina una transmisión en curso son la pérdida de paquetes y las variaciones de latencia en una línea que formalmente sigue «up».

Conocer el orden de magnitud ayuda a entenderlo. Zoom indica para el envío de un stream 1080p unos 3,8 Mbit/s de subida; una presentación compartida en paralelo añade entre 50 y 150 kbit/s, y el canal de audio entre 60 y 80 kbit/s. Un puesto de emisión profesional necesita por tanto unos 4 Mbit/s de subida — en una conexión con 40 o 300 Mbit/s de subida eso es un error de redondeo.

Ahí está precisamente el error de razonamiento de muchos planteamientos de protección: el ancho de banda no es el problema. El problema es la regularidad de la entrega. Un códec en tiempo real no puede volver a pedir un paquete perdido y esperarlo — la reproducción continúa. Si falta un paquete aparece un artefacto; si faltan varios seguidos, la imagen se congela o el sonido se corta. Un dos por ciento de pérdida de paquetes en una línea de 300 Mbit/s es invisible para la descarga de un archivo y claramente audible en una transmisión en directo.

De ahí se deriva el requisito real: no se trata de tener una línea de reserva. Se trata de que un error en la línea activa no llegue al receptor.

Hot Failover es un modo de funcionamiento del túnel SpeedFusion. El túnel se establece sobre todas las conexiones WAN implicadas y se mantiene activo en todas ellas; el tráfico útil, en cambio, lo transporta en cada momento solo la ruta con la prioridad más alta. Si esa ruta cae, toma el relevo la siguiente.

La ventaja decisiva frente al failover clásico sin túnel: la sesión se mantiene. Como el tráfico circula dentro del túnel y el extremo remoto conserva la misma dirección, la aplicación no percibe ningún cambio de dirección. No hay que volver a iniciar sesión, no hay reconexión, no hay expulsión de la reunión. Para un sistema de conferencias esa es una gran diferencia respecto a un router que simplemente cambia la ruta predeterminada.

Y aquí está el hueco del que rara vez se habla en las ofertas: la conmutación no empieza hasta que el fallo se ha detectado. La detección se produce mediante la supervisión de líneas y los keepalives del túnel. La rapidez con la que ocurre resulta del producto entre el intervalo de comprobación y el número de repeticiones antes de dar una línea por muerta — más el tiempo que necesita la conmutación en sí.

En esa ventana no hay sonido. Que sean tres, cinco o quince segundos depende de lo agresiva que sea la configuración de la supervisión; los valores del gráfico de arriba son un orden de magnitud típico de la práctica y no un valor de hoja de datos de Peplink. Los ajustes agresivos acortan la ventana, pero aumentan el riesgo de activaciones erróneas ante un pico breve de latencia.

Más importante todavía: el caso de fallo más frecuente no está cubierto en absoluto por Hot Failover. Una línea con un dos por ciento de pérdida de paquetes no está caída. Pasa cualquier comprobación, sigue activa y entrega todo el tiempo una imagen mala.

WAN Smoothing resuelve el mismo problema desde el otro lado. En lugar de elegir una línea y cambiar cuando cae, el túnel envía los mismos paquetes simultáneamente por varias líneas. El extremo remoto se queda con la copia que llega primero y descarta los duplicados.

Eso tiene tres consecuencias que encajan exactamente con una transmisión en directo:

• No hay conmutación. Si una línea cae en medio de una frase, el paquete ya ha llegado hace tiempo por la otra. Ni ventana de detección, ni hueco — tampoco los tres segundos.
• La pérdida de paquetes en una línea se vuelve invisible, siempre que ambos caminos no pierdan el mismo paquete al mismo tiempo. Con líneas tecnológicamente independientes eso es improbable.
• La latencia baja a la de la ruta más rápida. Como siempre gana la primera copia, no resulta la media de ambas líneas, sino el mínimo. Una segunda línea lenta no empeora por tanto la conexión — solo puede mejorarla.

El precio es ancho de banda, y de forma escalonada y previsible. El nivel Normal duplica el volumen de tráfico, Medium lo triplica y High lo cuadruplica; Maximum depende del número de pares de conexiones activos. En nuestro puesto de emisión con 4 Mbit/s de carga útil, el nivel Normal significa por tanto 8 Mbit/s en la conexión — en una línea empresarial, una nimiedad.

Lo importante es el punto de referencia: la sobrecarga se produce solo para el tráfico que circula por el túnel suavizado. Quien activa el smoothing de forma global para toda la casa duplica también cada descarga y cada copia de seguridad. Precisamente por eso corresponde ponerlo en un sub-túnel propio.

Entre «no hacer nada» y «enviar todo por duplicado» está Forward Error Correction. En lugar de transmitir copias completas, FEC añade al flujo de datos información de corrección con la que el extremo remoto puede reconstruir los paquetes perdidos sin volver a pedirlos.

La sobrecarga es así claramente menor. Los niveles estáticos se sitúan en torno al 13 por ciento y al 27 por ciento; la variante adaptativa se regula dinámicamente entre aproximadamente el 7 y el 20 por ciento, en función de la pérdida medida. En lugar de una duplicación se paga, por tanto, un recargo de un porcentaje bajo de dos cifras.

A cambio hay una limitación: FEC reconstruye mientras la información de corrección sea suficiente. Ante una caída total de la línea o una ráfaga larga de pérdidas no lo es — entonces el paquete sigue faltando. FEC es por eso la elección correcta cuando el ancho de banda es escaso o el camino va solo en una dirección, por ejemplo en un streaming en directo hacia una plataforma. Para una conferencia bidireccional con la máxima tolerancia a fallos, el smoothing sigue siendo la herramienta más potente — y ambos procedimientos pueden funcionar en paralelo en sub-túneles separados.

En los pliegos de requisitos aparece con frecuencia una formulación como: protección mediante Hot Failover y, en caso de necesidad, adicionalmente WAN Smoothing. Suena razonable y técnicamente no es realizable, al menos no en el sentido en que se pretende.

WAN Smoothing es un ajuste fijo en el perfil del túnel, no un lazo de regulación. No existe ningún automatismo que se active por sí solo cuando sube la latencia o crece la pérdida de paquetes. Quien planifica «en caso de necesidad» tiene que definir por tanto él mismo ese caso de necesidad — y hay exactamente tres respuestas sólidas:

1. Permanentemente activo para el sub-túnel crítico. La sobrecarga es conocida y pequeña, y el beneficio está siempre ahí. En casi todos los casos es la respuesta correcta.
2. Controlado por horario, vinculando a un perfil temporal la regla que dirige el tráfico al túnel suavizado. Tiene sentido cuando el volumen es limitado y los horarios de emisión son fijos.
3. FEC permanente, con smoothing solo para eventos definidos. El compromiso para líneas justas.

La conclusión incómoda que hay detrás: una protección que solo entra en acción después de detectar un problema nunca puede evitar la primera aparición del problema. Para una transmisión en directo, esa primera aparición es precisamente el daño.

La solución limpia separa el tráfico crítico del resto en lugar de duplicar toda la red. Peplink introdujo para ello los sub-túneles con el firmware 8.0.1: un enlace SpeedFusion puede llevar varios sub-túneles — están documentados hasta cinco — y cada uno con su propio perfil. Un túnel, varios comportamientos.

La configuración en la práctica:

1. El puesto de emisión recibe una dirección fija mediante una reserva DHCP y se ubica en una VLAN propia. Sin una dirección estable ninguna regla es fiable.
2. Crear un sub-túnel con WAN Smoothing, con el nivel Normal como punto de partida.
3. Una regla de tráfico dirige el tráfico de ese único ordenador a este sub-túnel — la asignación por la dirección de origen es más robusta que una regla sobre puertos, porque funciona independientemente de los puertos que use el software de conferencias en la siguiente actualización.
4. Todo lo demás circula directamente por las líneas o por un segundo sub-túnel en modo Hot Failover. Las copias de seguridad y las subidas grandes reciben además un límite de ancho de banda para que no desplacen al puesto de emisión.

Dos puntos en los que esto falla en la práctica. Primero, un túnel SpeedFusion necesita siempre un punto remoto — un segundo equipo Peplink, un FusionHub o el servicio alojado SpeedFusion Connect. Sin extremo remoto no hay smoothing, sino solo reparto de carga. Segundo, no es cosa que se resuelva por sí sola en cuanto al volumen de datos: lo que el túnel suavizado transmite por duplicado también cuenta por duplicado en el punto remoto. Cómo sale esa cuenta lo hemos calculado en un artículo propio.

Y la frase más importante para terminar, porque no aparece en el diagrama de red: la redundancia de líneas protege frente a fallos de línea. No protege frente a un puesto de emisión bloqueado, un adaptador de captura colgado o una avería del proveedor de conferencias. Quien quiera proteger de verdad una transmisión conecta también el ordenador y la pantalla al SAI y mantiene preparado un segundo ordenador como comoderador.

Este artículo se ha investigado y redactado con apoyo de IA y ha sido revisado antes de su publicación por los técnicos de Ascend certificados en Peplink.