Archivo de la etiqueta: videoconferencia

Instalar un servidor de videoconferencia libre, Jitsi Meet (V, Configurando Videobridges)

4 respuestas

Una vez configurados Prosody y Jicofo, el siguiente elemento (y último necesario para usar Jitsi Meet) será el Videobridge. El Videobridge es un Selective Forwarding Unit (SFU), esto significa que no hace ningún tipo de procesamiento de los flujos de vídeo, simplemente recoje el vídeo de cada participante y lo hace llegar al resto. Esto se traduce en:

  • Gran uso de ancho de banda, cada señal de vídeo que llega debe ser multiplicada por el número de participantes (menos uno, su origen). Si tenemos 5 participantes con cámaras activas, pongamos a 500kbps cada flujo. Tendremos 2.5Mbps de entrada en el videobrige y casi 10Mbps de salida de éste a los clientes. Podemos limitar este tráfico a los clientes con el parámetro channelLastN en la configuración de Jitsi Meet que comentaré más adelante, aliviando la carga en los navegadores.
  • Uso comedido de RAM y CPU. Al no tener que procesar los vídeos, el uso de estos recursos no es alto. Para conferencias con menos de 30-40 participantes, y un número razonable de cámaras abiertas, 1-2 cores y 2-3GB de RAM serán suficientes. Atención: por defecto el Videobridge podría reclamar hasta 3GB de RAM. Podemos limitar esa cantidad (si tenemos menos de 4GB de RAM) usando el parámetro VIDEOBRIDGE_MAX_MEMORY=XXXXm con los megas que queramos, por defecto 3072m, en el fichero /etc/jitsi/videobridge/config.

Dicho esto, podemos correr tantos Videobridge como deseemos, lo que permite escalar en horizontal. Podemos partir de un Videobridge en la misma máquina que Prosody y Jicofo, o dejar éstos en un servidor (con muy pocos requisitos de memoria y CPU) y luego ir añadiendo máquinas con Videobridge.

Configuración de un Videobridge

Al igual que pasaba con Jicofo, tenemos dos ficheros principales de configuración para un Videobridge. De hecho, hay información redundante en ellos. El motivo es que existen varios mecanismos de comunicación (APIs) de los Videobridge con el mundo exterior. Hasta no hace mucho la conexión entre Videobridge y Prosody se hacía registrando el Videobridge como un componente (servicio) en Prosody. Hoy la preferencia es el uso de MUCs (canales). Y de ahí los rastros que van quedando por su configuración.

Empecemos por /etc/jitsi/videobridge/config, donde encontramos parámetros de arranque del proceso y configuración de XMPP como componente:

# Configuración componente XMPP
JVB_HOSTNAME=EXAMPLE.NET
JVB_HOST=MI_SERVIDOR_PROSODY
JVB_PORT=5347
JVB_SECRET=CLAVE_DE_COMPONENTE
# Opciones arranque
JVB_OPTS="--apis=,"
JAVA_SYS_PROPS=".......

El primer grupo de opciones no serían necesarias si no registramos Videobridge como componente. No hay mucho que explicar de ellas y la tendencia del proyecto es usar MUCs.

Si es digna de mención la opción JVB_OPTS. En versiones actuales lleva el valor "--apis=,", que levantará el cliente XMPP (como usuario normal, no componente) por defecto. Antiguamente era necesario especificarlo (con el valor xmpp). También podemos activar un API REST u otro llamado Colibri del que se pueden sacar estadísticas del Videobridge. Por eso es frecuente ver en documentación no muy actual el valor "--apis=rest,xmpp". Salvo que queramos el API REST activo, no es necesario modificar esta variable. Por el MUC, que ahora configuraremos, también se obtienen estadísticas del Videobridge e incluso hay un exportador para prometheus que usa este mecanismo.

El fichero en el que realmente hay que configurar Videobridge en sus versiones más modernas (videobridge2) es /etc/jitsi/videobridge/sip-communicator.properties:

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.STATISTICS_INTERVAL=5000
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=MI_SERVIDOR_PROSODY
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.EXAMPLE.NET
org.jitsi.videobridge.xmpp.user.shard.USERNAME=USUARIO_XMPP
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=CLAVE_XMPP
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=NOMBRE_DEL_JVB
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=lospuentes@internal.auth.EXAMPLE.NET
org.jitsi.videobridge.AUTHORIZED_SOURCE_REGEXP=lospuentes@internal.auth.EXAMPLE.NET/focus.*$
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

Las dos primeras opciones (DISABLE_AWS_HARVESTER y STUN_MAPPING_HARVESTER_ADDRESSES) están relacionada con el protocolo ICE desarrollado por Jitsi y que sirve para gestionar las conexiones que atraviesan NAT. La primera no es relevante salvo que tengamos el servidor en AWS y la segunda deberemos especificarla si nuestro videobridge está detrás de algún NAT (es decir, no tiene una IP pública pero se usará con clientes de fuera de su red local). El servidor especificado en este ejemplo (meet-jit-si-turnrelay.jitsi.net:443) es el que pone la configuración del paquete, pero podríamos usar uno bajo nuestro control para no depender de este servicio externo.

A continuación vienen tres opciones (ENABLE_STATISTICS, STATISTICS_TRANSPORT y STATISTICS_INTERVAL) que indican que queremos las estadísticas, y con que frecuencia (en milisegundos) por el MUC de comunicación con Jicofo. Estas, además de poder exportarse a Prometheus u otra herramienta, permiten que Jicofo tenga conocimiento de la carga en cada uno de los Videobridges permitiendo que balancee correctamente las nuevas conferencias entre ellos.

Luego tenemos toda la configuración del Videobridge como cliente XMPP. La opción HOSTNAME apuntará al servidor XMPP y podrá ser localhost si corre en la misma máquina o tener la IP o nombre de la máquina donde se encuentre Prosody. DOMAIN indica el Virtualhost de Prosody donde se autentican los elementos que conforman Jitsi Meet, normalmente auth.DOMINIO_PRINCIPAL. USERNAME y PASSWORD son las credenciales para registrarse en Prosody, recordar que hay que crear el usuario como vimos anteriormente. Varios, o todos, los videobridge pueden usar el mismo USERNAME y PASSWORD, y la opción MUC_NICKNAME permitirá diferenciarlos posteriormente. Así que podemos crear un usuario por videobridge y usar el mismo nombre como nick, o crear un sólo usuario y que cada videobridge use un nick diferente. Esto último facilitaría la configuración de nuevos videobridge (no sería necesario crear un usuario en Prosody por cada uno). MUC_JIDS indica el nombre del canal (lospuentes) y el componente de MUC (internal.auth.EXAMPLE.NET) donde se comunicaran los videobridges con Jicofo, así que atención a que sea el mismo en Jicofo y todos los videobridge. La última opción importante en esta sección es AUTHORIZED_SOURCE_REGEXP, que indica de donde puede recibir órdenes en videobridge. Cuidado con esta opción, porque una expresión regular errónea no permitiría la creación de conferencias en el videobridge. Casi toda la documentación hasta ahora ponía como ejemplo algo tipo: focus@auth.EXAMPLE.NET./.* Esta sintáxis sólo es válida si se usan componentes XMPP. Ya no es correcta con el uso de MUCs, pese a no estar muy documentado (esto es todo lo que encontré al respecto), y deberemos usar la sintaxis: lospuentes@internal.auth.EXAMPLE.NET/focus.*$, donde lospuentes es el ya sabido nombre del canal, internal.auth.EXAMPLE.NET es el nombre del componente MUC y focus es el nick de Jicofo en XMPP.

Para terminar con la configuración del cliente XMPP del videobride, la opción DISABLE_CERTIFICATE_VALIDATION, como su nombre indica, permite desactivar la validación del certificado SSL que presenta Prosody. Como ya comenté, la instalación del paquete jitsi-meet-prosody, crear unos certificados autofirmados para el dominio auth.DOMINIO_PRINCIPAL. Si no queremos copiar dichos certificados en los videbridge, y su conexión al Prosody es local, podemos usar esta opción para ahorrarnos la tarea.

Con esto terminamos la configuración del videobridge. Para probarlo por completo recomiento una conferencia con al menos tres participantes. El motivo es que con 2 participantes el videobridge «no es realmente necesario», el vídeo irá entre los participantes directamente. Sólo la entrada de un tercer usuario hará que el videbridge se ponga a trabajar de verdad. Y es en ese momento, la entrada del tercero, cuando veremos si está todo OK. Si al entrar el tercer participante las imágenes de todos quedan en negro, hay algo mal configurado. Revisad el log del Videobridge (/var/log/jitsi/jvb.log) y de Jicofo (/var/log/jitsi/jicofo.log) en busca de problemas de comunicación entre ellos. En el del videobrige deberíamos ver algo como:

2020-05-20 12:33:34.980 INFO: [20] [hostname=localhost id=shard] MucClient$MucWrapper.join#751: Joined MUC: lospuentes@internal.auth.EXAMPLE.NET
# Seguido (si habilitamos las estadísticas) de estos:
2020-05-20 12:35:54.636 INFO: [19] AbstractHealthCheckService.run#171: Performed a successful health check

En el de Jicofo, a la entrada del Videobridge, veremos:

org.jitsi.jicofo.bridge.BridgeSelector.log() Added new videobridge: Bridge[jid=lospuentes@internal.auth.EXAMPLE.NET/JVB_NICK, relayId=null, region=null, stress=0.00]

En caso de no verse esta línea «Added new videobridge«, revisa que el nombre del canal sea igual en ambos (Jicofo y videobridge) y que el videobridge se está registrando («Joined MUC«) correctamente. Si todo va correctamente, ya tienes la base. En próximas entradas hablaré del front-end web (Jitsi Meet), Jibri y los famosos tokens.

$ exit

Instalar un servidor de videoconferencia libre, Jitsi Meet (IV, Configurando Jicofo)

6 respuestas

Una vez tenemos configurado el servidor XMPP, con o sin autenticación, veamos el siguiente componente a configurar: Jicofo. Encargado de repartir las conferencias entre los videobridges disponibles, podemos decir que, junto con Prosody, Jicofo es la pieza central de la arquitectura Jitsi Meet. Además ambas son bastante ligeras y pueden correr juntas, junto con nginx y Jitsi Meet (el cliente web), en una máquina con una CPU y poco más de 1GB de RAM.

Configuración de Jitsi Conference Focus(Jicofo)

Jicofo tiene dos ficheros principales de configuración. El primero, /etc/jitsi/jicofo/config, lleva las opciones que se pasan al demonio en su ejecución (JAVA_SYS_PROP y JICOFO_OPTS) y las de autenticación de Jicofo en Prosody. Son estas últimas las que normalmente tocaremos (o tocará el paquete Debian en su instalación). Se trata de:

JICOFO_HOST=localhost
JICOFO_HOSTNAME=EXAMPLE.NET
JICOFO_SECRET=SECRETO
JICOFO_PORT=5347
JICOFO_AUTH_DOMAIN=auth.EXAMPLE.NET
JICOFO_AUTH_USER=focus
JICOFO_AUTH_PASSWORD=CLAVE

JICOFO_HOST, yo hubiera usado otro nombre para esta variable, es el servidor XMPP al que se conectará Jicofo. «localhost» será el valor de esta variable si ejecutamos Prosody en la misma máquina que Jicofo. En otro caso será el nombre o IP del servidor Prosody y, salvo que uses en Prosody un certificado SSL válido universalmente, tendrás que copiar los certificados de Prosody para tu dominio (normalmente en /var/lib/prosody/EXAMPLE.NET.crt y auth.EXAMPLE.NET.crt) al directorio /usr/local/share/ca-certificates/ del servidor con Jicofo y ejecutar update-ca-certificates en él para que sea reconocido por Jicofo.

Jicofo se registra, a día de hoy, de dos maneras en el servidor XMPP:

1.- Como un usuario normal. Cuyos datos son JICOFO_AUTH_DOMAIN, el dominio donde se registran todos los componentes (auth.EXAMPLE.NET), JICOFO_AUTH_USER y JICOFO_AUTH_PASSWORD. Estos datos, así como la creación del usuario en Prosody, suelen cumplimentarse por la instalación del paquete Debian. Si lo haces manualmente, puedes comprobar que son correctos, o crearlos como se indica, en el directorio de usuarios de Prosody. Si decidieras cambiar el nombre de usuario, «focus» por defecto, ten en cuenta que es el administrador de algunos componentes en Prosody y tendrás que corregir esa configuración.

2.- Como un «componente», un servicio dentro del propio servidor XMPP. El nombre del servicio será focus.EXAMPLE.NET (no confundir con el usuario: focus.auth.EXAMPLE.NET). Los datos de este registro son JICOFO_HOSTNAME (al que añadirá focus. para el nombre del servicio) y JICOFO_SECRET. Que deberán de coincidir con la configuración en Prosody:

Component "focus.EXAMPLE.NET"
  component_secret = "SECRETO"

El segundo de los ficheros de configuración, /etc/jitsi/jicofo/sip-communicator.properties, indica el nombre «del canal» o sala donde se reunirán los diferentes componentes (videobridges y Jibris):

org.jitsi.jicofo.BRIDGE_MUC=lospuentes@internal.auth.EXAMPLE.NET
# OPCIONALES, sólo si se usan Jibris:
org.jitsi.jicofo.jibri.BREWERY=losgrabadores@internal.auth.EXAMPLE.NET
org.jitsi.jicofo.jibri.PENDING_TIMEOUT=90

internal.auth.EXAMPLE.NET es un componente MUC (Multi-User Chat) de Prosody que ya vimos. Cuando configuremos los videobridges y Jibris, deberemos indicar estos nombres de canales en su configuración, sólo así sabrá Jicofo de su existencia.

Una nota importante. Como podréis deducir de quién se registra dónde, es importante el orden en el que se arrancan (o reinician en caso de cambios de configuración) los servicios. El primero en arrancar debe ser Prosody, seguido de Jicofo y por último el resto de componentes. De no hacerlo así se pueden sufrir comportamientos extraños.

$ exit

Instalar un servidor de videoconferencia libre, Jitsi Meet (I, la teoría)

6 respuestas

Últimamente parece que las videoconferencias se han puesto de moda, como el papel higiénico. Y si bien hay muchas alternativas, la inmensa mayoría podrían no respetar tu privacidad y algunas tienen un historial de problemas de seguridad que asusta.

Por suerte hay una alternativa plenamente funcional y libre: Jitsi Meet.

No necesitas nada para usar Jitsi Meet*

* Salvo un navegador actual o su aplicación móvil/de escritorio

Si no tienes medios (servidor, ancho de banda, ganas de complicarte la vida), puedes usar su servicio público que funciona estupendamente. Es muy sencillo, simplemente dale un nombre a tu conferencia y pasa la URL resultante (por ejemplo: https://meet.jit.si/UnPingüino) a todos los participantes que quieras invitar.

Evita, eso sí, nombres fáciles o comunes («pepe», «prueba», «test») para la conferencia o puede que entre más gente de la que esperas, ya que las conferencias en el servidor público no limitan quien entra en ellas.

Pero si lo que quieres es no depender de terceros, controlar quien puede entrar en tus conferencias, o proteger tu privacidad, puedes instalar Jitsi Meet en un servidor propio. Y a eso es a lo que hemos venido.

Las piezas del puzzle

Nada es perfecto, y si en algo peca(ba) Jitsi Meet es en su documentación. Tal era la situación que salió un proyecto paralelo sólo para documentarlo: EasyJitsi
Os recomiendo echarle un ojo para tener más información.

Lo primero que debemos hacer antes de montar Jitsi Meet es entender que piezas lo componen y para que sirven cada una de ellas.

Prosody

Aunque no es parte del proyecto Jitsi, Prosody es una de las piezas más importantes de esta arquitectura. Se trata de un servidor XMPP. O en términos más claros; un servidor de mensajería instantánea.
XMPP es un grupo de protocolos que definen y permiten todas las características esperables en un servicio de mensajería: autenticación de usuarios, conversaciones con varios participantes (rooms/canales), envío de ficheros, … Es el protocolo sobre el que se construye Google Talk / Hangouts / Chat, aunque Google decidiera no usar el estándar para interoperar con otras implementaciones XMPP. Pero tranquilos, con más de 1.500 millones de usuarios de Gmail pronto tampoco tendrá que intercambiar correo con nadie que no sean ellos y podrá inventarse las extensiones que lo mejoren y liberen de viejos estándares. ¡Hala!, ya me despaché. Sigamos…

Prosody será el encargado de autenticar al resto de componentes de Jitsi Meet y, en caso de quererlo, a los usuarios que se conecten a nuestro servicio de Meet. Además gestiona la comunicación entre componentes y usuarios. Por ejemplo permitiendo que Jicofo sepa de la existencia de videobridges y Jibris en servicio.

Jicofo (Jitsi Conferenre Focus)

Es el encargado de dirigir la orquesta. Lleva el control de los recursos, decide en que videobridge se hospeda una conferencia (en función de la carga de los disponibles) o que Jibri será el que transmitirá (a Youtube, por ejemplo) o grabará la sala que lo así solicite.

Videobride

Es el encargado de recibir y hacer llegar los flujos de audio y vídeo a los participantes de una conferencia. Aunque en una conferencia de dos personas es posible que los vídeos vayan de un a otro participante directamente, sin mediar el videobridge, en cuanto los participantes son tres o más, todos envían su señal de vídeo al videobridge, que la repite al resto de participantes.

Este funcionamiento es además característica fundamental de Jitsi Meet. Los videobridge no mezclan vídeo, según llega de un cliente sale al resto. Eso se traduce en menos latencia, al no perder tiempo procesando vídeo, a costa de un uso alto (con muchos participantes) de ancho de banda. Por ejemplo, y dependiendo de la calidad que usemos, si tenemos 10 participantes, con la cámara abierta, enviando vídeo a 3Mbps, además de estar recibiendo 30Mbps estaría sacando unos 300Mbps de tráfico.

Jibri (Jitsi BRoadcasting Infrastructure)

Permite grabar, en disco o nube, o retransmitir a Youtube (por ahora) una sesión. Está compuesto por varios componentes: el propio Jibri que se conecta con prosody para recibir las órdenes de grabación de Jicofo, un navegador Chrome que se conecta como un usuario más a la sesión que grabará, y ffmpeg que se encarga de codificar el vídeo final.

Una característica a tener en cuenta de Jibri es que una sola instancia es capaz de grabar una sola sesión. Así que si quieres grabar más de una simultáneamente necesitarás tener más de un servidor/docker con Jibri.

Un servidor web y Jitsi Meet

Jitsi Meet, propiamente dicho, sería la parte frontal de todo el invento. Es una aplicación en Javascript que estará alojada en un servidor web. En el momento que escribo esto, nginx el servidor mejor soportado por Jitsi Meet para hacer este trabajo.

Otros componentes

Opcionalmente, en las últimas versiones, se puede instalar/configurar un servidor TURN/STUN para facilitar las comunicaciones de clientes detrás de NAT. De no hacerlo se pueden usar servidores públicos, en principio sin grandes compromisos (a mi entender) salvo la dependencia en la disponibilidad del servicio.

Jigasi es la última pieza del puzzle. Este componente permite integrar Jitsi Meet con una centralita de Voz IP. Ya sea para realizar llamadas desde una conferencia en curso (Meet ordena a Jigasi llamar) o para que participantes puedan unirse a una conferencia a través de una llamada telefónica (la centralita de Voz IP dirige las llamadas a Jigasi que las hace llegar a Jitsi Meet).

En la próxima entrega entraré en más detalle sobre la configuración de cada uno de ellos. Si os corre prisa echarlo a andar podéis usar su instalación docker, pegaros con sus paquetes, o probar el «playbook» de Ansible que la Universidad a Distancia de Madrid (UDIMA) ha publicado en su Github. Y sí, puede que yo tenga algo que ver con esto último 😛