[PATCH v3 4/4] cf: Handle send ss proactive command
---
src/call-forwarding.c | 262 +---
src/ofono.h | 28 +
src/stk.c | 130
src/ussd.c| 145 +++
4 files changed, 548 insertions(+), 17 deletions(-)
diff --git a/src/call-forwarding.c b/src/call-forwarding.c
index fd05d38..9384bff 100644
--- a/src/call-forwarding.c
+++ b/src/call-forwarding.c
@@ -55,11 +55,14 @@ struct ofono_call_forwarding {
GSList *cf_conditions[4];
int flags;
DBusMessage *pending;
+ struct ofono_ss_request *req;
int query_next;
int query_end;
struct cf_ss_request *ss_req;
struct ofono_ussd *ussd;
+ struct ofono_stk *stk;
unsigned int ussd_watch;
+ unsigned int stk_watch;
const struct ofono_call_forwarding_driver *driver;
void *driver_data;
struct ofono_atom *atom;
@@ -68,6 +71,7 @@ struct ofono_call_forwarding {
static void get_query_next_cf_cond(struct ofono_call_forwarding *cf);
static void set_query_next_cf_cond(struct ofono_call_forwarding *cf);
static void ss_set_query_next_cf_cond(struct ofono_call_forwarding *cf);
+static void ss_set_query_next_cf_cond_stk(struct ofono_call_forwarding *cf);
static void cf_unregister_ss_controls(struct ofono_call_forwarding *cf);
struct cf_ss_request {
@@ -77,6 +81,27 @@ struct cf_ss_request {
GSList *cf_list[4];
};
+static void request_finish_stk(struct ofono_call_forwarding *cf,
+ const struct ofono_error *error)
+{
+ struct ofono_ss_request *req = cf-req;
+
+ if (req req-cb)
+ req-cb(error, req-user_data);
+
+ cf-req = NULL;
+}
+
+static void request_cancel_stk(void *ss)
+{
+ struct ofono_call_forwarding *cf = ss;
+
+ if (!cf-req || !cf-req-cb)
+ return;
+
+ cf-req = NULL;
+}
+
static gint cf_condition_compare(gconstpointer a, gconstpointer b)
{
const struct ofono_call_forwarding_condition *ca = a;
@@ -860,12 +885,52 @@ static void ss_set_query_cf_callback(const struct
ofono_error *error, int total,
}
}
+static void ss_set_query_cf_cb_stk(const struct ofono_error *error, int total,
+ const struct ofono_call_forwarding_condition *list,
+ void *data)
+{
+ struct ofono_call_forwarding *cf = data;
+ GSList *l;
+
+ if (error-type != OFONO_ERROR_TYPE_NO_ERROR) {
+ ofono_error(Setting succeeded, but query failed);
+ cf-flags = ~CALL_FORWARDING_FLAG_CACHED;
+ request_finish_stk(cf, error);
+ return;
+ }
+
+ l = cf_cond_list_create(total, list);
+ DBG(%s conditions:, cf_type_lut[cf-query_next]);
+ cf_cond_list_print(l);
+
+ cf-ss_req-cf_list[cf-query_next] = l;
+
+ if (cf-query_next == cf-query_end) {
+ request_finish_stk(cf, error);
+ g_free(cf-ss_req);
+ cf-ss_req = NULL;
+ }
+
+ set_new_cond_list(cf, cf-query_next, l);
+
+ if (cf-query_next != cf-query_end) {
+ cf-query_next++;
+ ss_set_query_next_cf_cond_stk(cf);
+ }
+}
+
static void ss_set_query_next_cf_cond(struct ofono_call_forwarding *cf)
{
cf-driver-query(cf, cf-query_next, BEARER_CLASS_DEFAULT,
ss_set_query_cf_callback, cf);
}
+static void ss_set_query_next_cf_cond_stk(struct ofono_call_forwarding *cf)
+{
+ cf-driver-query(cf, cf-query_next, BEARER_CLASS_DEFAULT,
+ ss_set_query_cf_cb_stk, cf);
+}
+
static void cf_ss_control_callback(const struct ofono_error *error, void *data)
{
struct ofono_call_forwarding *cf = data;
@@ -883,16 +948,31 @@ static void cf_ss_control_callback(const struct
ofono_error *error, void *data)
ss_set_query_next_cf_cond(cf);
}
-static int cf_ss_control(int type, const char *sc,
- const char *sia, const char *sib,
- const char *sic, const char *dn,
- DBusMessage *msg, void *data)
+static void cf_ss_control_cb_stk(const struct ofono_error *error, void *data)
{
struct ofono_call_forwarding *cf = data;
+
+ if (error-type != OFONO_ERROR_TYPE_NO_ERROR) {
+ DBG(Error occurred during cf ss control set/erasure);
+
+ request_finish_stk(cf, error);
+
+ g_free(cf-ss_req);
+ cf-ss_req = NULL;
+ return;
+ }
+
+ ss_set_query_next_cf_cond_stk(cf);
+}
+
+static int parse_ss_control(struct ofono_call_forwarding *cf, int type,
+ const char *sc, const char *sia,
+ const char *sib, const char *sic,
+ const char *dn)
+{
int cls = BEARER_CLASS_SS_DEFAULT;
int timeout = DEFAULT_NO_REPLY_TIMEOUT;
[PATCH v3 1/4] Add macro for general result and additional info
---
src/stkutil.h | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/stkutil.h b/src/stkutil.h
index 2d98185..5c75524 100644
--- a/src/stkutil.h
+++ b/src/stkutil.h
@@ -254,6 +254,8 @@ enum stk_result_type {
STK_RESULT_TYPE_COMMAND_NOT_UNDERSTOOD =0x31,
STK_RESULT_TYPE_DATA_NOT_UNDERSTOOD = 0x32,
STK_RESULT_TYPE_COMMAND_ID_UNKNOWN =0x33,
+ STK_RESULT_TYPE_SS_RETURN_ERROR = 0x34,
+ STK_RESULT_TYPE_SMS_RP_ERROR = 0x35,
STK_RESULT_TYPE_MINIMUM_NOT_MET = 0x36,
STK_RESULT_TYPE_USSD_RETURN_ERROR = 0x37,
STK_RESULT_TYPE_CALL_CONTROL_PERMANENT =0x39,
@@ -263,6 +265,26 @@ enum stk_result_type {
STK_RESULT_TYPE_MMS_ERROR = 0x3D,
};
+/* Defined according to TS 102.223 Section 8.12.2 */
+enum stk_result_addnl_me_pb {
+ STK_RESULT_ADDNL_ME_PB_NO_SPECIFIC_CAUSE = 0x00,
+ STK_RESULT_ADDNL_ME_PB_SCREEN_BUSY =0x01,
+ STK_RESULT_ADDNL_ME_PB_BUSY_ON_CALL = 0x02,
+ STK_RESULT_ADDNL_ME_PB_SS_BUSY =0x03,
+ STK_RESULT_ADDNL_ME_PB_NO_SERVICE = 0x04,
+ STK_RESULT_ADDNL_ME_PB_NO_ACCESS = 0x05,
+ STK_RESULT_ADDNL_ME_PB_NO_RADIO_RESOURCE = 0x06,
+ STK_RESULT_ADDNL_ME_PB_NOT_IN_SPEECH_CALL = 0x07,
+ STK_RESULT_ADDNL_ME_PB_USSD_BUSY = 0x08,
+ STK_RESULT_ADDNL_ME_PB_BUSY_ON_SEND_DTMF = 0x09,
+ STK_RESULT_ADDNL_ME_PB_NO_NAA_ACTIVE = 0x0A
+};
+
+/* Defined according to TS 31.111 Section 8.12.4 */
+enum stk_result_addnl_ss_pb {
+ STK_RESULT_ADDNL_SS_PB_NO_SPECIFIC_CAUSE = 0x00
+};
+
enum stk_tone_type {
STK_TONE_TYPE_DIAL_TONE = 0x01,
STK_TONE_TYPE_BUSY_TONE = 0x02,
--
1.7.2.3
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH v3 2/4] stk: Support send ss response
--- src/stkutil.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/stkutil.c b/src/stkutil.c index 82da079..cdd66bd 100644 --- a/src/stkutil.c +++ b/src/stkutil.c @@ -5455,6 +5455,8 @@ const unsigned char *stk_pdu_from_response(const struct stk_response *response, response-select_item.item_id, NULL); break; + case STK_COMMAND_TYPE_SEND_SS: + break; case STK_COMMAND_TYPE_SETUP_CALL: ok = build_setup_call(builder, response); break; -- 1.7.2.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v3 3/4] ss: Use errno for ssc handling functions
---
src/call-barring.c| 63 ++--
src/call-forwarding.c | 63 +---
src/call-settings.c | 34 --
src/ussd.c| 55 --
4 files changed, 88 insertions(+), 127 deletions(-)
diff --git a/src/call-barring.c b/src/call-barring.c
index f89602e..04d9bab 100644
--- a/src/call-barring.c
+++ b/src/call-barring.c
@@ -359,25 +359,19 @@ static const char *cb_ss_service_to_fac(const char *svc)
return NULL;
}
-static gboolean cb_ss_control(int type, const char *sc,
+static int cb_ss_control(int type, const char *sc,
const char *sia, const char *sib,
const char *sic, const char *dn,
DBusMessage *msg, void *data)
{
struct ofono_call_barring *cb = data;
- DBusConnection *conn = ofono_dbus_get_connection();
int cls = BEARER_CLASS_DEFAULT;
const char *fac;
- DBusMessage *reply;
void *operation = NULL;
int i;
- if (__ofono_call_barring_is_busy(cb)) {
- reply = __ofono_error_busy(msg);
- g_dbus_send_message(conn, reply);
-
- return TRUE;
- }
+ if (__ofono_call_barring_is_busy(cb))
+ return -EBUSY;
DBG(Received call barring ss control request);
@@ -386,7 +380,7 @@ static gboolean cb_ss_control(int type, const char *sc,
fac = cb_ss_service_to_fac(sc);
if (!fac)
- return FALSE;
+ return -ENOENT;
cb_set_query_bounds(cb, fac, type == SS_CONTROL_TYPE_QUERY);
@@ -397,13 +391,13 @@ static gboolean cb_ss_control(int type, const char *sc,
cb-ss_req_lock = i;
if (strlen(sic) 0)
- goto bad_format;
+ return -EINVAL;
if (strlen(dn) 0)
- goto bad_format;
+ return -EINVAL;
if (type != SS_CONTROL_TYPE_QUERY !is_valid_pin(sia, PIN_TYPE_NET))
- goto bad_format;
+ return -EINVAL;
switch (type) {
case SS_CONTROL_TYPE_ACTIVATION:
@@ -419,12 +413,8 @@ static gboolean cb_ss_control(int type, const char *sc,
break;
}
- if (!operation) {
- reply = __ofono_error_not_implemented(msg);
- g_dbus_send_message(conn, reply);
-
- return TRUE;
- }
+ if (!operation)
+ return -ENOSYS;
/*
* According to 27.007, AG, AC and AB only work with mode = 0
@@ -434,7 +424,7 @@ static gboolean cb_ss_control(int type, const char *sc,
if ((!strcmp(fac, AG) || !strcmp(fac, AC) || !strcmp(fac, AB))
(type == SS_CONTROL_TYPE_ACTIVATION ||
type == SS_CONTROL_TYPE_REGISTRATION))
- goto bad_format;
+ return -EINVAL;
if (strlen(sib) 0) {
long service_code;
@@ -443,12 +433,12 @@ static gboolean cb_ss_control(int type, const char *sc,
service_code = strtoul(sib, end, 10);
if (end == sib || *end != '\0')
- goto bad_format;
+ return -EINVAL;
cls = mmi_service_code_to_bearer_class(service_code);
if (cls == 0)
- goto bad_format;
+ return -EINVAL;
}
cb-ss_req_cls = cls;
@@ -473,12 +463,7 @@ static gboolean cb_ss_control(int type, const char *sc,
break;
}
- return TRUE;
-
-bad_format:
- reply = __ofono_error_invalid_format(msg);
- g_dbus_send_message(conn, reply);
- return TRUE;
+ return 0;
}
static void cb_set_passwd_callback(const struct ofono_error *error, void *data)
@@ -496,21 +481,15 @@ static void cb_set_passwd_callback(const struct
ofono_error *error, void *data)
__ofono_dbus_pending_reply(cb-pending, reply);
}
-static gboolean cb_ss_passwd(const char *sc,
+static int cb_ss_passwd(const char *sc,
const char *old, const char *new,
DBusMessage *msg, void *data)
{
struct ofono_call_barring *cb = data;
- DBusConnection *conn = ofono_dbus_get_connection();
- DBusMessage *reply;
const char *fac;
- if (__ofono_call_barring_is_busy(cb)) {
- reply = __ofono_error_busy(msg);
- g_dbus_send_message(conn, reply);
-
- return TRUE;
- }
+ if (__ofono_call_barring_is_busy(cb))
+ return -EBUSY;
DBG(Received call barring ss password change request);
@@ -522,19 +501,15 @@ static gboolean cb_ss_passwd(const char *sc,
fac = cb_ss_service_to_fac(sc);
if (!fac)
- return FALSE;
+ return -ENOENT;
Re: huawei e1550
В Срд, 13/10/2010 в 16:54 +0400, Alexander A Khryukin пишет: В Срд, 13/10/2010 в 15:14 +0300, Kalle Valo пишет: Alexander A Khryukin alexan...@mezon.ru writes: Sorry, I wasn't able to immeadiately say from the logs what went wrong. Can you get a log which includes AT commands? It would help a lot. Just run this command to get the logs: OFONO_AT_DEBUG=1 /usr/sbin/ofonod -n What's the exact version of ofono you are using? Huawei has had some changes lately. Also is the SIM configured to ask for PIN or not? I'm guessing no from the log, but can't be sure. Ok.I connect modem to usb-port, and log it OFONO_AT_DEBUG=1 /usr/sbin/ofonod -n Sorry, I forgot -d switch from the command which enables the debug messages. So it should be like this: OFONO_AT_DEBUG=1 /usr/sbin/ofonod -n -d http://pastie.org/1212535 I didn't immeadiately find anything wrong in the AT logs. So basically your modem disappers from the bus and then comes back. Can a firmware crash cause that? The last commands were: ofonod[838]: PCUI: AT+CSCB=1\r ofonod[838]: PCUI: \r\nOK\r\n ofonod[838]: PCUI: AT+CSCB=0,4096,4097,4098,4099,4100,4101,4102,4103,4104,4105,4106,4107,4108,4109,4110,4111,4352-4356\r Can you try the patch below? Maybe it gives us some hint what's happening. diff --git a/plugins/huawei.c b/plugins/huawei.c index b20d83c..13ef192 100644 --- a/plugins/huawei.c +++ b/plugins/huawei.c @@ -624,8 +624,6 @@ static void huawei_post_online(struct ofono_modem *modem) data-pcui); ofono_sms_create(modem, OFONO_VENDOR_HUAWEI, atmodem, data-pcui); - ofono_cbs_create(modem, OFONO_VENDOR_QUALCOMM_MSM, - atmodem, data-pcui); ofono_ussd_create(modem, OFONO_VENDOR_QUALCOMM_MSM, atmodem, data-pcui); git apply --stat p.patch Working =) Now compile. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono bump ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[RFC sim-ready-v1 PATCH 0/3] ofono_sim_ready_notify
Hi all, Here is my 2nd stab at the ofono_sim_ready_notify(). Main difference from Denis's and Kristen's patch is that the modem driver now has a way to indicate that is ready or not: if SIM is not ready, the ofono_sim_driver indicates that with query_passwd_state callback returning OFONO_SIM_PASSWORD_INVALID. A separate enum and a string value for PinRequired property for that case would probably be nice, however, it is not very clear to me how the modems handle the transition from PIN-locked SIM to SIM-locked modem. After the driver determines that the SIM is ready, it calls ofono_sim_ready_notify(). The patches has now been tested with the PIN and PUK codes with mbm and the new isimodem sim driver by Jukka Saunamaki. IFX seems to be identical in PIN and PUK cases, too. The isimodem driver demonstrates also the case where PIN is disabled but SIM is not ready yet when oFono tries to initialize the modem. The isimodem driver tries to read some CPHS information in order to determine if the modem is ready. I'm not sure how that kind of probing should be implemented in atmodem driver. --Pekka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[RFC sim-ready-v1 PATCH 1/3] sim: add ofono_sim_ready_notify
From: Pekka Pessi pekka.pe...@nokia.com
If SIM is not ready, the ofono_sim_driver indicates that with
query_passwd_state callback returning OFONO_SIM_PASSWORD_INVALID.
After the driver determines that SIM is ready, it calls
ofono_sim_ready_notify().
Based on patches by Kristen Accardi and Denis Kenzior.
---
include/sim.h |2 ++
src/sim.c | 26 ++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/include/sim.h b/include/sim.h
index 7860e24..f4171d1 100644
--- a/include/sim.h
+++ b/include/sim.h
@@ -188,6 +188,8 @@ enum ofono_sim_state ofono_sim_get_state(struct ofono_sim
*sim);
void ofono_sim_inserted_notify(struct ofono_sim *sim, ofono_bool_t inserted);
+void ofono_sim_ready_notify(struct ofono_sim *sim);
+
/* This will queue an operation to read all available records with id from the
* SIM. Callback cb will be called every time a record has been read, or once
* if an error has occurred. For transparent files, the callback will only
diff --git a/src/sim.c b/src/sim.c
index 695562f..b0462c8 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -86,6 +86,8 @@ struct ofono_sim {
unsigned char *efimg;
unsigned short efimg_length;
+ gboolean waiting_ready;
+
enum ofono_sim_state state;
struct ofono_watchlist *state_watches;
@@ -1407,6 +1409,14 @@ static void sim_pin_query_cb(const struct ofono_error
*error,
goto checkdone;
}
+ if (pin_type == OFONO_SIM_PASSWORD_INVALID) {
+ DBG(Waiting for ready notification);
+
+ sim-waiting_ready = TRUE;
+
+ return;
+ }
+
if (sim-pin_type != pin_type) {
sim-pin_type = pin_type;
pin_name = sim_passwd_name(pin_type);
@@ -1431,6 +1441,8 @@ checkdone:
static void sim_pin_check(struct ofono_sim *sim)
{
+ sim-waiting_ready = FALSE;
+
if (!sim-driver-query_passwd_state) {
sim_initialize_after_pin(sim);
return;
@@ -1439,6 +1451,20 @@ static void sim_pin_check(struct ofono_sim *sim)
sim-driver-query_passwd_state(sim, sim_pin_query_cb, sim);
}
+void ofono_sim_ready_notify(struct ofono_sim *sim)
+{
+ DBG();
+
+ if (sim == NULL)
+ return;
+
+ if (sim-state != OFONO_SIM_STATE_INSERTED)
+ return;
+
+ if (sim-waiting_ready)
+ sim_pin_check(sim);
+}
+
static void sim_efli_read_cb(int ok, int length, int record,
const unsigned char *data,
int record_length, void *userdata)
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/5] stk: Support send ss response
Hi, On 18 October 2010 10:04, Gu, Yang yang...@intel.com wrote: I couldn't understand this comment well. Additional information is a part of result dataobj, so it's already included. Is there something I should handle further? It seems correct to me, the result dataobj is added just before the switch(). Best regards ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Call Barring and MMI Supplementary Service codes
Hi Rajesh, On 10/15/2010 04:03 PM, rajesh.naga...@elektrobit.com wrote: Hi Fred, As per the 3GPP 22.030 Annex C: - the MMI Service Code 22 refers to All sync services telecommunication service. - the MMI Service Code 24 refers to All data circuit sync telecommunication service. They are both linked to the same Basic Group Service 8. So as per our understanding, this means the All sync services is equal to All data circuit sync. Is that everyone's comprehension as well? Yes No. Previously (Before Rel99, Refer GSM 02.02 and GSM 02.30) we had the the bearer services All dedicated PAD access (BSG Number 9, MMI 27) and All dedicated packet access (BSG Number 10, MMI 26). In this All dedicated PAD access is an asynchronous connection and All dedicated packet access is a synchronous connection. So All Sync Services used to be = All data circuit sync + All dedicated packet access Now that bearer service All dedicated packet access is not supported, All Sync Services = only All data circuit sync When we try to run Call Barring certification tests (particularly 31.8.3.1 from 3GPP 51.010), the spec requires us to activate the call barring with the MMI code 22. We do it using org.ofono.SupplementaryServices.Initiate with the following string *33*1234*22# (This is the activation of BAOC with password 1234 on All Sync Services), Ofono then sends to the modem the following AT command: AT+CLCK= AO,1,1234,16 According to the 3GPP 27.007 §7.4 (CLCK), 16 is data circuit sync. So modem will translate that into all data circuit sync in the REGISTER message sent to the network simulator. However according to 3GPP 51.010 31.8.3.1, only a REGISTER message containing All synchronous services is awaited. So conformance scripts will consider the test as FAILED. We noticed the test would be PASS only if CLCK classx parameter was 80 (instead of 16). 80 = 16 (data circuit sync) + 64 (dedicated packet access). As the AT command specification 27.007 still has values for dedicated packet access (64) and dedicated PAD access (128), in the AT modem case for All Sync Services we have to translate to All data circuit sync (16) + All dedicated packet access (64) not only to All data circuit sync (16), otherwise as you pointed out the corresponding conformance test case will fail. Thats the reason the test case passes when you pass 80. My interpretation of 22.004 and 22.030 was that dedicated packet access and dedicated PAD access were deprecated and no longer being used. The fact that they're still listed in 27.007 seems to be irrelevant. One possibility is that the bearer services covered by dedicated packet dedicated pad access were lumped together with bearer services 20 and 30 from 3GPP 22.002. Shouldn't we translate the *33*1234*22# MMI SS String into AT+CLCK=AO,1,1234,80 ? From my understanding YES. I actually am fine making this change, and it is quite trivial to boot. But before we do that, can we confirm that this is indeed mandated by the specs, and not an error in the test cases. What values are expected from MMI services 25, 24 and 26? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: CDMA SMS Handling
Hi Rajesh, Doing it the way I suggested would keep the impact on the current code base absolutely minimal. This way you can start submitting patches right away for CDMA support without impacting anyone. Once the CDMA aspects are stabilized and we're happy with them we can do the final struct / API refactoring as needed. Thoughts? Yes, i agree doing this way would have minimal impact to the current code base. But from refactoring prespective the effort will be double if we do the refactoring at the later stage, as now we need to refactor only the GSM code and later we have to refactor both GSM and CDMA code. I understand your concern, but I think the changes required are simply too invasive at this point. There's also the possibility that after doing all the work for CDMA we might find that it is incompatible with the rest of smsutil. I prefer not to take this risk right now. Besides, I think you will find that transforming the data structures from my proposal to your original proposal at a later date will not be that much work. If we have proper unit tests in place it should take no more than an afternoon... Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/5] stk: Support send ss response
Hi Andrew/Yang, On 10/18/2010 12:30 PM, andrzej zaborowski wrote: Hi, On 18 October 2010 10:04, Gu, Yang yang...@intel.com wrote: I couldn't understand this comment well. Additional information is a part of result dataobj, so it's already included. Is there something I should handle further? It seems correct to me, the result dataobj is added just before the switch(). Yes you guys are right, for some reason I thought additional info was a separate object. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Identification of Active Application in UICC card
Hi, According to 3GPP specification 3GPP TS 31.102 section 5.1.1 USIM application selection, After UICC activation, the ME selects a USIM application. If no EFDIR file is found or no USIM applications are listed in the EFDIR file, the ME may then try to select the GSM application as specified in TS 51.011. If EFdir is present and if AID present is matching with the USIM AID(RID = A00087, Application Code = 1002), then the selected/active application is 3G USIM. If EFdir is not present or the AID present is matching with the SIM AID(RID = A9, ETSI application code = 0001), then the selected/active application is GSM. Information on the AID and RID can be found in the specification 3GPP TS 31.110. RID - Registered application provider identifier AID - Application Identifier Since almost all the cards nowdays are UICC cards and EFdir is also a mandatory file, can we rely on the EFdir to confirm the active application? This way, we can avoid reading of files which are not present in the active application and also we can avoid issuing of multiple read requests for the same file(eg: EFecc) Thanks and Regards, jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Call Barring and MMI Supplementary Service codes
Hi Denis, My interpretation of 22.004 and 22.030 was that dedicated packet access and dedicated PAD access were deprecated and no longer being used. The fact that they're still listed in 27.007 seems to be irrelevant. As dedicated packet access and dedicated PAD access is mentioned in 27.007, the AT modems still consider these values while translating the corresponding Basic Service group. Thats the reason when sending 16 the AT modem translates it to All data circuit sync and 80 to All Sync services in REGISTER message(Fred can you confirm this ?). In case of message based modems, we have seperate MMI for All Sync services and All data circuit sync services and as MMI's for dedicated packet access and dedicated PAD access are deprecated the translation happens without conflict. One possibility is that the bearer services covered by dedicated packet dedicated pad access were lumped together with bearer services 20 and 30 from 3GPP 22.002. I think the dedicated packet access and dedicated PAD access bearers are deprecated, not grouped with BS 20 and 30. Shouldn't we translate the *33*1234*22# MMI SS String into AT+CLCK=AO,1,1234,80 ? From my understanding YES. I actually am fine making this change, and it is quite trivial to boot. But before we do that, can we confirm that this is indeed mandated by the specs, and not an error in the test cases. There is no error in the corresponding test cases. What values are expected from MMI services 25, 24 and 26? For MMI 22 (All Sync Services)= 80 (All data circuit sync (16) + All dedicated packet access (64)) For MMI 21 (All Async Services)= 160 (All data circuit async (32) + All dedicated PAD access (128)). For MMI 26 (Telephony and All sync services)= 81 (Telephony (1) + All data circuit sync (16) + All dedicated packet access (64)) For MMI 24 (All data circuit sync)= 16 (All data circuit sync) For MMI 25 (All data circuit async)= 32 (All data circuit async) Fred, can you modify the values for MMI 22, 21 and 26 as above and confirm from the test result whether our understanding is correct or not ? BR, Rajesh ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
