You are here: Integration > Microsoft Lync / Skype for Business > Multiple SIP domains (public DMZ)

Public DMZ deployment with multiple SIP domains for Lync / 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 Lync / Skype for Business* federation in a Pexip Infinity public DMZ deployment.

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

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

    commonName = sip.example.com
    altNames = sip.example.com, conf01.example.com, conf02.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. customer-xyz.com to this existing deployment.

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

Adding an additional subdomain

To add an additional subdomain e.g. abc.example.com to an existing deployment:

  1. Add a new system location.

    You must add a new Pexip Infinity system location (Platform configuration > 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 (for Lync / Skype for Business integration) global setting (Platform configuration > Global settings) has been set to example.com.

    You must override this global setting for each new location. Go to Platform configuration > Locations and configure the Pexip Infinity domain (for Lync / Skype for Business integration) setting as appropriate for each new location.

    For example, for location abc, set the Pexip Infinity domain (for Lync / Skype for Business integration) 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 conf01.abc.example.com and conf02.abc.example.com and assign them to location abc.

  4. Configure additional DNS A records and DNS SRV records for the new Conferencing Nodes.

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

    • A-record: conf01.abc.example.com, pointing to the publicly-reachable IP address of conf01.abc.example.com
    • A-record: conf02.abc.example.com, pointing to the publicly-reachable IP address of conf02.abc.example.com
    • SRV-record: _sipfederationtls._tcp.abc.example.com, pointing to conf01.abc.example.com on port 5061

    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 conf01.abc.example.com; you cannot, for example, configure the _sipfederationtls._tcp.abc.example.com SRV-record to point to conf01.example.com). This is required due to the trust model for Lync/SfB 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 node referenced by the _sipfederationtls._tcp SRV record, and the SANs should include the FQDNs of all of the nodes in the location.

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

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

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

  6. Configure each Conferencing Node's SIP TLS FQDN.

    The SIP TLS FQDN setting for each node should be configured to reflect its unique DNS FQDN. Go to Platform configuration > Conferencing Nodes, choose each Conferencing Node in turn and configure the SIP TLS 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 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. customer-xyz.com to an existing deployment:

  1. Add a new system location.

    You must add a new Pexip Infinity system location (Platform configuration > Locations) to support each additional domain.

    For example, add a new system location xyz to support the domain customer-xyz.com.

  2. Configure the Pexip Infinity domain for the new system location.

    In our example deployment, the Pexip Infinity domain (for Lync / Skype for Business integration) global setting (Platform configuration > Global settings) has been set to example.com.

    You must override this global setting for each new location. Go to Platform configuration > Locations and configure the Pexip Infinity domain (for Lync / Skype for Business integration) setting as appropriate for each new location.

    For example, for location xyz, set the Pexip Infinity domain (for Lync / Skype for Business integration) to customer-xyz.com.

  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 conf01.customer-xyz.com and conf02.customer-xyz.com and assign them to location xyz.

  4. Configure additional DNS A records and DNS SRV records for the new Conferencing Nodes.

    For example, for the nodes supporting domain customer-xyz.com, you would create:

    • A-record: conf01.customer-xyz.com, pointing to the publicly-reachable IP address of conf01.customer-xyz.com
    • A-record: conf02.customer-xyz.com, pointing to the publicly-reachable IP address of conf02.customer-xyz.com
    • SRV-record: _sipfederationtls._tcp.customer-xyz.com, pointing to conf01.customer-xyz.com on port 5061

    Note that the domain name used in the SRV-record has to match the domain in the corresponding A-record (e.g.
    _sipfederationtls._tcp.customer-xyz.com must use the same domain as conf01.customer-xyz.com). This is required due to the trust model for Lync/SfB 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 node referenced by the _sipfederationtls._tcp SRV record, and the SANs should include the FQDNs of all of the nodes in the location.

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

    commonName = conf01.customer-xyz.com
    altNames = conf01.customer-xyz.com, conf02.customer-xyz.com

    When hosting an additional top-level domain (customer-xyz.com 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. Configure each Conferencing Node's SIP TLS FQDN.

    The SIP TLS FQDN setting for each node should be configured to reflect its DNS FQDN. Go to Platform configuration > Conferencing Nodes, choose each Conferencing Node in turn and configure the SIP TLS 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 example.com domain (signaling will still be handled by the new nodes in the new location).