Product SiteDocumentation Site

11.8. Servizi di Comunicazione Real-Time

I servizi Real-Time Communication (RTC - Comunicazione in Tempo Reale) includono voce, video/webcam, instant messaging (IM - Messaggistica Istantanea) e condivisione desktop. Questo capitolo fornisce una breve introduzione a tre dei servizi necessari per il funzionamento di RTC, tra cui un server TURN, un server SIP e un server XMPP. I dettagli completi di come pianificare, installare e gestire questi servizi sono disponibili nella Guida rapida Real-Time Communications, che include esempi specifici per Debian.
Sia SIP e XMPP in grado di fornire le stesse funzionalità. SIP è un po' più conosciuto per voce e video mentre XMPP è tradizionalmente considerato come un protocollo di messaggistica istantanea. In realtà, entrambi possono essere utilizzati per qualsiasi di questi scopi. Per massimizzare le opzioni di connettività, si consiglia di eseguire entrambi in parallelo.
Questi servizi si basano su certificati X.509 sia per l'autenticazione che per la riservatezza. Per ulteriori informazioni, vedere Sezione 10.2, «Certificati X.509».

11.8.1. Impostazioni DNS per i servizi RTC

I servizi RTC richiedono record DNS SVR e NAPTR. Un esempio di configurazione che può essere collocato nel file di zona per falcot.com (vedere abcge Esempio 10.13, «Estratto da /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. Server TURN

TURN è un servizio che aiuta i clienti dietro router NAT e firewall a scoprire il modo più efficace per comunicare con altri clienti e per trasmettere i flussi multimediali se non può essere trovato nessun percorso multimediale diretto. E' vivamente consigliato che il server TURN sia installato prima che tutti gli altri servizi RTC vengano offerti agli utenti finali.
TURN e il relativo protocollo ICE sono degli standard aperti. Per beneficiare di questi protocolli, massimizzando la connettività e riducendo al minimo la frustrazione degli utenti, è importante assicurarsi che tutto il software client supporti ICE e TURN.
Perchè l'algoritmo ICE lavori in modo efficace, il server deve avere due indirizzi IPv4 pubblici.
Installare il pacchetto coturn e modificare il file di configurazione /etc/turnserver.conf. Per impostazione predefinita, in /var/db/turndb è configurato un database SQLite per le impostazioni degli account utente ma, volendo, è possibile configurare PostgreSQL, MySQL o Redis. La cosa più importante da fare è inserire gli indirizzi IP del server.
Il server può essere avviato eseguendo turnserver dal pacchetto coturn. Vogliamo che il server sia un servizio di sistema avviato automaticamente. Questo è il comportamento predefinito utilizzando systemd. Se si usa il vecchio SysVinit è necessario modificare il file /etc/default/coturn come segue:
#
# Uncomment it if you want to have the turnserver running as
# an automatic system service daemon
#
TURNSERVER_ENABLED=1
Per impostazione predefinita, il server TURN utilizza l'accesso anonimo. È necessario aggiungere gli utenti che si desidera utilizzare:
# turnadmin -a -u roland -p secret_password -r falcot.com
# turnadmin -A -u admin -p secret_password
Si usa l'argomento -a per aggiungere un utente normale e -A per aggiungere un utente amministratore.

11.8.3. Proxy Server SIP

Un server proxy SIP gestisce le connessioni SIP in entrata e in uscita tra le altre organizzazioni, fornitori di SIP trunking, PBXes SIP come Asterisk, telefoni SIP, softphone SIP-based e applicazioni WebRTC.
E' altamente raccomandato installare e configurare il proxy SIP prima di tentare una configurazione SIP PBX. Il proxy SIP normalizza la magior partedel traffico che raggiunge il PBX e fornisce una maggiore connettività e resilienza.

11.8.3.1. Installare il proxy SIP

Installare il pacchetto kamailio e quello per il backend del database. Gli amministratori di Falcot hanno scelto MySQL, quindi installano kamailio-mysql-modules e mariadb-server. Il file /etc/kamailio/kamctlrc contiene la configurazione per gli strumenti di controllo kamctl e kamdbctl. È necessario modificare il SIP_DOMAIN impostandolo al proprio dominio del servizio SIP e DBENGINE impostandolo a MySQL, ma è anche possibile utilizzare un altro backend di database.
[...]
## your SIP domain
SIP_DOMAIN=sip.falcot.com

## chrooted directory
# CHROOT_DIR="/path/to/chrooted/directory"

## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE
# by default none is loaded
#
# If you want to setup a database with kamdbctl, you must at least specify
# this parameter.
DBENGINE=MYSQL
[...]
Ora ci concentriamo sul file di configurazione /etc/kamailio/kamailio.cfg. Falcot ha bisogno dell'autenticazione e della posizione persistente dell'utente, quindi aggiungeremo le seguenti direttive #!define all'inizio del file:
#!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 ha bisogno di una struttura di database che possiamo creare eseguendo, come root, kamdbctl create. Infine, possiamo aggiungere alcuni utenti con kamctl.
# kamdbctl create
[...]
# kamctl add roland secret_password
Una volta che tutto è correttamente configurato, è possibile avviare o riavviare il servizio con systemctl restart kamailio e connettersi con un client SIP fornendo l'indirizzo IP e la porta (5090 è quella predefinita). Gli utenti hanno i seguenti id: roland@sip.falcot.com, e possono accedere utilizzando un client (vedere Sezione 13.9, «Software Comunicazioni Real-Time»).

11.8.4. Server XMPP

Un server XMPP gestisce la connettività tra gli utenti XMPP locali e gli utenti XMPP in altri domini su Internet pubblico.
prosody è un popolare server XMPP che opera in modo affidabile su server Debian.

11.8.4.1. Installa il server XMPP

Installare il pacchetto prosody.
Rivedere il file di configurazione /etc/prosody/prosody.cfg.lua. La cosa più importante da fare è inserire i JIDs degli utenti che hanno il permesso di gestire il server.
admins = { "joe@falcot.com" }
E' necessario un file di configurazione individuale per ogni dominio. Copiare l'esempio da /etc/prosody/conf.avail/example.com.cfg.lua ed usarlo come punto di partenza. Qui è 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"
Per abilitare il dominio ci deve essere un collegamento simbolico a/etc/prosody/conf.d/. Crearlo in questo modo:
# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/
Riavvia il servizio per usare la nuova configurazione.

11.8.4.2. Gestione del server XMPP

Alcune operazioni di gestione possono essere eseguite utilizzando l'utilità da riga di comando prosodyctl . Per esempio, per aggiungere l'account amministratore specificato in /etc/prosody/prosody.cfg.lua:
# prosodyctl adduser joe@falcot.com
Per ulteriori dettagli su come personalizzare la configurazione, consultare la documentazione online di Prosody.

11.8.5. Servizi in esecuzione sulla porta 443

Alcuni amministratori preferiscono eseguire tutti i loro servizi RTC sulla porta 443. Ciò consente agli utenti di collegarsi da postazioni remote come alberghi e aeroporti dove altre porte potrebbero essere bloccate o il traffico Internet venire instradato attraverso server proxy HTTP.
Per utilizzare questa strategia, ogni servizio (SIP, XMPP e TURN) ha bisogno di un indirizzo IP diverso. Tutti i servizi possono essere ancora sullo stesso host poiché Linux supporta più indirizzi IP su un singolo host. Il numero della porta, 443, deve essere specificato nel file di configurazione per ogni processo e anche nei record DNS SRV.

11.8.6. Aggiungere WebRTC

La Falcot vuole consentire ai clienti di effettuare chiamate telefoniche direttamente dal sito web. Gli amministratori Falcot vogliono anche usare WebRTC come parte del loro piano di disaster recovery, possono utilizzare per uso personale il browser web a casa per accedere al sistema telefonico aziendale e lavorare normalmente in caso di emergenza.
WebRTC è una tecnologia in rapida evoluzione ed è essenziale per utilizzare i pacchetti della distribuzione Testing. Un'altra opzione è quella di compilare il software.
WebRTC, un software libero sviluppato da Google , utilizza un'API semplice per fornire RTC a browser ed applicazioni mobili.
Un approccio molto flessibile è l'utilizzo dell'implementazione WebRTC di GStreamer. Essa consente di realizzare applicazioni multimediali basate su pipeline permettendo lo sviluppo di applicazioni interessanti ed altamente efficienti. Un buon punto di partenza è la seguente demo di Centricular, la principale azienda che lo sviluppa:
Siti web click-to-call più avanzati utilizzano generalmente script lato server per generare dinamicamente il file config.js. Il codice sorgente di DruCall dimostra come farlo con PHP.
Questo capitolo ha unicamente dato dimostrazione di una piccola parte dei software disponibili per i sistemi server: tuttavia molti dei servizi di rete comuni sono stati descritti. Ora è tempo di passare ad un capitolo ancora più tecnico: scenderemo ancor più in profondità su alcuni concetti, descrivendo implementazioni massive e virtualizzazione.