Proposal: active scanning with scan response

[mikolajefento]

Currently, there is no option in requestLEScan to listen for scan responses, nor is there a field in BluetoothAdvertisingEvent to access the scan response. I believe it would be beneficial to introduce 'normal' and 'active' scan modes, as there appears to be confusion in various implementations at present.

For instance, in Chromium, the watchAdvertisements method returns two subsequent events: one with standard manufacturer data and another with the scan response. However, when using requestLEScan, only the standard advertising response is provided.

I propose that establishing a clear distinction would, at the very least, aid in determining which API is stable enough in different implementations to effectively utilize scan responses.

[dlech]

This sounds like platform-specific differences showing through.

On Windows, different events are received for each advertisement packet received so we get separate events for "regular" advertisement data and a separate event for the scan response. But on macOS, Android and Linux events only indicate that something in the advertisement data changed and there is no way to tell on those platforms which information was in the advertisement data and which data was in the scan response. So this one is probably more of an implementation issue where Windows needs to be made to work more like the other platforms under the hood so that web developers don't have to handle OS-specific differences in their apps.

Also, on macOS, passive scanning is not possible (also not an easy way to do it on Linux). So I think it only makes sense to have active scanning in WebBLE.

[alvinjiooo]

Just to clarify, does the "scan response" mean serviceData in advertisementreceived?
Both watchAdvertisements and requestLEScan induce advertisementreceived so I assume if scan responses are available to one it should also be available to another?

[dlech]

"scan response" in this context means an advertisement data packet with a PDU Type of SCN_RSP. What types of advertisement data it contains depends entirely on the peripheral device.

I would expect watchAdvertisements and requestLEScan to return the same info for the same device, so if it isn't, that sounds like a potential implementation bug to me.

[alvinjiooo]

Yes, I would assume watchAdvertisements and requestLEScan to see the same information if the advertisement event matched what filter defined. Although the complete filtering implementation is not finished yet.

In Chromium:
content/browser/bluetooth/advertisement_client.cc
// TODO(crbug.com/707635): Support manufacturerData and serviceData
// filters.

[mikolajefento]

It seems that the teams implementing BLE scanning and advertising would need to unify how scan responses work across all platforms. However, with no clear instructions on how it should work, it could lead to different implementations on different browsers, resulting in an API that cannot be used in the real world, or at least is very difficult to use.

For example, on Android, scan response is integrated with advertising data (see: context), but from my experience on iOS, the data is split into two subsequent messages. I have found that it works similarly on Windows.

My proposal is to add a field in the scan event for the scanResponseData (similar to serviceData). This way, it would be clear to teams implementing the specification that they should include this data (or null if not present) inside the event, and therefore they must glue together incoming SCN_RSP data packets with ADV packets

[reillyeon]

From the conversation above it sounds like the issue is whether two advertisementreceived events are fired, each with data from a single Bluetooth packet or one advertisementreceived event is filed with the combined data from both packets. I'm trying to understand whether this difference matters to applications because there might be some data missing or incorrectly combined, or if all the data is present but applications need to consider the possibility it will be split across multiple events. The former would be a serious issue while the latter is annoying but workable.

[mikolajefento]

@reillyeon, based on my experience with Chromium implementation, I've observed missing data when using requestLEScan. This could be due to incomplete implementation, as pointed out earlier. On the other hand, with watchAdvertisements, data arrives separately on Windows but combined on Android, which is indeed annoying but workable 😄.

Considering this, it's conceivable that different browsers may handle data combination differently, leading to potential debugging challenges. To streamline this process, a simple addition to the Web Bluetooth spec could be added. If the specification explicitly stated whether scan responses should be combined or split, browser developers could align their implementations accordingly facilitating long-term maintenance.