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 dos servicios utilizan certificados X.509 para garantizar la confidencialidad y la autenticación. La
Sección 10.2.1.1, “Infraestructura de llave pública: easy-rsa” proporciona más detalles acerca de la creación de estos certificados. De forma alternativa también puede encontrar información muy útil en la
Real-Time Communications Quick Start Guide (en inglés):
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:
; 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.
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.
11.8.2.1. Instalación de un servidor TURN
Instale el paquete resiprocate-turn-server.
Edite el archivo de configuración /etc/reTurn/reTurnServer.config. Lo más importante es configurar las direcciones IP del servidor.
# your IP addresses go here:
TurnAddress = 198.51.100.19
TurnV6Address = 2001:DB8:1000:2000::19
AltStunAddress = 198.51.100.20
# your domain goes here, it must match the value used
# to hash your passwords if they are already hashed
# using the HA1 algorithm:
AuthenticationRealm = myrealm
UserDatabaseFile = /etc/reTurn/users.txt
UserDatabaseHashedPasswords = true
Reiniciar el servicio.
11.8.2.2. Gestionar los usuarios de TURN
Utilice la herramienta htdigest para gestionar la lista de usuarios del servidor TURN.
# htdigest /etc/reTurn/users.txt myrealm joe
Después de cualquier modificación en /etc/reTurn/users.txt se debe notificar la señal HUP para que el servidor lo recargue (o también se puede autorizar la recarga automática en /etc/reTurn/reTurnServer.config).
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
Instalar el paquete repro. Se recomienda el uso del paquete desde jessie-backports, ya que cuenta con las últimas mejoras de mejora de conectividad y resiliencia.
Editar el fichero de configuración /etc/repro/repro.config. Lo más importante es poner la dirección IP del sevidor. El ejemplo de más abajo muestra cómo configurar tanto SIP como WebSockets/WebRTC, haciendo uso de TLS, IPv4 e IPv6:
# Transport1 será para SIP sobre conexiones TLS
# Aquí usamos el puerto 5061, pero si tiene clientes que se conectan desde
# lugares con firewalls puede cambiarlo para que escuche en el puerto 443
Transport1Interface = 198.51.100.19:5061
Transport1Type = TLS
Transport1TlsDomain = falcot.com
Transport1TlsClientVerification = Optional
Transport1RecordRouteUri = sip:falcot.com;transport=TLS
Transport1TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport1TlsCertificate = /etc/ssl/public/falcot.com.pem
# Transport2 es la versión IPv6 de Transport1
Transport2Interface = 2001:DB8:1000:2000::19:5061
Transport2Type = TLS
Transport2TlsDomain = falcot.com
Transport2TlsClientVerification = Optional
Transport2RecordRouteUri = sip:falcot.com;transport=TLS
Transport2TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport2TlsCertificate = /etc/ssl/public/falcot.com.pem
# Transport3 será para SIP sobre conexiones WebSocket (WebRTC)
# Aquí usamos el puerto 8443, pero puede hacer uso del 443
Transport3Interface = 198.51.100.19:8443
Transport3Type = WSS
Transport3TlsDomain = falcot.com
# Podría requerir que el navegador envíe un certificado pero, actualmente
# parece que los navegadores no pueden hacerlo, por lo que déjelo como None:
Transport3TlsClientVerification = None
Transport3RecordRouteUri = sip:falcot.com;transport=WSS
Transport3TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport3TlsCertificate = /etc/ssl/public/falcot.com.pem
# Transport4 es la versión IPv6 de Transport3
Transport4Interface = 2001:DB8:1000:2000::19:8443
Transport4Type = WSS
Transport4TlsDomain = falcot.com
Transport4TlsClientVerification = None
Transport4RecordRouteUri = sip:falcot.com;transport=WSS
Transport4TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport4TlsCertificate = /etc/ssl/public/falcot.com.pem
# Transport5: Podría ser para conexiones TCP a un servidor Asterisk
# de su red interna. No habilite el puerto 5060 a través del firewall
# externo.
Transport5Interface = 198.51.100.19:5060
Transport5Type = TCP
Transport5RecordRouteUri = sip:198.51.100.19:5060;transport=TCP
HttpBindAddress = 198.51.100.19, 2001:DB8:1000:2000::19
HttpAdminUserFile = /etc/repro/users.txt
RecordRouteUri = sip:falcot.com;transport=tls
ForceRecordRouting = true
EnumSuffixes = e164.arpa, sip5060.net, e164.org
DisableOutbound = false
EnableFlowTokens = true
EnableCertificateAuthenticator = True
Use la utilidad htdigest para gestionar la contraseña del administrador del interfaz web. El nombre del usuario debe ser admin y el realm debe coincidir con el indicado en repro.config.
# htdigest /etc/repro/users.txt repro admin
Reinicie el servicio para usar la nueva configuración.
11.8.3.2. Gestionando el proxy SIP
Vaya al interfaz web en http://sip-proxy.falcot.com:5080 para completar la configuración añadiendio dominios, usuarios locales y rutas estáticas.
El primer paso es añadir el dominio local. El proceso debe reiniciarse tras agregar o quitar dominios de la lista.
El proxy sabe cómo dirigir las llamadas entre usuarios locales y direcciones completas SIP. La configuración de redirección solo es necesaria cuando se desea modificar el comportamiento por defecto. Por ejemplo, para reconocer números de teléfono, añadir un prefijo y redirigirlos a un proveedor SIP.
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 conocido servidor de XMPP que opera de modo fiable en servidores Debian.
11.8.4.1. Instalar el servidor XMPP
Instalar el paquete prosody. Se recomienda el uso del paquete desde jessie-backports, ya que cuenta con las últimas mejoras de maximización de conectividad y resiliencia.
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.pem";
certificate = "/etc/ssl/public/falcot.com.pem";
}
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 gestion pueden realizarse haciendo uso de la utilidad de línea de comandos prosodyctl. Por ejemplo, para añadir la cuenta del administrador especificada en /etc/prosody/prosody.cfg.lua:
# prosodyctl adduser joe@falcot.com
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.
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 jessie-backports o Testing.
JSCommunicator es un teléfono WebRTC genérico que no requiere de ningun script de tipo PHP en la parte servidora. Está construido exclusivamente con HTML, CSS y JavaScript. Es la base de muchos otros servicios y módulos WebRTC empleados en frameworks web avanzados.
El modo más rápido de instalar un teléfono WebRTC en un portal web es hacer uso del paquete
jscommunicator-web-phone. Requiere un proxy SIP proxy con transporte WebSocket. Las instruccones en
Sección 11.8.3.1, “Instalación de un proxy SIP” incluyen los detalles necesarios para habilitar el transporte WebSocket en el proxy SIP
repro.
Tras instalar jscommunicator-web-phone, hay varios modos de usarlo. Una estrategia sencilla es incluir, o copiar, la configuración de /etc/jscommunicator-web-phone/apache.conf en la configuración de host virtual de Apache.
Una vez los ficheros del teléfono web están disponibles en el servidor web, personalice /etc/jscommunicator-web-phone/config.js para que apunte al servidor TURN y al proxy SIP. Por ejemplo:
JSCommSettings = {
// Entorno del servidor web
webserver: {
url_prefix: null // Si se configura, prefijo empleado para construir URLs sound/
},
// STUN/TURN media relays
stun_servers: [],
turn_servers: [
{ server:"turn:turn-server.falcot.com?transport=udp", username:"joe", password:"j0Ep455d" }
],
// Conexión WebSocket
websocket: {
// Fíjese que empleamos el certificado del dominio falcot.com y el puerto 8443
// Esto coincide con los ejemplos Transport3 y Transport4 en
// el fichero repro.config para falcot.com
servers: 'wss://falcot.com:8443',
connection_recovery_min_interval: 2,
connection_recovery_max_interval: 30
},
...
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.
