On Friday 20 December 2019 23:46:57 Pali Rohár wrote:
> Hi!
> 
> On Friday 20 December 2019 15:19:01 Denis Kenzior wrote:
> > Hi Pali,
> > 
> > > > 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.
> 
> Some subset of AT commands are needed to parse and interpret. But not
> telephony commands and having up-to-date internal telephony state.
> 
> > > 
> > > 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 implement.
> > 
> > > 
> > > > 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"
> > > issues.
> > 
> > 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 examples:
> > 
> > - 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.
> 
> Yes, this would be needed, but because code os very similar it could be
> reused from one common place.
> 
> > 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?
> 
> Because pulseaudio has already own implementation of HSP profile and
> some kind of ofono implementation (which you named below "giant hack")
> it already needs to handle such problem.
> 
> But solution should be relatively simple. If we decide that new daemon
> is "new proper way" then it would have higher priority as current HFP
> API by ofono. So if hsphfpd is registered on dbus && hsphfpd say that it
> is active, then use hsphfpd. Otherwise if ofono is registered on dbus
> and say that device is active/connected use ofono.
> 
> > Supporting this new way buys us a lot of extra code /
> > complexity with no value added.
> 
> Value is support for HSP profile and support for HFP AG role without
> modem. And it would provide (for PA) unified same interface as for HFP
> HF role and HFP AG role with modem. I think this is a big value for PA
> (or bluez alsa or pipewire) to have one API which would handle all HSP
> and HFP profile/role combinations.
> 
> > - 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.
> 
> I know :-) I already implemented prototype implementation to check and
> see how complicated it is and if API make sense and how hard it is for
> agents (audio - pulseaudio) implement and maintain it.
> 
> > 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.
> 
> CSR codecs are not supported nor implemented in ofono. It is more
> complicated as HFP codecs... and needs a new API for audio application.
> Another value which brings my hsphfpd is that it handles these CSR
> codecs and provide API for audio application to use them.
> 
> > 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...
> 
> I was not thinking about certification. It is not something which I
> could do.... And also pulseaudio itself do not have certifications.
> 
> > > 
> > > 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
> > > selection)?
> > > 
> > 
> > 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.
> 
> Ok. I thought that phone simulator = ofono emulator. I just saw that
> phone simulator which is described in pulseaudio documentation.
> 
> > > 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...
> > > 
> > > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index5h2
> > > 
> > > ... 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 ;)
> 
> Ok, so we definitely agree that ofono currently do not support HFP AG
> without modem for desktop users. And this scenario is needed for
> connecting bluetooth headsets, so we need some solution for it.
> 
> > 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
> > your efforts.
> 
> Ok! So which options do we have?
> 
> > 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.
> 
> Well, if this would work automatically without any user interaction or
> without special setup, it seems to be usable.
> 
> But what is needed from this implementation in ofono? Basically API for
> each functionality designed in hsphfod daemon. And one of it is also
> support for HSP profile (with CSR and Apple extensions).
> 
> I'm not against for it, but I thought that having functionality which is
> not related to telephony / modem you would not want to see in ofono
> project (like linux uinput layer for button events or API for displaying
> raw text on embedded display; or CSR audio codec negotiation).
> 
> So how do you see possibility to have also HSP profile in ofono? So have
> one place which would provide audio API for SCO? Because this is a big
> requirements from audio software side, to not use 4 different APIs to
> access SCO sockets (and its rfcomm / SLC configuration) in HSP and HFP
> profiles.

Hi Denis! Can you look at this email? I would like to know what could be
next steps, specially if ofono (in some way) could be extended for all
use-cases and would be usable for Linux desktop. Or not and I rather
should continue with my hsphfpd proposal.

-- 
Pali Rohár
pali.rohar@gmail.com