Servidores SRT
Usa Servidores SRT para recibir de forma segura y con baja latencia señales de encoders remotos o sistemas de partners mediante endpoints gestionados de ingesta SRT. Controla el acceso de emisores y receptores, supervisa el transporte en directo desde la experiencia autenticada de Callaba y prepara rutas PULL principal y de respaldo para reconexión y recuperación después de un corte.
Elige este módulo cuandoNecesitas ingesta SRT gestionada con reglas de acceso, telemetría y failover entre fuente principal y respaldo.
Usa otro módulo cuandoUsa Rutas SRT para reenviar sin cambios; usa Retransmisiones para transcodificar, añadir overlays o cambiar de protocolo.
/api/srt-servers/createAntes de empezar
Todos los métodos de gestión requieren un x-access-token válido. Reserva puertos SRT accesibles, coordina con el emisor los ajustes de latencia y passphrase y define el acceso de emisores y receptores antes de compartir los datos de conexión.
Qué puedes hacer
createyupdateconfiguran puertos, latencia, ancho de banda, búfer de recepción, passphrase, acceso, callbacks y hosts de enrutamiento.getAll,getCountygetByIdconsultan los servidores.startystopcontrolan el listener.switchTovalida y guarda una ruta PULL configurada como preferida. Aplica la preferencia mediante una secuencia controlada de mantenimiento constopystart.removeelimina el servidor.
Flujo de ejemplo
- Crea un listener con el puerto, latencia, passphrase y reglas de acceso necesarios.
- Añade hosts de enrutamiento principal y de respaldo cuando necesites failover.
- Inicia el servidor y conecta el emisor.
- Supervisa el bitrate en directo, el ancho de banda estimado, el tiempo de ida y vuelta, los búferes y los contadores de pérdida en la experiencia de operación de Callaba.
- Interrumpe la fuente principal durante una prueba de aceptación controlada y confirma en la experiencia autenticada de operación que el bucle de reconexión y hosts de enrutamiento alcanza un respaldo preparado.
Casos de uso habituales
- Recibir una señal cifrada desde una cámara remota o un encoder situado en el recinto.
- Operar señales SRT PULL principal y de respaldo con reconexión y recuperación después de una interrupción.
- Controlar el acceso de emisores y receptores para partners o conexiones invitadas.
- Supervisar el estado de la contribución y el origen de la conexión durante un evento en directo.
Límites y resolución de problemas
El emisor y el listener deben coincidir en modo, puerto, latencia, identidad del stream y passphrase. El failover no siempre es hitless: el tiempo de detección y recuperación depende de la fuente, el destino, el intervalo de reconexión, el búfer, la latencia y la red. switchTo guarda una preferencia de ruta configurada, pero no recarga un relay en ejecución. Aplícala con una detención y un inicio controlados y después comprueba el estado SRT en directo desde la experiencia autenticada de Callaba.
Siguientes pasos
Comprueba la señal en directo y conecta después el servidor con Rutas SRT, Retransmisiones, Grabaciones, Multiview o Reproductores web.
Crear un gateway de servidor SRT para contribución
Crea un punto de ingesta SRT seguro para una señal de producción remota, inícialo y comprueba la configuración guardada de acceso y enrutamiento antes de dirigirla.
- Crear el gateway SRTDefine puertos, latencia, passphrase, acceso de emisor y receptor y enrutamiento.
POST /api/srt-servers/create - Iniciar la ingestaInicia el listener antes de compartir los datos de conexión con la fuente.
POST /api/srt-servers/start - Revisar el gateway guardadoConfirma puertos, registros de acceso, hosts de enrutamiento y estado activo desde el recurso autenticado.
POST /api/srt-servers/getById
Una respuesta de creación correcta confirma la configuración, no el estado del medio. Inicia el recurso y comprueba sus estadísticas antes de enviar tráfico de producción.
Preparar y validar rutas SRT principal y de respaldo
Configura fuentes principal y de respaldo aprobadas en un servidor PULL, revisa las rutas guardadas y valida la reconexión durante una interrupción controlada de la fuente.
- Configurar el conjunto de fuentesCrea un servidor PULL con las URL principal y de respaldo en routing_hosts.
POST /api/srt-servers/create - Revisar las rutas guardadasConfirma que el servidor usa PULL y contiene todos los hosts principal y de respaldo aprobados.
POST /api/srt-servers/getById - Iniciar el relay configuradoInicia el servidor solo después de revisar el orden de rutas y la configuración de conexión.
POST /api/srt-servers/start - Cerrar la aceptación con seguridadDespués de validar la pérdida de la fuente principal y la recuperación del respaldo, detén cuando corresponda el runtime temporal de aceptación.
POST /api/srt-servers/stop - Finalizar las rutas de producciónAplica las correcciones validadas de timeout u orden de rutas con el servidor en mantenimiento controlado.
POST /api/srt-servers/update
Es una recuperación por reconexión entre fuentes configuradas, no redundancia hitless a nivel de paquetes. Valida la recuperación con media real desde la experiencia autenticada de Callaba.
Aplicar una fuente SRT preferida en el siguiente inicio controlado
Revisa las rutas PULL, detén el relay en una ventana planificada, guarda la fuente preferida e inicia el servidor para que Engine regenere el runtime con esa preferencia.
- Registrar principal y respaldoCrea un servidor PULL cuyo routing_hosts contenga todas las URL que puede seleccionar la política.
POST /api/srt-servers/create - Revisar las rutas permitidasConfirma el modo PULL y las URL exactas guardadas antes de iniciar el mantenimiento.
POST /api/srt-servers/getById - Detener el relayEntra en mantenimiento controlado antes de cambiar la preferencia de ruta guardada.
POST /api/srt-servers/stop - Guardar la fuente preferidaEnvía el id del servidor y una srt_url exacta ya presente en routing_hosts.
POST /api/srt-servers/switchTo - Regenerar e iniciarInicia el servidor para regenerar el relay con la preferencia guardada y comprueba después el medio en directo desde la experiencia de operación.
POST /api/srt-servers/start
switchTo valida y guarda la preferencia de ruta configurada, pero no recarga un relay en ejecución. Trata stop, switchTo y start como una única transacción de mantenimiento planificada.
Controlar el acceso de emisores y receptores SRT
Elige al crear el servidor un acceso abierto para invitados, una lista de IP o un listener con passphrase y revisa los registros de acceso antes de distribuir los datos de conexión.
- Crear el límite de accesoConfigura stream_control_type y access_settings junto con puertos, latencia y passphrase opcional.
POST /api/srt-servers/create - Verificar los accesos guardadosConsulta la relación de acceso y confirma los roles de emisor y receptor antes de compartir las URL.
POST /api/srt-servers/getById - Rotar la política de forma seguraEnvía el estado completo del servidor y de acceso al cambiar entre invitados, lista permitida u operación protegida.
POST /api/srt-servers/update
CONTROL_ACCESS_ALLOW_ALL acepta identidades arbitrarias de emisor o receptor y debe reservarse para invitados intencionados. Usa CONTROL_ACCESS_IP_ADDRESS con access_settings para hosts conocidos y añade una passphrase SRT cuando necesites cifrado.
Crea un listener SRT con sus puertos, latencia, búfer, cifrado, enrutamiento, supervisión y reglas de acceso. Envía el JWT generado en el panel mediante la cabecera x-access-token.
Usa routing_type para configurar un listener independiente, PUSH o PULL. No envíes un campo server_fc por separado: Callaba calcula el control de flujo a partir de server_rcvbuf.
Las unidades son importantes: server_latency se expresa en milisegundos, server_timeout en segundos y tanto server_maxbw como server_rcvbuf en bytes.
Ejemplos de solicitud
Elige una plantilla sin enrutamiento, con enrutamiento por IP pública o Callaba, o con opciones de seguridad y supervisión. También hay un ejemplo de vMix Script para el aprovisionamiento desde un flujo de operador.
Casos de uso habituales
- Ofrecer a OBS, un encoder de campo o un colaborador un endpoint estable de contribución.
- Configurar enrutamiento PUSH o PULL para una fuente de respaldo o una entrega gestionada.
- Aplicar passphrase, reglas de acceso y callbacks de eventos o estadísticas a una ingesta que el equipo de operaciones debe supervisar.
Estos ejemplos mantienen routing desactivado y utilizan el propio servidor como límite estable de la ingesta.
Usa esta estructura cuando el servidor deba funcionar como un punto local sencillo de ingesta SRT, sin ninguna capa de enrutamiento. Es el contrato más simple y el más parecido al formulario básico del panel.
El modo PUBLIC_IP permite enrutar directamente hacia direcciones de red públicas. Usa PUSH cuando este servidor deba enviar activamente al punto remoto. Usa PULL cuando el extremo remoto sea el origen al que se conecta este servidor.
Usa esta estructura cuando el servidor deba enviar activamente hacia un destino de enrutamiento con IP pública. Cada destino necesita una dirección y un puerto; routing_server_name sigue siendo opcional en este modo.
Usa esta estructura cuando el servidor deba obtener el flujo del extremo enrutado en vez de enviárselo. En la práctica, es la variante PULL del ejemplo con IP pública y mantiene el ciclo de conexión correspondiente.
El modo de enrutamiento CALLABA utiliza destinos con nombre y aplica un contrato más estricto: la dirección, el puerto y el nombre del servidor son obligatorios. Usa PUSH cuando este servidor deba enviar a la ruta de Callaba, y PULL cuando la ruta de Callaba sea el origen al que se conecta.
Usa esta estructura cuando el servidor deba enrutar hacia la ruta de Callaba Cloud en modo PUSH. En este modo, cada destino también debe incluir routing_server_name.
Usa esta estructura cuando el servidor deba obtener el flujo desde la ruta de Callaba en vez de enviarlo. Mantiene el mismo contrato de destino con nombre, pero cambia el tipo de enrutamiento.
Estos ejemplos conservan la estructura básica de ingesta y activan una sola capacidad avanzada cada vez, para que puedas copiar con facilidad únicamente los campos que necesitas.
Usa esta estructura cuando el punto de ingesta deba exigir cifrado SRT. El ejemplo emplea una frase de contraseña de 16 caracteres, de acuerdo con la recomendación del producto para una protección AES-128 sólida.
Uso recomendado: puntos de ingesta compartidos, contribución de socios o cualquier caso en el que el servicio de escucha no deba aceptar sesiones SRT sin cifrar de forma predeterminada.
Usa esta estructura cuando el servidor deba enviar estadísticas SRT a un punto externo de supervisión. El servicio valida conjuntamente la URL de retorno y el intervalo.
Uso recomendado: eventos administrados, flujos de soporte y puntos de ingesta de larga duración en los que necesites telemetría externa sin consultar continuamente el objeto completo del servidor.
Usa esta estructura cuando solo deban permitirse direcciones concretas de publicadores o receptores. Cada entrada requiere host y role_name cuando stream_control_type es CONTROL_ACCESS_IP_ADDRESS.
Uso recomendado: ingesta controlada desde ubicaciones conocidas o direcciones fijas de los extremos. Si esas direcciones cambian a menudo, este modo requiere más mantenimiento que un listener abierto sencillo.
Etiqueta en el panel: Nombre.
Asigna un nombre claro al elemento creado para evitar confusiones más adelante. La capa de validación acepta entre 1 y 60 caracteres.
El contrato de API validado actualmente acepta SERVER_TYPE_SRT.
El modelo aún define SERVER_TYPE_WEBRTC, pero la validación de creación y actualización en producción solo permite actualmente el tipo de servidor SRT.
Etiqueta en el panel: Activar tras crearlo.
Este valor representa el estado del servidor. Al desconectarlo, se detienen las conexiones y transferencias de datos de todos los publicadores y receptores vinculados a este servidor SRT.
Etiqueta en el panel: Puerto.
Puerto en el que escucha el servidor SRT. La validación en producción acepta valores de 1024 a 65535.
Etiqueta en el panel: Puerto del receptor.
Puerto utilizado para recibir flujos SRT. La API validada actualmente también exige un valor de 1024 a 65535.
El entorno de ejecución cuenta con una alternativa si falta este puerto, pero el contrato público de creación y actualización sigue exigiéndolo de forma explícita.
Etiqueta en el panel: Latencia.
La latencia se configura en milisegundos. La recomendación del producto es usar aproximadamente ping × 4, con un mínimo práctico absoluto cercano a 120 ms para mantener una contribución SRT estable.
Consulta una configuración práctica en Cómo encontrar la latencia perfecta para tu entorno SRT.
Etiqueta en el panel: Ancho de banda máximo de red.
Ancho de banda o bitrate de red en Byte/s. Usa -1 para indicar que no hay límite. La capa de validación acepta actualmente valores de hasta 3125000000.
Etiqueta en el panel: Tiempo de espera por inactividad del flujo.
Se configura en segundos. Cuando se alcanza el límite, el servidor desconecta al cliente. -1 indica que no hay límite de tiempo.
Etiqueta en el panel: Tamaño del búfer del receptor.
Este campo se expresa en bytes. La API REST acepta de 12058624 a 200000000.
El panel comienza con 12058624 y recomienda 48234496 para producción. El control de flujo se deriva de este búfer de recepción, por lo que no debes enviar un campo server_fc separado.
Etiqueta en el panel: Frase de contraseña.
Secreto de cifrado SRT opcional para el punto de ingesta. El panel recomienda una longitud de 16, 24 o 32 caracteres para frases de contraseña AES-128, AES-192 y AES-256 seguras, respectivamente.
Sección del panel: Ajustes de enrutamiento.
Determina si el servidor SRT funciona como una ingesta local independiente o como un punto enrutado. Los valores validados son DISABLED, PUBLIC_IP y CALLABA.
Esta elección define la plantilla de ejecución utilizada: modo independiente, enrutamiento PUSH o enrutamiento PULL.
Estrategia que se aplica cuando el enrutamiento está activado. El modelo del servidor define PUSH y PULL.
Lista de destinos de enrutamiento.
Con el modo CALLABA, cada elemento debe incluir routing_host, routing_port y routing_server_name. Con PUBLIC_IP, la dirección y el puerto son obligatorios, mientras que el nombre del servidor es opcional.
El producto también vincula este modo a los flujos de respaldo. Consulta cómo configurar un flujo SRT de respaldo cuando se interrumpe el flujo principal.
URL de retorno opcional para enviar las estadísticas SRT. Si se configura, debe ser un URI válido con http o https.
Intervalo de envío de las estadísticas en segundos.
La validación de creación y actualización acepta valores de 1 a 10. Si las estadísticas están activadas y no se indica un intervalo, el servicio utiliza 1 segundo.
Modo de validación de acceso para cada flujo. Cuando se selecciona el control por dirección IP, el servicio valida las entradas relacionadas de access_settings como objetos de dirección y rol.
Lista opcional de reglas de acceso o identidades de flujo que se crearán junto con el servidor.
En las respuestas, aparecen como registros relacionados de access, no como el contenido original de la solicitud.
Id de recurso que se devuelve al crear o listar el servidor SRT.
Alias práctico del identificador del servidor. En la respuesta de producción, id coincide con _id.
Nombre guardado del servidor.
Código en formato slug generado a partir de server_name. El servicio lo obtiene mediante una normalización apta para URL.
Tipo del servidor creado, por ejemplo SERVER_TYPE_SRT.
Puerto de escucha que devuelve el producto para el servidor SRT creado.
Puerto del receptor que devuelve el producto para el servidor SRT creado.
Documento del puerto UDP asignado al lado publicador del servidor.
Documento del puerto UDP asignado al lado receptor del servidor.
Valor de latencia configurado en milisegundos.
Ancho de banda máximo configurado en Byte/s.
Tiempo de espera por inactividad configurado en segundos. Actualmente, el documento de producción lo serializa como una cadena.
Tamaño del búfer de recepción en bytes. El control de flujo se deriva de este valor.
Indica si el servidor creado queda activado inmediatamente después de su creación.
Campo de cifrado guardado para el servidor. Si la protección mediante frase de contraseña está activada, el servicio guarda un valor codificado en lugar del secreto en texto sin cifrar.
Prefijo del ID de flujo o de la URL del lado publicador que se guarda con el servidor.
Prefijo del ID de flujo o de la URL del lado receptor que se guarda con el servidor.
Destinos de enrutamiento guardados con el servidor. En el flujo mínimo de creación predeterminado, es una lista vacía.
Intervalo de estadísticas resuelto. El flujo de creación en producción usa 1 de forma predeterminada.
Registros relacionados de acceso a flujos para este servidor SRT. getById los devuelve con más detalle que las operaciones de creación y actualización.
Identificador del usuario propietario que añade el servicio.
Marca de tiempo de creación que devuelve el producto en producción.
Marca de tiempo de la última modificación que devuelve el producto en producción.
Campo de versión del documento que devuelve la serialización del modelo.
El producto devuelve un indicador booleano de éxito junto con el objeto del servidor SRT creado. Cuando la creación se completa correctamente, su valor es true.