[pulseaudio-discuss] Inconsistent SDP database after HSP AG registered

[João Paulo Rechi Vita]

Hello Luiz, Johan, Marcel!

(cc'ing pulseaudio-discuss for awareness, but I believe nothing is
wrong on PulseAudio side)

I'm investigating a problem on to the interaction of more than one
PulseAudio instance with bluetoothd, specifically when registering the
HSP external profiles (oFono is not being used). On my setup, one
PulseAudio instance is started for GDM, and when the user logs in,
another instance is started for the user session. A few moments later
the GDM session finishes and the first PulseAudio instance exits.

The first instance is able to register support for HSP AG just fine,
and a SDP record is added to the server. When the second instance
starts, while the first one is already active, the RFCOMM server fails
to bind the socket, but the profile probe does not fail. From
PulseAudio's perspective everything worked just fine, but a SDP record
is not added to the server. This does not have any symptoms at this
point, since the record from the first instance is still active. You
can find the logs when that happens bellow.

Aug 29 20:03:40 mimieux pulseaudio[3166]: D: [pulseaudio]
backend-native.c: Bluetooth Headset Backend API support using the
native backend
Aug 29 20:03:40 mimieux pulseaudio[3166]: D: [pulseaudio]
backend-native.c: Registering Profile /Profile/HSPAGProfile
00001112-0000-1000-8000-00805f9b34fb
Aug 29 20:03:40 mimieux pulseaudio[3166]: I: [pulseaudio]
backend-ofono.c: Failed to register as a handsfree audio agent with
ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono
was not provided by any .service files
Aug 29 20:03:40 mimieux pulseaudio[3166]: D: [pulseaudio]
bluez5-util.c: oFono is running: no
Aug 29 20:03:40 mimieux bluetoothd[796]:
src/profile.c:register_profile() sender :1.864
Aug 29 20:03:40 mimieux bluetoothd[796]: src/profile.c:create_ext()
Created "Headset Voice gateway"
Aug 29 20:03:40 mimieux bluetoothd[796]:
src/profile.c:ext_adapter_probe() "Headset Voice gateway" probed
Aug 29 20:03:40 mimieux bluetoothd[796]: RFCOMM server failed for
Headset Voice gateway: rfcomm_bind: Address already in use (98)
Aug 29 20:03:40 mimieux bluetoothd[796]:
src/profile.c:ext_device_probe() Headset Voice gateway probed with
UUID 00001108-0000-1000-8000-00805f9b34fb
Aug 29 20:03:40 mimieux bluetoothd[796]: src/service.c:change_state()
0x556fa9e9f470: device 00:16:94:0B:1B:8B profile Headset Voice gateway
state changed: unavailable -> disconnected (0)

The problem happens when the first instance finally exits, and its SDP
record is removed. At this point there is a valid agent for the
profile (the second PulseAudio instance), but its UUID is not in list
of supported UUIDs on the SDP server for that adapter, and not on the
UUIDs property on the adapter object on D-Bus either.

While pairing and re-connections to headsets seem to be working fine
even after that failure, this is causing problems with a downstream
change we carry on PulseAudio at Endless, where we look at the
supported UUIDs from both the adapter and the device to device whether
a certain profile is supported, and then only create card profiles for
supported Bluetooth profiles. So in this case we end up without a card
profile for HSP even though the profile is actually supported. This
change is pending upstream review on
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/50,
but in any case the SDP database and UUIDs property should be
consistent with the list of supported profiles.

I'm not familiar with BlueZ' RFCOMM implementation, and haven't really
touched on BlueZ' code in a while, so I don't know what is the right
fix for this problem. I can write patches if given a general direction
of how to approach it, but I'm happy to test someone else's patches as
well.

Thanks!

--
João Paulo Rechi Vita