Todas las comparativas de software de videoconferencia open source son la misma lista de funciones. Salas, pantalla compartida, chat, pizarra, grabación. Todas las tienen.
Nada de eso decide nada.
Lo que decide es cómo el software mueve el vídeo entre las personas, y te comprometes con eso en el momento en que eliges una plataforma. Si te equivocas, ninguna configuración posterior te salva. Por eso esto está escrito desde el lado del servidor: siete plataformas que puedes alojar tú mismo, qué le hace cada una a tu factura de ancho de banda, cuánto de una máquina espera quedarse y hasta dónde llega cada una.
La versión corta
Ir a una sección
Por qué la arquitectura lo decide todo
Hay tres formas de llevar el vídeo de una persona a varias. Todo lo que sigue es una variación de una de ellas.
Peer to peer conecta a cada persona directamente con todas las demás. Tres personas, tres conexiones. Ocho personas, veintiocho conexiones, y cada una está subiendo siete copias de su propia cámara. Perfecto para una llamada uno a uno. Deja de funcionar hacia los cuatro participantes con una conexión doméstica normal. Jami es la única herramienta de la lista que funciona así a propósito.
Un SFU, una unidad de reenvío selectivo (selective forwarding unit), pone un servidor en medio. Tú subes un flujo, el servidor lo copia a todos los demás y nada se decodifica ni se recodifica por el camino.
Esa última parte es todo el truco. Reenviar cuesta poca CPU y mucho ancho de banda, así que una instancia modesta sostiene una sala más grande de lo que imaginarías mientras tu tráfico de salida crece sin hacer ruido. Jitsi Videobridge, mediasoup, Janus y LiveKit son todos SFU, y entre ellos son el motor que hay dentro de casi todo lo de este artículo.
Un MCU decodifica cada flujo entrante, los mezcla en una sola imagen y devuelve un único flujo. Amable con el ancho de banda de los clientes, brutal con la CPU del servidor. Ha caído en gran medida en desuso para la conferencia general y nada de lo que aparece aquí usa uno por defecto.
Por eso "cuánta gente aguanta" es una pregunta sobre el servidor de medios, no sobre el logotipo. Nuestra explicación de la arquitectura WebRTC analiza a fondo las compensaciones, y cómo está construido Jitsi muestra qué aspecto tiene un despliegue SFU cuando ya es real.
Los siete servidores
Jitsi Meet
Apache 2.0, y lo más parecido que tiene este campo a una respuesta por defecto.
Son cuatro servicios, no uno: un frontend web, Prosody para la señalización XMPP, Jicofo para gestionar las conferencias y el videobridge que es el que mueve los medios. Con los paquetes Debian lo tienes funcionando en Ubuntu en unos quince minutos, y la guía de inicio rápido del manual de Jitsi es la versión que conviene seguir. La pila con Docker Compose es mejor camino si prefieres no entregarle todo el host.
Lo bueno: no exige cuentas, funciona en cualquier navegador y se integra limpiamente en otros productos con la API de iframe. Lo malo: un videobridge no es un plan de escalado. Por defecto, Jicofo pasa una conferencia a otro puente hacia los ochenta participantes, así que una reunión realmente grande significa varios puentes con retransmisión entre ellos. Escribimos sobre cómo llegar a mil usuarios y sobre el mismo problema en Kubernetes.
Una cosa que conviene saber antes de tu primera instalación. Los medios salen por UDP 10000, y ese puerto tiene que llegar directamente al puente. Cuando no aparece el vídeo, comprueba eso primero, antes de ponerte a leer registros o a cambiar la configuración. Es el motivo más común de que una instalación nueva tenga audio para dos personas y silencio para tres.
BigBlueButton
LGPL, y hecho para enseñar más que para reuniones. No es un posicionamiento, se nota en el producto: una pizarra compartida sobre diapositivas subidas, salas para grupos, encuestas, notas compartidas, una cola para levantar la mano y una grabación que reproduce la sesión en lugar de darte un archivo de vídeo. Habla LTI, así que Moodle y Canvas se conectan directamente. mediasoup se encarga de los medios, y la documentación de BigBlueButton es inusualmente buena para un proyecto de este tamaño. Si un servidor deja de bastar, explicamos la configuración con varios servidores en cómo escalar BigBlueButton en AWS.
La instalación es un solo script, y es de verdad la primera puesta en marcha más fácil de todo lo de la lista.
Con una condición. Espera un servidor Ubuntu limpio y dedicado, y el proyecto lo indica como requisito, no como sugerencia. Cuenta con dedicarle la máquina entera.
¿Lo comparas directamente con Jitsi? Lo hicimos en una comparación aparte.
Nextcloud Talk
AGPL, forma parte de Nextcloud, y ese es todo el argumento a su favor. Las llamadas viven junto a tus archivos, así que puedes iniciar una desde un documento y compartir ese documento dentro de ella sin salir de la página. Si tu organización ya usa Nextcloud, añadir Talk es casi gratis.
La escala es donde la gente se tropieza. De fábrica, Talk usa la señalización propia de Nextcloud, que sirve para unas pocas personas y nada más. Pasado ese punto necesitas el High Performance Backend, que es un servidor de señalización independiente con Janus detrás. Es de código abierto y la documentación de administración de Talk lo cubre. También es un segundo despliegue con sus propios requisitos, y casi todas las quejas sobre la calidad de las llamadas de Talk acaban en alguien que nunca lo instaló.
¿Primero tienes que montar Nextcloud? Nuestra guía de despliegue de Nextcloud cubre esa mitad.
plugNmeet
De código abierto, construido sobre LiveKit y orientado a un trabajo distinto al del resto de la lista. Parte de que ya tienes una aplicación y quieres conferencias dentro de ella. Primero va la API, y la interfaz es simplemente un consumidor más de esa API, al revés de como están diseñadas las demás. Existen integraciones con Moodle y WordPress, y la documentación de plugNmeet empieza por la API y no por la interfaz, lo que te dice qué tipo de proyecto es.
Es la elección correcta cuando metes llamadas dentro de un producto tuyo y quieres que las salas, los permisos y el ciclo de vida los maneje tu propio backend. Es la equivocada si lo que quieres es una URL que puedas mandar a la gente.
Jami
GPL, mantenido por Savoir-faire Linux y la única entrada realmente peer to peer de la lista.
No hay servidor. Las cuentas son identidades criptográficas que viven en el dispositivo, los pares se encuentran entre sí mediante una tabla hash distribuida y los medios van directamente entre los participantes. Nada de lo que dice nadie pasa por una infraestructura que opere alguien, y eso es una afirmación distinta de "lo alojamos nosotros mismos" y conviene tratarla como tal.
El coste es la escala y la previsibilidad. El vídeo en grupo funciona, pero la velocidad de subida de cada participante es un techo, y la conectividad depende de que el paso por NAT salga bien sin ningún servidor tuyo al que recurrir. Linux, Windows, macOS, Android, iOS, todo cubierto en la documentación de Jami. Úsalo para grupos pequeños en los que la ausencia de servidor es el requisito real y no una frase bonita de folleto.
Apache OpenMeetings
Apache 2.0, Java y el veterano del grupo. Trae más superficie que la mayoría: pizarra, gestión de archivos, grabación, encuestas, un calendario de programación, LDAP. Kurento se encarga de los medios, y todo empieza en el sitio de Apache OpenMeetings.
Aun así, el desarrollo avanza despacio comparado con Jitsi o BigBlueButton, y la pila es más pesada de montar porque tienes que cuidar de Java, Kurento y una base de datos en lugar de ejecutar un solo instalador. Se gana su sitio si quieres específicamente la programación y la gestión de documentos integradas, o si tu equipo ya maneja servicios Java y esto es terreno conocido y no algo nuevo que aprender.
Element y Matrix
Element es un cliente de Matrix, un protocolo abierto y federado de comunicación en tiempo real, así que autoalojar aquí significa ejecutar un servidor doméstico (homeserver) y no un producto de conferencias. A cambio obtienes más que vídeo: mensajería cifrada, espacios, federación con otros servidores Matrix y llamadas construidas sobre un SFU de LiveKit. Empieza por la documentación de Matrix y no por Element, porque el protocolo es a lo que te comprometes.
Es el despliegue más pesado del artículo. Herramienta equivocada si solo necesitas videoconferencia. Herramienta correcta si estás reemplazando Slack y Zoom en el mismo proyecto y la mensajería es lo principal.
Conviene decir también que Element dejó de llamarse Riot en 2020. Cualquier documentación que aún use el nombre antiguo tiene seis años de retraso, así que contrástala con la documentación actual antes de seguirla.
Comparación lado a lado
| Plataforma | Licencia | Arquitectura de medios | Vía de instalación | Tamaño de sala cómodo | Mejor encaje |
|---|---|---|---|---|---|
| Jitsi Meet | Apache 2.0 | SFU (Jitsi Videobridge) | Paquetes Debian o Docker Compose | Decenas por puente, centenas con varios | Salas de uso general, integración |
| BigBlueButton | LGPL | SFU (mediasoup) | Script de instalación, servidor dedicado | Tamaño de aula, decenas de cámaras activas | Enseñanza y formación |
| Nextcloud Talk | AGPL | SFU (Janus, mediante el HPB) | Aplicación de Nextcloud, más HPB para escalar | Pequeño sin HPB, decenas con él | Equipos que ya usan Nextcloud |
| plugNmeet | Código abierto | SFU (LiveKit) | Docker, manejado con tus propias llamadas a la API | Decenas, LiveKit escala más | Conferencias dentro de tu propio producto |
| Jami | GPL | Peer to peer, sin servidor | Solo aplicaciones de escritorio y móviles | Un puñado | Grupos pequeños, máxima privacidad |
| Apache OpenMeetings | Apache 2.0 | Servidor de medios Kurento | Java, Kurento y una base de datos | Pequeño a mediano | Programación y documentos integrados |
| Element / Matrix | Apache 2.0 | SFU (LiveKit) sobre Matrix | Homeserver, cliente y SFU | Decenas | Primero mensajería, con llamadas incluidas |
Cuánto cuesta mantener un software de videoconferencia open source
La licencia es gratis. El servidor no, y la factura no tiene la forma que la mayoría espera.
El ancho de banda se agota antes que la CPU. Un SFU reenvía en lugar de transcodificar, así que cada participante extra te cuesta tráfico de salida mucho más rápido de lo que te cuesta procesador. Diez personas con la cámara encendida significan que el servidor recibe diez flujos y envía noventa. Esa curva es cuadrática, y por eso una sala de cincuenta no es cinco veces una sala de diez. Simulcast y reenviar solo a las personas a las que se está mirando en ese momento suavizan el efecto. Ninguno cambia la forma. Para poner cifras a tus propias salas, prueba la calculadora de ancho de banda de videollamadas.
También necesitas TURN. Una parte de tus usuarios está detrás de un NAT simétrico o de un cortafuegos corporativo que bloquea los puertos UDP que quiere WebRTC, y para ellos la llamada no se degrada, falla del todo. Coturn es la respuesta estándar. Es un servicio aparte, y los medios retransmitidos lo cruzan en ambos sentidos, así que tiene un coste de ancho de banda propio y real. Los conceptos están en STUN, TURN e ICE, la configuración en cómo configurar un servidor TURN para Jitsi Meet y, una vez en marcha, el probador ICE de WebRTC te muestra si de verdad entrega candidatos de retransmisión.
Luego están los puertos, que es donde los despliegues mueren de verdad. La señalización es HTTPS normal por el 443 y no le da problemas a nadie. Los medios quieren UDP y no atravesarán un proxy inverso normal. Ese desajuste está detrás de la mayoría de los reportes de "funciona con dos personas, falla con tres" que encontrarás en los foros, y conviene leer qué puertos necesita abiertos Jitsi Meet antes de la instalación y no después.
Para ver tamaños de instancia y cifras mensuales según el tamaño de sala, lo desglosamos aparte en cuánto cuesta realmente autoalojar Jitsi Meet.
Si estás construyendo, no desplegando
Mucha gente que busca software de servidor de videoconferencia no quiere una plataforma terminada. Quiere la capa de medios y piensa construir la interfaz ella misma. Ninguna de las siete anteriores es la respuesta para eso, y lo que hay que mirar es un nivel más abajo:
- LiveKit. SFU con licencia Apache 2.0 y SDK de cliente para web, móvil y lenguajes de servidor. Es el backend de medios dentro de plugNmeet y de Element Call, y eso dice más de su madurez que cualquier página de funciones.
- mediasoup. Una biblioteca SFU para Node.js, no una aplicación. De bajo nivel, bien documentada y sobre la que funciona BigBlueButton.
- Janus. Construido en torno a plugins, así que atiende pasarelas SIP y retransmisión además de conferencias. Es el SFU que hay detrás del backend de alto rendimiento de Nextcloud Talk.
- Jitsi Videobridge por sí solo, sin el resto de la pila, si quieres quedarte con el puente y escribir tu propia señalización a su alrededor.
Los comparamos como es debido en servidores de medios WebRTC de código abierto, que es el mejor punto de partida si estás construyendo y no desplegando.
Cómo elegir
Cuatro preguntas te llevan allí más rápido que cualquier matriz de funciones.
¿Qué tamaño tiene la sala más grande que de verdad vas a usar? No la más grande que puedas imaginar. Con menos de cinco personas, peer to peer es viable y Jami se vuelve interesante. Hasta unas pocas decenas, cualquier SFU de aquí hace el trabajo. Pasados los cien, estás diseñando un despliegue con varios puentes, y eso apunta a Jitsi, que tiene el camino más trillado para ello.
¿Es una reunión o una clase? Si tu respuesta incluye diapositivas, levantar la mano, grupos de trabajo y asistencia, BigBlueButton se hizo exactamente para eso y todo lo demás es una imitación.
¿Tiene que vivir dentro de otra cosa? Integrarlo en tu propio producto apunta a plugNmeet o a la API de iframe de Jitsi. Añadir llamadas a un Nextcloud existente apunta a Talk. Reemplazar a la vez tu plataforma de chat apunta a Matrix.
Y luego la que casi todos se saltan. ¿Quién se encarga de esto el día malo? Autoalojar no es una instalación, son las renovaciones de TLS, las actualizaciones de versión, la capacidad cuando la reunión general de toda la empresa cae sobre un solo puente y alguien localizable cuando una llamada se corta durante algo importante. Si nadie se hace cargo de eso, paga un plan alojado. Es una decisión de ingeniería legítima, no una rendición.
Para la mayoría de los equipos que hacen la pregunta general, la respuesta es Jitsi Meet. Licencia permisiva, un camino de despliegue muy recorrido, una salida cuando un puente se queda corto y mucho más conocimiento operativo por escrito que cualquier otra cosa de aquí para el momento en que algo se rompe a una hora incómoda. Las demás ganan en lo concreto. Esos casos concretos son reales. Pero siguen siendo casos concretos.
Preguntas frecuentes
¿Qué es un servidor de videoconferencia de código abierto?
Es la parte de servidor de un sistema de videollamadas que alojas tú mismo en lugar de alquilarlo a Zoom o Google. En la práctica es un servidor de medios que recibe el audio y el vídeo de cada participante y lo reenvía a todos los demás, más una capa de señalización que decide quién está en qué sala. Como el código es abierto, puedes leerlo, modificarlo y ejecutarlo en tu propio hardware sin licencia por usuario.
¿Cuántos participantes aguanta un servidor de videoconferencia autoalojado?
Depende mucho más de la arquitectura de medios que de la marca del software. Una herramienta peer to peer como Jami se maneja bien con unas pocas personas. Un SFU como Jitsi Videobridge o mediasoup soporta decenas por sala en una sola máquina, y por defecto Jicofo pasa una conferencia de Jitsi a otro puente hacia los 80 participantes. Pasadas unas pocas centenas, ya tienes varios puentes con retransmisión entre ellos, y eso es una cuestión de diseño del despliegue, no un ajuste.
¿Necesito también un servidor TURN?
Casi siempre, sí. Una minoría de tus usuarios estará detrás de un NAT simétrico o de un cortafuegos corporativo que bloquea los puertos UDP que quiere WebRTC, y para ellos los medios tienen que retransmitirse por TURN o la llamada simplemente no se conecta. Coturn es la opción estándar y es un servicio aparte que alojas junto al servidor de videoconferencia.
¿Sale realmente más barato autoalojar la videoconferencia que usar Zoom?
Elimina las licencias por usuario, y de ahí viene el ahorro, pero lo sustituye por el coste del servidor, el del ancho de banda y tu propio tiempo de operación. Para un equipo pequeño, las cuentas suelen favorecer un plan alojado. Para unos cientos de usuarios habituales, o para quien necesita que los medios se queden en su propia infraestructura por motivos de cumplimiento normativo, lo habitual es que gane el autoalojamiento.
¿Qué servidor de videoconferencia de código abierto es el más fácil de instalar?
BigBlueButton, si aceptas su condición. Su script de instalación monta toda la pila de una vez, pero espera un servidor dedicado y limpio, y no le gusta compartir. Jitsi Meet es el más fácil de encajar en un entorno existente, porque con Docker Compose levantas los cuatro servicios sin adueñarte del host.
¿Puedo integrar una de estas herramientas en mi propia aplicación?
Sí. Jitsi Meet tiene una API de iframe que mete una conferencia completa en una página con unas pocas líneas de JavaScript, y plugNmeet está pensado desde el principio para que lo maneje una aplicación externa a través de su API. Si quieres construir tú mismo la interfaz en lugar de incrustar la de otro, lo que buscas es una biblioteca SFU como LiveKit o mediasoup, no una plataforma terminada.
¿La videoconferencia de código abierto admite cifrado de extremo a extremo?
Parte de ella sí, con matices. Jitsi Meet ofrece E2EE mediante flujos insertables del navegador, lo que exige navegadores compatibles y desactiva todo lo que necesite que el servidor vea los medios, incluida la grabación. Jami cifra de extremo a extremo por diseño, porque no hay ningún servidor en medio. Matrix y Element tratan el cifrado como una función de primer nivel. Todo lo demás cifra en tránsito, pero descifra en el servidor.
Jitsi Meet en AWS, ya configurado
Una imagen de Jitsi Meet lista para producción, con la red del videobridge, TLS y TURN ya resueltos, si quieres el resultado autoalojado sin pasar una semana con los puertos.
Consigue Jitsi Meet en AWS Marketplace
