Infrastruktur
Hosting Konzepte für Web Services
Im Folgenden werden die Hosting-Szenarien beschrieben, die mit XPhone Connect Mobile und Web-Meeting möglich sind. Der Übersichtlichkeit halber sind in den Konzeptgrafiken nur Mobile Clients dargestellt. Für XPhone Connect WebMeeting gelten diese Hosting-Szenarien jedoch in gleicher Weise.
Hinweis
Die Medienströme sind getrennt zu betrachten: Konzept Medien Datenströme.
Achtung
Ab 250 Mobile App Usern müssen die Web-Anwendungen für die Mobile App (XPhoneMobile.MVC und WebClientApi) auf einem separaten Server installiert werden.
Lesen Sie auch die Kapitel Systemvoraussetzungen für XPhone Connect Mobile und Installation von Web-Anwendungen auf separatem Rechner.
IIS auf XPhone Server
Die Web-Anwendungen werden auf dem XPhone Server mit der Betriebsart XPhone als UC-Lösung mit installiert. Bei diesem Konzept ist der IIS auf dem XPhone Server der Kommunikationspartner der XPhone Connect Mobile App und der XPhone Web Meeting Teilnehmer. Daher muss der IIS entsprechend für https-verschlüsselte Verbindungen konfiguriert und Zertifikate hinterlegt werden. Wird neben Mobile auch Web Meeting verwendet, ist ein öffentliches Zertifikat zwingend erforderlich. Auch für XPhone Connect Mobile ist ein öffentliches Zertifikat sinnvoll. XPhone Connect Mobile verbindet sich mit dem Webserver in der Regel über https und mit einem FQDN, der die öffentliche IP-Adresse des IIS im DNS auflöst. Die in der Firewall weitergeleiteten Ports auf den IIS können frei gewählt und in der URL für die XPhone Mobile Clients konfiguriert werden.
Hinweis
In diesem Kapitel erfahren Sie, wie Sie ein Zertifikat im IIS installieren können: HTTPS Konfiguration auf dem IIS.
IIS in DMZ
Bei diesem Konzept werden die Web-Anwendungen auf einem separatem Rechner in der DMZ installiert.
In diesem Fall ist der IIS in der DMZ der Kommunikationspartner für die XPhone Connect Mobile App und die WebMeeting-Teilnehmer.
XPhone Connect Mobile verbindet sich mit dem Webserver in der Regel über https und mit einem FQDN, der die öffentliche IP-Adresse des IIS im DNS auflöst.
Die in der Firewall weitergeleiteten Ports auf den IIS können frei gewählt und in der URL für die XPhone Mobile Clients konfiguriert werden.
Deswegen muss der IIS entsprechend für https-verschlüsselte Verbindungen konfiguriert und Zertifikate hinterlegt werden.
Der IIS muss die XPhone Server Ports TCP 2230
und 2231
erreichen.
Hinweis
In diesem Kapitel erfahren Sie, wie Sie ein Zertifikat im IIS installieren können: HTTPS Konfiguration auf dem IIS.
Reverse Proxy in DMZ
Bei diesem Konzept ist der Reverse-Proxy der Kommunikationspartner der XPhone Connect Mobile App und der WebMeeting-Teilnehmer. Daher muss der Reverse-Proxy entsprechend für https-verschlüsselte Verbindungen konfiguriert und Zertifikate hinterlegt werden. Das zweite Beinchen in Richtung XPhone Server muss nicht verschlüsselt sein. Somit verbleibt die Web Application (mobile/webmeeting) auf dem XPhone Server (Betriebsart XPhone als UC-Lösung).
Hinweis
Selbstverständlich kann auch die zweite Verbindung zwischen Reverse-Proxy und XPhone Server verschlüsselt werden, Der Reverse-Proxy bleibt jedoch der Kommunikationspartner der XPhone Connect Mobile App und ist somit auch für die Verschlüsselung verantwortlich.
Medien Datenströme und Signalisierung
Abhängig von der NAT-Konfiguration gibt es für XPhone Connect Softphone Mobile und Softphone Desktop unterschiedliche Konzepte und Anforderungen bezüglich der RTP-Medienströme (Payload Separation):
Der XPhone Call Controller ist aus dem Internet erreichbar (über NAT oder Portforwarding für RTP-Audioströme).
Die standard Portrange des XPhone Call Controllers ist
UDP 30000-33000
.Die Portrange ist frei konfigurierbar und darf von extern nicht auf andere Ports intern umgemappt werden.
Pro aktivem Gespräch sind vier eingehende Ports zu vorzusehen (für RTP und RTCP).
Zwei Ports je Gesprächsteilnehmer.
Zusätzlich kann ggf. Hole Punching bei restriktiven NAT Typen nötig sein.
STUN Server
Zur Ermittlung der öffentlichen IP-Adresse bei Softphone Mobile/Desktop (Payload Separation) nötig.
Optionaler TURN Server
Die NAT-Router/Firewalls auf Seite der Desktop- oder Mobile Clients unterliegen meist nicht dem Einfluss des XPhone-Server-Betreibers. Somit kann der verwendete NAT-Typ zu restriktiv sein, um eine direkte IP-Verbindung zu ermöglichen (z.B. Symmetric NAT).
Zum Überwinden von NAT-Routern / Firewalls auf der Client Seite für RTP Datenströme, die von XPhone Connect Server zu den XPhone Clients gesendet werden (Leistungsmerkmal Softphone Mobile oder Softphone Desktop).
Softphone Mobile
In diesem Szenario findet die Signalisierung für Softphone Mobile über die https Verbindung zum IIS statt.
Über STUN werden die öffentliche IP Adressen ermittelt, die für die RTP Datenströme den Kommunikationspartner signalisiert werden.
Der XPhone Call Controller ist aus dem Internet erreichbar (via NAT oder UDP Portforwarding für RTP Audioströme).
Hierbei ist es unerheblich, ob es sich bei dem XPhone Call Controller (XCC) um den Integrierten XCC auf dem Windows Server, oder einen ausgelagerten XCC auf einem Linux Satelliten, handelt.
Der XPhone Call Controller RTP Port-Bereich kann frei konfiguriert werden (Default ist
UDP 30000-33000
).Zusätzlich kann ggf. Hole Punching bei restriktiven NAT Typen nötig sein.
Der RTP Medien-Stream erfolgt direkt vom XPhone Mobile Client zum XPhone Call Controller und umgekehrt.
Zusätzlich mit TURN Server
In diesem Szenario findet die Signalisierung für Softphone Mobile über die https Verbindung zum IIS statt.
Über STUN werden die öffentlichen IP Adressen ermittelt, die für die RTP Datenströme dem Kommunikationspartner signalisiert werden.
Der XPhone Call Controller ist aus dem Internet erreichbar (via NAT oder UDP Portforwarding für RTP Audioströme).
Hierbei ist es unerheblich, ob es sich bei dem XPhone Call Controller (XCC) um den Integrierten XCC auf dem Windows Server, oder einen ausgelagerten XCC auf einem Linux Satelliten, handelt.
Der XPhone Call Controller RTP Port-Bereich kann frei konfiguriert werden (Default ist
UDP 30000-33000
)Zusätzlich kann ggf. Hole Punching bei restriktiven NAT Typen nötig sein.
In diesem Szenario wird ein zusätzlicher TURN Server verwendet, um die NAT-Router oder Firewalls der XPhone Connect Mobile Clients zu überwinden.
Der TURN Server verwendet verschiedene Verfahren (ICE), um die Firewall auf der Client-Seite zu überwinden, so dass ein RTP-Datenstrom vom XPhone Server zu den XPhone Connect Mobile Clients über den TURN Server möglich ist.
Der RTP Medien-Stream wird direkt vom XPhone Mobile Client zum XPhone Call Controller gesendet.
Achtung
C4B stellt keinen TURN Server zur Verfügung. Hieran muss in der Planungsphase unbedingt gedacht werden, denn es können u.U. weitere Kosten anfallen. Zur Zeit ist ausschließlich der kostenpflichtige Xirsys.com TURN Server freigegeben. Möchten Sie andere TURN Server verwenden, so fragen Sie bitte den C4B Produktsupport.
Softphone Desktop (Payload Separation)
In diesem Szenario findet die Signalisierung für Softphone Desktop über eine VPN Verbindung statt. Der XPhone Client erreicht den XPhone Server über diese VPN Verbindung.
Über STUN werden die öffentlichen IP Adressen ermittelt, die für die RTP Datenströme dem Kommunikationspartner signalisiert werden.
Der XPhone Call Controller ist aus dem Internet erreichbar (via NAT oder UDP Portforwarding für RTP Audioströme).
Hierbei ist es unerheblich, ob es sich bei dem XPhone Call Controller (XCC) um den Integrierten XCC auf dem Windows Server, oder einen ausgelagerten XCC auf einem Linux Satelliten, handelt.
Der XPhone Call Controller RTP Port-Bereich kann frei konfiguriert werden (Default ist
UDP 30000-33000
)Zusätzlich kann ggf. Hole Punching bei restriktiven NAT Typen nötig sein.
Der RTP Medien-Stream erfolgt direkt vom XPhone Mobile Client zum XPhone Call Controller und umgekehrt.
Tipp
Hierbei ist von Vorteil, dass die Audiodaten nicht über das VPN geroutet werden. Wenn QoS über VPN nicht unterstützt wird, führt dies häufig zu schlechter Sprachqualität.
Zusätzlich mit TURN Server
In diesem Szenario findet die Signalisierung für Softphone Desktop über eine VPN Verbindung statt. Der XPhone Client erreicht den XPhone Server über diese VPN Verbindung.
Über STUN werden die öffentlichen IP Adressen ermittelt, die für die RTP Datenströme dem Kommunikationspartner signalisiert werden.
Der XPhone Call Controller ist aus dem Internet erreichbar (via NAT oder UDP Portforwarding für RTP Audioströme).
Hierbei ist es unerheblich, ob es sich bei dem XPhone Call Controller (XCC) um den Integrierten XCC auf dem Windows Server, oder einen ausgelagerten XCC auf einem Linux Satelliten, handelt.
Der XPhone Call Controller RTP Port-Bereich kann frei konfiguriert werden (Default ist
UDP 30000-33000
)Zusätzlich kann ggf. Hole Punching bei restriktiven NAT Typen nötig sein.
In diesem Szenario wird ein zusätzlicher TURN Server verwendet, um die NAT-Router oder Firewalls der XPhone Connect Mobile Clients zu überwinden.
Der TURN Server verwendet verschiedene Verfahren (ICE), um die Firewall auf der Client-Seite zu überwinden, so dass ein RTP-Datenstrom vom XPhone Server zu den XPhone Connect Mobile Clients über den TURN Server möglich ist.
Der RTP Medien-Stream wird direkt vom XPhone Mobile Client zum XPhone Call Controller gesendet.
Achtung
C4B stellt keinen TURN Server zur Verfügung. Hieran muss in der Planungsphase unbedingt gedacht werden, denn es können u.U. weitere Kosten anfallen. Zur Zeit ist ausschließlich der kostenpflichtige Xirsys.com TURN Server freigegeben. Möchten Sie andere TURN Server verwenden, so fragen Sie bitte den C4B Produktsupport.
Tipp
Hierbei ist von Vorteil, dass die Audiodaten nicht über das VPN geroutet werden. Wenn QoS über VPN nicht unterstützt wird, führt dies häufig zu schlechter Sprachqualität.
Push-Benachrichtigung
XPhone Connect Mobile kann Push Benachrichtigungen an Android oder iOS Smartphones versenden. Hierfür nutzt der XPhone Server die Google und Apple Push Dienste. Optional kann ein Proxy-Server für diese ausgehenden Push Benachrichtigungen verwendet werden.
Um Pushes zu den Apple und Google Diensten schicken zu können, benötigt man Zertifikate.
C4B stellt über die C4B Push Dienste jedem XPhone Server diese Zertifikate automatisch zur Verfügung.
Jeder XPhone Server schickt selbständig Push Benachrichtigungen an die Apple und Google Push Dienste.
Ausgehende Verbindungen
C4B Push Dienste (für alle Push-Dienste)
Protocol: HTTPS
Destination Port: 443
Google (Android)
Doc: https://firebase.google.com/docs/cloud-messaging/concept-options#messaging-ports-and-your-firewall
Protocol: HTTPS
Destination URL: https://fcm.googleapis.com/
Destination Port: 443
Port: 5228, (5229), (5230)
Hinweis
Nur relevant für eine Firewall, die sich zwischen Mobile App und Google Server befindet, z.B. im internen Firmennetzwerk Port 5229, 5230 werden als Fallback genutzt und sollten freigeschaltet werden.
Apple (iOS)
Protocol: TCP
Destination URL: https://api.push.apple.com
Destination Port: 443 [1]
Port: 5223
Hinweis
Nur relevant für eine Firewall, die sich zwischen Mobile App und Apple Server befindet, z.B. im internen Firmennetzwerk
IP-Adresses: 17.0.0.0/8
Netzwerk
Verbindungsübersicht für Softphone Desktop/Mobile
Achtung
Ein eventuell auf der Firewall vorhandenes Application Layer Gateway für SIP muss abgeschaltet werden bzw. müssen alle verwendeten SIP-Ports freigegeben werden.
Hinweis
Mit unserem Firewall Generator können Sie eine individuelle Port- und Firewall-Regelliste erstellen.
Quelle |
Ziel |
Listener-Port(s) |
Transport |
Protocol |
Sonstiges |
|
---|---|---|---|---|---|---|
1 |
XPhone Connect Client |
XPhone Connect Server |
2230 |
TCP |
WCF |
|
1 |
XPhone Connect Client |
XPhone Connect Server - Web-Server IIS |
80/443 |
TCP |
http/s |
Ziel: https://<domain>/xphoneconnect/AppLink Ziel: https://<domain>/xphoneconnect/Applink2 Zusatzinformationen Dashboard |
2 |
XPhone Connect Client |
XPhone Call Controller |
30000-33000 |
UDP |
SRTP |
|
2 |
XPhone Call Controller |
XPhone Connect Client |
49152-65535 |
UDP |
SRTP |
|
3 |
XPhone Connect Client |
STUN-Server |
3478, 3479 |
UDP |
STUN |
|
4 |
XPhone Connect Server |
C4B Push Service |
443 |
TCP |
https |
Ziel: https://mobile.c4b.de/pushconfig Zusatzinformationen |
5 |
XPhone Connect Server |
Google Push Service |
443 |
TCP |
https |
Ziel: https://fcm.googleapis.com/ Ziel: https://fcm.googleapis.com/fcm/send Zusatzinformationen |
6 |
XPhone Connect Server |
Apple Push Service |
443 (2197) |
TCP |
https |
Ziel: https://api.push.apple.com IP-Adressbereich: 17.0.0.0/8 Zusatzinformationen |
7 |
XPhone Connect Server |
Satellit mit XPhone Call Controller |
3280 22 |
TCP |
gRPC SSH |
|
8 |
XPhone Connect Server |
Satellit mit XPhone Call Controller |
4901 |
TCP |
SIP |
|
8 |
Satellit mit XPhone Call Controller |
XPhone Connect Server |
4900 |
TCP |
SIP |
|
8 |
XPhone Connect Server |
Satellit mit XPhone Call Controller |
8021 |
TCP |
Event Socket |
|
9 |
Web-Server IIS |
XPhone Connect Server |
2231 |
TCP |
gRPC |
|
10 |
Web-Server IIS |
XPhone Connect Server |
2230 |
TCP |
WCF |
|
11 |
Satellit mit XPhone Call Controller |
XPhone Connect Mobile |
ANY |
UDP |
SRTP |
Zusatzinformationen Gilt auch für Smartphones im WLAN. |
11 |
XPhone Connect Mobile |
Satellit mit XPhone Call Controller |
30000-33000 |
UDP |
SRTP |
|
12 |
TURN-Server |
Satellit mit XPhone Call Controller |
30000-33000 |
UDP |
SRTP |
|
12 |
Satellit mit XPhone Call Controller |
TURN-Server |
Abhängig vom TURN Server |
UDP |
SRTP |
|
12 |
Satellit mit XPhone Call Controller |
TURN-Server |
443, 3478 Abhängig vom TURN-Server |
TCP |
https |
|
13 |
Satellit mit XPhone Call Controller |
STUN-Server |
3478, 3479 |
UDP |
https |
|
14 |
Satellit mit XPhone Call Controller |
PBX / SBC |
5060 |
TCP/UDP |
SIP |
Abhängig von der PBX/SBC Einstellung Konfiguration des SIP Gateways |
14 |
Satellit mit XPhone Call Controller |
PBX / SBC |
* |
UDP |
RTP |
Abhängig von der PBX/SBC Konfiguration |
14 |
PBX / SBC |
Satellit mit XPhone Call Controller |
5060 |
TCP/UDP |
SIP |
Abhängig von der PBX/SBC Einstellung Konfiguration des SIP Gateways |
14 |
PBX / SBC |
Satellit mit XPhone Call Controller |
30000-33000 |
UDP |
RTP |
|
15 |
XPhone Connect Mobile |
Google Push Service |
5228 5229 5230 |
TCP |
https |
Zusatzinformationen Gilt auch für Smartphones im WLAN. |
16 |
XPhone Connect Mobile |
Apple Push Service |
5223 |
TCP |
https |
Zusatzinformationen Gilt auch für Smartphones im WLAN. |
17 |
XPhone Connect Mobile |
Web-Server IIS |
443 |
TCP |
https |
Ziel: https://<domain>/xphoneconnect/mobile Ziel: https://<domain>/xphoneconnect/webclientapi Zusatzinformationen |
18 |
XPhone Connect Mobile |
TURN-Server |
abhängig vom TURN-Server |
UDP |
SRTP |
|
18 |
XPhone Connect Mobile |
TURN-Server |
abhängig vom TURN-Server Default: 443,3478 |
TCP |
https |
|
18 |
TURN-Server |
XPhone Connect Mobile |
49152-65535 |
UDP |
SRTP |
|
19 |
XPhone Connect Mobile |
STUN-Server |
3478 |
UDP |
STUN |
|
20 |
XPhone Connect Server |
PBX |
Abhängig von PBX |
CSTA/TAPI |
||
21 |
Satellit mit XPhone Call Controller |
NTP Server |
123 |
UDP |
Ports
Hinweis
Mit unserem Firewall Generator können Sie eine individuelle Port- und Firewall-Regelliste erstellen.
Nach der Installation des XPhone Connect Servers bzw. XPhone Connect Clients werden Ausnahmen für XPhone Connect in der Windows Firewall konfiguriert. Sollten andere Firewalls verwendet werden, stellen Sie bitte sicher, dass die genannten Ports, je nach eingesetzten Funktionen und Produkten offen sind.
Allgemeine Ports
Allgemein |
Port |
---|---|
Automatische Ermittlung des XPhone Connect Servers (WS-Discovery, s. Automatische Ermittlung des XPhone Connect Servers) |
3702 UDP |
XPhone Connect Directory Kommunikation mit LDAP Clients |
389 TCP |
Ports für Fax / Voicemail
Allgemein |
Port |
---|---|
Voicemail-Player zwischen XPhone Connect Client und Server |
2528 TCP |
IMAP (interner E-Mail Server - XPhone Connect Client / XPhone Connect Server ein- und ausgehend) |
2511 TCP |
SMTP-Zugriff vom XPhone Connect Server zum internen / externen E-Mail-Server |
25 TCP |
IMAP-Zugriff vom XPhone Connect Server zum externen E-Mail-Server |
389 TCP |
Active Directory (Konnektor)
Allgemein |
Port |
---|---|
LDAP-Zugriff |
389 TCP |
Global Catalog Server Zugriff |
3268 TCP |
Bildschirmfreigabe
Allgemein |
Port |
---|---|
Client- zu Client-Verbindung, wird vom Betriebssystem dynamisch gewählt. Ein Betrieb über das Internet ist i.d.R. aufgrund von NAT nicht möglich. |
49152 bis 65535 (nicht änderbar) |
Hinweis
Es kann notwendig sein, dass in der Firmen-Firewall bzw. dem Firmen-IPS (Intrusion-Prevention-System, z.B. Snort) eine Ausnahmeregel gesetzt wird, welche RDP-Verbindungen auch ohne die Verwendung des Ports 3389 zulässt.
Siehe auch Bildschirmfreigabe clientseitig
Federation
Allgemein |
Port |
---|---|
Kommunikation z.B. mit Skype for Business, Protokoll MTLS Siehe auch Federation |
5061 |
VoIP-Ready
Der XPhone Call Controller und seine Funktionen, wie z.B. das Softphone, sind für einen reibungslosen Betrieb (gute Sprachqualität, keine Verzögerungen) auf den Einsatz in einem VoIP Ready Netzwerk angewiesen. Um ein optimales Benutzererlebnis zu erreichen, müssen folgende Voraussetzungen erfüllt sein:
QoS auf allen betroffenen Switches/Routern und Endpoints nach IEEE802.p;
DiffServ (RFC 2474) oder ToS (RFC 791) (QoS/DSCP)
Zeitsynchronität
Höchstens 50ms Verzögerung in eine Richtung (one Way Delay);
Höchstens 150ms Gesamtverzögerung
Höchstes 3% Paketverlust
Höchstens 20ms Jitter
Höchstens 40% Netzwerkauslastung in den betroffenen Segmenten.
Zeitsynchronisierung
Das Netzwerk muss zeitsynchronisiert sein, um einen zuverlässigen Betrieb zu gewährleisten. Die Synchronisation der Uhren im Netzwerk ist eine Voraussetzung für VoIP Ready und kann z.B. über NTP (Network Time Protocol) ermöglicht werden.
Quality of Service (DSCP)
Um die Audio IP-Pakete im Netzwerk bevorzugt behandeln zu können, bringt das Windows Betriebssystem einige Optionen mit. Diese werden entweder direkt via Registry gesetzt oder können via Gruppenrichtlinie verteilt werden. Zum Definieren der Priorität von ausgehendem Netzwerkdatenverkehr kann DSCP (Differentiated Services Code Point) verwendet werden. Gemäß der Beschreibung in RFC 2474 ermöglicht DSCP das Angeben von Werten von 0 bis 63 im TOS-Feld (Type of Service) eines IPv4-Pakets. Netzwerkrouter verwenden den DSCP-Wert, um Netzwerkpakete zu klassifizieren und die entsprechende Warteschlange zu bestimmen. Ein höherer Wert weist auf eine höhere Priorität des Pakets hin. Im Netzwerk muss (wenn noch nicht bereits geschehen) eine QoS-Richtlinie verwendet werden. Die QoS-Richtlinie muss einen DSCP-Wert anwenden. Weitere Informationen dazu finden sie in der XPhone Connect Server Dokumentation (QoS Konfiguration).
Firewalleinstellungen für Bildschirmfreigabe
Damit die Bildschirmfreigabe zwischen XPhone Connect Clients im Netzwerk funktioniert, müssen ggf. die lokalen Firewallregeln angepasst bzw. über Gruppenrichtlinien verteilt werden. Sollte die Bildschirmfreigabe zwischen den Clients nicht funktionieren, sind bei der Fehlersuche und -behebung folgende Hinweise zu beachten:
Netzwerk
Beteiligt sind nur die Peers, also die jeweils beteiligten Computer mit XPhone Connect Client. Maßgeblich sind an dieser Stelle die lokalen Firewalls der Rechner. In den Firewalleinstellungen des Rechners wird dies über den Eintrag für die Anwendung XPhone Connect Client geregelt. Dort muss jeglicher Netzwerkverkehr zugelassen sein (eingehend und ausgehend).
Protokoll
Als Protokoll kommt bei der Übertragung der Bilder RDP zum Einsatz. Dies ist nicht zu verwechseln mit dem Dienst Remote Desktop (Terminal Server Dienst) oder Remote Assistance (Remoteunterstützung). Für das Protokoll RDP an sich ist uns keine Stelle bekannt, wo dieses separat gesperrt sein könnte.
Authentifizierung
Das für die Bildschirmfreigabe verwendete Desktop Sharing API liefert zur Authentifizierung ein Secret, welches über einen verschlüsselten Kanal zum anderen Client übermittelt wird. Damit ist die Funktion unabhängig von den eingestellten Authentifzierungsarten und die empfohlene Einstellung kann beibehalten werden (Authentifizierung auf Netzwerkebene).
Dienste
Die Windowsdienste Remote Desktop (Terminal Server Dienst) und Remote Assistance (Remoteunterstützung) verwenden ebenfalls das Remote Desktop Protokoll RDP, letzterer verwendet dabei ebenfalls das Desktop Sharing API. Wenn Remote Assistance funktioniert, sollten auch die Voraussetzungen für die XPhone Connect Bildschirmfreigabe gegeben sein, umgekehrt gilt dies aber nicht unbedingt. D.h. auch bei deaktivierter Remoteunterstützung funktioniert die Bildschirmfreigabe unter Umständen trotzdem.
Haben Sie einen Fehler auf dieser Seite gefunden?
Oder ist etwas nicht gut oder zu ungenau formuliert? Dann freuen wir uns über eine E-Mail, am besten mit einem Verbesserungsvorschlag, an doku@c4b.de. Vielen Dank!