Agregar servidores Jitsi Videobridge (JVB) es la forma habitual de aumentar la capacidad multimedia en una implementación de Jitsi Meet. Mantenga los servicios web, Prosody y Jicofo en el host de Meet existente y, a continuación, agregue máquinas puente independientes que se registren en la misma sala de detección de puentes de Prosody. Jicofo podrá entonces ubicar las nuevas conferencias en un puente disponible. En este diseño básico, los participantes de una conferencia utilizan un puente seleccionado; no necesita Octo solo porque la implementación tenga varios servidores JVB.
Esta guía sigue la configuración escalable basada en paquetes para Debian/Ubuntu del Manual de Jitsi, revisada el 6 de octubre de 2026. Las dependencias exactas de los paquetes y la configuración generada pueden variar según la distribución, la versión del paquete Jitsi y si el servidor se instaló con Docker u otro método. Utilice la guía de instalación oficial correspondiente a su implementación actual.
Entienda qué significa “multiservidor” en Jitsi.
Verificado: Una única instalación de Jitsi Meet puede usar varios Videobridges. Jicofo supervisa los puentes y asigna una nueva conferencia a uno de ellos. El ejemplo simplificado del Manual de Jitsi ubica los servicios de Meet en un servidor y tres JVB en servidores separados. Cada puente debe ser accesible para los participantes de la reunión en cuanto a contenido multimedia y para la infraestructura de Meet en cuanto a señalización.
Error común: «Necesito un balanceador de carga delante de los JVB». En el diseño multibridge documentado, Jicofo selecciona un puente; los clientes envían el contenido multimedia a ese puente. Un balanceador de carga HTTP genérico delante del contenido multimedia UDP no sustituye la detección de puentes ni la asignación de conferencias. Acción: Añada cada JVB al grupo de puentes de Prosody/Jicofo y publique su dirección IP pública (VIP) accesible. No dirija el tráfico multimedia de todos los puentes a una única IP virtual UDP arbitraria.
Error común: «Más puentes permiten que una reunión se conecte automáticamente a todos los servidores». En la configuración básica, Jicofo asigna una conferencia a un puente. Distribuir a los participantes de una conferencia entre regiones o puentes es una topología de retransmisión independiente llamada Octo (retransmisiones seguras en la documentación actual de JVB). Recomendación: Comience con la agrupación de puentes convencional si su objetivo es tener más reuniones simultáneas; investigue Octo solo cuando una conferencia deba usar puentes en varias ubicaciones o necesite esa funcionalidad de retransmisión.
Planifique la piscina del puente antes de instalarla.
Elija un nombre de host o dirección pública y estable para cada JVB. Asigne a cada máquina virtual una identidad de sistema operativo única y un alias de instancia JVB único cuando la configuración utilice la presencia de XMPP MUC. Todos los puentes deben poder acceder al mismo servicio Prosody y sala de servidores de puentes. Mantenga las versiones alineadas: Jicofo no mezclará puentes con versiones diferentes en la misma conferencia, y la documentación actual de relés reitera esta restricción para Octo.
| Camino | Úsalo cuando | Lo que añade |
|---|
| Múltiples JVB, una región | Necesitas mayor capacidad para celebrar reuniones simultáneas por separado. | Instalación, registro, acceso a la red y validación del puente. |
| El sistema Octo realiza relevos en todas las regiones. | Una conferencia necesita participantes o enlaces con los medios de comunicación en más de una región. | Configuración de identidad y región del relé, conectividad WebSocket de Colibri, estrategia de Jicofo e información correcta de la región del cliente. |
Depende de tu entorno: No existe un número universal de participantes por máquina virtual. La documentación de requisitos de Jitsi prioriza la capacidad de la red y la carga de trabajo sobre un único valor fijo. El códec, la resolución, la transmisión simultánea, la velocidad de paquetes, las conferencias concurrentes y el ancho de banda del proveedor influyen en la capacidad. Acción: Establece una base de referencia para tu carga de trabajo real, luego agrega un puente a la vez y observa el uso de la CPU, el rendimiento de la red, la pérdida de paquetes y la calidad de la conferencia.
Configurar varios servidores JVB paso a paso
1. Confirma que el anfitrión de Meet existente esté en buen estado.
Antes de agregar máquinas, verifique que la página de Meet existente se cargue correctamente, que Prosody y Jicofo estén en funcionamiento y que una llamada de prueba se complete a través del puente actual. Registre las versiones de los paquetes de Jitsi. Una configuración defectuosa de señalización o certificados en el servidor principal hará que un nuevo puente parezca mal configurado, incluso cuando su red funcione correctamente.
En una instalación de paquetes Debian/Ubuntu, inspeccione los servicios systemctl status prosody jicofo jitsi-videobridge2y revise los registros de servicio. Utilice los nombres de servicio presentes en su instalación; las implementaciones en contenedores exponen comandos y ubicaciones de registro diferentes.
2. Preparar las reglas de DNS, enrutamiento y firewall.
Asigne a cada puente su propia dirección pública o una asignación NAT uno a uno correctamente configurada. La guía de configuración escalable enumera estas rutas típicas: los clientes públicos acceden al servidor web mediante TCP 80/443; los servidores JVB acceden a Prosody mediante TCP 5222; y los clientes acceden a cada Videobridge mediante UDP 10000 para la transmisión de contenido multimedia. Generalmente, se utiliza TCP 80 para la configuración de certificados o redirecciones, mientras que un sitio Meet de producción debe usar HTTPS.
- Permita el tráfico UDP entrante 10000 a cada puente desde las redes participantes que admita su servicio.
- Permita el puente TCP 5222 hacia Prosody desde los hosts JVB y restrinja su uso a esos hosts cuando su firewall lo permita.
- En la medida de lo posible, mantenga el servicio Prosody/XMPP privado dentro de la infraestructura prevista.
- No exponga públicamente los puntos finales HTTP/de depuración privados de JVB. Si habilita o configura un proxy para un punto final WebSocket público de Colibri, siga la documentación vigente de JVB y del proxy inverso para esa implementación específica.
Depende de su red: NAT, grupos de seguridad en la nube, IPv6, TURN y redes corporativas restrictivas pueden requerir candidatos o rutas adicionales. La lista de puertos predeterminada no garantiza que el tráfico multimedia funcione correctamente a través de su firewall. Acción: Verifique el flujo de paquetes hacia cada dirección de puente público desde una red cliente externa y realice una llamada de prueba; una conexión XMPP exitosa por sí sola no verifica el tráfico multimedia UDP.
3. Instale el mismo paquete Jitsi Videobridge en cada nodo.
Utilice el repositorio Jitsi y las instrucciones del paquete que coincidan con la distribución del host de Meet. En cada nuevo nodo Debian/Ubuntu, instale jitsi-videobridge2el paquete y responda a las indicaciones de configuración con el nombre de host de Meet, tal como se indica en la configuración escalable oficial. El manual indica que, para su configuración documentada basada en paquetes, el puente no requiere ningún cambio adicional más allá de la configuración predeterminada después de la instalación.
No instale una segunda instancia completa de Jitsi Meet en cada puente, a menos que desee implementaciones de Meet independientes. Para un grupo de puentes, mantenga los roles web, Prosody y Jicofo en el host principal y agregue los servicios JVB a las demás máquinas. Utilice la misma versión de JVB compatible en todo el grupo; realice las actualizaciones por etapas para evitar que un grupo con versiones mixtas permanezca más tiempo del necesario.
4. Verificar el registro del puente y la identidad.
En la configuración basada en paquetes, primero deje que la configuración oficial del paquete genere los ajustes esperados. Los JVB deben conectarse a Prosody y anunciar la presencia del puente al mismo MUC de cervecería que Jicofo supervisa. Si está utilizando la ruta de configuración actual del cliente XMPP, la documentación de JVB muestra las partes relevantes en videobridge.statsy videobridge.apis.xmpp-client.configs; Jicofo debe unirse a la cervecería correspondiente usando jicofo.bridge.brewery-jid.
Una configuración moderna típica tiene esta forma; reemplace todos los valores de ejemplo con valores de su instalación y proteja el secreto compartido:
videobridge {
stats {
enabled = true
transports = [{ type = "muc" }]
}
apis {
xmpp-client {
configs {
xmpp-server-1 {
hostname = "meet.example.com"
domain = "auth.meet.example.com"
username = "jvb"
password = "REPLACE_WITH_SECRET"
muc_jids = "JvbBrewery@internal.auth.meet.example.com"
muc_nickname = "bridge-01"
}
}
}
}
}
Utilice uno diferente muc_nicknameen cada puente (por ejemplo, bridge-02y bridge-03). El proyecto JVB advierte que los alias deben ser únicos en todas las instancias. El nombre exacto del archivo de configuración y si se necesita este bloque explícito dependen de su paquete y configuración existente; evite superponer una configuración moderna escrita manualmente sobre la configuración generada de paquetes heredados sin consultar la documentación de la versión instalada.
5. Inicie el servicio y revise los registros.
Reinicia o inicia JVB en cada nuevo host y comprueba que permanezca activo y se conecte a Prosody. La guía de configuración escalable recomienda revisar los registros de Prosody y Jicofo para confirmar las conexiones de puente y que Jicofo las detecte. Si no aparece ninguna, comprueba en este orden: resolución DNS y accesibilidad TCP 5222; credenciales XMPP y dominio; ortografía exacta del MUC de la cervecería; apodo duplicado; y, por último, compatibilidad de versiones de JVB/Jicofo.
6. Ejecuta una prueba de medios externos en cada puente.
Inicie varias reuniones de prueba nuevas y confirme que Jicofo las distribuye entre los recursos disponibles a lo largo del tiempo. Se espera que una reunión se conecte a un puente; esto no indica que el balanceo haya fallado. Utilice la interfaz de depuración de Jicofo, si está habilitada y con acceso restringido, para inspeccionar los puentes disponibles y las conferencias activas. La documentación de JVB proporciona curl http://localhost:8888/debugun ejemplo de depuración local; configure interfaces de diagnóstico de enlace o firewall para que permanezcan privadas.
Realice pruebas con clientes fuera de la red del servidor. Confirme que el audio y el video funcionan, luego inspeccione la dirección del puente seleccionado y el flujo UDP. Si un puente aparece en Jicofo, pero las llamadas fallan solo cuando se selecciona dicho puente, investigue su dirección pública, la asignación NAT, el firewall UDP y los candidatos anunciados. Mantenga un puente fuera de rotación durante el mantenimiento únicamente mediante un procedimiento de drenaje o implementación compatible con su versión instalada; reiniciar un puente activo puede interrumpir las reuniones asignadas a él.
¿Cuándo deberías activar Octo?
Octo es el tema adecuado cuando una sola conferencia debe usar varios puentes, a menudo porque los participantes están distribuidos en distintas regiones. No es un requisito previo para agregar JVB para la capacidad habitual. La documentación actual de retransmisión de JVB requiere la configuración de retransmisión en cada puente participante, Colibri WebSockets para las conexiones entre puentes y una estrategia de selección de puentes Jicofo adecuada. El comportamiento con reconocimiento de región también depende de proporcionar información precisa sobre la región del cliente a la configuración de Meet.
Una configuración de relé incluye un identificador único relay-idy una región para cada puente, mientras que Jicofo habilita Octo y selecciona una estrategia como RegionBasedBridgeSelectionStrategy. Los puntos finales de WebSocket del relé también deben enrutarse correctamente a través de cualquier proxy. Estos ajustes varían según las versiones y las topologías, por lo que se recomienda seguir la guía de relé actual y validar las rutas exactas del proxy antes del despliegue.
Acción: Deje Octo desactivado para un grupo de puentes simple de una sola región. Si necesita un grupo de puentes multirregión, pruebe la estrategia de división documentada en un entorno de prueba, inspeccione el selector de puentes y el estado de la conferencia de Jicofo, y luego configure las regiones de los clientes y la selección basada en regiones. No establezca etiquetas de región hasta que sepa cómo los clientes recibirán los metadatos de región correspondientes.
Qué monitorizar a medida que creces
- Red: rendimiento de entrada y salida, pérdida de paquetes, fluctuación y si el puerto UDP 10000 es accesible desde redes de clientes reales.
- Presión del host: CPU, memoria, estado de la JVM y tasa de paquetes sostenida. Tamaño con reuniones representativas en lugar de un recuento de llamadas universal asumido.
- Miembros del pool: presencia del puente en Jicofo, consistencia de la versión y si las conferencias recién creadas pueden llegar a todos los nodos.
- Experiencia del participante: continuidad del audio, congelamiento del vídeo, reconexiones y calidad bajo el pico de concurrencia previsto.
Si los usuarios reportan problemas solo en un JVB, compare la ruta de red y la configuración de ese nodo con las de un nodo que funcione correctamente antes de aumentar todo el clúster. Si todos los puentes se degradan simultáneamente, el cuello de botella podría ser el ancho de banda compartido, los servicios de señalización principales o la red de participantes. El escalado funciona cuando los nuevos puentes son accesibles de forma independiente, están registrados correctamente y reducen la carga de manera significativa durante pruebas realistas.
Referencias oficiales