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

This topic contains example Conferencing Node naming patterns, certificate, and DNS requirements for an on-premises integration with Skype for Business. It also includes the DNS requirements for B2B federation with remote SfB 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 integrations.

Example deployment scenario

In this example, our on-premises SfB 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 Edge servers have a pool name of sip.example.com (sip.<domain> is the typical naming convention for the SfB 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 systems:

• The Configured 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 Configured 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 and used as the destination of the static route from SfB 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 Configured 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 Configured 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 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 and VTC federation

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

• The SfB 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 domain (example.com)

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

This SRV record ensures that federated SfB clients that are calling contacts who have a "user@example.com" style name are routed to the SfB 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 clients with user@example.com contact names, dial directly into SfB 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 Pexip apps (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 server. See Using Pexip Infinity as a Skype for Business gateway for more information.

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

To enable federation for SfB 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 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 Pexip apps (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 and VTCs

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

Internal and remote corporate SfB routing to VTC systems

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

Even though vc.example.com is not the SfB domain, as these are corporate clients the call is always routed to the SfB 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.

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

Internal VTC systems routing to SfB

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

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

In these examples, the local DNS records to support H.323 and SIP endpoints, and Pexip apps that dial @example.com i.e. calls to SfB 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 Pexip apps 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.)