1 Doc de transcripción

1.1 1. Qué es Videocan

Videocan es una plataforma de vídeo que dota de videocanal a un contact center basado en OmniSuite. Permite que una interacción que entra como chat a través de OpenChannel se convierta, en la práctica, en una videollamada de audio y vídeo entre un usuario externo y un agente.

La idea central es sencilla: la llamada no es una llamada de audio tradicional (no interviene Asterisk en ningún punto). El usuario y el agente acaban entrando en la misma sala de videoconferencia (hoy basada en Jitsi Meet, comercialmente "Vybite Meet"), y todo el control de cola, enrutado y atención del agente se apoya en la infraestructura existente de OmniSuite vía OpenChannel.

Puntos clave del alcance funcional actual:

Solo hay audio y vídeo. No hay compartición de pantalla.
El chat está desactivado: si se quisiera, debería salir por OpenChannel, no por Meet, así que de momento no se usa.
Sustituye a la solución anterior basada en Vydao, que se ha reemplazado por Meet.

1.1.1 Contexto: qué es un OpenChannel

OpenChannel es el mecanismo de OmniSuite para meter un canal de chat dentro del contact center. Lo que se inicia es, técnicamente, una interacción de chat que se encola, hereda todos los procesos típicos de OmniSuite (colas, prioridades, asignación) y acaba siendo atendida por un agente. Videocan se apoya en ese canal de chat para transportar al agente el enlace de la videollamada.

1.2 2. Flujo funcional

1.2.1 2.1. Llamada entrante (usuario → agente)

Un usuario, desde una aplicación web, un navegador o una app móvil (que internamente abre una página web), introduce una serie de datos y pulsa "Iniciar videollamada".
Ese evento desencadena dos cosas en paralelo:
- Lado usuario: se le crea una sala de Meet y queda en la pantalla de espera de la sala ("esperando conexión").
- Lado OmniSuite: se genera una interacción de chat por OpenChannel que se encola y llega a un agente.
El agente (logueado en OmniSuite con sus canales) recibe el aviso de interacción en cola. Al aceptarla se le abre una pestaña tipo chat con un mensaje del estilo "Nueva llamada de [Nombre], pulsa aquí para unirte" y una URL.
Esa URL no es una URL de Meet: es una URL del API de agente de Videocan (lleva get, agente, api-key, etc.). El agente la pulsa.
Videocan, a partir de esa URL, autentica al agente como moderador en Meet mediante JWT y lo introduce en la sala (la misma del usuario).
Se establece la videollamada. El usuario, que estaba esperando, ve entrar al agente y comienza la comunicación (audio + vídeo vía Meet).

Detalle de seguridad relevante: el agente no conoce el nombre de la sala. En la URL que recibe va "encholado" (codificado) tanto el JWT como el nombre de sala, de modo que esa URL solo sirve para entrarn en esa sala concreta.

1.2.2 2.2. Llamada saliente / "nueva sala" (agente → usuario)

La llamada saliente asume que ya existe un canal de comunicación con el destinatario. El mecanismo es deliberadamente simple:

El agente dispone de un plugin / botón ("compartir enlace") que genera una nueva sala.
Videocan crea el nombre de la sala al vuelo (aleatorio) — la sala la crea Videocan, no Meet directamente.
Videocan genera un JWT firmado para esa sala y construye una página web que mete al agente ya autenticado como moderador.
El agente copia el enlace de la reunión y lo envía al destinatario por el canal que corresponda (p. ej. WhatsApp, el propio canal por el que se estuviera hablando).
Cualquiera que abra ese enlace entra en la sala. Si lo abren varios, entran varios.

El API de agente está filtrado por IP: solo se puede invocar desde dentro (IP privada) o desde una IP fija conocida (p. ej. la salida del entorno del cliente), según el despliegue.

1.2.3 2.3. Cierre de la llamada

La interacción de OpenChannel debería cerrarse al colgar la videollamada (se cuelga "como se cuelga una llamada"). En la demo se observó que en ocasiones el agente tuvo que cerrarla a mano en OpenChannel; queda como punto a confirmar con el equipo experto en OmniSuite si el cierre debe ser automático o manual. Como red de seguridad existen timeouts (ver §6) para liberar el canal aunque algo quede colgado.

1.3 3. Arquitectura y componentes

Todo el módulo se despliega en una máquina virtual independiente (separada de la de OpenChannel/OmniSuite), sobre Debian 13, y requiere una IP pública dedicada (puede estar NATeada 1:1). El puerto de RTP de Meet usa esa IP pública.

Conceptualmente es una instalación de Vybite Meet (Jitsi) personalizada más el demonio propio Videocan. Componentes:

Componente	Función
Nginx	Proxy inverso y servidor de contenido. Punto de entrada HTTPS (443/TCP). Publica los tres APIs de Videocan.
Certbot	Generación y renovación automática de certificados TLS (Let's Encrypt). Solo en instalaciones públicas; en instalaciones internas no se instala.
Prosody	Servidor XMPP (programado en Lua) sobre el que se apoya Meet. Equivalente moderno al antiguo OpenFire.
Módulo Prosody propio ("mod")	Módulo desarrollado a medida que engancha con Videocan; informa de entradas y salidas de la sala para mantener sincronizado OpenChannel con el estado real de Meet.
Jitsi Meet + Jicofo + JVB	Pila de videoconferencia. JVB = Jitsi Video Bridge (puente de medios). Se instala mediante una lista de paquetes homologados.
Videocan (demonio)	Demonio propio. Es el "cerebro": expone los APIs, controla canales/llamadas, construye plantillas, gestiona la autenticación del agente y aplica la firma de licencia.
Fail2ban	Seguridad (bloqueo por intentos).
nftables	Cortafuegos (sustituto de iptables).
Zabbix	Monitorización. No reside en esta máquina, pero puede consultarse vía interfaz `nc` (especialmente para vigilar congestiones).

No hay MySQL ni base de datos en esta máquina. Tampoco hay LDAP en este entorno. Toda la configuración del módulo vive en un único fichero (ver §6).

1.3.1 3.1. Los tres APIs del demonio Videocan

A través de Nginx, Videocan expone tres APIs:

API de cliente (usuario): lo invoca la aplicación del usuario para iniciar la videollamada.
API de agente: devuelve al agente la URL que lo autentica como moderador. Filtrable por IP.
API hacia Prosody: la usa el módulo de Prosody para notificar eventos de sala (conexión/desconexión, destrucción de sala). Es la "flecha vertical" del diagrama.

Ejemplo de evento observado en el log al destruirse una sala:

POST Prosody v_room_destroy

Con estos eventos Videocan mantiene sincronizados los canales con lo que existe realmente en Meet. No debería crearse ninguna sala sin que intervenga Videocan.

1.3.2 3.2. Protocolos (leyenda del diagrama)

Color de flecha	Protocolo
Azul	HTTP / HTTPS (incluye el API REST)
Naranja	XMPP y BOSH (BOSH = encapsulación de XMPP sobre HTTP)
Verde	RTP (audio y vídeo), por 10000/UDP en el lado de Meet

El 10000/UDP coincide con el rango que usa Asterisk (10000–20000/UDP), pero no hay conflicto porque nunca conviven un Asterisk y un Meet en la misma máquina. Ese puerto debe abrirse en el firewall sobre la IP pública del módulo.

1.4 4. Modelo de autenticación y seguridad

El modelo es deliberadamente "sin usuarios":

No hay usuarios, ni contraseñas, ni LDAP, ni inventario de usuarios en ningún punto.
Igual que en Meet estándar, la seguridad se basa en conocer (o no) las URLs / el nombre de sala. Quien conoce el nombre de una sala abierta, entra.
Moderador (agente): entra autenticado mediante JWT. El mero hecho de conocer la URL de agente (un "churro" largo que en teoría solo conoce el agente que coge la llamada) implica ser agente. Esa URL lleva el JWT y el nombre de sala codificados, y solo sirve para esa sala.
Invitados: cualquiera que conozca el nombre de la sala puede entrar sin autenticar.
Si un agente reenvía su URL a otra persona, esa persona también entraría como moderador. Si dos agentes pinchan la URL que circula por OpenChannel, ambos entran en la misma sala.

1.4.1 Diferencias frente a un Vybite Meet estándar

Son básicamente dos:

Autenticación del moderador. En Vybite Meet estándar el moderador se valida contra LDAP o contra la base de datos de usuarios de Vybite. En Videocan, el moderador (agente) se autentica vía JWT generado al vuelo por Videocan, sin LDAP ni base de datos.
Carteles (textos/idiomas de la interfaz). Se sustituyen para que no aparezca la palabra "Jitsi" sino "Vybite", y para corregir las traducciones al castellano.

Conclusión operativa: un Vybite Meet existente de un cliente no sirve para dar este servicio. Serían máquinas e instalaciones distintas (por los carteles, las personalizaciones y la IP pública). Solo en un caso muy forzado podría plantearse compartir máquina usando dos dominios distintos sobre una misma IP pública. Como norma general: no.

1.5 5. Control de canales

Un canal = una llamada. El servicio se factura por canales simultáneos.
Videocan lleva un control del número de canales en uso y aplica una limitación de canales concurrentes (videocan_canales_maximo). Si se alcanza el máximo, las nuevas llamadas entran con congestión.
Los "hilos" del demonio (p. ej. 2) son para atender peticiones web y no guardan relación con el número de canales; con pocos hilos basta porque no hay tanto tráfico web.
Diagnóstico en caliente mediante el socket de control:

nc localhost 1132

Muestra, entre otras cosas, los canales activos (canales_...) y el contador de alarmas (las alarmas suelen deberse a temas de logs).

1.6 6. Configuración: videocan.conf

La configuración del módulo está centralizada en un único fichero en formato libconfig, ubicado dentro del árbol /etc/mdtel/ (en la máquina de desarrollo mostrada aparecía también como /etc/mdtel-videocan.conf; la convención estándar es /etc/mdtel/videocan.conf).

Para facilitar el despliegue existe un configurador (cuestionario) que el centro de servicios debe rellenar antes de arrancar una instalación y entregar cumplimentado.

1.6.1 6.1. Parámetros globales

Parámetro	Descripción
host (nombre DNS)	El más crítico. Es el nombre de dominio completo (FQDN), p. ej. `labmeetvideo.mednova.local`. Aparece en multitud de sitios, incluso en nombres de fichero. Es la razón por la que se instala de cero en cada despliegue (ver §8).
openchannel_apikey	API key de OpenChannel/OmniSuite. Por su tamaño no cabe como cadena en libconfig, así que se guarda en un fichero aparte y el programa lo carga. Ruta: `/etc/mdtel/apikey_openchannel.txt`. La proporciona el equipo de OmniSuite.
videocan_canales_maximo	Número de canales (llamadas) concurrentes soportados.
Filtro IP del API de agente	Restringe desde qué IP/máscara se puede invocar el API de agente (p. ej. `172.25.x.x`). A `0` queda abierto.
Dominios y certificados	Indica si se trabaja con certificados; debe resolverse antes de instalar.
firma	Firma electrónica de la licencia (ver §9). En un fichero base va vacía.

1.6.2 6.2. Parámetros por servicio

Los servicios son, en la práctica, los OpenChannels (conceptualmente equivalentes a VDNs): los distintos "puntos de entrada" temáticos. Por cada servicio se configura:

Parámetro	Descripción
Nombre interno	Identificador intrascendente (1, 2, 3…).
Nombre a mostrar	Nombre descriptivo que ve el cliente por defecto como interlocutor (p. ej. "Antonio"). Hay APIs para que cada agente salga con el suyo.
token de servicio	Token que el usuario (no el agente) debe conocer para invocar el servicio; viaja en la URL de usuario. En algún despliegue concreto (FAPS) se decidió que no viaje nada y baste la URL.
url_openchannel	URL de OpenChannel que crea el proveedor de la plataforma (Skally) para ese servicio.
Proxy / verificación TLS de OpenChannel	Si se sale por proxy y si hay que verificar el certificado de OpenChannel (si es HTTPS).
Timeout de conexión de agente (s)	Tiempo máximo que el cliente espera sin que entre el agente; al vencer se cuelga la interacción de OpenChannel (en Meet no se puede informar al cliente, así que solo se corta OpenChannel). Se baraja fijarlo en torno a 3600 s como red de seguridad y sacarlo del configurador.
Expiración del JWT de agente (s)	Tiempo que tiene el agente para entrar con el JWT (no limita la duración de la conversación). Valor mostrado: 1800 s (30 min).
Antirrebotes	Si llegan varias peticiones al mismo servicio desde la misma IP en una ventana (p. ej. 20 s), se etiquetan como rebote (doble clic) y no entran.
Timeout de liberación de sala (s)	Si una sala no se libera sola, se libera el canal a los 30 s de detectar que no hay sala. Red de seguridad heredada de antes de existir el API de Prosody; el canal liberado cuenta para los concurrentes.
Nombre por defecto	Nombre a mostrar cuando los datos entrantes no incluyen nombre.
Variables	Pares nombre/valor (ver §7). Las fijas (`$0`–`$2`) más las específicas por servicio (de `$3` en adelante).

1.6.3 6.3. Datos de entrada del usuario

La aplicación de front-end recopila los datos que quiera y los envía al invocar el inicio de videollamada. No hay un conjunto de datos fijo; pueden llegar como argumentos de un GET o como JSON, pero el API siempre trabaja con pares nombre/valor. Ejemplos:

Servicio "videollamada" (FAPS): name, lastname, id (que aquí es el móvil), correo, dni.
Servicio "emergencia 112": solo llegan latitud y longitud; al no llegar nombre, el campo nombre queda vacío.

1.7 7. Plantillas

Ubicación: /etc/mdtel-videocan/templates.

Una plantilla es la página web que Videocan devuelve cuando se invoca una URL del API (por ejemplo get_agente_nuevasala). Es una página con lógica, específica de cada llamada (no solo de cada servicio), porque el nombre de sala se genera al vuelo para cada llamada.

Las variables se marcan con $:
- $0 → host
- $1 → sala de la videollamada (creada al vuelo)
- $2 → nombre a mostrar (displayName)
- $3 → token JWT (cadena)
- de $3/siguientes en adelante → variables específicas del servicio
Videocan sustituye las variables en la plantilla y entrega la página resultante. Quien la recibe queda viendo una sala de Meet ya con el JWT aplicado, entrando autenticado.
Las plantillas usan el API de integración de Jitsi Meet (referencia pública: jitsi-meet-api-integration). No se usa un IFrame: la sala se integra directamente en la página (un IFrame "siempre es puñetero"). El JavaScript de la integración vive en las plantillas.
Permiten personalizar el aspecto: por ejemplo toolbarButtons (qué botones se muestran; hay muchos comentados/quitados), startWithAudioMuted, el botón de Full Screen (se muestra el botón, no se entra en pantalla completa automáticamente), etc.
Puede haber una plantilla por servicio, pero lo habitual es que sean compartidas porque todos los servicios ven prácticamente lo mismo. Las diferencias razonables serían pequeñas (p. ej. permitir o no grabar, activar el botón de chat) y se tocarían vía toolbarButtons.

Limitación conocida (móvil): al entrar compartiendo la URL, el usuario entra en vista de interlocutor en grande (no en cuadrícula), por lo que en el móvil no se ve a sí mismo. Es un problema relevante para lengua de signos, donde la persona necesita verse para comprobar el encuadre. Pulsando el botón de cuadrícula se soluciona, pero la intención es que la app sea transparente. El ajuste no se puede hacer por parámetros de URL; habría que resolverlo con JavaScript en la plantilla. Queda como punto abierto.

1.8 8. Instalación

El planteamiento actual es instalar siempre de cero (no entregar una imagen de máquina virtual), porque el nombre del host está en multitud de sitios (incluidos nombres de fichero) y reescribirlo en una imagen sería más complejo. Si en el futuro hubiera muchas instalaciones, podría replantearse.

1.8.1 8.1. Prerrequisitos y orden

Obtener la IP pública y darla de alta en DNS (lo hace el cliente o nosotros, según de quién sea el dominio). Sin nombre DNS no se puede instalar (se necesita para el certificado).
Instalar Nginx y Certbot, obtener el certificado y crear el firewall (nftables).
Instalar Meet mediante la lista de paquetes homologados (apt install <paquete>, uno a uno). No se instala el repositorio de Jitsi, sino paquetes concretos y homologados.
La instalación de Meet modifica la configuración de Nginx y de Prosody, así que tras instalarlo hay que reajustar ambos. (La configuración que deja Meet por defecto no sirve.) El proceso requiere iterar y reconfigurar varias veces.
Sustituir el contenido estático (ver §8.2).
Rellenar videocan.conf, instalar el demonio, configurar el JWT en Prosody y firmar (ver §9).

Detalle de apt: para instalar un .deb local hay que indicar una ruta de directorio; por eso se usa apt install ./paquete.deb (con ./). Se usa apt install en lugar de dpkg -i porque resuelve dependencias.

Existe un punto intermedio de validación muy útil: cuando todo funciona sin autenticación, cualquiera que conozca el nombre de sala entra directamente. Si host/pepito permite que varios se conecten a la sala "pepito" sin autenticar, la instalación base está correcta. A partir de ahí se valida el resto tirando de logs y de la herramienta jitsi-debug (sección Health).

1.8.2 8.2. Contenido estático (carteles y personalización)

Jitsi instala un directorio de contenido estático en /usr/share/jitsi-meet/…. Videocan lo reemplaza entero por uno propio (logos, fondos, textos "Vybite Meet"). Ese directorio propio es igual para todas las instalaciones (no se configura nada en él).
Los carteles (textos de interfaz) están en /usr/share/jitsi-meet/lang/:
- main.json → inglés (suele estar bien, retocado para sustituir "Jitsi" por "Vybite").
- main-es.json → castellano (~1700 carteles; las traducciones por defecto son deficientes y se corrigen).
No se recomienda modificar los DEB para empaquetar el contenido propio: como los paquetes modifican configuraciones y Meet cambia con frecuencia, no compensa.
Actualizaciones (update/upgrade): son arriesgadas porque pueden reescribir los carteles (decenas de cambios por actualización). El procedimiento de mantenimiento de carteles consiste en comparar a tres (inglés viejo, inglés nuevo, español nuevo) con una herramienta tipo Meld o el comparador de Notepad++, y trasladar los cambios manteniendo coherencia terminológica. Por eso Meet no se actualiza en cada release, sino periódicamente, y solo cuando interesa (la mayoría de novedades —integración con Drive, transcripción, traducción simultánea— no se usan). La transcripción se apoya en Vosk, que de momento da resultados pobres. Las actualizaciones por seguridad sí deberán contemplarse.

1.8.3 8.3. Instalación del demonio Videocan

Sigue el estándar de los demonios "mdtel":

Binario y módulo en /opt/videocan/bin/ (/opt/videocan/ como raíz; el módulo de Prosody también reside ahí).
Arranque en /etc/init.d/.
Configuración en /etc/mdtel/videocan.conf (más apikey_openchannel.txt en el mismo árbol).
Rotación de logs en /etc/logrotate.d/videocan.
Logs en /var/log/videocan/videocan.log (el demonio corre como usuario videocan, no como root, por estar publicado en web).

1.8.4 8.4. Instalaciones existentes (referencia)

labmeetvideo.mednova.local — instalación interna (sin Certbot, no publicada).
mdtel.videocan01.vybite.es — instalación con IP pública (en Soax), para el centro de servicios de pruebas/demos.

1.9 9. Firma de licencia y tokens

El videocan.conf debe estar protegido para que no se pueda manipular (por ejemplo, cambiar el número de canales a 2000). Esa protección es la firma electrónica, que usa el mismo procedimiento y los mismos certificados que Vybite.

1.9.1 9.1. Qué se protege

La firma cubre tres valores:

Número de servicios (no su contenido: se pueden modificar libremente, pero no crear más de los firmados).
Número de canales.
host (dominio) — para que no se pueda instalar en muchos sitios con la misma licencia.

1.9.2 9.2. Tokens

Los tokens y el JWT_SECRET hacen que cada instalación sea distinta. La herramienta de firma puede regenerarlos (claves particulares aleatorias por instalación).
El token de servicio debe coincidir con lo que conoce la aplicación de usuario del otro lado. Por eso, cuando se regeneran tokens, hay que revisar las URLs de acceso y, en su caso, tocar la página web que se entrega al cliente (p. ej. en FAPS, el token lo tenemos nosotros, así que se ajusta en la página web alojada en esta máquina).
El JWT_SECRET debe configurarse en Prosody como APP_SECRET (ver §9.4).

1.9.3 9.3. Herramienta videocan-firmar

Primer parámetro = operación a realizar:

Operación	Efecto
Generar tokens	Regenera los tokens (not firma). No requiere la clave; podría delegarse al cliente.
Firmar	Generar solo la firma.
Generar tokens y firmar	Operación recomendada para todas las instalaciones.
Verificar	Indica si la firma del fichero es válida. No requiere clave (va embebida en la herramienta).

Reglas:

Siempre se indica el fichero de configuración (no se modifica el original: la herramienta entrega otro fichero ya procesado).
Para firmar se necesita el fichero de clave privada (.key); para verificar no se necesita nada.

Ejemplos:

# Verificar
videocan-firmar verificar /etc/mdtel/videocan.conf
# → "La sección Videocan tiene un campo firma que no es correcto.
#     Error al verificar firma de videocan.conf."   (si no es válido)

# Generar tokens + firmar (recomendado)
videocan-firmar tokens-firmar mdtel.key videocan.conf
# → "Operación correcta. Se actualiza el fichero."
#   Avisos: token de servicio modificado (revisar URLs de acceso),
#           JWT_SECRET modificado (configurar APP_SECRET y reiniciar Prosody),
#           firma del archivo modificada.

Una verificación correcta enumera qué se está firmando (host, número de servicios, número de canales) y termina con un OK en la última línea:

Host labmeetvideo... ok

1.9.4 9.4. Tras firmar

Configurar APP_SECRET en Prosody con el nuevo JWT_SECRET. Configuración de Prosody en /etc/prosody/conf.avail/ (estructura similar a la de Nginx; el fichero incluye el nombre de dominio).
Reiniciar Prosody.
Revisar las URLs de acceso afectadas por el cambio de tokens de servicio.

1.9.5 9.5. Comportamiento sin firma válida ("la bomba")

Si la firma no es válida, el sistema sigue funcionando pero limitado a 1 canal (canales_max = 1). El paso a 1 canal no ocurre en el arranque, sino tras un tiempo indeterminado (diseñado así para dificultar su localización en el código). Esto permite, en la práctica, hacer demos: con el fichero sin firmar y configurado a 1 canal, todo funciona. El procedimiento habitual del cliente puede ser instalar primero (con tokens, para que arranque y se pueda probar) y entregarnos después el fichero para que lo firmemos con las licencias.

1.10 10. Diagnóstico y logs

Recurso	Uso
`nc localhost 1132`	Socket de control de Videocan: canales activos, alarmas, congestión.
`/var/log/videocan/videocan.log`	Log del demonio Videocan.
`/var/log/prosody/`	Log de Prosody.
`/var/log/nginx/`	Log de Nginx.
`/var/log/jitsi/`	Log de la pila Jitsi.
`jitsi-debug` (script)	Comprobación de salud de la instalación (sección Health).
Zabbix (vía `nc`)	Monitorización externa, especialmente de congestiones, explotando el socket `nc`.

1.11 11. Resumen de rutas y puertos

Rutas (convención estándar /etc/mdtel/):

/opt/videocan/bin/                      # demonio Videocan + módulo
/etc/init.d/videocan                    # arranque
/etc/mdtel/videocan.conf                # configuración principal (libconfig)
/etc/mdtel/apikey_openchannel.txt       # API key de OpenChannel
/etc/mdtel-videocan/templates/          # plantillas (páginas web con JS de integración Meet)
/etc/logrotate.d/videocan               # rotación de logs
/etc/prosody/conf.avail/                # configuración de Prosody (APP_SECRET)
/var/log/videocan/videocan.log          # log del demonio (usuario videocan)
/usr/share/jitsi-meet/                  # contenido estático (reemplazado por el propio)
/usr/share/jitsi-meet/lang/main.json    # carteles inglés
/usr/share/jitsi-meet/lang/main-es.json # carteles castellano (~1700)

Puertos:

443/TCP    Nginx (HTTPS, proxy inverso, APIs de Videocan)
10000/UDP  RTP de Meet (audio/vídeo) sobre la IP pública
1132       Socket de control local de Videocan (nc localhost 1132)

1.12 12. Limitaciones y puntos abiertos

Solo audio y vídeo; sin compartición de pantalla ni chat (el chat, si se activase, debería ir por OpenChannel).
Vista en móvil: el usuario no se ve a sí mismo al entrar (entra en vista de interlocutor, no en cuadrícula). Relevante para lengua de signos. Pendiente de resolver vía JavaScript en plantilla.
Cierre de la interacción OpenChannel: confirmar con el equipo de OmniSuite si debe ser automático o manual.
Transcripción (Vosk): calidad pobre; no apta de momento.
Actualizaciones de Meet: arriesgadas por los carteles; solo cuando interese o por seguridad.
Requiere IP pública dedicada por máquina (a día de hoy).
Validación de la instalación completa sobre máquina estándar de producción: pendiente de cerrar.
Un Vybite Meet de cliente no sirve para este servicio (instalaciones distintas).

2 Notas tomadas

2.1 Maquina genérica

Debian 13
nginx
certbot
prosody
No hay Mariadb/Mysql
Para montar el meet habrá un procedimiento que nos dará Antonio

2.2 Diferencias con un VIVAit Meet "standard"

Autenticación: VIVAit Meet autentica con credenciales con LDAP o BBDD VIVAit; aquí no hay LDAP ni usuarios. En la URL que llega del chat de la URL de videocan llega un Token. Con esa URL, cuando se conecta el agente, se autentica usando JWT y ya entra autenticado como moderador.
Carteles

2.3 Consideraciones de arquitectura

No se entrega máquina virtual, siempre se instalará: Por ejemplo, el nombre de host está en una cantidad de sitios tan grande que es inmanejable de otra forma.
Nodo dedicado: Siempre instalado en un nodo entero; no es compatible con Asterisk (ambos usan el puerto 10000).
Red: Requiere una IP Pública entera (puede ser Nateada).
Exclusividad: No es compatible con "otro meet" que pudiera haber en el cliente.

2.4 Desarrollos

Módulo mod en prosody
Videocan (Demonio): Proporciona APIs:
- API de conexión de cliente
- API de conexión de Agente
- API contra prosody (control de canales)
Aplicación para firmar (videoCanFirmar): Usa la clave privada habitual.
- Se le pasa un fichero videoCan.conf y devuelve otro modificado (no lo machaca).
- Puede generar firma, jwt_secret (para prosody) y tokens (para la conexión desde el lado cliente a URL de videoCan para el servicio).
Plantilla: Cuando se invoca a una URL de videocan, la página que se le devuelve es una plantilla. Personalizan aspectos "del meet", reciben parámetros, etc.
Cuando invocamos a openchannel desde videocan también existe una plantilla para "lo que le entra al agente".
Plantillas: Tienen Javascript.

2.5 Proceso de instalación

Pendiente del detalle.
Configurar prosody (seguramente solo cambiar nombre de host).
Modificar el JWT.
Reconfigurar varias veces NGINX y meet.
Puntos intermedios de prueba en los que se puede probar vídeo (sin autenticación).
Importante: Ir viendo logs en todo el proceso.

2.6 Seguridad

2.6.1 Medidas de protección

Nftables
Fail2ban: Manejamos el nginx y el mcan.
Firmas de control: Firmamos una cadena que contiene los valores que nos interesa proteger para poder tener distribución y que, por ejemplo, no nos amplíen el número de canales. Protegemos:
- Número de servicios
- Número de canales
- Host
Actualizaciones (por seguridad): update/upgrade, y cuando saquemos actualizaciones de meet o videocan.

2.7 Configuraciones

Hay un fichero guía de instalación / cuestionario a cliente.
videoCan.conf

2.8 Diagnósticos

2.8.1 Videocan

Comando de diagnóstico:

nc localhost 1132

Rutas de logs principales:

/var/log/videoCan/videoCan.log

/var/log/nginx (Típicos de nginx)

/var/log/prosody

/var/log/jitsi

Monitoreo: Zabbix (explotando el comando "nc").

Omnisuite videoCan