Bluetooth HF role
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.
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)
Could you clarify which (if any) of these features are currently supported by oFono?
In general, is there any documented list of unsupported features?
Regards,
Mikel
Hi Mikel,
Quoted 7 lines · Mikel Astiz
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.
Quoted 6 lines
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.
Quoted 2 lines
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
Quoted 3 lines
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
Hi Denis,
Quoted 36 lines · Denis Kenzior
Hi Mikel,
Quoted 7 lines · Mikel Astiz
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.
Quoted 6 lines
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.
Quoted 2 lines
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
- +BTRHQuoted 2 lines
In general, is there any documented list of unsupported features?
Quoted 7 lines
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.
Best regards,
Mikel
Hi Mikel,
Quoted 44 lines · Mikel Astiz
Hi Denis,
Quoted 41 lines · Denis Kenzior
Hi Mikel,
Quoted 7 lines · Mikel Astiz
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.
Quoted 6 lines
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.
Quoted 2 lines
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
- +BTRHQuoted 2 lines
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.
Quoted 9 lines
Quoted 2 lines
Regards
-DenisOK, 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
Hi Denis,
Quoted 55 lines · Denis Kenzior
Hi Mikel,
Quoted 44 lines · Mikel Astiz
Hi Denis,
Quoted 41 lines · Denis Kenzior
Hi Mikel,
Quoted 7 lines · Mikel Astiz
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.
Quoted 6 lines
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.
Quoted 2 lines
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
- +BTRHQuoted 2 lines
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.
Quoted 8 lines
Quoted 2 lines
Regards
-DenisOK, 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.
Quoted 7 lines
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
Hi Mikel,
Quoted 9 lines
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.
This is my preferred option.
Quoted 5 lines
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()andAnswerAndHold().
I don't think this is a good idea, you lose much of the flexibility for the applications; e.g. being able to implement the same API and work on real modems, hfp devices, sap devices, etc.
Having said that, the +BTRH is a bit special. I believe it is only supported on CDMA networks, while the HFP protocol is modeled after the GSM call model. We might have to look into implementing it on VoiceCallManager and tweak the GSM call state logic accordingly, which won't be fun ;) Any ideas are welcome here, I have no experience with Response and Hold or access to networks with it enabled.
Quoted 6 lines
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.
CDMA versions were designed this way because the CDMA call state machine is dirt simple. There didn't seem to be a need to make applications deal with the complexity of the GSM API while having a much simpler model underneath.
Quoted 3 lines
My vote would be in favor of the first option, for the sake of simplicity.
What do you think? Any other alternative?
Nope, your proposal is in line with my current thinking.
Regards,
-Denis
Hi,
Quoted 83 lines · Mikel Astiz
Hi Denis,
Quoted 55 lines · Denis Kenzior
Hi Mikel,
Quoted 44 lines · Mikel Astiz
Hi Denis,
Quoted 41 lines · Denis Kenzior
Hi Mikel,
Quoted 7 lines · Mikel Astiz
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.
Quoted 6 lines
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.
Quoted 2 lines
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
- +BTRHQuoted 2 lines
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.
Quoted 8 lines
Quoted 2 lines
Regards
-DenisOK, 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.
Quoted 7 lines
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,
-DenisBefore 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 asRedial()andAnswerAndHold(). 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.
Quoted 3 lines
My vote would be in favor of the first option, for the sake of simplicity.
What do you think? Any other alternative?
I forgot to add that another alternative would be to merge voice-call related extensions in the existing API. For example, by adding the method Redial() in org.ofono.VoiceCallManager, and extending the semantics of SwapCalls() to put incoming calls on hold.
Regards,
Mikel
Hi Mikel,
Quoted 10 lines · Mikel Astiz
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.
Some examples I've found so far are the following:
1. Response and hold (AT+BTRH=0)
2. Redial last number (AT+BLDN)
Yeah, these are missing.
Quoted 2 lines
3. Retrieval of supported Bluetooth features for a certain modem/device (AT+BRSF)
This is done by hfp_slc_establish() in hfp_hf.c plugin.
Quoted 5 lines
Could you clarify which (if any) of these features are currently supported by oFono?
In general, is there any documented list of unsupported features?
No, I think you need to confront the code against the spec.
Gustavo