11.8. Servizi di Comunicazione Real-Time
I servizi Real-Time Communication (RTC) includono voce, video/webcam, instant messaging (IM) e condivisione desktop. Questo capitolo fornisce una breve introduzione a tre dei servizi necessari per il funzionamento RTC, tra cui il server TURN, server SIP e il 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 di 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.
11.8.1. Impostazioni DNS per i servizi RTC
I servizi RTC richiedono registrazioni DNS SVR e NAPTR. Un esempio di configurazione che può essere collocato nel file di zona per 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 è 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.
11.8.2.1. Installare il server TURN
Installare il pacchetto resiprocate-turn-server.
Modificare il file di configurazione /etc/reTurn/reTurnServer.config. La cosa più importante da fare è inserire gli indirizzi IP del server.
# 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
Riavvia il servizio.
11.8.2.2. Gestione degli utenti TURN
Utilizzare l'utility htdigest per gestire l'elenco utenti del server TURN.
# htdigest /etc/reTurn/users.txt myrealm joe
Utilizzare il segnale HUP signal per consentire al server di ricaricare il file /etc/reTurn/users.txt dopo la modifica o abilitare la funzione automatica di ricarica nel /etc/reTurn/reTurnServer.config.
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 apcchetto repro. E' altamente raccomandato l'uso del pacchetto da jessie-backports, in quanto ha i più recenti miglioramenti per massimizzare la connettività e la resilienza.
Modifica il file di configurazione /etc/repro/repro.config. La cosa più importante da fare è inserire gli indirizzi IP del server. L'esempio sotto mostra come impostare correttamente sia SIP che WebSockets/WebRTC, utilizzando TLS, IPv4 e IPv6:
# Transport1 will be for SIP over TLS connections
# We use port 5061 here but if you have clients connecting from
# locations with firewalls you could change this to listen on port 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 is the IPv6 version of 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 will be for SIP over WebSocket (WebRTC) connections
# We use port 8443 here but you could use 443 instead
Transport3Interface = 198.51.100.19:8443
Transport3Type = WSS
Transport3TlsDomain = falcot.com
# This would require the browser to send a certificate, but browsers
# don't currently appear to be able to, so leave it as 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 is the IPv6 version of 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: this could be for TCP connections to an Asterisk server
# in your internal network. Don't allow port 5060 through the external
# firewall.
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
Utilizzare l'utility di comando htdigest per gestire la password dell'amministratore per l'interfaccia web. Il nome utente deve essere admin ed il nome di dominio deve corrispondere al valore specificato in repro.config.
# htdigest /etc/repro/users.txt repro admin
Riavvia il servizio per usare la nuova configurazione.
11.8.3.2. Gestione del proxy SIP
Vai all'interfaccia web all'indirizzo http://sip-proxy.falcot.com:5080 per completare la configurazione ed aggiungere domini, utenti locali e route statiche.
Il primo passo è quello di aggiungere il dominio locale. Il processo deve essere riavviato dopo aggiunta o la rimozione di domini dall'elenco.
Il proxy sa come instradare le chiamate tra utenti locali e indirizzo completo SIP, la configurazione di routing è necessaria solo per sovrascritture del comportamento predefinito, ad esempio, per riconoscere i numeri di telefono, aggiungere un prefisso e instradarli a un provider SIP.
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. E' altamente raccomandato l'uso del pacchetto da jessie-backports , in quanto ha i più recenti miglioramenti per massimizzare la connettività e la resilienza.
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.pem";
certificate = "/etc/ssl/public/falcot.com.pem";
}
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'utility da riga di comando prosodyctl. Per esempio, per aggiungere l'account amministratore specificato in /etc/prosody/prosody.cfg.lua:
# prosodyctl adduser joe@falcot.com
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 dalle distribuzioni jessie-backports o Testing.
JS Communicator è un generico, telefono WebRTC non marchiato che non richiede alcun scripting lato server come PHP. E 'costruito esclusivamente con HTML, CSS e JavaScript. E 'la base per molti altri servizi WebRTC e moduli per altri framework web publishing avanzati.
Il pacchetto
jscommunicator-web-phone è il modo più rapido per installare un telefono WebRTC in un sito web. E' richiesto un proxy SIP con un trasporto WebSocket. Le istruzioni nella
Sezione 11.8.3.1, «Installare il proxy SIP» contengono i dettagli necessari per consentire il trasporto WebSocket nel proxy SIP
repro.
Dopo l'installazione di jscommunicator-web-phone, ci sono vari modi per usarlo. Una strategia semplice è quello di includere o copiare la configurazione da /etc/jscommunicator-web-phone/apache.conf nella configurazione di un host virtuale di Apache.
Una volta che i file web-phone sono disponibili nel server web, personalizzare il /etc/jscommunicator-web-phone/config.js per puntare al server TURN ed al proxy SIP. Per esempio:
JSCommSettings = {
// Web server environment
webserver: {
url_prefix: null // If set, prefix used to construct sound/ URLs
},
// STUN/TURN media relays
stun_servers: [],
turn_servers: [
{ server:"turn:turn-server.falcot.com?transport=udp", username:"joe", password:"j0Ep455d" }
],
// WebSocket connection
websocket: {
// Notice we use the falcot.com domain certificate and port 8443
// This matches the Transport3 and Transport4 example in
// the falcot.com repro.config file
servers: 'wss://falcot.com:8443',
connection_recovery_min_interval: 2,
connection_recovery_max_interval: 30
},
...
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.
