Qué es el protocolo SRT y cuándo conviene usarlo en un directo

SRT —Secure Reliable Transport— es un protocolo de transporte de vídeo en directo de código abierto, desarrollado originalmente por Haivision. Su propósito es llevar una señal por una red que no es de confianza —internet público, una línea móvil, un enlace satelital— con la mayor fiabilidad posible y con un retardo que el productor controla.

El problema que ataca: internet no garantiza que los paquetes lleguen, ni en orden, ni espaciados de forma regular. En una descarga da igual porque no hay prisa; en directo, cada paquete perdido es un bloque de imagen roto y cada retraso es un salto.

Cómo recupera los paquetes perdidos: ARQ

SRT funciona sobre UDP, que por sí solo no recupera nada, y añade encima su propio mecanismo de recuperación llamado ARQ (Automatic Repeat reQuest). El funcionamiento, en esencia:

1. El emisor numera cada paquete, lo envía y guarda una copia en un búfer.
2. El receptor reconstruye la secuencia y detecta huecos: si le llegan el 100, el 101 y el 103, falta el 102.
3. El receptor pide específicamente ese paquete y el emisor lo reenvía desde su búfer, a tiempo de colocarlo en su sitio antes de entregar la secuencia a la salida.

Esa petición y ese reenvío tardan, como mínimo, lo que la señal tarda en ir y volver. Ahí está la clave del protocolo: para que la recuperación sea posible, el receptor tiene que esperar. Ese tiempo de espera es el búfer de latencia, y es un parámetro configurable.

La latencia es un parámetro, no una consecuencia

En SRT decides cuánto retardo aceptas, y ese número determina cuántas oportunidades de recuperación caben dentro. Con poco búfer, un paquete perdido se pierde igual que sin SRT; con búfer generoso hay margen para pedirlo varias veces.

La regla práctica más extendida, y la que aplicamos como punto de partida, es reservar al menos cuatro veces el tiempo de ida y vuelta del enlace: si el trayecto tiene 30 ms, un búfer de unos 120 ms deja espacio para varios intentos. En enlaces de fibra cortos basta con valores bajos y el retardo total resulta imperceptible; en enlaces móviles o satelitales se sube bastante, porque lo que hay que absorber es la variación del retardo —el jitter— más que la pérdida en sí; y en contribución con vuelta de conversación se aprieta, aceptando que un tramo malo se verá mal.

Un segundo parámetro que conviene no olvidar: SRT necesita ancho de banda de sobra para los reenvíos. Si el enlace da justo para el bitrate del vídeo, no hay hueco por donde reenviar nada. Se reserva un margen sobre el caudal —del orden de un cuarto adicional como referencia habitual— y se dimensiona la subida contando con él, como explicamos en qué conexión necesita un streaming profesional.

Cifrado

La S del nombre es real: SRT incorpora cifrado AES con clave compartida, que se activa poniendo la misma contraseña en los dos extremos. Importa más de lo que parece: una señal de contribución que atraviesa internet sin cifrar es interceptable, y hay eventos —una junta de accionistas, una presentación bajo embargo, un acto institucional sensible— donde eso no es aceptable. Con RTMP a secas esa protección no existe; con SRT es una casilla de configuración.

Caller, listener y rendezvous

Una fuente frecuente de confusión: en SRT, quién inicia la conexión es independiente de quién envía el vídeo. Hay tres modos:

• Listener. Escucha en un puerto esperando que alguien se conecte. Necesita dirección alcanzable y puerto abierto: es el papel del receptor fijo, un servidor o un decodificador en la sede.
• Caller. Llama al otro extremo. No necesita puerto abierto ni dirección pública, porque la conexión sale de dentro hacia fuera: es el papel del emisor en el evento, detrás de un router móvil o de la red del recinto.
• Rendezvous. Los dos llaman a la vez y se encuentran a mitad de camino. Sirve cuando ninguno puede abrir puertos, y es el modo más frágil ante cortafuegos estrictos.

Por defecto usamos emisor en caller y receptor en listener: es lo que menos depende de la red del recinto, que es justo la que no controlamos.

SRT frente a RTMP

RTMP es un protocolo antiguo, sobre TCP, con limitaciones evidentes: cuando la red pierde paquetes, TCP los retransmite pero frena el envío, y ese frenazo es exactamente lo que produce el buffering en directo; no cifra por sí mismo; y está atado en la práctica a H.264 y AAC. A cambio tiene una virtud enorme: lo acepta todo el mundo, y muchas plataformas de destino no ingestan SRT.

De ahí sale el esquema real, que no es «SRT o RTMP» sino los dos: SRT en el tramo frágil —del evento hasta un punto fiable— y RTMP en el tramo final hasta la plataforma, aprovechando que ese último salto ocurre entre dos redes buenas. Es lo que montamos cuando emitimos desde un recinto con conectividad dudosa hacia YouTube o hacia una plataforma corporativa.

SRT sobre redes móviles y satélite

Es donde más se nota. Una línea 4G o 5G en un recinto con público es muy variable: el caudal sube y baja, el retardo fluctúa y hay pérdidas en ráfagas cuando la celda se congestiona. SRT, con búfer suficiente, absorbe buena parte de eso y entrega señal continua donde RTMP habría dado cortes. Lo mismo aplica a Starlink, cuya latencia absoluta es baja pero con más jitter que una conexión terrestre.

Conviene no confundir dos cosas: SRT recupera pérdidas y absorbe variación, pero no crea ancho de banda. Si el enlace no da el caudal necesario, la solución es bajar el bitrate o agregar líneas, no subir el búfer.

Cuándo NO aporta nada

Hay tres situaciones en las que meter SRT solo añade complejidad:

• Cuando el enlace es una fibra dedicada y estable y el destino acepta RTMP. Si no hay pérdida que recuperar, el mecanismo de recuperación no hace nada y solo has añadido un equipo o un servicio intermedio en la cadena, que es un punto de fallo más.
• Cuando el destino no lo admite. Si la plataforma final solo ingesta RTMP, hay que convertir en algún punto, y ese punto tiene que estar en una red buena. Sin un extremo fiable donde terminar el SRT, no se gana nada.
• Cuando el problema real es otro. Un cable defectuoso, un codificador saturado o una subida insuficiente no se arreglan cambiando de protocolo.

El material con el que montamos estos enlaces —routers, agregación, satélite y conversión— está en equipos de transmisión, y el planteamiento general de salida redundante, en conectividad para streaming.