Re: [PATCH 0/10] Unregister AT notifiers when removing drivers
Hi Zhenhua, This series unregister AT notifiers in removing various AT modem drivers when modem goes to offline mode. Please review them. just a heads up here that Denis and I talked about this. And we are going to fix this inside GAtChat in the background for you. Trying to fix this single handed in every atom driver is wrong. This approach creates too much of a maintenance burden. And additional code complexity and memory footprint doing it this way. So we have to tackle it in a central place. And that is GAtChat. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 04/16] emulator: Add APIs to send GAtServer result
Hi Zhenhua,
Defines APIs to send final/intermediate/unsolicited result to DUN
client.
---
include/emulator.h |2 ++
src/emulator.c | 28
src/ofono.h| 11 +++
3 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/include/emulator.h b/include/emulator.h
index 29e87b9..2a45c65 100644
--- a/include/emulator.h
+++ b/include/emulator.h
@@ -36,6 +36,8 @@ enum ofono_emulator_status {
OFONO_EMULATOR_STATUS_DESTROY,
};
+enum _GAtServerResult;
+
this is not good. It should not be needed outside of GAtChat. Why not
just include gatserver.h?
And in addition the _GAt declaration should never be used. Why not use
the typedef one?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
maximum number of gsm 7 bit character in a concatenate sms message, supported by Ofono
All, Could someone tell me the maximum number of characters in a concatenated sms message containing standard gsm 7 bit characters , I could send using ofono ? Regards, Alain - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Removal of modemconf plugin
Hello, so the modemconf plugin seemed to be a good idea at the time I wrote it, but lately is causes more issues and confusion than it solves. So we will be removing this plugin shortly. For this to happen the following dependencies need to be solved first: 1) Move phonesim plugin over to use /etc/ofono/phonesim.conf 2) Create configure option to build without phonesim support 3) Create udev rule for Calypso device detection 4) Modify Calypso plugin to work with udev rule Using special udev rules for special devices (in conjunction with the oFono auto-detection rule) make the process of setting up oFono for the system integrator a lot simpler. No manual configuration file patching anymore. Just installation of an additional udev rule. The open here is the ISI modem detection, but this should be clearly done via a Phonet plugin. And also the N900 specific case inside modemconf is just wrong. This needs to be fixed and just auto-detected via Phonet or maybe just via RTNL directly. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH resend 1/3] voicecall: Rename cb-function hangup to hangup_active in core and drivers.
Hi Sjur, On 08/09/2010 04:18 PM, Sjur Brændeland wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com --- drivers/atmodem/voicecall.c |4 ++-- drivers/calypsomodem/voicecall.c |2 +- drivers/hfpmodem/voicecall.c |2 +- drivers/isimodem/voicecall.c |2 +- drivers/stemodem/voicecall.c |2 +- include/voicecall.h |2 +- 6 files changed, 7 insertions(+), 7 deletions(-) I applied patch 1 and 2. For patch 3 I changed my mind and fixed it slightly differently (e.g. just always skipping WAITING calls). Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/3] stedriver: remove unsupported CAIF socket IOCTLs.
Hi Sjur, On 08/09/2010 04:29 PM, Sjur Brændeland wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com --- drivers/stemodem/gprs-context.c | 48 +- 1 files changed, 2 insertions(+), 46 deletions(-) This patch has been applied. Thanks. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/3] stedriver: Copy caif_socket.h from 2.6.36 release candidate.
Hi Sjur, On 08/09/2010 04:29 PM, Sjur Brændeland wrote: From: Sjur Brændeland sjur.brandel...@stericsson.com Copied include/linux/caif/caif_socket.h and added AF_CAIF, PF_CAIF and SOL_CAIF definitions found in linux/include/socket.h. --- drivers/stemodem/caif_socket.h | 207 1 files changed, 123 insertions(+), 84 deletions(-) This patch has been applied. Thanks. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Add EFest entry
Hi Yang, On 08/11/2010 06:00 AM, Yang Gu wrote: --- src/default.xml |4 1 files changed, 4 insertions(+), 0 deletions(-) This patch has been applied. Thanks. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/2] huawei: poll sim state
Hi Kalle,
On 08/10/2010 04:57 AM, Kalle Valo wrote:
On my Huawei E1552 when I plug in the modem (ie. cold start) with PIN locked
SIM, the sim state is 255 (HUAWEI_SIM_STATE_NOT_EXISTENT). As the modem
doesn't send ^SIMST notifications, poll the sim state until it's ready.
In theory it might be possible to do this better, for example follow
^BOOT notifications or something, but it's unknown what parameter we
should check for.
---
plugins/huawei.c | 34 ++
1 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/plugins/huawei.c b/plugins/huawei.c
index f8ada24..ba66513 100644
--- a/plugins/huawei.c
+++ b/plugins/huawei.c
@@ -73,8 +73,11 @@ struct huawei_data {
enum huawei_sim_state sim_state;
struct ofono_gprs *gprs;
struct ofono_gprs_context *gc;
+ guint query_sim_state;
};
+static gboolean query_sim_state(gpointer user_data);
+
static int huawei_probe(struct ofono_modem *modem)
{
struct huawei_data *data;
@@ -114,8 +117,15 @@ static void notify_sim_state(struct ofono_modem *modem,
{
struct huawei_data *data = ofono_modem_get_data(modem);
- if (sim_state == HUAWEI_SIM_STATE_NOT_EXISTENT)
+ DBG(%d, sim_state);
+
+ if (sim_state == HUAWEI_SIM_STATE_NOT_EXISTENT) {
ofono_sim_inserted_notify(data-sim, FALSE);
+
+ /* SIM is not ready, try again a bit later */
+ data-query_sim_state =
+ g_timeout_add_seconds(2, query_sim_state, modem);
+ }
Polling the sim state forever might not be a good idea if the SIM is not
inserted in the first place. You might want to give up after several
tries or so.
else
ofono_sim_inserted_notify(data-sim, TRUE);
@@ -154,6 +164,21 @@ static void sysinfo_cb(gboolean ok, GAtResult *result,
gpointer user_data)
notify_sim_state(modem, (enum huawei_sim_state) sim_state);
}
+static gboolean query_sim_state(gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+ struct huawei_data *data = ofono_modem_get_data(modem);
+
+ DBG();
+
+ data-query_sim_state = 0;
+
+ g_at_chat_send(data-pcui, AT^SYSINFO, sysinfo_prefix,
+ sysinfo_cb, modem, NULL);
+
+ return FALSE;
+}
+
static void simst_notify(GAtResult *result, gpointer user_data)
{
struct ofono_modem *modem = user_data;
@@ -187,9 +212,7 @@ static void cfun_enable(gboolean ok, GAtResult *result,
gpointer user_data)
g_at_chat_register(data-pcui, ^SIMST:, simst_notify,
FALSE, modem, NULL);
- /* query current sim state */
- g_at_chat_send(data-pcui, AT^SYSINFO, sysinfo_prefix,
- sysinfo_cb, modem, NULL);
+ query_sim_state(modem);
}
static GAtChat *create_port(const char *device)
@@ -319,6 +342,9 @@ static int huawei_disable(struct ofono_modem *modem)
DBG(%p, modem);
+ if (data-query_sim_state)
+ g_source_remove(data-query_sim_state);
+
if (data-modem) {
g_at_chat_cancel_all(data-modem);
g_at_chat_unregister_all(data-modem);
Otherwise patch looks good.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: maximum number of gsm 7 bit character in a concatenate sms message, supported by Ofono
Hi Alain, On 08/12/2010 08:13 AM, Kouassu, AlainX wrote: All, Could someone tell me the maximum number of characters in a concatenated sms message containing standard gsm 7 bit characters , I could send using ofono ? Please see unit/test-sms.c test_prepare_limits() for a comprehensive answer to your question. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Startup sequence for Online / offline mode
Modem drivers that support Online / offline mode default to offline when oFono loads them. Which component is responsible for calling oFono and switch the modem to online mode? Will that component be part of MeeGo? Cheers, Waldo -- Intel Corporation - Hillsboro, Oregon Ultra Mobility Group - Platform Software Architecture Tel: +1 503 264 6237 - Mobile: +1 503 703-7327 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 5/5] smsutil: save pending status reports to imsi file
Hi Petteri,
On 08/10/2010 11:25 AM, Tikander Petteri wrote:
Hi Denis,
I'm the guy, who already introduced shortly yesterday to Inaky, and I'm
continuing Pasi Miettinen's fine
work with SMS status-reports.
Good to have you aboard :)
So, here are some comments (included below) for updating status
report-functionality for your earlier comments,
how SR-functionality could be improved.
snip
General comment here is that you're duplicating much of the code that
inserts
the information into the data structure. You can play the same trick as
sms_assembly which uses a single function to do the heavy lifting,
but takes
an argument whether to store this info on disk. Obviously during
load you
don't want to re-save this information on disk. Then your load function
becomes much smaller and easier to understand.
OK. I agree that generally single function for heavy lifting is nicer
solution.
I will implement some general function, which handles adding of new id-table
(if not already added)
to assembly-table, and storing necessary node-information there. After that I
will move some functionality from
sr_assembly_load_backup() to this general function. Also this function can be
used when sending new sms-text message.
And I will add new parameter for telling, if this function will save data to
imsi-file on disk or not.
Existing sms-assembly handles it that way. But, one difference with
sms-assembly and status-report logic is, that
sms-assembly naturally stores every messages of concatenated, long
SMS-message to own backup files, but status report
gathers all information belonging to the same long SMS-message (using message
reference numbers) to the single file.
So Pasi implemented in the loading-phase (sr_assembly_load_backup) storing of
MR-numbers simply
by copying the whole buffer containing MR's belonging to the single
concatenated message-node:
1) memcpy(node-mrs, buf, sizeof(node-mrs));
And naturally when sending single message, single MR-bit is set up
('status_report_assembly_add_fragment()'):
2) node-mrs[offset] |= bit;
So, when now implementing new general function, one solution could be to
bring MR-string as parameter
so way (1) could be used in different cases.
Also I have to take care of variable 'sent_mrs', which will be incremented in
the sms-submit, but not in the loading phase.
I agree there are going to be differences. See how far you get trying
to unify these behind a single function and send for another round of
reviews.
snip
return ret;
}
+static gboolean sr_assembly_add_fragment_backup(const char *imsi,
+ const struct id_table_node *node,
+ unsigned int msg_id)
Lets be consistent with how sms assembly works. E.g. take the main
assembly
object and return void. Just helps to read the code when it is
consistent.
OK. Lets give main assembly to this (and corresponding) function(s).
How about return value? For instance existing sms assembly-function
'sms_assembly_add_fragment_backup()'
already returns something else than void.
sms_assembly_add_fragment_backup returns the new list of fragments.
What value can we return from this function? I think returning
TRUE/FALSE for file write failures are not worth it. There's not much
that can be done in that case anyway... So it seems void is good
enough, but feel free to suggest something.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: Startup sequence for Online / offline mode
Hi Waldo, On 08/12/2010 12:23 PM, Bastian, Waldo wrote: Modem drivers that support Online / offline mode default to offline when oFono loads them. Which component is responsible for calling oFono and switch the modem to online mode? Will that component be part of MeeGo? This feature is still highly experimental and not all of the details have been figured out (only ISI supports it today). Our current thinking is to have ConnMan manage the Online state of the GSM modems (e.g. replace Powered handling with Online handling.) However, we're still pretty far from that; we'd need to migrate all existing modem drivers to manage Online/Offline state properly first. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] atmodem/phonebook: parse text as hexstring
On Wed, Aug 11, 2010 at 03:53:36PM +0800, Gu, Yang wrote:
Hi,
Hello, Yang.
Thanks for the comments. I've done this patch in a rush (have done a
worse one before to test and import some data from a cell phone). Your
feedback is important so we can improve it and I can have some doubts
answered.
-Original Message-
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of
Thadeu Lima de Souza Cascardo
Sent: Monday, August 09, 2010 6:28 AM
To: ofono@ofono.org
Subject: [PATCH] atmodem/phonebook: parse text as hexstring
Some modems omit the quotes when dumping strings in UCS2. Parsing
them as hexstring already does the hex decoding and accepts missing
quotes.
Signed-off-by: Thadeu Lima de Souza Cascardo casca...@holoscopio.com
---
drivers/atmodem/phonebook.c | 139
--
1 files changed, 66 insertions(+), 73 deletions(-)
diff --git a/drivers/atmodem/phonebook.c b/drivers/atmodem/phonebook.c
index 5e7a52b..59fcbbc 100644
--- a/drivers/atmodem/phonebook.c
+++ b/drivers/atmodem/phonebook.c
@@ -59,16 +59,50 @@ struct pb_data {
GAtChat *chat;
};
-static char *ucs2_to_utf8(const char *str)
+static void warn_bad_text(const char *text)
{
-long len;
-unsigned char *ucs2;
+ofono_warn(Name field conversion to UTF8
+ failed, this can indicate a
+ problem with modem
+ integration, as this field
+ is required by 27.007.
+ Contents of name reported
+ by modem: %s, text);
+}
Why this warning is extracted as a function here?
In one of my versions of the patch, it was too much inlined and the
function was already too long. Since it's static, it will probably be
inlined. Should I just put it back in place of its only caller?
+
+static gboolean parse_text(GAtResultIter *iter, char **str, int encoding)
+{
+const char *string;
+const guint8 *hex;
+int len;
char *utf8;
-ucs2 = decode_hex(str, -1, len, 0);
-utf8 = g_convert((char *)ucs2, len, UTF-8//TRANSLIT, UCS-2BE,
-NULL, NULL, NULL);
-g_free(ucs2);
-return utf8;
+/* charset_current is either CHARSET_UCS2 or CHARSET_UTF8 */
Please help to add CHARSET_IRA here. I know the original code is not correct.
OK. Any pointers to any documentation about it? UCS2 support worked very
well for me. Some names had characters in the Latin1 range and it was no
problem.
+if (encoding == CHARSET_UCS2) {
+/* Some devices ommit the quotes, so use hexstring,
+ * which also decode to hex */
Misspell the omit here. We have guideline to write multiple line comments,
please refer doc/coding_style.txt and section M2.
Thanks. I will take a look and fix those.
+if (g_at_result_iter_next_hexstring(iter, hex, len))
+utf8 = g_convert((const gchar *)hex, len,
+UTF-8//TRANSLIT, UCS-2BE,
+NULL, NULL, NULL);
+else
+return FALSE;
Please insert a blank line here.
+if (utf8) {
+*str = utf8;
+return TRUE;
+} else {
+warn_bad_text(string);
We only report the warning when the field name (i.e., text) couldn't be
converted correctly, for it's a mandatory field. Otherwise, we don't issue
the warning.
I will add a gboolean mandatory parameter to the function. I've thought
about that, but now I have a pretty good line (mandatory), that's pretty
clear.
+return FALSE;
+}
+} else {
+/* In the case of IRA charset, assume these are Latin1
+ * characters, same as in UTF8
+ */
Same problem here for the multiple line comment
+if (g_at_result_iter_next_string(iter, string)) {
Could the device omit the quote here? If so, this function couldn't handle it
correctly either.
Not the device I have. This does not add a regression. If we find any
device that will omit the quote in this case, we may add the fix later.
For now, I am more confortable requiring the quote here and fixing it
for the cases we know some devices will omit it.
In any case, the UCS2 case was already expecting an hexstring, since it
was doing the conversion later. And the hexstring code allowed the
quotes to be omited. This is not the case here, where a string is
expected. I don't know about the IRA case.
+*str = g_strdup(string);
+return TRUE;
+}
+}
+return FALSE;
}
static const char *best_charset(int supported)
@@ -110,15 +144,15 @@ static void at_cpbr_notify(GAtResult *result, gpointer
user_data)
int index;
const char *number;
int type;
Re: Startup sequence for Online / offline mode
Hi Waldo, Modem drivers that support Online / offline mode default to offline when oFono loads them. Which component is responsible for calling oFono and switch the modem to online mode? Will that component be part of MeeGo? This feature is still highly experimental and not all of the details have been figured out (only ISI supports it today). Our current thinking is to have ConnMan manage the Online state of the GSM modems (e.g. replace Powered handling with Online handling.) However, we're still pretty far from that; we'd need to migrate all existing modem drivers to manage Online/Offline state properly first. I agree with Denis here. The Online state needs to be controlled by ConnMan, but we haven't done that change yet. It would break current users since we haven't migrated all modems to handle Online state properly or emulate it if needed. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Terminating emergency calls
Hi Sjur, On 08/12/2010 12:39 PM, Sjur Brændeland wrote: Hi Denis. I thought of one more issue with voice calls. I don't think it is safe to to terminate emergency calls using release_specific, AT+CHLD=1X. At least this don't work for STE modems. I suggest calls in state active should be terminated using hangup_all or hangup_active. What do you think? So in the case of a single call, the emergency call will be terminated using hangup_all / hangup_active anyway. I have relaxed the single call restriction for active calls when hangup_active is provided by the driver. Refer to c7b13ec2fe664b122216a312f2442c9ca26f5f43 For mpty calls this gets tricky. I'd like some answers to these questions: - Can Emergency calls participate in mpty? - Can Emergency calls be HELD? - How do we recognize Emergency calls? Is simple string matching of numbers in EmergencyNumbers of VoiceCallManager enough? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Startup sequence for Online / offline mode
Modem drivers that support Online / offline mode default to offline when oFono loads them. Which component is responsible for calling oFono and switch the modem to online mode? Will that component be part of MeeGo? This feature is still highly experimental and not all of the details have been figured out (only ISI supports it today). Our current thinking is to have ConnMan manage the Online state of the GSM modems (e.g. replace Powered handling with Online handling.) However, we're still pretty far from that; we'd need to migrate all existing modem drivers to manage Online/Offline state properly first. I agree with Denis here. The Online state needs to be controlled by ConnMan, but we haven't done that change yet. It would break current users since we haven't migrated all modems to handle Online state properly or emulate it if needed. My understanding was that the Online state would be initialized by a component like Telepathy-ring or some sort of system management daemon to ensure that the dialer is up and running and able to accept calls before the Online state is entered. If ConnMan initializes the Online state, how is it ensured that all required clients (Dialer, SMS, etc.) have registered already? Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Terminating emergency calls
Denis Kenzior denk...@gmail.com wrote: I thought of one more issue with voice calls. I don't think it is safe to to terminate emergency calls using release_specific, AT+CHLD=1X. At least this don't work for STE modems. I suggest calls in state active should be terminated using hangup_all or hangup_active. What do you think? So in the case of a single call, the emergency call will be terminated using hangup_all / hangup_active anyway. I have relaxed the single call restriction for active calls when hangup_active is provided by the driver. Refer to c7b13ec2fe664b122216a312f2442c9ca26f5f43 Yes, it seems to be ok for voicecall_hangup, but in manager_hangup_all the active call is still terminated with release_specific in voiceall_release_next. This implies that if you have an emergency call and terminate it with manager_hangup_all AT+CHLD=1X still will be used, right? I suggest we change voicecall_release_next like this: if (vc-driver-hangup_active != NULL (call-call-status == CALL_STATUS_ALERTING || call-call-status == CALL_STATUS_DIALING || + call-call-status == CALL_STATUS_ACTIVE || call-call-status == CALL_STATUS_INCOMING)) vc-driver-hangup_active(vc, multirelease_callback, vc); else vc-driver-release_specific(vc, call-call-id, multirelease_callback, vc); For mpty calls this gets tricky. I'd like some answers to these questions: - Can Emergency calls participate in mpty? I have to verify this with some of my colleagues, but I am pretty sure emergency calls cannot be applied to the AT+CHLD command. i.e. they cannot be part of mpty. Regards Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Startup sequence for Online / offline mode
Hi Waldo, Modem drivers that support Online / offline mode default to offline when oFono loads them. Which component is responsible for calling oFono and switch the modem to online mode? Will that component be part of MeeGo? This feature is still highly experimental and not all of the details have been figured out (only ISI supports it today). Our current thinking is to have ConnMan manage the Online state of the GSM modems (e.g. replace Powered handling with Online handling.) However, we're still pretty far from that; we'd need to migrate all existing modem drivers to manage Online/Offline state properly first. I agree with Denis here. The Online state needs to be controlled by ConnMan, but we haven't done that change yet. It would break current users since we haven't migrated all modems to handle Online state properly or emulate it if needed. My understanding was that the Online state would be initialized by a component like Telepathy-ring or some sort of system management daemon to ensure that the dialer is up and running and able to accept calls before the Online state is entered. If ConnMan initializes the Online state, how is it ensured that all required clients (Dialer, SMS, etc.) have registered already? ConnMan has control over the flight mode and thus is has control over the online state. If it happens that ConnMan switches the modem online and call gets received before the dialer is running, then it might time out in the end. And that is just fine with me. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/10] Unregister AT notifiers when removing drivers
Hi Marcel, Marcel Holtmann wrote: Hi Zhenhua, This series unregister AT notifiers in removing various AT modem drivers when modem goes to offline mode. Please review them. just a heads up here that Denis and I talked about this. And we are going to fix this inside GAtChat in the background for you. Trying to fix this single handed in every atom driver is wrong. This approach creates too much of a maintenance burden. And additional code complexity and memory footprint doing it this way. So we have to tackle it in a central place. And that is GAtChat. Thanks for update. Yes. The fix by Denis looks smart and make sense to me. By using fa?ade pattern, we don't require user to track register/unregister of AT notifers any more. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Regards, Zhenhua ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 10/16] gprs: Add ofono_gprs_create_context method
Hi Marcel, Marcel Holtmann wrote: Hi Zhenhua, DUN server may create one primary context if none of contexts existing on the GPRS atom. so Denis and I had a chat about this. And we agreed that oFono core should just create one Internet context if none exists. If the plugin driver registers a GPRS atom, we should just create one context anyway. ConnMan requires this anyway and it makes sense. We can also go one step ahead and fail to remove this default Internet context. It should be present all the time. Thanks for update. I will update my patch to keep this context alive after DUN client disconnect from us. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Regards, Zhenhua ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Terminating emergency calls
Hi Sjur, Sjur Br?ndeland wrote: Denis Kenzior denk...@gmail.com wrote: I thought of one more issue with voice calls. I don't think it is safe to to terminate emergency calls using release_specific, AT+CHLD=1X. At least this don't work for STE modems. I suggest calls in state active should be terminated using hangup_all or hangup_active. What do you think? So in the case of a single call, the emergency call will be terminated using hangup_all / hangup_active anyway. I have relaxed the single call restriction for active calls when hangup_active is provided by the driver. Refer to c7b13ec2fe664b122216a312f2442c9ca26f5f43 Yes, it seems to be ok for voicecall_hangup, but in manager_hangup_all the active call is still terminated with release_specific in voiceall_release_next. This implies that if you have an emergency call and terminate it with manager_hangup_all AT+CHLD=1X still will be used, right? I suggest we change voicecall_release_next like this: if (vc-driver-hangup_active != NULL (call-call-status == CALL_STATUS_ALERTING || call-call-status == CALL_STATUS_DIALING || + call-call-status == CALL_STATUS_ACTIVE || call-call-status == CALL_STATUS_INCOMING)) vc-driver-hangup_active(vc, multirelease_callback, vc); else vc-driver-release_specific(vc, call-call-id, multirelease_callback, vc); For mpty calls this gets tricky. I'd like some answers to these questions: - Can Emergency calls participate in mpty? I have to verify this with some of my colleagues, but I am pretty sure emergency calls cannot be applied to the AT+CHLD command. i.e. they cannot be part of mpty. If emergency calls cannot be part of mpty call, we can use either hangup_all or hangup_active as Denis said. However, your suggested fix will break multiparty call scenario since multiparty_hangup calls voicecall_release_next as well. Maybe we should use call-type to indicate whether it's an emergy call. It looks to me that the type flag in struct ofono_call hasn't been used yet. Correct me if I am wrong. Regards Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Regards, Zhenhua ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
light test report for oFono v0.26
Test Objective -- This is regular light testing for oFono upstream release. During this round of testing, we mainly focus on new feature testing to ensure new features work well and regression testing to ensure no big regression. Test Environment --- General PC: pre-installed FC12) oFono v0.26 Phonesim 1.4 Huawei E160G Modem, 1552 Modem UNICOM 3G sim card UNICOM WCDMA network env Test Coverage --- The testing is based on phonesimv1.4 and covered most of implemented features in v0.26 (Call history, SMS, Voice call, Multiparty call, Sim Phonebook, SS, Setting, GSM string, USSD, Modem, Voice mail, Networking, SIM file, Cell broadcast, Call volume, Message history, HFP, GPRS, Modem Emualtor) ppp and sms delivery report features testing are also included in this round of testing. Test Result Summary --- Total executed total 311 test cases during this round of testing, and among them: Pass:308 Fail: 3 Most functionalities work well. we reported 2 new bug and No regression is detected out. ppp: it works well. user can setup connection; disconnect the connection. website access and ftp upload/download work well. Sometimes oFono v0.25 will crash when disconnecting ppp, but the issue is fixed quickly in ofono v0.26 :-) Sms delivery report: most functionalities work well and more stable. User can enable/disable delivery report, get/set sms bearer, get delivery report after sending sms successfully. However, rp -error of sms is not tested for it is hard to test it in real network. Issue Summary --- New bugs: Bug 5193 - the attached status did not update after power off GPRS radio Bug 4081- Cannot get sms delivery status without international number Main Open bugs: Bug 8898 - spend long time on getting fail report of sms Bug 872 - Cannot deactivate all contexts Bug 5193 - the attached status did not update after power off GPRS radio Bug 5117- Crash when receiving unsolicited +CREG: 0 Bug 389 - 3G modem fail to work after disable/enable the 3G device in ConnMan Bug 5193 - the attached status did not update after power off GPRS radio Bug 4081- Cannot get sms delivery status without international number Bug 4001 - Segfault in ofono_modem_driver_unregister Bug 3971 - Cannot set Voice No reply timeout value in CF Bug 2078 - 3G network service sometimes fail to come out after swtich off/on 3G device Bug 868 - ussd notification display is incorrect with UCS2 character set Detailed Test Results: --- to make it more readable, we summarized by feature list. :-) Features checkpoints test results comments Call historyMissed call pass Outgoing call pass Incoming call pass Duration pass Datepass SMS Send/receivepass Class0, 1 pass Set service center address pass More segments pass Different character set pass Voice call Dial pass Accept pass Reject pass Hold pass Retrieve pass Release pass ECT pass Multiparty call Create pass Hang up pass Private chatpass Hold
