Alojar Jitsi en su propio VPS

Los servicios de videoconferencia de consumo (Zoom, Google Meet, Teams) imponen límites de duración en los planes gratuitos, cuotas de participantes, y conservan sus grabaciones en sus propios servidores. Jitsi Meet, autoalojado, elimina estas restricciones: salas sin límite, duración sin límite, ninguna cuenta requerida para unirse a una reunión, flujos de video que permanecen en su infraestructura. Es especialmente pertinente para una organización preocupada por la confidencialidad de sus reuniones, para un despacho que trata datos sensibles, o para integrar la videoconferencia en una aplicación de terceros (Jitsi ofrece una API iframe estable). El coste de funcionamiento se reduce a la factura del VPS — ninguna suscripción por puesto, ningún sobrecoste de software.

Jitsi se dimensiona por el ancho de banda, no por la CPU. La documentación de Jitsi recomienda 8 GB de RAM (4 GB bastan para reuniones pequeñas), unos 4 núcleos dedicados para un servidor básico y, sobre todo, un enlace de red fiable: un flujo 720p consume unos 2,5 Mbit/s, y un enlace de 100 Mbit/s no sostiene a una veintena de participantes en alta definición. Vigile la carga de red del JVB. Tres puertos deben ser accesibles desde internet: TCP 443 (HTTPS), TCP 80 (desafío de Let's Encrypt y redirección a HTTPS), UDP 10000 (medios JVB). El puerto TCP 4443, citado por guías antiguas, ya no figura en la lista oficial. Si coturn se ejecuta en el mismo VPS, añada sus puertos: 3478 en UDP y TCP, 5349 en TLS (el 443 ya lo ocupa el contenedor web). Se necesita Docker con Compose V2 (comando docker compose), un nombre de dominio meet.sudominio.com con un registro A que apunte a la IP pública del VPS, y una IP pública dedicada y estable — una IP compartida complica seriamente la configuración de coturn.

Grabación de las reuniones. Jitsi integra Jibri para la grabación local o el streaming RTMP. Jibri captura el renderizado de un navegador en tiempo real: una instancia solo graba una reunión a la vez, y la documentación de Jitsi pide al menos 8 GB de RAM por instancia en 720p, preferiblemente en un servidor separado. Active ENABLE_RECORDING=1 en .env y arranque el contenedor Jibri incluido: docker compose -f docker-compose.yml -f jibri.yml up -d. Autenticación de los organizadores. Por defecto, cualquiera puede crear una sala: una instancia pública así configurada se convierte en videoconferencia gratuita para desconocidos, con su ancho de banda. Active ENABLE_AUTH=1, AUTH_TYPE=internal y ENABLE_GUESTS=1 para exigir una cuenta del lado del organizador dejando que los invitados se unan libremente. Cree las cuentas de anfitrión con docker compose exec prosody prosodyctl --config /run/prosody/config/prosody.cfg.lua register admin meet.jitsi <contrasena>: meet.jitsi es el dominio XMPP interno, no su nombre público, y la contraseña se genera (openssl rand -base64 18) en lugar de reutilizarse. Limitar los participantes anónimos. ENABLE_LOBBY=1 habilita la sala de espera: una vez que el moderador la activa, cada entrada debe validarse antes de acceder a la sala. Combinado con ENABLE_AUTH=1, esto da un control completo sobre quién accede a qué.

Sin sonido o video bloqueado en «connecting» — coturn + UDP 10000. Es la avería más frecuente. Compruebe en este orden: (1) ufw status — ¿están abiertos los puertos TCP 443 y UDP 10000? (2) los registros de coturn (journalctl -u coturn en nativo, docker logs <contenedor-coturn> si no) — ¿arranca coturn sin error de certificado? (3) Desde una máquina externa: curl -v telnet://meet.sudominio.com:3478 — ¿responde coturn? (4) En los logs del navegador (F12 → Consola): ¿ve ICE failed o failed to gather candidates? Si es así, coturn no es accesible desde el exterior. Compruebe que TURN_HOST y TURNS_HOST en .env resuelven a la IP real del servidor coturn. Conexión rechazada en TCP 443. Si el certificado Let's Encrypt no pudo emitirse (puerto 80 cerrado en el primer arranque), el contenedor web se detiene tras el mensaje Failed to obtain a certificate from the Let's Encrypt CA y ya nada responde en el 443. Solución: abra el puerto 80, compruebe HTTP_PORT=80 y vuelva a lanzar docker compose up -d; no hace falta borrar la configuración, y cada nuevo intento cuenta en los límites de Let's Encrypt. Compartir pantalla rechazado por el navegador. Compartir la pantalla exige un contexto seguro (HTTPS válido). Si ve getUserMedia is not supported, el certificado no es válido o el dominio no está en HTTPS. Compruebe PUBLIC_URL — debe empezar por https:// con un dominio cuyo certificado sea válido, no una IP en bruto. Error «ICE failed» persistente pese a un coturn operativo. Compruebe la variable JVB_ADVERTISE_IPS (antes DOCKER_HOST_ADDRESS): debe contener la IP pública del VPS, no la IP interna del contenedor Docker (172.17.x.x). Si su VPS está detrás de un NAT cloud (raro pero existente), necesita la IP NAT externa, no la IP de la interfaz de red.

El puente de video JVB expone una API de estadísticas en tiempo real en http://localhost:8080/colibri/stats. Este endpoint JSON informa del número de conferencias activas, participantes, ancho de banda entrante y saliente en kbit/s, y el RTT medio (rtt_aggregate). El puerto 8080 solo se publica en 127.0.0.1: manténgalo así. Para una vigilancia continua, el JVB ya expone sus métricas en formato Prometheus en /metrics (mismo puerto privado); del lado de Prosody, active PROSODY_ENABLE_METRICS=1 en .env. Conecte después una pila Prometheus + Grafana: el repositorio incluye prometheus.yml y grafana.yml, que publican los puertos 9090 y 3000 en todas las interfaces. Limítelos a 127.0.0.1 o a una VPN, porque los puertos publicados por Docker eluden las reglas de ufw.

Sin Prometheus, una vigilancia mínima se logra con un cron que consulta /colibri/stats y alerta cuando el rendimiento supera un umbral: curl -s http://127.0.0.1:8080/colibri/stats | python3 -c "import json,sys; s=json.load(sys.stdin); print(s.get('bit_rate_download',0), s.get('bit_rate_upload',0))".

Para estimar la capacidad antes de la saturación: la capacidad de un JVB depende ante todo del enlace de red y de las resoluciones enviadas; mídala con su propia carga en lugar de fiarse de una cifra genérica. Cuando el límite se acerca, rtt_aggregate sube y la calidad percibida cae antes de que la CPU sature — esa es la señal para añadir otra instancia JVB.

Jitsi funciona en modo SFU: el puente de video (JVB) retransmite cada flujo hacia cada participante, por lo que el ancho de banda saliente crece proporcionalmente al número de participantes multiplicado por el número de flujos. Un flujo 720p pesa unos 2,5 Mbit/s según la documentación de Jitsi: multiplique por el número de flujos realmente enviados a cada participante para estimar el caudal saliente. Fije channelLastN: 5 en custom-config.js (carpeta web de la configuración) para recibir solo los N últimos videos activos para limitar los flujos del lado del cliente en las reuniones grandes, y vigile docker stats jvb para anticipar la saturación. Por encima de una veintena de participantes simultáneos regulares, despliegue varias instancias JVB en VPS distintos detrás de un único Jicofo: es la arquitectura de escalado horizontal nativa de Jitsi. Para despliegues multi-organización o multidominio, tenga en cuenta que una instalación docker-jitsi-meet solo tiene una PUBLIC_URL: si cada organización necesita sus propias cuentas y un espacio de salas aislado, prevea una instancia por organización, en su propio subdominio.