Product SiteDocumentation Site

11.8. Echtzeit-Kommunikationsdienste

Real-Time Communication (RTC) Dienste beinhalten Sprache, Video/Webcam, Instant Messaging (IM) und Desktop Sharing. Dieses Kapitel gibt eine kurze Einführung in drei der für den Betrieb von RTC erforderlichen Dienste, darunter ein TURN-Server, SIP-Server und XMPP-Server. Ausführliche Informationen zur Planung, Installation und Verwaltung dieser Dienste finden Sie im Real-Time Communications Quick Start Guide, der Beispiele speziell für Debian enthält.
Sowohl SIP als auch XMPP können die gleiche Funktionalität bieten. SIP ist etwas bekannter für Sprache und Video, während XMPP traditionell als IM-Protokoll angesehen wird. Allerdings können beide für jeden dieser Zwecke verwendet werden. Um die Konnektivitätsmöglichkeiten zu maximieren, wird empfohlen, beide parallel zu betreiben.
Diese Dienste basieren auf X.509-Zertifikaten, sowohl für die Authentifizierung als auch für Vertraulichkeit. Siehe Abschnitt 10.2.1.1, „Public-Key-Infrastrultur: easy-rsa für Details zur Erstellung. Alternativ dazu bietet die Real-Time Communications Quick Start Guide auch nützliche Erklärungen:

11.8.1. DNS-Einstellungen für RTC-Dienste

RTC-Dienste erfordern DNS SRV- und NAPTR-Einträge. Eine Beispielkonfiguration, die in der Zonendatei für falcot.com abgelegt werden kann:
; 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. TURN Server

TURN ist ein Dienst, der Clients hinter NAT-Routern und Firewalls hilft, die effizienteste Art der Kommunikation mit anderen Clients zu finden und die Medienströme weiterzuleiten, wenn kein direkter Medienpfad gefunden werden kann. Es wird dringend empfohlen, den TURN-Server zu installieren, bevor die anderen RTC-Dienste den Endbenutzern angeboten werden.
TURN and the related ICE protocol are open standards. To benefit from these protocols, maximizing connectivity and minimizing user frustration, it is important to ensure that all client software supports ICE and TURN.
For the ICE algorithm to work effectively, the server must have two public IPv4 addresses.

11.8.2.1. Install the TURN server

Install the resiprocate-turn-server package.
Edit the /etc/reTurn/reTurnServer.config configuration file. The most important thing to do is insert the IP addresses of the 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
Restart the service.

11.8.2.2. Managing the TURN users

Use the htdigest utility to manage the TURN server user list.
# htdigest /etc/reTurn/users.txt myrealm joe
Use the HUP signal to make the server reload the /etc/reTurn/users.txt file after changing it or enable the automatic reload feature in /etc/reTurn/reTurnServer.config.

11.8.3. SIP Proxy Server

A SIP proxy server manages the incoming and outgoing SIP connections between other organizations, SIP trunking providers, SIP PBXes such as Asterisk, SIP phones, SIP-based softphones and WebRTC applications.
It is strongly recommended to install and configure the SIP proxy before attempting a SIP PBX setup. The SIP proxy normalizes a lot of the traffic reaching the PBX and provides greater connectivity and resilience.

11.8.3.1. Install the SIP proxy

Install the repro package. Using the package from jessie-backports is highly recommended, as it has the latest improvements for maximizing connectivity and resilience.
Edit the /etc/repro/repro.config configuration file. The most important thing to do is insert the IP addresses of the server. The example below demonstrates how to setup both regular SIP and WebSockets/WebRTC, using TLS, IPv4 and 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
Use the htdigest utility to manage the admin password for the web interface. The username must be admin and the realm name must match the value specified in repro.config.
# htdigest /etc/repro/users.txt repro admin
Restart the service to use the new configuration.

11.8.3.2. Managing the SIP proxy

Go to the web interface at http://sip-proxy.falcot.com:5080 to complete the configuration by adding domains, local users and static routes.
The first step is to add the local domain. The process must be restarted after adding or removing domains from the list.
The proxy knows how to route calls between local users and full SIP address, the routing configuration is only necessary for overriding default behavior, for example, to recognize phone numbers, add a prefix and route them to a SIP provider.

11.8.4. XMPP Server

An XMPP server manages connectivity between local XMPP users and XMPP users in other domains on the public Internet.
Prosody is a popular XMPP server that operates reliably on Debian servers.

11.8.4.1. Install the XMPP server

Install the prosody package. Using the package from jessie-backports is highly recommended, as it has the latest improvements for maximizing connectivity and resilience.
Review the /etc/prosody/prosody.cfg.lua configuration file. The most important thing to do is insert JIDs of the users who are permitted to manage the server.
admins = { "joe@falcot.com" }
An individual configuration file is also needed for each domain. Copy the sample from /etc/prosody/conf.avail/example.com.cfg.lua and use it as a starting point. Here is 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";
                }
To enable the domain, there must be a symlink from /etc/prosody/conf.d/. Create it that way:
# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/
Restart the service to use the new configuration.

11.8.4.2. Managing the XMPP server

Some management operations can be performed using the prosodyctl command line utility. For example, to add the administrator account specified in /etc/prosody/prosody.cfg.lua:
# prosodyctl adduser joe@falcot.com
See the Prosody online documentation for more details about how to customize the configuration.

11.8.5. Running services on port 443

Some administrators prefer to run all of their RTC services on port 443. This helps users to connect from remote locations such as hotels and airports where other ports may be blocked or Internet traffic is routed through HTTP proxy servers.
To use this strategy, each service (SIP, XMPP and TURN) needs a different IP address. All the services can still be on the same host as Linux supports multiple IP addresses on a single host. The port number, 443, must be specified in the configuration files for each process and also in the DNS SRV records.

11.8.6. Adding WebRTC

Falcot wants to let customers make phone calls directly from the web site. The Falcot administrators also want to use WebRTC as part of their disaster recovery plan, so staff can use web browsers at home to log in to the company phone system and work normally in an emergency.
WebRTC is a rapidly evolving technology and it is essential to use packages from the jessie-backports or Testing distributions.
JSCommunicator is a generic, unbranded WebRTC phone that does not require any server-side scripting such as PHP. It is built exclusively with HTML, CSS and JavaScript. It is the basis for many other WebRTC services and modules for more advanced web publishing frameworks.
The package jscommunicator-web-phone is the quickest way to install a WebRTC phone into a web site. It requires a SIP proxy with a WebSocket transport. The instructions in Abschnitt 11.8.3.1, „Install the SIP proxy“ include the necessary details to enable the WebSocket transport in the repro SIP proxy.
After installing jscommunicator-web-phone, there are various ways to use it. A simple strategy is to include or copy the configuration from /etc/jscommunicator-web-phone/apache.conf into an Apache virtual host configuration.
Once the web-phone files are available in the web server, customize the /etc/jscommunicator-web-phone/config.js to point at the TURN server and SIP proxy. For example:
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
  },

  ...
More advanced click-to-call web sites typically use server-side scripting to generate the config.js file dynamically. The DruCall source code demonstrates how to do this with PHP.
Dieses Kapitel hat nur einen Bruchteil der verfügbaren Serversoftware dargestellt; jedoch wurden die meisten der üblichen Netzwerkdienste beschrieben. Jetzt ist es Zeit für ein noch technischeres Kapitel: wir werden tiefer in die Einzelheiten einiger Konzepte eindringen, sowie Masseneinsätze und Virtualisierungen beschreiben.