Windows and Microsoft Teams hijacks connection to bonded BLE peripheral, preventing custom Windows application access

We have a nRF52840 peripheral using the S140 SoftDevice on the SDK15.3.

Our peripheral is configured to advertise with the following advertising data: flags (BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE only), 128-bit custom service UUIDs, and a name. This uses the scan response. Our connection type is connectable directed, but we've tested once with undirected and we saw no change in behavior. Our peripheral always advertises except when connected. After disconnecting, it immediately restarts advertising. Our peripheral's GATT table contains a custom GATT service with a few custom characteristics. We also have the Generic Attribute Service present. Bonding is used.

Our device solely interacts with Windows, and we only support one Windows bond and connection at a time. We have a Windows application that performs scanning, selects our nordic peripheral and initiates the connection using the Windows BLE API. Normally, our application is in full control of the BLE connection. However, we have observed that if another BT audio device is connected AND Microsoft teams is open, the Windows OS (or the MS teams application) automatically connects to our peripheral. Our peripheral will trigger a disconnection after 5 seconds because Windows is not sending a custom authentication message over our custom GATT characteristic. But after each disconnect, Windows automatically reconnects. This prevents our application from successfully completing scanning and connecting the to the peripheral, as Windows hijacks the connection and we can't find a way in the Windows BT/BLE API to obtain a handle to the connection. As soon as we quit MS Teams, Windows stops auto-connecting and our application can successfully connect and use the peripheral.

Overall, it seems that MS Teams wants to control our peripheral (but only when also connected to an audio device). We've reviewed how Windows enumerates our BLE peripheral, and there is no evidence of a standard service such as HID that would make sense to trigger an auto-connection. Nothing in our advertisements or GATT table would suggest this. While this is likely a Windows/MS Teams issue, we're curious whether this has ever been observed before. If so, are there any red flags with our Nordic configuration?

Parents
  • Our team had a discussion with MS Teams support, but they claimed innocence because it "could not be a Teams issue because Teams is not a BT device" which we've shown is demonstrably false (behavior is 100% correlated and reproducible to teams being open or not). Teams isn't necessarily doing anything illegal, but it also isn't being a good neighbor by requesting connections to peripherals it never uses. It's also possible that the Windows OS is doing something strange based on the APIs used by MS Teams.

    Regardless, we've found an alternative Windows API using the DeviceInformation class that allows our Windows application to "connect" and obtain a handle to our BLE peripheral even when Windows has already connected to our peripheral from outside of our Windows application.

Reply
  • Our team had a discussion with MS Teams support, but they claimed innocence because it "could not be a Teams issue because Teams is not a BT device" which we've shown is demonstrably false (behavior is 100% correlated and reproducible to teams being open or not). Teams isn't necessarily doing anything illegal, but it also isn't being a good neighbor by requesting connections to peripherals it never uses. It's also possible that the Windows OS is doing something strange based on the APIs used by MS Teams.

    Regardless, we've found an alternative Windows API using the DeviceInformation class that allows our Windows application to "connect" and obtain a handle to our BLE peripheral even when Windows has already connected to our peripheral from outside of our Windows application.

Children
No Data
Related