7:20 p.m.
----- Message d'origine -----
> * AT+CPBR and friends is hooked to the phonebook, which is
Qt-based,
and
> therefore inadequate inside oFono.
I am not buying into the AT+CPBR for the local and user specific
phonebook. That one is inside Tracker anyway and also inside the user
session. Trying to really support this is a broken idea. CPBR can not
expose the information of modern contacts storage anyway, so just don't
bother.
I can see how AT+CPBW could be problematic, more so than AT+CPBR. But that is not
relevant. If a big enough customer wants it badly enough, it has to be done. I do not want
to end up with an architecture that forbids satisfying some of my employer's potential
major customers.
If you really care about it then use Bluetooth PBAP via obexd which
we
have enabled already.
> * At Nokia, we also have some non-standard commands for internal
use.
> * Some operators require some funky AT commands of their own. It might
not be
> possible to open-source them, even if we want to.
And these should be on an engineering mode only USB CDC ACM interface
with a different backend anyway.
I already mentioned that the same software must run in certification and in user's
hands for "whole device" certification to be valid. But anyway, some of those
commands were requested as DUN extensions, not as testing stuff. So no no no.
Only because someone wants to shoehorn this into something nasty,
doesn't mean we should do it. And I am not going to scarifies the
simplicity of the oFono D-Bus API for this.
We are talking about the Originated boolean call property?!
--
Rémi
9:58 p.m.
New subject: [PATCH] Add voice call boolean property for MO/MT distinction
Hi Remi,
do me a favor and try not to break the threading next time.
> > * At Nokia, we also have some non-standard commands for
internal use.
> > * Some operators require some funky AT commands of their own. It might
> not be
> > possible to open-source them, even if we want to.
>
> And these should be on an engineering mode only USB CDC ACM interface
> with a different backend anyway.
I already mentioned that the same software must run in certification and in user's
hands for "whole device" certification to be valid. But anyway, some of those
commands were requested as DUN extensions, not as testing stuff. So no no no.
I am getting a bit sick of this secrecy. oFono is for all intense and
purposes open source. So if you want a proper discussion here then
please list the AT command in question.
Since you are clearly working on this right now, please compile a list
of required AT commands and share it. A good place to list the required
commands for "whole device" certification would be the doc/ directory.
Regards
Marcel
10:24 p.m.
New subject: [PATCH] Add voice call boolean property for MO/MT distinction
Hi Marcel,
2010/11/30 Marcel Holtmann <marcel(a)holtmann.org>:
I am getting a bit sick of this secrecy. oFono is for all intense
and
purposes open source. So if you want a proper discussion here then
please list the AT command in question.
So this patch seems to be to enable reporting call direction as part
of reporting call status using AT+CLCC. It is needed by HFP as well
as a conformance suite for USB ACM that Rémi is working on.
In addition, I think it is good API design to provide call direction
as a property via a GetProperties() call, as it is already available
by witnessing call progress in the State property. A user restarting
in the middle of an ongoing call will otherwise miss this state
information.
So technically, this patch should go in, especially given it is a
property without which these two users of oFono won't work properly.
Cheers,
Aki
10:39 p.m.
New subject: [PATCH] Add voice call boolean property for MO/MT distinction
Hi Aki,
> I am getting a bit sick of this secrecy. oFono is for all
intense and
> purposes open source. So if you want a proper discussion here then
> please list the AT command in question.
So this patch seems to be to enable reporting call direction as part
of reporting call status using AT+CLCC. It is needed by HFP as well
as a conformance suite for USB ACM that Rémi is working on.
as I said before, someone has to do the due diligence and start listing
all required AT commands for conformance testing. I want to see the full
picture and not some random patches here and there.
I am still not convinced that these details should be exposed via D-Bus
APIs at all. Using the internal AT emulator would be a way better fit.
So can you guys come up with a detailed list of AT commands for this? I
want to have this documented. Then we can have a proper discussion since
this is not getting anywhere.
Regards
Marcel
4310
days inactive
4310
days old
3 comments
3 participants
participants (3)
-
Aki Niemi -
Marcel Holtmann -
Remi.Denis-Courmont＠nokia.com