Design principles and guidelines for the reverse proxy and TURN server

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

Reverse proxy application

In Pexip Infinity deployments, all Pexip Connect app clients use HTTPS for the call signaling connections towards Conferencing Nodes.

The reverse proxy application is responsible for proxying HTTP/HTTPS requests from Connect app WebRTC and desktop clients to one or more Conferencing Nodes. If you are using VMR Scheduling for Exchange, the reverse proxy application can also be used to proxy and load balance requests from Outlook clients.

To proxy these requests, the reverse proxy application must be able to communicate with these externally-located clients as well as the Conferencing Nodes. This means that the reverse proxy must be able to reach any internally-located 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).

TURN server application

As the reverse proxy does not handle media, the TURN server application enables external clients to exchange RTP/RTCP media (i.e. ensure audio/video connectivity) with the Conferencing Nodes.

A TURN server is a media relay/proxy that allows peers to exchange UDP or TCP media traffic whenever one or both parties are behind NAT. When Conferencing Nodes are deployed behind NAT (and they are not configured for static NAT), these nodes will instruct the WebRTC client to send its media packets to the TURN server, which will forward (relay) the packets to the Conferencing Nodes. Since this TURN server is normally located outside of the enterprise firewall, the Conferencing Node will constantly send media packets to this TURN server to "punch holes" in the firewall, allowing this TURN server to relay media packets back to the Conferencing Node, as the firewall will classify this as return traffic.

When using a TURN server with a Conferencing Node:

  • Conferencing Nodes only use TURN over UDP (not TCP). However, Conferencing Nodes will perform ICE TCP negotiation.
  • Conferencing Nodes always communicate with its configured TURN server over a single UDP port (default UDP/3478). UDP media is multiplexed from the Conferencing Node to that single port on the TURN server. The TURN server will reply back to the same port pair on the Conferencing Node. The TURN server never initiates a connection towards a Conferencing Node.
  • As general good practice, we always recommend deploying the TURN server in a suitably secured network segment, such as a DMZ.

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 for ICE to work between the Conferencing Node and clients using ICE (such as Skype for Business / Lync clients and Connect app 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 is referred to as such in this guide.

Example communication scenario

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 appears as coming from 198.51.100.2, which means that 198.51.100.2 is the reflexive address of the Conferencing Node.

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

See When is a reverse proxy, TURN server or STUN server required? for guidelines of when each type of device is required in your deployment.