I assume an active decline. If it fails after my test-period I do assume a time-out. This does not work perfectly as every device has a different time out period. Exceptions thrown are no solid indication of the response. - Possibility to cancel send requests (or better: Get stream requests) if not acted upon within a certain period of time. Similar to issue above. I know one might be able to achieve this with multithreading and asynch send requests, but this is cumbersome to program (at least for my knowledge) As far as I know, this is rather a bluetooth design flaw than a BlueTools one. You are requesting a stream and are not given any specific timeout/return codes depending on you are slow to respond to this or not at all. I will dig deeper into this in the future though to see if my suspicion is correct. quote: - Ability to detect receiving device type. As far as I know Bluetooth supports device groups allowing to identify if the device on the other end is e.g. a phone device, audio device, computer device, etc. Some other BT Apis support this feature Implemented as of BlueTools 1.21 (Beta 1) quote: - Multi dongle support. Allow bluetools to address more than one dongle on one PC. 2 Dongles would be fine, 4 would be great. Not sure if windows and the bluetooth stacks can handle that today Certainly something we are considering for the future. quote: - Ability to get