Infrastructure#

Virtualization#

Warning

When using XPhone Server, XPhone Satellite or an SQL server in a VM, snapshots and migration during operation are not permitted. Snapshots may only be created when the system is switched off.
- SQL servers in clusters are excluded from this, as they are specially designed for this purpose.
If it turns out that a VM does not comply with the specifications, we reserve the right to suspend support for this machine until it has been completely reinstalled.

XPhone Server

We recommend setting the MAC address of the virtual machine statically. If the MAC address remains dynamic, the hardware ID of the server may change when the VM is moved or migrated within the hypervisor. As a result, the licensing of the XPhone server becomes invalid. In this case, all users lose their assigned client licenses and can no longer use the XPhone Client until the server is relicensed.
XPhone Call Controller

Configure the Virtualization host for Quality of Service.
UM services
- When connecting UM services in virtual environments, sufficient system capacity must be available at all times for the XPhone Connect IP channels (XCAPI interface). A dedicated processor core is an advantage. Further information can be found in the XCAPI technical documentation.
- In a virtual environment, the virtualized machine must also use the hardware timer of the host system, as purely virtualized timers are usually not accurate enough for voice transmission. For detailed information on hardware/virtual timers, please refer to the virtualization provider’s documentation.
- XCAPI on Xen Server
  The (Windows) server on which the XCAPI is installed must be manually assigned a MAC address in the following format:
  
  00-16-3E-XX-XX-XX
  
  The values XX must be replaced accordingly (freely selectable) by the customer.
  
  The first 3 digits are XEN-specific and the XCAPI recognizes the virtual system. The server must be restarted. Then a virtual ID can be read out in the XCAPI configuration (as with normal VMware). As always, the license must be requested with this virtual ID

Hosting concepts#

The hosting scenarios that are possible with XPhone Connect Mobile and 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 Meeting 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.

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 clients or mobile Mobile Apps 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).

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.

push

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 addresses: 17.0.0.0/8

Network#

Connection overview#

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.

ports

	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	XPhone Connect Server	Satellite with XPhone Call Controller	4899	TCP	SIP	Internal gateway
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 the 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		PBX / SBC
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 Automatic determination of the server)

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.

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 IEEE 802.1p;
DiffServ (RFC 2474) or ToS (RFC 791) (QoS/DSCP)
Time synchronicity
Maximum 50ms delay in one direction (one way delay);
Maximum 150ms total delay
Maximum 3% package 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)#

The Windows operating system offers several options for prioritizing audio IP packets in the network. These can be set directly via the registry or distributed via group policy. DSCP (Differentiated Services Code Point) can be used to define the priority of outgoing network traffic. According to RFC 2474, DSCP values from 0 to 63 can 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 for the packet. A QoS policy must be used in the network (if not already in place). The QoS policy must apply a DSCP value. For more information, refer to the XPhone Connect Server documentation (QoS Configuration).

Hint

With a remote 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 transmitted to the other client via an encrypted channel. This means that the function is independent of the authentication types set and the recommended setting can be retained (network-level authentication).
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.