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. Die Konzeptbilder enthalten der Übersicht halber jedoch nur Mobile Clients. Für XPhone Connect WebMeeting gelten diese Hosting Szenarien aber genauso.

Hinweis

Die Medienströme müssen separat betrachtet werden: 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.

IIS auf XPhone Server

concept_pw

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 von der XPhone Connect Mobile App und XPhone Web Meeting Teilnehmern. Deswegen muss der IIS entsprechend für https-verschlüsselte Verbindungen konfiguriert und Zertifikate hinterlegt werden. Wenn neben Mobile auch Web-Meeting verwendet wird, ist ein öffentliches Zertifikat obligatorisch. Für XPhone Connect Mobile ist ein öffentliches Zertifikat auch sinnvoll. XPhone Connect Mobile verbindet sich mit dem Webserver für gewöhnlich via https und mit FQDN, der im DNS die öffentliche IP-Adresse des IIS 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

IIS in DMZ

concept_iisdmz

Bei diesem Konzept werden die Web-Anwendungen auf einem separatem Rechner in der DMZ installiert. Hierbei ist der IIS in der DMZ der Kommunikationspartner von der XPhone Connect Mobile App und WebMeeting Teilnehmern. XPhone Connect Mobile verbindet sich mit dem Webserver für gewöhnlich via https und mit FQDN, der im DNS die öffentliche IP-Adresse des IIS 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

Reverse Proxy in DMZ

concept_rpdmz

Bei diesem Konzept ist der Reverse-Proxy der Kommunikationspartner von der XPhone Connect Mobile App und WebMeeting Teilnehmern. Deswegen 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

Natürlich kann auch das zweite Beinchen zwischen Reverse-Proxy und XPhone Server verschlüsselt werden, jedoch verbleibt der Reverse-Proxy als Kommunikationspartner der XPhone Connect Mobile App und ist somit auch für die Verschlüsselung zuständig.

Medien Datenströme und Signalisierung

Es gibt abhängig der NAT Konfiguration unterschiedliche Konzepte und Voraussetzungen hinsichtlich der RTP Medienströme für XPhone Connect Softphone Mobile und Softphone Desktop (Payload Separation):

  • Der XPhone Call Controller ist aus dem Internet erreichbar (via 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

rtp-pf-mobile

  1. In diesem Szenario findet die Signalisierung für Softphone Mobile über die https Verbindung zum IIS statt.

  2. Über STUN werden die öffentliche IP Adressen ermittelt, die für die RTP Datenströme den Kommunikationspartner signalisiert werden.

  3. 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.

  4. Der RTP Medien-Stream erfolgt direkt vom XPhone Mobile Client zum XPhone Call Controller und umgekehrt.

Zusätzlich mit TURN Server

rtp-turn-mobile

  1. In diesem Szenario findet die Signalisierung für Softphone Mobile über die https Verbindung zum IIS statt.

  2. Über STUN werden die öffentlichen IP Adressen ermittelt, die für die RTP Datenströme dem Kommunikationspartner signalisiert werden.

  3. 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.

  4. In Diesem Szenario wird ein zusätzlicher TURN Server zum Überwinden der NAT-Router/Firewall der XPhone Connect Mobile Clients verwendet.

    • Der TURN Server verwendet unterschiedliche Verfahren (ICE) um die Firewall auf der Client-Seite zu durchdringen, damit ein RTP Datenstrom vom XPhone Server zu den XPhone Connect Mobile Clients über den TURN Server möglich ist.

  5. 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)

rtp-pf-desktop

  1. 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.

  2. Über STUN werden die öffentlichen IP Adressen ermittelt, die für die RTP Datenströme dem Kommunikationspartner signalisiert werden.

  3. 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.

  4. 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

rtp-turn-desktop

  1. 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.

  2. Über STUN werden die öffentlichen IP Adressen ermittelt, die für die RTP Datenströme dem Kommunikationspartner signalisiert werden.

  3. 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.

  4. In Diesem Szenario wird ein zusätzlicher TURN Server zum Überwinden der NAT-Router/Firewall der XPhone Connect Mobile Clients verwendet.

    • Der TURN Server verwendet unterschiedliche Verfahren (ICE) um die Firewall auf der Client-Seite zu durchdringen, damit ein RTP Datenstrom vom XPhone Server zu den XPhone Connect Mobile Clients über den TURN Server möglich ist.

  5. 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.

push

  • 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)

Google (Android)

Apple (iOS)

1

Dieser Ziel Port kann mit dieser Anleitung auf 2197 geändert werden.

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.

ports

Quelle

Ziel

Listener-Port(s)

Transport

Protocol

Sonstiges

1

XPhone Connect Client

XPhone Connect Server

2230

TCP

WCF

2

XPhone Connect Client

XPhone Call Controller

30000-33000

UDP

SRTP

Änderbar

2

XPhone Call Controller

XPhone Connect Client

49152-65535

UDP

SRTP

Zusatzinformationen

3

XPhone Connect Client

STUN-Server

3478

UDP

STUN

Zusatzinformationen Konfiguration

4

XPhone Connect Server

C4B Push Service

443

TCP

https

Ziel: https://mobile.c4b.de/pushconfig Zusatzinformationen

5

XPhone Connect Server

C4B 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

Konfiguration

8

XPhone Connect Server

Satellit mit XPhone Call Controller

4901

TCP

SIP

Änderbar

8

Satellit mit XPhone Call Controller

XPhone Connect Server

4900

TCP

SIP

Änderbar

8

XPhone Connect Server

Satellit mit XPhone Call Controller

8021

TCP

Event Socket

9

Web-Server IIS

XPhone Connect Server

2231

TCP

gRPC

Zusatzinformationen

10

Web-Server IIS

XPhone Connect Server

2230

TCP

WCF

Zusatzinformationen

11

Satellit mit XPhone Call Controller

XPhone Connect Mobile

49152-65535

UDP

SRTP

Zusatzinformationen Gilt auch für Smartphones im WLAN.

11

XPhone Connect Mobile

Satellit mit XPhone Call Controller

30000-33000

UDP

SRTP

Zusatzinformationen Änderbar

12

TURN-Server

Satellit mit XPhone Call Controller

30000-33000

UDP

SRTP

Zusatzinformationen Änderbar

12

Satellit mit XPhone Call Controller

TURN-Server

Abhängig vom TURN Server

UDP

SRTP

Zusatzinformationen Konfiguration

12

Satellit mit XPhone Call Controller

TURN-Server

443, 3478 Abhängig vom TURN-Server

TCP

https

Zusatzinformationen Konfiguration

13

Satellit mit XPhone Call Controller

STUN-Server

3478

UDP

https

Konfiguration Konfiguration im SIP GW

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

Änderbar

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

Zusatzinformationen Konfiguration

18

XPhone Connect Mobile

TURN-Server

abhängig vom TURN-Server Default: 443,3478

TCP

https

Zusatzinformationen

18

TURN-Server

XPhone Connect Mobile

49152-65535

UDP

SRTP

Konfiguration

19

XPhone Connect Mobile

STUN-Server

3478

UDP

STUN

Zusatzinformationen

20

XPhone Connect Server

PBX

Abhängig von PBX

CSTA/TAPI

Anschaltanleitungen

21

Satellit mit XPhone Call Controller

NTP Server

123

UDP

Konfiguration

Ports

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

XCAPI

Allgemein

Port

SIP-Kommunikation

5060 UDP(!)

Weiterführende Informationen (z.B. für Betrieb in einer DMZ) finden Sie in

der Technote „XCAPI und Firewalls“ vom XCAPI Hersteller TE-Systems

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 Delays) darauf angewiesen, dass sie in einem VoIP Ready Netzwerk eingesetzt werden. Um ein möglichst gutes Benutzererlebnis zu erreichen, sind folgende Voraussetzungen einzuhalten:

  • 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 zeitsynchron sein, um einen zuverlässigen Betrieb gewährleisten zu können. Die Synchronisierung von Uhren im Netzwerk ist Voraussetzung für „VoIP Ready“ und kann beispielsweise ü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).

Hinweis

Bei einem ausgelagerten XCC auf einem Linux Satellit werden die QoS Parameter automatisch gesetzt.

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 entdeckt?

Bitte schicken Sie uns einen Hinweis auf diesen Fehler per Mail an doku@c4b.de. Vielen Dank!