Re: Underlying Bluetooth device of a modem

Re: Underlying Bluetooth device of a modem

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

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

Re: Underlying Bluetooth device of a modem

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2596 bytes --]

Hi Mikel,

On 08/10/2011 10:49 AM, Mikel Astiz wrote:
> 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.).
> 

Well only Bluetooth devices with HFP AG gateway service are created into
oFono modem objects, so I'm not sure what other kind of criteria you may
want here.  Likely they will have the same icon (e.g. phone) and the
same service (e.g. HFP AG).

If you are talking about being able to figure out whether an oFono modem
is an HFP_HF, DUN or a real modem, that is a slightly different topic.

Regards,
-Denis

Underlying Bluetooth device of a modem

[Mikel Astiz]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

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.

Regards,
Mikel Astiz

Re: Underlying Bluetooth device of a modem

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

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.

Regards

Marcel

Re: Underlying Bluetooth device of a modem

[Mikel Astiz]

[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]

Hi Marcel,

On 08/10/2011 03:39 PM, Marcel Holtmann wrote:
> 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.

Thanks for your quick answer.

Regarding the use case, the most obvious situation would be that the 
user would choose the device based on its Bluetooth alias, there could 
be other alternatives too. In any case, your answer seems to confirm 
that oFono currently does not expose this information, right?

Regarding your proposal of the devinfo driver, I will give it a try. I'm 
not actually familiar with the source code but that doesn't sound too 
difficult.

Another idea I was thinking about is to add a specific d-bus interface 
for these modems. Similar approaches could be followed by other modem 
types (if strictly necessary and modem-type specific). Would that make 
sense to you? I guess it's not desirable to have interfaces with one 
single method, but still it might be better than adding functionality to 
existing interfaces (for example by adding an optional property to 
org.ofono.Modem).

Best regards,

Mikel

Re: Underlying Bluetooth device of a modem

[Mikel Astiz]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

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.).

Regards,
Mikel

Re: Underlying Bluetooth device of a modem

[Gustavo Padovan]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

* Marcel Holtmann <marcel@holtmann.org> [2011-08-10 06:39:15 -0700]:

> 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.

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.

	Gustavo

Re: Underlying Bluetooth device of a modem

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

Hi Gustavo,

> > > 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.

Regards

Marcel

Re: Underlying Bluetooth device of a modem

[Mikel Astiz]

[-- Attachment #1: Type: text/plain, Size: 2785 bytes --]

Hi Gustavo and Marcel,

On 08/12/2011 12:39 AM, Marcel Holtmann wrote:
> Hi Gustavo,
>
>>>> 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.
>
> Regards
>
> Marcel
>
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono

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.

Regards,
Mikel

Re: Underlying Bluetooth device of a modem

[Gustavo Padovan]

[-- Attachment #1: Type: text/plain, Size: 2375 bytes --]

Hi Marcel,

* Marcel Holtmann <marcel@holtmann.org> [2011-08-11 15:39:40 -0700]:

> Hi Gustavo,
> 
> > > > 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.

	Gustavo

Re: Underlying Bluetooth device of a modem

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]

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.
> >> 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 have no interest in exposing a BlueZ D-Bus object path within oFono.
So this is not an option.

If you really end up with two Bluetooth adapters in your system and both
of them paired to the same headset, you will have first to solve the
user interaction within BlueZ, before you get to oFono. If you wanna
export the headset's BD_ADDR via oFono's serial number and maybe the
headset's name via model information, then that is fine, but do not try
to get smart by handing some constructed internal objects around. That
will end up in a big mess quickly.

Regards

Marcel

Re: Underlying Bluetooth device of a modem

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

Hi Gustavo,

> > > > > 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.

maybe I haven't made myself clear here. That is the kind of hacking in a
public API that we will not support. So this is not a solution. And once
you start thinking about it from a public API point of view, you will
realize this as well. It will just create a mess.

Regards

Marcel