Hi all, I am trying to set up a simple HFP demonstrator using BlueZ+oFono+PulseAudio, with a dbus client that coordinates the three of them. Being a simple prototype, the goal is to see how they behave and analyze how well it would all scale. The first question that arises is quite simple. In a multi-phone scenario (all of them connected to our PC using Bluetooth HFP), oFono properly lists all the phones as available modems. I would like to know whether these modems can be associated to their underlying bluetooth device (mac address, bluez device dbus path, or whatever). I have been looking on the available modem properties but this seems not to be present. Could somebody confirm this or otherwise explain how it can be done?

The purpose of my interest is that, depending on the use-case, the final user would have to choose the modem (or device) manually.

Hi Denis, On 08/10/2011 08:45 AM, Denis Kenzior wrote: > Hi Mikel, > > On 08/10/2011 03:46 AM, Mikel Astiz wrote: >> Hi all, >> >> I am trying to set up a simple HFP demonstrator using >> BlueZ+oFono+PulseAudio, with a dbus client that coordinates the three of >> them. Being a simple prototype, the goal is to see how they behave and >> analyze how well it would all scale. >> >> The first question that arises is quite simple. In a multi-phone >> scenario (all of them connected to our PC using Bluetooth HFP), oFono >> properly lists all the phones as available modems. I would like to know >> whether these modems can be associated to their underlying bluetooth >> device (mac address, bluez device dbus path, or whatever). I have been >> looking on the available modem properties but this seems not to be >> present. Could somebody confirm this or otherwise explain how it can be >> done? >> > Have a look at the Modem.Name property, HFP_HF plugin sets this based on > the BlueZ Device.Alias property of the remote device. Which should be > either the remote device name or the local alias. This might actually > be enough for your purposes. > >> The purpose of my interest is that, depending on the use-case, the final >> user would have to choose the modem (or device) manually. >> > Depending on the usecase you might require more information, such as the > bdaddr of the remote device. In that case you will have to do a bit > more work, such as defining a new atom that exports the information you > require. > > Regards, > -Denis Thanks for your answer. I replied to Marcel's message before reading yours so we could hopefully merge into one message thread. One specific point to your answer: the device alias is certainly available (and in this case would satisfy the use case of manually-select-by-alias, so to speak) but that doesn't seem to scale well if you would also like to use other criteria (for example, to filter some devices depending on their icon, available services, etc.).

Hi Mikel, > I am trying to set up a simple HFP demonstrator using > BlueZ+oFono+PulseAudio, with a dbus client that coordinates the three of > them. Being a simple prototype, the goal is to see how they behave and > analyze how well it would all scale. > > The first question that arises is quite simple. In a multi-phone > scenario (all of them connected to our PC using Bluetooth HFP), oFono > properly lists all the phones as available modems. I would like to know > whether these modems can be associated to their underlying bluetooth > device (mac address, bluez device dbus path, or whatever). I have been > looking on the available modem properties but this seems not to be > present. Could somebody confirm this or otherwise explain how it can be > done? > > The purpose of my interest is that, depending on the use-case, the final > user would have to choose the modem (or device) manually. you would need to be a bit more specific on what the actual use case entails here. How would selection work and how the user is involved in it. Depending on that, things should be done differently. So besides that, some simple pieces that come to mind quickly are to create a HFP devinfo atom driver that just exports the BD_ADDR as serial number.

> > I am trying to set up a simple HFP demonstrator using > > BlueZ+oFono+PulseAudio, with a dbus client that coordinates the three of > > them. Being a simple prototype, the goal is to see how they behave and > > analyze how well it would all scale. > > > > The first question that arises is quite simple. In a multi-phone > > scenario (all of them connected to our PC using Bluetooth HFP), oFono > > properly lists all the phones as available modems. I would like to know > > whether these modems can be associated to their underlying bluetooth > > device (mac address, bluez device dbus path, or whatever). I have been > > looking on the available modem properties but this seems not to be > > present. Could somebody confirm this or otherwise explain how it can be > > done? > > > > The purpose of my interest is that, depending on the use-case, the final > > user would have to choose the modem (or device) manually. > > you would need to be a bit more specific on what the actual use case > entails here. How would selection work and how the user is involved in > it. Depending on that, things should be done differently. > > So besides that, some simple pieces that come to mind quickly are to > create a HFP devinfo atom driver that just exports the BD_ADDR as serial > number. Only the BD_ADDR is not enough, the device can paired with two or more adapters. Exports its DBUS path seems a best option. HFP plugin already keep the path for internal use, so its just a matter of put it devinfo. Also, the modem path gives you the information you need. The numbers there are the adapter bd_addr followed by the remove device bd_add.

>>>> I am trying to set up a simple HFP demonstrator using >>>> BlueZ+oFono+PulseAudio, with a dbus client that coordinates the three of >>>> them. Being a simple prototype, the goal is to see how they behave and >>>> analyze how well it would all scale. >>>> >>>> The first question that arises is quite simple. In a multi-phone >>>> scenario (all of them connected to our PC using Bluetooth HFP), oFono >>>> properly lists all the phones as available modems. I would like to know >>>> whether these modems can be associated to their underlying bluetooth >>>> device (mac address, bluez device dbus path, or whatever). I have been >>>> looking on the available modem properties but this seems not to be >>>> present. Could somebody confirm this or otherwise explain how it can be >>>> done? >>>> >>>> The purpose of my interest is that, depending on the use-case, the final >>>> user would have to choose the modem (or device) manually. >>> you would need to be a bit more specific on what the actual use case >>> entails here. How would selection work and how the user is involved in >>> it. Depending on that, things should be done differently. >>> >>> So besides that, some simple pieces that come to mind quickly are to >>> create a HFP devinfo atom driver that just exports the BD_ADDR as serial >>> number. >> Only the BD_ADDR is not enough, the device can paired with two or more >> adapters. Exports its DBUS path seems a best option. >> HFP plugin already keep the path for internal use, so its just a matter of put >> it devinfo. >> Also, the modem path gives you the information you need. The numbers there are >> the adapter bd_addr followed by the remove device bd_add. > you can not get the BD_ADDR out of the device path. The device path is > arbitrary. And if anybody considers to misuse it, then I will add even > more random bits into it. > Yes, I was assuming that ofono did not intentionally guarantee to encode this kind of information in the dbus path. Exposing the needed information explicitly seemed more clear. Considering the case pointed out by Gustavo about two adapters paired to the same device, I agree that the device path is the appropriate choice. Besides, do you think exposing this information can be interesting for the upstream project? Do you believe that this is a special use-case? I mean that any bluetooth-centered application would probably like to know the relationship between the modems and the devices.

> > > > I am trying to set up a simple HFP demonstrator using > > > > BlueZ+oFono+PulseAudio, with a dbus client that coordinates the three of > > > > them. Being a simple prototype, the goal is to see how they behave and > > > > analyze how well it would all scale. > > > > > > > > The first question that arises is quite simple. In a multi-phone > > > > scenario (all of them connected to our PC using Bluetooth HFP), oFono > > > > properly lists all the phones as available modems. I would like to know > > > > whether these modems can be associated to their underlying bluetooth > > > > device (mac address, bluez device dbus path, or whatever). I have been > > > > looking on the available modem properties but this seems not to be > > > > present. Could somebody confirm this or otherwise explain how it can be > > > > done? > > > > > > > > The purpose of my interest is that, depending on the use-case, the final > > > > user would have to choose the modem (or device) manually. > > > > > > you would need to be a bit more specific on what the actual use case > > > entails here. How would selection work and how the user is involved in > > > it. Depending on that, things should be done differently. > > > > > > So besides that, some simple pieces that come to mind quickly are to > > > create a HFP devinfo atom driver that just exports the BD_ADDR as serial > > > number. > > > > Only the BD_ADDR is not enough, the device can paired with two or more > > adapters. Exports its DBUS path seems a best option. > > HFP plugin already keep the path for internal use, so its just a matter of put > > it devinfo. > > Also, the modem path gives you the information you need. The numbers there are > > the adapter bd_addr followed by the remove device bd_add. > > you can not get the BD_ADDR out of the device path. The device path is > arbitrary. And if anybody considers to misuse it, then I will add even > more random bits into it. Yes, but I am talking about the oFono modem path, you can extract the bd_addr from there and call BlueZ api to discover the remove device path. But add the device path to modem devinfo is a best option, I just wanted to mention that this extraction is possible.