Planning and prerequisites for your Microsoft Teams and Pexip Infinity integration

This topic provides an overview of the Pexip Teams Connector architecture, your deployment environment options, and all certificate, network and firewall considerations and requirements.

You can then install your Teams Connector as described in Installing and configuring the Teams Connector in Azure.

Architecture overview

The Pexip Teams Connector must be deployed in Microsoft Azure. The Teams Connector handles all Teams communications and meeting requests from the Pexip Infinity platform and passes them on to the Microsoft Teams environment.

The dedicated Pexip Teams Connector application ensures control and ownership for organizations with stringent regulatory compliance requirements.

The diagram below shows the Teams Connector components that are deployed in Azure, and how they interact with the Pexip Infinity platform and Microsoft Teams. The Azure Virtual Machine scale set (VMSS) allows the Pexip application to run across a group of identical, load balanced VMs. You do not have to set up these Azure components individually — they are all created as part of the Teams Connector deployment process.

Teams Connector components

Pexip Infinity platform

While the Teams Connector must be deployed in Microsoft Azure, the Pexip Infinity platform can be installed in any supported environment such as on-premises or in a public or hybrid cloud (which would typically be Microsoft Azure when integrating with Microsoft Teams).

On-premises deployment

The Pexip Infinity platform can be deployed on-premises with public-facing Conferencing Nodes used to connect to the Pexip Teams Connector in Azure.

Teams Connector deployed in Azure and Infinity platform deployed on-premises

In this example deployment, external endpoints and federated systems, as well as on-premises devices can all connect to Teams conferences via the Pexip DMZ nodes.

Cloud-hosted deployment

The Pexip Infinity platform can be deployed in a dedicated public or hybrid cloud within your own cloud subscription, providing full control over your environment.

Teams Connector and Infinity platform deployed in Azure

Here, external endpoints, federated systems and on-premises devices can all connect to Teams conferences via the cloud-hosted Pexip Infinity nodes. You could use any supported cloud service but you would typically deploy your Conferencing Nodes in Microsoft Azure alongside your Pexip Teams Connector.

Including third-party call control

The Pexip Teams Connector and the Pexip Infinity platform can both be deployed in Azure with an on-premises, third-party call control system.

Teams Connector and Infinity platform deployed in Azure with third-party call control

If you have a third-party call control system that you want to retain, it can be configured to connect your on-premises systems to the cloud-hosted Pexip Infinity platform.

Pexip Infinity has a close integration with Microsoft Teams and uses Teams APIs and Microsoft SDKs to provide Infinity's interoperability features. Even though Pexip strives to maintain backwards compatibility between older versions of Pexip Infinity and the latest release of Microsoft Teams, to ensure compatibility with the latest updates to Teams we recommend that you aim to keep your Pexip Infinity deployment up-to-date with the latest Pexip Infinity software release. If, for example, you have a large Pexip deployment for non-Teams related services, and you have stringent upgrade procedures meaning that you do not always keep your Infinity software up-to-date with the latest release, you may want to consider deploying a second instance of the Pexip Infinity platform that is dedicated to your Teams interoperability requirements, and which can be managed separately and upgraded more frequently.

See Pexip Infinity installation guidelines for complete information about all of the platforms into which you can deploy the Pexip Infinity platform, and Configuring Pexip Infinity as a Microsoft Teams gateway for specific instructions about how to integrate Pexip Infinity with the Teams Connector.

Preparing your Azure environment, regions and capacity planning

This section lists the various preparation steps you must perform before starting your Teams Connector installation into Azure.

Obtain an Azure subscription and an Azure tenant ID

Ensure that you have an Azure subscription and an Azure tenant ID for your Teams Connector deployment.

Most of the installation steps can be performed by somebody with Contributor permissions for the Azure subscription. However, there is one step that the Owner of the Azure subscription must perform (see Azure permissions requirements for more information).

Decide Azure deployment region(s) and check quota

Decide in which Azure region you want to deploy the Teams Connector. Large enterprises may want to install a Teams Connector in multiple regions.

  • The Azure region must support Automation and Fs series instance types.

    See Azure automation for more information about Automation, and Azure product availability by region.

  • Ensure that you have sufficient resource quota and capacity for your region and instance types.

    By default, Azure Resource Manager virtual machine cores have a regional total limit and a regional per series limit, that are enforced per subscription. Typically, for each subscription, the default quota allows up to 10-20 CPU cores per region and 10-20 cores per series.

    The allocated quota may be increased by opening a support ticket with Microsoft via the Azure Portal. Based on your capacity requirement, you should request a quota increase for your subscription. Ensure that you request a sufficient number of CPU cores. Each Teams Connector instance will use 4 vCPU of type Fs-series. Thus, for example, if 6 Teams Connector instances are required, then the quota must be increased to 4 cores x 6 Fs-series instances = 24 CPU cores of type Fs-series. However we strongly recommend that you request a quota covering more than the minimum, such as 40 cores, to allow for an increase in the future. It may take a number of days for the quota increase request to be processed. For more information see https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits.

Capacity planning

Contact your Pexip authorized support representative to discuss your call capacity requirements, and how many Teams Connector instances are required.

Network and certificate requirements

This diagram shows how the main elements in a Microsoft Teams integration communicate with each other and how the connection between each element is validated/authenticated.

Teams communications and network flow

  • You must have one or more publicly-reachable Conferencing Nodes. Those nodes:

    • can be Transcoding Conferencing Nodes or Proxying Edge Nodes
    • can have static NAT and/or dual network interfaces, as the Teams Connector is treated as a lineside connection.
  • The public-facing Conferencing Nodes always communicate with the Teams Connector via public IP, even if they are within the same Azure tenant.
  • The Teams Connector communicates with the Microsoft Teams (O365) backend via public IP; all traffic stays within the Microsoft network.
  • The Teams Connector supports connections over TLSv1.2 only, and does not support RC2, RC4, DES and 3DES ciphers.

In summary, the certificate usage principles are:

  • The Teams Connector and Pexip Infinity validate the connection in both directions by TLS client certificate validation. This means that every certificate's Enhanced Key Usage properties must be set for both server and client authentication.

  • Public-facing Conferencing Nodes must have a valid publicly-signed PEM-formatted certificate (typically with a .CRT or .PEM extension).
  • The Teams Connector must have a publicly-signed PFX-formatted certificate. Multiple names/certificates are required if deploying Teams Connectors in several regions.

Obtaining and preparing the TLS certificate for the Teams Connector

You must install on the Teams Connector a TLS certificate that has been signed by an external trusted CA (certificate authority).

You need to have this certificate available before you install the Teams Connector.

The certificate must be in Personal Information Exchange Format (PFX), also known as PKCS #12, which enables the transfer of certificates and their private keys from one system to another. It must use RSA keys.

  1. Decide on the FQDN (DNS name) you will use for the Teams Connector load balancer in Azure that will front the Teams Connector deployment e.g. pexip-teamsconn-eu.teams.example.com.

    • This is what you will use as the value of $PxTeamsConnFqdn in the variables initialization script.
    • The certificate's subject name must match the DNS name you will configure in Pexip Infinity (Call control > Microsoft Teams Connectors > Address of Teams Connector) later in the process.
    • It can use the same domain space as your Pexip Infinity deployment, or your Teams deployment, or it can use an altogether different domain. In all cases you always need to create the necessary DNS CNAME record(s) and public certificates for the chosen domain.
    • If you intend to deploy other Teams Connectors in other Azure regions, you will need a different DNS name for each Teams Connector and a certificate that matches that identity.
    • It can be a wildcard certificate, where the wildcard character ('*') is the only character of the left-most label of a DNS domain name. Note that Pexip supports RFC 6125 — this means that if you are using subdomains then, for example, a wildcard certificate of *.example.com would match foo.example.com but not bar.foo.example.com or example.com.

    Note that if you subsequently need to replace the certificate that you have installed, you will need to redeploy the Teams Connector.

  2. Request a certificate for that name and generate the certificate in PFX format. Any intermediate certificates must also be in the PFX file.

You can use the Pexip Infinity Management Node to generate a certificate signing request (CSR).

You can use the Pexip Infinity Management Node to convert PEM certificates to PFX format (or vice versa), by uploading a PEM-formatted certificate and then downloading it again in PFX format. When downloading you can also include the private key and all necessary intermediate certificates in the PFX bundle.

Ensuring Conferencing Nodes have suitable certificates

The Conferencing Nodes (typically Proxying Edge Nodes) that will communicate with the Teams Connector must have TLS certificates installed that have been signed by an external trusted CA (certificate authority). If a chain of intermediate CA certificates is installed on the Management Node (to provide the chain of trust for the Conferencing Node's certificate) those intermediate certificates must not include any HTTP-to-HTTPS redirects in their AIA (Authority Information Access) section.

We recommend that you assign a "pool name" to all of the Conferencing Nodes that will communicate with the Teams Connector. The pool name should be used as a common Subject name on the certificate that is uploaded to each of those Conferencing Nodes. The certificate should also contain the individual FQDNs of each of the nodes in the pool as a Subject Alternative Name on the certificate. This pool name can then be specified on the Teams Connector (the $PxNodeFqdns variable in the initialization script) as the name of the Conferencing Nodes that it will communicate with.

This approach makes it easier to add extra Conferencing Nodes into the pool as they will all present the same certificate/subject name to the Teams Connector. If you add a new Conferencing Node with a name that is not configured on the Teams Connector you will have to redeploy the Teams Connector and specify the new names.

See Certificate and DNS examples for a Microsoft Teams integration for more information and examples about certificates, DNS records and using a "pool name" for Conferencing Nodes.

Firewall ports for the Teams Connector and NSG rules

The following table lists the ports/protocols used to carry traffic between the Teams Connector components and Microsoft Teams (O365), your public-facing Conferencing Nodes (typically Proxying Edge Nodes) and any management networks.

Source address Source port Destination address Destination port Protocol Notes
Conferencing Nodes
Conferencing Nodes 33000–39999 *

Teams Connector load balancer

Teams Connector instance

443 TCP Signaling
Conferencing Nodes 40000–49999 * Teams Connector instance 50000-54999 UDP Call media
Teams Connector components
Teams Connector instance ephemeral Microsoft Teams (O365) <any> TCP Signaling
Teams Connector instance ephemeral Conferencing Nodes 443 TCP Signaling
Teams Connector instance 50000-54999 Conferencing Nodes 40000–49999 * UDP Call media
Teams Connector instance 55000-59999 Microsoft Teams (O365) <any> UDP Call media
Teams Connector instance ephemeral OCSP responder 80 TCP Certificate revocation checking
Teams Connector instance ephemeral Windows update servers 80/443 TCP Windows updates
Microsoft Teams (O365)
Microsoft Teams (O365) <any> Teams Connector load balancer

10000-10399

10500-10899

11000-11399

TCP Signaling
Microsoft Teams (O365) <any> Teams Connector instance 55000-59999 UDP Call media
Management
Management workstation <any> Teams Connector load balancer 50000-50399 TCP Only enabled for any workstation addresses specified during Teams Connector installation
Teams Connector instance 3389
Client application viewing the meeting invitation
<any> <any> Conferencing Nodes 443 TCP Access to Alternative Dial Instructions

* Configurable via the Media port range start/end, and Signaling port range start/end options (see About global settings).

† The Conferencing Nodes referenced in the InstructionUri for the "Alternate VTC dialing instructions".

Teams Connector firewall ports

Teams Connector Network Security Group (NSG)

A Network Security Group that supports these firewall requirements is created automatically in Azure as a part of the Teams Connector installation process, and is assigned to each Teams Connector instance. Note that the NSG includes:

  • Rules used for internal traffic within the Teams Connector that is forwarded from the load balancer to the instances (to ports 10100, 10101 and 20100) — these ports do not need to be opened between the Conferencing Nodes / Microsoft Teams and the Teams Connector.
  • An "RDP" rule (priority 1000): if the $PxMgmtSrcAddrPrefixes installation variable contains addresses, this rule allows RDP access to the Teams Connector instances from those addresses. If no addresses are specified then a Deny rule is created (so that you can add addresses and allow it later if required).

You must also allow the relevant ports through any of your own firewalls that sit between the Teams Connector components and your public-facing Conferencing Nodes and management networks.

You may need to modify some of the NSG rules in the future if you subsequently add more Conferencing Nodes to your Pexip Infinity platform, or change the addresses of any management workstations.

Teams Connector Network Security Group

Additional deployment information

The following features are provided/enabled automatically as part of the deployment process:

  • VMSS (virtual machine scale set) disk encryption is enabled by default. The keys are stored in an Azure Key Vault. Note that the disk encryption can affect performance for approximately 30 minutes after the deployment has finished.
  • Access keys for the storage account that is used for logging are managed by Azure Key Vault and are automatically regenerated every 90 days (not configurable).