[PATCH] Add voice call boolean property for MO/MT distinction

[PATCH] Add voice call boolean property for MO/MT distinction

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]

---
 doc/voicecall-api.txt |    5 +++++
 src/voicecall.c       |    6 +++++-
 2 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/doc/voicecall-api.txt b/doc/voicecall-api.txt
index f0ba316..f3cad7c 100644
--- a/doc/voicecall-api.txt
+++ b/doc/voicecall-api.txt
@@ -87,6 +87,11 @@ Properties	string LineIdentification [readonly]
 			"override category" option was not provisioned for
 			the current subscriber.
 
+		boolean Originated [readonly]
+
+			Indicates whether the call was mobile-originated
+			(true) or mobile-terminated (false).
+
 		boolean Multiparty [readonly]
 
 			Contains the indication if the voice call is part
diff --git a/src/voicecall.c b/src/voicecall.c
index 52baec3..045b492 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -322,7 +322,7 @@ static void append_voicecall_properties(struct voicecall *v,
 	const char *status;
 	const char *callerid;
 	const char *timestr;
-	ofono_bool_t mpty;
+	ofono_bool_t mpty, originated;
 
 	status = call_status_to_string(call->status);
 	callerid = phone_number_to_string(&call->phone_number);
@@ -342,6 +342,10 @@ static void append_voicecall_properties(struct voicecall *v,
 					&timestr);
 	}
 
+	originated = call->direction == CALL_DIRECTION_MOBILE_ORIGINATED;
+	ofono_dbus_dict_append(dict, "Originated", DBUS_TYPE_BOOLEAN,
+				&originated);
+
 	if (g_slist_find_custom(v->vc->multiparty_list,
 				GINT_TO_POINTER(call->id),
 				call_compare_by_id))
-- 
1.7.1

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

Hi Rémi,

> +		boolean Originated [readonly]
> +
> +			Indicates whether the call was mobile-originated
> +			(true) or mobile-terminated (false).
> +

What use case are you trying to enable with this API?  I don't see how
this could be useful for the UI...

Regards,
-Denis

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Wednesday 24 November 2010 23:31:43 ext Denis Kenzior, you wrote:
> Hi Rémi,
> 
> > +		boolean Originated [readonly]
> > +
> > +			Indicates whether the call was mobile-originated
> > +			(true) or mobile-terminated (false).
> > +
> 
> What use case are you trying to enable with this API?  I don't see how
> this could be useful for the UI...

This becomes a problem if we have more than one application "managing" voice 
calls. And I expect that will _be_ the most common case. You have the main 
call UI, but you also have the Bluetooth headset/carkit, the USB AT commands 
port, and possibly some third party call applications.

Generally speaking, I don't see the point in oFono hiding obvious stuff that it 
knows about.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Johan Hedberg]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

Hi,

On Thu, Nov 25, 2010, Rémi Denis-Courmont wrote:
> > > +		boolean Originated [readonly]
> > > +
> > > +			Indicates whether the call was mobile-originated
> > > +			(true) or mobile-terminated (false).
> > > +
> > 
> > What use case are you trying to enable with this API?  I don't see how
> > this could be useful for the UI...
> 
> This becomes a problem if we have more than one application "managing" voice 
> calls. And I expect that will _be_ the most common case. You have the main 
> call UI, but you also have the Bluetooth headset/carkit, the USB AT commands 
> port, and possibly some third party call applications.

Right. At least for HFP the call direction needs to be in the AT+CLCC
reply. I.e. if the bluetoothd ofono telephony driver is used and
bluetoothd starts after one or more calls are already in progress
bluetoothd wouldn't have seen the call setup process and therefore not
know the direction of the call (without this property).

Johan

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

Hi Johan,

On 11/25/2010 02:23 AM, Johan Hedberg wrote:
> Hi,
> 
> On Thu, Nov 25, 2010, Rémi Denis-Courmont wrote:
>>>> +		boolean Originated [readonly]
>>>> +
>>>> +			Indicates whether the call was mobile-originated
>>>> +			(true) or mobile-terminated (false).
>>>> +
>>>
>>> What use case are you trying to enable with this API?  I don't see how
>>> this could be useful for the UI...
>>
>> This becomes a problem if we have more than one application "managing" voice 
>> calls. And I expect that will _be_ the most common case. You have the main 
>> call UI, but you also have the Bluetooth headset/carkit, the USB AT commands 
>> port, and possibly some third party call applications.
> 
> Right. At least for HFP the call direction needs to be in the AT+CLCC
> reply. I.e. if the bluetoothd ofono telephony driver is used and
> bluetoothd starts after one or more calls are already in progress
> bluetoothd wouldn't have seen the call setup process and therefore not
> know the direction of the call (without this property).

I really don't view +CLCC emulation outside oFono as a valid use case.
We already have a task to implement HFP AG role inside oFono, and
especially with CDMA on the horizon this is the only way to go.

So unless there are more convincing arguments, I'm against this API
change.  I really suggest that instead of doing this outside oFono,
someone picks up the AT modem emulator work and continue where Zhenhua
left off.

Regards,
-Denis

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Johan Hedberg]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

Hi Denis,

On Thu, Nov 25, 2010, Denis Kenzior wrote:
> > Right. At least for HFP the call direction needs to be in the AT+CLCC
> > reply. I.e. if the bluetoothd ofono telephony driver is used and
> > bluetoothd starts after one or more calls are already in progress
> > bluetoothd wouldn't have seen the call setup process and therefore not
> > know the direction of the call (without this property).
> 
> I really don't view +CLCC emulation outside oFono as a valid use case.
> We already have a task to implement HFP AG role inside oFono, and
> especially with CDMA on the horizon this is the only way to go.
> 
> So unless there are more convincing arguments, I'm against this API
> change.  I really suggest that instead of doing this outside oFono,
> someone picks up the AT modem emulator work and continue where Zhenhua
> left off.

Picking up the AT modem emulator work is definitely something that
should happen. I also want to see that. However, wanting to accelarate
that work forward is imho the wrong reason reject this API. The BlueZ
ofono telephony driver is something that exists over a year now and
it'll continue to be partially broken wrt. +CLCC as long as there's a
requirement to "see" the call state changes in order to know the call
direction. Just yesterday we merged an optimization which initializes
the driver only when Bluetooth gets powered on and this further
increases the likelyhood of an ongoing call when the initialization
happens.

Another argument in favor of this API is that without it the D-Bus API
is in a way incomplete. You have a piece of state information that's
available by observing the state changes but not for a entity that jumps
into the game after the changes have happened. It's a bit like having an
API with a StateChanged signal but without a GetState method.

Johan

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 2273 bytes --]

On Thursday 25 November 2010 10:23:10 ext Johan Hedberg, you wrote:
> > This becomes a problem if we have more than one application "managing"
> > voice calls. And I expect that will _be_ the most common case. You have
> > the main call UI, but you also have the Bluetooth headset/carkit, the
> > USB AT commands port, and possibly some third party call applications.
> 
> Right. At least for HFP the call direction needs to be in the AT+CLCC
> reply. I.e. if the bluetoothd ofono telephony driver is used and
> bluetoothd starts after one or more calls are already in progress
> bluetoothd wouldn't have seen the call setup process and therefore not
> know the direction of the call (without this property).

Yeah. For USB CDC ACM gadget functionality, there is basically the same 
problem. Because oFono assumes it has full control over the modem, most 
cellular commands have to go through the oFono D-Bus API.

However, a number of other commands talk to completely different stuff, 
including but not limited to:
* AT+CBC et al deals with energy management, which is proprietary in Nokia's 
case and hence cannot be reached from GPL'd oFono.
* AT+CKPD, AT+CTSA and friends use either Linux uinput driver or perhaps to 
the windowing framework (X11, Wayland?).
* AT+CBKLT is hooked to the screensaver whatever takes care of it.
* AT+CPBR and friends is hooked to the phonebook, which is Qt-based, and 
therefore inadequate inside oFono.
* 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.

I would like to emphasize that, even if many of those commands are mostly if 
not only used in testing, they may still need to cooperate with oFono and/or 
to be present in the end-user devices. Besides, duplicating the implementation 
effort inside and outside oFono would be a waste of time.

All in all, implementing the AT commands DCE emulator inside oFono is not a 
realistic option. That is not to say that it must be closed-source, at least 
not most parts of it, but it's going to (have to) talk D-Bus to oFono.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 3414 bytes --]

Hi Remi,

> > > This becomes a problem if we have more than one application "managing"
> > > voice calls. And I expect that will _be_ the most common case. You have
> > > the main call UI, but you also have the Bluetooth headset/carkit, the
> > > USB AT commands port, and possibly some third party call applications.
> > 
> > Right. At least for HFP the call direction needs to be in the AT+CLCC
> > reply. I.e. if the bluetoothd ofono telephony driver is used and
> > bluetoothd starts after one or more calls are already in progress
> > bluetoothd wouldn't have seen the call setup process and therefore not
> > know the direction of the call (without this property).
> 
> Yeah. For USB CDC ACM gadget functionality, there is basically the same 
> problem. Because oFono assumes it has full control over the modem, most 
> cellular commands have to go through the oFono D-Bus API.
> 
> However, a number of other commands talk to completely different stuff, 
> including but not limited to:
> * AT+CBC et al deals with energy management, which is proprietary in Nokia's 
> case and hence cannot be reached from GPL'd oFono.

where is the problem here. An oFono plugin could just talk D-Bus to this
daemon.

> * AT+CKPD, AT+CTSA and friends use either Linux uinput driver or perhaps to 
> the windowing framework (X11, Wayland?).

This is not even a problem. Using uinput and this is solved. Wayland
talks kernel input only anyway and so can X11.

> * AT+CBKLT is hooked to the screensaver whatever takes care of it.

No matter what you do, this is a more complex problem. The screensaver
run as user session. You might just need to modify it to also listen on
the D-Bus system bus on a well defined service name and problem solved.

> * 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.

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 would like to emphasize that, even if many of those commands are mostly if 
> not only used in testing, they may still need to cooperate with oFono and/or 
> to be present in the end-user devices. Besides, duplicating the implementation 
> effort inside and outside oFono would be a waste of time.
> 
> All in all, implementing the AT commands DCE emulator inside oFono is not a 
> realistic option. That is not to say that it must be closed-source, at least 
> not most parts of it, but it's going to (have to) talk D-Bus to oFono.

I disagree here. The AT commands emulator belongs inside oFono.

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.

Regards

Marcel

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

Hi Marcel,

2010/11/29 Marcel Holtmann <marcel@holtmann.org>:
> Only because someone wants to shoehorn this into something nasty,
> doesn't mean we should do it.

I'd say it fits with oFono's overall strategy of following 27.007
whenever possible.

>And I am not going to scarifies the
> simplicity of the oFono D-Bus API for this.

Please. Have a look at the VoicecallManager API. Someone has
shoehorned all the nasty MMI-isms from 22.030 there. Surely we have to
have a separate ReleaseAndAnswer method, how else a dialer could
implement the intuitive "1" followed by SEND procedure?

-- 
Pekka.Pessi mail at nokia.com

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Remi.Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

----- 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

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

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

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Aki Niemi]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

Hi Marcel,

2010/11/30 Marcel Holtmann <marcel@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

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

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

Re: [PATCH] Add voice call boolean property for MO/MT distinction

[Remi.Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

----- Message d'origine -----
> do me a favor and try not to break the threading next time.

When I am away from my laptop, I use whatever MUA I can. This is obviously not deliberate a choice.

> I am getting a bit sick of this secrecy. oFono is for all intense and
> purposes open source.

And I am sick of arguing for something as simple and obvious as exposing the call direction in the calls list.

> So if you want a proper discussion here then
> please list the AT command in question.

Operator requirements are typically confidential. Since they are copyighted by their originator, not by me or my employer, I cannot fix that. Or rather, I can try (it is ongoing) but I cannot promise anything.

But this is only a side issue. We have a working AT commands DCE implementation that supports both cellular/oFono stuff and all the other that we need. Open-sourcing as much as we can is an ongoing process. I am not interested in rewriting that (and the BlueZ HFP code) into oFono just for the heck of it.

Furthermore providing some useful features (like call direction) only via a would-be oFono AT commands but not via the _preferred_ D-Bus interface seems silly and counter-productive to me.

-- 
Rémi