oFono SMS Validity Period and Message Class support
Hi, all: We are using ofono to send sms with validity period and message class in our project. but by checking source code, it seems ofono doesn't support these requirements. Current implemntation is the dbus interface "SendMessage" contains "To" and "Text" only. Does oFono plan to support these extra fields when sending sms? Thanks. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 3/6] radio settings: add FastDormancy property
Hi Denis, > > The fundamental problem here is that there is only a single > CACHED flag for multiple properties, which may be modified > individually. So, either you get extra signals or you get too > few. I checked the CACHED flag here because otherwise the > following might happen: > > Yes, I know. But this problem is present in every single atom. oFono > does not guarantee that every attribute is signaled when the atom is > initialized. So I gathered. To me this looks like a wider issue, though. InProgress errors are returned in many other contexts as well, and they are not that well documented in the API documentation. All this makes it a bit painful to write a robust oFono client. Probably this could be at least partially rectified by improving the documentation. > > 1. client tries to GetProperties() and gets the "Operation > already in progress" error. > > 2. client waits for PropertyChanged signal to get the > FastDormancy value > > 3. signal never comes because the default value happens to > match the one returned by the driver and the signal is suppressed > > > > In general I think that for interfaces where this can happen, the > likelihood is very low that it actually will in the real world. Perhaps so. The network and SIM interfaces, which are most likely to be bombared by multiple UI components, seem to be doing the right thing at least. > Do note that I have had the same argument with myself off and > on for the > past two years. So far this was never raised as an issue. > If this ever > becomes a problem, we can fix it properly using an appropriate idiom. If this becomes a problem, it won't necessarily be visible to upstream. More likely this will be noticed in product maturization phase, and the fixes made to a product specific stable branches might never trickle back to upstream. > > I do agree that sending extra signals is bad but I think > that not sending a signal is even worse. If the client cannot > rely on getting a PropertyChanged signal after a busy error, > all it can do is resort to polling. I.e., every client has to > implement a polling pattern for GetProperties: > > > > while (GetProperties() == BUSY) > > sleep(FOR_A_WHILE); > > > > Having a separate CACHED flag for each value would solve > this optimally. Failing that, I don't think a few extra > signals is so bad. Forcing clients to poll is just ugly. > > > > Honestly, if you expect multiple applications to battle over the > FastDormancy property, then it should be modeled differently. Perhaps > with application registration and lifetime tracking over > D-Bus, similar > to how agents work. Hardly that, FastDormancy is unlikely to be a problem. I was merely curious whether there is a general design rule underneath, or if these things are decided on a case by case basis. Based on your comments and looking at the code, I guess it's more case by case. I just feel uneasy about an API that returns transient errors by design, on the (even if informed) assumption that it will probably be ok. I also dislike the fact that a generic InProgress error pretty much forces a client to just retry each operation until it succeeds. If there are problems like this, they are most likely discovered only in the product maturization phase and then it's generally too late to fix the upstream. Too late for that particular product, that is. Br, MikaL ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 2/3] voicecall: emergency call handling added
Hi Denis,
Thank you for your comments, here is my response.
On 10/28/2010 06:48 AM, ext Denis Kenzior wrote:
Hi Andras,
On 10/25/2010 03:03 AM, Andras Domokos wrote:
From: Andras Domokos
Signed-off-by: Andras Domokos
---
include/voicecall.h | 12 +++
src/voicecall.c | 221 ++
2 files changed, 215 insertions(+), 18 deletions(-)
diff --git a/include/voicecall.h b/include/voicecall.h
index 2356fcf..d530148 100644
--- a/include/voicecall.h
+++ b/include/voicecall.h
@@ -38,6 +38,9 @@ typedef void (*ofono_call_list_cb_t)(const struct ofono_error
*error,
const struct ofono_call *call_list,
void *data);
+typedef void (*ofono_voicecall_emergency_notify_cb_t)(ofono_bool_t state,
+ void *data);
+
/* Voice call related functionality, including ATD, ATA, +CHLD, CTFR, CLCC
* and VTS.
*
@@ -116,6 +119,15 @@ void ofono_voicecall_set_data(struct ofono_voicecall *vc,
void *data);
void *ofono_voicecall_get_data(struct ofono_voicecall *vc);
int ofono_voicecall_get_next_callid(struct ofono_voicecall *vc);
+unsigned int __ofono_voicecall_add_emergency_watch(struct ofono_voicecall *vc,
+ ofono_voicecall_emergency_notify_cb_t notify,
+ void *data, ofono_destroy_func destroy);
+void __ofono_voicecall_remove_emergency_watch(struct ofono_voicecall *vc,
+ unsigned int id);
+ofono_bool_t ofono_voicecall_get_emergency_state(struct ofono_voicecall *vc);
+void __ofono_voicecall_set_emergency_state(struct ofono_voicecall *vc,
+ int state);
+
Just some general comments, but this patch seems to be backwards from
the earlier proposal. Namely EmergencyMode is a property on the Modem
interface, not on the VoiceCallManager. See doc/modem-api.txt,
Emergency property.
I thought it was more logical to have the EmergencyMode property
linked to voicecall since it is about a special call case, but I am fine
with moving that property up to modem level.
In general I think that the emergency_watch is unnecessary. Having a
reference counted emergency tracking inside the modem object and a modem
online state watch should be sufficient.
The idea with the emergency watch is that any subsystem can get the
notification when the emergency mode is entered and react on it.
To give you a more complex example, it might well be that the gprs
connection needs to be torn down when making an emergency call in
2G mode, there are such networks out there that prevents you from
making an emergency call if your device is attached to a PDP context.
In this given situation it comes to the question how to bring down the
gprs connection. It can be done such that the gprs atom will tear down
the connection after receiving the EmergencyMode notification, or
another option is to have gprs connection handling functions made
available by gprs and to deal with the gprs connection within voicecall
(or somewhere else). The online/offline mode change handling in fact is
bringing up the some issue, how the mode change handling should be
implemented when making the emergency call. My idea was let every
subsystem deal with the specifics of its own subsystem.
#ifdef __cplusplus
}
#endif
diff --git a/src/voicecall.c b/src/voicecall.c
index 7b5fe3b..a619b30 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
#include
@@ -56,6 +57,9 @@ struct ofono_voicecall {
void *driver_data;
struct ofono_atom *atom;
struct dial_request *dial_req;
+ struct ofono_watchlist *emergency_watches;
+ unsigned int emergency_state;
+ unsigned int modem_state_watch;
};
struct voicecall {
@@ -85,6 +89,8 @@ static const char *default_en_list_no_sim[] = { "119", "118", "999",
"110",
static void generic_callback(const struct ofono_error *error, void *data);
static void multirelease_callback(const struct ofono_error *err, void *data);
+static const char *voicecall_build_path(struct ofono_voicecall *vc,
+ const struct ofono_call *call);
It is generally against the coding style to forward-declare static
functions. If this function is needed, please simply move it higher.
OK, I'll conform to the agreed coding policy.
static gint call_compare_by_id(gconstpointer a, gconstpointer b)
{
@@ -121,6 +127,145 @@ static void add_to_en_list(GSList **l, const char **list)
*l = g_slist_prepend(*l, g_strdup(list[i++]));
}
+static gint number_compare(gconstpointer a, gconstpointer b)
+{
+ const char *s1 = a, *s2 = b;
+ return strcmp(s1, s2);
+}
+
+static ofono_bool_t emergency_number(struct ofono_voicecall *vc,
+ con
RE: oFono SMS Validity Period and Message Class support
Hi, > Hi, all: > > We are using ofono to send sms with validity period and > message class in our project. > but by checking source code, it seems ofono doesn't support > these requirements. > > Current implemntation is the dbus interface "SendMessage" > contains "To" and "Text" only. > > Does oFono plan to support these extra fields when sending sms? > Right now oFono uses hardcoded Relative validity period of value 167 (24hrs: 12hrs +(167-143)x30mins)for SUBMIT message. If later supported then the Validity period should be part of the SMS app settings and the setting changes will trigger the property change in the org.ofono.MessageManager interface. But currently Validity Period property is missing in org.ofono.MessageManager interface. So it doesnt need to be part of the SendMessage dbus interface ? Regarding the message class, none of the UE usually gives the a user setting for message class for outgoing SMS. So oFono uses unspecified message class and it sets only the encoding type (GSM 7bit or UCS2) in the DCS byte for the SUBMIT message. For the SMS DELIVER it decodes the Message class and handles it accordingly (Note: Class 2 messages are not supported in oFono) BR, Rajesh ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: huawei e1550
Bump. Same problem in 0.33 and 0.33 git ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] TODO: Owner of Read / Write EFcfis
Hi Jeevaka, > TODO |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) patch has been applied. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 2/3] voicecall: emergency call handling added
Hi Andras, > > In general I think that the emergency_watch is unnecessary. Having a > > reference counted emergency tracking inside the modem object and a modem > > online state watch should be sufficient. > > > > > The idea with the emergency watch is that any subsystem can get the > notification when the emergency mode is entered and react on it. > To give you a more complex example, it might well be that the gprs > connection needs to be torn down when making an emergency call in > 2G mode, there are such networks out there that prevents you from > making an emergency call if your device is attached to a PDP context. > In this given situation it comes to the question how to bring down the > gprs connection. It can be done such that the gprs atom will tear down > the connection after receiving the EmergencyMode notification, or > another option is to have gprs connection handling functions made > available by gprs and to deal with the gprs connection within voicecall > (or somewhere else). The online/offline mode change handling in fact is > bringing up the some issue, how the mode change handling should be > implemented when making the emergency call. My idea was let every > subsystem deal with the specifics of its own subsystem. we had this specific discussion before and my understanding is that all these networks have been updated by now anyway. So this is not an issue anymore. However in the end this is not something oFono should be doing in the first place. The modem should do this. oFono does not know if something is or becomes an emergency call. Only the modem itself knows if it starts the procedure to make an emergency call. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 3/6] radio settings: add FastDormancy property
Hi Mika, > > So I gathered. To me this looks like a wider issue, though. InProgress errors > are returned in many other contexts as well, and they are not that well > documented in the API documentation. All this makes it a bit painful to write > a robust oFono client. Probably this could be at least partially rectified by > improving the documentation. > Of course, and patches are always welcome. >> Do note that I have had the same argument with myself off and >> on for the >> past two years. So far this was never raised as an issue. >> If this ever >> becomes a problem, we can fix it properly using an appropriate idiom. > > If this becomes a problem, it won't necessarily be visible to upstream. More > likely this will be noticed in product maturization phase, and the fixes made > to a product specific stable branches might never trickle back to upstream. > I disagree. I think upstream will be notified and we will improve the situation as we progress. But I do agree it might be too late for that particular product. Of course that is the case with all software. >> Honestly, if you expect multiple applications to battle over the >> FastDormancy property, then it should be modeled differently. Perhaps >> with application registration and lifetime tracking over >> D-Bus, similar >> to how agents work. > > Hardly that, FastDormancy is unlikely to be a problem. I was merely curious > whether there is a general design rule underneath, or if these things are > decided on a case by case basis. Based on your comments and looking at the > code, I guess it's more case by case. I just feel uneasy about an API that > returns transient errors by design, on the (even if informed) assumption that > it will probably be ok. I also dislike the fact that a generic InProgress > error pretty much forces a client to just retry each operation until it > succeeds. If there are problems like this, they are most likely discovered > only in the product maturization phase and then it's generally too late to > fix the upstream. Too late for that particular product, that is. > One of the biggest principles in oFono is not to perform premature optimization. Sure there is a potential issue, but nobody knows whether it will actually manifest itself outside of malicious code (which we tell to bugger off) or what the most common manifestation pattern will be. If / once we know for sure this is a problem, then we can solve it properly. So far this approach has been working very nicely for us. There are countless occasions where taking the wait-and-see approach and gathering more information allowed us to devise a much better solution than we would have originally. So the general rule is: Do the simplest thing that is likely to work. If it doesn't work, improve it. > Br, > > MikaL Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: oFono SMS Validity Period and Message Class support
Hi, On 10/29/2010 03:43 AM, Su, Yong wrote: > Hi, all: > > We are using ofono to send sms with validity period and message class in our > project. > but by checking source code, it seems ofono doesn't support these > requirements. oFono does not allow you to set the validity period and simply hard-codes it (I believe 48 hours). Unless you have a really good reason why you want to set the validity period, this isn't likely to change. Sending SMS messages other than class unspecified makes no sense and will not be supported. If you have some extremely specific use case in mind where this does make sense, please write your own oFono plugin. > > Current implemntation is the dbus interface "SendMessage" contains "To" and > "Text" only. > > Does oFono plan to support these extra fields when sending sms? Right now the answer is no. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 2/3] voicecall: emergency call handling added
Hi Andras, >> Just some general comments, but this patch seems to be backwards from >> the earlier proposal. Namely EmergencyMode is a property on the Modem >> interface, not on the VoiceCallManager. See doc/modem-api.txt, >> Emergency property. >> > I thought it was more logical to have the EmergencyMode property > linked to voicecall since it is about a special call case, but I am fine > with moving that property up to modem level. > Oh I can see that as well, but I think earlier we agreed that it should be on the Modem interface. This has several advantages: offline / online toggling has to happen in the modem and it is easier for the power management framework to monitor it there. So unless you feel really strongly against that I suggest we stick with the earlier proposal. >> In general I think that the emergency_watch is unnecessary. Having a >> reference counted emergency tracking inside the modem object and a modem >> online state watch should be sufficient. >> >> > The idea with the emergency watch is that any subsystem can get the > notification when the emergency mode is entered and react on it. Don't get me wrong, it might be useful in the future. But for the context of supporting emergency calls in the voicecall driver the emergency watch is not really needed. In general I prefer to review code which has an immediate or foreseeable need. In this case if we detect an emergency call dial and we're offline, we: - Save the pending call - establish an online watch - ofono_modem_inc_emergency_mode() Once we are online: - Dial the call Once the call ends - ofono_modem_dec_emergency_mode() Nowhere do we actually need to use an emergency watch itself. > To give you a more complex example, it might well be that the gprs > connection needs to be torn down when making an emergency call in > 2G mode, there are such networks out there that prevents you from > making an emergency call if your device is attached to a PDP context. > In this given situation it comes to the question how to bring down the > gprs connection. It can be done such that the gprs atom will tear down > the connection after receiving the EmergencyMode notification, or > another option is to have gprs connection handling functions made Have we established that this is actually still needed? I thought you guys said all the networks that have this problem have been fixed by now? If this is still required, I suggest you group the emergency watch functions with patches implementing the above functionality. > available by gprs and to deal with the gprs connection within voicecall > (or somewhere else). The online/offline mode change handling in fact is > bringing up the some issue, how the mode change handling should be > implemented when making the emergency call. My idea was let every > subsystem deal with the specifics of its own subsystem. Let the modem figure out the specifics. Basically as long as the count for emergency is greater than 1, Offline mode should not be entered. Once it reaches 0, the online mode should go back to the previous value. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
