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:

  • conf01.example.com (Conferencing Node 1)
  • conf02.example.com (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 (conf03.example.com, conf04.example.com 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 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 Lync MSSIP domain to, in this case, example.com.
  5. Create a Lync federation DNS SRV record and its associated A-records for the SIP domain example.com (which will use the sip.example.com hostname and round-robin DNS to refer to the 2 Conferencing Nodes).
  6. Ensure that 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 Lync clients.

Optional configuration:

* Note that where this documentation refers to "Lync", 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 example.com 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 example.com in use by Office365, you will already have sip.example.com 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>.example.com. 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 vc.example.com, your DNS A record hostname that refers to your DMZ Conferencing Nodes would be sip.vc.example.com, your _sipfederationtls._tcp SRV record would need to be _sipfederationtls._tcp.vc.example.com. and your individual Conferencing Node hostnames would be conf01.vc.example.com, conf02.vc.example.com etc.

Assigning publicly-issued TLS server certificates to Conferencing Nodes

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

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

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

commonName = sip.example.com
altNames = sip.example.com, conf01.example.com, conf02.example.com

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. conf01.example.com and conf02.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 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 conf01.example.com Conferencing Node has been set to conf01.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 sip.example.com round-robin DNS A-records, which in our example also includes the conf02.example.com Conferencing Node).

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

Configuring the Lync MSSIP domain

You must specify the name of the SIP domain that is routed from Lync to Pexip Infinity for this deployment. This domain is inserted into the From header in outbound calls from Pexip Infinity to Lync, and ensures that Lync 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 Lync MSSIP domain setting:

Typically this will be set to the same SIP domain as used elsewhere in the deployment, which is example.com 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. vc.example.com.

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 environments towards the domain example.com are routed to our Conferencing Node, the following DNS SRV record must be created:

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

The DNS SRV record should:

  • point to the DNS A-records that refer to our Conferencing Nodes (in our case using the hostname sip.example.com)
  • 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 federation. Using our example:

  • _sipfederationtls._tcp.example.com must use the same domain as sip.example.com
  • you cannot, for example, configure the _sipfederationtls._tcp.example.com SRV record to point to sip.video.example.com or conf01.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 sip.example.com 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 calls from federated peers, we have 2 round-robin DNS A-records for the sip.example.com hostname:

Hostname Host IP address
sip.example.com. 198.51.100.40
sip.example.com. 198.51.100.41

Even if you only intend initially to use a single Conferencing Node to receive incoming Lync 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 sip.example.com 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
conf01.example.com. 198.51.100.40
conf02.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.

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

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

Note that:

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

To ensure that each Conferencing Node uses DNS to locate an appropriate 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 Lync server.

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

 

It should now be possible to send and receive calls between Pexip Infinity Conferencing Nodes and federated 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. conf03.example.com.
  • Configure the new Conferencing Node's SIP TLS FQDN setting to reflect its DNS FQDN e.g. conf03.example.com.
  • Add a DNS A-record for the new hostname e.g.

    conf03.example.com.       86400 IN A 198.51.100.42

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.