Product SiteDocumentation Site

11.8. Servicios de comunicación en tiempo real

Los servicios de comunicación en tiempo real (Real-Time Communication, RTC) agrupan los servicios de voz sobre IP, video/webcam, mensajería instantánea (instant messaging, IM) y de compartición de escritorio. Este capítulo proporciona una breve introducción a tres servicios necesarios para una infraestructura de comunicaicón en tiempo real: un servidor TURN, un servidor SIP y un servidor XMPP. Se pueden encontrar explicaciones más extensas de cómo planificar, instalar y gestionar estos servicios en inglés en Real-Time Communications Quick Start Guide, que contiene incluso ejemplos específicos para Debian.
Tanto SIP como XMPP pueden proporcionar la misma funcionalidad. SIP es algo más conociod para la voz sobre IP y para el video, mientras que XMPP se utiliza como protocolo de mensajería instantánea. En realidad ambos pueden ser utilizados para cualquier ade estos servicios. Para optimizar las opciones de conectividad se recomienda utilizar ambos en paralelo.
Estos servicios dependen de certificados X.509 tanto para autentificación como para propósitos de confidencialidad. Consulte Sección 10.2, “Certificados X.509” para más información.

11.8.1. Parámetros DNS para los servicios RTC

Los servicios RTC requieren registros DNS SRV y NAPTR. He aquí un ejemplo de configuración que se podría incluir en el fichero de zona para falcot.com: (ver también Ejemplo 10.13, “Extracto de /etc/bind/db.falcot.com:
; the server where everything will run
server1            IN     A      198.51.100.19
server1            IN     AAAA   2001:DB8:1000:2000::19

; IPv4 only for TURN for now, some clients are buggy with IPv6
turn-server        IN     A      198.51.100.19

; IPv4 and IPv6 addresses for SIP
sip-proxy          IN     A      198.51.100.19
sip-proxy          IN     AAAA   2001:DB8:1000:2000::19

; IPv4 and IPv6 addresses for XMPP
xmpp-gw            IN     A      198.51.100.19
xmpp-gw            IN     AAAA   2001:DB8:1000:2000::19

; DNS SRV and NAPTR for STUN / TURN
_stun._udp  IN SRV    0 1 3467 turn-server.falcot.com.
_turn._udp  IN SRV    0 1 3467 turn-server.falcot.com.
@           IN NAPTR  10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.

; DNS SRV and NAPTR records for SIP
_sips._tcp  IN SRV    0 1 5061 sip-proxy.falcot.com.
@           IN NAPTR  10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.

; DNS SRV records for XMPP Server and Client modes:
_xmpp-client._tcp  IN     SRV    5 0 5222 xmpp-gw.falcot.com.
_xmpp-server._tcp  IN     SRV    5 0 5269 xmpp-gw.falcot.com.

11.8.2. Servidor TURN

TURN es un servicio que permite a los clientes que se encuentran detrás de un router o firewall con NAT encontrar el camino más eficaz para comunicarse con otros clientes y en caso de no encontrarse ningún camino directo retransmitir los flujos de voz y datos. Se recomienda vivamente instalar un servidor TURN antes de ofrecer ningún otro servicio RTC a los usuarios finales.
TURN y el protocolo ICE son estándares abiertos. Para sacar provecho de estos protocolos, maximizando la conectividad y minimizando la frustración de los usuarios, es importante asegurarse que todos los programas cliente sean compatibles.
Para que el agoritmo ICE funcione eficazmente, el servidor tiene que tener do direcciones IPv4 públicas.
Instale el paquete coturn y edite el archivo de configuración /etc/turnserver.conf . Por defecto, se configura una base de datos SQLite en /var/db/turndb para los ajustes de las cuentas de usuario, pero se pueden configurar PostgreSQL, MySQL o Redit si se prefiere. Lo más importante es insertar las direcciones IP del servidor.
El servidor se puede iniciar ejecutando turnserver del paquete coturn . Queremos que el servidor sea un servicio del sistema iniciado automáticamente. Este es el comportamiento predeterminado usandosystemd. Solo cuando se usa el SysVinit anterior, se debe editar el archivo/etc/default/coturn así:
#
# Descomente esto si quiere tener el servidor TURN
# ejecutándose como un demonio de servicio de sistema
#
TURNSERVER_ENABLED=1
Por defecto, el servidor TURN usa un acceso anónimo. Tenemos que añadir los usuarios que queremos usar:
# turnadmin -a -u roland -p secret_password -r falcot.com
# turnadmin -A -u admin -p secret_password
Usamos el argumento -a para añadir un usuario normal y -A para añadir un usuario administrador.

11.8.3. Servidor Proxy SIP

Un servidor proxy SIP gestiona las conexiones SIP entrantes y salientes entre distintas organizaciones, los proveedores de enlaces SIP (SIP trunking), las centralitas privadas (Private Automatic Branch eXchange, PBX) como Asterisk, los teléfonos y programas de telefonía SIP y las aplicaciones WebRTC.
Es altamente recomendable instalar y configurar un proxy SIP antes de intentar poner en servicio una centralita (PBX). El proxy SIP normaliza en gran medida el tráfico que llega a la centralita y proporciona una mayor conectividad y resiliencia.

11.8.3.1. Instalación de un proxy SIP

Instale el paquete kamailio y el paquete para el backend de la base de datos, los administradores de Falcot eligieron MySQL, así que instalan kamailio-mysql-modules y mariadb-server. /etc/kamailio/kamctlrc es el archivo de configuración para las herramientas de control kamctl y kamdbctl. Necesita editar y asignarle a SIP_DOMAIN su dominio de servicio SIP y asignarle a DBENGINE a MySQL, se puede usar otro backend de base de datos.
[...]
## su dominio SIP
SIP_DOMAIN=sip.falcot.com

## directorio con chroot
# $CHROOT_DIR="/path/to/chrooted/directory"

## tipo de base de datos: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT o SQLITE
# por defecto no se carga ninguna
#
# Si quiere configurar una base de datos con kamdbctl, como mínimo debe
# especificar este parámetro.
DBENGINE=MYSQL
[...]
Ahora nos centramos en el archivo de configuración /etc/kamailio/kamailio.cfg. Falcot necesita la autentificación de usuario y la ubicación de usuario persistente, así que añaden las siguientes directivas #!define en la parte superior de ese archivo:
#!KAMAILIO
#
# Kamailio (OpenSER) SIP Server v5.2 - default configuration script
#     - web: https://www.kamailio.org
#     - git: https://github.com/kamailio/kamailio
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_USRLOCDB
[...]
Kamailio necesita una estructura de base de datos que podemos crear ejecutando kamdbctl create como superusuarios. Finalmente, podemos agregar algunos usuarios con kamctl.
# kamdbctl create
[...]
# kamctl add roland secret_password
Una vez que todo esté correctamente configurado puede iniciar o reiniciar el servicio con systemctl restart kamailio, puede conectar con un cliente SIP proporcionando la dirección IP y el puerto (5090 es el puerto predeterminado). Los usuarios tienen el siguiente id: roland@sip.falcot.com, y pueden iniciar sesión utilizando un cliente (ver Sección 13.9, “Software de comunicaciones en tiempo real”)

11.8.4. Servidor XMPP

Un servidor XMPP gestiona la conectividad entre usuarios locales XMPP y usuarios XMPP en otros dominios de la red pública Internet.
prosody es un servidor XMPP popular que funciona de manera confiable en servidores Debian.

11.8.4.1. Instalar el servidor XMPP

Instale el paquete prosody.
Revisar el fichero de configuración /etc/prosody/prosody.cfg.lua. Lo más importante en agregar los JIDs de los usuarios a los que se les permite gestionar el servidor.
admins = { "joe@falcot.com" }
También se necesita un fichero de configuracion por cada dominio. Copiar el ejemplo de /etc/prosody/conf.avail/example.com.cfg.lua y usarlo como punto de partida. Este es falcot.com.cfg.lua:
VirtualHost "falcot.com"
        enabled = true
        ssl = {
                key = "/etc/ssl/private/falcot.com.key";
                certificate = "/etc/ssl/certs/falcot.com.pem";
                }

-- Set up a MUC (multi-user chat) room server on conference.example.com:
Component "conference.falcot.com" "muc"
Para activar el dominio debe haber un enlace simbólico de /etc/prosody/conf.d/. Créelo de este modo:
# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/
Reinicie el servicio para usar la nueva configuración.

11.8.4.2. Gestionando el servidor XMPP

Algunas operaciones de administración se pueden realizar mediante la utilidad de línea de comandosprosodyctl. Por ejemplo, para agregar la cuenta de administrador especificada en /etc/ prosody/prosody.cfg.lua:
# prosodyctl adduser joe@falcot.com
Para más detalles sobre cómo personalizar la configuración, vea la documentación en línea de Prosody.

11.8.5. Servicios corriendo en el puerto 443

Alguno administradores prefieren ejecutar todos sus servicios RTC en el puerto 443. Esto facilita a los usuarios conectarse desde lugares remotos, tales como hoteles y aeropuertos. Donde el resto de puertos pueden estar bloqueados o el tráfico de Internet se redirige a través de servidores proxy HTTP.
Para usar esta estrategia cada servicio (SIP, XMPP y TURN) necesita una dirección IP distinta. Todos los servicios pueden estar todavía en el mismo equipo, ya que Linux soporta múltiples IP en un solo equipo. El número de puerto, 443, debe especificarse en los ficheros de configuración de cada uno de los procesos, y también en los registros SRV del DNS.

11.8.6. Agregando WebRTC

Falcot quiere permitir a los clientes realizar llamadas telefónicas directamente desde el sitio web. Los administradores de Flacot también quieren usar WebRTC como parte de su plan de contingencia, de modo que el personal pueda hacer uso de los navegadores web desde casa y hacer uso del sistema de telefonía de la empresa y trabajar normalmente en caso de emergencia.
WebRTC es una tecnología que evoluciona rápidamente, y es esencial hacer uso de los paquetes de las distribuciones Testing. Otra opción es compilar el software.
WebRTC usa una simple API para proveer de RTC a navegadores y aplicaciones móviles, es software libre y está siendo desarrollado por Google.
Un enfoque muy flexible es el uso de la implementación WebRTC GStreamer. Permite aplicaciones multimedia basadas en tuberías, lo que permite desarrollar aplicaciones interesantes y altamente eficientes. Un buen punto de partida es la siguiente demostración de Centricular, la principal compañía que la está desarrollando: :
Portales web más avanzados de tipo click-para-llamar normalmente hacen uso de scripts en la parte de servidor para generar dinámicamente el fichero config.js. El código fuente de DruCall muestra cómo hacerlo con PHP.
Este capítulo sólo analiza una parte de todo el software de servidor disponible; sin embargo, describimos la mayoría de los servicios de red. Ahora es el momento de un capítulo aún más técnico: profundizaremos en los detalles de algunos conceptos, describiremos los despliegues masivos y la virtualización.