Source code
Hi, I am trying to download the source code of oFono. Looks like the link is down. Can some one pls help Thanks, Sankar. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Reg: Supporting Operator Preferred List in oFono
Hi Denis, On Wed, Mar 23, 2011 at 7:56 PM, Denis Kenzior 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 wrote:
> 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 is 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
Regarding Network Scan
Hi, Using the Scan method call on the NetworkRegistration interface, I can query the available networks in the current region. Is there a way I can cancel this scan operation.? Thanks, Sankar. ___ 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 wrote: > Hi Marcel, > > 2010/12/21 Marcel Holtmann : > > 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, 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, Thanks for confirming. On Mon, Dec 6, 2010 at 6:52 PM, wrote: > 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 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. > > Currently, there is no way to enable or disable fixed dialling or Barred > Dialling using oFono. If my assumption is correct, there is no plans to > add support.(Denis/Marcel can confirm this). oFono doesn't support > storing any numbers in the SIM storage(EFadn, EFfdn or EFbdn). Agreed as > per the specification calls shall be allowed to any number that is part > of the FDN list. But its been agreed that oFono will enter presim state > when FDN or BDN service is enabled in which state only emergency calls > are allowed. > 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. > > > 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. > > Yes, your understanding is correct. FDN applies to the Mobile originated > calls, SMS etc. > 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. > > 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 > - > - 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
Re: Need Clarification on DCS handling in Status Report for SMS
Hi Rajesh, On Thu, Dec 2, 2010 at 7:33 AM, 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
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 in querying the pin status
Hi Denis, On Tue, Oct 19, 2010 at 8:31 PM, Denis Kenzior 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 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
Query related to UDUB for voice calls.
Hi,
I was referring to the voice calls portion of ofono and I have a query
related to user determined user busy.
In the ofono core, if the user rejects a voice call, based on the call
status, respective driver function is called. I have pasted the code below.
static DBusMessage *voicecall_hangup(
DBusConnection *conn,
DBusMessage *msg, void *data)
{
/* According to various specs, other than 27.007, +CHUP is used
* to reject an incoming call
*/
if (call->status == CALL_STATUS_INCOMING) {
if (vc->driver->hangup == NULL)
return __ofono_error_not_implemented(msg);
vc->pending = dbus_message_ref(msg);
vc->driver->hangup(vc, generic_callback, vc);
return NULL;
}
if (call->status == CALL_STATUS_WAITING) {
if (vc->driver->set_udub == NULL)
return __ofono_error_not_implemented(msg);
vc->pending = dbus_message_ref(msg);
vc->driver->set_udub(vc, generic_callback, vc);
return NULL;
}
}
But as per the 3GPP TS 22001 v6.0.0, UDUB applies to an incoming call also.
Below is the excerpt from the specification.
C.3
User Determined User Busy (UDUB) condition
This condition occurs when a call is offered to a user equipment and the UE
responds "user busy" because the
subscribers resources (terminal or person using them) are busy. Then the
PLMN will clear the call with the indication
"busy" back towards the calling subscriber (see also clause 4).
Can some please clarify if the above behaviour in ofono core is proper or
this need to be corrected?
Thanks,
Sankar.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
