DNS record examples
This section describes the DNS records required for endpoints, federated Skype for Business / Lync environments and Infinity Connect clients to access Pexip Infinity services.
You can use the tool at http://dns.pexip.com to lookup and check SRV records for a domain.
Enabling endpoints to discover Conferencing Nodes
The following examples show the records that are required in DNS for endpoints to discover Pexip Infinity Conferencing Nodes.
It shows example DNS A and SRV records for the domain vc.example.com to allow:
- SIP and H.323 endpoint registration messages to be routed to Pexip Infinity
- calls from SIP and H.323 endpoints to be routed to Pexip Infinity
If you have multiple Conferencing Nodes, you must set up DNS A and SRV records for each node.
Host DNS A-records
This example assumes there are 2 Conferencing Nodes, thus 2 DNS A-records are required.
| Hostname | Host IP address |
|---|---|
| px01.vc.example.com. | 198.51.100.40 |
| px02.vc.example.com. | 198.51.100.41 |
In your actual deployment, both the Hostname and Host IP address should be changed to use the real names and addresses of your Conferencing Nodes.
DNS SRV records
The following DNS SRV records are required for H.323 and SIP services. For each service there should be one record per host (Conferencing Node). Therefore, in this example, there are 2 records per service — one for each target host — px01.vc.example.com and px02.vc.example.com.
| Name | Service | Protocol | Priority | Weight | Port | Target host |
|---|---|---|---|---|---|---|
| vc.example.com. vc.example.com. |
h323cs h323cs |
tcp tcp |
10 10 |
10 10 |
1720 1720 |
px01.vc.example.com. px02.vc.example.com. |
| vc.example.com. vc.example.com. |
h323ls h323ls |
udp udp |
10 10 |
10 10 |
1719 1719 |
px01.vc.example.com. px02.vc.example.com. |
| vc.example.com. vc.example.com. |
h323rs h323rs |
udp udp |
10 10 |
10 10 |
1719 1719 |
px01.vc.example.com. px02.vc.example.com. |
| vc.example.com. vc.example.com. |
sip sip |
tcp tcp |
10 10 |
10 10 |
5060 5060 |
px01.vc.example.com. px02.vc.example.com. |
| vc.example.com. vc.example.com. |
sips sips |
tcp tcp |
10 10 |
10 10 |
5061 5061 |
px01.vc.example.com. px02.vc.example.com. |
| vc.example.com. vc.example.com. |
sip sip |
udp * udp * |
10 10 |
10 10 |
5060 5060 |
px01.vc.example.com. px02.vc.example.com. |
| * SIP UDP is disabled on Pexip Infinity by default. | ||||||
In your actual deployment, both the Name and the Target host should be changed to use the real domain name and host names of your Conferencing Nodes.
In these examples, the DNS records would be:
_h323cs._tcp.vc.example.com. 86400 IN SRV 10 10 1720 px01.vc.example.com. _h323cs._tcp.vc.example.com. 86400 IN SRV 10 10 1720 px02.vc.example.com. _h323ls._udp.vc.example.com. 86400 IN SRV 10 10 1719 px01.vc.example.com. _h323ls._udp.vc.example.com. 86400 IN SRV 10 10 1719 px02.vc.example.com. _h323rs._udp.vc.example.com. 86400 IN SRV 10 10 1719 px01.vc.example.com. _h323rs._udp.vc.example.com. 86400 IN SRV 10 10 1719 px02.vc.example.com. _sip._tcp.vc.example.com. 86400 IN SRV 10 10 5060 px01.vc.example.com. _sip._tcp.vc.example.com. 86400 IN SRV 10 10 5060 px02.vc.example.com. _sips._tcp.vc.example.com. 86400 IN SRV 10 10 5061 px01.vc.example.com. _sips._tcp.vc.example.com. 86400 IN SRV 10 10 5061 px02.vc.example.com. _sip._udp.vc.example.com. 86400 IN SRV 10 10 5060 px01.vc.example.com. _sip._udp.vc.example.com. 86400 IN SRV 10 10 5060 px02.vc.example.com. px01.vc.example.com. 86400 IN A 198.51.100.40 px02.vc.example.com. 86400 IN A 198.51.100.41
If the ability to implement geographically-aware DNS exists, then different weights and priorities could be set on the SRV records for different locations. For example, if there is both a European and a North American site, each with separate DNS servers, the European one could return European Pexip nodes at a higher priority than the North American nodes, and vice versa.
Enabling direct federation with remote Skype for Business / Lync environments
In public DMZ / hybrid deployments with remote Skype for Business / Lync environments, to ensure that calls from those remote SfB/Lync environments are routed to your Conferencing Nodes, a DNS SRV record in the format _sipfederationtls._tcp.<domain> must be created.
Example
Assume that the following _sipfederationtls._tcp.vc.example.com DNS SRV and associated A-records have been created:
_sipfederationtls._tcp.vc.example.com. 86400 IN SRV 1 100 5061 px.vc.example.com. px.vc.example.com. 86400 IN A 198.51.100.40 px.vc.example.com. 86400 IN A 198.51.100.41
The SRV record points to the DNS A‑record px.vc.example.com, port 5061, with a priority of 1 and a weight of 100. In other words, it tells Skype for Business / Lync to send its TLS requests to px.vc.example.com on TCP port 5061.
We then have 2 round-robin DNS A-records for the px.vc.example.com pool hostname that resolves px.vc.example.com to the IP addresses of our 2 Conferencing Nodes (198.51.100.40 and 198.51.100.41).
Even if you only intend initially to use a single Conferencing Node to receive incoming SfB/Lync calls, this pool-based approach allows you to easily add more nodes in the future. (In your actual deployment, the hostnames (including the pool hostname) and host IP addresses should be changed to use the real hostnames and IP addresses of your Conferencing Nodes.)
Note that these A-records specified for the px.vc.example.com pool are required in addition to the "standard" A-records that will exist for each Conferencing Node based on their individual hostnames and resolve to the same IP addresses,
In your actual deployment, the domain and host IP address should be changed to use the real name and address of your Conferencing Node.
The domain name used in the _sipfederationtls._tcp.<domain> SRV record has to match the domain in the corresponding A-record. This is required due to the trust model for SfB/Lync federation. For example:
- An SRV record such as _sipfederationtls._tcp.vc.example.com must have a corresponding A-record with the same domain, such as px.vc.example.com.
- You cannot, for example, configure the _sipfederationtls._tcp.vc.example.com SRV record to point to px.video.example.com or px01.otherdomain.com.
For more information, see Pexip Infinity configuration for public DMZ / hybrid deployments with remote Skype for Business / Lync environments and Certificate and DNS examples for public DMZ / hybrid integrations with Skype for Business / Lync.
Enabling access from the Infinity Connect Mobile client and the Infinity Connect desktop client
To enable participants to connect to conferences via the Infinity Connect desktop client or Infinity Connect Mobile client, you must provide a DNS lookup so that these clients know which host to contact. 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 these desktop and mobile clients, each domain used in aliases in your deployment must either have an 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.
Example
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.
For more information, see Setting up DNS records for Infinity Connect mobile and desktop client use.