Re: Handling of Fixed Dialing

2010-10-06 Thread Marcel Holtmann
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.

don't forget to update the documentation with the new D-Bus property.

Regards

Marcel


___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono


RE: Handling of Fixed Dialing

2010-10-06 Thread Jeevaka.Badrappan
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 abled to test this in my 2G-modem properly. Response
for EF-phase is 3. So oFono-API starts to access EFust/EFest files. 
> But reading of EFest gives next error:

> 'technical problem with no diagnostic given'. 

> So FD-status is no reachable, although I have activated it in the
SIM-card.
> I also checked if the FD-status could be located in EFsst (well,
accessed with same code as with EFust), but I couldn't give any change
for allocated/activated bits for 
> FDN, even though I enabled/disabled FDN.

> Please comment/test.

  I had a discussion with Denis today about both FDN and BDN status.

GSM SIM Card:(EFsst)

  In this case, FDN service status depends on the bits in EFsst and
EFadn invalidation information.( invalidation information is part of the
"Get RESPONSE" response data)
  
  EFsst - FDN is allocated and activated in the SIM:
 
FDN is enabled - When EFadn is invalidated or not activated.
  FDN is disabled - When EFadn is validated.

  EFsst - FDN is not allocated or not activated in the SIM:
  FDN is disabled

  Note: This information can be found in the 3GPP 11.11 specification
section 11.5.1. Paragraph starts with "FDN capability request".
Invalidation information bits information can be found in the 3GPP
51.011 specification section 9.2.1(Response parameters/data in case of
an EF:) and section 9.3

USIM Card:(EFust, EFest) 

  In USIM case, FDN enabled/disabled dependents on the bits in the EFust
and EFest. 

Let me know if something is unclear

Thanks and Regards,
jeevaka
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono


Re: Handling of Fixed Dialing

2010-10-07 Thread Petteri Tikander
Hi Jeevaka and Denis,

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 also reading of EFadn in the SIM-initialization routine, 
check invalidated-flag, and make decision of continuing initialization routine 
based on that?

The other issue was that selection of service table (SIM/USIM) based on 
EFphase. So SIM returns '3' in my tests. But the SIM-card seems to be of type 
SIM (not USIM), because I accessed some USIM-type elementary files (EFest, 
EFpbr) and those returned only error-codes. Like phase (3g) wouldn't actually 
be exactly the same thing than USIM-type. What about doing the next change in 
the SIM-init routine (not trusting to EFphase response when accessing the 
correct service tables):

- read first EFest
- if EFest-access gives a valid response, read EFust
- if EFest-access doesn't give a valid response, read EFsst

Br, Petteri

> 
>   I had a discussion with Denis today about both FDN and BDN status.
> 
> GSM SIM Card:(EFsst)
> 
>   In this case, FDN service status depends on the bits in EFsst and
> EFadn invalidation information.( invalidation information is part of the
> "Get RESPONSE" response data)
> 
>   EFsst - FDN is allocated and activated in the SIM:
> 
>   FDN is enabled - When EFadn is invalidated or not activated.
>   FDN is disabled - When EFadn is validated.
> 
>   EFsst - FDN is not allocated or not activated in the SIM:
>   FDN is disabled
> 
>   Note: This information can be found in the 3GPP 11.11 specification
> section 11.5.1. Paragraph starts with "FDN capability request".
> Invalidation information bits information can be found in the 3GPP
> 51.011 specification section 9.2.1(Response parameters/data in case of
> an EF:) and section 9.3
> 
> USIM Card:(EFust, EFest)
> 
>   In USIM case, FDN enabled/disabled dependents on the bits in the EFust
> and EFest.
> 
> Let me know if something is unclear
> 
> Thanks and 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: Handling of Fixed Dialing

2010-10-07 Thread Marcel Holtmann
Hi Petteri,

> and thanks for the comments.

please stop top posting on this mailing list. Please don't have me to
repeat this over and over again.

Regards

Marcel


___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono


RE: Handling of Fixed Dialing

2010-10-07 Thread Jeevaka.Badrappan
 
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 also reading of EFadn in the SIM-initialization routine, check
invalidated-flag, and make 
> decision of continuing initialization routine based on that?

  Exactly, thats what the specification also says. EFsst will inform 2
things: SIM's capabilty to support the service and service's
availability for the card holder. EFadn's file status is the one we need
to depend on for FDN enabled/disabled status. 

> The other issue was that selection of service table (SIM/USIM) based
on EFphase. So SIM returns '3' in my tests. But the SIM-card seems to be
of type SIM (not USIM), 
> because I accessed some USIM-type elementary files (EFest,
> EFpbr) and those returned only error-codes. Like phase (3g) wouldn't
actually be exactly the same thing than USIM-type. What about doing the
next change in the SIM-init 
> routine (not trusting to EFphase response when accessing the correct
service tables):

> - read first EFest
> - if EFest-access gives a valid response, read EFust
> - if EFest-access doesn't give a valid response, read EFsst

EFphase information is not the correct way to determine the SIM card
type(SIM/USIM). 

In most of the message based modems(eg: isimodem), there exists a
mechanism to get the type of the card. 

AT based modem is the issue. Since most of the AT based modems doesn't
support AT+CSIM, its difficult to determine the card type.

I still believe that we need to determine the card type during the SIM
initialization itself for reading the right SIM files.

Regards,
jeevaka

___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono