One-Touch Join process and deployment overview

This topic gives an overview of the process used by One-Touch Join to extract calendar information and provide it to endpoints, along with information on general deployment and network considerations.

Process overview

The general process from setting up One-Touch Join through to having the endpoint display a Join button at the start of a meeting is as follows:

Administrator configures OTJ

1. The administrator configures their Google Workspace, Exchange on-premises or Office 365 deployment to support Pexip Infinity One-Touch Join, and ensures that each physical meeting room that contains an endpoint to be used for One-Touch Join has an associated email address.
2. The administrator then configures One-Touch Join on the Pexip Infinity Management Node. This configuration is automatically replicated to the One-Touch Join service that runs on each Conferencing Node in the Pexip Infinity deployment.
3. Finally, the administrator configures their endpoints to support One-Touch Join.

End user sends invitation

When an end user wants to use a One-Touch Join room for a meeting, they create a meeting invitation in their usual way, using their usual client, ensuring that the room resource is added to the invitation.

Generally, rooms are added to a meeting invitation as a room resource, but One-Touch Join also works if the room resource's email address is included in the list of invitees, or as a location.

OTJ provides endpoint with meeting information

1. Each meeting room resource has one Conferencing Node which will be its primary node. Periodically, One-Touch Join on the Conferencing Node connects to Google Workspace or Microsoft Exchange and reads the calendars of each room resource for which it is the primary node. For each room resource, One-Touch Join finds all meetings to which the room has been invited. By default, it does this for all meetings with a scheduled start time from one day in the past up to seven days in the future, but this range is configurable.
2. One-Touch Join parses the meeting invitation (in accordance with the relevant meeting processing rule) to obtain information about the meeting, which it uses to generate the alias that the endpoint will dial in order to join the meeting.

3. One-Touch Join then provides the meeting information to the endpoint that is associated with the room resource:

   • for Cisco endpoints, One-Touch Join pushes the meeting information to the endpoint - either directly (for endpoints on the same network) or via Webex Cloud (for endpoints on a different network)
   • for Poly endpoints, the endpoint registers to the OTJ calendaring service on the Conferencing Node and periodically requests updated meeting information from the Conferencing Node.

   More than one endpoint can be associated with a single room resource; in this case, all the endpoints will receive the same meeting information.

4. When the meeting is about to start, the endpoint displays a Join button; participants in the room simply click the button and the endpoint dials in to the meeting.

The flow of information between the calendar/email service, One-Touch Join and the endpoint is shown in the following diagram (using Google Workspace and a Cisco endpoint as the example):

Frequency of and limitations on calendar requests

The length of time taken for a meeting booked via Exchange or Google calendar to appear on the corresponding room endpoint depends on a number of factors, but is largely due to the number of endpoints in your deployment.

In general, for deployments of around 170 endpoints or fewer, the One-Touch Join service will poll room resource calendars with a maximum frequency of every 30 seconds. (It does not poll any more frequently than this to avoid impacting the performance of Conferencing Nodes.)

• Cisco endpoints are updated after each poll if a meeting change is detected, and meetings are re-pushed to Cisco endpoints once per hour.
• Poly endpoints generally connect to the Conferencing Node to get updates every minute, but this depends on the Poly configuration.

As you add more endpoints, One-Touch Join reduces the frequency of requests correspondingly. For a deployment of 4,000 endpoints (the maximum supported number), endpoints are updated around every 12 minutes. This is because both Microsoft Exchange and Google limit the number of API requests that can be made to their calendar services in a 24-hour period.

Changing the request quota

You can change the 24-hour quota to increase the frequency of endpoint updates in larger deployments, but note that doing so may impact the performance of the Conferencing Nodes, so we do not generally recommend doing so unless:

• you have deployed a dedicated One-Touch Join platform or system locations, and
• you are using the Office 365 Graph API

— in which case you could increase the quota to between 4,000,000 - 8,000,000. However, we recommend you discuss larger deployments with your Pexip authorized support representative.

To increase the 24-hour quota:

• For Google Workspace deployments, first request an increase to API limits and then increase the Maximum Google Workspace API requests, but note that this is a paid-for service.
• For Exchange on-premises and Office 365 EWS API deployments, increase the Find Items Request Quota.
• For Office 365 Graph API deployments, increase the Maximum Graph API requests.

Locations, Conferencing Nodes and redundancy

Conferencing Nodes

All Conferencing Nodes in your deployment are capable of running One-Touch Join. However, the service will be in active operation on only those nodes that belong to a location that has been associated with a OTJ Endpoint Group (and when that Endpoint Group has been associated with an OTJ profile).

Within each such location, a maximum of five Conferencing Nodes will actively read room resource calendars and process meeting information. Responsibility for each room resource is spread across these nodes in order to balance the workload and provide redundancy. Should one node become unavailable (for example, if it is put into maintenance mode or loses connectivity), the other nodes take over responsibility for its room resources.

However, if there are one or more Poly endpoints in the location, the One-Touch Join service on all nodes within the location will handle requests from Poly endpoints. Therefore round-robin DNS records are required for all nodes in a location that has Poly endpoints.

You can use existing system locations for One-Touch Join, in which case up to five Conferencing Nodes in that location will be actively operating One-Touch Join in addition to their core functions. Alternatively, you can set up system locations that will be used specifically for One-Touch Join. These can be in the same physical locations as your existing Conferencing Nodes, but their resources will be dedicated to One-Touch Join.

The concept of media overflow locations does not apply to One-Touch Join (overflow locations relate specifically to the handling of call media). Therefore if you want to provide redundancy, this can only be done by providing additional Conferencing Nodes within a given location. For the same reason, if you put all Conferencing Nodes in a One-Touch Join location into maintenance mode, then none of the endpoints in the associated Endpoint Groups will receive any updates.

Management Node

As with other Pexip Infinity services, the One-Touch Join service will continue to function if the Management Node goes offline, although you will not be able to make any changes to the configuration of the service during this time.

For deployments using OAuth, the Management Node periodically refreshes OAuth tokens on behalf of Conferencing Nodes, so eventually (after some weeks) these nodes may become unable to authenticate with Exchange / Google Workspace.

Network architecture, firewalls and web proxy

Conferencing Nodes

Each Conferencing Node used for One-Touch Join requires a persistent connection to one of Google Workspace, on-premises Microsoft Exchange server; Office 365; or the Microsoft Graph API (depending on the calendar service you are integrating with), either directly or via a web proxy*.

If you are using OAuth (i.e. you are using an OTJ Google Workspace Integration, an OTJ Graph Integration, or an OTJ Exchange integration with OAuth enabled), each Conferencing Node must be able to reach the OAuth token endpoint, either directly or via a web proxy*.

Each Conferencing Node must be able to access the Cisco One-Touch Join endpoints within its location (using the endpoints' APIs), either directly or via a web proxy*.

If you have Webex-registered endpoints, each Conferencing Node must be able to access the Webex OAuth token endpoint, and Webex cloud.

Poly endpoints must be able to connect directly to the Conferencing Nodes in their location.

* Web proxies are enabled on a system location basis. When enabled, all One-Touch Join-related outbound requests from Conferencing Nodes in that location will use the web proxy. You can bypass use of the web proxy for connections to endpoints on the local network, or for EWS connections to the Exchange server; for further information, please contact your Pexip authorized support representative.

Management Node

As with all Pexip Infinity deployments, the Management Node must be able to contact each Conferencing Node.

In addition, if your One-Touch Join deployment is using OAuth (within an Exchange integration, a Google Workspace integration with domain user authorization, or where your deployment includes Webex-registered endpoints on a different network to your Conferencing Nodes), the Management Node will send requests to the OAuth token endpoint, both during the initial set up, and periodically thereafter in order to refresh the OAuth tokens. These requests are sent either directly or via the web proxy (if one has been configured for the Management Node).

Port usage

The following table lists the ports/protocols required for communication between the components of Pexip One-Touch Join:

Source address	Source port	Destination address	Dest. port	Protocol
Management Node	55000–65535	Web proxy (if configured for the Management Node)	8080 † Configurable by the administrator.	TCP
Management Node	55000–65535	OAuth token endpoint (for Exchange integrations connecting to O365 using OAuth for the service account; or Google Workspace integrations; or Webex-registered endpoints) ◊ Does not apply if a web proxy has been configured. for Exchange/O365 service account authorization: login.microsoftonline.com for Google Workspace domain user authorization: oauth2.googleapis.com/token for Webex-registered endpoints: webexapis.com	443 † Configurable by the administrator.	TCP (HTTPS)
Conferencing Node	55000–65535	Web proxy (if configured for the system location to which the Conferencing Node belongs)	8080 † Configurable by the administrator.	TCP
Conferencing Node	55000–65535	graph.microsoft.com (for O365 Graph Integrations) ◊ Does not apply if a web proxy has been configured.	443 † Configurable by the administrator.	TCP (HTTPS)
Conferencing Node	55000–65535	Exchange on-premises or Office 365 (for Exchange Integrations or O365 EWS Integrations) ◊ Does not apply if a web proxy has been configured.	443 † Configurable by the administrator.‡ Determined by Exchange.	TCP (HTTPS)
Conferencing Node	55000–65535	Exchange Server (only required if the O365 Autodiscover URL lookup has otherwise failed) ◊ Does not apply if a web proxy has been configured.	80† Configurable by the administrator.	TCP (HTTP)
Conferencing Node	55000–65535	OAuth token endpoint (for Exchange Integrations connecting to O365, or O365 Graph Integrations, or Google Workspace integrations, or Webex-registered endpoints) ◊ Does not apply if a web proxy has been configured. for O365: login.microsoftonline.com for Google Workspace service account authorization: googleapis.com/oauth2/v4/token for Google Workspace domain user authorization: oauth2.googleapis.com/token for Webex-registered endpoints: webexapis.com	443 † Configurable by the administrator.	TCP (HTTPS)
Conferencing Node	55000–65535	googleapis.com (for Google Workspace Integrations) ◊ Does not apply if a web proxy has been configured.	443	TCP (HTTPS)
Conferencing Node	55000–65535	Cisco endpoint API ◊ Does not apply if a web proxy has been configured.	80/443 † Configurable by the administrator.	TCP (HTTP/HTTPS)
Conferencing Node	55000–65535	Webex cloud: webexapis.com ◊ Does not apply if a web proxy has been configured.	443	TCP (HTTPS)
Poly endpoint	<any>	Conferencing Node	443	TCP (HTTPS)
† Configurable by the administrator. ‡ Determined by Exchange. ◊ Does not apply if a web proxy has been configured. Note also that the ephemeral port range (55000–65535) is subject to change.

The diagram below summarizes the connectivity required between the components of Pexip One-Touch Join, using Microsoft Exchange as an example.

Note in most cases, and particularly for a dedicated One-Touch Join deployment, all Conferencing Nodes should remain within the internal network, and not in the DMZ.

Permitting the service account to access calendars

Exchange integrations

For Exchange on-premises integrations, the One-Touch Join service account must be able to impersonate the calendar of each OTJ room resource (or a user's personal calendar, if you wish to Use OTJ with personal endpoints and calendars). This is achieved by adding the email address to a specific OTJ Distribution Group, and giving the service account application impersonation rights to that group. For instructions on how to do this, see Configuring Application Impersonation on the service account.

Existing Office 365 One-Touch Join deployments that were set up to use the EWS API also use application impersonation; see Configuring Application Impersonation on the service account. However, the EWS API is being deprecated by Microsoft, so for new One-Touch Join deployments in Office 365 environments you should instead use the Graph API to provide access to room resource mailboxes.

The use of Exchange impersonation is common in business applications that work with mail, when a single account needs to access many accounts.

The following information from Microsoft provides further background on the use of impersonation in Exchange:

• Impersonation and EWS in Exchange for guidelines on when to use impersonation in your Exchange service applications.
• Exchange Impersonation vs. Delegate Access for information on the differences between impersonation and delegate access.

Google Workspace integrations

For Google Workspace integrations, the OTJ service account (or the authentication user, if using 3-legged OAuth) must be able to access the calendar of each room resource. This is achieved by sharing the room resource's calendar (or the user's personal calendar, if you plan to use OTJ with personal endpoints and calendars — see below) with the service account. For instructions on how to do this, see Sharing individual calendars with the service account.

Note that the Google calendar API limits the number of calendars that can be shared within a 24 hour period to 750 (for more information, see this Google article). This means that if you have more than 750 room resources that you wish to use for OTJ, they will need to be set up over a period of days.

Using One-Touch Join with personal endpoints and calendars

Some users in your enterprise may have their own personal endpoints on their desk or in their office, which they want to integrate with their personal calendars so that they can simply use the "Join" button to connect to any video meetings that appear in their calendar.

To achieve this, you use the user's own email address as the room resource email address when configuring OTJ. You must also ensure that the OTJ service can access the user's calendar. In Exchange environments this is achieved by adding the personal email address to the distribution group used for OTJ; in Google Workspace environments the calendar must be shared with the service account.