DNS record examples
This section describes the DNS records required to allow endpoints and 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
DNS A‑records are required for endpoints and clients to discover Pexip Infinity Conferencing Nodes. Separate, additional records that resolve to these DNS A‑records are required for SIP and H.323 endpoints, federated Skype for Business / Lync environments and Infinity Connect clients respectively.
The examples below show 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
- calls from remote Skype for Business / Lync environments to Pexip Infinity
- Infinity Connect desktop client and mobile clients for Android to register to Pexip Infinity
- Infinity Connect clients to make calls 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 for SIP and H.323 endpoints
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. |
|
|
||||||
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.
If you have a mixture of public-facing and privately-addressed Conferencing Nodes, ensure that your public-facing SRV records refer to your public-facing Conferencing Nodes (A-records), and vice versa for your local DNS records and your privately-addressed 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 (GeoDNS) 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,
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
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.
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 and Infinity Connect mobile client to initially send their HTTP requests to host px01.vc.example.com (our primary node) on TCP port 443. The clients will also try to use host px02.vc.example.com (our fallback node) if they cannot contact px01.
For more information, see Setting up DNS records and firewalls for Infinity Connect client connectivity.