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


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