Videoconferencia autohospedada en un VPS: ancho de banda

El software de videoconferencia autohospedado en un VPS tiene un problema de ancho de banda

Las videoconferencias autohospedadas fallan en los servidores pequeños por una razón, y casi nunca es la instalación. El componente del servidor que usan 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. Pero no podrá soportar la reunión general que tiene en mente.

Por tanto, siga este orden. Cuente a los participantes, calcule los megabits y después elija el servidor. La instalación requiere veinte minutos de copiar y pegar. El enlace ascendente determina si los demás podrán 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 multimedia interviene en el vídeo. Una llamada en malla entre dos personas sólo necesita un servidor de señalización. Por eso las llamadas entre dos personas casi no tienen coste de alojamiento. La malla deja de funcionar con unas cuatro o cinco personas, porque un portátil conectado a una red doméstica tiene que cargar cuatro o cinco copias separadas 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 decodificar el vídeo. Ese es todo el mecanismo. Por eso un SFU consume poca CPU y mucho ancho de banda de red.

La arquitectura anterior es un MCU (multipoint control unit). Decodifica cada flujo entrante, los combina en una sola imagen y vuelve a codificarla. El ancho de banda saliente es mínimo. El consumo de CPU es enorme. Actualmente casi ningún sistema de vídeo usa un MCU, y esta guía tampoco usa ninguno.

Ahora, la aritmética de un SFU. Supongamos que cada persona envía vídeo a 1.2 Mbps y que nadie tiene la cámara apagada. 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 tiene que recibir los otros N menos 1 flujos. Esa segunda cifra es la que hace inviables los 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. Empiece por 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 puede gestionar sin problemas. Entre la fila de cuatro personas y la de treinta personas, 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 quedan por debajo de estas cifras. Conviene saber exactamente cómo. 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 interlocutores que han hablado más recientemente. 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 en pantalla la imagen de los demás.

¿Qué te proporciona realmente el uplink 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 clientes del mismo host físico, por lo que el caudal sostenido durante una hora de alta demanda es inferior a la velocidad del puerto. Una llamada de conferencia genera precisamente una carga sostenida. La mayoría de los planes también tienen un límite mensual de transferencia. Después de superarlo, el proveedor reduce la velocidad o cobra un importe adicional.

Ese límite es lo que aparece como un importe 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. Comprueba el límite de transferencia antes que la cantidad de RAM. Si la página del plan no lo especifica claramente, esa falta de precisión ya es una respuesta. Cómo evaluar correctamente una oferta de VPS barata 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 por la que debería empezar la mayoría. Se instala desde el repositorio Debian del proyecto, configura nginx y un certificado durante la instalación, y el videobridge (JVB) usa un único puerto UDP, lo que mantiene cortas 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 elegir un 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 el proceso falla si el nombre apunta a otro lugar.

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

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 suele olvidarse. UDP 3478 y TCP 5349 pertenecen al servidor coturn que el paquete de Jitsi instala junto al bridge. Es la ruta alternativa para quienes tienen redes que bloquean UDP.

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

El primer comando debería mostrar el servicio como 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 tener presente: 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 aportan nada a 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 completa, el chat funciona y todos los mosaicos 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 asocia una dirección pública, JVB sólo encuentra la dirección privada. Por eso, todos los clientes intentan enviar el tráfico multimedia a una dirección como 10.0.0.5 y los paquetes no llegan a ningún sitio.

Indique al bridge ambas 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 configuraban 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. Siguen funcionando, pero las instalaciones nuevas deben usar el bloque de mapeo anterior.

La otra causa es un firewall que no se ha configurado. La mayoría de los proveedores ejecutan un firewall de red en el panel de control, independiente de ufw en el servidor, y UDP 10000 debe estar abierto en ambos. Para saber qué capa descarta los paquetes, ejecute sudo tcpdump -ni any udp port 10000 en el servidor mientras alguien se conecta desde el exterior. Si no llega ningún paquete, nada alcanza la máquina, por lo que el bloqueo está aguas arriba del sistema operativo. Si llegan paquetes, pero los mosaicos siguen en negro, el bridge está respondiendo con una dirección que el cliente no puede alcanzar; el problema es el mapeo. Si no está seguro de la configuración de 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 exige el servidor completo

BigBlueButton está diseñado para la enseñanza. Incluye 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 mucha diferencia, la opción más pesada de esta lista. No es un paquete que se pueda añadir a un servidor existente.

En agosto de 2026, la ruta compatible 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 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 intervalo 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 propios ejemplos del proyecto envían ese script directamente a bash. Descárguelo y léalo primero, porque reescribe la configuración de nginx, instala su propia pila multimedia y de audio, fija versiones de paquetes y reclama el nombre de host. Ese comportamiento forma parte del diseño, no es un defecto: BigBlueButton espera controlar la máquina. El indicador -w configura el firewall, -s es el nombre de host, -e es la dirección que registra Let's Encrypt 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 de su proxy inverso nginx antes de que el script la modifique.

Compare con atención 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 suponen tamaños de sala distintos. Por tanto, considérelas como el punto de partida de cada proyecto, no como una comparación directa. La diferencia de CPU es real y se debe a todo lo que hace BigBlueButton además de reenviar vídeo.

Galène: la opción sencilla

Galène es un SFU compacto escrito en Go. Se compila como 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 entorno de ejecución 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 es Go 1.22. Si go build indica que el módulo necesita una versión más reciente de Go, instale una cadena de herramientas actual desde go.dev en lugar de intentar solucionar el problema con el paquete de la distribución.

Un grupo es la forma en que Galène denomina a una sala. Cada 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 proceden directamente del README del proyecto, por lo que debe cambiarlas 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 '' deshabilita 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 ice-servers.json.

Puede colocar nginx delante de la interfaz web estableciendo proxyURL en data/config.json y configurando un proxy para 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 con el puerto TURN. Por tanto, el proxy inverso 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, pero no publica ninguna cifra concreta. Por tanto, no espere encontrar una. El cálculo del ancho de banda anterior sigue siendo plenamente aplicable. Lo que se ahorra es la memoria y los componentes adicionales de todo lo que no forma parte del SFU.

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

Muchos requisitos de «videoconferencia» consisten en realidad en que una persona presenta contenido ante una audiencia que escribe en el chat. Si ese es su caso, una SFU es la herramienta equivocada y el modelo de costes cambia por completo. Owncast recibe un flujo RTMP de OBS o de un codificador similar y sirve HLS mediante HTTPS convencional. El ancho de banda por espectador crece de forma lineal en lugar de cuadrática. Además, como la salida consta de 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 se realiza en un paso independiente más arriba. El instalador obtiene la versión actual y un binario de ffmpeg si todavía no dispone de uno. Ejecute ./owncast desde el directorio de instalación y abra el panel de administración en /admin, en el puerto 8080. El inicio de sesión predeterminado usa el usuario admin y la clave de flujo predeterminada abc123 como contraseña. Cámbiela antes de apuntar un dominio al servidor.

Del diseño de HLS se derivan dos consecuencias. Los espectadores reciben la emisión con un retraso de algunos segundos o minutos, porque HLS entrega segmentos completos. Por tanto, no permite una conversación de ida y vuelta. Además, en toda la ruta no intervienen UDP ni TURN, por lo que llega a redes en las que 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 añade otra codificación de 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 y no otro producto que operar. Aun así, requiere más de un paquete. Element Call necesita dos componentes detrás del homeserver. El primero es un SFU de LiveKit, que reenvía el tráfico multimedia. El segundo es el servicio de autorización de 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 lo que 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 termina TLS
• TCP 7881 para ICE sobre TCP, cuando un cliente no puede salir por 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; el puerto 5349 debe cambiarse a 443, salvo que haya un balanceador de carga delante

Dos puertos por participante puede parecer preocupante, pero no lo es. Un rango de 10,000 puertos cubre a miles de participantes, y su enlace de subida se agotará mucho antes que el rango. Abra de todos modos todo el rango, porque un rango abierto sólo parcialmente falla para algunas personas y funciona para otras. Este es el peor tipo de fallo para depurar. La parte de esto correspondiente al homeserver es una tarea independiente, descrita en ejecución de un homeserver 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 de 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 el tráfico UDP saliente está bloqueado por completo. 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 recibe 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 abierto durante el intento muestra los pares de candidatos y el fallo. Pida a esa persona que vuelva a intentarlo desde un teléfono con datos móviles. Si funciona allí, la causa es su red y TURN es la solución.

TURN sobre TCP en 443 o 5349 es el mecanismo alternativo 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 incluye 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

En Debian y Ubuntu, el servicio incluido en el paquete no se inicia hasta que se configura TURNSERVER_ENABLED=1 en /etc/default/coturn. Un coturn instalado pero no habilitado se ve exactamente igual desde el exterior que no tener TURN. Por eso esta línea puede costar varias horas de trabajo.

Ahora, el coste que nadie suele calcular. Un relay transporta todos los medios de cada participante retransmitido en ambas direcciones. Cuando coturn comparte un equipo con el SFU, la mayor parte de ese tráfico atraviesa loopback y consume CPU en lugar de ancho de banda de subida. Además, el listener TLS cifra cada paquete una segunda vez, por encima de DTLS, que ya protege los medios. Si mueve TURN a otro equipo, ese equipo necesita un 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 tanto, un paquete perdido se retransmite en lugar de omitirse. Un participante retransmitido mediante una conexión con pérdidas acumula latencia en lugar de sufrir un fallo breve. El relay es un mecanismo alternativo que permite conectarse, pero 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 descodifica vídeo. Por eso, cuatro núcleos pueden atender una sala que, sobre el papel, parece imposible de gestionar. Dos funciones rompen esta propiedad. Ambas suelen sorprender a quienes las activan mediante una casilla.

La primera es la grabación. Jitsi graba con Jibri, y la documentación de Jibri describe exactamente su funcionamiento: 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 con un navegador completo y ejecutar un codificador de vídeo de forma continua 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 un equipo o máquina virtual independiente, sin otras aplicaciones que utilicen los dispositivos de pantalla o audio. La grabación requiere un segundo servidor; no es una simple casilla.

La segunda es el acceso telefónico. Integrar una línea telefónica en 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 de forma continua durante toda la llamada. La transcodificación de audio consume muchos menos recursos que la transcodificación 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 telefónicos. Si necesita un número de acceso telefónico, un servidor VoIP autohospedado es el componente que realiza ese trabajo y debe ejecutarse en un equipo independiente por el mismo motivo que Jibri.

¿Qué tamaño de servidor necesita realmente?

Para dos personas, casi ninguno. Jitsi habilita 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 utiliza la conexión directa. La incorporación de una tercera persona vuelve a activar el bridge. Por eso, un VPS de 1 GB con Jitsi funciona bien como servidor para llamadas individuales, pero mal para llamadas de cuatro personas. Esta es la razón por la que es tan frecuente escuchar «funcionó cuando lo probé».

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. Con este tamaño, 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 el audio y vídeo de los oradores recientes, establezca las cámaras desactivadas como opción predeterminada 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 la arquitectura adecuada. El evento puede ser realmente una emisió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 única capa de señalización, lo que constituye un proyecto distinto del que empezó.

Queda un último aspecto de la arquitectura. La mayoría de los equipos necesitan 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 funcionamiento. Configurar una alternativa autohospedada a Slack para el tráfico diario y reservar el servidor de conferencias para las llamadas programadas es la disposición que funciona con un presupuesto reducido para un 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 hasta el videobridge. Si la lista de participantes se completa y todos los recuadros permanecen en negro, la ruta de medios está interrumpida, pero la 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 un mapeo estático en ice4j.harvest.mapping dentro de /etc/jitsi/videobridge/jvb.conf y reinicie jitsi-videobridge2. Ejecute sudo tcpdump -ni any udp port 10000 mientras alguien se une para saber cuál de los dos problemas existe, porque la ausencia total de paquetes indica que el bloqueo está antes del sistema operativo.

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

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

¿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 cuando hay exactamente dos participantes y omite por completo el videobridge. No es un servidor útil para llamadas grupales. Prosody, el videobridge y el runtime 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 sólo 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 está en el otro extremo de la llamada. Un participante en una red corporativa que bloquee el tráfico UDP saliente, o detrás de una NAT de nivel de operador que asigne un puerto de origen diferente para cada destino, no puede establecer una ruta de medios directa, independientemente de que la dirección del servidor sea pública. 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 sus 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 en el mismo equipo una plataforma completa de conferencias de audio, una pizarra compartida, una capa de presentaciones, un flujo de grabación y posprocesamiento, y un frontend web con cuentas de usuario. También impone requisitos específicos 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 puntos de partida, no como mediciones de su carga de trabajo.