>> There have been one or two implementations of AG role fully external to
>> oFono. These implementations simply used the existing oFono APIs to drive
>> the modem.
> bluez & pulseaudio developers told me that it would be a good idea to
> avoid implementing a new AT parser for telephony stack. And rather use
> ofono implementation for telephony part...
In my opinion there's nothing scary about AT parsing. In fact that is
the easiest part of this whole venture. If you don't want to roll your
own parser, you can borrow one from the oFono project. We already
solved this nicely in the form of the gatchat library. You could
incorporate this into your project (if it is GPL compatible). Or you
could wait until we port gatchat to ell which will be under LGPL license.
> But if I should use existing DBus API provided by ofono, it means that I
> need to do parsing of all AT commands (including telephony) and
> translate them to ofono DBus API.
I think you will need to do this regardless. Otherwise I fail to see
how you prevent one 'agent' from consuming AT commands it shouldn't be.
This is a possibility you need to consider, whether it happens by
accident or maliciously.
> I agree, this should work and there is not need to modify ofono. But it
> means that in hsphfpd daemon I need to have full AT parser for all
> telephony commands and it was something which bluez / pa developers
> thought that should be avoided. Therefore I come up with idea that
> telephony commands would be handled by external Telephony Agent, which
> can be ofono.
Understood. But I think the metric function was selected
inappropriately in this case. My opinion is that you should have
started with what the overall architecture should look like; you should
not have based design decisions on which parts might be a little hard to
>> You could do that. But as I said, we rejected such a design a
>> long time ago due to complexity and other issues.
> Anyway, what is the problem with accepting modem socket in ofono via
> DBus and starts talking with it like with any other modem which ofono
> supports? Currently ofono already takes modem socket from bluez via DBus
> API, so in same way hsphfpd can pass modem socket to ofono. Basically
> ofono then can reuse same code which already uses for sockets from
> bluez, just it do not have to parse and interpret audio related AT
> commands (as these are handled by hsphpfd itself).
> What are exact issues? I do not see complexity at ofono part (as has
> already everything implemented) and currently I do not see those "other"
The issues are many. And really the question is not whether it 'could
be' done, but whether it 'should be' done. Let me describe a couple
- In the case of HF role (1), oFono already provides all the necessary
APIs. So put yourself in oFono's maintainer shoes. What would we gain
by supporting almost the same but different mechanism? We would have to
introduce a new hfp_hf plugin, one that is almost identical, but
different to hfp_hf_bluez5 plugin. These two plugins would have
coexistence issues, which would add more complexity. Then there's the
impact on PulseAudio and other users. How do they know when to use the
HandsfreeAudio API vs some external API? Supporting this new way buys
us a lot of extra code / complexity with no value added.
- The other example is more practical. HFP Service Level Connection
(SLC) establishment is actually quite tricky. There are certain
limitations on what can and cannot be done prior to SLC establishment,
including how audio handling is done. Unfortunately, codec negotiation,
indicator negotiation, and feature negotiation are part of the SLC.
oFono already solves all of this and handles all of it nicely. We have
passed all relevant certification testing. It is very unclear how you
plan to handle this (or whether you realistically even can) in your
architecture when the responsibilities are split between the various
daemons. So again, oFono has nothing to gain here...
> You suggested to use phone simulator together with ofono and then
> starts extending / patching phone simulator to supports all needed parts
> which are in my hsphfpd design (battery status, button press, codec
Not quite. I suggested you expand oFono's emulator implementation (for
AG role) and its DBus APIs (for HF role) to support the new vendor
specific features that you want.
Forget about the phone simulator, it is really irrelevant for what
you're trying to accomplish.
> Also how to handle the main problem of phone simulator that it is too
> much complicated to setup it on desktop? Looking at the steps...
> ... that desktop user needs to run nontrivial commands in command like,
> plus creating configuration file only just to connect bluetooth headset
> is ridiculous and non-acceptable for desktop application.
> If this problem is not fixed, ofono and phone simulator are not usable
> as "main" software implementation of HFP profile for usage of bluetooth
> headsets on Linux.
oFono was never advertised as solving the 'HFP AG without a modem' use
case. This is something we never had as a requirement / objective.
Phonesim is a development tool. So of course it isn't trivial to setup,
it isn't meant to be used in production in the first place. The use of
phonesim described in the PA wiki, while creative, is a giant hack ;)
Basically it all boils down to the fact that nobody has stepped up all
this time to solve a particular use case you care about. But blaming
oFono for this is misguided.
So, if you want to solve the HFP AG without a modem case I fully support
Perhaps this can even be solved in oFono itself (since it already does
90% of what you want) by making the modem requirement optional. What we
could do for example is to create a dummy modem if an AG connection is
requested and no other suitable modems are detected in the system. The
resultant AG wouldn't have any call control capability, it could still
be used for transferring audio data, battery, etc. If you want to
pursue this, we can brainstorm further.
On XMM modems SIM is busy after PUK is entered. CME ERROR: 14
is received for AT+CPIN? query. Therefore polling for CPIN: READY
drivers/atmodem/sim.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c
index e750a13..3ed5aa0 100644
@@ -1354,13 +1354,14 @@ static void at_pin_send_cb(gboolean ok, GAtResult *result,
+ case OFONO_VENDOR_XMM:
* On ZTE modems, after pin is entered, SIM state is checked
* by polling CPIN as their modem doesn't provide unsolicited
* notification of SIM readiness.
- * On SIMCOM modems, SIM is busy after pin is entered (we
- * got a "+CME ERROR: 14" for the "AT+CPIN?" request) and
+ * On SIMCOM and XMM modems, SIM is busy after pin is entered
+ * (we got a "+CME ERROR: 14" for the "AT+CPIN?" request) and
* ofono don't catch the "+CPIN: READY" message sent by the
* modem when SIM is ready. So, use extra CPIN to check the
>>> But would you accept patches which exports DBus API e.g. for displaying text
>>> on HFP headset with embedded display? Or patches which implements 3
>>> different way for reporting battery level status of HFP headset? And API
>>> for sending "computer battery level" to HFP headset? Or implementing
>>> setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
>>> uinput linux device for button press events? Because all these
>> So which roles are we talking about here? Your Design document shows
>> hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was not
>> the intent?
> My proposed hsphfpd is going to support both roles. Which means to
> implement whole HFP profile. So for connecting bluetooth headsets (when
> AG role is needed on desktop) and also for connecting mobile phones
> (when HF role is needed on desktop).
> And my primary motivation is for bluetooth headsets as this is what are
> asking desktop and laptop users again and again that is missing on Linux
> So higher priority has AG role and slightly lower priority has HF role.
So to summarize. You have broadly 3 main use cases for HFP:
1. HF connecting to AG role. Essentially a carkit role. oFono does
this pretty well already and has the APIs defined that cover up to HFP
1.7. Any vendor extensions can be easily added. And some carkit
manufacturers already use it.
2. AG role when you have a 'real modem' behind it. oFono already
provides everything needed for this scenario.
3. AG role when you don't have a real modem or you have some sort of
VoIP use case. oFono doesn't cover this case as you stated.
So I can see value in something that implements case #3. But having
said that, oFono will not be receiving AT commands from external daemons:
- For case 1, it'd just be a rehash of what oFono does well already. I
reinvented a few wheels in my time, but doesn't mean I think this one
- The reasoning for case 2/3 I already covered upthread.
>> If you're talking about extending oFono APIs when it is acting as the HF
>> connecting to the AG, then codec setup APIs, etc are definitely something
>> that would be welcome.
>> If you're talking about AG role, then that is different... In general, if
>> the oFono is in an AG role, then there should be nothing to configure and
>> there are no APIs for this role.
> Codecs needs to be configured also in AG role. Before accepting SCO
> connection you need to configure SCO socket for correct codec. Also for
> vendor codecs it needs to be properly negotiated via AT commands.
Sure, but that doesn't mean they need an actual D-Bus API to be
configured with. You can simply extend oFono emulator to support
whatever codecs you want and whatever custom AT command handling that
you need. If the HF requests the codec, then you use it. There's no
D-Bus API required here. Again, take a look at how this is done in
>> Such a design will get a NAK from me on the oFono side. But don't let that
>> stop you. You can simply invoke oFono APIs directly from your daemon. No
>> need for any changes in oFono itself. As mentioned above, I wouldn't
>> recommend it, but... :)
> So if you are disagreeing with this design, can you propose alternative?
> Which would support needs for desktop users? Support for HSP profile (in
> AG role), support for HFP profile (in AG role), ability to parse and
> interpret needed AT commands. And later also HS and HF role of these
There have been one or two implementations of AG role fully external to
oFono. These implementations simply used the existing oFono APIs to
drive the modem. You could do that. But as I said, we rejected such a
design a long time ago due to complexity and other issues.
Or you can ignore the call control aspects entirely...
But in the end, it is your architecture. All I can do is point out
(early in the process) what is and what is not acceptable to oFono upstream.
>> Okay, I see now. Yes, the above is correct. My comments about not needing
>> a modem device hold true only if oFono is in HFP HF role connecting to an
> Ok. So I guess now you understood main problem. I thought it was
> obvious, but seems that bluetooth HFP is too complicated, so talking
> about it always needs more detailed explanation. Sorry for that if it
> was not clear from my side since beginning what are requirements for my
Well it was a bit of reading comprehension fail on my part as well. The
two roles are really quite different, so precise language helps.
> Yes, I see. Also there are devices without HFP support, only with HSP.
> pulseaudio support also these devices and pulseaudio is not going to
> drop support for them. Last time when I looked at ofono, it has no HSP
> support. Is ofono going to add support for HSP?
> But would you accept patches which exports DBus API e.g. for displaying text
> on HFP headset with embedded display? Or patches which implements 3
> different way for reporting battery level status of HFP headset? And API
> for sending "computer battery level" to HFP headset? Or implementing
> setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
> uinput linux device for button press events? Because all these
So which roles are we talking about here? Your Design document shows
hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was
not the intent?
If you're talking about extending oFono APIs when it is acting as the HF
connecting to the AG, then codec setup APIs, etc are definitely
something that would be welcome.
If you're talking about AG role, then that is different... In general,
if the oFono is in an AG role, then there should be nothing to configure
and there are no APIs for this role. Things like reporting AG battery
level to HFP headset are done directly using plugins. See
ofono_emulator_set_indicator and how this is done by upower.c for
example. I happily take patches for any additional features (codecs,
etc) you want to support here.
But... oFono upstream has no interest in accepting forwarded AT commands
from some external daemon if we're in AG role. We rejected such a
design years ago and nothing has changed.
AG role is already quite tricky to implement without additional
complexity introduced by having multiple applications and IPC. "Its
your funeral" as the saying goes if you want to go that route.
> I disagree here. Primary purpose of HFP for desktop users is ability to
> use bluetooth's microphone. And not telephony stack and its complicated
> features like call hold and others, which are in HFP used and
> implemented probably only in car kits.
So your primary goal here is to have the desktop play the role of the
AG, purely so you can forward the audio from a headset out to whatever
it is that you want. And you want oFono (or some other daemon) to
(optionally) handle the call related AT commands in the HFP AG role.
Such a design will get a NAK from me on the oFono side. But don't let
that stop you. You can simply invoke oFono APIs directly from your
daemon. No need for any changes in oFono itself. As mentioned above, I
wouldn't recommend it, but... :)
>>>> Also for using ofono with HFP profile is not possible on desktop
>>>> computer which do not have any modem as it is hooked to some active
>> This statement is not true at all. You can use oFono without any 'real'
>> modems attached. It can happily manage only HFP devices (or modems as we
>> call them.)
> Ok, can you please provide exact steps how to do it, including
> activating of bidirectional audio stream?
So again, which role? If we're the HF connecting to the AG, then things
just work without a modem. If we're the AG, then yes you need a modem
to be driven by the AG connection.
>> You must be thinking of the oFono HFP AG implementation...
> Yes! For connecting bluetooth headset you need HFP AG implementation.
> And I guess this is the reason why simulator is needed. HFP headset acts
> as a "client" for modem. Therefore on desktop / laptop you need to
> implement "modem server" which will be used by HFP headset "client".
> And phone simulator is doing exactly this "modem server", it is
> simulator of modem.
Okay, I see now. Yes, the above is correct. My comments about not
needing a modem device hold true only if oFono is in HFP HF role
connecting to an AG.