Setting up DNS records and firewalls for Infinity Connect client connectivity

DNS records

You must set up DNS records so that the Infinity Connect clients know which host to contact when placing calls or registering to Pexip Infinity.

The host will typically be a public-facing Conferencing Node (for on-premises deployments where your Transcoding Conferencing Nodes are located within a private network we recommend that you deploy public-facing Proxying Edge Nodes).

To enable access from the Infinity Connect desktop clients and Infinity Connect mobile clients, each domain used in aliases in your deployment must either have a DNS SRV record for _pexapp._tcp.<domain>, or resolve directly to the IP address of a public-facing Conferencing Node.

The SRV records for _pexapp._tcp.<domain> should always:

  • point to an FQDN which must be valid for the TLS certificate on the target Conferencing Nodes
  • reference port 443 on the host.

Note that SRV records are not required for the Infinity Connect web app — the web app clients connect to Conferencing Nodes directly via DNS A-records, so no SRV lookup is required.

Ultimately it is the responsibility of your network administrator to set up SRV records correctly so that the Infinity Connect desktop client and Infinity Connect mobile client know which system to connect to.

You can use the tool at to lookup and check SRV records for a domain.

Firewall configuration

Infinity Connect clients connect to a Conferencing Node, so you must ensure that any firewalls between the two permit the following connections:

  • Infinity Connect mobile client > Conferencing Node port 443 TCP
  • Infinity Connect (all clients) > Conferencing Node ports 40000–49999 TCP/UDP
  • Conferencing Node ports 40000–49999 TCP/UDP > Infinity Connect (all clients)

For more information, see Pexip Infinity port usage and firewall guidance.

Using Infinity Connect from outside your network

In many cases, your Pexip Infinity deployment will be located inside a private network. If this is the case and you want to allow Infinity Connect users who are located outside your network (for example on another organization's network, from their home network, or the public internet) to connect to your deployment, you need to provide a way for those users to access those private nodes.

Since version 16 of Pexip Infinity, we recommend that you deploy Proxying Edge Nodes instead of a reverse proxy and TURN server if you want to allow externally-located clients to communicate with internally-located Conferencing Nodes. A Proxying Edge Node handles all media and signaling connections with an endpoint or external device, but does not host any conferences — instead it forwards the media on to a Transcoding Conferencing Node for processing.

If you do not want to deploy Proxying Edge Nodes, and thus want to route all signaling and media from external clients via a reverse proxy and a TURN server to your internal/on-premises nodes, you should note that only Pexip's Infinity Connect WebRTC clients (web app for Chrome, Firefox, Opera and Safari (version 11 onwards), the mobile clients for iOS and Android, and the desktop client) will be able to establish media connectivity. Microsoft Edge browsers and any RTMP-based browsers (Internet Explorer and Safari (versions 6-10)) cannot use a TURN server and thus will not be able to send or receive media. For more information, see Pexip Reverse Proxy and TURN Server.

Further information and connectivity examples

Information on how each of the Infinity Connect clients attempts to locate a Conferencing Node when placing a call is described in the following sections. Within each section is an example of the lookup process for that client. The example uses the following records:

Assume that the following DNS SRV records have been created: 86400 IN SRV 10 100 443 86400 IN SRV 20 100 443

These point to the DNS A‑records, port 443 (HTTPS), with a priority of 10 and a weight of 100, and, port 443, with a relatively lower priority of 20 and a weight of 100.

This tells the Infinity Connect desktop and mobile clients to initially send their HTTP requests to host (our primary node) on TCP port 443. The clients will also try to use host (our fallback node) if they cannot contact px01.