Certificate and DNS examples for an on-premises integration with Skype for Business / Lync

This topic contains example Conferencing Node naming patterns, certificate, and DNS requirements for an on-premises integration with Skype for Business / Lync. It also includes the DNS requirements for B2B federation with remote SfB/Lync and VTC systems.

You can use this example as the basis for your own integration, changing the example domain and DNS names as appropriate for your particular environment.

General information on managing certificates can be found at Certificate creation and requirements for Skype for Business / Lync integrations.

* Note that where this documentation refers to "SfB/Lync", it represents both Microsoft Skype for Business and Lync unless stated otherwise.

Example deployment scenario

In this example, our on-premises SfB/Lync Front End Pool is configured with a trusted application pool of Conferencing Nodes, and that application pool has an identity/FQDN of confpool-eu.vc.example.com. The SfB/Lync Edge servers have a pool name of sip.example.com (sip.<domain> is the typical naming convention for the SfB/Lync Edge server pool name).

Enterprise Conferencing Node configuration

For all of your enterprise-based Pexip Infinity Conferencing Nodes that are involved in call signaling with your on-premises SfB/Lync systems:

  • The SIP TLS FQDN setting on each Conferencing Node must match the node's DNS FQDN and it must be unique per node. For example, if the node's DNS FQDN is conf01.vc.example.com then its SIP TLS FQDN setting must also be conf01.vc.example.com.
  • The certificate on each Conferencing Node must refer to the Trusted Application Pool FQDN (as configured in SfB/Lync and used as the destination of the static route from SfB/Lync to Pexip) and it must also contain the Conferencing Node DNS FQDNs. We recommend that you generate and use a single SAN certificate that encompasses all of the Conferencing Nodes in the application pool:

    • The Subject name (commonName attribute) must be the Trusted Application Pool FQDN (such as confpool-eu.vc.example.com in our examples).
    • The Subject Alternative Name (altNames attribute) entries must include the Trusted Application Pool FQDN (i.e. a repeat of the Subject name), plus the FQDNs of all of the nodes in the pool that are involved in signaling.
    • Assign the same certificate to all of the enterprise nodes that are involved in call signaling.

Public DMZ Conferencing Node configuration

For all of your public DMZ-based Pexip Infinity Conferencing Nodes that are involved in call signaling with your B2B and federated systems:

  • The SIP TLS FQDN setting on each Conferencing Node must match the node's DNS FQDN and it must be unique per node. For example, if the node's DNS FQDN is px01.vc.example.com then its SIP TLS FQDN setting must also be px01.vc.example.com.
  • The certificate on each Conferencing Node must include the hostname referenced by the _sipfederationtls._tcp SRV record that points to those nodes, plus the names of all of the Conferencing Nodes that are involved in call signaling:

    • The Subject name (commonName attribute) should be set to the target hostname referenced by the _sipfederationtls._tcp SRV record (the pool name of the Conferencing Nodes).

      In our examples, if the DNS SRV record is:

      _sipfederationtls._tcp.vc.example.com. 86400 IN SRV 1 100 5061 px.vc.example.com.

      then the Subject name must be px.vc.example.com

    • The Subject Alternative Name (altNames attribute) entries must include:

      • the target hostname referenced in the Subject name
      • the FQDNs of all of the public DMZ nodes that are involved in call signaling
      • the domain names that are used in any DNS SRV records that route calls to those Conferencing Nodes (e.g. vc.example.com from the example _sipfederationtls SRV record above).
    • Assign the same certificate to all of the public DMZ nodes that are involved in call signaling.
  • 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.

DNS requirements for SfB/Lync and VTC federation

Here is a summary of the DNS requirements to support federation for SfB/Lync and VTC endpoints. These examples assume that:

  • The SfB/Lync domain is example.com.
  • The Pexip Infinity VTC subdomain is vc.example.com.
  • There are two Pexip Conferencing Nodes in the public DMZ (px01 and px02, and they have a DNS poolname of px.vc.example.com).

Your standard DNS A records for your public DMZ Conferencing Nodes will typically already exist:

px01.vc.example.com.         86400 IN A 198.51.100.40
px02.vc.example.com.         86400 IN A 198.51.100.41

Federation for the main SfB/Lync domain (example.com)

Typically, your main federation DNS SRV record for SfB/Lync clients will already exist.

This SRV record ensures that federated SfB/Lync clients that are calling contacts who have a "user@example.com" style name are routed to the SfB/Lync Edge server. For our example.com domain it would typically be:

_sipfederationtls._tcp.example.com. 86400 IN SRV 1 100 5061 sip.example.com.

To allow external VTC systems to dial SfB/Lync clients with user@example.com contact names, dial directly into SfB/Lync meetings, or dial a Pexip Virtual Reception (for example sfb.lobby@example.com) you must configure additional public DNS SRV records. These example records will direct calls from H.323 devices, SIP devices and Infinity Connect clients (via the _pexapp SRV record) that are placed to the top-level example.com domain to your Pexip Conferencing Nodes in the public DMZ (that are hosted in the vc.example.com subdomain):

_h323cs._tcp.example.com. 86400 IN SRV 10 10 1720 px01.vc.example.com.
_h323cs._tcp.example.com. 86400 IN SRV 10 10 1720 px02.vc.example.com.

_h323ls._udp.example.com. 86400 IN SRV 10 10 1719 px01.vc.example.com.
_h323ls._udp.example.com. 86400 IN SRV 10 10 1719 px02.vc.example.com.

_sip._tcp.example.com.    86400 IN SRV 10 10 5060 px01.vc.example.com.
_sip._tcp.example.com.    86400 IN SRV 10 10 5060 px02.vc.example.com.

_sips._tcp.example.com.   86400 IN SRV 10 10 5061 px01.vc.example.com.
_sips._tcp.example.com.   86400 IN SRV 10 10 5061 px02.vc.example.com.

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

Note that before configuring these DNS records you should check that there are no other example.com records already configured that are routing such calls elsewhere. (You can use the tool at http://dns.pexip.com to lookup and check SRV records for a domain.)

You then need to configure appropriate Virtual Reception and/or Call Routing Rules on your Pexip Infinity system that will route those calls (placed to @example.com) onwards to the SfB/Lync server. See Using Pexip Infinity as a Skype for Business / Lync gateway for more information.

Federation for the Pexip Infinity subdomain (vc.example.com)

To enable federation for SfB/Lync clients that want to connect to internal VTC systems (e.g. calls placed to alias@vc.example.com) through your Pexip Conferencing Nodes in the public DMZ, you need a federation DNS SRV record for your Pexip Infinity subdomain.

The _sipfederationtls._tcp.vc.example.com DNS SRV and associated round-robin A-records shown below will route calls from federated SfB/Lync clients that are placed to the Pexip Infinity subdomain (@vc.example.com) to your Pexip Conferencing Nodes in the public DMZ (using the pool hostname px.vc.example.com):

_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

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 addition, the following public DNS SRV records will route calls from H.323 devices, SIP devices and Infinity Connect clients (via the _pexapp SRV record) placed to your @vc.example.com subdomain to your Pexip Conferencing Nodes in the public DMZ:

_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.

_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.

_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.

Local DNS requirements for on-premises SfB/Lync and VTCs

This section shows example local DNS records to enable on-premises SfB/Lync and VTC systems to integrate with Pexip Infinity.

Internal and remote corporate SfB/Lync routing to VTC systems

In our example deployment, remote corporate and on-premises SfB/Lync clients can call VTC systems by calling <alias>@vc.example.com.

Even though vc.example.com is not the SfB/Lync domain, as these are corporate clients the call is always routed to the SfB/Lync server, and that server is configured with a static route to direct any calls placed to @vc.example.com to the application pool of Conferencing Nodes.

In DNS, ensure that the following records are configured:

  • An A-record for each Conferencing Node. In our example this is 2 records with host names of conf01 and conf02, and they each point to the individual IP address of the node.
  • Another A-record per Conferencing Node. This time the host name of every record should be confpool-eu.vc.example.com (the application pool name of the Conferencing Nodes), and again associate it with the IP address of each Conferencing Node. This step is not required for Skype for Business servers, but is necessary for Lync servers as it allows Lync to spread the traffic across all of the Conferencing Nodes.

For example (change the IP addresses as appropriate for your actual deployment):

conf01.vc.example.com.         86400 IN A 10.44.0.10
conf02.vc.example.com.         86400 IN A 10.44.0.11
confpool-eu.vc.example.com.    86400 IN A 10.44.0.10  (only required for Lync deployments)
confpool-eu.vc.example.com.    86400 IN A 10.44.0.11  (only required for Lync deployments)

Internal VTC systems routing to SfB/Lync

In our example deployment, on-premises VTC systems and Infinity Connect clients can call SfB/Lync clients or join SfB/Lync meetings via Pexip Infinity by calling <user/meeting_ID>@example.com.

To route those calls to SfB/Lync, Pexip Infinity must be configured with suitable Call Routing Rules (see Using Pexip Infinity as a Skype for Business / Lync gateway for more information).

In these examples, the local DNS records to support H.323 and SIP endpoints, and Infinity Connect clients that dial @example.com i.e. calls to SfB/Lync clients and meetings, would be:

_h323cs._tcp.example.com. 86400 IN SRV 10 10 1720 conf01.vc.example.com.
_h323cs._tcp.example.com. 86400 IN SRV 10 10 1720 conf02.vc.example.com.

_h323ls._udp.example.com. 86400 IN SRV 10 10 1719 conf01.vc.example.com.
_h323ls._udp.example.com. 86400 IN SRV 10 10 1719 conf02.vc.example.com.

_sip._tcp.example.com.    86400 IN SRV 10 10 5060 conf01.vc.example.com.
_sip._tcp.example.com.    86400 IN SRV 10 10 5060 conf02.vc.example.com.

_sips._tcp.example.com.   86400 IN SRV 10 10 5061 conf01.vc.example.com.
_sips._tcp.example.com.   86400 IN SRV 10 10 5061 conf02.vc.example.com.

_pexapp._tcp.example.com. 86400 IN SRV 10 10 443  conf01.vc.example.com.
_pexapp._tcp.example.com. 86400 IN SRV 10 10 443  conf02.vc.example.com.

conf01.vc.example.com.    86400 IN A 10.44.0.10
conf02.vc.example.com.    86400 IN A 10.44.0.11

In addition, those VTC devices and Infinity Connect clients may also want to call into Pexip Infinity-hosted VMRs or other gatewayed devices with addresses in the form <alias>@vc.example.com. The local DNS records to support those calls would be:

_h323cs._tcp.vc.example.com. 86400 IN SRV 10 10 1720 conf01.vc.example.com.
_h323cs._tcp.vc.example.com. 86400 IN SRV 10 10 1720 conf02.vc.example.com.

_h323ls._udp.vc.example.com. 86400 IN SRV 10 10 1719 conf01.vc.example.com.
_h323ls._udp.vc.example.com. 86400 IN SRV 10 10 1719 conf02.vc.example.com.

_sip._tcp.vc.example.com.    86400 IN SRV 10 10 5060 conf01.vc.example.com.
_sip._tcp.vc.example.com.    86400 IN SRV 10 10 5060 conf02.vc.example.com.

_sips._tcp.vc.example.com.   86400 IN SRV 10 10 5061 conf01.vc.example.com.
_sips._tcp.vc.example.com.   86400 IN SRV 10 10 5061 conf02.vc.example.com.

_pexapp._tcp.vc.example.com. 86400 IN SRV 10 10 443  conf01.vc.example.com.
_pexapp._tcp.vc.example.com. 86400 IN SRV 10 10 443  conf02.vc.example.com.

conf01.vc.example.com.       86400 IN A 10.44.0.10
conf02.vc.example.com.       86400 IN A 10.44.0.11

(The A records for the individual Conferencing Nodes are the same for routing via @example.com and via @vc.example.com.)