Public DMZ deployment with multiple SIP domains for Skype for Business federation

For some environments, such as those required by service providers, it may be desirable to support (host) multiple SIP domains for Skype for Business / Lync* federation in a Pexip Infinity public DMZ deployment.

In our example public DMZ deployment, federation support for the SIP domain vc.example.com was implemented. This comprised:

  • two Conferencing Nodes: px01.vc.example.com and px02.vc.example.com
  • a global Pexip Infinity domain of vc.example.com
  • a _sipfederationtls._tcp.vc.example.com DNS SRV record pointing to px.vc.example.com
  • the same SAN certificate installed on every Conferencing Node, configured as:

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

This section describes the considerations and steps that must be taken to add an additional subdomain e.g. abc.example.com or an additional top-level domain e.g. companyname.vc to this existing deployment.

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

Adding an additional subdomain

To add an additional subdomain, such as abc.example.com, to an existing deployment:

  1. Add a new system location.

    • You must add a new Pexip Infinity system location (Platform > Locations) to support each additional subdomain.
    • For example, add a new system location abc to support the subdomain abc.example.com.
  2. Configure the Pexip Infinity domain for the new system location.

    • In our example deployment, the Pexip Infinity domain global setting (Platform > Global settings > Connectivity) has been set to vc.example.com.
    • You must override this global setting for each new location. Go to Platform > Locations and configure the Pexip Infinity domain setting as appropriate for each new location.
    • For example, for location abc, set the Pexip Infinity domain to abc.example.com.
  3. Deploy new Conferencing Nodes.

    • You must deploy new Conferencing Nodes to support each additional subdomain, and they should be assigned to the new system location.
    • For example, add nodes px01.abc.example.com and px02.abc.example.com and assign them to location abc.
  4. Configure additional DNS A records and DNS SRV records for the pool of new Conferencing Nodes.

    For example, for the nodes supporting the subdomain abc.example.com, you would create:

    • SRV-record: _sipfederationtls._tcp.abc.example.com, pointing to pool hostname px.abc.example.com on port 5061
    • Pool round-robin A-record: px.abc.example.com, pointing to your 1st Conferencing Node (the publicly-reachable IP address of px01.abc.example.com)
    • Pool round-robin A-record: px.abc.example.com, pointing to your 2nd Conferencing Node (the publicly-reachable IP address of px02.abc.example.com)
    • Standard A-record: px01.abc.example.com, pointing to the publicly-reachable IP address of px01.abc.example.com
    • Standard A-record: px02.abc.example.com, pointing to the publicly-reachable IP address of px02.abc.example.com

    Note that the domain name used in the SRV-record has to match the domain in the corresponding A-record (e.g.
    _sipfederationtls._tcp.abc.example.com must use the same domain as px.abc.example.com; you cannot, for example, configure the _sipfederationtls._tcp.abc.example.com SRV-record to point to px.example.com). This is required due to the trust model for SfB/Lync federation.

  5. Obtain and install a SAN certificate for the new Conferencing Nodes.

    All of the new Conferencing Nodes in the new location should use the same SAN certificate. The certificate Common Name should be set to the FQDN of the pool hostname referenced by the _sipfederationtls._tcp SRV record, and the SANs should include the FQDNs of all of the nodes in the location, plus the pool hostname and the domain name used in the _sipfederationtls SRV record.

    For example, the certificate for our new nodes would have:

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

    See Certificate creation and requirements for Skype for Business integrations for more information on generating certificate signing requests.

  6. Assign each Conferencing Node's Configured FQDN.

    The Configured FQDN setting for each node should be set to reflect its unique DNS FQDN. Go to Platform > Conferencing Nodes, choose each Conferencing Node in turn and set the Configured FQDN field accordingly.

  7. To provide additional media capacity, you can optionally configure the new abc location to have a Primary overflow location set to the system location used by the original Conferencing Nodes that are supporting the vc.example.com domain (signaling will still be handled by the new nodes in the new location).

Adding an additional top-level domain

To add an additional top-level domain e.g. companyname.vc to an existing deployment:

  1. Add a new system location.

    • You must add a new Pexip Infinity system location (Platform > Locations) to support each additional domain.
    • For example, add a new system location xyz to support the domain companyname.vc.
  2. Configure the Pexip Infinity domain for the new system location.

    • In our example deployment, the Pexip Infinity domain global setting (Platform > Global settings > Connectivity) has been set to vc.example.com.
    • You must override this global setting for each new location. Go to Platform > Locations and configure the Pexip Infinity domain setting as appropriate for each new location.
    • For example, for location xyz, set the Pexip Infinity domain to companyname.vc.
  3. Deploy new Conferencing Nodes.

    • You must deploy new Conferencing Nodes to support each additional domain, and they should be assigned to the new system location.
    • For example, add nodes px01.companyname.vc and px02.companyname.vc and assign them to location xyz.
  4. Configure additional DNS A records and DNS SRV records for the pool of new Conferencing Nodes.

    For example, for the nodes supporting the domain companyname.vc, you would create:

    • SRV-record: _sipfederationtls._tcp.companyname.vc, pointing to pool hostname px.companyname.vc on port 5061
    • Pool round-robin A-record: px.companyname.vc, pointing to your 1st Conferencing Node (the publicly-reachable IP address of px01.companyname.vc)
    • Pool round-robin A-record: px.companyname.vc, pointing to your 2nd Conferencing Node (the publicly-reachable IP address of px02.companyname.vc)
    • Standard A-record: px01.companyname.vc, pointing to the publicly-reachable IP address of px01.companyname.vc
    • Standard A-record: px02.companyname.vc, pointing to the publicly-reachable IP address of px02.companyname.vc

    Note that the domain name used in the SRV-record has to match the domain in the corresponding A-record (e.g.
    _sipfederationtls._tcp.companyname.vc must use the same domain as px.companyname.vc. This is required due to the trust model for SfB/Lync federation.

  5. Obtain and install a SAN certificate for the new Conferencing Nodes.

    All of the new Conferencing Nodes in the new location should use the same SAN certificate. The certificate Common Name should be set to the FQDN of the pool hostname referenced by the _sipfederationtls._tcp SRV record, and the SANs should include the FQDNs of all of the nodes in the location, plus the pool hostname and the domain name used in the _sipfederationtls SRV record.

    For example, the certificate for our new nodes would have:

    commonName = px.companyname.vc
    altNames = px.companyname.vc, px01.companyname.vc, px02.companyname.vc, companyname.vc

    When hosting an additional top-level domain (companyname.vc in our example), the owner of that domain will have to provide the certificate. Typically, in a service provider environment, the domain owner will be the customer itself and not the service provider. The customer would have to obtain the certificate and give it to the service provider.

  6. Assign each Conferencing Node's Configured FQDN.

    The Configured FQDN setting for each node should be set to reflect its DNS FQDN. Go to Platform > Conferencing Nodes, choose each Conferencing Node in turn and set the Configured FQDN field accordingly.

  7. To provide additional media capacity, you can optionally configure the new xyz location to have a Primary overflow location set to the system location used by the original Conferencing Nodes that are supporting the vc.example.com domain (signaling will still be handled by the new nodes in the new location).