Re: Bluetooth HF role

[Mikel Astiz <mikel.astiz@bmw-carit.de>]

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

Hi Denis,

On 08/21/2011 04:13 AM, Denis Kenzior wrote:
> Hi Mikel,
>
> On 08/25/2011 07:32 AM, Mikel Astiz wrote:
>> Hi Denis,
>>
>> On 08/20/2011 11:00 AM, Denis Kenzior wrote:
>>> Hi Mikel,
>>>
>>> On 08/24/2011 10:28 AM, Mikel Astiz wrote:
>>>> Hi all,
>>>>
>>>> I'm trying to understand the features currently supported by oFono
>>>> regarding the handsfree role in Bluetooth/HFP. My first impression
>>>> looking at the source code is that some HFP functionality might be
>>>> missing, but I would rather have your confirmation.
>>>>
>>> Correct, in general only features that map 1:1 to existing APIs are
>>> exposed.  So that means network registration, voicecalls and call-volume
>>> interfaces.
>>>
>>>> Some examples I've found so far are the following:
>>>> 1. Response and hold (AT+BTRH=0)
>>>> 2. Redial last number (AT+BLDN)
>>>> 3. Retrieval of supported Bluetooth features for a certain modem/device
>>>> (AT+BRSF)
>>>>
>>> BRSF is supported and used internally, but the information is not
>>> exposed over D-Bus.
>>>
>>>> Could you clarify which (if any) of these features are currently
>>>> supported by oFono?
>>> Bluetooth specific features are not supported yet, these will require a
>>> separate atom. Roughly this means anything starting with +B.. including:
>>>      - +BINP
>>>      - +BLDN
>>>      - +BVRA
>>>      - +NREC
>>>      - +BSIR
>>>      - +BTRH
>>>
>>>> In general, is there any documented list of unsupported features?
>>>>
>>> In general the TODO list is your best source of readily available
>>> information.  In the case of HFP HF, there is no such documentation ;)
>>> Patches adding tasks to the TODO list to support these features are
>>> always welcome.
>>>
>>> Regards
>>> -Denis
>> OK, thanks for the information.
>>
>> Then I guess the next question is whether you have plans to support this
>> in the future, or if you would accept patches in this direction. I'm
>> afraid some of them could potentially affect the existing API.
>>
> Patches are always welcome.  I'm not sure why you want to change the
> existing API, sounds like most of these features belong to a new atom
> interface, however I could be wrong.  Go ahead and send your proposal so
> we have a starting point for the discussion.
>
> Regards,
> -Denis

Before discussing the source code itself, I would like to know your 
opinion about the different alternatives that come into my mind.

When you talk about a new atom interface, we could:

a. Create an HFP interface that includes all bluetooth-specific 
extensions. This could something like org.ofono.Handsfree or 
org.ofono.HfpModem.
b. Be more consistent with the existing oFono API and split the new 
extensions into several interfaces, such as org.ofono.hfp.Modem and 
org.ofono.hfp.VoiceCallManager (and whatever else is needed). This 
second interface would support methods such as Redial() and AnswerAndHold().
c. If this second approach of hfp.VoiceCallManager is followed, we could 
not only include the extensions there, but also replicate the whole API 
in org.ofono.VoiceCallManager. Personally I would rather not do this, 
but it seems to me that org.ofono.cdma.CdmaVoiceCallManager has been 
designed that way.

My vote would be in favor of the first option, for the sake of simplicity.

What do you think? Any other alternative?

Regards,
Mikel