Videoconferencia autohospedada en un VPS: ancho de banda

La videoconferencia autohospedada en un VPS es un problema de ancho de banda

La videoconferencia autohospedada falla en servidores pequeños por una razón, y casi nunca es la instalación. El componente del servidor que utilizan todas las herramientas modernas es un SFU (unidad de reenvío selectivo). Recibe un flujo de vídeo de cada participante y reenvía una copia a todos los demás participantes, por lo que el tráfico saliente del servidor crece con el cuadrado del número de participantes. Un VPS de 1 GB o 2 GB con un enlace ascendente compartido ejecutará el software sin problemas. No podrá transportar la reunión general que está imaginando.

Por tanto, haga el trabajo en este orden. Cuente a los participantes, calcule los megabits y después elija el servidor. La instalación consiste en veinte minutos de copiar y pegar. El enlace ascendente determina si alguien podrá oírle.

¿Por qué el ancho de banda crece con el cuadrado del número de participantes?

Empecemos por la malla. Cada navegador codifica la imagen de su cámara y envía una copia directamente a cada uno de los demás navegadores. Ningún servidor de medios procesa el vídeo. Una llamada de malla entre dos personas necesita un servidor de señalización y nada más. Por eso, alojar llamadas entre dos personas cuesta casi nada. La malla deja de ser viable con unas cuatro o cinco personas, porque un portátil conectado a una red doméstica tiene que cargar cuatro o cinco copias independientes de su propio vídeo al mismo tiempo.

Un SFU funciona de otra forma. Cada navegador carga una copia al servidor. El servidor lee las cabeceras RTP (real-time transport protocol) y reenvía esos paquetes a los demás participantes sin descodificar el vídeo. Ese es todo el mecanismo. Por eso un SFU consume poco CPU y mucho ancho de banda de red.

La arquitectura anterior es un MCU (multipoint control unit). Descifra cada flujo entrante, los compone en una sola imagen y vuelve a codificar esa imagen. El ancho de banda saliente es mínimo. El coste de CPU es enorme. Actualmente, casi ningún sistema usa un MCU para vídeo, y esta guía no usa ninguno.

Ahora veamos los cálculos de un SFU. Supongamos que cada persona envía vídeo a 1.2 Mbps y que nadie ha apagado su cámara. El servidor recibe N veces 1.2 Mbps. Ese valor crece de forma lineal y no suele ser problemático. El servidor envía N veces (N menos 1) veces 1.2 Mbps, porque cada una de las N personas debe recibir los otros N menos 1 flujos. Ese segundo valor es el que termina con muchos proyectos.

[
  {
    "label": "4 people",
    "sfu_egress_mbps": 14.4,
    "egress_gb_per_hour": 6.5,
    "monthly_volume_tb": 0.13
  },
  {
    "label": "8 people",
    "sfu_egress_mbps": 67.2,
    "egress_gb_per_hour": 30.2,
    "monthly_volume_tb": 0.6
  },
  {
    "label": "15 people",
    "sfu_egress_mbps": 252,
    "egress_gb_per_hour": 113.4,
    "monthly_volume_tb": 2.3
  },
  {
    "label": "30 people",
    "sfu_egress_mbps": "1,044",
    "egress_gb_per_hour": 469.8,
    "monthly_volume_tb": 9.4
  },
  {
    "label": "50 people",
    "sfu_egress_mbps": "2,940",
    "egress_gb_per_hour": "1,323",
    "monthly_volume_tb": 26.5
  }
]

Esas filas son cálculos, no mediciones de un servidor concreto. La columna mensual supone veinte horas de llamadas al mes. Lea primero la última fila. Cincuenta personas con la cámara encendida necesitan 2,940 Mbps de tráfico saliente sostenido desde una sola máquina. Treinta personas necesitan 1,044 Mbps. Cuatro personas necesitan 14.4 Mbps, una cantidad que cualquier VPS gestiona sin problemas. Entre la fila de cuatro personas y la de treinta, el número de participantes crece siete veces y media, mientras que el tráfico saliente crece más de setenta veces.

Las implementaciones reales suelen quedar por debajo de estas cifras. Conviene saber exactamente por qué. Jitsi y LiveKit usan simulcast: el emisor publica varias capas de calidad al mismo tiempo, y el SFU reenvía una capa de baja calidad a quienes no aparecen en pantalla. Jitsi también tiene un ajuste last-N que reenvía vídeo sólo de los hablantes más recientes. Ambas técnicas ahorran mucho tráfico. Ninguna cambia la forma de la curva. Además, ambas dejan de ayudar en cuanto todos encienden la cámara y fijan la imagen de los demás.

¿Qué le proporciona realmente el enlace ascendente de un VPS?

Una página de planes indica «puerto de 1 Gbps». Esa es la velocidad de la tarjeta de red virtual, no una garantía sobre el siguiente salto. El enlace se comparte con los demás inquilinos del mismo host físico, por lo que el rendimiento sostenido durante una hora de alta carga es inferior a la velocidad del puerto, y una videollamada es precisamente una carga sostenida. La mayoría de los planes también incluyen un límite mensual de transferencia, tras el cual se aplica una limitación de velocidad o se cobra un importe adicional.

Ese límite es donde aparece el coste inesperado en la factura. Veinte horas de la llamada de treinta personas en un mes transfieren 9.4 TB desde el servidor, a 469.8 GB por hora. Veinte horas de la llamada de cincuenta personas transfieren 26.5 TB. Compruebe el límite de transferencia antes que la cantidad de RAM y, si la página del plan no lo especifica claramente, esa falta de precisión ya es una respuesta. Leer correctamente una oferta de VPS es más importante para esta carga de trabajo que para casi cualquier otra.

Jitsi Meet: la opción predeterminada y sus requisitos

Jitsi Meet es la opción con la que debería empezar la mayoría. Se instala desde el repositorio Debian del propio proyecto, configura nginx y un certificado durante la instalación, y el videobridge (JVB) usa un único puerto UDP, lo que mantiene breves las reglas del firewall. Requiere Debian 11 o posterior, o Ubuntu 22.04 o posterior.

sudo apt update
sudo apt install -y apt-transport-https curl gnupg
sudo add-apt-repository universe
sudo apt update
sudo curl -sL https://prosody.im/files/prosody-debian-packages.key -o /usr/share/keyrings/prosody-debian-packages.key
echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list
sudo apt install -y lua5.2
curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install -y jitsi-meet

El instalador solicita un nombre de host y después ofrece varias opciones de certificado. Seleccione la opción Let's Encrypt y proporcione un nombre de dominio que ya resuelva a la dirección pública de este servidor. El certificado se emite mediante un desafío HTTP, por lo que un nombre que apunte a otro lugar falla en ese paso.

Después, abra los puertos. Estos son los que documenta el manual, con SSH en primer lugar para que ufw enable no le deje fuera:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable

TCP 80 y 443 sirven la aplicación web y permiten renovar el certificado. UDP 10000 transporta todo el audio y el vídeo, y es el puerto que se suele olvidar. UDP 3478 y TCP 5349 pertenecen al servidor coturn que el paquete de Jitsi instala junto con el bridge. Es la ruta alternativa para los usuarios cuyas redes bloquean UDP.

sudo systemctl status jitsi-videobridge2
sudo ss -ulnp | grep 10000

El primer comando debería indicar que el servicio está activo. El segundo debería mostrar el bridge escuchando en UDP 10000. Si no muestra nada, el bridge no se inició y /var/log/jitsi/jvb.log indicará el motivo.

Para dimensionar el servidor, el manual de Jitsi publica sus propios valores iniciales y BigBlueButton publica otros mucho mayores:

[
  {
    "label": "Jitsi Meet",
    "ram_gb": 8,
    "cpu_cores": 4,
    "uplink_mbps": "1,000"
  },
  {
    "label": "BigBlueButton 3.0",
    "ram_gb": 16,
    "cpu_cores": 8,
    "uplink_mbps": 250
  }
]

El manual de Jitsi recomienda 8 GB de RAM y 4 núcleos dedicados para un servidor serio. A menudo, 1,000 Mbps de red son suficientes. También indica que las instalaciones más pequeñas funcionan con 4 GB o 2 GB. Hay un detalle de esa página que conviene recordar: Prosody, el servidor XMPP que gestiona la señalización, sólo puede usar un núcleo. Los núcleos adicionales ayudan al bridge, pero no hacen nada por la señalización.

¿Por qué todos se unen a la llamada, pero nadie ve el vídeo?

Este es el fallo habitual de Jitsi en un VPS. La lista de participantes se llena, el chat funciona y todos los recuadros de vídeo permanecen en negro. El videobridge anuncia las direcciones que encuentra en sus propias interfaces. En un proveedor que asigna a la máquina virtual una dirección privada y le asigna una dirección pública mediante NAT, la única dirección que encuentra JVB es la privada. Por eso, todos los clientes intentan enviar los medios a una dirección como 10.0.0.5 y los paquetes no llegan a ningún sitio.

Indique al bridge las dos direcciones. Añada un mapeo estático a /etc/jitsi/videobridge/jvb.conf:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "10.0.0.5"
          public-address = "203.0.113.10"
        }
      ]
    }
  }
}

Reinicie con sudo systemctl restart jitsi-videobridge2. Obtenga la dirección local de ip -4 addr show y la dirección pública del panel de control del proveedor. Las guías antiguas configuran lo mismo en /etc/jitsi/videobridge/sip-communicator.properties con las claves org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS y org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS. Esas claves siguen funcionando, pero las instalaciones nuevas deben usar el bloque de mapeo anterior.

La otra causa es un firewall que no configuró. La mayoría de los proveedores ejecuta un firewall de red en el panel de control, independiente de ufw en el servidor, y UDP 10000 debe estar abierto en ambos. Para averiguar qué capa descarta los paquetes, ejecute sudo tcpdump -ni any udp port 10000 en el servidor mientras alguien se une desde fuera. Si no llega ningún paquete, nada alcanza la máquina y el bloqueo está antes del sistema operativo. Si llegan paquetes mientras los recuadros permanecen en negro, el bridge responde con una dirección que el cliente no puede alcanzar. En ese caso, el problema está en el mapeo. Si no tiene claro si el problema está en ufw, las reglas de ufw que realmente necesita un VPS explican el orden de las reglas que suele causar problemas.

BigBlueButton: pesado, rígido y requiere el servidor completo

BigBlueButton está diseñado para la enseñanza. Incluye una pizarra, salas separadas, encuestas y un área de presentaciones. Su canalización de grabación es una función principal, no un complemento. También es, con diferencia, la opción más pesada de esta guía. No es un paquete que pueda añadir a un servidor existente.

En agosto de 2026, la ruta admitida es BigBlueButton 3.0 en Ubuntu 22.04, seleccionada con el indicador de versión jammy-300. Los requisitos de producción indicados por el proyecto son 16 GB de memoria con swap habilitado, 8 núcleos de CPU con un alto rendimiento por hilo, 250 Mbps de ancho de banda simétrico y 500 GB de disco si conserva las grabaciones (50 GB si las deshabilita). Los puertos son TCP 80 y 443, además del rango UDP de 16384 a 32768.

wget -q https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh
less bbb-install.sh
bash bbb-install.sh -w -v jammy-300 -s bbb.example.com -e info@example.com -g

Los ejemplos del propio proyecto pasan ese script directamente a bash. Descárguelo y léalo primero. El script reescribe la configuración de nginx, instala su propia pila multimedia y de audio, fija versiones de paquetes y se apropia del nombre de host. Ese comportamiento forma parte del diseño, no es un defecto: BigBlueButton espera controlar toda la máquina. El indicador -w configura el firewall, -s es el nombre de host, -e es la dirección que Let's Encrypt registra y -g añade el frontend Greenlight. Si el mismo servidor también termina TLS para otros servicios, mueva BigBlueButton a otro servidor o asegúrese de entender qué hace la configuración del proxy inverso de nginx antes de que el script la modifique.

Compare detenidamente las dos filas de esa tabla. BigBlueButton solicita el doble de memoria y el doble de núcleos que la recomendación de Jitsi, pero solicita una cuarta parte del ancho de banda. Las dos cifras no se han medido de la misma forma y parten de tamaños de sala diferentes. Por tanto, trátelas como el punto de partida de cada proyecto, no como una comparación directa. La diferencia de CPU es real. Se debe a todo lo que hace BigBlueButton además de reenviar vídeo.

Galène: la opción pequeña

Galène es un SFU compacto escrito en Go. Se compila en un único binario estático, incluye su propio cliente web y también incorpora un servidor TURN. Por tanto, no necesita un servidor XMPP, un runtime de Java ni una aplicación Rails que mantener activa. Si necesita una llamada fiable para diez personas en un servidor modesto, pruebe esta opción antes de concluir que necesita más hardware.

sudo apt update && sudo apt install -y git golang-go
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w'
mkdir groups

El paquete golang-go de Ubuntu 24.04 contiene Go 1.22. Si go build indica que el módulo necesita una versión más reciente de Go, instale un toolchain actual desde go.dev en lugar de intentar resolverlo con el paquete de la distribución.

Un grupo es la forma en que Galène denomina una sala, y un grupo es un archivo JSON:

echo '{"users": {"vimes": {"password":"sybil", "permissions":"op"}}}' > groups/night-watch.json
./galene &

Abra https://your.server:8443/group/night-watch/ e inicie sesión como vimes. Esas credenciales aparecen directamente en el README del proyecto, así que cámbielas antes de que el puerto sea accesible desde cualquier otro lugar. Para una implementación real, el proyecto documenta una unidad de systemd:

[Unit]
Description=Galene
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/galene
User=galene
Group=galene
ExecStart=/home/galene/galene
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Los puertos son TCP 8443 para la interfaz web, TCP y UDP 1194 para el servidor TURN integrado y un intervalo de puertos UDP altos para los medios. Fije ese intervalo para poder escribir una única regla de firewall:

./galene -udp-range 40000-40100

La opción -turn es la importante en un VPS. -turn ':1194' escucha en todas las direcciones IPv4 públicas. -turn '203.0.113.1:1194' indica a Galène la dirección que verán realmente los clientes. Esto es necesario cuando la dirección propia de la máquina es privada. -turn '' desactiva el servidor integrado para que pueda usar uno externo mediante data/ice-servers.json. El valor predeterminado es auto, que se comporta como :1194 cuando no existe ningún ice-servers.json.

Puede colocar nginx delante de la interfaz web configurando proxyURL en data/config.json y haciendo proxy de la ubicación /ws con las cabeceras de actualización de WebSocket. Tenga claro qué cubre esta configuración: los clientes siguen abriendo flujos UDP directos y conexiones TCP directas al puerto TURN. Por tanto, el reverse proxy sólo gestiona la página y la señalización. Los medios nunca pasan por él.

La documentación de Galène indica que necesita recursos de servidor muy moderados y no publica ninguna cifra concreta, así que no espere encontrar una. Los cálculos de ancho de banda anteriores siguen siendo plenamente aplicables. Lo que ahorra es la memoria y los componentes adicionales de todo lo que no forma parte del SFU.

Owncast: de uno a muchos, con un ancho de banda lineal

Muchos requisitos de «videoconferencia» consisten en realidad en que una persona presenta contenido a una audiencia que escribe en el chat. Si ese es su caso, una SFU es la herramienta equivocada y la economía cambia por completo. Owncast recibe un flujo RTMP desde OBS o un codificador similar y sirve HLS mediante HTTPS estándar. El ancho de banda por espectador crece de forma lineal en lugar de cuadrática. Además, como la salida son segmentos HTTP normales, puede trasladarla a un almacenamiento de objetos o a una CDN y dejar de pagar por ella en el origen.

curl -sL https://owncast.online/install.sh -o install-owncast.sh
less install-owncast.sh
bash install-owncast.sh

La documentación del proyecto indica que no debe ejecutarse como root y que hay que inspeccionar cualquier script remoto antes de ejecutarlo. Por eso la descarga es un paso independiente más arriba. El instalador obtiene la versión actual y un binario de ffmpeg si todavía no tiene uno. Ejecute ./owncast desde el directorio de instalación y abra el panel de administración en /admin por el puerto 8080. El inicio de sesión predeterminado usa el usuario admin y la clave de transmisión predeterminada abc123 como contraseña. Cámbiela antes de apuntar un dominio al servidor.

Del diseño HLS se derivan dos consecuencias. Los espectadores tienen un retraso de algunos segundos o minutos respecto a la emisión en directo, porque HLS envía segmentos completos. Por tanto, no es posible mantener una conversación de ida y vuelta. Además, en ningún punto de la ruta se usa UDP ni TURN. Así, llega a redes donde una llamada WebRTC no puede conectarse.

Owncast también es la única herramienta de esta lista que transcodifica de forma intencionada. Cada calidad de salida que habilite implica otra codificación con ffmpeg del flujo entrante, que se ejecuta durante toda la emisión. En un VPS pequeño, ofrezca una o dos calidades. Con cinco, saturará la CPU mientras la red permanece inactiva.

Element Call en un servidor Matrix que ya administra

Si ya administra Matrix, el vídeo es una ampliación, no un segundo producto que mantener. Aun así, requiere más de un paquete. Element Call necesita dos servicios detrás de su homeserver. El primero es un SFU de LiveKit, que reenvía el tráfico multimedia. El segundo es el servicio de autorización MatrixRTC, element-hq/lk-jwt-service, que entrega al cliente la URL de WebSocket de LiveKit y un JWT firmado (JSON Web Token) para conectarse. Este servicio usa la API de federación de Matrix. Por tanto, necesita un proxy inverso TLS delante y un nombre que la federación pueda alcanzar.

Puertos documentados de LiveKit:

• TCP 7880 para la API y el WebSocket del cliente, detrás de un proxy que termine TLS
• TCP 7881 para ICE sobre TCP, cuando un cliente no puede salir mediante UDP
• UDP 50000 a 60000 para el tráfico multimedia; cada participante de una sala usa dos puertos
• UDP 3478 y TCP 5349 si habilita el servidor TURN integrado; 5349 debe cambiarse a 443 salvo que haya un balanceador delante

Dos puertos por participante pueden parecer preocupantes, pero no lo son. Un rango de 10,000 puertos cubre a miles de participantes, y su enlace de salida se saturará mucho antes de agotar el rango. Abra todo el rango de todos modos. Un rango abierto sólo parcialmente falla para algunas personas y funciona para otras. Ese es el tipo de fallo más difícil de depurar. La parte de este servicio correspondiente al homeserver requiere una configuración independiente, descrita en administrar un homeserver de Synapse en un VPS.

¿Por qué una persona nunca puede conectarse? TURN y las redes que bloquean UDP

Primero, algunos términos que se usan una sola vez. ICE (interactive connectivity establishment) es el proceso que utilizan dos endpoints WebRTC para encontrar una ruta funcional entre ellos. STUN (session traversal utilities for NAT) es un servicio pequeño que indica a un cliente cómo se ve su propia dirección pública desde el exterior. TURN (traversal using relays around NAT) es un relay: cuando no existe una ruta directa, ambos extremos envían sus medios al servidor TURN y este los reenvía.

Necesita TURN para los participantes cuyas redes no puede controlar. Uno puede estar en una red corporativa o universitaria donde se bloquea por completo el tráfico UDP saliente. Otro puede estar detrás de un NAT de nivel de operador que asigna un puerto de origen diferente para cada destino. Esto se denomina NAT simétrico y hace que la dirección comunicada por STUN no sea útil.

El síntoma es específico. La mayoría de las personas se une y todo funciona. Una persona ve la lista de participantes y el chat, pero sólo obtiene un recuadro negro y un indicador de carga. Su navegador recopiló candidatos, ninguno de los pares funcionó y ICE terminó en estado fallido. En Chrome, chrome://webrtc-internals abierta durante el intento muestra los pares de candidatos y el fallo. Pida a esa persona que vuelva a intentarlo desde un teléfono conectado a datos móviles. Si allí funciona, la causa es su red y TURN es la solución.

TURN sobre TCP en 443 o 5349 es la alternativa que funciona en casi todas partes, porque una red que bloquea TLS en 443 también ha bloqueado la web. El paquete de Jitsi instala y configura coturn automáticamente. Por eso sus reglas de firewall documentadas incluyen UDP 3478 y TCP 5349. Galène incorpora TURN en el puerto 1194. LiveKit incluye un servidor TURN integrado que se activa en la configuración. Si ejecuta coturn por su cuenta:

sudo apt install -y coturn
sudo systemctl enable --now coturn

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_STRING
realm=turn.example.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
min-port=49152
max-port=65535
no-multicast-peers

Esas opciones se configuran en /etc/turnserver.conf. En Debian y Ubuntu, el paquete inicia coturn en cuanto se instala, con la versión predeterminada de ese archivo. Por eso enable --now, ejecutado arriba, lo encuentra ya en ejecución y no cambia nada. La configuración se aplica cuando ejecuta sudo systemctl restart coturn. Cada edición posterior del archivo requiere el mismo reinicio. Las guías antiguas también indican establecer TURNSERVER_ENABLED=1 en /etc/default/coturn. Sólo el script de inicio antiguo lee esa opción. La unidad de systemd que ejecutan los paquetes actuales no la utiliza. Por tanto, esa línea no cambia nada y un coturn que nunca se haya reiniciado sigue utilizando el archivo predeterminado.

Ahora, el coste que casi nadie documenta. Un relay transporta todos los medios de cada participante retransmitido en ambas direcciones. Cuando coturn comparte equipo con el SFU, la mayor parte de ese tráfico pasa por loopback y consume CPU en lugar de ancho de banda de subida. Además, el listener TLS cifra cada paquete una segunda vez, encima de DTLS, que ya transporta los medios. Si mueve TURN a otra máquina, esa máquina necesita su propio plan de ancho de banda, dimensionado de la misma forma que el del SFU. TURN sobre TCP convierte los medios en tiempo real en un flujo fiable. Por eso un paquete perdido se retransmite en lugar de omitirse, y un participante retransmitido en un enlace con pérdidas acumula retraso en vez de sufrir una interrupción breve. El relay es una alternativa para conseguir la conexión, con una calidad inferior a la que habría ofrecido la ruta directa.

¿Cuándo transcodifica el SFU y qué coste tiene?

Un SFU reenvía paquetes y nunca decodifica vídeo. Por eso, cuatro núcleos pueden atender una sala que, sobre el papel, parece imposible. Dos funciones rompen esta propiedad. Ambas suelen sorprender a quienes las activan mediante una casilla de verificación.

La primera es la grabación. Jitsi graba con Jibri, y su propia documentación describe exactamente lo que hace: inicia una instancia de Chrome renderizada en un framebuffer virtual y captura y codifica la salida con ffmpeg. Esto implica renderizar toda la reunión en un navegador completo y ejecutar además un codificador de vídeo durante toda la llamada. La misma documentación indica que un solo Jibri admite una única grabación simultánea y que está pensado para ejecutarse en una máquina o máquina virtual independiente, sin otras aplicaciones que utilicen los dispositivos de pantalla o audio. La grabación requiere un segundo servidor, no una casilla de verificación.

La segunda es el acceso telefónico. Conectar una línea telefónica a una conferencia implica convertir Opus a 48 kHz al formato que acepta la red telefónica, normalmente G.711 a 8 kHz, en ambas direcciones y durante toda la llamada. La transcodificación de audio consume muchos menos recursos que la de vídeo, pero se ejecuta por cada tramo de llamada y nunca se pausa. Por tanto, el coste aumenta con el número de participantes que llaman. Si quiere un número de acceso telefónico, un servidor VoIP autohospedado es el componente que realiza ese trabajo y debe ejecutarse en un servidor independiente por la misma razón que Jibri.

¿Qué tamaño de servidor necesita realmente?

Para dos personas, casi ninguno. Jitsi activa el modo peer-to-peer de forma predeterminada cuando hay exactamente dos participantes. En ese modo, la conferencia deja de enviar datos a través del videobridge y usa la conexión directa. La incorporación de una tercera persona vuelve a cambiar al bridge. Por eso, un VPS de 1 GB que ejecute Jitsi funciona bien como servidor para llamadas entre dos personas, pero funciona mal con cuatro. Esta es la razón por la que «funcionó cuando lo probé» aparece con tanta frecuencia en los informes.

Para un máximo aproximado de diez personas con las cámaras activadas, 67.2 Mbps con ocho participantes se mantiene dentro de lo que puede sostener la conexión ascendente de un VPS normal. Dos CPU virtuales y 4 GB permiten ejecutar Jitsi o Galène con ese tamaño, siempre que no esté grabando. Supervise el contador de transferencia en lugar del gráfico de CPU.

Para treinta personas, el peor caso es 1,044 Mbps sostenidos, y veinte horas de ese tráfico equivalen a 9.4 TB. Este es el tamaño en el que debe calcular primero el coste del ancho de banda y después el del servidor. Active last-N para que el bridge reenvíe sólo a los últimos oradores, establezca las cámaras desactivadas como valor predeterminado para los asistentes y coloque el SFU en un proveedor con una cuota de transferencia que soporte ese cálculo.

Por encima de ese tamaño, un solo VPS no es una arquitectura adecuada. El evento puede ser realmente una transmisión, en cuyo caso Owncast más una CDN cuesta una fracción de esto. La otra opción es utilizar más de un videobridge detrás de una sola capa de señalización. Ese es un proyecto distinto del que inició.

Queda un último aspecto de enrutamiento. La mayoría de los equipos necesita el chat durante muchas más horas al día que el vídeo. Además, el chat es barato de alojar y fácil de mantener en ejecución. Implementar una alternativa autoalojada a Slack para el tráfico diario y reservar el servidor de conferencias para las llamadas programadas es la configuración que se ajusta a un presupuesto reducido de VPS.

FAQ

¿Por qué las personas pueden unirse a mi reunión de Jitsi, pero no pueden verse ni oírse?

El chat y la lista de participantes viajan por el canal de señalización, que usa TCP en 443, mientras que el audio y el vídeo usan UDP 10000 para llegar al videobridge. Si la lista de participantes se completa y todos los recuadros permanecen en negro, la ruta multimedia está interrumpida, pero la ruta de señalización funciona. Compruebe UDP 10000 en ambos firewalls: el del servidor y el firewall de red independiente del panel de control del proveedor. Después, compruebe que el bridge conozca su dirección pública: en una máquina virtual con una dirección privada y otra pública asignada, añada una asignación estática en ice4j.harvest.mapping dentro de /etc/jitsi/videobridge/jvb.conf y reinicie jitsi-videobridge2. Ejecutar sudo tcpdump -ni any udp port 10000 mientras alguien se une permite saber cuál de los dos problemas existe, porque la ausencia total de paquetes indica que el bloqueo está aguas arriba del sistema operativo.

¿Cuánto ancho de banda consume una videollamada de 30 personas?

En el peor caso, cuando todos tienen la cámara activada y el SFU reenvía una capa de calidad completa a cada participante, salen del servidor aproximadamente 1,044 Mbps, es decir, 469.8 GB por hora. Es un cálculo basado en N veces (N menos 1) flujos de 1.2 Mbps cada uno, no una medición de su instalación. El simulcast y un ajuste last-N reducen mucho este consumo en condiciones normales, porque la mayoría de los participantes no aparece en pantalla en un momento determinado. Aun así, dimensione el sistema para algo cercano al peor caso, ya que ese caso se produce en una reunión general cuando todos activan la cámara a la vez.

¿Puedo ejecutar Jitsi Meet en un VPS de 1 GB?

Se instalará y una llamada de dos personas funcionará, en parte porque Jitsi usa el modo peer to peer con exactamente dos participantes y omite por completo el videobridge. No es un servidor útil para llamadas de grupo. Prosody, el videobridge y el entorno de ejecución de Java necesitan memoria; la recomendación del propio manual es 8 GB para una implementación seria, y el cálculo del ancho de banda será un problema antes que la memoria. Si dispone de un servidor de 1 GB, Galène se adapta mejor a ese tamaño que Jitsi.

¿Sigo necesitando un servidor TURN si mi VPS tiene una dirección IP pública?

Sí. El problema que resuelve TURN se encuentra en el otro extremo de la llamada. Un participante en una red corporativa que bloquea el tráfico UDP saliente, o detrás de un NAT de nivel de operador que asigna un puerto de origen diferente para cada destino, no puede crear una ruta multimedia directa, por muy pública que sea la dirección del servidor. TURN sobre TCP en 443 o 5349 les proporciona un relay que el firewall identifica como tráfico web normal. La instalación del paquete de Jitsi configura coturn para este fin de forma predeterminada. Por eso, las reglas de firewall documentadas abren UDP 3478 y TCP 5349.

¿Por qué BigBlueButton necesita mucho más hardware que Jitsi Meet?

Porque hace mucho más que reenviar vídeo. Su requisito de producción publicado es de 16 GB de RAM y 8 núcleos, frente a 8 GB y 4 núcleos en el manual de Jitsi. BigBlueButton ejecuta una pila completa de conferencias de audio, una pizarra compartida y una capa de presentaciones, una canalización de grabación y posprocesamiento, y un frontend web con cuentas de usuario, todo en la misma máquina. También impone requisitos concretos sobre la plataforma: en agosto de 2026, la instalación compatible es la versión 3.0 en Ubuntu 22.04. Ambas cifras proceden de la documentación de cada proyecto y sirven como punto de partida, no como mediciones de su carga de trabajo.