Getting Started

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

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

IIS on XPhone Server

concept_pw

The web applications are installed on the XPhone Server using the XPhone as a UC Solution mode. In this setup, the IIS on the XPhone Server acts as the communication partner for the XPhone Connect Mobile app and XPhone Meeting participants. Therefore, IIS must be configured accordingly for HTTPS-encrypted connections, and certificates must be installed. If Meeting is used in addition to Mobile, a public certificate is mandatory. A public certificate is also recommended for XPhone Connect Mobile. XPhone Connect Mobile typically connects to the web server via HTTPS using an FQDN that resolves the public IP address of IIS in the DNS. The ports forwarded in the firewall for the IIS can be freely selected and configured in the URL for the XPhone Mobile Apps. If video is used in meetings, the LiveKit server must be accessible via port 7880. LiveKit runs either on the XPhone Connect Server or on an external Satellite.

Hint

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

IIS in DMZ

concept_iisdmz

In this setup, the web applications are installed on a separate server in the DMZ. In this case, the IIS server in the DMZ acts as the communication partner for the XPhone Connect Mobile app and the meeting participants. XPhone Connect Mobile typically connects to the web server via HTTPS using an FQDN that resolves to the IIS server’s public IP address in DNS. The ports forwarded in the firewall for IIS can be freely selected and configured in the URL for the XPhone Mobile Apps. Therefore, IIS must be configured accordingly for HTTPS-encrypted connections, and certificates must be installed. The IIS must be able to reach the XPhone server ports TCP 2230 and 2231. If video is used in meetings, the IIS must also be able to reach the LiveKit server via port 7880. LiveKit runs either on the XPhone Connect Server or on an external satellite.

Hint

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

Reverse proxy in DMZ

concept_rpdmz

In this setup, the reverse proxy acts as the communication partner for both the XPhone Connect Mobile app and the meeting participants. Therefore, the reverse proxy must be configured to support HTTPS-encrypted connections, and certificates must be installed. The connection to the XPhone Server does not need to be encrypted. Thus, the web application (mobile/webmeeting) remains on the XPhone Server (XPhone operating mode as a UC solution). If video is used in meetings, the reverse proxy must also be able to reach the LiveKit server via port 7880. LiveKit runs either on the XPhone Connect Server or on an external satellite.

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#

Softphone Mobile and Softphone Desktop#

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

Meeting#

Audio#

Audio streams in meetings are routed through the XPhone Call Controller (FreeSwitch). The same network requirements apply as for Softphone Mobile and Softphone Desktop (see above). The configuration of the XPhone Call Controller is described in the chapter Meetings.

Video and screen sharing#

For video and screen sharing in meetings, LiveKit is used as the media server. LiveKit can be run either on the XPhone Connect Server or off-site on a Linux satellite.

Signaling (WebSocket) is transmitted from the browser via IIS (/XPhoneConnect/ReverseProxy/) to the LiveKit server on port 7880. Video streams (RTP), on the other hand, are transmitted directly between the browser and LiveKit via the configured UDP port range.

  • The LiveKit server must be accessible via port 7880 (TCP) for IIS or the reverse proxy. This port does not need to be exposed to the internet.

  • The source port range for video RTP communication is UDP 33001–34000 (default) and can be configured in the Web-Administration. These ports must be accessible from the outside (similar to the RTP port range of the XPhone Call Controller for audio).

  • If IIS or a reverse proxy is hosted externally, it must be able to access the LiveKit server via port 7880.

The complete configuration is described in the chapter Meetings.

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)
Google (Android)

XPhone Server -> Google (Sending push notifications):

Mobile app -> Google (Receiving push notifications):

Hint

This applies only if there is a firewall between the mobile app and Google (e.g., an internal company Wi-Fi network). This does not apply when using a cellular network or guest Wi-Fi.

  • Protocol: TCP

  • Destination ports: 5228, 5229, 5230, and 443

Hint

5229 and 5230 serve as fallbacks and should also be enabled. The connection must be direct (no proxy), and the NAT/firewall timeout must be at least 30 minutes.

Apple (iOS)

XPhone Server -> Apple (Sending push notifications):

Mobile app -> Apple (Receiving push notifications):

Hint

This applies only if there is a firewall between the mobile app and Apple (e.g., internal company Wi-Fi). This does not apply when using a cellular network or guest Wi-Fi.

  • Protocol: TCP

  • Destination Port: 5223 (Fallback: 443)

  • IP addresses: 17.0.0.0/8

Network#

Connection overview#

Attention

Any Application Layer Gateway for SIP that may be present on the firewall must be disabled, or all SIP ports in use must be opened.

Hint

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

ports

Source

Destination

Listener-Port(s)

Protocol

Others

1

Client

Server

2230

TCP / WCF

1

Client

IIS

80/443

TCP / http/s
Terget: https://<domain>/xphoneconnect/AppLink
Terget: https://<domain>/xphoneconnect/Applink2
Additional Information: Dashboard

2

Client

XCC

30000-34000

UDP / SRTP

Changeable

2

XCC

Client

49152-65535

UDP / SRTP

Additional information

3

Client

STUN server

3478, 3479

UDP / STUN
Additional information
:ref:` <net-stun> Configuration`

4

Server

C4B Push Service

443

TCP / https
Target: https://mobile.c4b.de/pushconfig
Additional information

5

Server

Google Push Service

443

TCP / https
Target: “https://fcm.googleapis.com/”
Target: https://fcm.googleapis.com/fcm/send
Additional information

6

Server

Apple Push Service

443 (2197)

TCP / https
Target: https://api.push.apple.com
IP addresses: 17.0.0.0/8
Additional information

7

Server

Satellite with XCC
3280
22
TCP / gRPC
TCP / SSH

Configuration

8

Server

Satellite with XCC

4901

TCP / SIP

Changeable

8

Server

Satellite with XCC

4899

TCP / SIP

Internal gateway

8

Satellite with XCC

Server

4900

TCP /SIP

Changeable

8

Server

Satellite with XCC

8021

TCP / Event Socket

9

IIS

Server

2231

TCP / gRPC

Additional information

10

IIS

Server

2230

TCP / WCF

Additional information

10

IIS / Reverse-Proxy

LiveKit server (Server or Satellite)

7880

TCP / http
For video and screen sharing during meetings.
Additional information

11

Satellite with XCC

Mobile

ANY

UDP /SRTP
Additional information
This also applies to smartphones connected to Wi-Fi.

11
Mobile
Meeting Participants

Satellite with XCC

30000–33000 (Audio) 33001–34000 (Video)

UDP / SRTP
Additional information
Changeable

12

TURN

Satellite with XCC

30000-34000

UDP / SRTP
Additional information
Changeable

12

Satellite with XCC

TURN server

Depends on the TURN server

UDP / SRTP
Additional information
Configuration

12

Satellite with XCC

TURN server

Depends on TURN server Default: 443,3478

TCP / https
Additional information
Configuration

13

Satellite with XCC

STUN server

3478, 3479

UDP / https
Configuration
:ref:`SIP Gateway Configuration <sip-gw-anysoft-cnnctn> `

14

Satellite with XCC

PBX / SBC

5060

TCP/UDP / SIP
Depending on the PBX/SBC settings
Configuring the SIP Gateway

14

Satellite with XCC

PBX / SBC

*

UDP / RTP
Depending on the PBX/SBC
Configuration

14

PBX / SBC

Satellite with XCC

5060

TCP/UDP / SIP
Depending on the PBX/SBC settings
Configuring the SIP Gateway

14

PBX / SBC

Satellite with XCC

30000-33000

UDP / RTP

Changeable

15

Mobile

Google Push Service

5228 5229 5230

TCP / https
Additional information
This also applies to smartphones connected to Wi-Fi.

16

Mobile

Apple Push Service

5223

TCP / https

Additional information Also applies to smartphones on WLAN.

17

Mobile

IIS

443

TCP / https
Target: https://<domain>/xphoneconnect/mobile
Target: https://<domain>/xphoneconnect/webclientapi
Additional information

18

Mobile

TURN

depends on TURN server

UDP / SRTP
Additional information
Configuration

18

Mobile

TURN

depends on TURN server Default: 443,3478

TCP / https

Additional information

18

TURN

Mobile

49152-65535

UDP / SRTP

Configuration

19

Mobile

STUN

3478

UDP / STUN

Additional information

20

Server

PBX

Depending on PBX

CSTA/TAPI

PBX / SBC

21

Satellite with XCC

NTP

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.

See also Screen sharing client-side

Federation

General

Port

Communication to federation systems via MTLS.

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 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. Synchronizing the clocks on the network is a prerequisite for VoIP Ready and can be achieved, for example, using NTP (Network Time Protocol).

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.

Your opinion matters!

Be it praise, helpful ideas, or a tip about an error – we truly appreciate every message.
Just send us an email at doku@c4b.de. And help us make this documentation even better.
Thank you very much for your support!