Infrastructure

Hosting concepts for web services

The hosting scenarios that are possible with XPhone Connect Mobile and Web-Meeting are described below. For the sake of clarity, only Mobile Clients are shown in the concept graphics. However, these hosting scenarios apply to XPhone Connect WebMeeting in the same way.

Hint

The media streams must be considered separately: concept media data streams.

Attention

From 250 mobile app users, the web applications for the mobile app (XPhoneMobile.MVC and WebClientApi) must be installed on a separate server.

• See also chapters System requirements for XPhone Connect Mobile and Installation of web applications on separate computer.

IIS on XPhone Server

The web applications are installed on the XPhone Server with the operating mode XPhone as UC solution as well. With this concept, the IIS on the XPhone server is the communication partner of the XPhone Connect Mobile App and XPhone Web Meeting participants. Therefore, the IIS must be configured accordingly for https-encrypted connections and certificates must be stored. If Web Meeting is used in addition to Mobile, a public certificate is mandatory. For XPhone Connect Mobile, a public certificate is also useful. XPhone Connect Mobile connects to the web server usually via https and with FQDN, which resolves in DNS the public IP address of IIS. The ports forwarded in the firewall to the IIS can be freely chosen and configured in the URL for XPhone Mobile Clients.

Hint

• In this chapter you will learn how to install a certificate in IIS: HTTPS configuration on the IIS.

IIS in DMZ

In this concept, the Web applications are installed on a separate computer in the DMZ. The IIS in the DMZ is the communication partner of the XPhone Connect Mobile app and WebMeeting participants. XPhone Connect Mobile connects to the web server usually via https and with FQDN, which resolves in DNS the public IP address of the IIS. The ports forwarded in the firewall to the IIS can be freely chosen and configured in the URL for XPhone Mobile clients. Therefore, the IIS must be configured accordingly for https-encrypted connections and certificates must be stored. The IIS must reach the XPhone server ports TCP 2230 and 2231.

Hint

• In this chapter you will learn how to install a certificate in IIS: HTTPS configuration on the IIS.

Reverse proxy in DMZ

In this concept, the reverse proxy is the communication partner of the XPhone Connect Mobile app and WebMeeting participants. Therefore, the reverse proxy must be configured accordingly for https-encrypted connections and certificates must be stored. The second leg towards the XPhone server does not need to be encrypted. Thus, the web application (mobile/webmeeting) remains on the XPhone server (operating mode XPhone as UC solution).

Hint

Of course, the second leg between reverse proxy and XPhone server can also be encrypted, but the reverse proxy remains as the communication partner of the XPhone Connect Mobile app and is therefore also responsible for encryption.

Media data streams and signaling

Depending on the NAT configuration, there are different concepts and requirements for XPhone Connect Softphone Mobile and Softphone Desktop with regard to RTP media streams (payload separation):

• The XPhone Call Controller can be reached from the Internet (via NAT or port forwarding for RTP audio streams).

  • The default port range of the XPhone Call Controller is UDP 30000-33000.

    • The port range is free configurable and must not be mapped from external to other ports internally.

  • Four incoming ports are to be provided per active call (for RTP and RTCP).

    • Two ports per call participant.

  • Additionally, Hole punching may be needed for restrictive NAT types.

• STUN server

  • Required to determine the public IP address for Softphone Mobile/Desktop (payload separation).

• Optional TURN server

  • The NAT routers/firewalls on the desktop or mobile client side are usually not subject to the influence of the XPhone server operator. Thus, the NAT type used may be too restrictive to enable a direct IP connection (e.g. Symmetric NAT).

  • To bypass NAT routers / firewalls on the client side for RTP data streams sent from XPhone Connect Server to the XPhone clients (feature Softphone Mobile or Softphone Desktop).

Softphone Mobile

1. In this scenario, signaling for Softphone Mobile takes place via the https connection to IIS.

2. STUN is used to determine the public IP addresses that are signaled to the communication partners for the RTP data streams.

3. The XPhone Call Controller can be reached from the Internet (via NAT or UDP port forwarding for RTP audio streams).

   • It does not matter whether the XPhone Call Controller (XCC) is the integrated XCC on the Windows server or an outsourced XCC on a Linux satellite.

   • The XPhone Call Controller RTP port range can be freely configured (default is UDP 30000-33000).

   • Additionally, Hole punching may be needed for restrictive NAT types.

4. The RTP media stream is directly from the XPhone Mobile Client to the XPhone Call Controller and vice versa.

Additional with TURN server

1. In this scenario, signaling for Softphone Mobile takes place via the https connection to IIS.

2. STUN is used to determine the public IP addresses that are signaled to the communication partners for the RTP data streams.

3. The XPhone Call Controller can be reached from the Internet (via NAT or UDP port forwarding for RTP audio streams).

   • It does not matter whether the XPhone Call Controller (XCC) is the integrated XCC on the Windows server or an outsourced XCC on a Linux satellite.

   • The XPhone Call Controller RTP port range can be freely configured (default is UDP 30000-33000).

   • Additionally, Hole punching may be needed for restrictive NAT types.

4. In this scenario, an additional TURN server is used to overcome the NAT routers or firewalls of the XPhone Connect Mobile Clients.

   • The TURN Server uses various procedures (ICE) to bypass the firewall on the client side so that an RTP data stream from the XPhone Server to the XPhone Connect Mobile Clients is possible via the TURN Server.

5. The RTP media stream is sent directly from the XPhone Mobile Client to the XPhone Call Controller.

Attention

C4B does not provide a TURN server. This must be considered in the planning phase, because additional costs may be necessary. At the moment only the chargeable Xirsys.com TURN Server is released. If you want to use other TURN Servers, please ask the C4B product support.

Softphone Desktop (payload separation)

1. In this scenario, the signaling for Softphone Desktop takes place via a VPN connection. The XPhone client reaches the XPhone server via this VPN connection.

2. STUN is used to determine the public IP addresses that are signaled to the communication partners for the RTP data streams.

3. The XPhone Call Controller can be reached from the Internet (via NAT or UDP port forwarding for RTP audio streams).

   • It does not matter whether the XPhone Call Controller (XCC) is the integrated XCC on the Windows server or an outsourced XCC on a Linux satellite.

   • The XPhone Call Controller RTP port range can be freely configured (default is UDP 30000-33000).

   • Additionally, Hole punching may be needed for restrictive NAT types.

4. The RTP media stream is directly from the XPhone Mobile Client to the XPhone Call Controller and vice versa.

Tip

The advantage here is that the audio data is not routed over the VPN. If QoS is not supported over VPN, this often leads to poor voice quality.

Additional with TURN server

1. In this scenario, the signaling for Softphone Desktop takes place via a VPN connection. The XPhone client reaches the XPhone server via this VPN connection.

2. STUN is used to determine the public IP addresses that are signaled to the communication partners for the RTP data streams.

3. The XPhone Call Controller can be reached from the Internet (via NAT or UDP port forwarding for RTP audio streams).

   • It does not matter whether the XPhone Call Controller (XCC) is the integrated XCC on the Windows server or an outsourced XCC on a Linux satellite.

   • The XPhone Call Controller RTP port range can be freely configured (default is UDP 30000-33000).

   • Additionally, hole punching may be necessary for restrictive NAT types.

4. In this scenario, an additional TURN server is used to overcome the NAT routers or firewalls of the XPhone Connect Mobile Clients.

   • The TURN Server uses various procedures (ICE) to bypass the firewall on the client side so that an RTP data stream from the XPhone Server to the XPhone Connect Mobile Clients is possible via the TURN Server.

5. The RTP media stream is sent directly from the XPhone Mobile Client to the XPhone Call Controller.

Attention

C4B does not provide a TURN server. This must be considered in the planning phase, because additional costs may be necessary. At the moment only the chargeable Xirsys.com TURN Server is released. If you want to use other TURN Servers, please ask the C4B product support.

Tip

The advantage here is that the audio data is not routed over the VPN. If QoS is not supported over VPN, this often leads to poor voice quality.

Push notification

XPhone Connect Mobile can send push notifications to Android or iOS smartphones. For this purpose, the XPhone server uses the Google and Apple push services. Optionally, a proxy server can be used for these outgoing push notifications.

• To be able to send pushes to Apple and Google services, you need certificates.

  • C4B provides these certificates automatically to each XPhone Server via the C4B Push services.

• Each XPhone Server sends push notifications to the Apple and Google push services on its own.

Outgoing connections

C4B Push Services (for all Push Services)

• Protocol: HTTPS

• Destination Port: 443

• URL: https://mobile.c4b.de/pushconfig

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)

  Hint

  Only relevant for a firewall located between mobile app and Google server, e.g. in internal company network port 5229, 5230 are used as fallback and should be unlocked.

• URL: https://fcm.googleapis.com/fcm/send

Apple (iOS)

• Doc: https://support.apple.com/en-us/HT203609

• Protocol: TCP

• Destination URL: https://api.push.apple.com

• Destination Port: 443 [1]

• Port: 5223

  Hint

  Notes: Only relevant for a firewall which is between the mobile app and the Google server, e.g. in the internal company network Port 5229, 5230 are used as fallback and should be activated

• IP adress: 17.0.0.0/8

[1]

This destination port can be changed to 2197 with this guide.

Network

Connection overview for Softphone Desktop/Mobile

Attention

If there is an application layer gateway for SIP on the firewall, it must be switched off or all SIP ports used must be released.

Hint

With our Firewall Generator you can create an individual port and firewall rule list.

	Source	Destination	Listener-Port(s)	Transport	Protocol	Others
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 More Dashboard information
2	XPhone Connect Client	XPhone Call Controller	30000-33000	UDP	SRTP	Changeable
2	XPhone Call Controller	XPhone Connect Client	49152-65535	UDP	SRTP	Additional information
3	XPhone Connect Client	STUN server	3478, 3479	UDP	STUN	Additional information Configuration
4	XPhone Connect Server	C4B Push Service	443	TCP	https	Destination: https://mobile.c4b.de/pushconfig Additional information
5	XPhone Connect Server	Google Push Service	443	TCP	https	Destination: https://fcm.googleapis.com/ Destination: https://fcm.googleapis.com/fcm/send Additional information
6	XPhone Connect Server	Apple Push Service	443 (2197)	TCP	https	Destination: https://api.push.apple.com IP address range: 17.0.0.0/8 Additional information
7	XPhone Connect Server	Satellite with XPhone Call Controller	3280 22	TCP	gRPC SSH	Configuration
8	XPhone Connect Server	Satellite with XPhone Call Controller	4901	TCP	SIP	Changeable
8	Satellite with XPhone Call Controller	XPhone Connect Server	4900	TCP	SIP	Changeable
8	XPhone Connect Server	Satellite with XPhone Call Controller	8021	TCP	Event Socket
9	Web-Server IIS	XPhone Connect Server	2231	TCP	gRPC	Additional information
10	Web-Server IIS	XPhone Connect Server	2230	TCP	WCF	Additional information
11	Satellite with XPhone Call Controller	XPhone Connect Mobile	ANY	UDP	SRTP	Additional information Also applies to smartphones on the WIFI.
11	XPhone Connect Mobile	Satellite with XPhone Call Controller	30000-33000	UDP	SRTP	Additional information Changeable
12	TURN server	Satellite with XPhone Call Controller	30000-33000	UDP	SRTP	Additional information Changeable
12	Satellite with XPhone Call Controller	TURN server	Depends on TURN server	UDP	SRTP	Additional information Configuration
12	Satellite with XPhone Call Controller	TURN server	Depends on TURN server Default: 443,3478	TCP	https	Additional information Configuration
13	Satellite with XPhone Call Controller	STUN server	3478, 3479	UDP	https	Configuration Configuration in SIP GW
14	Satellite with XPhone Call Controller	PBX / SBC	5060	TCP/UDP	SIP	Depending on PBX/SBC setting Configuration of SIP Gateway
14	Satellite with XPhone Call Controller	PBX / SBC	*	UDP	RTP	Depending on the PBX/SBC Configuration
14	PBX / SBC	Satellite with XPhone Call Controller	5060	TCP/UDP	SIP	Depending on PBX/SBC setting Configuration of SIP Gateway
14	PBX / SBC	Satellite with XPhone Call Controller	30000-33000	UDP	RTP	Changeable
15	XPhone Connect Mobile	Google Push Service	5228 5229 5230	TCP	https	Additional information Also applies to smartphones on WLAN.
16	XPhone Connect Mobile	Apple Push Service	5223	TCP	https	Additional information Also applies to smartphones on WLAN.
17	XPhone Connect Mobile	Web-Server IIS	443	TCP	https	Destination: https://<domain>/xphoneconnect/mobile Destination: https://<domain>/xphoneconnect/webclientapi Additional information
18	XPhone Connect Mobile	TURN server	depends on TURN server	UDP	SRTP	Additional information Configuration
18	XPhone Connect Mobile	TURN server	depends on TURN server Default: 443,3478	TCP	https	Additional information
18	TURN server	XPhone Connect Mobile	49152-65535	UDP	SRTP	Configuration
19	XPhone Connect Mobile	STUN server	3478	UDP	STUN	Additional information
20	XPhone Connect Server	PBX	Depending on PBX	CSTA/TAPI		Connection instructions
21	Satellite with XPhone Call Controller	NTP Server	123	UDP		Configuration

Ports

Hint

With our Firewall Generator you can create an individual port and firewall rule list.

After installing the XPhone Connect Server or XPhone Connect Clients, exceptions are configured for XPhone Connect in the Windows Firewall. If other firewalls are used, please ensure that the listed ports are open for the set functions and products.

General ports

General	Port
Determine the XPhone Connect Server automatically (WS-Discovery, see Determine the XPhone Connect Server automatically)	3702 UDP
XPhone Connect Directory communication with LDAP clients	389 TCP

Ports for Fax / Voicemail

General	Port
Voicemail player between XPhone Connect Client and Server	2528 TCP
IMAP (internal e-mail server - XPhone Connect Client / XPhone Connect Server inbound and outbound):	2511 TCP
SMTP access from XPhone Connect Server to an internal / external e-mail server	25 TCP
IMAP access from XPhone Connect Server to the external E-mail server	389 TCP

Active Directory (connector)

General	Port
DAP access	389 TCP
Global catalogue server access	3268 TCP

Screen sharing

General	Port
Client-to-client connection, is dynamically selected by the operating system. Operation over the Internet is usually not possible due to NAT.	49152 to 65535 (cannot be changed)

Hint

It may be necessary to set an exception rule in the company firewall or company IPS (intrusion prevention system, e.g. Snort) that allows RDP connections even without using port 3389.

See also Screen sharing client-side

Federation

General	Port
Communication, e.g. with Skype for Business, MTLS protocol See also Federation	5061

VoIP Ready

The XPhone Call Controller and its functions, such as the softphone, are dependent on being used in a VoIP Ready network for smooth operation (good voice quality, no delays). To achieve the best possible user experience, the following requirements must be met:

• QoS on all affected switches/routers and endpoints according to IEEE802.p;

• DiffServ (RFC 2474) or ToS (RFC 791) (QoS/DSCP)

• Time synchronicity

• Maximum 50ms delay in one direction (one way delay);

• Maximum 150ms total delay

• Highest 3% packet loss

• Maximum 20ms jitter

• Maximum 40% network utilization in the affected segments.

Time synchronization

The network must be time synchronized to ensure reliable operation. The synchronization of clocks in the network is a prerequisite for “VoIP Ready” and can be enabled via NTP (Network Time Protocol), for example.

Quality of Service (DSCP)

In order to be able to give preferential treatment to the audio IP packets in the network, the Windows operating system provides some options. These are either set directly via the registry or can be distributed via group policy. DSCP (Differentiated Services Code Point) can be used to define the priority of outgoing network traffic. As described in RFC 2474, DSCP allows values from 0 to 63 to be specified in the TOS (Type of Service) field of an IPv4 packet. Network routers use the DSCP value to classify network packets and determine the appropriate queue. A higher value indicates a higher priority of the packet. A QoS policy must be used on the network (if not already in place). The QoS policy must apply a DSCP value. For more information, see the XPhone Connect Server documentation (QoS Configuration).

Hint

For an outsourced XCC on a Linux Satellite, the QoS parameters are set automatically.

Firewall settings for screen sharing

For screen sharing to work between XPhone Connect Clients in the network, the local firewall rules may need to be adapted or distributed via group guidelines. If screen sharing does not work between the clients, the following information must be observed when troubleshooting:

• Network

  Only the Peers are involved, i.e. the respective computers involved with XPhone Connect Client. The computers’ local firewalls are of relevance here. In the computer’s firewall settings, this is regulated via the entry for the XPhone Connect Client application. All network traffic must be permissible there (inbound and outbound).

• Protocol

  RDP is used as a protocol for transferring the images. This should not be confused with the Remote desktop service (Terminal Server service) or Remote assistance (remote support). We are not aware of any situation for the actual RDP protocol where it could be blocked separately.

• Authentication

  The Desktop Sharing API used for screen sharing provides a secret for authentication which is sent to the other client via an excrypted channel. Accordingly, this feature is independent of the set types of authentication and the recommended setting can be retained (Authentication at network level).

• Services

  The Remote desktop service (Terminal Server service) and Remote assistance (Remote support) Windows services also use the Remote Desktop Protocol RDP, whereby the latter also uses the Desktop Sharing API. If Remote assistance works, the requirements for XPhone Connect screen sharing should also be in place but the same does not necessarily apply vice versa, i.e. screen sharing may still work even when remote support is deactivated.

Have you found a mistake on this page?

Or is something not formulated well or too vague? Then we look forward to receiving an e-mail, preferably with a suggestion for improvement, to doku@c4b.de. Thank you very much!