org.freesmartphone.GSM.SIM

[Bernhard Kaindl]

Hi,
    Nobody here except for Mickey and Michael know me, so I write a bit
about how I came here:

I met Mickey and Michael on the train to FOSDEM 2008 where I saw
Michael's project. A few weeks ago, I flashed it on my GTA01v4 and
started researching the GSM 07.05 technical specification for SMS
in order to start working on an SMS daemon based on pygsmd.py.
I did a quick test for listing and reading SMS.

I also tested a few existing toolkits which implement parts of GSM
07.05 for SMS like (x)gnokii, python-(gammu)/wammu and gsmlib-1.11
to learn more.

So based on that, I am giving you my comments about obvious and
not-so-obvious observations which I got during this research:

On Sat, 19 Apr 2008, Sudharshan S wrote:
> Michael 'Mickey' Lauer wrote:
>>
>> Do we want
>> * SendMessage
>> * MessageSent
>> * IncomingMessage
>>
>> as a part of org.freesmartphone.GSM.SIM or will we leave that exclusively to
>> org.freesmartphone.GSM.SMS ?
>>
>
> I would vote the above to be part of SMS as it sounds more intuitive.
> Just my 2 cents, but I feel people will find themselves looking for
> SendMessage or MessageSent as part of org.freesmartphone.GSM.SMS first.

To have working SendMessage, MessageSent, IncomingMessage you need a
SIM, but in addition, you need to be registered to a network and be
connected to it. So they have the same requirements as making and
receiving calls.

A standard configuration for receiving SMS is configuring the GSM device
to write received SMS into SMS storage (until it's full) and send you
a notification on such received SMS. If saving the SMS to SMS storage
was successful, the GSM device signals to the GSM network that the SMS
has been received.

Depending on the capabilities, GSM modems can also be switched to another
mode where incoming SMS are not saved to SMS storage but sent over the
AT-command link to be stored by some SMS daemon, outside of the GSM
device. When the SMS daemon then confirms the successful transmission
of such SMS, the GSM device signals to the network that the SMS has been
received.

This latter mode may be useful when you do not want to be constrained
by the SIM storage which the GSM modem supports but store SMS in your
own storage space.

I mentioned "SMS storage" a couple of times here. Such SMS storage does
not need to be the SIM card itself, Most newer GSM phones can write SMS
directly to some other internal storage space, outside of the SIM.

The old Nokia 6150 probably only writes SMS to SIM but some newer ones
like the Sony T610 certainly seems to write SMS to some internal SMS
storage. In fact, the GSM 07.05 technical specification provides for
some standed message storages names:

"BM" broadcast message storage
"ME" ME message storage
"MT" any of the storages associated with ME
"SM" SIM message storage
"TA" TA message storage
"SR" status report storage

The GSM modem in my GTA01v4 uses "SM" (the SIM card) by default and
seems to also have "ME" ("Mobile Equipment"), but the ME storage does
not seem to work right, maybe because the GSM modem in my GTA01v4 is
really just configured as a modem an not as a full-blown phone like
the GSM part of normal feature-phones like the Sony T610 would be.

So depending on whether the freesmartphone API should also support
some more powerful GSM devices like fully features phones and
smartphones which have other SMS storage means besides the SIM
which is often very limited in space (I think mine can fit maybe
20 or 32 received SMS), I would not neccesarily associate SMS with
the SIM at all.

The same applis to the phonebook storage. Fully-featured GSM devices
(exluding the GSM modem of my Neo here) Phonebook entries can store
phonebook entries outside of the SIM which is also very limited in
space and information richness. Other phnonebook storage besides SIM
are supported by the tools which I looked at (gammu/gnokki or gsmlib)

Similar to other phones, also "free" phones like the OpenMoko or other
devices coming up could also support and use such SIM-external SMS
and phonebook storage and it may be useful to be able to use the
freesmartphone API also for access to such information in such storage
from outside of the phone itself, say when I connected an OpenMoko
phone (running whatever software) to my Computer and be able to
access phonebook entries and SMS on the phone using the API.

To address the storage space to use, the DBUS object_path could be
useful. E.g. to address the SIM storage, an object_path ending with
/SIM could be used while e.g. /Device could be used to access storage
of the device itself.

That's not an idea of mine, I got that idea Michael when he proposed
to me to use the Storage API method for both SMS and phonebook.

The only difference besides the object path would be the acutal data
which is saved and retrieved.

The data actual data which can be saved and retrieved would be dependent
on the object path and be rather fixed for SIM-stored SMS and phonebook,
while it could be very detailed for SIM-external phonebooks for example.

My suggestion for SendMessage, MessageSent, IncomingMessage would be
to place it at a location where it's clear that they will only work
when the phone is in an on-line status, connected to the network,
even inside of a new path like org.freesmartphone.GSM.Network.Online
to make that clear.

Accessing SMS and phonebook information in the SIM only works if the
SIM authentication status is "READY", which may require the SIM to
be authenticated with a PIN.

It appears to me that also access to other private information like
SIM-external SMS and phonebook entries should (optionally) require
authentication to the device by means of a PIN for example.

I don't know of your thoughs for this, but some phones have (besides the
SIM's PIN) some other locking codes which can optionally be enabled.
Maybe such provisions may be useful also for accessing private
device-local information like SIM-external SMS and phone book
information.

Any such authentication may be shared for SMS and phonebook storage
and a default may be to check for the SIM authentication status and
use that also for off-SIM information, or the device could use another
authentication API.

I guess that the SIM and phonebook API might provide a method call
which tells which kind of authentication to use to access SIM and
phonebook informaiton and a simple answer would be to return e.g.
"SIM PIN" in that case, which would refer the user of the API to
use SIM authentication before acessing SMS and phonebook data.

With an example API which uses an object path to specify the storage
addressed and uses an generic storage API to access SMS info, a
method call could look like this:

object_path=/org/mobile/GsmPhone/SMS/SIM
org.freesmartphone.GSM.Storage.GetAuthMethod() could return: "SIM PIN"

It could be specified to always return a list of strings (string array)
to have the API supporting cases where multible autentication methods
may be asked by the device.

Other object paths would be e.g.:

/org/mobile/GsmPhone/SMS/SIM
/org/mobile/GsmPhone/SMS/Device
/org/mobile/GsmPhone/Phonebook/SIM
/org/mobile/GsmPhone/Phonebook/Device

To support multible phones connected to one Computer, the API may
possibly be extended to provide for a method to Enumerate and List
the GSM phones connected to a computer and then do all access to them
using an Object Path which is returned by the GSM phone enumeration API,
e.g. a sequence like this could be used:

/org/mobile/GsmPhone/Enumerate:
org.freesmartphone.GSM.ListPhones() -> {"FIC_GTA01v4_SN1234556"}

/org/mobile/GsmPhone/FIC_GTA01v4_SN1234556/SMS/Device:
org.freesmartphone.GSM.Storage.GetAuthMethod() {"SIM PIN"}

/org/mobile/GsmPhone/FIC_GTA01v4_SN1234556:
org.freesmartphone.GSM.SIM.SendPin("1111")
org.freesmartphone.GSM.SIM.AuthStatus() -> "READY"

/org/mobile/GsmPhone/FIC_GTA01v4_SN1234556/SMS/Device:
org.freesmartphone.GSM.Storage.ListEntries() -> {"1","2","3"}
org.freesmartphone.GSM.Storage.RetieveEntry("1") -> ("Number":"+49xxx",
      "Text":"Good day!", "Time":"2008/02/03 15:22", .....)

Bernhard