Conmutación SRT ante fallos reales de red

La conmutación por error de SRT demuestra su utilidad durante los fallos que hacen que una conexión parezca estar en buen estado mientras el programa se congela. Desenchufar un cable es una primera prueba útil. Un plan de aceptación fiable también debe abarcar la congestión, la pérdida silenciosa de paquetes, el tráfico de retorno interrumpido y una ruta principal que desaparece y vuelve repetidamente.

Comience por definir el impacto en el espectador que puede aceptar. Registre la interrupción máxima de la imagen, el lapso de silencio en el audio y el tiempo de recuperación; a continuación, pruebe la cadena completa frente a esos límites. Que un receptor cambie la entrada seleccionada solo demuestra una parte de la recuperación.

Elija deliberadamente el mecanismo de conmutación por error de SRT

El protocolo Secure Reliable Transport (SRT) utiliza la solicitud de repetición automática (ARQ) para recuperar los paquetes perdidos mediante la retransmisión. El almacenamiento en búfer en modo en directo proporciona tiempo de recuperación; los paquetes que no cumplen su plazo de entrega pueden descartarse. La documentación de las opciones de socket de la biblioteca SRT define estos controles. La retransmisión sigue dependiendo de que exista una ruta operativa entre el remitente y el receptor.

Cambio entre fuentes independientes

Un receptor puede aceptar dos fuentes SRT, supervisarlas y seleccionar una para su salida. Cada fuente puede tener su propio codificador, conexión y sincronización. El receptor debe decidir cuándo cambiar y cómo gestionar la transición entre esas secuencias multimedia.

La documentación sobre entradas de enrutador de AWS MediaConnect ofrece un ejemplo concreto: sus entradas SRT admiten la conmutación por error de la fuente, mientras que su opción de fusión de paquetes se aplica a otros protocolos enumerados. El umbral documentado es de 500 milisegundos sin datos de origen. Se trata de un intervalo de detección específico del producto, no de una garantía del protocolo SRT ni de una promesa sobre la interrupción visible.

Protección de paquetes con grupos de conexión

Los grupos de conexión SRT coordinan varias conexiones que transportan un mismo flujo de datos enviado. El modo broadcast envía datos duplicados a través de las rutas de los miembros y descarta los duplicados en la recepción. El modo main/backup (principal/respaldo) envía normalmente la carga útil por una ruta, con otras conexiones disponibles para tomar el relevo.

La guía de inicio rápido sobre la agrupación de conexiones SRT, disponible en el repositorio de código abierto de Haivision, documenta los requisitos específicos de compilación y aplicación. Confirme la compatibilidad con grupos en ambos extremos, la configuración de la biblioteca instalada y quién se encarga de volver a conectar a los miembros que hayan fallado. Un dispositivo etiquetado como «compatible con SRT» puede que solo ofrezca conexiones ordinarias.

La redundancia en modo broadcast consume ancho de banda en cada ruta. Además, exige abordar por separado los fallos del emisor y del receptor compartidos por las rutas. Dos versiones codificadas de forma independiente del mismo programa no pueden tratarse simplemente como paquetes duplicados en un grupo.

A. Conmutar entre señales independientes

Codificador A

Codificador B

Señal SRT A

Señal SRT B

Seleccionar una señalDecodificador / salida

El receptor selecciona una señal completa. Las señales codificadas de forma independiente pueden tener distintas marcas de tiempo y secuencias de paquetes; pruebe la transición del programa.

B. Duplicar paquetes con un grupo SRT broadcast

Un emisorPaquete P

Ruta APaquete P

Ruta BPaquete P

Descartar el duplicado PUn flujo de datos

Los mismos datos viajan por ambas rutas. Las aplicaciones de ambos extremos deben admitir grupos compatibles. Cada ruta transporta la carga útil; siguen existiendo fallos comunes en los extremos.

Se muestra el modo broadcast. En modo main/backup, la carga útil suele viajar por una sola ruta del grupo. Son esquemas de arquitectura, no una afirmación de compatibilidad de Evrideo con grupos.

Identifique los puntos de fallo compartidos

Siga ambas rutas a través del host del codificador, la interfaz de red, el conmutador de acceso, el cortafuegos, el circuito de Internet y la infraestructura receptora. Averigüe qué fuente de alimentación, conducto de última milla, red ascendente o componente en la nube puede interrumpir ambas.

Las diferentes direcciones de destino por sí solas aportan muy poca información. Dos interfaces pueden seguir utilizando el mismo enrutador. Dos operadores pueden compartir una entrada física. Registre la independencia que haya verificado y los riesgos compartidos que persistan.

Decida por separado si necesita protección contra la pérdida de red, el fallo del codificador, el fallo del receptor o la pérdida de todo un emplazamiento. Una ruta de red duplicada desde un codificador cubre un conjunto de fallos distinto al de dos cadenas de contribución completas.

Codificador comúnPunto de fallo compartido

Router comúnPunto de fallo compartido

Dos rutas de red

Circuito A

Circuito B

Receptor comúnPunto de fallo compartido

Un circuito puede sobrevivir a un fallo de red. Perder el codificador, router o receptor compartido puede interrumpir ambas rutas. Compruebe también la alimentación, el acceso físico y la infraestructura aguas arriba.

Prevea el tiempo necesario hasta la decodificación de los contenidos multimedia

Mida tres intervalos: la detección del fallo, la obtención de material de sustitución utilizable y el restablecimiento de la reproducción en la fase de salida. Los búferes existentes pueden ocultar algunas interrupciones, mientras que la espera de un punto de acceso decodificable o la reconstrucción del estado del programa pueden prolongarlas. Mida el resultado en lugar de tratar estos intervalos como una fórmula aditiva universal.

Registre el tiempo de ida y vuelta (RTT), la variación en el retardo, las retransmisiones y las pérdidas no recuperadas bajo una carga realista. Incluya la ruta más lenta. Una ruta de respaldo necesita capacidad para el programa completo y el tráfico de recuperación cuando se active.

Considere una señal de contribución hipotética de 12 Mb/s con un RTT primario de 40 ms y un RTT de respaldo de 150 ms. Esas cifras por sí solas no permiten determinar un ajuste de latencia seguro. Inyecte las ráfagas de pérdida y la congestión previstas, compruebe cuándo llegan los paquetes de sustitución y observe si el receptor sigue cumpliendo sus plazos de entrega. Repita el proceso con tráfico concurrente y con ambas rutas afectadas.

Los ajustes de reconexión también merecen ser revisados. La documentación de la fuente SRT de GStreamer distingue entre la reconexión en modo caller y la espera en modo listener tras una desconexión. La reconexión automática no establece una segunda ruta de programa utilizable. Pruebe la aplicación implementada, incluyendo fallos de autenticación y reinicios del proceso.

1. t0
   Provocar el fallo

   Pérdida de paquetes, descarte silencioso del tráfico, imagen congelada o fallo de un proceso.

2. t1
   Detectar y seleccionar

   Registre por separado las marcas de tiempo de la alarma y de la selección de entrada.

3. t2
   Obtener una señal utilizable

   Compruebe las tablas del programa, las marcas de tiempo y un punto de acceso decodificable.

4. t3
   Verificar la salida decodificada

   Mida la recuperación de imagen y audio, los subtítulos y la continuidad SCTE-35.

5. t4
   Restablecer la protección

   Repare la ruta fallida, pruebe la disponibilidad del respaldo y aplique la política de retorno acordada.

Hitos ilustrativos, sin escala temporal. Las etapas pueden solaparse y los búferes ocultar fallos. Mida la interrupción visible real en la salida; no sume estas etapas para predecirla.

Compruebe el programa tras el cambio

En el caso de las secuencias de transporte MPEG, compare la identidad del programa, los identificadores de paquetes, las tablas de programa, la configuración de los códecs y la sincronización entre las señales. Compruebe que coincidan las pistas de audio y los subtítulos requeridos. Compruebe la disponibilidad de puntos de acceso aleatorio para reanudar la decodificación y determine cómo gestiona el receptor cualquier discontinuidad en las marcas de tiempo.

El informe técnico ETSI TR 101 290 ofrece orientación sobre la medición de flujos de transporte que abarca las tablas de programas, los contadores de continuidad y la sincronización de PCR/PTS. Utilice esas mediciones junto con la imagen y el sonido decodificados. Una sesión SRT establecida puede transmitir una imagen congelada, audio ausente o una señalización de programa dañada.

Capture la salida antes, durante y después de la conmutación. Inspeccione la sincronización de audio y vídeo, los subtítulos y los marcadores SCTE-35, incluida una conmutación durante una pausa publicitaria. Cuando un empaquetador y un reproductor de streaming sigan al receptor, inclúyalos en el ensayo: la experiencia de reproducción final es el criterio de aceptación.

Ensaye fallos que se asemejen a los de producción

Utilice una ruta de prueba aislada o una ventana de mantenimiento autorizada. Acuerde primero los umbrales, designe a un responsable de la reversión y registre las versiones de software, la configuración y las marcas de tiempo sincronizadas. A continuación se presenta un plan de pruebas de ingeniería, no una afirmación sobre resultados medidos de los clientes:

• Inyecte pérdidas aleatorias, pérdidas en ráfagas, variaciones del retardo y reordenación. Compare los paquetes retransmitidos con las pérdidas no recuperadas y los fallos visibles en la salida.
• Descarte silenciosamente el tráfico UDP y, a continuación, perturbe el tráfico en sentido inverso por separado. La detección debe funcionar sin un mensaje de desconexión claro.
• Restrinja la capacidad y aumente las diferencias de retardo en la ruta. Confirme que la ruta que permanece operativa soporta el servicio bajo carga.
• Reinicie los emisores y receptores, y pruebe credenciales de respaldo incorrectas. Compruebe que las alarmas identifiquen una ruta de respaldo inutilizable.
• Restaure el sistema principal repetidamente. Observe el comportamiento de conmutación y pruebe un segundo fallo tras la recuperación.
• Congele la imagen de origen o elimine el audio mientras continúan los paquetes. Confirme que la supervisión a nivel de programa detecta el problema.

Para cada prueba, registre la inyección de fallos, las alarmas, la selección de ruta, la salida utilizable y la redundancia restablecida. Conserve las capturas de la salida, así como los contadores de red. Tras una primera conmutación satisfactoria, una ruta de respaldo sin restablecer deja el servicio expuesto al siguiente fallo.

Acuerde la política de retorno al sistema primario

Documente si el sistema vuelve automáticamente, espera un intervalo de estabilidad o requiere la intervención de un operador. En el ejemplo de AWS, se vuelve a seleccionar una fuente principal configurada cuando se restablecen los datos. Otras implementaciones difieren. Las conmutaciones frecuentes durante una recuperación inestable pueden interrumpir repetidamente a los espectadores, por lo que debe ensayar la política real.

Evrideo Outpost ofrece rutas primarias y de respaldo configurables, visibilidad de SRT y supervisión del flujo de transporte. StreamCheck admite diagnósticos de SRT previos a la transmisión. Utilice estas capacidades para recopilar pruebas y confirmar el comportamiento específico del receptor que requiere su diseño, en lugar de dar por sentado la compatibilidad con grupos de paquetes o transiciones sin pérdidas.

Apruebe la conmutación por error de SRT mediante una matriz de fallos acordada, una recuperación de la señal de salida cuantificada y un responsable designado para restablecer la redundancia. Consulte con Evrideo las rutas de contribución y las pruebas de aceptación para su canal.