Example deployment in an on-premises Skype for Business environment

This section explains how to integrate Pexip Infinity with an existing, on-premises Skype for Business / Lync* environment. If you want to deploy Pexip Infinity in a public DMZ / hybrid deployment, see Example public DMZ / hybrid deployment for remote Skype for Business environments instead.

The following diagram shows the example deployment which forms the basis of the on-premises integration between SfB/Lync and Pexip Infinity:

Example on-premises deployment used in this guide

As Pexip Infinity is a truly distributed platform, it does not matter where messages arrive in the Pexip platform, as it will always ensure that the appropriate Conferencing Nodes get the message or the media for the conference.

This example deployment uses a setup where all components are geographically located in Europe. The local SfB/Lync infrastructure has two SfB/Lync Front End Servers in a Front End Pool (fepool-eu.example.com), and a SfB/Lync Edge Server. It also has three Pexip Conferencing Nodes that are all associated with the same Pexip system location (Europe), and will be set up in an application pool (confpool-eu.vc.example.com) and integrated with SfB/Lync.

The example environment contains the following pools:

  • SfB/Lync FEP fepool-eu.example.com containing:

    • fe01.example.com
    • fe02.example.com

    (Note that the SfB/Lync pool is assumed to be working already; this guide does not cover how to install SfB/Lync in general.)

  • Pexip Conferencing Nodes confpool-eu.vc.example.com containing:

    • conf01.vc.example.com
    • conf02.vc.example.com
    • conf03.vc.example.com

The environment also contains a SfB/Lync Edge Server sip-eu.example.com.

Your actual Pexip Infinity environment may differ from the example, in which case you should make the relevant adjustments. This guide covers the specifics of one geographic location. Large enterprises with multiple SfB/Lync locations would simply apply the same configuration model for the other locations towards their local Pexip Conferencing Nodes (see Adding new Front End Pools (FEPs), locations and Conferencing Nodes).

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

Integration objectives

The goal with our example integration is to set up a static SIP domain route for the SIP domain vc.example.com (which in this example is a VTC subdomain of the main example.com SfB/Lync domain) from the Front End Pool towards a trusted application pool of local Conferencing Nodes. This provides a redundant integration environment between SfB/Lync and Pexip Infinity. This means that:

  • Incoming calls from remote corporate SfB/Lync users to the VTC subdomain (vc.example.com) will arrive at the Edge Server and be routed to the Pexip Infinity Conferencing Nodes via the static SIP route on the Front End Pool. The configuration to support this routing is explained in this on-premises guide.
  • Incoming native and federated SfB/Lync-to-SfB/Lync calls to the main example.com domain also arrive at the Edge Server and continue to be handled as normal.

In addition, you can also configure your Pexip Infinity system so that incoming calls from external federated SfB/Lync users to the VTC subdomain and any B2B calls are routed via Proxying Edge Nodes to the relevant services. See Deployment guidelines for Proxying Edge Nodes for more information.

The Pexip Infinity system location that contains the Conferencing Nodes will be configured with a SfB/Lync server. Outgoing calls from Pexip Infinity to SfB/Lync clients will dial out from an appropriate Conferencing Node in that location.

Conferencing Nodes do not need to use a TURN server for media routing to remote or federated SfB/Lync clients, providing they can reach the public-facing interface of the SfB/Lync Edge server. However, if the Conferencing Nodes are behind a NAT then they do need access to a STUN/TURN server so that each node can discover its NAT address. In Skype for Business / Lync deployments it is essential that a Conferencing Node can discover its NAT address.

The following diagram illustrates the typical signaling (SIP) and media (RTP) paths for various call scenarios involving Pexip Infinity and corporate 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 on-premises deployment signaling and media paths

Geographic distribution

With SfB/Lync environments that are geographically spread, for instance with SfB/Lync infrastructure in both Europe and US, it may be desirable to deploy a pool of one or more Conferencing Nodes in each location, to ensure efficient media routing between a Conferencing Node and the SfB/Lync user. In these cases, a static SIP domain route should be created from the local Front End Pool (FEP) towards a redundant pool of Conferencing Nodes in its nearest geographic location. If two SfB/Lync users from different geographic areas dial into a conference via Conferencing Nodes at different locations, the two local conferences are automatically merged together by the virtual backplane between the two respective Conferencing Nodes.

In a similar manner, to support dialing out from a Pexip-hosted conference to a SfB/Lync participant, SfB/Lync servers are configured for each location. This allows Pexip Infinity to dial out to the SfB/Lync server from a Conferencing Node at the most appropriate geographic location (see Adding new Front End Pools (FEPs), locations and Conferencing Nodes).

Combining with support for other external clients

An on-premises deployment can also provide access to Pexip Infinity services for clients located on the public internet. Here is an example deployment scenario for a separate VTC subdomain (vc.example.com) that provides B2B support for standards-based devices, federated B2B support for external SfB/Lync clients, and support for remote corporate SfB/Lync clients:

You can route external clients as appropriate either via your Proxying Edge Nodes or via your SfB Edge server with a deployment that looks like this:

In this deployment scenario:

  • The Management Node and the Transcoding Conferencing Nodes are deployed with private IP addresses in the local enterprise network.
  • External SIP and H.323 endpoints and other forms of business-to-business video calls connect to the Transcoding Conferencing Nodes via a firewall traversal / video call control solution such as a Cisco VCS.
  • External Connect apps connect to Proxying Edge Nodes. Their signaling is terminated on the proxying node and their media is proxied through to the internal Transcoding Conferencing Nodes. In addition you can optionally deploy a reverse proxy for load balancing and resiliency, or branding.
  • Federated SfB calls to the Pexip Infinity video subdomain (e.g. @vc.example.com) are routed through Proxying Edge Nodes.
  • Remote corporate SfB clients are routed through your SfB Edge server as normal, but they can also make gateway calls to the Pexip Infinity video subdomain (e.g. @vc.example.com) — in which case media is routed through the SfB Edge server providing the internal Transcoding Conferencing Node can route to the public facing interface of the SfB Edge server (otherwise a TURN server is required).
  • Federated calls to your SfB domain (e.g. @example.com) are routed through your SfB Edge server as normal.
  • Calls from external SIP, H.323 and Connect apps can be gatewayed via Pexip Infinity to SfB clients or SfB meetings if required (see Using Pexip Infinity as a Skype for Business gateway for more information).

Alternatively, your deployment may look like this, which is the same as the one above except that it also routes SIP and H.323 devices through Proxying Edge Nodes, instead of via third-party call control:

See DNS record examples for information about how to route calls from external clients to your Pexip Infinity nodes.