Hi Bertrand,
ofono-boun...@ofono.org wrote:
> Hi Jeevaka,
>
> One 'minor bug', I guess that there is a missing 'Post SIM
> and Post online atoms are not created.' For case 2.
>
Good catch.
> And one question. For case 2 and 3, the 'Modem remains in
> online mode but the functionalities will b
Hi Christophe,
> Hi,
>
> I need to map ofono_sim_password_type according to h24 AT
command manual.
>
> Can somebody check if I mapped correctly enum with documentation
definition.
>
> OFONO_SIM_PASSWORD_SIM_PIN : PIN attempts
>
> OFONO_SIM_PASSWORD_SIM_PUK,
Hi Marcel,
ofono-boun...@ofono.org wrote:
> Hi Jeevaka,
>
>> Following patch is a proposal for emergency mode. Test has been
>> done with the phonesim.
>>
>> Listed down few important cases to give an overview of the state
>> changes that happen in each case.
>
> and I think we should turn th
Hi Denis,
Denis Kenzior wrote:
> Hi Jeevaka,
>
>> void emit_en_list_changed(struct ofono_voicecall *vc) static void
>> set_new_ecc(struct ofono_voicecall *vc) {
>> int i = 0;
>> +GSList *l;
>>
>> g_slist_foreach(vc->en_list, (GFunc) g_free, NULL);
>> g_slist_free(vc->en_list); @
Hi Andrew,
Andrzej Zaborowski wrote:
> Hi Jeevaka
>
> On 7 March 2011 16:35, Jeevaka Badrappan
> wrote:
>> As per the specification, if alphad identifier is provided and is a
>> null data object, no information should be given to the user.
>
> What do do you think of the following change?
>
>
Hi Andrew,
ofono-boun...@ofono.org wrote:
> Hi Jeevaka,
>
> On 7 March 2011 16:35, Jeevaka Badrappan
> wrote:
>> ---
>> src/stkutil.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/src/stkutil.c b/src/stkutil.c index abd1c99..66b2924
>> 100644 --- a/src/stkut
Hi Marcel,
ofono-boun...@ofono.org wrote:
> Hi Antti,
>
>> drivers/atmodem/network-registration.c |2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/atmodem/network-registration.c
>> b/drivers/atmodem/network-registration.c
>> index 4913611..2d589f0 100644
Hi Aki,
ofono-boun...@ofono.org wrote:
> Hi Jeevaka,
>
> On Tue, 2011-03-08 at 12:35 +0200, ext
> jeevaka.badrap...@elektrobit.com
> wrote:
>> This log is taken some time back. Possible that Network Daylight
>> Saving Time is received as part of the MM information message whereas
>> it may not be
Hi Antti,
ofono-boun...@ofono.org wrote:
> Hi Jeevaka,
>
> On Tue, 2011-03-08 at 10:59 +0200, ext
> jeevaka.badrap...@elektrobit.com
> wrote:
>> Hi Antti,
>>
>> ofono-boun...@ofono.org wrote:
>>> ---
>>> drivers/atmodem/network-registration.c |2 ++
>>> 1 files changed, 2 insertions(+), 0 d
Hi Antti,
ofono-boun...@ofono.org wrote:
> ---
> drivers/atmodem/network-registration.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/atmodem/network-registration.c
> b/drivers/atmodem/network-registration.c
> index 4913611..2d589f0 100644
> --- a/drivers
Hi Rajesh,
ofono-boun...@ofono.org wrote:
> Hi Jeeva,
>
> Is this WarningType really required on the App side ?
> Irrespective of the warning type, the emergency broadcast
> message handling won't change on the apps side (i.e, its
> going to be displayed immediately to the user). This can be
> ac
Hi Amit,
ofono-boun...@ofono.org wrote:
> Hi Amit,
>
> On 02/09/2011 10:56 AM, Amit Mendapara wrote:
>> Hi Danis,
>>
>> I have submitted three patches as you suggested but no one has
>> reviewed it. Would you tell me what else I can do to ensure it's
>> been integrated in ofono?
>>
>
> So it
Hi Denis,
Denis Kenzior wrote:
>
> So if you really insist on creating the call with a
> particular id, you might as well make that a parameter of the
> create_call function. However, do note that you still have one
> potential problem.
> If the ATD callback returns before the call is signaled,
Hi all,
Badrappan Jeevaka wrote:
> ---
> drivers/ifxmodem/voicecall.c | 197
> +++---
> 1 files changed, 90 insertions(+), 107 deletions(-)
>
Ignore this patch.
Regards,
Jeevaka
___
ofono mailing list
ofono@ofono.
Hi Antti,
ofono-boun...@ofono.org wrote:
> ---
> doc/network-time-api.txt | 36
> 1 files changed, 36 insertions(+), 0 deletions(-) create
> mode 100644 doc/network-time-api.txt
>
> diff --git a/doc/network-time-api.txt
> b/doc/network-time-api.txt new fil
ofono-boun...@ofono.org wrote:
> On Tuesday 01 February 2011 13:44:03 ext Jeevaka Badrappan, you wrote:
>> Hi,
>>
>> Following patch converts the DST from hours to seconds which is the
>> expected outcome.
>
> Is it? I think DST is just a boolean.
Refere 3GPP TS 24.008 section 10.5.3.12
Regard
Hi Sjur,
ofono-boun...@ofono.org wrote:
>
> - SIM identities used for IMS registration such as:
> PrivateImsIdentity, PublicImsIdentity, HomeDomainName.
Correct me if I'm wrong. Private Identity is the one used for registration,
authorisation, administration and billing purposes whereas the P
Hi Lasse,
ofono-boun...@ofono.org wrote:
> Hi
>
> I am checking what is the level of SAT/STK support in ofono
> and have a couple of questions. The current implementation
> contains support for basic STK commands, like menus, inputs,
> calls, sms and so on. In TODO, there is only REFRESH command
Hi Andrzej,
ofono-boun...@ofono.org wrote:
> +static void at_discover_apps_cb(gboolean ok, GAtResult *result,
> + gpointer user_data) +{
> + struct cb_data *cbd = user_data;
> + GAtResultIter iter;
> + ofono_sim_list_apps_cb_t cb = cbd->cb;
> + struct of
Hi Lucas,
Lucas De Marchi wrote:
> this happens to work for -1, but bear in mind memset "fills
> the first n bytes of the memory area". Considering
> sizeof(int) == 4, it will set each byte to -1, which happens
> to be -1 considering all 4 bytes too. But imo this is just
> being lucky.
>
> In my
Hi Marcel,
ofono-boun...@ofono.org wrote:
> Hi Jeevaka,
>
>> plugins/ifx.c |2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/plugins/ifx.c b/plugins/ifx.c index c0a69c2..08b0001
>> 100644 --- a/plugins/ifx.c
>> +++ b/plugins/ifx.c
>> @@ -57,6 +57,7 @@
>> #includ
Hi,
>>
>> So a question about this. Why are we checking the netreg atom?
>> Shouldn't we be checking the gprs atom's attached property? But this
>> brings up an even more interesting question, do we even need to
>> assume that we have to be attached to the cellular network to
>> perform these o
Hi Kai Vehmanen,
ofono-boun...@ofono.org wrote:
> not later, but as part of standard call setup. E.g. on ISI,
> CTM is a property of a voice call. And this makes sense as
> TTY calls _are_ essentially voice calls, with just a bit
> indicating to the network that the voice circuit should be
> free
Hi Marcel,
ofono-boun...@ofono.org wrote:
>> Main reason for separate notification function is to avoid going
>> through all the cases handled inside voicecall_notify. TTY field in
>> ofono_call is basically for the GetProperties.
>
> I see. So here is the main question that comes from this now.
Hi Marcel,
ofono-boun...@ofono.org wrote:
>> +static void xctms_modify_cb(gboolean ok, GAtResult *result,
>> gpointer +user_data) { + struct cb_data *cbd = user_data;
>> +ofono_ctm_set_cb_t cb = cbd->cb;
>> +struct ofono_error error;
>> +const char *setting = NULL;
>> +struct o
Hi Marcel,
ofono-boun...@ofono.org wrote:
> Hi Jeevaka,
>
>> include/voicecall.h |2 ++
>> src/voicecall.c | 12
>> 2 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/voicecall.h b/include/voicecall.h index
>> e37d73b..6f1bdd2 100644 --- a/includ
Hi Guillaume,
>
> According to 3GPP TS 31.124 a null length for the text string
> should be allowed. An empty string must be returned to the
> user in this case.
> ---
> src/stkutil.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
Agree. As per the 3GPP TS 31.124 null
Hi Denis,
> > + ofono_bool_t online;
>
> Why do you need to track this variable? Can't you simply
> call ofono_modem_get_online()?
>
This way calling of ofono_modem_get_online for each get or set request
can be avoided.
Regards,
Jeevaka
___
ofon
Hi Sankar,
> Then as per your email, the support provided in Ofono seems to be
limited. If there is no enable or disable is allowed,
> I am not sure, how we can we have a card in which FDN enabled, which
will force the ofono to enter presim state. Unless there is no
> option to disable at, foreve
Hi Sankar,
> Is there a way for the clients to enable or disable the Fixed
Dialling? I assume they should be able to do this by using the dbus
calls, "LockPin/UnlockPin". Is there a
> way to store the FDN numbers in the sim card? How does ofono validate
the request to be passed to the network wh
Hi Yang,
>
> +static void get_time(struct stk_response *rsp) {
> + time_t now;
> + struct tm *t;
> +
> + time(&now);
> + t = localtime(&now);
> +
> + rsp->result.type = STK_RESULT_TYPE_SUCCESS;
> +
> + if (t->tm_year > 100)
> + rsp->provide_local_info.dateti
Hi Guillaume,
> >
> > Denis on IRC also wondered if this response should be
> allowed when the
> > message is flagged urgent.
> >
>
> According to the spec I think no, this type of response is
> not allowed when the message is fluffed urgent.
>
As per the ETSI TS 102 223 V9.0.0 section 6
Hi Sankar,
> As per the specification, querying of group of supplementary services
is not allowed. Do you propose a solution where core queries all the
three call forwardings namely
> CF busy, CF Not Reachable, CF noreply and updating the clients with
the status using the above property after re
Hi Aki,
>
> I think the problem is that we try to decode the alpha tag
> even when it is not present, i.e., when _numlen is zero.
>
> In fact, this has already been fixed in my current working
> tree in a bit different way. Mostly due to the fact that I added a new
> g_isi_sb_iter_get_struct
Hi Yang,
> +
> +unsigned int __ofono_netreg_get_tech(struct ofono_netreg *netreg) {
> + GSList *o;
> + unsigned int techs = 0;
> + struct network_operator_data *opd;
> +
> + for (o = netreg->operator_list; o; o = o->next) {
> + opd = o->data;
> + techs |= o
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
Hi Petteri,
> and thanks for the comments.
> I checked the invalidated-flag of EFadn (from file status-byte of GET
RESPONSE) and it actually changed according to FDN-enabling/disabling.
But for some reason I didn't
> got any change in EFsst for FDN/ADN-services. Could it be a good idea
to add
Hi Petteri,
> First patch checks if Fixed Dialing is enabled in the SIM-card by
reading FD-activated bit from EFsst or EFest. If FDN is enabled, SIM
initialization procedure is stopped, > and modem will stay in the
PRE-SIM state.
> If FD is enabled, this is signaled via DBUS.
> I haven't been ab
Hi Petteri,
+static void at_barring_query_enabled(struct ofono_sim *sim,
+ ofono_sim_locked_cb_t cb, void *data) {
+ struct sim_data *sd = ofono_sim_get_data(sim);
+ struct cb_data *cbd = cb_data_new(cb, data);
+ char buf[64];
+
+ if (!cbd)
+
Hi Denis, Marcel,
> what was wrong with the clear indication that this patch is messed up.
>
> This patch comes from a stupid Windows system that tries to change
> every single mode to 0755. Please fix this.
> Whoops, my fault totally missed this. I wonder if there are git
settings that can
Hi Yang,
> --- a/src/stk.c
> +++ b/src/stk.c
> + unsigned char addnl[2];
> +
> + default:
> + DBG("Send ss finishes with error type: %d",
error->type);
> + rsp.result.type = STK_RESULT_TYPE_SS_RETURN_ERROR;
> + addnl[0] = (unsigned char) error->error;
>
Hi Denis,
> The thing is, oFono configures SMS for direct delivery (e.g. no SM/ME
storage). And even if direct delivery does not work (e.g. crappy modem
or Class 2 / Class 3 messages) oFono still removes the SMS
> as soon as it is delivered. We should never hit a sim/me memory full
conditions
Hi,
> Of course, one can argue whether this feature really has some real
> world relevance or is purely theoretical.
>
> I wonder if it is a type approval requirement to support?
> I'm afraid there is a PICS case for this thing. I cannot recall how we
got N900 through this particular hoop, but p
Hi Marcel,
> If device memory capacity is over there is a way to set HLR about
> memory capacity exceeded.
> But in Ofono I didn't find any indication regarding memory capacity
> exceeded for class 1 messages.
>
> Is this feature is going to be added in future? please let me know.
> when you
Hi Yang,
> Below is the description:
> This patch is to handle send ss proactive command from SIM.
> Currently when sending a supplementary service control string via
D-Bus, a series of functions would be called. For example, if we want to
send a call barring activatioin string via D-Bus, these
Hi Denis,
>
> - else if (charset == SMS_CHARSET_8BIT) {
> - /* TODO: Figure out what to do with 8 bit data */
> + if (charset == SMS_CHARSET_7BIT) {
> + switch (data->charset) {
> + case AT_UTIL_CHARSET_GSM:
> + msg = convert_gsm_
Hi Andrew,
> What is the meaning of that -1? I don't see this value handled in
stkutil.
If dcs is -1, then the text is assumed to be in UTF-8. Will add the
-1 handling in stkutil.h
> The rest of this patch looks okay to me, but you have some formatting
> issues: space after '(' above, and
Hi Denis, Andrzej,
> Actually the spec is deviating from the intended purpose of the Text
data object (which
> should contain Text), so handling it specifically is actually better.
I have incorported the comments as part of the Patch "stk and stkutil
changes for Send USSD proactive command". A
Hi,
The following patch "Added missing DCS handling in stkutil and stk"
handles the missing dcs case as:
As per 3GPP TS 31.111 section 8.15 Text string structure requires dcs
and text string to be sent. Current stkutil function and data structure
is missing the dcs information.
In this patch,
Hi,
> On irc we figured that the best hint about what is expected to be
returned is in the tests in 31.124. +CUSD returns sms-like DCS, while
STK expects Cell Broadcast-like DCS and recommends using only the >
values 00, 04, 08, so there needs to be a translation from one to the
other (perhaps
Hi Pekka,
> I thought the modem already unpacks the ussd message to 8-bit gsm and
the dcs parameter is rather meaningless in that case. Perhaps the
atmodem ussd should re-pack the string in order to achieve the
> desired symmetry on the API?
Agree that the modem already unpacks the string rece
Hi Denis,
> Can you send what you have so far to the list? Andrew and Yang are
actually already looking into this, so it might be nice for the three of
you to be on the same page and not duplicate effort.
I'm sending the patches for the Send USSD proactive command handling. I
have tested the c
Hi,
> Can you send what you have so far to the list? Andrew and Yang are
actually already looking into this, so it might be nice for the three of
you to be on the same page and > not duplicate effort.
Ok, I'll try to send the patch by today.
Thanks and Regards,
Jeevaka
-
Hi Denis,
> The original USSD API actually did look like this. It used binary
data
> + dcs field. However, we quickly found that all modems are screwed up
> in this area. The specification added binary PDU mode to SMS and CBS,
but never bothered with USSD. So all modems get this part wrong.
Hi,
> Yes, the driver api may need a change like this. The current API was
created based on the fact that many modems don't understand anything
other than DCS = 15. However
> with STK's "Send USSD" command, sending the requested DCS as-is is
probably our best bet.
> There is a hope that most
Hi Marcel
> you have me confused now. Are you talking about the D-Bus based API
towards applications or the SIM Toolkit support?
> SIM Toolkit is something totally different. Even for SMS we just deal
with raw PDUs there. While the user side applications over D-Bus will
never get access to the
Hi Marcel,
> Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver
> - AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet
> and sends it to the network. In this way, we will always send the data
> coding scheme as GSM 7-bit default alphabet or whatever the char
Hi,
Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver -
AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet and
sends it to the network. In this way, we will always send the data
coding scheme as GSM 7-bit default alphabet or whatever the character
set modem is
Hi Yang Gu,
> In current code, sim_pin_check() is called inside sim_efpl_read_cb().
> However, there may be a chance it would never be called, thus the
modem won't be initialized correctly.
> ---
> src/sim.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
> diff --git a/src/sim.
59 matches
Mail list logo
