State of the API

[Vesa Pikki]

Pikki Vesa wrote:
> Michael 'Mickey' Lauer wrote:
>   
>> Hi guys,
>>
>> I just finished documenting nearly everything of the following APIs:
>>
>> * org.freesmartphone.GSM.MUX
>> * org.freesmartphone.GSM.Device
>> * org.freesmartphone.GSM.SIM
>> * org.freesmartphone.GSM.Network
>> * org.freesmartphone.GSM.Call
>>
>> Especially the Call interface got some changes to clarify and make it more
>> convenient to use (sorry, but I think they were necessary).
>>
>> Before continuing with SMS, Phonebook, and the like, I will now implement the
>> current status in pygsmd. Now that we have docs, please read over the current
>> status and give some comments.
>>
>> Cheers,
>>
>> Mickey.
>>
>> --
>> Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de
>>
>> _______________________________________________
>> smartphones-standards mailing list
>> smartphones-standards at linuxtogo.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
>>
>>     
> Hi
>
> First I'd like to say that you've done a great job on documenting APIs.
> Keep up the good work.
>
> We are using Telit's gsm modem in gsmd2's development. It has an AT
> command called ECAM (Extended call monitoring) to notify about call
> progress. It has the following call statuses:
> 0 - idle
> 1 - calling (MO)
> 2 - connecting (MO)
> 3 - active
> 4 - hold
> 5 - waiting (MT)
> 6 - alerting (MT)
> 7 - busy
>
>
> I'd like to hear your opinion on how to map these to call progress
> signal's statuses? Or perhaps have an explanation in the document for
> each statuses use.
>
> Here's what I've figured out so far:
> [ecam message - fso callprogress signal]
> idle - Disconnect or should it be Reject aswell when remote end
> disconnected?)
> calling - Setting up
> connecting - Progress
> active - Connected
> hold - Release
> waiting - ?
> alerting - Alert
> busy - Reject
> ? - Sync
> ? - Proceed
>
>
> I have attatched a file which has some tests I ran earlier regarding the
> call statuses which might give you a bit more insight.
>
> --
> Vesa Pikki
>
>   
Hi

Couple more thougths. How about adding Device.Reset and 
Device.Diagnostic methods and Device.Error signal.

Device.Reset (it could also have multiple reset levels) could do one or 
more of the following:
 - Reconnect with modem
 - Send atz
 - Send any initialization at commands gsm daemon has
 - Restart gsm daemon
 - Clear any cached values on gsm daemon (for example assumptions that a 
sim card is inserted or pin code is set)

Device.Diagnostic could send a set of at commands to test modem. First 
by sending AT to test that a modem is alive, then
sending at+cpin? to check it's pin state and so forth.

Device.Error would be sent if gsm daemon is unable to connect to gsm 
modem or has some other problems with gsm modem.

-- 
Vesa Pikki