Certificate and DNS examples for a Microsoft Teams integration

This topic contains example Conferencing Node naming patterns, certificate, and DNS requirements for an integration with Microsoft Teams. 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 installing, requesting and managing certificates can be found at Managing TLS and trusted CA certificates.

Example deployment scenario

In this example deployment scenario:

  • The Pexip Infinity platform is on the vc.example.com VTC subdomain. It has (optional) privately-addressed Conferencing Nodes on the enterprise network, and (mandatory) publicly-reachable Conferencing / Edge Nodes in the public DMZ.
  • The Pexip Teams Connector is a publicly-reachable application in Microsoft Azure at pexip-teamsconn-eu.teams.example.com.
  • Externally-located SIP devices, H.323 devices and Pexip Connect apps can call into the platform to be routed into Microsoft Teams conferences (or other Pexip Infinity services) using aliases in the format <alias>@example.com and/or <alias>@vc.example.com.

    Your choice of routing via your primary domain (example.com in this case) and/or via your Pexip subdomain (vc.example.com) depends on your existing environment and dial plan requirements. For example, if your environment already includes DNS records and routing for SIP and H.323 devices to your primary domain for other purposes, then you can use the Pexip subdomain (vc.example.com) as your interoperability route into Teams for all call protocols.

    Routing via your primary domain is preferable as it allows for simpler dial-in addresses such as teams@example.com (see example invitation, right).

  • Federated Skype for Business / Lync clients can also call into the platform using aliases in the format <alias>@vc.example.com.
  • Enterprise-based SIP devices, H.323 devices and Pexip Connect apps can call into Microsoft Teams conferences (or other Pexip Infinity services) using aliases in the format <alias>@example.com and <alias>@vc.example.com.

The following diagram shows the example Conferencing Node naming patterns, certificate, and DNS requirements to support these call scenarios.

Example Conferencing Node naming patterns, certificate, and DNS requirements

Note that the same Conferencing Nodes can be used for all other Pexip Infinity services, such as routing calls into Microsoft Skype for Business and Lync environments, and the certificate and DNS naming requirements and examples are compatible with all Pexip Infinity deployment scenarios.

Teams Connector and Conferencing Node certificates

In summary, the certificate usage principles are:

  • The Teams Connector and Pexip Infinity validate the connection in both directions by TLS client certificate validation. This means that every certificate's Enhanced Key Usage properties must be set for both server and client authentication.

  • Public-facing Conferencing Nodes must have a valid publicly-signed PEM-formatted certificate (typically with a .CRT or .PEM extension).
  • The Teams Connector must have a publicly-signed PFX-formatted certificate. Multiple names/certificates are required if deploying Teams Connectors in several regions.

Teams Connector certificate requirements

You must install on the Teams Connector a TLS certificate that has been signed by an external trusted CA (certificate authority).

You need to have this certificate available before you install the Teams Connector.

The certificate must be in Personal Information Exchange Format (PFX), also known as PKCS #12, which enables the transfer of certificates and their private keys from one system to another. It must use RSA keys.

  1. Decide on the FQDN (DNS name) you will use for the Teams Connector load balancer in Azure that will front the Teams Connector deployment e.g. pexip-teamsconn-eu.teams.example.com.

    • This FQDN is what you will use as:

      • the value of $PxTeamsConnFqdn in the variables initialization script
      • the certificate's subject name
      • the DNS name you will configure in Pexip Infinity (Call control > Microsoft Teams Connectors > Address of Teams Connector) later in the process.
    • It can use the same domain space as your Pexip Infinity deployment (i.e. vc.example.com in this example), or your Teams deployment, or it can use an altogether different domain. In all cases you always need to create the necessary DNS CNAME record(s) and public certificates for the chosen domain.
    • If you intend to deploy other Teams Connectors in other Azure regions, you will need a different DNS name for each Teams Connector and a certificate that matches that identity. You can use a single certificate for this, containing Subject Alternative Name (altNames attribute) entries for all of the regional Teams Connectors.
    • It can be a wildcard certificate, where the wildcard character ('*') is the only character of the left-most label of a DNS domain name. Note that Pexip supports RFC 6125 — this means that if you are using subdomains then, for example, a wildcard certificate of *.example.com would match foo.example.com but not bar.foo.example.com or example.com.
  2. Request a certificate for that name and generate the certificate in PFX format. Any intermediate certificates must also be in the PFX file.

You can use the Pexip Infinity Management Node to generate a certificate signing request (CSR).

You can use the Pexip Infinity Management Node to convert PEM certificates to PFX format (or vice versa), by uploading a PEM-formatted certificate and then downloading it again in PFX format. When downloading you can also include the private key and all necessary intermediate certificates in the PFX bundle.

Optional: internal/enterprise-based Conferencing Node guidelines

This section describes what is required for any internal/enterprise-based Conferencing Nodes. Enterprise-based nodes are optional and when used they can route calls from your internal VTC systems into Microsoft Teams conferences via the public DMZ-based Conferencing Nodes.

Certificates

For all of your enterprise-based Conferencing Nodes that are involved in call signaling with any on-premises VTC systems:

  • We recommend that you generate and use a single SAN certificate that encompasses all of the enterprise-based Conferencing Nodes:

    • The Subject name should be a common pool name, such as confpool-eu.vc.example.com in our examples.
    • The Subject Alternative Name (altNames attribute) entries must include the Subject name plus the FQDNs of all of the nodes in the pool that are involved in any call signaling, such as conf01.vc.example.com and conf02.vc.example.com in our examples.
  • Assign the same certificate to all of the enterprise Conferencing Nodes that are involved in call signaling.
  • Conferencing Nodes require PEM-formatted certificates (typically with a .CRT or .PEM extension).

DNS records

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 hostnames and 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

To allow enterprise-based VTC systems to dial directly into Microsoft Teams meetings, or dial a Pexip Virtual Reception using aliases in the format <alias>@example.com (for example teams@example.com), you must configure local DNS SRV records. These example records will direct calls from H.323 devices, SIP devices and Connect apps (via the _pexapp SRV record) that are placed to the top-level example.com domain to your Conferencing Nodes in your private enterprise network (that are hosted in the vc.example.com subdomain):

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

In addition, those VTC devices and Connect apps may also want to call into Pexip Infinity services 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.

Public DMZ / Edge Conferencing Node guidelines

This section describes what is required for all of your public DMZ-based Conferencing Nodes that are involved in routing calls from your B2B and federated VTC systems into Microsoft Teams conferences. These examples assume that:

  • The Pexip Infinity platform is on the vc.example.com VTC subdomain.
  • 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

Certificates

The Conferencing Nodes (typically Proxying Edge Nodes) that will communicate with the Teams Connector must have TLS certificates installed that have been signed by an external trusted CA (certificate authority). If a chain of intermediate CA certificates is installed on the Management Node (to provide the chain of trust for the Conferencing Node's certificate) those intermediate certificates must not include any HTTP-to-HTTPS redirects in their AIA (Authority Information Access) section.

The certificate guidelines are the same as for any internal Conferencing Nodes as described above, except that you should use a different pool name and certificate:

  • We recommend that you generate and use a single SAN certificate that encompasses all of the public DMZ-based "Edge" Conferencing Nodes:

    • The Subject name should be a common pool name, such as px.vc.example.com in our examples.
    • The Subject Alternative Name (altNames attribute) entries must include the Subject name plus the FQDNs of all of the nodes in the pool that are involved in any call signaling, such as px01.vc.example.com and px02.vc.example.com in our examples.
  • Assign the same certificate to all of the public DMZ-based Conferencing Nodes that are involved in call signaling and communications with the Teams Connector.
  • Conferencing Nodes require PEM-formatted certificates (typically with a .CRT or .PEM extension).

DNS records for routing calls to @example.com

To allow external VTC systems to dial directly into Microsoft Teams meetings, or dial a Pexip Virtual Reception (for example teams@example.com) you must configure additional public DNS SRV records. These example records will direct calls from H.323 devices, SIP devices and Connect 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 for SIP and H.323 that are already configured and 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 Call Routing Rules on your Pexip Infinity system that will route those calls (placed to @example.com) onwards to Microsoft Teams. See Configuring Pexip Infinity as a Microsoft Teams gateway for more information.

DNS records for routing calls to @vc.example.com

In addition, the following public DNS SRV records will route calls from H.323 devices, SIP devices and Connect apps 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.

Similarly you will then need suitable Call Routing Rules on your Pexip Infinity system to handle calls placed to @example.com.

Support for federated Skype for Business / Lync systems via the vc.example.com subdomain

If you want to enable federation for SfB/Lync clients to allow them to connect to Microsoft Teams (or other Pexip Infinity services) through your Pexip Conferencing Nodes in the public DMZ, you need a federation DNS SRV record for your Pexip Infinity subdomain that will handle calls placed to aliases in the format alias@vc.example.com.

Note that SfB/Lync clients should use direct routing aliases into Teams conferences. If they are routed via a Virtual Reception the call will revert to audio-only during the transfer.

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.

More stringent configuration and certificate guidelines also apply when handling SfB/Lync calls:

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

Note that the _sipfederationtls._tcp SRV record is used to route incoming calls from SfB/Lync clients. If you do not need to support SfB/Lync calls then you do not need a _sipfederationtls._tcp SRV record.

Migrating from — or co-existing with — a Skype for Business environment

If you have an existing Pexip Infinity integration with a Skype for Business / Lync environment, your existing DNS records and certificates should not need to change. Our certificate and DNS examples for on-prem and public DMZ / hybrid SfB/Lync integrations are exactly the same as the examples used here for our Microsoft Teams integration.

You only have to ensure that your Teams Connector certificate also meets our stated requirements.

Pexip Infinity works simultaneously with both Microsoft Teams and Skype for Business. This means that users can be enabled to use both platforms and they can be migrated from one platform to the other at your own pace. Interoperability into either platform is handled by the same single Pexip Infinity installation, and the same Conferencing Nodes.

Typically your main domain (such as example.com) is used by your on-premises or Office 365 SfB/Lync environment, and your main federation DNS SRV record for SfB/Lync clients will already exist, which for our example.com domain it would typically be:

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

By using a subdomain for your Pexip environment i.e. <subdomain>.example.com, such as vc.example.com in our example, you can avoid any conflicts with your SfB/Lync environment.

However, by creating the H.323/SIP/Web App DNS SRV routing records for calls to @example.com as described above, you can provide a dial-in lobby address of:

  • skype@example.com for interoperability into Skype for Business meetings
  • and

  • teams@example.com for interoperability into Teams meetings

and then in each case the user would be directed to the appropriate Pexip Virtual Reception and would enter the appropriate conference ID for the relevant Microsoft meeting platform.

Your SfB/Lync-oriented routing rules in Pexip Infinity would then direct the SfB/Lync calls to your SfB/Lync environment, and your Teams-oriented routing rules would direct the Teams calls into Microsoft Teams via the Teams Connector.