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.
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.
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 a 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.
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 in this guide.
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.
See When is a reverse proxy, TURN server or STUN server required? for summary guidelines of when each type of device is required in your deployment.