media server logo
PreciosIniciar sesiónLaunch SRT server

Servidor SRT: cómo desplegarlo, operarlo y diagnosticarlo en producción

Mar 21, 2026
Iurii Pakholkov, fundador de Callaba

Escrito por Iurii Pakholkov

Fundador de Callaba. Crea herramientas de vídeo en la nube para SRT, RTMP, WebRTC, NDI, enrutamiento en vivo, monitorización, grabación y flujos de producción.

Última actualización: 22 de julio de 2026

Un servidor SRT es un endpoint de ingesta de vídeo en vivo que recibe, envía o retransmite señales SRT. Suele utilizarse para transportar vídeo en vivo desde una cámara, un codificador, una sede remota, un estudio, un dispositivo móvil o el sistema de un socio hasta un flujo multimedia controlado.

SRT significa Secure Reliable Transport (transporte seguro y fiable). Funciona sobre UDP y añade recuperación, cifrado, control de latencia, modos de conexión y estadísticas en tiempo real. Por eso resulta útil para contribución en vivo a través de Internet público, redes de sedes, enlaces de larga distancia y otras conexiones imperfectas.

Un servidor SRT no es lo mismo que un reproductor web, un CDN o un servidor de reproducción para espectadores. En la mayoría de los flujos en vivo, SRT se utiliza para contribución e ingesta. Después de recibir la señal en vivo, el servidor SRT puede enrutarla, grabarla, transcodificarla, enviarla por restreaming o convertirla a formatos para espectadores, como HLS, WebRTC o salidas RTMP.

Respuesta breve: ¿qué es un servidor SRT?

Un servidor SRT es el punto de ingesta de vídeo en vivo que acepta conexiones SRT de codificadores, herramientas de software, aplicaciones móviles, cámaras, sedes o señales de socios. La configuración más común utiliza el servidor en modo Listener y codificador en modo Caller. El servidor escucha en un puerto UDP, recibe la señal en vivo, muestra estadísticas como bitrate, RTT y pérdida de paquetes, y después entrega la señal a flujos de grabación, restreaming, transcodificación, enrutamiento, Multiview o reproducción.

Servidor SRT para ingesta de vídeo en vivo Diagrama indexable que muestra un codificador enviando SRT sobre UDP a un servidor SRT, y el servidor dirigiendo la señal en vivo a monitorización, grabación, restreaming y reproducción. servidor SRT ingesta de vídeo en vivo · UDP · Caller/Listener · monitorización · enrutamiento Codificador cámara, OBS, vMix, FFmpeg, aplicación móvil SRT sobre UDP stream ID · passphrase · latencia servidor SRT endpoint Listener recibir · monitorizar enrutar · proteger Grabación HLS Restreaming API contribución recuperación UDP control del flujo
Un servidor SRT recibe primero la señal de contribución. La grabación, la reproducción, el restreaming y el enrutamiento ocurren después de la ingesta.

¿Qué es un servidor SRT?

Un servidor SRT es el endpoint que acepta o administra conexiones SRT. Puede recibir una señal SRT en vivo de un codificador, retransmitirla a otro sistema o actuar como punto de entrega controlado entre una fuente remota y una plataforma de producción.

En un flujo de trabajo en vivo típico, el servidor SRT realiza cuatro trabajos prácticos:

  • Recibe la transmisión en vivo: un codificador de cámara, OBS, vMix, FFmpeg, Larix u otra fuente envía vídeo al servidor.
  • Protege la ruta de contribución: SRT puede recuperar paquetes perdidos y cifrar la sesión de transporte.
  • Expone estadísticas en vivo: los operadores pueden monitorizar el bitrate, el RTT, la pérdida de paquetes, las retransmisiones y el estado de conexión.
  • Entrega la señal a la siguiente etapa: el servidor puede dirigir la señal a flujos de grabación, transcodificación, restreaming, conmutación o reproducción.

Esto convierte al servidor SRT en la frontera entre la fuente y la plataforma. Cuando un equipo remoto dice «estamos enviando», el servidor SRT es donde se comprueba si la señal realmente llega, si es estable y si puede utilizarse en las etapas posteriores.

Servidor SRT frente al protocolo SRT

El protocolo SRT es el método de transporte. El servidor SRT es el sistema o endpoint de software que utiliza ese protocolo para recibir o enviar señales en vivo.

Término Significado Ejemplo
Protocolo SRT Método de transporte basado en UDP para enviar medios en vivo con recuperación, cifrado, control de latencia y estadísticas. La conexión entre un codificador y Callaba.
servidor SRT Endpoint de ingesta o relay que acepta sesiones SRT y las conecta con el resto del flujo. Callaba en modo Listener para una señal de una sede remota.

¿Qué es un servidor SRT para vídeo en vivo?

Un servidor SRT para vídeo en vivo es un servidor SRT utilizado para contribución de vídeo en tiempo real o casi en tiempo real. Recibe la señal mientras ocurre el evento y la entrega a un flujo de producción, grabación o distribución en vivo.

Los equipos utilizan servidores SRT para contribución remota de eventos, ingesta en la nube desde cámaras y codificadores, transporte del estudio a la nube, entrega de señales de socios, rutas de contribución de respaldo, producción remota y restreaming multidestino.

La palabra «en vivo» importa porque ajustar SRT no es lo mismo que transferir archivos. El servidor debe equilibrar retardo y recuperación. Si la latencia es demasiado baja para la ruta de red real, la señal puede conectarse y aun así sufrir cortes cuando hay pérdida de paquetes o jitter.

Cómo funciona un servidor SRT

Un servidor SRT recibe audio y vídeo ya codificados a través de una conexión SRT. En los flujos de vídeo en vivo, SRT suele transportar una señal MPEG-TS multiplexada, aunque el contenedor exacto depende del emisor y del flujo. En la práctica, el servidor recibe una señal multimedia lista: vídeo H.264 o H.265/HEVC, audio AAC y, en algunos casos, metadatos.

Cómo funciona un servidor SRT Diagrama indexable del flujo: codificación de la fuente, transporte SRT, ingesta en el servidor SRT, monitorización, enrutamiento y formatos de salida. Cómo funciona un servidor SRT El servidor recibe primero la contribución en vivo. La reproducción, la grabación y el restreaming ocurren después de la ingesta. 1. codificar H.264 / H.265 2. enviar SRT Caller 3. Recibir Servidor SRT Listener 4. Monitorear bitrate, RTT, pérdida 5. enrutar grabación restreaming transcodificación reproducción
SRT suele aportar más valor en las etapas de contribución e ingesta. Después, el servidor entrega la señal al resto del flujo multimedia.
  1. Un codificador crea la señal de audio y vídeo en vivo.
  2. El codificador envía la transmisión a un servidor SRT.
  3. El servidor SRT recibe la transmisión y rastrea el estado de la conexión.
  4. Si se pierden paquetes, SRT puede solicitar la retransmisión mientras los paquetes aún son útiles.
  5. El servidor entrega la señal al siguiente paso: grabador, transcodificador, restreaming, conmutador, automatización por API o sistema de reproducción.

Modos Caller, Listener y Rendezvous

SRT utiliza tres modos de conexión. El modo decide de qué lado inicia la conexión y cómo funciona la sesión a través de firewalls y NAT.

Modos Caller, Listener y Rendezvous de SRT Diagrama indexable que explica los modos de conexión SRT Listener, Caller y Rendezvous para configurar un servidor SRT. Modos SRT: Caller, Listener y Rendezvous Para la ingesta en la nube, el patrón de producción más habitual utiliza el servidor como Listener y el codificador como Caller. Listener servidor espera IP pública o DNS conocida. Puerto UDP conocido. La mejor primera configuración de nube. Caller el codificador se conecta Inicia la sesión SRT. Común para OBS, vMix, codificadores de hardware. Rendezvous ambos lados se conectan Útil en algunos casos de NAT. Prueba antes de la producción. No es la primera configuración. Primera prueba recomendada: codificador Caller → servidor SRT Listener
Para una primera prueba de ingesta en la nube, simplifica: servidor SRT en modo Listener y fuente remota en modo Caller.
  • Listener: espera una conexión SRT entrante en un puerto UDP conocido. Es el modo habitual para un servidor de ingesta en la nube o un endpoint de centro de datos.
  • Caller: inicia la conexión hacia un Listener. Es habitual en codificadores de campo, OBS, vMix, FFmpeg, aplicaciones móviles y fuentes remotas.
  • Rendezvous: ambos lados inician la conexión. Puede ayudar en algunos escenarios NAT, pero debe probarse cuidadosamente antes de producción.

Puertos del servidor SRT y reglas de firewall

SRT usa UDP. Eso significa que el servidor debe tener abierto el puerto UDP correcto en el grupo de seguridad de la nube, el firewall del host, el enrutador o la política de red.

  • el servidor tiene una IP pública o una dirección de red accesible;
  • el puerto UDP correcto está abierto;
  • el codificador utiliza el modo Caller/Listener correcto;
  • el stream ID coincide con la regla de enrutamiento del servidor, si se utiliza;
  • la passphrase coincide en ambos lados, si el cifrado está habilitado;
  • el flujo receptor está asignado a la salida correcta.

Un error habitual es comprobar solo que el codificador indique «conectado». La conexión no basta: también hay que confirmar que llega señal multimedia, que el bitrate es estable y que la siguiente etapa puede utilizarla.

Ejemplo de configuración del servidor SRT

Esta es una configuración práctica para la primera prueba. Sustituye el host, el puerto, el stream ID y la passphrase por tus propios valores.

Install steps 
Server side:
mode: listener
UDP port: 10080
latency: 200 ms
stream ID: event-main
passphrase: optional, same on both sides

Sender side:
srt://YOUR_CALLABA_IP:10080?mode=caller&latency=200&streamid=event-main

Regla de prueba: primero valida un emisor, un puerto UDP, un stream ID, una vista previa y una grabación. Después añade cifrado, varias fuentes, failover, enrutamiento, enlaces de reproductor y monitorización de producción.

Dónde encajan los servidores SRT en los flujos de trabajo de transmisión en vivo

SRT suele ser más fuerte en el lado de contribución del flujo de trabajo. Es la parte donde la transmisión en vivo viaja desde la fuente hasta la plataforma.

cámara o codificador → servidor SRT → transcodificador / grabador / restreaming / flujo de reproducción

Después de recibir la señal, la plataforma puede prepararla para restreaming, grabación, transcodificación, reproducción, enrutamiento, failover, automatización por API o monitorización de producción.

Servidor SRT frente a RTMP, HLS, WebRTC y NDI

SRT no sustituye a todas las tecnologías de vídeo. Resuelve una parte específica del flujo.

Tecnología Función recomendada Nota práctica
SRT Contribución, ingesta y transporte en vivo entre endpoints controlados. Úsalo cuando la ruta de contribución sea importante o imperfecta.
RTMP/RTMPS Publicación sencilla e ingesta en plataformas sociales. Suele utilizarse después de la ingesta SRT para el envío final a las plataformas.
HLS Reproducción a gran escala para espectadores en navegadores, televisores y dispositivos móviles. Los navegadores suelen necesitar HLS u otro formato de reproducción, no SRT directamente.
WebRTC Vídeo interactivo en tiempo real, llamadas, señales de retorno y participación con latencia inferior a un segundo. Útil cuando el espectador o participante necesita una latencia muy baja.
NDI Redes de producción de baja latencia dentro de entornos de estudio o LAN controlados. Utiliza puentes SRT/NDI para mover señales de producción entre sedes o flujos en la nube.

Para una comparación a nivel de protocolo, lea SRT frente a RTMP.

Cómo desplegar un servidor SRT

La configuración exacta depende del software, el proveedor de nube y el flujo, pero la lógica de despliegue suele ser la misma.

Lista de verificación de configuración del servidor SRT Tabla indexable para configurar un servidor SRT: modo, puerto UDP, latencia, stream ID, passphrase, códec, bitrate, audio y ruta de salida. Lista de verificación de configuración del servidor SRT Una sesión conectada no basta. Alinea la configuración de transporte y verifica la carga útil multimedia. Configuración Lado del servidor Lado del emisor Por qué es importante ModoListenerCallerhandshake DirecciónIP pública/DNShost del servidoraccesibilidad Puertoabrir puerto UDPmismo puertocortafuegos Latenciapresupuesto de recuperaciónmisma políticajitter / pérdida Stream IDregla de ruta/accesomismo valoridentidad Passphrasemisma clavemisma clavecifrado Códecrecibir + rutaH.264 / H.265compatibilidad ContenedorMPEG-TS comúnseñal A/V multiplexadaformato de carga útil Bitratecomprobar entrada realpor debajo del uplinkestabilidad Audiovista previa + monitorAAC/fuente de audiocarga útil EstadísticasRTT, pérdida, retransmisionessalud del uplinkdiagnóstico Rutagrabar / restreamingetiqueta de fuenteflujo de trabajo
La configuración de un servidor SRT requiere ajustes de red y comprobaciones multimedia. Un handshake correcto no demuestra que el vídeo sea utilizable.
Configuración Primera prueba recomendada Por qué es importante
Modo Servidor como Listener, codificador como Caller Patrón más sencillo de ingesta en la nube.
Puerto UDP Abrir un puerto UDP documentado por cada señal de ingesta El tráfico SRT no llegará a través de un firewall cerrado.
Latencia Empezar con 200–500 ms para rutas normales de Internet Da tiempo a SRT para recuperar pérdidas y fluctuaciones.
MPEG-TS/contenedor MPEG-TS es un contenedor habitual para vídeo en vivo sobre SRT El servidor recibe una carga útil multimedia multiplexada, no solo una conexión de transporte.
Stream ID Utiliza un valor legible como event-main Ayuda a enrutar, identificar y proteger las señales.
Passphrase Mismo valor en el emisor y el servidor El cifrado falla si las claves no coinciden.
  1. Crear un servidor o instancia en la nube con suficiente CPU, capacidad de red y almacenamiento para tu flujo de trabajo.
  2. Abre el puerto UDP requerido en el grupo de seguridad de la nube y el firewall del host.
  3. Crear un endpoint SRT Listener que recibirá la transmisión entrante.
  4. Definir reglas de stream ID y passphrase si necesita enrutamiento y cifrado.
  5. Conectar el codificador como SRT Caller y enviar la señal al endpoint Listener.
  6. Consulta estadísticas en vivo como bitrate, RTT, pérdida de paquetes, retransmisiones y estado de conexión.
  7. Dirigir la señal a la siguiente etapa para grabación, restreaming, transcodificación o reproducción.

Cómo utilizar un servidor SRT en Callaba

Dentro de Callaba, generalmente se usa un servidor SRT como punto de ingesta controlado. Una fuente remota envía una transmisión a Callaba, y Callaba hace que esa transmisión esté disponible para el siguiente paso del flujo de trabajo.

Los flujos de trabajo comunes de Callaba incluyen:

  • codificador SRT a Callaba y después restreaming a Twitch o YouTube;
  • OBS a Callaba mediante SRT y después grabación de la señal;
  • vMix a Callaba mediante SRT y después enrutamiento a otro destino;
  • aplicación móvil a Callaba mediante SRT y después restreaming a plataformas sociales;
  • sede remota a Callaba y después empaquetado para reproducción en navegador;
  • entrada SRT a Multiview en el navegador, grabador, enrutamiento por API y entrega controlada al reproductor.

Comprobación interactiva: abre el demo de Callaba Multiview para ver el aspecto de las fuentes recibidas después de la ingesta en la nube.

Qué monitorear en un servidor SRT

Una sesión SRT conectada no siempre significa que la señal esté sana. Monitoriza tanto el transporte como la carga multimedia.

Señales de transporte

  • Estado de la conexión: conectado, desconectado, reconectando o con error.
  • Bitrate entrante: si la señal multimedia continúa fluyendo al ritmo esperado.
  • RTT: tiempo de ida y vuelta entre emisor y receptor.
  • Pérdida de paquetes: cuántos datos se pierden en la ruta.
  • Retransmisiones: con qué frecuencia SRT tiene que recuperar los paquetes faltantes.
  • Jitter: cuánto varía el intervalo de llegada de los paquetes.
  • Presión del búfer de recepción: si la conexión está demasiado cerca de su límite de recuperación.

Umbrales prácticos: en buenas condiciones, el RTT suele estar entre 20 y 60 ms. Si se mantiene por encima de 150 ms o sigue creciendo, revisa la ruta de red. Una pérdida superior al 1–2 % suele indicar que debes aumentar la latencia, reducir el bitrate o mejorar el uplink antes de culpar al servidor.

Señales multimedia

  • vídeo negro o congelado, audio ausente o silencio;
  • códec, velocidad de fotogramas, resolución o formato de audio incorrectos;
  • timestamps incorrectos, keyframes ausentes o mapeo de señal incompatible.

Problemas comunes del servidor SRT

Ruta de diagnóstico del servidor SRT Diagrama indexable para diagnosticar un servidor SRT: comprobar modo, puerto UDP, stream ID, passphrase, latencia, carga útil multimedia y ruta de salida. Depurar un servidor SRT en este orden No te detengas en «conectado». Comprueba el transporte, la carga multimedia y la ruta de salida. 1. Modo Caller/Listener 2. UDP ¿puerto abierto? 3. Seguridad stream ID, clave 4. Latencia ¿suficiente recuperación? 5. Medios códec, audio 6. Estadísticas RTT, pérdida, bitrate 7. Salida grabación, HLS, RTMP
Diagnostica primero el transporte, después la carga útil multimedia y por último la ruta de salida.

La conexión SRT no se inicia

Comprueba el modo de conexión, el puerto UDP, la IP pública, las reglas del firewall, el stream ID y la passphrase de cifrado. La mayoría de los handshakes SRT fallidos se deben a un modo incorrecto, tráfico UDP bloqueado, un puerto equivocado o ajustes de seguridad que no coinciden.

La señal se conecta, pero el vídeo es inestable

Revisa RTT, jitter, pérdida de paquetes, retransmisiones y latencia. Si la latencia es demasiado agresiva para la ruta de red, SRT puede no tener tiempo suficiente para recuperar los paquetes perdidos antes de que dejen de ser útiles.

La transmisión se conecta pero no hay audio

Comprueba primero el codificador. Asegúrate de que la fuente de audio esté habilitada, que esté seleccionado el dispositivo de audio correcto, que el códec de audio sea compatible con el siguiente paso del flujo de trabajo y que la aplicación receptora pueda leer la pista de audio.

Antes de depurar el servidor SRT, confirma que el audio existe en la fuente. Utiliza la monitorización local en OBS, vMix, el codificador de hardware, los auriculares o la vista previa del dispositivo antes de culpar a la red o al servidor.

Las estadísticas de SRT se ven bien pero los espectadores aún tienen problemas

Si el enlace SRT está sano pero los espectadores ven pausas o artefactos, el problema puede estar en una etapa posterior. Comprueba la transcodificación, el empaquetado, el origen, el CDN, el reproductor y el formato de salida antes de atribuir el fallo al servidor SRT.

Servidor SRT autohospedado o gestionado

Puedes operar un servidor SRT propio o utilizar una plataforma gestionada. La mejor opción depende de cuánto control operativo quiera asumir el equipo.

Opción Usar cuando Riesgo principal
Servidor SRT autohospedado Necesitas control total sobre la ubicación de red, el cumplimiento, la lógica de enrutamiento o las reglas internas de despliegue. Tu equipo asume la monitorización, el escalado, las actualizaciones y las operaciones del evento.
Plataforma gestionada para flujos SRT Necesitas lanzar rápidamente y quieres monitorización, enrutamiento, grabación o restreaming en un solo lugar. Aun así, debes validar puertos, ajustes de la fuente, stream ID, passphrase y rutas de salida.

Callaba puede utilizarse como plataforma SRT en la nube o autohospedada. Puedes lanzarla en AWS, instalarla en tu propio servidor, crear puntos de ingesta SRT y conectarlos con restreaming, grabación, enrutamiento, vista previa en navegador, Multiview, entrega al reproductor y automatización por API.

Lista de verificación del día del evento para un servidor SRT

  • Confirma la IP del servidor o el nombre de host.
  • Confirma que el puerto UDP esté abierto.
  • Confirma los modos Caller, Listener o Rendezvous en ambos lados.
  • Confirma el stream ID, si se utiliza.
  • Confirma la passphrase de cifrado, si se utiliza.
  • Confirma el bitrate, el códec, la velocidad de fotogramas, la resolución y el formato de audio previstos.
  • Inicia la señal y verifica el bitrate entrante.
  • Comprueba RTT, pérdida de paquetes, retransmisiones y jitter.
  • Comprueba el vídeo y el audio reales, no solo el estado de conexión.
  • Confirma la ruta de salida: grabación, restreaming, transcodificación o reproducción.
  • Confirma la sincronización horaria: el servidor y el codificador deben usar NTP u otra fuente de tiempo coherente para correlacionar registros y grabaciones durante el diagnóstico.
  • Prueba la ruta de respaldo antes de que comience el evento.

Referencias oficiales y lecturas relacionadas

Utiliza estas referencias para detalles del protocolo SRT, documentación de configuración de Callaba y guías de flujo relacionadas.

Preguntas frecuentes

¿Qué es un servidor SRT?

Un servidor SRT es un endpoint de ingesta o relay de vídeo en vivo que recibe, envía o enruta señales SRT. Suele transportar una señal desde un codificador, una cámara, una sede remota, un estudio, un dispositivo móvil o un sistema asociado hasta un flujo multimedia controlado.

¿Qué es un servidor SRT para vídeo en vivo?

Es un servidor SRT utilizado para contribución de vídeo en tiempo real. Recibe la señal mientras ocurre un evento y la entrega a grabación, restreaming, transcodificación, conmutación, enrutamiento o reproducción.

¿Es lo mismo un servidor SRT que un servidor de streaming?

No siempre. Un servidor SRT suele gestionar ingesta o transporte en vivo entre endpoints controlados. Una plataforma de streaming completa también puede incluir transcodificación, grabación, reproducción, analítica, control de acceso, automatización por API y entrega mediante CDN.

¿Un servidor SRT utiliza UDP?

Sí. SRT corre sobre UDP. Es por eso que el puerto UDP correcto debe estar abierto en el firewall del servidor, el grupo de seguridad de la nube, el enrutador o la política de red.

¿Qué puerto utiliza un servidor SRT?

SRT no exige un único puerto fijo. El puerto se define en la configuración del servidor. En producción, los equipos suelen reservar un puerto UDP o un rango documentado para la ingesta SRT e indicar qué señales, clientes o eventos utilizan cada puerto.

¿Un servidor SRT debe usar Listener o Caller?

En la mayoría de los flujos de ingesta en la nube, el servidor SRT usa Listener y el codificador usa Caller. Funciona bien cuando el servidor tiene IP pública o DNS, un puerto UDP conocido y reglas de firewall claras.

¿Puede OBS enviar a un servidor SRT?

Sí. OBS puede enviar vídeo a un servidor SRT mediante una URL de salida SRT. El servidor recibe la señal y puede dirigirla a grabación, restreaming, transcodificación o reproducción.

¿Puede vMix enviar a un servidor SRT?

Sí. vMix admite flujos SRT y puede enviar o recibir señales SRT. Una configuración habitual envía SRT desde vMix a Callaba, mientras Callaba se encarga de monitorización, enrutamiento, grabación o restreaming.

¿Es SRT mejor que RTMP?

SRT suele superar a RTMP en contribución sobre redes inestables, con pérdidas o de larga distancia. RTMP sigue siendo habitual para publicación sencilla e ingesta de plataforma. Muchos flujos utilizan SRT para contribución y RTMP o RTMPS para la entrega final a una plataforma social.

¿Pueden los navegadores reproducir SRT directamente?

En flujos web normales, los navegadores no reproducen SRT directamente. Un servidor SRT recibe primero la señal y la plataforma la convierte o empaqueta en un formato para espectadores, como HLS o WebRTC.

¿Por qué mi señal SRT se conecta, pero no muestra vídeo?

La conexión de transporte SRT puede funcionar aunque la carga útil multimedia sea incorrecta. Comprueba códec, contenedor, timestamps, keyframes, pistas de audio, mapeo de señal, compatibilidad de salida y si realmente llega bitrate al servidor.

¿Cómo puedo hacer que un servidor SRT sea más confiable?

Utiliza un servidor estable, abre los puertos UDP correctos, elige una latencia realista, monitoriza RTT y retransmisiones, conserva margen de ancho de banda, valida la carga útil multimedia y prueba un endpoint de respaldo antes del evento.

¿SRT suele transportar MPEG-TS?

En vídeo en vivo, SRT suele transportar MPEG-TS con audio y vídeo multiplexados, aunque el contenedor exacto depende del emisor y del flujo. El servidor debe verificar la carga útil, no solo la conexión SRT.

¿Qué métricas del servidor SRT debo observar primero?

Empieza por bitrate entrante, RTT, pérdida de paquetes, retransmisiones y estado de conexión. En buenas condiciones, el RTT puede estar entre 20 y 60 ms. Si se mantiene por encima de 150 ms o la pérdida supera el 1–2 %, aumenta la latencia, reduce el bitrate o mejora la ruta de red.

Adónde ir a continuación

Última actualización: 22 de julio de 2026