While this blog already contains several articles discussing Poly’s RealConnect solution many organizations with existing Poly video infrastructure deployments want to understand which RealConnect for Microsoft Teams topology may be best.  The purpose of this article is to explain the differences between the available topologies so that an informed decision can be made.  Some of this content has already been covered in various older articles, but this serves as an opportunity to present the latest information in a single cohesive story leveraging best practices derived from real-world planning and deployments.

The main areas where differences reside between the topologies are categorized as: architecture, video experience, and licensing.  While the overall user experience is nearly identical between all scenarios there are a few distinct differences which can often sway the decision one way or the other, while other differences could collectively impact the cost to deploy and/or use the solution.

Often the first and only criteria though is simply based on selecting a cloud-only solution which provides little to no on-premises footprint, thus making the decision very easy.  But when cost, complexity, and overall experience might outweigh that elementary approach then understanding the nuances among the supported topologies is fundamental to arriving at the ideal solution.  Alternatively it may seem desirable to leverage existing Poly video infrastructure which could currently be used for traditional video meetings or even RealConnect with Skype for Business, but certain limitations in that approach may make the cloud-only route more attractive to some.

As many of the following scenarios are simply minor configuration differences among overall identical deployments then it can be fairly trivial to change models later on.  Even multiple topologies could be utilized concurrently in the same environment if desired, so migrating or transitioning between different topologies can also be figured into the overall planning.

Some initial advice is to maybe not get too caught up in heading towards the most complex approach solely to try and mimic every single use case which may exist today.  Designing 80% of the solution based on 20% or less of common use can often lead to a cyclical approach with no clear winner, so given the state of world today and how quickly people have been able to adapt to forced changes in work behavior this can also serve as an opportunity to shed some of those antiquated behaviors and deliver a simpler overall solution.

Background

A traditional video endpoint, also referred to as a VTC (VideoTeleCommunications) system by definition only supports standards-based SIP and/or H.323 protocols and cannot communicate directly with Microsoft Teams.  For these systems to interoperate with Microsoft Teams the only available method is to leverage Microsoft’s partner-based Cloud Video Interop (CVI) offerings to join a scheduled Teams meeting.  The RealConnect Service is Poly’s CVI offering which is hosted entirely in Microsoft Azure and is utilized in all of the available RealConnect topologies discussed here.  Thus, the service can either used by itself as a cloud-only solution or it can be used in conjunction with an on-premises Poly video infrastructure deployment which may or may not contain a traditional Multipoint Control Unit (MCU), commonly referred to as a bridge.  There is no way for a VTC endpoint or a Poly bridge to connect directly into Microsoft Teams; both must utilize the CVI service to do so.

Because the service is required for all possible scenarios then the initial onboarding and repeated meeting scheduling experience is the same across the board.  Once the service is enabled for a Microsoft 365 tenant then enabled Teams users will begin to see additional video conferencing details when creating new Teams meeting invitations.

Throughout this article the example above will be used to illustrate how calls would be placed from a VTC endpoint to join this meeting via the provided details.  Every meeting scheduled by any user in the same Teams organization will always use the same Tenant Key (e.g. 12345678) while ever single scheduled meeting will always use a unique VTC Conference ID (e.g. 1177958860).  (Note that the Audio Conferencing ID is different as these IDs are used by different services which are not compatible.)  How this information can be leveraged to place calls can vary depending on the chosen topology.

In summary, the following three Poly offerings provide different options to leverage RealConnect for Microsoft Teams:

1. RealConnect Service – Endpoint calls go directly into the service via standard firewalls.
2. RealConnect for Clariti  – Endpoint calls go to an on-premises Poly video bridge, which in turn connects into the service.
3. RealConnect Access Suite – Endpoint calls go directly into the service via a Poly firewall traversal solution.

The first two options are quite straightforward as all endpoint calls will land directly into the cloud service.  The difference between them is that if existing enterprise firewalls cannot or should not route traffic from internal VTC endpoints to the Internet then the RealConnect Access Suite (RCAS) can be deployed on-premises to provide call routing and firewall traversal services as well as endpoint registration and management capabilities.  The important components historically provided with RCAS are the Distributed Media Application (DMA) for call routing and the RealPresence Access Director (RPAD) for firewall traversal.  More recently that has been updated to leverage only the DMA product for both server instances, one as the DMA Core and the other as the DMA Edge (which replaces the older RPAD product).  Understand that RCAS is not a requirement to leverage the service as existing firewalls can typically be configured to successfully support the required traffic.  Or other existing standards-based video routing platforms like Cisco VCS or Cisco Call Manager could also be used. (Note that older Polycom Video Border Proxy (VBP) products are not supported with the RealConnect Service.)

The RealConnect for Clariti option includes a deployment of the same routing and traversal components provided in RCAS but brings also brings a video MCU (or bridge) into the topology in the form of the RealPresence Collaboration Server (RPCS), previously know as the RMX.  This bridge provides the ability to land some or all VTC endpoint calls into the same traditional Virtual Meeting Room (VMR) where the bridge will also then place its own outbound call up to the RealConnect Service to complete the connection into a Teams meeting.  Additional control over the VTC side of the Teams meeting is offered here, but this can come with both a literal and figurative cost.

Also mentioned in this article is the Poly One Touch Dial (OTD) Service which is complementary to RealConnect in that it can be used to provide a proper dial strings to VTCs capable of displaying a ‘Join’ button on calendar entries.  While the OTD Service is a cloud only, Azure-hosted service there is also an on-premises version of OTD provided via Poly Workflow Server which is often used, but not required, with Clariti deployments.

The concepts discussed in this article are not overly complex but are commonly misunderstood as a whole when a few precise details are omitted. The overall experience is largely identical between all models of RealConnect, even among the scenarios available to Skype for Business platforms.  A Teams meeting must always be scheduled for any scenario, the invitation formatting is the same, and the user workflow is unchanged from a regular Teams workflow.  Users reserve room resources as usual and when they enter the room they simply hit a ‘join’ button on the available room control interface to join the scheduled meeting.  This is where the differences begin though as the call routing, licensing cost, and video experience are reflective of the selected topology.

Architecture

There are only small variations in the overall architectures between the RealConnect for Teams deployment options outlined above, and as stated all scenarios will still traverse the RealConnect Service.  The main difference is whether VTCs are calling directly into the cloud or instead calling into a bridge hosted internally.  The most important factor here though is the number of concurrent meetings these endpoints are joining.  On the surface it seems like providing a bridge on-premises for all endpoints to call into would drastically reduce the amount of sessions, and thus total bandwidth utilization, egressing a corporate network out to the Internet. But remember that an outbound session still needs to be established from that internal bridge out into the RealConnect Service in order to connect into the Teams meeting.  This means that the true value (in terms of bandwidth management) of using a local bridge is based not on the number of VTCs in use but the number of unique meetings these VTCs are joining at one time.

If meetings typically are comprised of a single conference room joining a meeting with several individual attendees joining from desktop and mobile devices then for every meeting like this that is running at the same time on the bridge a connection to the cloud service needs to be established.  The math here is simple, if 3 VTCs are in use at one given time and they are all joining 3 different Teams meetings then the local bridge will need to establish 3 connections into the RealConnect Service.  There is no real bandwidth saving here as the 3 endpoints could simply be calling directly into the service.

Alternatively though if a typical meeting consists of multiple conference rooms joining the same Teams meeting alongside native Teams participants then this imbalance starts to favor the RealConnect for Clariti models.  Thus, if the 3 VTCs are all joining the same Teams meeting then the bridge only needs to establish a single connection out to the service to reach that one Teams meeting.  This scenario can drastically reduce the number of egress connections to the Internet depending on the amount of concurrent meetings.

The real-world problem here though is that meaningful data may not be available to attempt to make an informed decision on this behavior alone.  Additionally meeting participation might vary so vastly over time that selecting one scenario over the other would not offer any measurable advantage if the two cases essentially balance each other out.  If some meetings have multiple VTCs but most have only a single VTC then it is usually simpler to just leverage the service directly, or leave this decision up to the other categories covered here.

The order the following topologies are presented is deliberate as they will progress from the easiest to acquire and use while offering the least flexibility in management and control to more complex yet flexible solutions.  Keep in mind though that there will be trade-offs with each approach so perceived advantages in one may lead to something seen as undesirables in another.

RealConnect Service

This is the CVI service managed by Poly and hosted in Microsoft Azure which VTCs call directly into in order to join a scheduled Teams meeting.  The service is comprised of several regional load balancers which receives a SIP or H.323 calls from a VTC (or from an MCU in the case of the Clariti models) and then intelligently directs that call into one of several virtual gateways in the best available pool of resources also hosted in Azure.  The gateway then utilizes a Teams bot to connect to the Teams meeting and handles bi-directional transcoding of audio, video, and content sharing streams.

The service does not include endpoint registration or device management as it simply accepts calls placed to various dial strings in the t.plcm.vc domain.  Standard network firewalls can typically be configured to allow SIP and/or H.323 traffic outbound into the service over defined ports.  In this basic approach the OTD service is typically leveraged to allow supported endpoints to call directly into meetings from scheduled meetings on the device’s calendar.  Alternatively meetings can be joined directly (or indirectly via an entry queue) by manually entering a dial string .  One way to improve the manual dialing experience on legacy endpoints which do not support Exchange calendaring (like Lifesize or Tandberg) is to create a speed dial entry on endpoints or in an endpoint directory which calls directly into the RealConnect Service entry queue specific to the tenant.  Using the example Tenant Key of 12345678 an organization could create a speed dial for “12345678@t.plcm.vc” which would allow users to simply call that entry and then upon connection would enter the unique VTC conference ID provided in the specific Teams invitation.

RealConnect Access Suite

RCAS is a licensing model which provides nearly the same video infrastructure components as Poly Clariti, except without any bridge to host meetings.  This is meant for environments where there is a need for endpoint device management and call routing/traversal when using external meeting services, like the RealConnect Service.

Endpoint calling behavior and bandwidth utilization into the service is no different other than video-specific routing components can now be utilized to assist calls in reaching the service in azure across the Internet.  One additional benefit that RCAS provides is that with endpoint registration comes the ability to define dial rules to further simplify manual dialing for rooms where calendaring is not available.  A standard dialing prefix (e.g. ‘6’) could be defined to mask the longer Tenant Key and required destination hostname or IP Address so that users could manually join a meeting by dialing the prefix followed by the unique video conference ID for the meeting.  For example dialing 61177958860 on the endpoint would be identified by the DMA by the leading ‘6’ as a prefix to match the defined rule, and then it would parse the remainder of the string out as the actual VTC conference ID.  The rule would essentially take a dial string of ‘61177958860’ and replace it with ‘12345678.1177958860@t.plcm.vc’ and then route the call accordingly.

RealConnect for Clariti

There are two different deployment models of RealConnect for Clariti which are nearly identical but a minor configuration change impacts how some calls are routed differently between them.  There is the more common Consolidated Model which treats all VTC calls the same regardless of their origin and the Split Model which effectively splits VTC calls between the bridge and the service depending on their registration or DNS behavior.

This Consolidated Model leverages both the service and an on-premises deployment of Poly video infrastructure components similar to RCAS yet with the addition of a bridge.  The configuration directs all endpoint calls to the bridge which then automatically establishes a single cascade connection per Teams meeting into the service.  This handles all VTC calls the same regardless of where they are located or registration status.

Note that while the solution name includes ‘Clariti’ that does mean that Clariti-licensed deployment is a requirement . Older procurement models of the RealPresence Platform are supported as are both hardware appliances and virtual server deployments of the infrastructure components.  The actual requirement is an infrastructure deployment which includes at least one DMA, one RPCS (or supported RMX), and an RPAD or DMA Edge all running prerequisite firmware versions.  This configuration leverages a custom hostname in the Teams invitation (instead of the default ‘t.plcm.vc’) which directs all endpoints calls via DNS to Clariti and never to the service.  Registered endpoint calls will be handled via dial rules configuration on the DMA and unregistered endpoint calls will be directed to the DMA or RPAD based on DNS resolution responses.  Only the bridge cascade is ever directed into the service.  Both SIP and H.323 can be supported simultaneously for endpoint calls, but the cascade call from the bridge into the service is only possible over H.323.

Note that local entry queues are not supported when using Clariti thus the full dial string is required when placing the call in order to establish the cascade from the bridge to the target Teams meeting.  The entry queue behavior is only available to endpoints which call directly into the service, which is not possible in this configuration.

Meanwhile, the Split Model is functionally identical to the previous and leverages almost the exact same configuration, but that single change means that calls from unregistered endpoints will no longer be directed to the bridge and will instead go directly to the service.

Where the Consolidated model uses a custom hostname the Split model retains the default ‘t.plcm.vc’ hostname in the Teams meeting invitation so that DNS responses will point directly to the service.  Endpoints which are registered to the Clariti deployment, internal or external alike, will not use DNS as the call is simply sent to the registrar which is configured to use the bridge for these calls.  This model allows and organization to insure that any endpoints belonging to other parties would connect directly into the RealConnect Service when joining their Teams meeting without ever touching their own network or internal video infrastructure.

Video Experience

Throughout the entire RealConnect workflow, from scheduling to meeting completion, the user experience is essentially identical across all models with one notable exception: the video layout. The audio experience is identical between all models as you can always hear everyone who is speaking, and the content sharing is no different as everyone can see the shared desktop or application provided by a single attendee at a time.

The number of concurrent video participants shown at one time and specifically who is shown at any given time is driven by a variety of factors.  Most importantly understand that Microsoft Teams does not currently give preference to attendees with their video camera enabled over those who are not sharing their video.  The only selection logic is based on audio activity. If an attendee is speaking then they are the current focus of the meeting and will be put into the current layout (if they are not already in it) regardless of whether their camera is enabled at the time or not.  This behavior is no different from Skype for Business, or Lync, or any of the Microsoft UC platforms.  This is why a video layout can often be heavily populated with tiles simply showing the user’s photo, or if no photo is available for their account then a plain circle with their initials, yet other participants who do have their video enabled are not currently being shown as they have not spoken recently enough and have been pushed down the list of most recent speakers.

The maximum number of attendees shown at one time is currently in flux.  Within Microsoft Teams it has always been a maximum of 4 participants across nearly every native client, but at the time this article was posted Microsoft has been rapidly working on increasing this limitation, driven primarily by the rise in Teams usage due to the COVID-19 pandemic.  Many Microsoft 365 tenants are already experiencing the updated layouts now which provide up to 9 participants at a time.  This new feature is something that Microsoft has been working on for some time and while the clients are just now being updated the backend services have supported sending up to 9 streams for some time.  That meant that Poly was able to expand the RealConnect Service to provide a 3×3 layout of up to 9 participants back at the beginning of the year.  The behavior when RealConnect for Clariti is involved is much more nuanced as the number of concurrent participants shown on either side of the meeting can vary based the configured mode.  The diagrams used in this article leverage the new maximum of 9 on both sides.

RealConnect Service

The video layout experience is simple and consistent when endpoints are calling directly into the RealConnect Service.  Every VTC call into the service is allocated their own gateway which means that each VTC appears as a unique participant in the meeting.  The roster entry for that endpoint will display the configured System Name on the endpoint, which can vary between SIP and H.323 configurations in some VTCs.  The endpoint can be muted or removed from the meeting like any other attendee.

This approach means that the Teams meeting service will be receiving inbound video streams from every endpoint coming through the service, so there is absolutely no difference in which video streams are seen between native Teams endpoints and VTC endpoints.  The RealConnect Service already supports showing up to 9 participants at one time and at the time this article was posted Microsoft is currently in the middle of rolling out the same maximum of 9 in many native Teams clients.  Nothing is different from the normal Teams experience here and the last 9 active speakers will be displayed to any and all participants capable of receiving that many streams.

In the example diagram below a total of 10 participants are in the same Teams meeting. Of those ten are 6 participants using any variety of native Teams clients, 1 native Teams device (like a Microsoft Teams Room solution), and 3 standards-based VTCs coming in through the RealConnect Service.  The video layouts below for one VTC and one Teams client illustrate viewing the exact same attendees, other than themselves of course.

There is an important difference to understand between the two though.  The native Teams client is actually receiving nine different Scalable Video Coding (SVC) streams while the VTC is receiving a single Advanced Video Coding (AVC) video stream.  This means that the native Teams clients and devices can control the layouts locally as well as pin individual participants who may not even be active speakers.  Conversely, the RealConnect Service controls the video tile layout and simply sends that entire image to the VTC.  The VTC cannot control who is seen nor modify the arrangement of video tiles.

RealConnect Access Suite

The behavior when using RCAS is identical to what is shown above as the service is still handling all calls and there is no additional bridge involved.

RealConnect for Clariti

The video experience for both VTCs and Teams clients is different with RealConnect for Clariti.  The addition of the on-premises bridge means that there are effectively two separate MCUs handling different participants in the same Teams meeting.  As outlined in the architecture discussion earlier the native Teams clients and devices continue to communicate directly with the Teams meeting services and behave no differently themselves.  But VTCs which are connected to the on-premises Poly bridge will receive a traditional virtual meeting room layout as managed by the Clariti platform.  The cascade established between the bridge and Teams via the RealConnect Service will only send and receive a single video stream of the active speakers from both MCUs.  The Teams participant list will also only show a single participant entry for this cascade.

Stating with the Consolidated Model the diagram below indicates the red VTC as the active speaker among the three rooms connected directly to the bridge, while the green Teams client is the active speaker among those connected directly to the Teams meeting service.  The bridge will only ever send a single video participant, thus only the red VTC will be seen by an Teams participants.

While there is no change from the service-only model in how the Teams participants operate themselves they will only be able to see a single VTC participant as the bridge only sends one at a time, automatically switching to the current active speaker across the cascade.  As the red VTC is the current active speaker then that is what the Teams participants see.

Meanwhile the VTCs connected to the bridge will see every other local participant, which could be even more than 9 if enough VTCs are connected and the bridge’s local layout configuration allows.  But no more than 1 participant from the Teams side will ever be seen by the VTCs as the RealConnect Service only sends a single video participant from Teams across the cascade down the bridge.  The local bridge will add that video tile to the overall layout which it manages.

If the Split Model of RealConnect for Clariti is used then it would be possible to have a mixture of both experiences.  The VTCs connected to the local bridge would adhere to the same behavior just described above but other VTCs landing directly on the service would operate as explained in the previous section applicable to the service.

In this diagram the red VTC is connected to the bridge while the blue VTC is connected directly to the service.  The Teams participants will still only see the active speaker from those connected to the bridge, but the blue VTC is now connected directly to the service and thus can also be seen at the same time by the Teams participants.

While this Split Model is more commonly selected for how calls are routed a use case where the video layout experience may be important is when dealing with multi-codec immersive telepresence systems.  In this scenario it may be desired to send regular VTCs directly to the service but route calls from the immersive rooms to a bridge so that those rooms can benefit from multi-stream stitching to provide views not available in the service.

Licensing

There are many different license SKUs (Stock Keeping Units) available today which can vary by region, quantity, or subscription durations.  All of the available RealConnect licenses are measured by concurrent use which means none of the licenses described below are assigned to individual endpoints, they are applied to the service or servers. These licenses are only consumed during active calls, so the number of endpoints in use (and in one case the number of different meetings) at the same time dictate how many licenses are needed, not how many VTCs may exist in an organization.

The various applicable licenses can be divided into different categories:

• [A] Service Endpoint Licenses – used by the service and applied to inbound calls from an endpoint.
• [B] RCAS Licenses – used by RCAS to allow outbound call traversal from an endpoint.
• [C] Clariti Licenses – used by Clariti to allocate bridge resources for inbound endpoint calls and outbound bridge calls.
• [D] Service Cascading Licenses – used by the service and applied to inbound calls from a bridge.

Each potential calling scenario is depicted in the diagram above which can be used as a visual aid to understanding how multiple license types would be needed in certain deployments.

RealConnect Service

As usual the cloud-only approach is the simplest, requiring only enough concurrent-use licenses (category ‘A’) to support the maximum number of VTCs calling into the service at one time.  The number of Teams meetings occurring at the same time is irrelevant, so if 10 endpoints are calling into 10 different Teams meetings or 10 endpoints are all calling into the same Teams meeting the service still handles 10 total calls.  Calls in this scenario only consume a single license for each endpoint.

The licenses SKUs which fall into this category all include the text “RealConnect Service for MSFT Teams Video Interop” and “Concurrent VTC” in their descriptions.

RealConnect Access Suite

If RCAS has been deployed to assist with calls from endpoints into the service then two license types are now required.  The RCAS solution operates on concurrent call traversal licenses, so every endpoint call that needs to route through RCAS to reach its intended destination requires an RCAS license (category ‘B’).  In this case because the call is ultimately headed to the RealConnect Service in order to join a Teams meeting then an endpoint license for the service (‘A’) is also required.  Thus, each call from an endpoint joining a Teams meeting will consume 2 licenses: one traversal license and one service license.

The license SKUs which fall into this category all include the text “RealConnect Access Suite – Concurrent User License” in their descriptions.

RealConnect for Clariti

A Poly Clariti deployment is licensed on concurrent use of bridge resources so there is no licensing cost applied to call traversal here like with RCAS.  In this scenario any VTC which lands on the bridge requires a Clariti license (category ‘C’), as well as any outbound calls placed by the bridge.  As outlined in the earlier architecture discussion this scenario involves the bridge placing an outbound call into the RealConnect Service in order to cascade the separate MCUs.  When a call comes into the service from a Poly bridge in this scenario then it consumes a much lower-cost license than when an endpoint calls into the service.  Because the actual endpoints are already consuming Clariti licenses then a different license for the service was created to specifically address meeting cascade connections from the Clariti bridge.  For each unique Teams meeting that Clariti needs to cascade into at one time a cascading license (category ‘D’) is required.  The first VTC call into a Teams meeting consumes 3 licenses (2 for Clariti and 1 for the service), but when any additional VTCs joins the same Teams meeting then only a single Clariti license is consumed per additional VTC.

There is a single SKU (4870-09900-660) for the additional cascading license described as “RealConnect Service for MSFT Teams Video Interop. Concurrent Subscription for Clariti“.

This topology is much more nuanced in potential license utilization due to multiple factors which could be at play at the same time.  To best plan for how many licenses of each category might be used it is important to understand two different behaviors.

First, the number of concurrent Teams meetings has a direct impact on consumption of additional Clariti licenses and service cascading licenses.

The total number of different licenses consumed at one time will depend on both the number of endpoints in use as well as the number of unique Teams meetings the endpoints are joining.  When a single VTC joins a Teams meeting that call will consume 2 Clariti licenses (‘C’) and 1 service cascading license (‘D’).  If another VTC joins the same Teams meeting then that endpoint only consumes 1 additional Clariti license (‘C’) because the cascade from the bridge to that specific Teams meeting has already been established by the first endpoint so there is no need for the bridge to place an additional outbound call using up more Clariti and service licenses.

But, if another VTC joins a different Teams meeting which does not currently have any other VTCs in it then that call would trigger the establishment of another call from the bridge into the service to cascade a different VMR on the bridge into that second Teams meeting.  What this means is that the number of cascading licenses (‘D’) consumed depends on the number of concurrent Teams meetings.  The general guidance covered at the end of this previous article simply states to acquire half the number of Clariti licenses (‘C’) in a properly sized environment as cascading licenses (‘D’).  Meaning if a deployment has 60 Clariti licenses then it is not possible to ever utilize more than 30 cascading licenses given that a single VTC in a Teams meeting consumes 2 Clariti licenses (1 for the endpoint, 1 for the cascade).

Second, the RealConnect for Clariti Split Model allows some endpoint calls directly into the service which introduces the need to acquire both endpoint and cascading licenses for the service.

While an exact number of service cascading licenses can be decided based on internal Clariti sizing the number of additional service endpoint licenses needed is more of an moving target.  It really comes down to balancing any unregistered external corporate endpoints with the possibility of any invited external party attempting to join from their own standards-based video system.