Call Counters (2nd)
cover Call Counters (2nd)
Here a proposal for call counters implementation for keeping track of the total incoming and outgoing call duration counters. Each established call instance is contributing to either of the call duration counters. The 2 counters are updated periodically when there is an established call and the information is stored in a file. The bookkeeping of the call duration counters are per IMSI number.
The implementation makes use of the history framework which had to be expanded with a function for marking the beginning of a voice call. There is a D-Bus interface to call counters for reading and clearing the counters.
Andras Domokos (5):
history: expand history API include file
history: expand history API
voicecall: take into use the new history function
plugins: add call counters
doc: call counters API doc
Makefile.am | 3 + doc/callcounters-api.txt | 18 ++ include/history.h | 3 + plugins/callcounters.c | 388 ++++++++++++++++++++++++++++++++++++++++++++++ src/history.c | 24 +++ src/ofono.h | 4 + src/voicecall.c | 3 + 7 files changed, 443 insertions(+), 0 deletions(-) create mode 100644 doc/callcounters-api.txt create mode 100644 plugins/callcounters.c
RFC PATCH 1/5 history: expand history API include file
--- include/history.h | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
include/history.h +3 -0
@@ -49,6 +49,9 @@ struct ofono_history_driver {const char *name;int (*probe)(struct ofono_history_context *context);void (*remove)(struct ofono_history_context *context); +void (*call_started)(struct ofono_history_context *context, +const struct ofono_call *call, +time_t start);void (*call_ended)(struct ofono_history_context *context,const struct ofono_call *call,time_t start,time_t end);
Signature · 1 line
1.7.0.4
RFC PATCH 2/5 history: expand history API
In reply to Andras Domokos--- src/history.c | 24 ++++++++++++++++++++++++ src/ofono.h | 4 ++++ 2 files changed, 28 insertions(+), 0 deletions(-)
src/history.c +24 -0
@@ -114,6 +114,30 @@ void __ofono_history_probe_drivers(struct ofono_modem *modem) } } +static void history_call_started (struct ofono_atom *atom,void *data) +{ +struct ofono_history_context *context =__ofono_atom_get_data (atom); +struct history_call_foreach_data *hfd = data; + +if (context->driver->call_started ==NULL ) +return ; + + context->driver->call_started (context, hfd->call, hfd->start); +} + +void __ofono_history_call_started (struct ofono_modem *modem, +const struct ofono_call *call, +time_t start) +{ +struct history_call_foreach_data hfd; + + hfd.call = call; + hfd.start = start; + +__ofono_modem_foreach_atom (modem,OFONO_ATOM_TYPE_HISTORY , + history_call_started, &hfd); +} +static void history_call_ended (struct ofono_atom *atom,void *data) {struct ofono_history_context *context =__ofono_atom_get_data (atom);
src/ofono.h +4 -0
@@ -368,6 +368,10 @@ void __ofono_netreg_set_base_station_name(struct ofono_netreg *netreg,void __ofono_history_probe_drivers (struct ofono_modem *modem); +void __ofono_history_call_started (struct ofono_modem *modem, +const struct ofono_call *call, +time_t start); +void __ofono_history_call_ended (struct ofono_modem *modem,const struct ofono_call *call,time_t start,time_t end);
Signature · 1 line
1.7.0.4
RFC PATCH 3/5 voicecall: take into use the new history function
In reply to Andras Domokos--- src/voicecall.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
src/voicecall.c +3 -0
@@ -630,6 +630,7 @@ static void voicecall_emit_multiparty(struct voicecall *call, gboolean mpty)static void voicecall_set_call_status (struct voicecall *call,int status) { +struct ofono_modem *modem =__ofono_atom_get_modem (call->vc->atom);DBusConnection *conn =ofono_dbus_get_connection ();const char *path;const char *status_str;
@@ -658,6 +659,8 @@ static void voicecall_set_call_status(struct voicecall *call, int status)const char *timestr; call->start_time =time (NULL ); +__ofono_history_call_started (modem, call->call, + call->start_time); timestr =time_to_str (&call->start_time); ofono_dbus_signal_property_changed(conn, path,
Signature · 1 line
1.7.0.4
RFC PATCH 4/5 plugins: add call counters
In reply to Andras Domokos--- Makefile.am | 3 + plugins/callcounters.c | 388 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 391 insertions(+), 0 deletions(-) create mode 100644 plugins/callcounters.c
Makefile.am +3 -0
@@ -295,6 +295,9 @@ builtin_modules += example_nettime builtin_sources += examples/nettime.c endif +builtin_modules += cc +builtin_sources += plugins/callcounters.c + builtin_modules += smart_messaging builtin_sources += plugins/smart-messaging.c
plugins/callcounters.c new file +388 -0
388 lines not on this page · raw message
Signature · 1 line
1.7.0.4
RFC PATCH 5/5 doc: call counters API doc
In reply to Andras Domokos--- doc/callcounters-api.txt | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) create mode 100644 doc/callcounters-api.txt
doc/callcounters-api.txt new file +18 -0
@@ -0,0 +1,18 @@ +CallCounters hierarchy +====================== + +Service org.ofono +Interface org.ofono.CallCounters +Object path [variable prefix]/{modem0,modem1,...} + +Methods dict Get() + + Returns the total duration in seconds of the incoming + and outgoing calls. Separate counters are maintained for + each SIM card. + + void Clear() + Resets the call duration counters to 0. The operation + succeeds only if there are no ongoing calls. + + Possible Errors: [service].Error.Failed
Signature · 1 line
1.7.0.4
Hi Andras,
2010/11/22 Andras Domokos <[email protected]>:
Quoted 11 lines
Here a proposal for call counters implementation for keeping track of the total incoming and outgoing call duration counters. Each established call instance is contributing to either of the call duration counters. The 2 counters are updated periodically when there is an established call and the information is stored in a file. The bookkeeping of the call duration counters are per IMSI number.
The implementation makes use of the history framework which had to be expanded with a function for marking the beginning of a voice call. There is a D-Bus interface to call counters for reading and clearing the counters.
This set looks good to me, and I believe you fixed the issues from previous review comments. Denis, are you ok with this?
Cheers,
Aki
Hi Aki,
Quoted 15 lines · Aki Niemi
Hi Andras,
2010/11/22 Andras Domokos <[email protected]>:
Quoted 11 lines
Here a proposal for call counters implementation for keeping track of the total incoming and outgoing call duration counters. Each established call instance is contributing to either of the call duration counters. The 2 counters are updated periodically when there is an established call and the information is stored in a file. The bookkeeping of the call duration counters are per IMSI number.
The implementation makes use of the history framework which had to be expanded with a function for marking the beginning of a voice call. There is a D-Bus interface to call counters for reading and clearing the counters.
Quoted 3 lines
This set looks good to me, and I believe you fixed the issues from previous review comments. Denis, are you ok with this?
I'm still catching up, let me take another look.
Regards,
-Denis
Hi Aki,
Quoted 12 lines
Quoted 11 lines
Here a proposal for call counters implementation for keeping track of the total incoming and outgoing call duration counters. Each established call instance is contributing to either of the call duration counters. The 2 counters are updated periodically when there is an established call and the information is stored in a file. The bookkeeping of the call duration counters are per IMSI number.
The implementation makes use of the history framework which had to be expanded with a function for marking the beginning of a voice call. There is a D-Bus interface to call counters for reading and clearing the counters.
Quoted 2 lines
This set looks good to me, and I believe you fixed the issues from previous review comments. Denis, are you ok with this?
so Denis and I talked about this a little bit and I am not fine with this at all.
Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API.
My main concerns are here that we are waking up ofonod every 10 seconds and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API.
What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here.
In addition to that, what is the problem with just updating the stats after the call has ended?
Are you really expecting realtime updates of call time stats for some hidden UI stats menu? This would be a really expensive change for just doing that.
Has anybody looked at how we are doing realtime stats inside ConnMan?
Regards
Marcel
Hi Marcel,
2010/12/8 Marcel Holtmann <[email protected]>:
Quoted 2 lines
so Denis and I talked about this a little bit and I am not fine with this at all.
Next time, can you invite me to join your little talk?
Quoted 3 lines
Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API.
We need a UI showing total MO and MT call times. They also need to be able to be reset, if the user so wishes. The data needs to be reasonably reliable.
Quoted 2 lines
and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API.
What do you mean? Do you mean your iPhone has no such UI?
The reason these are not properties is just because it makes no sense to update the counters "live". The UI can poll if it so wishes, but the poll interval is not something we want to decide.
Quoted 5 lines
What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here.
In addition to that, what is the problem with just updating the stats after the call has ended?
Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear.
Andras has some data on what reasonable reliability here means.
Cheers,
Aki
Hi Aki,
Quoted 4 lines
Quoted 2 lines
so Denis and I talked about this a little bit and I am not fine with this at all.
Next time, can you invite me to join your little talk?
because you are not sitting next to me right now ;)
Quoted 7 lines
Quoted 3 lines
Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API.
We need a UI showing total MO and MT call times. They also need to be able to be reset, if the user so wishes. The data needs to be reasonably reliable.
Fair enough, but when I look at such a feature as a whole, then my question is when does it need to be shown? What is your user interaction requirement with this data?
Andras, please explain what reasonable reliable means.
Quoted 4 lines
Quoted 2 lines
and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API.
What do you mean? Do you mean your iPhone has no such UI?
I have actually tested this with an iPhone and it has such an UI element, but it is not realtime. It gets updated after the call has been completed.
So why can't we just update/reset this in Tracker via the history plugin in a general way. I am failing to see the need for this inside oFono. It seems to me that doing this within the scope of the Tracker integration is a lot cleaner and better for CPU and IO usage.
Quoted 7 lines
The reason these are not properties is just because it makes no sense to update the counters "live". The UI can poll if it so wishes, but the poll interval is not something we want to decide.
Quoted 3 lines
What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here.
Quoted 7 lines
Quoted 2 lines
In addition to that, what is the problem with just updating the stats after the call has ended?
Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear.
I think this is not a good idea to have oFono handles this. Why can't the system daemon just shutdown all calls when the battery reaches critical limit.
You will never fully run down the battery anyway. One of the system health components in the system will prevent it and then can cleanly shutdown oFono and thus all calls. The only case where the system could potentially misfunction in this area would be an emergency call. But that is a total different use case anyway.
Regards
Marcel
Hi,
Quoted 10 lines
Quoted 1 line
Because if your battery runs out in the middle of a 4 hour
conference
Quoted 3 lines
call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear.
I think this is not a good idea to have oFono handles this. Why can't the system daemon just shutdown all calls when the battery reaches critical limit.
Quoted 6 lines
You will never fully run down the battery anyway. One of the system health components in the system will prevent it and then can cleanly shutdown oFono and thus all calls. The only case where the system could
potentially misfunction in this area would be an emergency call. But that is a total different use case anyway.
There are other ways in which the device might reset without warning:
- hardware glitch triggering an involuntary reset
- software glitch triggering an involuntary reset
- device drops and battery connection is momentarily broken when it hits the ground
- user rips out the battery in mid-use
While periodically syncing call and data counters to permanent memory is by no means appealing, we have certain accuracy requirements for the stored counters. The only way those requirements can be met is by syncing the counters to storage at reasonable intervals. Whether this should be part of oFono is a matter for discussion, I guess, but at minimum we need to have the enablers to do this.
MikaL
Hi,
Quoted 19 lines · ext Marcel Holtmann
Hi Aki,
Quoted 5 lines
Quoted 3 lines
so Denis and I talked about this a little bit and I am not fine with this at all.
Next time, can you invite me to join your little talk?
because you are not sitting next to me right now ;)
Quoted 8 lines
Quoted 4 lines
Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API.
We need a UI showing total MO and MT call times. They also need to be able to be reset, if the user so wishes. The data needs to be reasonably reliable.
Quoted 7 lines
Fair enough, but when I look at such a feature as a whole, then my question is when does it need to be shown? What is your user interaction requirement with this data?
Andras, please explain what reasonable reliable means.
The call counters are shown to the user when he or she opens up an application/applet whatever UI component that is meant for showing this information.
Coming to the reliability part, saving the call counters information often enough, gives us sort of hard guarantee that whatever happens with any subsystem, be that SW or HW, the call counters will stay enough accurate. Syncing to the permanent storage, based on our product requirements, should take place in fact every 5 sec, or could be configurable.
There might be some liability issues if for some reason the counters would "loose" time, the user my blame the phone manufacturer for the extra expenses incurred by inaccurate counters.
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API.
What do you mean? Do you mean your iPhone has no such UI?
Quoted 9 lines
I have actually tested this with an iPhone and it has such an UI element, but it is not realtime. It gets updated after the call has been completed.
So why can't we just update/reset this in Tracker via the history plugin in a general way. I am failing to see the need for this inside oFono. It seems to me that doing this within the scope of the Tracker integration is a lot cleaner and better for CPU and IO usage.
We can discuss the place of the call counters plugin, but I think using the ofono history framework is a reasonable choice, with the note that the it needs to be expanded with a history function called in the beginning of a call.
The call counters plugin could be an optionally compiled/included (dynamic) plugin or "downgraded" to experimental status.
Quoted 21 lines
Quoted 9 lines
The reason these are not properties is just because it makes no sense to update the counters "live". The UI can poll if it so wishes, but the poll interval is not something we want to decide.
Quoted 3 lines
What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here.
Quoted 8 lines
Quoted 3 lines
In addition to that, what is the problem with just updating the stats after the call has ended?
Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear.
I think this is not a good idea to have oFono handles this. Why can't the system daemon just shutdown all calls when the battery reaches critical limit.
Quoted 6 lines
You will never fully run down the battery anyway. One of the system health components in the system will prevent it and then can cleanly shutdown oFono and thus all calls. The only case where the system could potentially misfunction in this area would be an emergency call. But that is a total different use case anyway.
It was already pointed out by Mika Liljeberg there could be cases when we might not get the chance to sync our data. We need to be prepared to cope with such cases as well (syncing the data often "enough").
Quoted 10 lines
Regards
Marcel
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
Regards,
Andras
Hi Andras,
Quoted 12 lines
Quoted 12 lines
Quoted 8 lines
Quoted 4 lines
Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API.
We need a UI showing total MO and MT call times. They also need to be able to be reset, if the user so wishes. The data needs to be reasonably reliable.
Fair enough, but when I look at such a feature as a whole, then my question is when does it need to be shown? What is your user interaction requirement with this data?
Quoted 6 lines
Quoted 3 lines
Andras, please explain what reasonable reliable means.
The call counters are shown to the user when he or she opens up an application/applet whatever UI component that is meant for showing this information.
do we have a clear use case requirement from an UI point of view on how this is expected to be working.
I checked with my iPhone and how it does it. Basically it just updates after the call and only after you re-entered that menu.
So here again, do we have a requirement to make this realtime or not. And I mean that from an user interaction point of view.
Quoted 6 lines
Coming to the reliability part, saving the call counters information often enough, gives us sort of hard guarantee that whatever happens with any subsystem, be that SW or HW, the call counters will stay enough accurate. Syncing to the permanent storage, based on our product requirements, should take place in fact every 5 sec, or could be configurable.
Writing and syncing something to disk every 5 seconds costs us IO. Is this really a sacrifice that is acceptable.
Quoted 3 lines
There might be some liability issues if for some reason the counters would "loose" time, the user my blame the phone manufacturer for the extra expenses incurred by inaccurate counters.
To be honest the counters can not be considered accurate anyway. Only the billing system has the final say.
Quoted 14 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API.
What do you mean? Do you mean your iPhone has no such UI?
Quoted 9 lines
I have actually tested this with an iPhone and it has such an UI element, but it is not realtime. It gets updated after the call has been completed.
So why can't we just update/reset this in Tracker via the history plugin in a general way. I am failing to see the need for this inside oFono. It seems to me that doing this within the scope of the Tracker integration is a lot cleaner and better for CPU and IO usage.
Quoted 6 lines
We can discuss the place of the call counters plugin, but I think using the ofono history framework is a reasonable choice, with the note that the it needs to be expanded with a history function called in the beginning of a call.
The call counters plugin could be an optionally compiled/included (dynamic) plugin or "downgraded" to experimental status.
So I am actually thinking that doing that inside PulseAudio is a lot more efficient solution.
The idea is that PA already runs in the user session and has to monitor the uplink/downlink state (and additionally could monitor call states as well if needed). So it knows when a call is active and it is active anyway doing the audio processing. So it could just then go ahead and write your call accounting into Tracker.
Would such an architecture work for you guys?
Quoted 26 lines
Quoted 20 lines
Quoted 8 lines
The reason these are not properties is just because it makes no sense to update the counters "live". The UI can poll if it so wishes, but the poll interval is not something we want to decide.
Quoted 3 lines
What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here.
Quoted 8 lines
Quoted 3 lines
In addition to that, what is the problem with just updating the stats after the call has ended?
Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear.
I think this is not a good idea to have oFono handles this. Why can't the system daemon just shutdown all calls when the battery reaches critical limit.
Quoted 6 lines
You will never fully run down the battery anyway. One of the system health components in the system will prevent it and then can cleanly shutdown oFono and thus all calls. The only case where the system could potentially misfunction in this area would be an emergency call. But that is a total different use case anyway.
Quoted 3 lines
It was already pointed out by Mika Liljeberg there could be cases when we might not get the chance to sync our data. We need to be prepared to cope with such cases as well (syncing the data often "enough").
Are these cases are really real life problems. For example with devices moving toward hotswap SIM cards, the exchange of battery and accidentally (or on purpose) removal seems to become more and more unrealistic.
Regards
Marcel
Hi Marcel,
Quoted 21 lines · ext Marcel Holtmann
Hi Andras,
Quoted 18 lines
Quoted 18 lines
Quoted 10 lines
Quoted 5 lines
Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API.
We need a UI showing total MO and MT call times. They also need to be able to be reset, if the user so wishes. The data needs to be reasonably reliable.
Fair enough, but when I look at such a feature as a whole, then my question is when does it need to be shown? What is your user interaction requirement with this data?
Andras, please explain what reasonable reliable means.
Quoted 7 lines
Quoted 4 lines
The call counters are shown to the user when he or she opens up an application/applet whatever UI component that is meant for showing this information.
do we have a clear use case requirement from an UI point of view on how this is expected to be working.
In our case, it is expected to have the counters information shown to the user continuously updated with about 1 second granularity, as long as the user keeps opened the UI showing the counters. This practically means "live" call counters in the UI.
Quoted 14 lines
I checked with my iPhone and how it does it. Basically it just updates after the call and only after you re-entered that menu.
So here again, do we have a requirement to make this realtime or not. And I mean that from an user interaction point of view.
Quoted 7 lines
Coming to the reliability part, saving the call counters information often enough, gives us sort of hard guarantee that whatever happens with any subsystem, be that SW or HW, the call counters will stay enough accurate. Syncing to the permanent storage, based on our product requirements, should take place in fact every 5 sec, or could be configurable.
Quoted 4 lines
Writing and syncing something to disk every 5 seconds costs us IO. Is this really a sacrifice that is acceptable.
I agree, from pure technical point of view it's a costly operation.
Quoted 7 lines
Quoted 4 lines
There might be some liability issues if for some reason the counters would "loose" time, the user my blame the phone manufacturer for the extra expenses incurred by inaccurate counters.
To be honest the counters can not be considered accurate anyway. Only the billing system has the final say.
I think any info we decide to show to the user has to be accurate enough, otherwise becomes meaningless.
Quoted 27 lines
Quoted 17 lines
Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API.
What do you mean? Do you mean your iPhone has no such UI?
Quoted 10 lines
I have actually tested this with an iPhone and it has such an UI element, but it is not realtime. It gets updated after the call has been completed.
So why can't we just update/reset this in Tracker via the history plugin in a general way. I am failing to see the need for this inside oFono. It seems to me that doing this within the scope of the Tracker integration is a lot cleaner and better for CPU and IO usage.
Quoted 7 lines
We can discuss the place of the call counters plugin, but I think using the ofono history framework is a reasonable choice, with the note that the it needs to be expanded with a history function called in the beginning of a call.
The call counters plugin could be an optionally compiled/included (dynamic) plugin or "downgraded" to experimental status.So I am actually thinking that doing that inside PulseAudio is a lot more efficient solution.
Quoted 8 lines
The idea is that PA already runs in the user session and has to monitor the uplink/downlink state (and additionally could monitor call states as well if needed). So it knows when a call is active and it is active anyway doing the audio processing. So it could just then go ahead and write your call accounting into Tracker.
Would such an architecture work for you guys?
I don't know at the moment whether this solution is good and elegant enough, we need to think about it.
Quoted 30 lines
Quoted 30 lines
Quoted 30 lines
Quoted 9 lines
The reason these are not properties is just because it makes no sense to update the counters "live". The UI can poll if it so wishes, but the poll interval is not something we want to decide.
Quoted 3 lines
What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here.
Quoted 10 lines
Quoted 4 lines
In addition to that, what is the problem with just updating the stats after the call has ended?
Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear.
I think this is not a good idea to have oFono handles this. Why can't the system daemon just shutdown all calls when the battery reaches critical limit.
You will never fully run down the battery anyway. One of the system health components in the system will prevent it and then can cleanly shutdown oFono and thus all calls. The only case where the system could potentially misfunction in this area would be an emergency call. But that is a total different use case anyway.
Quoted 9 lines
Quoted 4 lines
It was already pointed out by Mika Liljeberg there could be cases when we might not get the chance to sync our data. We need to be prepared to cope with such cases as well (syncing the data often "enough").
Are these cases are really real life problems. For example with devices moving toward hotswap SIM cards, the exchange of battery and accidentally (or on purpose) removal seems to become more and more unrealistic.
Probably this whole data reliability issue shouldn't be an oFono concern after all, there must be a backend doing that and not only for oFono data but any other highly important data.
Quoted 10 lines
Regards
Marcel
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
Regards,
Andras
Hi Andras,
Quoted 11 lines
Quoted 7 lines
Quoted 4 lines
The call counters are shown to the user when he or she opens up an application/applet whatever UI component that is meant for showing this information.
do we have a clear use case requirement from an UI point of view on how this is expected to be working.
In our case, it is expected to have the counters information shown to the user continuously updated with about 1 second granularity, as long as the user keeps opened the UI showing the counters. This practically means "live" call counters in the UI.
are your interaction designers aware of that users wanna use their phone for making phone calls and not watching call counters increasing every single second?
My iPhone has a granularity of 1 minute and I actually had to go out of my normal calling behavior to watch that counter. And it does not update actually during the call. It only updates when the call end.
And just to be clear here. Calling a D-Bus method every single second is not acceptable. That is a sure way to drain you battery.
Quoted 14 lines
Quoted 14 lines
I checked with my iPhone and how it does it. Basically it just updates after the call and only after you re-entered that menu.
So here again, do we have a requirement to make this realtime or not. And I mean that from an user interaction point of view.
Quoted 7 lines
Coming to the reliability part, saving the call counters information often enough, gives us sort of hard guarantee that whatever happens with any subsystem, be that SW or HW, the call counters will stay enough accurate. Syncing to the permanent storage, based on our product requirements, should take place in fact every 5 sec, or could be configurable.
Quoted 5 lines
Quoted 4 lines
Writing and syncing something to disk every 5 seconds costs us IO. Is this really a sacrifice that is acceptable.
I agree, from pure technical point of view it's a costly operation.
So here is my problem with this whole idea. How much do you care about battery life and call time?
You keep waking up ofonod during the call (which is not needed) and you keep the IO active. So from how I am looking at this problem, ofonod is the wrong place to solve this.
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
There might be some liability issues if for some reason the counters would "loose" time, the user my blame the phone manufacturer for the extra expenses incurred by inaccurate counters.
To be honest the counters can not be considered accurate anyway. Only the billing system has the final say.
I think any info we decide to show to the user has to be accurate enough, otherwise becomes meaningless.
Even if we entertain this for a bit, does a user really care about seconds of overall call time. For a single call, maybe, but for your overall call time. Is minutes not enough? How accurate does this really have to be?
Quoted 16 lines
Quoted 16 lines
Quoted 7 lines
We can discuss the place of the call counters plugin, but I think using the ofono history framework is a reasonable choice, with the note that the it needs to be expanded with a history function called in the beginning of a call.
The call counters plugin could be an optionally compiled/included (dynamic) plugin or "downgraded" to experimental status.So I am actually thinking that doing that inside PulseAudio is a lot more efficient solution.
The idea is that PA already runs in the user session and has to monitor the uplink/downlink state (and additionally could monitor call states as well if needed). So it knows when a call is active and it is active anyway doing the audio processing. So it could just then go ahead and write your call accounting into Tracker.
Quoted 4 lines
Quoted 2 lines
Would such an architecture work for you guys?
I don't know at the moment whether this solution is good and elegant enough, we need to think about it.
Please think about this. While not obvious at first, it seems pretty much reasonable to me. PA will be most likely active anyway.
However here is one thing that is unclear to me. Are we tracking talk time or call time. In case of call time, how do we deal with multiparty calls etc. Is a call on hold equals double time and so on.
So does this have to reflect billed time or actual time spent talking on the phone.
I am really missing a well defined features requirement from top to bottom with these details explained.
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 23 lines
Quoted 9 lines
The reason these are not properties is just because it makes no sense to update the counters "live". The UI can poll if it so wishes, but the poll interval is not something we want to decide.
Quoted 3 lines
What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here.
Quoted 10 lines
Quoted 4 lines
In addition to that, what is the problem with just updating the stats after the call has ended?
Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear.
I think this is not a good idea to have oFono handles this. Why can't the system daemon just shutdown all calls when the battery reaches critical limit.
Quoted 7 lines
You will never fully run down the battery anyway. One of the system health components in the system will prevent it and then can cleanly shutdown oFono and thus all calls. The only case where the system could potentially misfunction in this area would be an emergency call. But that is a total different use case anyway.
It was already pointed out by Mika Liljeberg there could be cases when we might not get the chance to sync our data. We need to be prepared to cope with such cases as well (syncing the data often "enough").
Quoted 8 lines
Quoted 5 lines
Are these cases are really real life problems. For example with devices moving toward hotswap SIM cards, the exchange of battery and accidentally (or on purpose) removal seems to become more and more unrealistic.
Probably this whole data reliability issue shouldn't be an oFono concern after all, there must be a backend doing that and not only for oFono data but any other highly important data.
I would highly recommend against making oFono responsible here. Since the ofonod process should be mostly sleeping during a voice call and not being busy with IO.
Regards
Marcel
Hi,
Quoted 8 lines · Marcel Holtmann
So I am actually thinking that doing that inside PulseAudio is a lot more efficient solution.
The idea is that PA already runs in the user session and has to monitor the uplink/downlink state (and additionally could monitor call states as well if needed). So it knows when a call is active and it is active anyway doing the audio processing. So it could just then go ahead and write your call accounting into Tracker.
Pulseaudio (or the meego PA modules for voice) isn't really an option for at least the following reasons:
- lots of modems still handle all audio and PA will know nothing about calls at all with these modems
- PA does not really care about individual calls, but whether the audio traffic channel is connected or not
- multi-call cases, cases were traffic channel is reconnected mid-call, etc, etc, PA simply does not know enough (and should not)
I guess this could be done in higher layers on top of oFono (telepathy-ring, dialer app, policy framework, etc), but I don't really know enough about the call timer stuff to comment on the pro/cons of this.
br,
Signature · 1 line
Kai Vehmanen
Hi Kai,
Quoted 9 lines
Quoted 8 lines
So I am actually thinking that doing that inside PulseAudio is a lot more efficient solution.
The idea is that PA already runs in the user session and has to monitor the uplink/downlink state (and additionally could monitor call states as well if needed). So it knows when a call is active and it is active anyway doing the audio processing. So it could just then go ahead and write your call accounting into Tracker.
Quoted 4 lines
Pulseaudio (or the meego PA modules for voice) isn't really an option for at least the following reasons:
- lots of modems still handle all audio and PA will know nothing about calls at all with these modems
actually Denis raised the same question, but then again this is for a product specific requirement. And for that product we know that PA will do the audio processing.
Quoted 5 lines
- PA does not really care about individual calls, but whether the audio traffic channel is connected or not
- multi-call cases, cases were traffic channel is reconnected mid-call, etc, etc, PA simply does not know enough (and should not)
And that is my point (see other email). This should be tracking talk time and not individual call time. And thus it would be fitting nicely into PA in that case.
Quoted 3 lines
I guess this could be done in higher layers on top of oFono (telepathy-ring, dialer app, policy framework, etc), but I don't really know enough about the call timer stuff to comment on the pro/cons of this.
Important for me is to weight the extra costs of IO and CPU consumption when doing this inside oFono. And since ofonod itself would actually not wake up during a phone call, I think this is not a good fit.
It could be that PA is not a good candidate either, but to me it looks like a pretty smart place to handle this.
Regards
Marcel
Hi,
Quoted 6 lines · Marcel Holtmann
Quoted 2 lines
- lots of modems still handle all audio and PA will know nothing about calls at all with these modems
actually Denis raised the same question, but then again this is for a product specific requirement. And for that product we know that PA will do the audio processing.
not really. We need modem adaptation for call counters and need an API that works with all modems. And I'd assume other handset vendors need such an API as well (either in oFono or somewhere else).
Quoted 3 lines
Important for me is to weight the extra costs of IO and CPU consumption when doing this inside oFono. And since ofonod itself would actually not wake up during a phone call, I think this is not a good fit.
I share the concern for the IO/CPU cost, but I don't think it matters much in which daemon this is done. Especially if some slack is allowed for the timers (which should be the case), ofonod will be scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts wake up pulseaudio). So the big cost of bringing CPU, memories et al online are already taken at this point, and the additional cost of running ofonod for a while is minimal (compared to waking up some non-realtime thread of pulseaudio, or some other component, to do the same).
But yeah, there is a IO/CPU cost in any case, I agree about that.
Br,
Signature · 1 line
Kai Vehmanen
Hi Kai,
Quoted 15 lines
Quoted 6 lines
Quoted 2 lines
- lots of modems still handle all audio and PA will know nothing about calls at all with these modems
actually Denis raised the same question, but then again this is for a product specific requirement. And for that product we know that PA will do the audio processing.
not really. We need modem adaptation for call counters and need an API that works with all modems. And I'd assume other handset vendors need such an API as well (either in oFono or somewhere else).
Quoted 3 lines
Important for me is to weight the extra costs of IO and CPU consumption when doing this inside oFono. And since ofonod itself would actually not wake up during a phone call, I think this is not a good fit.
Quoted 8 lines
I share the concern for the IO/CPU cost, but I don't think it matters much in which daemon this is done. Especially if some slack is allowed for the timers (which should be the case), ofonod will be scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts wake up pulseaudio). So the big cost of bringing CPU, memories et al online are already taken at this point, and the additional cost of running ofonod for a while is minimal (compared to waking up some non-realtime thread of pulseaudio, or some other component, to do the same).
this is not really true. We can not wakeup ofonod every single second. You might wanna start running powertop.
Regards
Marcel
Hello Marcel,
Quoted 8 lines · Marcel Holtmann
Quoted 5 lines
I share the concern for the IO/CPU cost, but I don't think it matters much in which daemon this is done. Especially if some slack is> allowed for the timers (which should be the case), ofonod will be scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts wake up pulseaudio).
this is not really true. We can not wakeup ofonod every single second. You might wanna start running powertop.
uhm, but I'm not claiming that. I was just stating that moving the timers to e.g. pulseaudio in this case won't save much if anything (the CPU will be woken up anyways, and the cost between scheduling ofonod or a thread from PA, has really no difference to overall consumption.. the CPU is woken up anyways and roughly the same code to handle the timer is run).
So whether this code is in oFono or elsewhere, does not matter much (to overall power consumption). The main question is of course how often the counters are synced.
Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult.
br,
Signature · 1 line
Kai Vehmanen
Hi Kai,
Quoted 16 lines
Quoted 8 lines
Quoted 5 lines
I share the concern for the IO/CPU cost, but I don't think it matters much in which daemon this is done. Especially if some slack is> allowed for the timers (which should be the case), ofonod will be scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts wake up pulseaudio).
this is not really true. We can not wakeup ofonod every single second. You might wanna start running powertop.
uhm, but I'm not claiming that. I was just stating that moving the timers to e.g. pulseaudio in this case won't save much if anything (the CPU will be woken up anyways, and the cost between scheduling ofonod or a thread from PA, has really no difference to overall consumption.. the CPU is woken up anyways and roughly the same code to handle the timer is run).
Quoted 3 lines
So whether this code is in oFono or elsewhere, does not matter much (to overall power consumption). The main question is of course how often the counters are synced.
actually it does matter since you have no extra context switch and in addition you not accidentally wake up PA and then ofonod. You have one centralized wakeup of one thread.
Of course this should be smart and done along with the PA audio processing and not async to that one.
If we consider that the only sensible thing is to track the actual talking time, then PA becomes a nice choice for this.
This doesn't mean that you should be implementing it, but I am still maintaining that this would be a pretty damn smart way of solving this efficiently.
Quoted 3 lines
Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult.
My take here is that a granularity of 1 minute is enough.
Doing this every 10 seconds and displaying it on a per second level sounds insane to me.
Regards
Marcel
Hi,
Quoted 30 lines · ext Marcel Holtmann
Hi Kai,
Quoted 16 lines
Quoted 9 lines
Quoted 6 lines
I share the concern for the IO/CPU cost, but I don't think it matters much in which daemon this is done. Especially if some slack is> allowed for the timers (which should be the case), ofonod will be scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts wake up pulseaudio).
this is not really true. We can not wakeup ofonod every single second. You might wanna start running powertop.
uhm, but I'm not claiming that. I was just stating that moving the timers to e.g. pulseaudio in this case won't save much if anything (the CPU will be woken up anyways, and the cost between scheduling ofonod or a thread from PA, has really no difference to overall consumption.. the CPU is woken up anyways and roughly the same code to handle the timer is run).
Quoted 4 lines
So whether this code is in oFono or elsewhere, does not matter much (to overall power consumption). The main question is of course how often the counters are synced.
actually it does matter since you have no extra context switch and in addition you not accidentally wake up PA and then ofonod. You have one centralized wakeup of one thread.
Of course this should be smart and done along with the PA audio processing and not async to that one.
Quoted 8 lines
If we consider that the only sensible thing is to track the actual talking time, then PA becomes a nice choice for this.
This doesn't mean that you should be implementing it, but I am still maintaining that this would be a pretty damn smart way of solving this efficiently.
Obviously, there are many implementation options, we have to decide only about whether we want to have this implemented in oFono or not, or in first place, whether the feature is needed at all or not. For the latter part I am collecting more info from our people.
Quoted 9 lines
Quoted 4 lines
Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult.
My take here is that a granularity of 1 minute is enough.
Doing this every 10 seconds and displaying it on a per second level sounds insane to me.
That second level D-Bus query of the call counters should be forgotten, probably is not going to happen and anyways, querying is something that can be controlled/tuned outside ofono. In fact any method can be "abused" in a similar way, is not oFono's responsibility to prevent such "misuse" from happening.
There is a single value to tune, the sync interval, we can either settle on a reasonable value, or we can make it a configurable parameter (the default value would disable the periodic syncing), then everybody can do whatever with its own product.
Quoted 10 lines
Regards
Marcel
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono
Regards,
Andras
Quoted 2 lines · you
Quoted 2 lines
Quoted 2 lines
this is not really true. We can not wakeup ofonod every single second. You might wanna start running powertop.
Yes we can. PulseAudio is going to be waking up the CPU 10 times per seconds or more.
Quoted 7 lines
Quoted 7 lines
uhm, but I'm not claiming that. I was just stating that moving the timers to e.g. pulseaudio in this case won't save much if anything (the CPU will be woken up anyways, and the cost between scheduling ofonod or a thread from PA, has really no difference to overall consumption.. the CPU is woken up anyways and roughly the same code to handle the timer is run).
Quoted 7 lines
Quoted 3 lines
So whether this code is in oFono or elsewhere, does not matter much (to overall power consumption). The main question is of course how often the counters are synced.
actually it does matter since you have no extra context switch and in addition you not accidentally wake up PA and then ofonod. You have one centralized wakeup of one thread.
No! The one extra context switch is negligible compared to the several few system calls that updating the call counter requires. And as Kai already said, the CPU will wake up anyway.
The real power consumption difference lies in the I/O, which would not happen if it weren't for fault-tolerant call counters. In that respect, which process writes, PulseAudio, oFono, or something else, is irrelevant.
Quoted 2 lines
Of course this should be smart and done along with the PA audio processing and not async to that one.
No. PulseAudio has no business with the call counters. It might not know that it is a call. And even if it did know, it might not know whether the call is ringing or connected.
oFono on the other hand has the informations. Also, if we gave up on fault tolerance to save power, oFono would be the logical place to provide call counters (through D-Bus). So it only makes sense that oFono does this - if anyone.
And then, it's our nor your decision to make how often (if at all) the call counters need to be flushed to the memory card. That's a matter for the vendor's legal & liability departement. So it really just needs to be configurable, including the ability to disable the feature altogether if it is not needed.
Quoted 2 lines
If we consider that the only sensible thing is to track the actual talking time, then PA becomes a nice choice for this.
I don't think so.
Quoted 9 lines
This doesn't mean that you should be implementing it, but I am still maintaining that this would be a pretty damn smart way of solving this efficiently.
Quoted 3 lines
Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult.
My take here is that a granularity of 1 minute is enough.
There are definitely call fares with sub-minute granularity. The minute is definitely INSUFFICIENT.
Quoted 2 lines
Doing this every 10 seconds and displaying it on a per second level sounds insane to me.
So I made a lengthy call to my mum this morning, using a desk phone. And it was showing minute:second, not just minutes. I have never seen a phone that does not show seconds and it would look pretty dumb to me.
But of course, that's a matter for UI designers, not for middleware oFono software engineers anyway.
Signature · 2 lines
Rémi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki
Hi Remi,
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult.
My take here is that a granularity of 1 minute is enough.
There are definitely call fares with sub-minute granularity. The minute is definitely INSUFFICIENT.
let me repeat my question here. Does this suppose to be represent spent time on calls (what I called talk time) or actual billing minutes.
If we talk about correct billing minutes then you are just opening pandora's box. Since we don't know the billing. And difference between air time, incoming/outgoing calls, multiparty calls, hold calls etc. and their billing schemes make this just insane.
So what is the actual requirement here. So far ever single answer was not satisfying. And that is why I proposed to just make this count the talk time.
Quoted 6 lines
Quoted 2 lines
Doing this every 10 seconds and displaying it on a per second level sounds insane to me.
So I made a lengthy call to my mum this morning, using a desk phone. And it was showing minute:second, not just minutes. I have never seen a phone that does not show seconds and it would look pretty dumb to me.
You do realize that this is NOT the feature we are talking about here.
The actual display of the duration of a call is pretty simple and currently easy to handle inside the UI. And that can be done up to the millisecond display if you or your UI designer wants it.
The proposed call counters here are long term counters showing your overall time. So showing minutes seems to be precise enough.
Regards
Marcel
Quoted 6 lines · you
Hi Remi,
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
My take here is that a granularity of 1 minute is enough.
There are definitely call fares with sub-minute granularity. The minute is definitely INSUFFICIENT.
let me repeat my question here. Does this suppose to be represent spent time on calls (what I called talk time) or actual billing minutes.
As said earlier, this is about the talk time. The scenario is a user ejects the battery during an already long-standing call or gets the device to crash or reset, gets billed, and comes and complain to its operator that (s)he gets overcharged. The counters will be much more wrong if we do not flush them to disk frequently.
We do not need to "implement" the billing policy for that. This is only about the total talk time.
Quoted 4 lines
If we talk about correct billing minutes then you are just opening pandora's box. Since we don't know the billing. And difference between air time, incoming/outgoing calls, multiparty calls, hold calls etc. and their billing schemes make this just insane.
Sure. We don't wants this.
Quoted 3 lines
So what is the actual requirement here. So far ever single answer was not satisfying. And that is why I proposed to just make this count the talk time.
The requirement is that the user cannot deduct (much) talk time from the call counters.
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Doing this every 10 seconds and displaying it on a per second level sounds insane to me.
So I made a lengthy call to my mum this morning, using a desk phone. And it was showing minute:second, not just minutes. I have never seen a phone that does not show seconds and it would look pretty dumb to me.
Quoted 8 lines
You do realize that this is NOT the feature we are talking about here.
The actual display of the duration of a call is pretty simple and currently easy to handle inside the UI. And that can be done up to the millisecond display if you or your UI designer wants it.
The proposed call counters here are long term counters showing your overall time. So showing minutes seems to be precise enough.
Showing minutes, as in flushing the counters every 60 seconds might work, but I'd rather make this a configurable knob.
That said, I do believe the stored value has to be more precise than minutes. Otherwise per call "error" may add up far too quickly.
Signature · 2 lines
Rémi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki
Hi Remi,
Quoted 26 lines
Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult.
My take here is that a granularity of 1 minute is enough.
There are definitely call fares with sub-minute granularity. The minute is definitely INSUFFICIENT.
let me repeat my question here. Does this suppose to be represent spent time on calls (what I called talk time) or actual billing minutes.
As said earlier, this is about the talk time. The scenario is a user ejects the battery during an already long-standing call or gets the device to crash or reset, gets billed, and comes and complain to its operator that (s)he gets overcharged. The counters will be much more wrong if we do not flush them to disk frequently.
We do not need to "implement" the billing policy for that. This is only about the total talk time.
Quoted 4 lines
If we talk about correct billing minutes then you are just opening pandora's box. Since we don't know the billing. And difference between air time, incoming/outgoing calls, multiparty calls, hold calls etc. and their billing schemes make this just insane.
Quoted 8 lines
Sure. We don't wants this.
Quoted 3 lines
So what is the actual requirement here. So far ever single answer was not satisfying. And that is why I proposed to just make this count the talk time.
The requirement is that the user cannot deduct (much) talk time from the call counters.
is actually everybody in agreement here that we talk about actual time spent on the phone talking? Denis and myself clearly see it that this is a sensible approach to overall call counters.
And if that is the case, then this maps closely to what PA has to track anyway. The more and more we talk about this, the more and more it makes sense to me to do this as a plugin to PA that stores the overall call time values into Tracker. And then can also be reset via Tracker.
This would satisfy all my concern that I have from an process wakeup and IO utilization overhead and battery consumption point of view.
Quoted 13 lines
Quoted 13 lines
Quoted 6 lines
Quoted 2 lines
Doing this every 10 seconds and displaying it on a per second level sounds insane to me.
So I made a lengthy call to my mum this morning, using a desk phone. And it was showing minute:second, not just minutes. I have never seen a phone that does not show seconds and it would look pretty dumb to me.
You do realize that this is NOT the feature we are talking about here.
The actual display of the duration of a call is pretty simple and currently easy to handle inside the UI. And that can be done up to the millisecond display if you or your UI designer wants it.
Quoted 8 lines
Quoted 2 lines
The proposed call counters here are long term counters showing your overall time. So showing minutes seems to be precise enough.
Showing minutes, as in flushing the counters every 60 seconds might work, but I'd rather make this a configurable knob.
That said, I do believe the stored value has to be more precise than minutes. Otherwise per call "error" may add up far too quickly.
I don't see this as a problem at all. This does not add up.
So if you loose 59 seconds in a 4 hours call, then that is pretty much statistically irrelevant. And that is only the case if you magically loose your battery.
In case you run out of battery or end the call properly, you will still get the accurate counter to the second. Since the device management daemon or oFono will inform you about it.
What you should really ask yourself is what you present to the user. If you use your phone for 3 phone calls that are less than three seconds, you might wanna display seconds. However in that case you have the accurate counter when ending the call in the first place. If you loose your battery and have not used the phone longer than a minute, why bother. This is not the problem that needs to be solved.
If you spent something crazy like 60 hours on the phone per month and then loose 59 seconds, it makes no difference either. At that point that inaccuracy is statistically irrelevant and can be ignored. And again, this is only a problem if you battery magically gets loose and flies away. Otherwise you are accurate to the second.
So in conclusion having an IO sync of the ongoing call every 60 seconds seems to be reasonable enough. And at the same time you keep a down to the second call time in case of a healthy device.
With all this in mind. How often does someone magically loose the battery and then goes complain to someone about a "big" difference in the bills. Or is this more an esoteric feature request. Can we not try to solve this sensible without going overboard and trying to solve world hunger ;)
Regards
Marcel
Hello,
Quoted 7 lines · Denis-Courmont Remi
Quoted 2 lines
let me repeat my question here. Does this suppose to be represent spent time on calls (what I called talk time) or actual billing minutes.
As said earlier, this is about the talk time. The scenario is a user ejects the battery during an already long-standing call or gets the device to crash or reset, gets billed, and comes and complain to its operator that (s)he gets overcharged. The counters will be much more wrong if we do not
I'm no longer sure what you guys mean with "billing minutes" and "talk time" here, so maybe we should talk in terms of code. E.g. look at the patches Andras sent to the list to see what is tracked and how:
- each call is tracked separately (e.g. counter still running for held calls)
- tracking separately for MO/MT calls
- call starts when state goes to ACTIVE (from INCOMING/ALERTING/DIALING/WAITING)
- call terminates to DISCONNECTED
In case of conflict, what's actually in Andras' patches overrides my interpretation above. ;)
This concept is already in oFono core (call->start_time is created when calls start, and __ofono_history_call_ended is called when calls end, matching the above).
Quoted 3 lines
That said, I do believe the stored value has to be more precise than minutes.
Otherwise per call "error" may add up far too quickly.
Yes, but I agree with Marcel that a 60sec update interval sounds reasonable (so higher resolution for stored values, but updates at e.g. every minute). Even better if the refresh rate can be tuned.
Hello Marcel,
I'll answer to two separates mails (of this thread) in one go:
Quoted 8 lines · Marcel Holtmann
Quoted 3 lines · Kai Vehmanen
So whether this code is in oFono or elsewhere, does not matter much (to overall power consumption). The main question is of course how often the counters are synced.
actually it does matter since you have no extra context switch and in addition you not accidentally wake up PA and then ofonod. You have one centralized wakeup of one thread.
You cannot do this with one thread wakeup. The real-time parts implementing voice data path in pulseaudio (and ones waking up to hw interrupts) need to follow soft-realtime practises to maximize execution determinism. I.e. these threads are run with SCHED_FIFO/RR and any calls to possibly-blocking system calls must be avoided (this includes dynamic memory allocation, access to file/sokcets, etc, etc). See e.g. JACK audio server project's guidelines for client apps for a good overview of what these limitations mean in practise.
Storing the call counters requires file/socket i/o, so doing this from a real-time thread is a big no-no (and if done anyways, would be a likely cause to audio hickups).
So you need to wake up another thread in any case (e.g. PA has separate threads for DBus and talking to PA clients). Of course an explicit wake-up is better than relying on timer slack to coalesce the wakeup of ofonod and pulseaudio, so I agree using a PA thread is technically better and more robust way to ensure no extra wakeups occur, but if/when implemented properly, waking up ofonod really has no penalty either.
But the above is really a minor issue I think. I think the most important argument against doing this in PA is (quoting my earlier reply):
--cut--
- lots of modems still handle all audio and PA will know nothing about calls at all with these modems
--ct---
This needs to be done in a component that is tracking calls, independently of what modem is used.
And then one further comment to a more recent mail in this thread:
Quoted 6 lines · Marcel Holtmann
is actually everybody in agreement here that we talk about actual time spent on the phone talking? Denis and myself clearly see it that this is a sensible approach to overall call counters.
And if that is the case, then this maps closely to what PA has to track anyway.
No, no. Surely what matters are the individual calls, and their state w.r.t. signaling. And this is what the patches Andras' has sent are tracking.
PA on the other hand tracks the traffic channel state and that cannot be used. E.g. in common real-life cases (handovers), the traffic channel can be temporarily disconnected during an active call (PA will see this, but it is _not_ visible in either the phone UI nor in billing). For to PA to implement call counters, it would have to be extended to track individual call state.
Br,
Signature · 1 line
Kai Vehmanen