Certificate and DNS examples for public DMZ / hybrid integrations with Skype for Business

This topic contains example Conferencing Node naming patterns, certificate, and DNS requirements for enabling direct federation with remote Skype for Business / Lync* environments. It also includes the DNS requirements for B2B federation with remote VTC systems.

You can use these examples 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.

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

Common rules for all example scenarios

These examples show different naming scenarios for your Pexip Infinity environment that illustrate the relationships between node hostnames, the certificates on those nodes and their associated DNS requirements:

Common naming and certificate rules

Each pool of Conferencing Nodes that are handling the signaling for a domain/subdomain must be dedicated to that domain/subdomain. Thus, if you want to support multiple domains/subdomains, you must have multiple pools of Conferencing Nodes. In our examples this would be one pool of nodes to handle the signaling for the vc.example.com subdomain, and a separate pool of nodes to handle the signaling for companyname.vc. However, each pool of nodes can share and make use of a common overflow location of Transcoding Conferencing Nodes (see Shared overflow/transcoding resources for more information).

In all of these scenarios, for all of your Conferencing Nodes in the public DMZ that are involved in call signaling:

  • 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/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.

Example 1: B2B and SfB/Lync federation to vc.example.com (VTC subdomain)

This example sets up B2B and SfB/Lync federation to the VTC subdomain of vc.example.com. A subdomain is typically required if the enterprise domain (and sip.<domain>) is already associated with an Office365 environment.

The following _sipfederationtls._tcp.vc.example.com DNS SRV and associated round-robin A-records will be utilized by calls from federated SfB/Lync clients that are placed to the vc.example.com Pexip domain. The DNS records will route the call 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:

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

In addition, the following DNS SRV records will route calls from H.323 devices, SIP devices and Connect app clients (via the _pexapp SRV record) placed to the @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.

Example 2: B2B and SfB/Lync federation to companyname.vc (alternative main domain)

This example shows how to enable B2B and SfB/Lync federation to a different top-level enterprise domain — companyname.vc in this case.

The following _sipfederationtls._tcp.companyname.vc DNS SRV and associated round-robin A-records will be utilized by calls from federated SfB/Lync clients that are placed to the companyname.vc Pexip domain. The DNS records will route the call to your Pexip Conferencing Nodes in the public DMZ (using the pool hostname px.companyname.vc):

_sipfederationtls._tcp.companyname.vc. 86400 IN SRV 1 100 5061 px.companyname.vc.
px.companyname.vc.                     86400 IN A 198.83.90.40
px.companyname.vc.                     86400 IN A 198.83.90.41

Note that these A-records specified for the px.companyname.vc 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:

px01.companyname.vc.         86400 IN A 198.83.90.40
px02.companyname.vc.         86400 IN A 198.83.90.41

In addition, the following DNS SRV records will route calls from H.323 devices, SIP devices and Connect app clients (via the _pexapp SRV record) placed to the @companyname.vc domain to your Pexip Conferencing Nodes in the public DMZ:

_h323cs._tcp.companyname.vc. 86400 IN SRV 10 10 1720 px01.companyname.vc.
_h323cs._tcp.companyname.vc. 86400 IN SRV 10 10 1720 px02.companyname.vc.

_h323ls._udp.companyname.vc. 86400 IN SRV 10 10 1719 px01.companyname.vc.
_h323ls._udp.companyname.vc. 86400 IN SRV 10 10 1719 px02.companyname.vc.

_sip._tcp.companyname.vc.    86400 IN SRV 10 10 5060 px01.companyname.vc.
_sip._tcp.companyname.vc.    86400 IN SRV 10 10 5060 px02.companyname.vc.

_sips._tcp.companyname.vc.   86400 IN SRV 10 10 5061 px01.companyname.vc.
_sips._tcp.companyname.vc.   86400 IN SRV 10 10 5061 px02.companyname.vc.

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

Shared overflow/transcoding resources

While each pool of Conferencing Nodes that are handling the signaling for a domain/subdomain must be dedicated to that domain/subdomain, all of those pools can share and make use of a common overflow pool of Transcoding Conferencing Nodes. The following example shows how a common pool of transcoding resources can be used to handle calls for multiple domains — vc.example.com, abc.example.com and companyname.vc in this case.

The Edge nodes (that are handling the signaling connection with the devices for calls to their respective domain/subdomain):

  • must have appropriate certificates installed for the domain/subdomain they are handling for federated SfB/Lync clients (as described above).
  • must have appropriate associated DNS records to route calls for their respective domain/subdomain to those nodes (as described above).
  • they can be Proxying Edge Nodes (and so all media transcoding is forwarded to the overflow nodes).
  • or they can be Transcoding Conferencing Nodes (and thus media transcoding is only performed on nodes in the overflow location when the Edge nodes are at capacity).

The Transcoding Conferencing Nodes in the overflow location (providing they are not receiving any call signaling):

  • do not require certificates to be installed.
  • do not require associated DNS records.

This means that even if you need to handle calls from multiple domains, you can provide a large, common pool of shared transcoding resources and easily add more Transcoding Conferencing Node resources as and when required (including dynamic bursting to a cloud service if required).