DNS record examples
This section describes the DNS records required for endpoints, federated Lync / Skype for Business 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 example.com to allow:
- SIP and H.323 endpoint registration messages to be routed to Pexip Infinity
- calls from non-registered 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 |
---|---|
conf01.example.com. | 198.51.100.40 |
conf02.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 — conf01.example.com and conf02.example.com.
Name | Service | Protocol | Priority | Weight | Port | Target host |
---|---|---|---|---|---|---|
example.com. example.com. |
h323cs h323cs |
tcp tcp |
10 10 |
10 10 |
1720 1720 |
conf01.example.com. conf02.example.com. |
example.com. example.com. |
h323ls h323ls |
udp udp |
10 10 |
10 10 |
1719 1719 |
conf01.example.com. conf02.example.com. |
example.com. example.com. |
h323rs h323rs |
udp udp |
10 10 |
10 10 |
1719 1719 |
conf01.example.com. conf02.example.com. |
example.com. example.com. |
sip sip |
tcp tcp |
10 10 |
10 10 |
5060 5060 |
conf01.example.com. conf02.example.com. |
example.com. example.com. |
sip sip |
udp * udp * |
10 10 |
10 10 |
5060 5060 |
conf01.example.com. conf02.example.com. |
example.com. example.com. |
sips sips |
tcp tcp |
10 10 |
10 10 |
5061 5061 |
conf01.example.com. conf02.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.example.com. 86400 IN SRV 10 10 1720 conf01.example.com. _h323cs._tcp.example.com. 86400 IN SRV 10 10 1720 conf02.example.com. _h323ls._udp.example.com. 86400 IN SRV 10 10 1719 conf01.example.com. _h323ls._udp.example.com. 86400 IN SRV 10 10 1719 conf02.example.com. _h323rs._udp.example.com. 86400 IN SRV 10 10 1719 conf01.example.com. _h323rs._udp.example.com. 86400 IN SRV 10 10 1719 conf02.example.com. _sip._tcp.example.com. 86400 IN SRV 10 10 5060 conf01.example.com. _sip._tcp.example.com. 86400 IN SRV 10 10 5060 conf02.example.com. _sip._udp.example.com. 86400 IN SRV 10 10 5060 conf01.example.com. _sip._udp.example.com. 86400 IN SRV 10 10 5060 conf02.example.com. _sips._tcp.example.com. 86400 IN SRV 10 10 5061 conf01.example.com. _sips._tcp.example.com. 86400 IN SRV 10 10 5061 conf02.example.com. conf01.example.com. 86400 IN A 198.51.100.40 conf02.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 Lync / Skype for Business environments
To ensure that calls from remote Lync / Skype for Business environments are routed to your Conferencing Node, a DNS SRV record in the format _sipfederationtls._tcp.<domain> must be created.
Example
Assume that the following _sipfederationtls._tcp.example.com DNS SRV and associated A-record have been created:
_sipfederationtls._tcp.example.com. 86400 IN SRV 1 100 5061 sip.example.com. sip.example.com. 86400 IN A 198.51.100.40
The SRV record points to the DNS A‑record sip.example.com (this is a typical convention in Lync / Skype for Business environments), port 5061, with a priority of 1 and a weight of 100. In other words, it tells Lync / Skype for Business to send its TLS requests to sip.example.com on TCP port 5061. The A-record then resolves sip.example.com to the node's IP address (198.51.100.40).
In your actual deployment, the domain and host IP address should be changed to use the real name and address of your Conferencing Node.
Note that the domain name used in the SRV record has to match the domain in the corresponding A-record. This is required due to the trust model for Lync/SfB federation. Using our example:
- _sipfederationtls._tcp.example.com must use the same domain as sip.example.com
- you cannot, for example, configure the _sipfederationtls._tcp.example.com SRV record to point to sip.video.example.com or conf01.otherdomain.com).
For more information, see Pexip Infinity configuration for public DMZ deployments with remote Lync / Skype for Business environments.
Enabling access from the Infinity Connect Mobile client and the Infinity Connect desktop client
To enable participants to connect to conferences within your deployment using 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 reverse proxy (for deployments where Conferencing Nodes are located within a private network), but it can also be a public-facing Conferencing Node.
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 reverse proxy or 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 or reverse proxy
- reference port 443 on the host.
Example
Assume that the following _pexapp._tcp.example.com DNS SRV records have been created:
_pexapp._tcp.example.com. 86400 IN SRV 10 100 443 proxy1.example.com. _pexapp._tcp.example.com. 86400 IN SRV 20 100 443 proxy2.example.com.
These point to the DNS A‑records proxy1.example.com, port 443 (HTTPS), with a priority of 10 and a weight of 100, and proxy2.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 proxy1.example.com (our primary reverse proxy server) on TCP port 443. The desktop client will also try to use host proxy2.example.com (our fallback server) if it cannot contact proxy1.
- The Infinity Connect Mobile client will send its HTTP requests either to proxy1.example.com or to proxy2.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 client and Infinity Connect desktop client use.