Infrastruktur#
Virtualisierung#
Warnung
Beim Einsatz von XPhone Server, XPhone Satellit oder einem SQL-Server in einer VM sind Snapshots und Migration im laufenden Betrieb nicht erlaubt. Snapshots dürfen nur im ausgeschalteten Zustand erstellt werden.
SQL-Server in Clustern sind hiervon ausgenommen, da sie speziell dafür ausgelegt sind.
Sollte sich herausstellen, dass eine VM die Vorgaben nicht einhält, behalten wir uns vor, den Support für diese Maschine auszusetzen, bis sie vollständig neu aufgesetzt wurde.
XPhone Server
Wir empfehlen, die MAC-Adresse der virtuellen Maschine statisch festzulegen. Wenn die MAC-Adresse dynamisch bleibt, kann es beim Verschieben oder Migrieren der VM innerhalb des Hypervisors dazu kommen, dass sich die Hardware-ID des Servers verändert. Dies hat zur Folge, dass die Lizenzierung des XPhone Servers ungültig wird. In diesem Fall verlieren alle Nutzer ihre zugewiesenen Client-Lizenzen und können den XPhone Client nicht mehr verwenden, bis der Server neu lizenziert wird.
XPhone Call Controller
Konfigurieren Sie den Virtualisierungs-Host für Quality of Service.
UM Dienste
Bei der Anbindung von UM-Diensten in virtuellen Umgebungen muss jederzeit ausreichend Systemkapazität für die XPhone Connect IP-Channels (XCAPI-Schnittstelle) zur Verfügung stehen. Ein dedizierter Prozessorkern ist von Vorteil. Weitere Informationen finden Sie in der technischen Dokumentation der XCAPI.
In einer virtuellen Umgebung muss die virtualisierte Maschine zusätzlich den Hardware-Timer des Host-Systems nutzen, da rein virtualisierte Timer in der Regel nicht genau genug für die Sprachübertragung sind. Detaillierte Informationen zu Hardware-/Virtual-Timern entnehmen Sie bitte der Dokumentation des Virtualisierungsanbieters.
XCAPI auf Xen Server
Dem (Windows) Server, auf dem die XCAPI installiert ist, muss manuell eine MAC-Adresse in folgendem Format zugewiesen werden:
00-16-3E-XX-XX-XX
Die Werte
XXmüssen entsprechend (frei wählbar) vom Kunden ersetzt werden.Die ersten 3 Ziffern sind XEN-spezifisch und die XCAPI erkennt das virtuelle System. Der Server muss neu gestartet werden. Danach kann in der XCAPI-Konfiguration eine Virtuelle ID ausgelesen werden (wie bei der normalen VMware). Die Lizenz muss wie immer mit dieser Virtuellen ID beantragt werden
Hosting Konzepte#
Im Folgenden werden die Hosting-Szenarien beschrieben, die mit XPhone Connect Mobile und Meeting möglich sind. Der Übersichtlichkeit halber sind in den Konzeptgrafiken nur Mobile Clients dargestellt. Für XPhone Connect Meeting 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 Feature: 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 Meeting Teilnehmer. Daher muss der IIS entsprechend für https-verschlüsselte Verbindungen konfiguriert und Zertifikate hinterlegt werden. Wird neben Mobile auch 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 für den IIS können frei gewählt und in der URL für die XPhone Mobile Apps konfiguriert werden.
Hinweis
In diesem Kapitel erfahren Sie, wie Sie ein Zertifikat im IIS installieren können: HTTPS-Zertifikat.
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 Meeting-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 für den IIS können frei gewählt und in der URL für die XPhone Mobile Apps 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-Zertifikat.
Reverse Proxy in DMZ
Bei diesem Konzept ist der Reverse-Proxy der Kommunikationspartner der XPhone Connect Mobile App und der Meeting-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-Clients oder Mobile Apps 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).
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-Adressen: 17.0.0.0/8
Netzwerk#
Verbindungsübersicht#
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 |
XPhone Connect Server |
Satellit mit XPhone Call Controller |
4899 |
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 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 zu federierenden Systemen über 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 IEEE 802.1p;
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öchstens 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äß RFC 2474 können DSCP-Werte von 0 bis 63 im TOS-Feld (Type of Service) eines IPv4-Pakets angegeben werden. 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 Authentifizierungsarten 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.