Setting up DNS records for Infinity Connect client connectivity

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 http://dns.pexip.com to lookup and check SRV records for a domain.

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, 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 _pexapp._tcp.vc.example.com DNS SRV records have been created:

_pexapp._tcp.vc.example.com. 86400 IN SRV 10 100 443 px01.vc.example.com.
_pexapp._tcp.vc.example.com. 86400 IN SRV 20 100 443 px02.vc.example.com.

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

  • This tells the Infinity Connect desktop client to initially send its HTTP requests to host px01.vc.example.com (our primary node) on TCP port 443. The desktop client will also try to use host px02.vc.example.com (our fallback node) if it cannot contact px01.
  • The Infinity Connect mobile client will send its HTTP requests either to px01.vc.example.com or to px02.vc.example.com, depending on the order of the returned SRV records. If it fails to contact the first host, it will not attempt to contact the second host address.