Hello,
I want to catch the answer button signal of a bluetooth headset when
connected in HFP mode (HSP is trivial through the dbus-headset-signal
"AnswerRequested"). I don't want to use the computer as the "headset
part", but as the "audio gateway part". I have a small self-build app
that can handle VoIP-calls and Bluetooth-audio through bluez and
pulseaudio. Now I want the app to recognize the answer button being
pressed and then answer or hang up a call. I know that it has to be
done through a telephony-dummy because of the more complicated HFP
state machine. So I also digged into the source of the corresponding
.c files and searched the web. But I still have several questions left:
1. The bluez bindings for ofono and maemo seem to be just fulfilling
the "headset part", so when connecting a mobile phone to the computer
through Bluetooth. But I need the other direction. Is this possible
with ofono or maemo?
2. I found this patch on the web:
http://whitequark.livejournal.com/20590.html. It is already
integrated into bluez (since version 4.6x), so my problem seems to be
possible to solve with the telephony-dummy. But I tested it and when
the headset is in connected mode, I don't receive anything when
pressing the answer button. In playing mode I just received "AT+BLDN"
(last_dialed_number) and "AT+CHUP" (terminate_call). But according to
the patch I should receive "AT+BVRA" (voice_dial). Should the headset
be in some state (if yes, in which one and how do I trigger it)?
3. Should I be able to use the dbus-methods in the telephony-dummy to
simulate a "HFP state machine" and maybe be able to catch the answer
button then? But here only the "audio gateway role" on the remote
device (org.bluez.HeadsetGateway) is documented in the audio-api.txt,
not the other direction.
Thanks,
Peter Kornatowski