You are here: Integration > Microsoft Lync / Skype for Business > Public DMZ Infinity configuration

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

This section describes the Pexip Infinity configuration for an example public DMZ deployment with remote Lync / Skype for Business* environments.

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

  • (Conferencing Node 1)
  • (Conferencing Node 2)

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. Optionally, additional media processing nodes (, etc.) may also be deployed if required.

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 Lync/SfB 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. Configure the SIP TLS FQDN setting for the Conferencing Nodes.
  4. Configure the Pexip Infinity domain to, in this case,
  5. Create a Lync/SfB federation DNS SRV record and its associated A-records for the SIP domain (which will use the hostname and round-robin DNS to refer to the 2 Conferencing Nodes).
  6. Ensure that Lync/SfB 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 Lync/SfB clients.

Optional configuration:

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

Planning DNS names for your environment

In this example environment, the domain is used as the SIP domain and is used in all of the configuration examples below. Use this as a model for your deployment, using your own domain and hostnames as appropriate.

Note that if you already have your domain name such as in use by Office365, you will already have associated with that environment. If you intend to use the same main domain for your Pexip deployment, then — to avoid any conflicts — you must use a subdomain for your Pexip environment i.e. <subdomain> You will therefore need to adapt the naming patterns used in these examples when applying them to your own environment. For example, for a subdomain of, your DNS A record hostname that refers to your DMZ Conferencing Nodes would be, your _sipfederationtls._tcp SRV record would need to be and your individual Conferencing Node hostnames would be, etc.

Assigning publicly-issued TLS server certificates to Conferencing Nodes

To enable a Pexip Infinity public DMZ deployment to receive incoming Lync/SfB calls from federated peers, one or more of the Conferencing Nodes ( and in our example) in the public DMZ must be configured with a publicly-issued TLS server certificate. This ensures that remote Lync/SfB 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.

However, if outbound Pexip Infinity to Lync/SfB 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 Lync/SfB 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 hostname referenced by the _sipfederationtls._tcp SRV record
  • Subject Alternative Name (altNames attribute) entries must be included for every individual node in the public DMZ (including the hostname referenced in the Subject name).

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 =
altNames =,,

For more information about creating certificate signing requests, see Certificate creation and requirements for Lync / Skype for Business integrations.

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

  1. From the Management Node, go to Platform configuration > 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. and 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 configuration > Trusted CA certificates and selecting Import.

Configuring the SIP TLS FQDN setting for the Conferencing Nodes

After the certificates have been uploaded to the Conferencing Nodes, the SIP TLS 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 configuration > Conferencing Nodes, choosing each Conferencing Node in turn and populating the SIP TLS FQDN field:

The example above shows that the SIP TLS FQDN for the Conferencing Node has been set to 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 round-robin DNS A-records, which in our example also includes the 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 Lync/SfB to Pexip Infinity for this deployment. This domain is inserted into the From header in outbound calls from Pexip Infinity to Lync/SfB, and ensures that Lync/SfB can route messages back to Pexip Infinity when, for example, initiating content sharing.

You specify this by going to Platform configuration > Global settings and configuring the Pexip Infinity domain (for Lync / Skype for Business integration) setting:

Typically this will be set to the same SIP domain as used elsewhere in the deployment, which is in this case. Note that if you are using the same main domain as Office365 for your Pexip deployment, and therefore using a subdomain for your Pexip environment, this should be the subdomain, e.g.

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

To ensure that calls from remote Lync/SfB environments towards the domain are routed to our Conferencing Node, the following DNS SRV record must be created:

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

The DNS SRV record should:

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

Note that the domain name used in the SRV record has to match the domain in the corresponding A-record. This is required due to the trust model for Lync/SfB federation. Using our example:

  • must use the same domain as
  • you cannot, for example, configure the SRV record to point to or

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 in our case).

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

Hostname Host IP address

Even if you only intend initially to use a single Conferencing Node to receive incoming Lync/SfB calls, this approach allows you to easily add more nodes in the future. (In your actual deployment, both the Hostname and Host IP address should be changed to use the real name of your domain i.e. sip.<your_domain> and the IP addresses of your Conferencing Nodes.)

Note that these A-records specified above for 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

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

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

The Pexip Infinity environment is now ready to accept incoming calls from any remote Lync/SfB environment.

Note that:

  • The remote Lync/SfB environment must be configured to allow Lync/SfB federation towards the domain.
  • To make an outbound call to another Lync/SfB user in a remote Lync/SfB 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 Lync / Skype for Business servers are not associated with a location

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

  1. Go to Platform configuration > 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 Lync/SfB 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.
  • Configure the new Conferencing Node's SIP TLS FQDN setting to reflect its DNS FQDN e.g.
  • Add a DNS A-record for the new hostname e.g.       86400 IN A

It is not necessary to create a new sip.<domain> round robin DNS A-record 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.