Example public DMZ / hybrid deployment for remote Skype for Business environments

This section explains how to deploy Pexip Infinity in a public DMZ and enable direct federation with remote Skype for Business / Lync* environments such as Office 365 and Skype for Business / Lync Online as well as traditional enterprise Skype for Business / Lync environments. If you want to integrate Pexip Infinity with an existing, on-prem SfB/Lync environment, see Example deployment in an on-premises Skype for Business environment instead.

You should follow these public DMZ guidelines for a hybrid deployment of on-premises and Office 365 where SfB/Lync users may be homed in either environment.

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

Deployment requirements

For integrating Pexip directly with remote SfB/Lync environments, the following requirements have to be satisfied:

  • The Conferencing Nodes in the Pexip environment must be deployed in a public DMZ network, meaning all Conferencing Nodes must be assigned publicly-reachable IP addresses, either directly or they can be deployed behind static NAT.
  • For inbound call support, at least one Conferencing Node must be configured with a public TLS server certificate (provided by an official CA provider such as Verisign, Comodo, GlobalSign and similar). For outbound call support, all Conferencing Nodes in the public DMZ must be configured with a public TLS server certificate.

    Note that RDP content sharing from Pexip Infinity towards a SfB/Lync client is considered an outbound call, even if the SfB/Lync client had dialed in to the conference, as RDP is a separately initiated SIP session.

  • The SfB/Lync federation DNS SRV record for the video domain in use must resolve to the Conferencing Node(s) that will receive incoming calls.

Example public DMZ deployment used in this guide

The diagram above shows the example deployment which forms the basis of the public DMZ deployment in this guide. In this scenario, all Conferencing Nodes are deployed in a public DMZ network. Two Conferencing Nodes are configured to receive incoming calls (handle the SIP signaling). Additional Conferencing Nodes can optionally be deployed to increase the media capacity. Media processing is dynamically distributed among all the Conferencing Nodes.

Those Pexip nodes may be Transcoding Conferencing Nodes, or in large deployments you could use dedicated Proxying Edge Nodes to manage the signaling and media connections with the SfB/Lync clients (or any other endpoints). See Publicly-addressable Transcoding Conferencing Nodes for more information.

The Management Node will typically also be located in the same public DMZ, but this is not a requirement. The Management Node can be located on an internal network behind the public DMZ, as long as:

  • there is no NAT (Network Address Translation) taking place between Pexip Infinity nodes on the internal network and nodes on the public DMZ, and
  • any firewalls between the two networks are configured to pass IPsec traffic in both directions between the Management Node and all Conferencing Nodes in the Pexip environment.

The following diagram illustrates the typical signaling (SIP) and media (RTP) paths for various call scenarios involving Pexip Infinity and external or Office 365-hosted SfB/Lync clients. Since media negotiation between Pexip Infinity and SfB/Lync involves ICE (Interactive Connectivity Establishment), media paths depend on network architecture and the presence of firewalls and NATs (Network Address Translators). Note that the actual media paths in a real deployment may differ. See Signaling and media paths for remotely-located Skype for Business clients for more information.

Example public DMZ deployment signaling and media paths