11.8. Services de communication en temps réel
Les services de communication en temps réel (
Real-Time Communication, RTC) regroupent les services de voix sur IP, de video/webcam, de messagerie instantanée (
instant messaging, IM) et de partage de bureaux. Ce chapitre introduit trois services nécessaires dans une infrastructure de communication en temps réel : un serveur TURN, un serveur SIP et un serveur XMPP. Des explications claires et détaillées de comment planifier, installer et gérer ces services sont disponibles en anglais dans le
Real-Time Communications Quick Start Guide, y compris des exemples spécifiques à Debian.
SIP et XMPP peuvent fournir les mêmes services. SIP est un peu plus connu pour la voix sur IP et la vidéo alors que XMPP est traditionnellement utilisé comme protocole de messagerie instantanée. En réalité, les deux peuvent être utilisés pour les deux services. Pour optimiser les options de connectivité, il est recommandé d'exploiter les deux en parallèle.
Ces deux services utilisent des certificats X.509 pour garantir la confidentialité et l'authentification. La
Section 10.2.1.1, « Infrastructure de clés publiques easy-rsa » donne plus de détails sur la création de ces certificats. Alternativement, on trouvera aussi des explications très utiles dans le
Real-Time Communications Quick Start Guide (en anglais) :
11.8.1. Paramètres DNS pour les services RTC
Les services RTC nécessitent des enregistrements DNS SRV et NAPTR. Voici un exemple de configuration qui peut être mis dans le fichier de zone pour falcot.com :
; le serveur où tout va fonctionner
server1 IN A 198.51.100.19
server1 IN AAAA 2001:DB8:1000:2000::19
; IPv4 seulement pour TURN pour le moment, certains clients
; ne fonctionnent pas avec IPv6
turn-server IN A 198.51.100.19
; adresses IPv4 et IPv6 pour SIP
sip-proxy IN A 198.51.100.19
sip-proxy IN AAAA 2001:DB8:1000:2000::19
; adresses IPv4 et IPv6 pour XMPP
xmpp-gw IN A 198.51.100.19
xmpp-gw IN AAAA 2001:DB8:1000:2000::19
; DNS SRV et NAPTR pour 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 et NAPTR pour SIP
_sips._tcp IN SRV 0 1 5061 sip-proxy.falcot.com.
@ IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.
; enregistrements DNS SRV pour les modes XMPP Server et Client:
_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 est un service qui aide les clients derrière des routeurs NAT et des pare-feu à trouver le chemin le plus efficace pour communiquer avec d'autres clients et pour relayer les flux media si aucun chemin direct n'est trouvé. Il est grandement recommandé d'installer le serveur TURN avant que tous les autres services RTC ne soient disponibles pour les utilisateurs finaux.
TURN et le protocole ICE sont des standards ouverts. Pour tirer profit de ces protocoles, en maximisant la connectivité et en minimisant la frustration des utilisateurs, il est important de s'assurer que tous les logiciels clients les supportent.
Pour que l'algorithme ICE fonctionne efficacement, le serveur doit avoir deux adresses publiques IPv4.
11.8.2.1. Installation du serveur TURN
Installez le paquet resiprocate-turn-server.
Éditez le fichier de configuration /etc/reTurn/reTurnServer.config. Le plus important est d'intégrer les adresses IP du serveur.
# vos addresses IP vont ici :
TurnAddress = 198.51.100.19
TurnV6Address = 2001:DB8:1000:2000::19
AltStunAddress = 198.51.100.20
# votre domaine va ici, il doit correspondre à la valeur utilisée pour
# créer vos mots de passe avec l'algorithme de hachage HA1 :
AuthenticationRealm = myrealm
UserDatabaseFile = /etc/reTurn/users.txt
UserDatabaseHashedPasswords = true
Redémarrez le service.
11.8.2.2. Gestion des utilisateurs de TURN
Utilisez l'utilitaire htdigest pour gérer la liste des utilisateurs du serveur TURN.
# htdigest /etc/reTurn/users.txt myrealm joe
Après toute modification à /etc/reTurn/users.txt, envoyez le signal HUP pour que le serveur le recharge (ou autorisez le rechargement automatique dans /etc/reTurn/reTurnServer.config).
11.8.3. Serveur Proxy SIP
Un serveur proxy SIP gère les connexions SIP entrantes et sortantes entre différentes organisations, les fournisseurs de tronc SIP (SIP trunking), les autocommutateurs téléphoniques privés (Private Automatic Branch eXchange, PBX) comme Asterisk, les téléphones SIP, les logiciels de téléphonie basés sur SIP et les applications WebRTC.
Il est fortement recommandé d'installer et de configurer le proxy SIP avant d'essayer de mettre en place un PBX (autocommutateur téléphonique privé). Le proxy SIP normalise une large partie du trafic arrivant au PBX et fournit une plus grande connectivité et une résilience plus importante.
11.8.3.1. Installation du proxy SIP
Installez le paquet repro. Utiliser le paquet de jessie-backposrts est fortement recommandé car il contient les dernières améliorations qui augmentent la connectivité et la résilience.
Éditez le fichier de configuration /etc/repro/repro.config. Le plus important est d'ajouter les adresses IP du serveur. L'exemple ci-dessous montre comment configurer à la fois le SIP normal et WebSockets/WebRTC en utilisant TLS, IPv4 et IPv6 :
# Transport1 est pour SIP sur des connexions TLS
# On utilise le port 5061 ici mais on pourrait utiliser le port
# 443 si des clients sont derrière des pare-feu trop restrictifs
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 est la version 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 est pour les connexions SIP sur WebSocket (WebRTC)
# On utilise le port 8443 ici mais on pourrait utiliser le port 443
Transport3Interface = 198.51.100.19:8443
Transport3Type = WSS
Transport3TlsDomain = falcot.com
# Ceci demanderait au navigateur d'envoyer un certificat, mais les
# navigateurs ne semblent pas bien le gérer, on le laisse donc à 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 est la version 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 : ceci pourrait être pour des connexions TCP à un serveur
# Asterisk dans le réseau interne. N'autorisez pas le port 5060
# dans le pare-feu externe.
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
Définissez le mot de passe administrateur pour l'interface web avec l'utilitaire htdigest. Le nom de l'utilisateur doit être admin et le domaine (realm) doit correspondre à la valeur spécifiée dans repro.config.
# htdigest /etc/repro/users.txt repro admin
Redémarrez le service pour utiliser la nouvelle configuration.
11.8.3.2. Gestion du proxy SIP
Visitez l'adresse http://sip-proxy.falcot.com:5080 pour compléter la configuration en ajoutant les domaines, les utilisateurs locaux et les routes statiques.
La première étape est d'ajouter le domaine local. Le processus doit être redémarré après l'ajout ou la suppression de domaines dans la liste.
Le proxy sait comment acheminer les appels entre les utilisateurs locaux et les adresses SIP complètes, la configuration du routage est uniquement nécessaire si le comportement par défaut ne convient pas ; par exemple pour reconnaître des numéros de téléphone, il faut ajouter un préfixe et les router vers un fournisseur SIP.
Un serveur XMPP gère la connectivité entre les utilisateurs XMPP locaux et les utilisateurs XMPP dans d'autres domaines de l'Internet public.
Prosody est un serveur XMPP populaire qui fonctionne bien sur les serveurs Debian.
11.8.4.1. Installation du serveur XMPP
Installez le paquet prosody. Il est préférable d'utiliser le paquet de jessie-backports car il intègre les dernières améliorations pour optimiser la connectivité et la résilience.
Vérifiez le fichier de configuration /etc/prosody/prosody.cfg.lua. La principale chose à faire est de renseigner l'identifiant des utilisateurs autorisés à gérer le serveur.
admins = { "joe@falcot.com" }
Il faut également un fichier de configuration pour chaque domaine. Copiez l'exemple de /etc/prosody/conf.avail/example.com.cfg.lua et adaptez le suivant les besoins. Voici le fichier falcot.com.cfg.lua créé par les administrateurs de Falcot :
VirtualHost "falcot.com"
enabled = true
ssl = {
key = "/etc/ssl/private/falcot.com-key.pem";
certificate = "/etc/ssl/public/falcot.com.pem";
}
Pour activer le domaine, il faut créer un lien symbolique dans /etc/prosody/conf.d/ :
# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/
Redémarrez le service pour utiliser la nouvelle configuration.
11.8.4.2. Gestion du serveur XMPP
Certaines opérations de gestion peuvent être réalisées avec l'utilitaire en ligne de commande prosodyctl. Par exemple, pour ajouter le compte administrateur spécifié dans /etc/prosody/prosody.cfg.lua :
# prosodyctl adduser joe@falcot.com
11.8.5. Services fonctionnant sur le port 443
Certains administrateurs préfèrent faire tourner tous leurs services RTC sur le port 443. Cela simplifie la connexion des utilisateurs qui sont dans des endroits éloignés, tels que des hôtels et des aéroports où les autres ports risquent d'être bloqués et où le trafic Internet est acheminé à travers des serveurs proxy HTTP.
Pour réaliser ceci, chaque service (SIP, XMPP et TURN) doit avoir une adresse IP différente. Tous les services peuvent cependant être sur le même hôte puisque Linux gère des adresses IP multiples sur un seul hôte. Le numéro de port, 443, doit être spécifié dans les fichiers de configuration de chaque service et aussi dans les enregistrements DNS de type SRV.
Falcot souhaite que les clients puissent téléphoner directement à partir du site web. Les administrateurs de Falcot veulent aussi utiliser WebRTC dans le cadre de leur plan de reprise après sinistre, pour que le personnel puisse utiliser les navigateurs web de chez eux pour se connecter au système téléphonique de l'entreprise et travailler normalement en cas d'urgence.
WebRTC est une technologie qui évolue rapidement et il est donc essentiel d'utiliser les paquets des distributions jessie-backports ou Testing.
JSCommunicator est un téléphone WebRTC générique, sans marque, qui n'a besoin d'aucun script côté serveur. Il est construit exclusivement avec du HTML, du CSS et du JavaScript. Il est à la base de nombreux autres services et modules WebRTC pour des
frameworks plus avancés.
Installer le paquet
jscommunicator-web-phone est la méthode la plus rapide pour avoir un téléphone WebRTC sur un site web. Cela nécessite d'avoir un proxy SIP avec un transport WebSocket. Les instructions figurant dans la
Section 11.8.3.1, « Installation du proxy SIP » donnent les informations nécessaires pour activer un transport WebSocket dans le proxy SIP
repro.
jscommunicator-web-phone peut être utilisé de différentes façons. L'une des stratégies les plus simples est d'inclure ou de copier la configuration /etc/jscommunicator-web-phone/apache.conf dans la configuration d'un hôte virtuel Apache.
Une fois que les fichiers de JSCommunicator sont disponibles sur le serveur web, il convient de personnaliser le fichier /etc/jscommunicator-web-phone/config.js pour pointer sur le serveur TURN et sur le serveur SIP. Par exemple ainsi :
JSCommSettings = {
// Environnement du serveur web
webserver: {
url_prefix: null // Si défini, préfixe pour construire sound/ URLs
},
// Relais STUN/TURN pour les médias
stun_servers: [],
turn_servers: [
{ server:"turn:turn-server.falcot.com?transport=udp", username:"joe", password:"j0Ep455d" }
],
// Connexion WebSocket
websocket: {
// Notez qu'on utilise le certificat du domaine falcot.com et le port 8443
// Cela correspond aux exemples Transport3 et Transport4 dans
// le fichier de configuration repro.confifg de falcot.com
servers: 'wss://falcot.com:8443',
connection_recovery_min_interval: 2,
connection_recovery_max_interval: 30
},
...
Les sites web les plus avancés qui proposent d'appeler en ligne utilisent généralement un script côté serveur qui génère dynamiquement le fichier
config.js. Le code source de
DruCall montre comment réaliser ceci en PHP.
Le tour d'horizon des logiciels serveurs proposé par ce chapitre est loin d'être exhaustif, mais il recouvre toutefois la réalité des services réseau les plus employés. Passons sans plus tarder à un chapitre encore plus technique : approfondissement de certains concepts, déploiement à grande échelle, virtualisation sont autant de sujets passionnants que nous allons aborder.
