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. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
