Using TURN servers with Pexip Infinity

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.

ICE (Interactive Connectivity Establishment) is a framework that allows endpoints to discover paths through which they can exchange media — such as via a TURN server — where direct routing between those devices may not be possible, e.g. when a device is on a private network or is behind a NAT.

Conferencing Nodes

Pexip Conferencing Nodes can utilize a TURN server and negotiate TURN relays with the following ICE capable clients:

  • Skype for Business / Lync clients
  • WebRTC clients (the Connect web app on the latest browsers, and the desktop and mobile clients)

If these endpoints will be connecting to privately-addressed "on-premises" Conferencing Nodes, you must configure Pexip Infinity with the address of at least one TURN server that it can offer to ICE clients.

A TURN server is not required if your Conferencing Nodes are publicly-addressable, either directly or via static NAT. For more information, see When is a reverse proxy, TURN server or STUN server required?.

Note that the H.323 specification has no concept of ICE.

The TURN servers that you use with Pexip Infinity:

  • Must have a public address (located either on the public internet or in a DMZ).
  • Unless a separate STUN server has also been configured, they must be deployed in such a way that traffic from the Conferencing Node towards the TURN server appears as coming from the Conferencing Node's public NAT address (its server reflexive address), otherwise this will prohibit some Skype for Business / Lync communication scenarios.
  • Must be routable from your Conferencing Nodes.
  • Must be standards-based (supporting RFC 5766), for example a Pexip TURN server (see Pexip Reverse Proxy and TURN Server) or a VCS Expressway.

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.

Note that Microsoft A/V Edge Server does not support RFC 5766 and therefore cannot be used as a TURN server with Pexip Infinity.

WebRTC clients (Connect app)

WebRTC clients can also be provisioned with the details of one or more TURN servers that they can use to set up bindings on a TURN server for that client to use to exchange media with other ICE-capable clients.

This may typically be required in direct media scenarios (where media is not sent to, or transcoded by, Conferencing Nodes) where the clients cannot route media directly between each other and must use a TURN server to relay the media instead.

In direct media scenarios we recommend using the Pexip TURN server (see Pexip Reverse Proxy and TURN Server), and you must configure it to run in permissive mode. If you use an alternative TURN server it must be a Coturn implementation.

When using direct media we strongly recommend for enhanced security that you use your own dedicated TURN server that is located in your DMZ.

Nominating the TURN servers used by Pexip Infinity and the Connect apps

Within Pexip Infinity you can configure one or more TURN servers. You then associate those TURN servers with each System location (with separate configuration for the TURN server used by Conferencing Nodes in that location, and the TURN server details to provision to Connect apps connected to that Conferencing Node), and with each Call Routing Rule. The same TURN server can be used by more than one location or rule.

Configuring TURN servers

To add, edit or delete TURN server connection details, go to Call control > TURN servers. The options are:

Option Description
Name The name used to refer to this TURN server in the Pexip Infinity Administrator interface.
Description An optional description of the TURN server.
Address The IP address or FQDN of the TURN server.
Port

The IP port on the TURN server to which the Conferencing Node or Connect app will connect.

Default: 3478.

Conferencing Node behavior:

  • When a port is specified, Pexip Infinity performs a DNS A-record lookup on the Address.
  • If a port is not specified, then a _turn._udp DNS SRV lookup on the Address is performed (and the port in the SRV record is used). There is no fallback to an A record lookup if the SRV lookup fails.

The behavior of the Connect app depends on the client web browser (and its implementation of RFC 5928).

TURN server type

Select the type of TURN server and authentication method:

  • Username & Password: authentication is performed with username and password credentials.
  • Time-limited credentials: authenticates via a shared secret for limited time period (currently 5 hours).

Default: Username & Password

TURN transport type

Select the network transport type for communication with the TURN server: UDP, TLS or TCP.

If you want to support multiple transport types you need to define multiple TURN servers.

Default: UDP.

Username and Password

The credentials of an account on the TURN server that can be used to create bindings.

(Only applies for a TURN server type of Username & Password.)

Shared secret

The shared secret used to authenticate with the TURN server. Maximum length: 100 characters.

See https://datatracker.ietf.org/doc/html/draft-uberti-behave-turn-rest-00 for more information about using time-limited credentials.

(Only applies for a TURN server type of Time-limited credentials.)

After adding the details of the TURN server, you must add it to the relevant locations and Call Routing Rules.

Associating TURN servers with Conferencing Nodes

To associate a TURN server with a Conferencing Node, you must configure the node's system location:

  1. Go to Platform > Locations.
  2. Select the Conferencing Node's location.
  3. Select a TURN server and select Save.

All Conferencing Nodes in that location will use the nominated TURN server for conference calls.

Associating TURN servers with gateway calls

If a gateway call is being placed to a Skype for Business / Lync client or Google Meet, the Conferencing Node placing the call will use the TURN server associated with the matching rule. (For gateway calls, the Conferencing Node does not use the TURN sever associated with its system location.)

To associate a TURN server address with a Call Routing Rule:

  1. Go to Services > Call routing.
  2. Select the relevant rule.
  3. Select a TURN server and select Save.

Configuring the TURN servers provided to Connect apps

To configure the specific TURN servers that are provisioned to WebRTC clients (i.e. the Connect app), you must configure the system locations used by the Conferencing Nodes that the clients connect to:

  1. Go to Platform > Locations.
  2. Select the Conferencing Node's location.
  3. Select your Client TURN servers.
  4. Optionally, if you are using direct media, you can select Enforce media routing via a client TURN server if you want to force the WebRTC client to route its media through one of the specified client TURN servers.
  5. Select Save.
  6. Repeat for other locations as necessary.

When a WebRTC client connects to a Conferencing Node in that location, the Conferencing Node will provide it with the details of the nominated TURN servers. These TURN servers may be used by the client to provide a media connectivity path if it cannot make a direct media connection to another client.

How Conferencing Nodes decide which TURN server to offer, and to provision to WebRTC clients

For standard call scenarios, where media is sent to and is transcoded by Conferencing Nodes, the TURN server offered by Conferencing Nodes to ICE clients is determined as follows:

  • Conferences: uses the TURN server associated with the location of the Conferencing Node that is handling the call signaling.
  • Calls placed via the Infinity Gateway: uses the TURN server associated with the Call Routing Rule that matched the call request. If there is no TURN server associated with the rule, then the TURN server associated with the location of the Conferencing Node that is handling the call is used instead. Note that rules can optionally be configured on a per-location basis.

If a TURN server is not configured for the location or rule, a TURN server relay candidate will not be offered.

When a Conferencing Node receives a call from an ICE client, it sends a request to the TURN server to allocate bindings to be used by that client. The client uses these bindings to route its call media through the firewall to the Conferencing Node. The Conferencing Node allocates up to four TURN bindings per call (made up of two TURN bindings per media stream for both audio and video).

Direct media scenarios

In direct media scenarios (where media is not sent to, or transcoded by, Conferencing Nodes) the clients are provisioned with (and should use) the Client TURN servers that are associated with the location of the Conferencing Node that is handling the call signaling.