Archivo de la etiqueta: webrtc

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 (III, Autenticación de asistentes con LDAP)

12 respuestas

Posiblemente uno de los motivos de mayor peso para instalar una instancia propia de Jitsi Meet es poder controlar/limitar quien accede a ella. Veremos en este artículo como requerir autenticación a los usuarios que se conectan usando LDAP para ello.

Autenticación de usuarios con LDAP (PAM, SQL, …)

Existen varias alternativas para la autenticación de usuarios con LDAP: mod_auth_ldap, mod_auth_ldap2 y el elegido por Jitsi en su paquetería: cyrus. Cyrus es una implementación del estándar SASL que abstrae el servicio de autenticación (LDAP en este caso) del consumidor del mismo (Prosody), por lo que en realidad usando SASL podríamos usar cualquier tipo de «backend» para validar usuarios (PAM, SQL,…). Los cambios necesarios en la configuración de nuestro VirtualHost principal (EXAMPLE.NET) serían:

Donde dice:
  authentication = "anonymous"

Dirá:
  authentication = "cyrus"
  cyrus_application_name = "xmpp"
  allow_unencrypted_plain_auth = true

Además añadiremos está línea en el bloque "modules_enabled":
  "auth_cyrus";

La opción cyrus_application_name indicará la configuración a usar por saslauthd para autenticar los usuarios. Mientras que la opción allow_unencrypted_plain_auth = true permite un mecanismo de autenticación inseguro (claves en claro) que sospecho es necesaria para dar soporte al cliente (javascript) de Jitsi Meet que no soporta otros mecanismos SASL como CRAM-MD5 o GSSAPI. Si configurasteis c2s_require_encryption = true, no debería ser un problema. En otro caso podrían viajar contraseñas en claro entre el servidor web y Prosody.

Lo siguiente será configurar saslauthd para prestar servicio a Prosody. Para ello instalaremos los siguientes paquetes (o sus correspondientes en distribuciones no Debian):

apt install sasl2-bin libsasl2-modules-ldap lua-cyrussasl

En el fichero de configuración de arranque de saslauthd (/etc/default/saslauthd) activaremos el arranque y configuraremos LDAP como «backend» para la autenticación:

START=yes
MECHANISMS="ldap"

Luego editaremos la configuración LDAP del saslauthd (/etc/saslauthd.conf). Por ejemplo para usar Autenticación Simple (conectar con el servidor LDAP usando las credenciales proporcionadas por el cliente):

ldap_servers: ldaps://IP_O_NOMBRE_SERVIDOR_LDAP/
ldap_search_base: ou=people,dc=EXAMPLE,dc=NET
ldap_filter: (uid=%u)
ldap_version: 3
ldap_auth_method: bind

Por último crearemos el fichero de configuración SASL para el servicio xmpp, el nombre de este fichero debe coincidir con el especificado en Prosody como cyrus_application_name. En este caso será /etc/sasl/xmpp.conf y su contenido será:

pwcheck_method: saslauthd
mech_list: PLAIN

Además debemos añadir al usuario prosody en el grupo sasl para que tenga acceso al socket de comunicación con el demonio saslauthd (en /run/saslauthd/):

# adduser prosody sasl

Después de editar todos estos ficheros será necesario reiniciar tanto Prosody como saslauthd:

# systemctl restart saslauthd
# systemctl restart prosody

Antes de seguir, os recomiendo que probéis al menos el funcionamiento de saslauthd para que en caso de problemas de autenticación podamos descartar esa parte. Un simple comando valdrá:

# testsaslauthd -u USUARIO -p CLAVE -f /var/run/saslauthd/mux

Sí, lo sé… contraseñas en línea de comando. No hay nada perfecto. Si pasamos la prueba, podemos seguir con la configuración.

Desde este momento, todos los usuarios tendrán que autenticarse para unirse a una conferencia. Pero es posible que también deseemos que usuarios anónimos se unan (a una sala creada), dejando la autenticación como requisito para crear una sala nueva y dar privilegios de moderador.

Dejar unirse, como invitados, a usuarios no autenticados (Secure Domain)

Tendremos hacer unos cambios en Jitsi Meet, Prosody y Jicofo para que los usuarios anónimos entren bajo un Virtualhost diferente en Prosody. Empezando por Prosody, añadiremos lo siguiente a nuestro fichero de configuración:

VirtualHost "invitados.EXAMPLE.NET"
  authentication = "anonymous"
  c2s_require_encryption = false

Como vemos, en este Virtualhost no hay autenticación. Luego habrá que informar a Jitsi Meet de este dominio para los usuarios que no se autentican. En su fichero de configuración (/etc/jitsi/meet/EXAMPLE.NET-config.js):

# Descomentar la siguiente línea:
anonymousdomain: 'invitados.EXAMPLE.NET',

Por último habrá que decirte a Jicofo (encargado de la creación de salas) que sólo los usuarios de nuestro dominio con autenticación pueden crear salas/ser moderadores. En /etc/jitsi/jicofo/sip-communicator.properties:

# Añadir la línea
org.jitsi.jicofo.auth.URL=XMPP:EXAMPLE.NET

No olvidéis reiniciar Prosody y Jicofo después de todos estos cambios. En próximas entregas hablaré de la configuración del resto de componentes y de la autenticación con tokens, que permite una integración con aplicaciones de terceros como Moodle.
$ exit