Comment 25 for bug 1798400

The premise is that my ignorance on BT is complete. After some investigation, it is my understanding that RFCOMM channels are to RFCOMM communication a bit like ports in TCP and UDP, with the main difference that while there are really a lot of TCP/UDP ports and some of them are reserved as "well known ports", the number of channels in RFCOMM is extremely limited, so that there cannot be well known ports. Furthermore, I understand that no one should "hardwire" RFCOMM channels and that channels should be released whenever not strictly needed.

If this understanding from myself is correct, there may be issues both in LibO and in PA.
From my understanding:

- LibO and the Impress remote should not hardwire RFCOMM channel 3. I understand that they should dynamically allocate a channel and make it discoverable via SDP.

- Impress should not keep binded to an RFCOMM channel all the time. There should be a visible option to switch on and off the binding (probably there should be a couple of impress remote related options in the "Slide Show -> Slide Show Settings" window, including one to fire up the BT rfcomm binding).

- PA should probably similarly not hardwire channel 3 for its HSP role, but here the situation seems more complex, because it may be the case that PA needs to strive for compatibility with devices that do not play to the rules.

- PA should probably have a DBUS interface to switch on and off the RFCOMM binding, so that to use an application needing RFCOMM channel 3, one does not need to take down the whole of PA.

I have opened a bug on PA too. See it at https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/827. That report is bad, because when I made it my understanding of BT was even poorer than it is now.

In any case, it seems to me that the current issue could be fixed completely on the LibO side, by dynamically allocating the channel and by letting the app running on the phone discover it via SDP.