Re: Reg: Supporting Operator Preferred List in oFono
Hi Denis, On Wed, Mar 23, 2011 at 7:56 PM, Denis Kenzior denk...@gmail.com wrote: Hi Sankar, On 03/23/2011 06:52 AM, Sankar wrote: Hi , I would like to know if there is any proposal to support the Operator Preferred List in oFono. This is being a key feature, allowing the user to add/delete/modify the PLMNSel, PLMNWact files on the card, which are used by the Baseband during the network registration procedures. This is not (and unlikely to be) a priority feature. These lists are mostly managed by the modem and do not need oFono's intervention. I agree lists are used by Modem, but definitely oFono's intervention is required if the user wants to modify this list. If you need this feature then I suggest you add a task to the TODO list and go about finding someone to implement it ;) I will explore this. I have not added any TODOs before. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Reg: Supporting Operator Preferred List in oFono
Hi , I would like to know if there is any proposal to support the Operator Preferred List in oFono. This is being a key feature, allowing the user to add/delete/modify the PLMNSel, PLMNWact files on the card, which are used by the Baseband during the network registration procedures. Thanks, Sankar. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 2/3] ssn: add code and call id to notifications
Hi Denis/Andras,
Is this patch applied and available in the GIT?
Regards,
Sankar.
On Thu, Feb 10, 2011 at 2:42 PM, Andras Domokos andras.domo...@nokia.comwrote:
Hi Denis,
On 02/10/2011 05:08 AM, ext Denis Kenzior wrote:
Hi Andras,
diff --git a/include/ssn.h b/include/ssn.h
index d640cad..ba3701b 100644
--- a/include/ssn.h
+++ b/include/ssn.h
@@ -37,9 +37,10 @@ struct ofono_ssn_driver {
};
/* SSN notifications (CSSI and CSSU). */
-void ofono_ssn_cssi_notify(struct ofono_ssn *ssn, int code, int index);
-void ofono_ssn_cssu_notify(struct ofono_ssn *ssn, int code, int index,
- const struct ofono_phone_number *number);
+void ofono_ssn_cssi_notify(struct ofono_ssn *ssn, unsigned int id,
+ int code1, int index);
+void ofono_ssn_cssu_notify(struct ofono_ssn *ssn, unsigned int id, int
code2,
+ int index, const struct ofono_phone_number
*number);
int ofono_ssn_driver_register(const struct ofono_ssn_driver *d);
void ofono_ssn_driver_unregister(const struct ofono_ssn_driver *d);
Right now I'm not seeing any users (or even potential ones) of the SSN
atom besides voicecall. What do you think of removing the SSN atom and
moving these to the voicecall atom?
Yes, we talked about removing the SSN atom, but I thought I would
keep it for now, it can be removed any time later, anyways, doesn't
save much removing it.
The only one I'm not sure about iscode2 from 27.007:
6 forward check SS message received (can be received whenever)
Any idea what this one is about?
Never encountered this message, and I am not sure what is it for.
A patch for handling this message can be submitted later, if a real
life case is found for it.
Regards,
-Denis
Regards,
Andras
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 0/4] Query retry counters
Hi Lucas,
On Tue, Jan 4, 2011 at 6:36 PM, Lucas De Marchi
lucas.demar...@profusion.mobi wrote:
Here is the second implementation for the retry counter task. The
difference
from the previous approach is that now a dict with all the available retry
counters is returned. This way is possible to query the retry counter even
when
PinRequired == None, what allows us to properly handle calls to EnterPin(),
LockPin(), UnlockPin() and so on.
The dict has the form { pin = 3, puk = 10, ... }. The driver implementation
for
huawei modem is done using its proprietary command, which returns 4
counters:
{SimManager} [/huawei0] Retries = { pin2 = 3, puk2 = 10, pin = 3, puk = 10
}
How this information is retrieved at the oFono core. Is your solution to
maintain a counter or read the value from the sim elementary files?
Thanks,
Sankar.
Lucas De Marchi (4):
include: add method to query pin Retries
sim: query remaining pin retries
doc: detail Retries property
atmodem: implement query for remaining pin retries
doc/sim-api.txt | 12 ++
drivers/atmodem/sim.c | 99
+++
include/sim.h | 11 +
src/sim.c | 102
+
4 files changed, 224 insertions(+), 0 deletions(-)
--
1.7.3.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: oFono release plan?
Hi Aki, On Tue, Dec 21, 2010 at 9:58 PM, Aki Niemi a...@protocolpolice.com wrote: Hi Marcel, 2010/12/21 Marcel Holtmann mar...@holtmann.org: we don't know that yet for sure. They might be all internal, but there might be also D-Bus visible changes. We will see once LTE support lands in oFono. Well, from my point of view there are some key APIs we know for sure are missing. Off the top of my head: - LCS, neighbor cell info - CDMA support Can you please add more light on what all is planned under the CDMA support. - the SMS (history) agent API - SIM authentication API (EAP-SIM, EAP-AKA, IMS and GBA) Can you please add more light on what is supported. I could not find this info in the todo list. Then again, I don't really see the point in a 1.0 beyond marketing. It's not like the current D-Bus API is allowed to change a lot as it stands currently. Cheers, Aki Regards, Sankar. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 3/4] doc: detail PinRetries property
Hi Lucas, On Tue, Dec 21, 2010 at 3:26 AM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: --- doc/sim-api.txt | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/doc/sim-api.txt b/doc/sim-api.txt index d4d2b1b..c7d1faa 100644 --- a/doc/sim-api.txt +++ b/doc/sim-api.txt @@ -145,3 +145,13 @@ Properties boolean Present [readonly] If BDN is enabled, oFono halts the SIM initialization procedure and only emergency calls are allowed. + + byte PinRetries [readonly] + + Contains the retry counter for the current required + pin. This counter is tipically decremented whenever a + call to EnterPin() fails. + + E.g.: if PinRequired is equal puk, this property + contains the number of times EnterPin can be called + with a wrong puk. Does this property also mention how many retries are possible when the user enters a wrong PUK for unblocking the sim pin. Thanks, Sankar. -- 1.7.3.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 4/4] TODO: Marking the Barred Dialing task as done
Hi Denis/Pessi, On Mon, Dec 6, 2010 at 9:18 PM, jeevaka.badrap...@elektrobit.com wrote: 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, forever with that sim card, the phone will be in presim state,leading to only placing of emergency calls. Support for disabling FDN was discussed earlier. Denis/Pessi could you confirm what was the decision made on FDN disable support? Can you please provide your comments on the support for Enable/Disable of FDN/BDN in ofono. Thanks, Sankar. Thanks for confirming. Then in this case, are we not forcing the mobile to go in a state, where if FDN is already enabled in the sim card( may be from a different phone), user allowed with no option rather than making an emergency call. Yes, we are forcing the mobile into presim state where only emergency calls are allowed. We have already discussed this many times in irc and its been agreed that only emergency calls are allowed when FDN or BDN enabled SIM used. Regards, Jeevaka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 4/4] TODO: Marking the Barred Dialing task as done
Hi Jeevaka, I have a few comments on the support of FDN and BDN in Ofono. Can you please clarify. Thanks, Sankar. On Mon, Oct 25, 2010 at 5:04 PM, Jeevaka Badrappan jeevaka.badrap...@elektrobit.com wrote: --- TODO |7 --- doc/features.txt |5 + 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/TODO b/TODO index d9a6580..ad96241 100644 --- a/TODO +++ b/TODO @@ -110,13 +110,6 @@ SMS SIM / SIM File system = -- Barred Dialing numbers support. BDN will not be supported by oFono. - If BDN service enabled SIM is used, oFono will go into emergency mode. - - Priority: Low - Complexity: C2 - Owner: Jeevaka Badrappan jeevaka.badrap...@elektrobit.com - - Read / Write EFcfis. Call forwarding settings can be bootstrapped on the SIM for faster notification of the user that call forwarding is active. These settings are stored in EFcfis. oFono should read these settings and diff --git a/doc/features.txt b/doc/features.txt index 3524e79..12be037 100644 --- a/doc/features.txt +++ b/doc/features.txt @@ -135,3 +135,8 @@ SIM check if FDN support is allocated and enabled in the SIM. If enabled, oFono halts the SIM initialization procedure and the modem remains in the PRESIM state. In this state oFono will only allow emergency calls. 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 when FDN is enabled? Looks like as per the current implementation of FDN, only emergency calls are allowed. But as per the 3GPP standards, calls shall be allowed to any number (irrespective of emergency no) that is part of the FDN list. If the modem remains in PRESIM State, how does the mobile receive the Incoming Calls or SMS? As per my understanding FDN applies in the uplink and not in the downlink. Please clarify if my understanding is wrong. + +- Barred Dialing support. oFono reads the necessary bits from the SIM to + check if BDN support is allocated and enabled in the SIM. If enabled, + oFono halts the SIM initialization procedure and the modem remains in the + PRESIM state. In this state oFono will only allow emergency calls. I have similar doubts for BDN also. -- Best Regards, Sankar. 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Need Clarification on DCS handling in Status Report for SMS
Hi, While doing a code reading for ofono SMS, it is observed that there seems to be an issue with the way DCS is handled for SMS status report notify. In the decode SMS function, there is a check to find out if there is a PI (parameter identifier). If there is a PI and no DCS flag set, then the ofono core sets the dcs to default. If the PI itself is missing in the PDU received from the network, then the dcs values are not set to default. This seems to cause a problem, where, the decoding of dcs fails, and results in not sending the delivery notification to clients. Can some one please comment on this. Thanks, Sankar. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Need Clarification on DCS handling in Status Report for SMS
Hi Rajesh, On Thu, Dec 2, 2010 at 7:33 AM, rajesh.naga...@elektrobit.com wrote: Hi Sankar, In the decode SMS function, there is a check to find out if there is a PI (parameter identifier). If there is a PI and no DCS flag set, then the ofono core sets the dcs to default. If the PI itself is missing in the PDU received from the network, then the dcs values are not set to default. This seems to cause a problem, where, the decoding of dcs fails, and results in not sending the delivery notification to clients. Yes, this is a bug. But rather than setting the DCS to default in this case, we should rather not call that sms_dcs_decode() function from ofono_sms_status_notify(), as the class information derived from the DCS decoding is not used there and also we are not handling the optional text information in the status report handling currently. If we decide to handle this optional text information (most likely not going to happen), then some modifications are required. Also there is another bug in the current code which might not be relevant if we decide to remove the sms_dcs_decode() function call from ofono_sms_status_notify(). In that function call instead of passing s.status_report.dcs, we are currently passing s.deliver.dcs. Thanks for your inputs. Can you please let me know when this will be addressed in the ofono. BR, Rajesh ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Need clarification in querying the pin status
Hi Denis, On Tue, Oct 19, 2010 at 8:31 PM, Denis Kenzior denk...@gmail.com wrote: Hi Mamata, On 10/19/2010 09:20 AM, mamata l wrote: Hi, I need clarification for querying the pin status when enabling/disabling pin fails and the maximum number of attempts of wrong password are reached in the modem. I am trying to enable pin with the wrong password, and trying to get the pin status. I observe that the maximum number of attempts for wrong password have reached and the modem has reached to puk state and also the modem de-registers from network. In this case when i tried to get the properties using GetProperties, the properties from the ofono core are received without querying the information from the modem. The PinRequired received is none . Could you please provide some info how to get the sim pin state when sim is blocked on puk at run-time and is there any way for app to know the number of attempts remaining. This is actually a bug in oFono, somehow we missed the fact that ChangePin with the wrong PIN will decrease the retry counts. The core needs to be fixed to query the current PIN state and reset the state to pre-sim if the retry limit is reached. Can you please let us know if this is already addressed or this will be addressed in future. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC 7/7] doc: Add new property to call forwarding
Hi Jeevaka, On Fri, Nov 26, 2010 at 11:53 AM, Jeevaka Badrappan jeevaka.badrap...@elektrobit.com wrote: --- doc/call-forwarding-api.txt |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/doc/call-forwarding-api.txt b/doc/call-forwarding-api.txt index 067531a..5dfb48e 100644 --- a/doc/call-forwarding-api.txt +++ b/doc/call-forwarding-api.txt @@ -57,3 +57,8 @@ Propertiesstring VoiceUnconditional [readwrite] Contains the value of the voice Not Reachable call forwarding rule. + + boolean VoiceUnconditionalStatus [readonly] + + Boolean representing the voice unconditional call + forwarding rule status. 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 receiving the status for all the three? -- 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Query related to UDUB for voice calls.
HI Denis, Thanks for the response. I feel like due to the limitation of the AT modem interface through 27007, we are missing the basic functionality defined in the other specifications for UDUB. Please comment. Thanks, Sankar. On Sat, Oct 2, 2010 at 4:26 AM, Denis Kenzior denk...@gmail.com wrote: Hi Rajesh, Please, NO top posting on this list. On 10/01/2010 04:31 PM, rajesh.naga...@elektrobit.com wrote: Hi Sankar, My understanding is that when a call is rejected by the user, irrespective of whether its an incoming call or a waiting call, the cause value for the release call should be set to UDUB, so that for the remote subscriber the User Busy note will be shown in the UI if the voice mailbox is not configured. In the message based modem case, we set the cause value to UDUB with the release call request and in the AT based modem case we should send AT+CHLD=0, which will in turn set UDUB. So for the Incoming call hangup case if we call vc-driver-hangup(vc, generic_callback, vc); in AT case it will send AT+CHUP which i am not sure is inturn going to set the cause value to UDUB or not (Someone with AT based modem experience can confirm this ???), but for message based modem case its going to call the release call request with cause value Release by user, which will be translated to normal call clearing. So in ofono core the hangup case for Incoming call should be handled in same way as Waiting call by calling vc-driver-set_udub(vc, generic_callback, vc); instead of vc-driver-hangup(vc, generic_callback, vc);, so that UDUB cause is sent to the remote party Unfortunately AT modems do not allow any CHLD operations on incoming calls, including CHLD=0. CHLD=0 can only be used to set UDUB on waiting calls. To release incoming calls you must use ATH or +CHUP. Since AT command modems are the only ones described by 3GPP standards, that is the modem interface oFono assumes. If your modem deviates from this standard, then you need to make sure to send the proper release cause for incoming calls in the driver for your target hardware. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
