Design principles and guidelines for the reverse proxy and TURN server

This section describes the network requirements for a reverse proxy and for a TURN server when deployed with Pexip Infinity.

A TURN server can also act as a STUN server, however, in some Pexip Infinity deployment scenarios you may need to configure a separate, external STUN server.

The reverse proxy application is responsible for proxying HTTP requests (via HTTPS) from clients (Infinity Connect Mobile client, and Infinity Connect WebRTC and desktop clients) to one or more Conferencing Nodes. To do this, the reverse proxy application must be able to communicate with both these externally-located clients as well as the Conferencing Nodes. This means that the reverse proxy must be able to reach the Conferencing Nodes either via a routed network or through NAT/port forwarding. The reverse proxy only needs to communicate with the Conferencing Nodes via HTTPS over TCP port 443 (when NAT/port forwarding is used to reach the Conferencing Nodes, the NATted port does not have to be 443, but the NAT/port forward must redirect to TCP/443 on the Conferencing Node).

The TURN server application is responsible for acting as a media relay between external clients and the Conferencing Nodes, so that these external clients can exchange RTP/RTCP media with the Conferencing Nodes. Conferencing Nodes communicate with the TURN server over a single UDP port (default UDP/3478).

Another key responsibility of the TURN server is to act as a STUN server for the Conferencing Nodes – when a Conferencing Node is deployed behind a NAT (from the perspective of clients located on the Internet), the Conferencing Node uses STUN towards the TURN server to discover its public NAT address. The Conferencing Node sends a STUN request to the TURN server, which responds back to the Conferencing Node and tells it from which IP address it received the STUN request. Using this method, the Conferencing Node can discover its public NAT address, which is important in order for ICE to work between the Conferencing Node and clients using ICE (such as Lync / Skype for Business clients and Infinity Connect WebRTC clients). In relation to TURN and ICE, this public NAT address is also known as the server reflexive address or simply reflexive address, and will be referred to as such throughout this section.

Using the above diagram as an example, the Conferencing Node has an IP address of 10.40.0.10 – this is a private/internal IP address which is not routable across public networks. When this Conferencing Node communicates with a host located on a public network (Internet), for instance a DNS server, traffic from this Conferencing Node passes through a NAT device (firewall/router), which will translate the source IP address for this traffic (10.40.0.10) to a public NAT address, in this case 198.51.100.2, before passing the traffic on to its destination. This means that when the DNS server receives the DNS request, the request will appear as coming from 198.51.100.2, which means that 198.51.100.2 is the reflexive address of the Conferencing Node.

For certain Lync / Skype for Business call scenarios to work correctly (notably RDP content sharing with external Lync / Skype for Business clients), it is essential that a Conferencing Node informs the remote Lync / Skype for Business client of this reflexive address. The Lync / Skype for Business client will in turn inform its Lync / Skype for Business Edge of this reflexive address so that the Edge server will relay media packets from the Conferencing Node to the Lync / Skype for Business client.

In some deployment scenarios where the TURN server is not located outside of the enterprise firewall — and thus sees traffic from the Conferencing Nodes as coming from its private address e.g. 10.40.0.10 — a Conferencing Node will not be able to discover its reflexive address (its public NAT address, e.g. 198.51.100.2) by sending its STUN requests to the TURN server. In this case you may need to configure Pexip Infinity with the address of a separate STUN server, such as stun.l.google.com, so that each Conferencing Node can discover its reflexive address.