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.
>
> 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. 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
> 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.
> 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 ;)
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.
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.
Regards,
-Denis
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
[email protected]
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
[email protected]
Hi Pali,
<snip>
>> 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.
Please think some more about what I said. You will need to parse every
AT command in your daemon, no way around that. You are right that you
do not need to keep track of the telephony state, but that is besides
the point. So if you need an AT parser anyway, the whole reasoning for
the proposed architecture starts to look shaky.
<snip>
>
>> - 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.
>
Again, you're not addressing my main point. Codec negotiation is part
of SLC establishment. SLC has both telephony and audio aspects.
They're inseparable. Your architecture fails to address this...
CSR codecs are not part of SLC and can be bolted on later. I already
told you that oFono can easily be changed to support this.
>> 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.
So again, no reason for us to get involved :)
Bottom line is there's no value for us in this architecture. If you
want to use the existing oFono APIs, that's fine. But we're not adding
a plugin for taking arbitrary AT commands from some other daemon :)
<snip>
>> 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).
Start a separate thread on ofono for this. I already gave you hints on
how to solve the 'AG without a real modem' use case. That would seem to
be the biggest 'win' and it should be fairly easy to make this work.
>
> 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.
>
HSP is a separate issue. Maybe we can handle it like the 'dundee'
daemon inside oFono (which handles Bluetooth DUN profile). In other
words have a dedicated daemon for hsp support that reuses the relevant
bits of oFono and maybe exposes the same APIs (i.e the ones documented
in doc/handsfree-audio-api.txt). That would make life for PulseAudio
pretty easy.
Regards,
-Denis
On Tuesday 07 January 2020 11:35:48 Denis Kenzior wrote:
> Hi Pali,
>
> <snip>
>
> > > 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.
>
> Please think some more about what I said. You will need to parse every AT
> command in your daemon, no way around that. You are right that you do not
> need to keep track of the telephony state, but that is besides the point.
> So if you need an AT parser anyway, the whole reasoning for the proposed
> architecture starts to look shaky.
I do not need to parse and interpret all AT commands. Telephony commands
does not have to parsed and interpreted. They can be forwarded to
telephony agent (if connected) OR replied with ERROR as a result that
command is not supported.
>
> >
> > > - 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.
> >
>
> Again, you're not addressing my main point. Codec negotiation is part of
> SLC establishment. SLC has both telephony and audio aspects. They're
> inseparable. Your architecture fails to address this...
Why? Codec negotiation is part of SLC, but codec can be changed prior
opening SCO connection.
How my architecture failed? What to address?
I implemented it in my prototype and it is working. So I do not
understand your point.
> CSR codecs are not part of SLC and can be bolted on later. I already told
> you that oFono can easily be changed to support this.
I'm not disagreeing with this.
> > > 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.
>
> So again, no reason for us to get involved :)
>
> Bottom line is there's no value for us in this architecture. If you want to
> use the existing oFono APIs, that's fine. But we're not adding a plugin for
> taking arbitrary AT commands from some other daemon :)
I can say exactly same. I'm not interested in any certification, I do
not see reason to care about it. Pulseaudio does not have any and is the
de-facto standard way how to use bluetooth audio on Linux.
> > > 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).
>
> Start a separate thread on ofono for this. I already gave you hints on how
> to solve the 'AG without a real modem' use case. That would seem to be the
> biggest 'win' and it should be fairly easy to make this work.
Ok, I will start a separate thread.
> >
> > 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.
> >
>
> HSP is a separate issue.
It is not separate issue. It is one of the main issues. If ofono is not
going to support HSP then there is absolutely no reason why to use ofono
and extend it to support a new features which currently do not support
(like CSR codecs which are in both HSP and HFP profiles). Basically
without it ofono is unusable for handling bluetooth audio on Linux
desktop.
> Maybe we can handle it like the 'dundee' daemon
> inside oFono (which handles Bluetooth DUN profile). In other words have a
> dedicated daemon for hsp support that reuses the relevant bits of oFono and
> maybe exposes the same APIs (i.e the ones documented in
> doc/handsfree-audio-api.txt). That would make life for PulseAudio pretty
> easy.
>
> Regards,
> -Denis
--
Pali Rohár
[email protected]