The purpose of this article is to demystify a common misconception with how Microsoft Teams allows various types of clients and devices to communicate between each other when leveraging several different native features.

The most important concept to understand in this article is that there is actually no direct pairing happening between the Teams clients among these scenarios.  Yes, then the title of this article is purposely misleading.  The word “pairing” was specifically included as that term is commonly used for categorizing the behavior of tying multiple devices together.  In Microsoft Teams there are several different scenarios where separate Teams clients and devices can communicate between each other to provide some beneficial feature or capability.  Sometimes these are clients which are both registered to Teams with the same user account while in other scenarios different user accounts are registered to each.  Yet, in Microsoft Teams at no point do any of these client or devices actually “pair” directly with each other, nor communicate directly between each other.

The same basic pattern of communications is utilized throughout all of the scenarios covered in this article.  Notice that in all the diagram below there are no lines of communication depicted directly between the clients and devices.  Each of the components in the diagram all contain their own native Teams client and are actively registered to the Teams service.  It is only through each client’s existing registration to Teams that they will communicate between each other.

All types of communication between clients and/or devices is handled directly by the Teams service in a client-server-client path and individual Teams clients do not establish any level of one-way or two-way communications directly between themselves, except for one specific scenario.  This is during peer-to-peer calls where audio, video, and/or screen sharing is involved.  Although Microsoft Teams is not a SIP-based platform like its OCS/Lync/Skype predecessors it still adheres to the concept of Internet Connectivity Establishment (ICE) to negotiate media streams.  When a Teams client or device places a peer call directly to another Teams client or device then any audio, video, or screen sharing sessions will always attempt to be routed directly between both clients.  This is only possible though when both parties can communicate directly between each other using their local host IP addresses which is limited to internal, routed IP networks and some VPN networks.  If peer-to-peer network communications cannot be successfully established then the Teams service will facilitate the media sessions between them in a client-server-client path by leveraging various media relay components available in the Teams cloud.  Any other Teams capabilities available in peer communications like chat or file sharing are always transmitted over the existing communications path to the Teams service only.  When participating in a Teams meeting though the Teams service directly handles all aspects of communications between all meeting participants, including all media streams.

While this architecture has one major benefit and one major limitation the trade-off is quite beneficial.  The downside is that every client or device must be actively registered to the Teams service as all communications will go through that connection, so these features are only available to native Teams clients.  The upside is that by Teams handling all of these communications scenarios directly then it does not matter how individual clients or devices are connected to an network, just as long as that network provides correct connectivity to the Teams service.  For example, attempting to share content from a smartphone on a guest Wi-Fi network to a meeting room system a few feet away which is connected to a different, secured cooperate network is often not possible when using a technology like AirPlay due to the networking requirement for those two devices to identify each other and setup a direct line of network communications.  Even when attempting to leverage a direct wireless connection like what Miracast provides the communication establishment is still subject to the myriad of personal devices available with different chipsets and radios which may not always function together.  And all of this complexity is further exasperated by the fact that the majority of smartphones only support one of these options so multiple technologies must be included to support the different platforms.  For example, most Android devices support Miracast, yet iOS devices only support AirPlay.

By instead using the existing, established communication path from the client or device to the Teams service then all of those complications are removed from the equation.  Yes, there is some added latency when sending data between two clients in the same proximity via a cloud service, but most of the scenarios are not heavily impacted by network latency.  The benefit of this architecture is significant as a device like a room system connected to a more secure physical network can easily interact with a Teams client connected to a basic guest Wi-Fi network with only access to the Internet.

A hurdle created by using this approach is that the devices still need a way to discover one another so Teams can initiate communications between them.  Moving away from a short range wireless-based approach removes the inherent knowledge of a nearby device.  To address this Microsoft decided to leverage an ubiquitous capability already embedded in most the hardware today which is capable of running a native Teams client: Bluetooth.  Even more important is the fact that only part of the Bluetooth technology is leveraged, leaving out the complicated and oft-unsuccessful pairing process.  Yet, the inclusion of Bluetooth technology as a method of device discovery seems to be one of the major causes for misunderstanding how some of these features work. 

As mentioned earlier the Teams clients or devices using Bluetooth do not establish any lines of communications between each other, which also means they do not utilize a traditional Bluetooth pairing procedures.  Among the scenarios where Bluetooth is involved its only purpose is to assist in the process of identifying to the Teams service which clients to connect together.  That assistance is limited to one party ‘beaconing’ its name so that another party in direct proximity can listen for it.  The listening party then uses that information to tell the Teams service that it wants to communicate with the other device and Teams will then decide if it is possible and/or allowed, and if so will handle the communication.  An analogy for this pattern of communication might be where one person yells their phone number across a room for someone else to hear it.  The second person uses their phone to call the number they heard and then from there the two people only speak to each other across the established phone call.

The multiple scenarios discussed in this article focus on features available when native Teams clients are used in conjunction with various native Teams devices like IP phones and video conferencing systems.  These are all new features designed to take advantage of the Microsoft Teams architecture and may differ in functionality and behavior from similar use-cases when compared to previous platforms like Skype for Business.  Incorrectly assuming that the underlying technology is the same between Skype for Business and Teams for some features is one reason why these new Teams features can be misunderstood.

Also, for the sake of clarification it is worth reiterating the latest branding changes in the native Microsoft Teams video conferencing system platforms.  What was originally referred to as a “Skype Room System” (SRS) and was rebranded to Microsoft Teams Rooms (MTR) a while ago has recently been updated to be called Microsoft Teams Rooms on Windows (MTRoW).  This change made room for the “Teams Collaboration Bars” to join the MTR family with their new identity of Microsoft Teams Rooms on Android (MTRoA).  This distinction is important to understand as some features covered in this article may only apply to one of the MTR categories while other features may apply to both.

Proximity Join

This feature allows supported Teams clients on desktop and mobile devices to easily bring a Microsoft Teams Room device or a conference phone into a Teams meeting that it was not originally invited to.  In the past this would require the meeting organizer or another invited participant to manually forward the meeting invitation to the desired room’s mailbox and then wait a minute or so for it to appear on the device’s calendar before being able to join.  Alternatively Teams allows a participant joining a meeting to manually add a room device into the meeting instead, but the user would typically need to search for and select the desired room form the corporate address book.  Proximity Join takes this one step further by allowing the client to listen via Bluetooth for a beacon being transmitted from a room system or conference phone which may be nearby.  If one is discovered then Teams will place that directly at the top of the rooms list and even suggest directly in the pre-meeting join window that the discovered room be used for this meeting.

This automatic discovery capability was the first feature brought to Teams devices which allowed a personal device to interact with a dedicated meeting device to provide new functionality never before available in Skype for Business.  It is currently available on all MTRoW and MTRoA platforms as well as select conference phones models (like the Poly Trio).  It is not available in desk phone models (like the Poly CCX).

There are multiple names used to describe this overall feature but it was first officially launched on the MTRoW platform as Proximity Detection.  This name refers to the ability for Teams desktop and mobile clients to utilize the Bluetooth radio on their own device to listen for any ‘beacons’ in the immediate area which may be transmitted by a supported Teams device.  For example, a MTRoW device has its Bluetooth Beaconing setting enabled by default which means it will use the embedded Bluetooth radio to transmit its name.

Better Together

More recently Microsoft has begun adding functionality into the Microsoft Teams Phones devices to deliver on a long-standing capability of their previous platforms: Better Together.  This term has been used specifically when referring to improving the user experience when signed into a desktop client application and a desktop phone with the same user account.  Independently both clients are capable of performing many of the same things, but synchronizing some of those actions is what customers are looking for.

This concept originally dates back to Office Communication Server with the first Microsoft UIC phone: the Polycom CX700 (codenamed Tanjay).  This phone (and the identical models manufactured by a few other Microsoft partners) included a USB Type-B port which allowed it to be connected directly to a desktop PC.  While the phone would still register to a server via its network connection the USB connection was used to provide the initial “Better Together” functionality of some basic features like user sign-in assistance, call pickup and a few other standard call controls.  The next generation of Lync Phone Edition devices came along with Lync Server 2010 and utilized the same Better Together architecture via USB.  When Skype for Business arrived though Microsoft had decided to shift away from phones running their own software and instead moved to the 3rd Party Interoperation Program (3PIP) which used partner-developed, officially certified IP phones that initially did not support any Better Together functionality.  Eventually this was added using a completely different architecture as the Skype for Business clients did not include any embedded support for Better Together features.  Thus, some of the certified phone vendors developed their own Windows desktop application which was used to interface with both the Skype client on the PC and a certified desktop phone (like the Polycom VVX) via Ethernet.  This new approach was awkwardly entitled “Better Together over Ethernet” (BToE) and the available feature-set was not always identical between different vendor’s phones.

With the introduction of certified IP phones for Teams Microsoft decided to return to developing and managing their own IP phone application.  This puts almost the entire spectrum of native Teams capabilities available on certified Teams phones into the Microsoft Android-based IP phone client, regardless of which vendor’s phone the client is running on.

Given the theme of this article it should be quite obvious at this point that Microsoft was not going to develop new Better Together functionality using any of the previous models where the client and phone communicated directly between each other.  As depicted in the earlier diagram the Teams phone and Teams client are both signed into Teams using the same user account and any communications between them are handled by the Teams service.  Just as with the Proximity Join feature Microsoft decided to leverage Bluetooth to assist with the initial connection process, but In order to use the provided Better Together feature set the phone is not paired to a PC via the traditional Bluetooth pairing process.  Bluetooth is only used to assist in the connection process within Teams and is not used for any communications between the clients.  This is not Better Together over Bluetooth; it’s simply “Better Together”.

Better Together is enabled by default for all users in a tenant.  This is controlled by the AllowBetterTogether parameter which is included in the Set-CsTeamsIPPhonePolicy PowerShell cmdlet.

The default Global policy in a tenant will have that parameter set to “Enabled”:

For whatever reason Microsoft chose to make this newer parameter type a String instead of Boolean. Typically “on/off’ parameters would be set to values of “$true” or “$false” in PowerShell, but this parameter needs to be set to a literal string of “Enabled” or “Disabled” to control the behavior. 

At the time this article was posted the implementation of Better Together in the most recent Teams release (1449/1.0.94.2020111101) only supports connecting a certified Teams phone with embedded Bluetooth with the Windows desktop 64-bit Teams client.  The available functionality is limited to synchronizing the lock state of the phone with the PC and allowing the phone to be selected as an audio/video device when joining Teams meetings. (Support for peer and group calls is currently planned for availability in June of this year.)

Connect Phone

In order to establish a connection between the desktop client and the phone the following steps must be completed.

• Sign into a Teams desktop client on a Windows PC with Bluetooth enabled.

• Sign into a supported Teams IP phone using the same user account.  This phone must support Bluetooth (e.g. Polycom CCX 600) and be located in general proximity to the desktop client .

• On the phone select Connect to a device from the main menu and within a few seconds the name of the nearby Windows PC with the same user signed into the Teams desktop client should appear. 

• Tap the Connect button on the phone and the following message should appear on the associated Windows desktop client.

• Click the Connect button on the PC to complete the process.  To view or manage the connected the device go to Settings > Devices in the Teams desktop client and select Manage Devices.

Synchronized Lock/Unlock

The connected phone will automatically lock and unlock its screen when the Windows PC is locked and unlocked.  This basic capability is as straight-forward as it sounds.  If the Phone Lock feature has been enabled on the connected phone then when the Windows PC is locked or unlocked the phone will automatically lock and unlock to mirror the PC’s state.

• To enable this feature navigate to Settings > Device Settings > Phone Lock from the phone’s main menu and then activate the Enable Phone Lock setting.

• When prompted enter a new 6-digit device PIN.  This PIN will serve as the unlock code for this phone only and is not associated with any other PINs in Teams.

Be aware that the inactivity value selected for the Phone Lock Timeout setting will not be applicable when the phone is actively connected to a desktop client.  As long as the Windows PC is not locked the phone will remain unlocked.  When the Windows PC is locked then the phone’s lock screen will appear and can either be unlocked manually by swiping up and entering the previously defined PIN or automatically by unlocking the connected PC.

Meeting Experience

The connected phone can now be selected as an audio device when joining Teams meetings and phone models with a landscape display (e.g. Poly CX600) will also display any screen sharing sessions.

This feature is a bit more complicated to understand as there are a few limitations in the current implementation.  Firstly, it is limited to Teams meetings only so a connected phone cannot be used as the PC’s audio device when placing or receiving peer calls from the Teams desktop client.  Secondly, when selecting the phone as the Audio device in the Teams desktop client it automatically changes the Video device to the phone as well.  This means that the desktop client will not be able to send video while at the same time sending/receiving the audio on the phone. When using a Teams-certified video phone (e.g. Yealink VP59) the phone will send and receive both audio and video streams, but when using an audio-only Teams phone then no video can be sent into the meeting.

The two possible user experiences are as follows:

• If the connected phone supports video (e.g. Yealink VP59) then the user’s own video and audio will both be sent into the meeting from the phone.  The desktop client will not send or receive any audio.  The desktop client cannot send video, but it will receive video streams from all other meeting participants.  Both the desktop client and phone can display video and screen sharing.  Only landscape-orientation phones support receiving Screen or Windows sharing in Teams while PowerPoint and Whiteboard sharing are not supported on any Teams IP phone.

• If the connected phone does not support video (e.g. Poly CCX 600) then the user’s own video cannot be seen by others in the meeting.  The desktop client cannot send video, but it will receive video from all other meeting participants.  The phone will handle both sending and receiving audio but will not receive video.  Screen sharing works on landscape phones the same as described in the previous scenario.

Teams Casting

This is an all-new feature which Microsoft plans to deliver soon to both Microsoft Teams Room platforms.  Based on Microsoft’s public roadmap for Teams this feature should be coming to the MTRoW in January and then to the MTRoA in February although it appears that the Teams mobile clients will not support this feature until later this year.

Currently there few details which can be openly shared on this upcoming feature, but the description in the public roadmap offers a sufficient amount of information to get an idea of what it will provide: “For quick ad-hoc sessions that don’t necessarily require setting up a formal meeting, people can use Teams casting to wirelessly connect to a Teams Room, and display content from their mobile phone. Users can broadcast their screen and cast content stored on locally on their device or accessible via Office 365.”

This is a capability many Teams customers have been asking about for some time now.  Currently in order to share content up on the screen of a Teams Room System the device (depending on the platform) would need to be included in either a peer call or a meeting with the device attempting to share the content.  This casting feature will allow a native Teams device to simply send the shared screen content to the room system without having to be in a call or meeting with the room system.  If the Teams Room is in currently in a meeting though then the casting feature will function the same, allowing the shared content to be seen both by those in the room and all other participants in the meeting.

The description is a bit misleading though in its use of the phrase “can use Teams casting to wirelessly connect to a Teams Room” as that is technically inaccurate.  The sharing device does not transmit or ‘cast’ the content stream directly to the Teams Room directly.  The device will send the content stream to the Teams service which will in turn direct the stream down to the desired room system.  The word “wireless” was likely used in the description as it also specifically calls out “their mobile phone”, which seems to infer that this feature may only be supported with mobile device platforms like iOS and/or Android and possibly not desktop clients like Windows or Mac. (This is complete speculation based on the wording in the public description.)  There is also no mention of Bluetooth but one may make an educated guess that the Bluetooth beaconing already available in the Teams Room systems might also be used to assist the operator of the sharing device in identifying which room system the Teams service should relay the content to.

(Once this capability is generally available in Microsoft Teams then additional details will be added here.)

Microsoft Teams Rooms on Android Touch Controller

This scenario is different than those above in that it is not something a Teams user would establish themselves or even be aware of.  This is an underlying connection which does not leverage Bluetooth beaconing as device administrators manually establish a connection when deploying a center-of-room touch controller with an MTR on Android device. This scenario is not yet generally available as it leverages functionality in the upcoming redesigned controller interface.  As Microsoft has discussed and demonstrated in several public events they are planning to update the existing touch controller experience on the MTRoA to look and operate nearly identically to the MTRoW.  This was originally planned for release in 2020 but has recently been rescheduled for availability in February 2021.

This is only applicable to Microsoft Teams Rooms on Android devices.  The MTRoW platform has always included a center-of-room touch controller which is simply a touch display connected directly to the core Windows PC via USB.  The MTRoA touch controller (e.g. Poly TC8) is a standalone network-connected device thus it requires a method to discover and communicate with the Teams client running on the MTRoA device (e.g. Poly Studio X30).

Just as with all the other scenarios covered in this article communications between the Teams clients on both the touch controller and the MTRoA device will be handled by the Teams service, and an administrator will facilitate the one-time connection between devices during deployment.

(Once this capability is generally available in Microsoft Teams then additional details will be added here.)