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/SfB environments to communicate with our public DMZ Pexip environment through federated connections, we must complete the following steps:
- Plan DNS names for your environment.
- Assign publicly-issued TLS server certificates to the Conferencing Nodes.
- Configure the SIP TLS FQDN setting for the Conferencing Nodes.
- Configure the Pexip Infinity domain to, in this case, example.com.
- Create a Lync/SfB 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).
- 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.
- Adding additional Conferencing Nodes for extra media capacity.
- Public DMZ deployment with multiple SIP domains for Lync / Skype for Business federation if you need to support multiple subdomains or top-level domains.
- Configuring Pexip Infinity nodes to work behind a NAT device if you want to deploy your Conferencing Nodes behind static NAT.
* Note that where this documentation refers to "Lync/SfB", it represents both Microsoft Lync and Skype for Business unless explicitly stated otherwise.
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.
To enable a Pexip Infinity public DMZ deployment to receive incoming Lync/SfB 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/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 = 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:
- From the Management Node, go to and select .
- Copy-paste the TLS certificate and its associated Private key into the relevant text boxes, or alternatively use the links to upload the certificate and private key files.
- 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.
- Select Conferencing Nodes. . The certificate and private key will be pushed automatically to the selected
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 toand selecting .
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 , 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.
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 Pexip Infinity domain (for Lync / Skype for Business integration) setting:and configuring the
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/SfB 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
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/SfB 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 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/SfB calls from federated peers, we have 2 round-robin DNS A-records for the sip.example.com 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 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|
(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 example.com domain will now be routed to sip.example.com 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.
- The remote Lync/SfB environment must be configured to allow Lync/SfB federation towards the example.com 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.
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.
- Go to .
- 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.
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.