Pexip Infinity configuration for public DMZ / hybrid deployments with remote Skype for Business environments

This section describes the Pexip Infinity configuration for an example public DMZ / hybrid deployment with remote Skype for Business / Lync* environments such as Office 365 and Skype for Business / Lync Online as well as traditional enterprise Skype for Business / Lync environments.

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

In this example, two Pexip Infinity Conferencing Nodes have been deployed in a public DMZ, as follows:

  • px01.vc.example.com
  • px02.vc.example.com

These Conferencing Nodes will handle the SIP signaling for the incoming calls. In general, for redundancy or load balancing we recommend a maximum of 2 or 3 Conferencing Nodes for handling incoming calls, which ideally are hosted on different physical servers for extra resiliency. These nodes may be Transcoding Conferencing Nodes (and optionally with additional overflow Transcoding Conferencing Nodes — px03.vc.example.com, px04.vc.example.com and so on — for extra capacity), or you could deploy px01 and px02 as Proxying Edge Nodes in front of a pool of Transcoding Conferencing Nodes.

The deployment process assumes that the Management Node and the Conferencing Nodes have already been configured with basic settings, such as an IP address and a DNS server, and that the Conferencing Nodes have already been configured with one or more Virtual Meeting Room aliases for the SIP domain to be used.

To allow remote SfB/Lync environments to communicate with our public DMZ Pexip environment through federated connections, we must complete the following steps:

  1. Plan DNS names for your environment.
  2. Assign publicly-issued TLS server certificates to the Conferencing Nodes.
  3. Set the Configured FQDN for the Conferencing Nodes.
  4. Configure the Pexip Infinity domain to, in this case, vc.example.com.
  5. Create a SfB/Lync federation DNS SRV record and its associated A-records for the SIP domain vc.example.com (which will use the px.vc.example.com hostname and round-robin DNS to refer to the 2 Conferencing Nodes).
  6. Ensure that SfB/Lync servers are not associated with a location so that each Conferencing Node uses DNS to locate an appropriate system via which to route outbound calls to SfB/Lync clients.

Optional configuration:

Hybrid deployments

You should follow these public DMZ guidelines for a hybrid deployment of on-premises and Office 365 where SfB/Lync users may be homed in either environment. Currently Microsoft does not support Trusted Application routing from an Office 365 tenant which is part of a hybrid deployment. Therefore, our recommended approach for a hybrid deployment is to only use federation, which is explained in this section. In this scenario, all users route to Pexip Infinity via the SfB/Lync federation DNS SRV record.

Planning DNS names for your environment

In this example environment, the subdomain vc.example.com is used as the SIP domain and is used in all of the configuration examples. Use this as a model for your deployment, adapting the naming patterns as appropriate for your own environment.

You can use your main domain (such as example.com) for your Pexip environment, but If that domain is already in use by Office365 (you will typically have the sip.example.com hostname associated with that environment), then — to avoid any conflicts — you must use a subdomain for your Pexip environment i.e. <subdomain>.example.com.

See Certificate and DNS examples for public DMZ / hybrid integrations with Skype for Business for more information about synchronizing your DNS records and certificate names.

Assigning publicly-issued TLS server certificates to Conferencing Nodes

To enable a Pexip Infinity public DMZ deployment to receive incoming SfB/Lync calls from federated peers, one or more of the Conferencing Nodes (px01.vc.example.com and px02.vc.example.com in our example) in the public DMZ must be configured with a publicly-issued TLS server certificate. This ensures that remote SfB/Lync environment Edge Servers will trust the Conferencing Node.

If only inbound call support is required, a certificate needs to be installed only on the Conferencing Node (or nodes, as in our example) referenced by the _sipfederationtls._tcp SRV record. These referenced nodes will handle the SIP signaling; media processing will be dynamically distributed among all the Conferencing Nodes assigned to the same location (or in any overflow locations).

However, if outbound Pexip Infinity to SfB/Lync call support is required, all of the Conferencing Nodes within the public DMZ must have publicly-issued certificates installed. This is because outbound calls from Pexip Infinity to SfB/Lync may be initiated by any Conferencing Node.

In deployments where inbound and outbound call support is required, we recommend that you generate and use a single SAN certificate that encompasses all of the Conferencing Nodes in the public DMZ.

In the certificate:

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

Therefore, in our example, the Subject name (commonName) and SAN (altNames) sections for the certificate to be installed on every Conferencing Node would be configured as:

commonName = px.vc.example.com
altNames = px.vc.example.com, px01.vc.example.com, px02.vc.example.com, vc.example.com

To assign a server certificate and private key to one or more Conferencing Nodes:

  1. From the Management Node, go to Certificates > TLS certificates and select Add TLS certificate.
  2. Copy-paste the TLS certificate and its associated Private key into the relevant text boxes, or alternatively use the select the file links to upload the certificate and private key files.
  3. In the Nodes section, from the Available Nodes list, select every Conferencing Node referenced by the _sipfederationtls._tcp SRV record (e.g. px01.vc.example.com and px02.vc.example.com in our example), or every node within the public DMZ if outbound calling support is required, and move them into the Chosen Nodes list.
  4. Select Save. The certificate and private key will be pushed automatically to the selected Conferencing Nodes.

If the server certificate has been issued by one or more intermediate CAs (Certificate Authorities), these intermediate certificates must be uploaded. You can upload them as a single-file bundle by going to Platform > Trusted CA certificates and selecting Import.

Setting the Configured FQDN for the Conferencing Nodes

After the certificates have been uploaded to the Conferencing Nodes, the Configured FQDN setting for each node should be configured to reflect its unique DNS FQDN. This is done on the Management Node, by going to Platform > Conferencing Nodes, choosing each Conferencing Node in turn and populating the Configured FQDN field:

The example above shows that the Configured FQDN for the px01.vc.example.com Conferencing Node has been set to px01.vc.example.com. This FQDN has to match one of the Subject Alternative Names in the certificate installed on the Conferencing Node. You must do this for each Conferencing Node that supports inbound calling (those that are referenced by the px.vc.example.com round-robin DNS A-records, which in our example also includes the px02.vc.example.com Conferencing Node).

If outbound calling support is required, you must do this for every Conferencing Node within the public DMZ.

Configuring the Pexip Infinity domain

You must specify the name of the SIP domain that is routed from SfB/Lync to Pexip Infinity for this deployment. This domain is inserted into the From header in outbound calls from Pexip Infinity to SfB/Lync, and ensures that SfB/Lync can route messages back to Pexip Infinity when, for example, initiating content sharing.

You specify this by going to Platform > Global settings > Connectivity and configuring the Pexip Infinity domain setting:

Typically this will be set to the same SIP domain/subdomain as used elsewhere in the Pexip deployment, which is vc.example.com in this case.

Creating a Skype for Business / Lync federation DNS SRV record for your domain and its associated A-records

To ensure that calls from remote SfB/Lync environments towards the domain vc.example.com are routed to our pool of Conferencing Nodes, the following DNS SRV record must be created:

_sipfederationtls._tcp.<domain> where <domain> in our case is vc.example.com, resulting in the DNS SRV record
_sipfederationtls._tcp.vc.example.com.

The DNS SRV record should:

  • point to the DNS A-records that refer to our Conferencing Nodes (in our case using the pool hostname px.vc.example.com)
  • have the port set to 5061 (required value)
  • have a priority of 1 (recommended value)
  • have a weight of 100 (recommended value)

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.

The following illustration show how the SRV record would look in Microsoft DNS Manager. (This is for illustration purposes only – the actual video DNS domain may be managed through other DNS providers.)

DNS A-records

DNS A-records must exist for the hostname specified in the _sipfederationtls._tcp SRV record (which is px.vc.example.com in our case).

This could be a single record, or as in our example, where for resiliency and capacity purposes we have a pool of 2 Conferencing Nodes configured to receive incoming SfB/Lync calls from federated peers, we have 2 round-robin DNS A-records for the px.vc.example.com hostname:

Hostname Host IP address
px.vc.example.com. 198.51.100.40
px.vc.example.com. 198.51.100.41

Even if you only intend initially to use a single Conferencing Node to receive incoming SfB/Lync calls, this pool-based approach allows you to easily add more nodes in the future. (In your actual deployment, the hostnames (including the pool hostname) and host IP addresses should be changed to use the real hostnames and IP addresses of your Conferencing Nodes.)

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, for example:

Hostname Host IP address
px01.vc.example.com. 198.51.100.40
px02.vc.example.com. 198.51.100.41

(Again, the Hostname and Host IP address should reflect the real names and addresses of your Conferencing Nodes.)

The IP address must be the public address of the Conferencing Node if it is located behind a NAT.

In these examples, the DNS records would be:

_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
px01.vc.example.com.                   86400 IN A 198.51.100.40
px02.vc.example.com.                   86400 IN A 198.51.100.41

With the DNS SRV record and A-records created correctly, calls from remote SfB/Lync environments towards the vc.example.com domain will now be routed to px.vc.example.com and resolve to your Conferencing Nodes, allowing any remote SfB/Lync environment to call into the Pexip Infinity environment.

Note that:

  • The remote SfB/Lync environment must be configured to allow SfB/Lync federation towards the vc.example.com domain.
  • To make an outbound call to another SfB/Lync user in a remote SfB/Lync environment, a _sipfederationtls._tcp.<remote_domain> record for that remote domain must exist. Even though you (as the administrator for your own domain) will not have any authority over the DNS records for that <remote_domain> — and are not responsible for creating them — you should check that such records exist when troubleshooting any outbound calling issues.

Ensuring that Skype for Business / Lync servers are not associated with a location

To ensure that each Conferencing Node uses DNS to locate an appropriate SfB/Lync system via which to route outbound calls, you must ensure that each Pexip Infinity location is not configured to route calls to a specific SfB/Lync server.

  1. Go to Platform > Locations.
  2. Select each location in turn and ensure that nothing is selected in the Lync / Skype for Business server field.

It should now be possible to send and receive calls between Pexip Infinity Conferencing Nodes and federated SfB/Lync clients.

Adding additional Conferencing Nodes for extra media capacity

If you add an extra Conferencing Node in the public DMZ to provide extra media capacity, you must:

  • Update the single SAN certificate used on every existing Conferencing Node, as well as the new node, to include in the altNames section the hostname of the new node e.g. px03.vc.example.com.
  • Configure the new Conferencing Node's Configured FQDN setting to reflect its DNS FQDN e.g. px03.vc.example.com.
  • Add a DNS A-record for the new hostname e.g.

    px03.vc.example.com.       86400 IN A 198.51.100.42

It is not necessary to create a new round robin DNS A-record for your Conferencing Node pool (px.vc.example.com in our case) for every new Conferencing Node. Only do this if you want the new Conferencing Node to handle incoming call signaling. In general we recommend a maximum of 2 or 3 Conferencing Nodes to handle the incoming signaling.