[asterisk-dev] GSM trunks & Dahdi - New funcionality Request for discussion

[Odicha]

Artem Makhutov escribió:
> Hi,
> 
> On Fri, Nov 20, 2009 at 12:32:40PM +0100, Kai Hoerner wrote:
>> Artem Makhutov wrote:
>>> Also the debugging, installation and so on would be more complicated.
>>> You will have to recompile the kernel modules on a kernel update and so on...
>>>   
>> Debugging would be more complicated, agreed.
>> You will have to recompile the kernel modules on kernel update anyways,
>> since they are still needed even if AT translation is done in user
>> space. So i don't see any difference here.
> 
> At least the Huawei sticks have in kernel drivers. So this don't have
> to be recompiled seperate on kernel updates.
> 

I think using tty ports is not a good idea. I have a "dahdi" driver for
E169 sticks, that could also be used for other usb sticks with audio
capabilities. Making whole dahdi interact with tty subsystem could give
us more troubles than advantages. (permissions... user space apps access
to tty ports while dahdi is running, etc.)

>>> I don't see any reasons to put this into kernel space.
>>>   
>> Probably a great benefit of this approach is that new device drivers can
>> be created and installed without even touching the AT standard command
>> library. Device specific code would be handled in one single place,
>> which seems logical to me. Also, this would allow vendor's to create
>> closed source drivers (we dont want them, but sometimes it's better than
>> nothing).
> 
> Sure, but you can also create a standard library which can load closed
> source modules.
> 
> If a user space application crashes you just need to restart it.
> If a kernel module crashes then you might need to restart the whole server...
> 
Of course, same as any other dahdi driver, with or without AT translation

>> By the way, i do not see the need of this "standard AT" library anyways.
>> couldn't you exchange just signals between userspace and the driver
>> modules? the driver itself should convert the "standard gsm signalling"
>> into which AT commands ever are needed to do actually execute the
>> signalling on the device.
>> (just thinking too)
> 
> Yes, this is what we have to do:
> 
> Create a standard library with all the required signalling stuff and so on.
> This standard library can load additional "translation" modules for the
> specific devices which translate the "standard signalling" into device
> specific commands.
> 

How? In a module / submodule struct? So it's the same as making it part
of the library.

IMHO the AT translation at driver level seems not so bad idea.
If fou upgrade kernel, what happens to dahdi drivers at now? It'll
continue happening the same, with or without AT translation integrated.
Remember that in my A schema all hardware has a specific dahdi driver.
E169 sticks will have a dahdi driver. They will not use tty translation.

> To achieve this we need to define the things that should be handled by the
> standard library.
> 
> Things like:
> Dial a number
> Hang up
> Answer
> Ring
> Switch SIM card
> Enter PIN code
> Send/Receive SMS
> Monitor signal strength
> Monitor GSM network
> Send/Receive FAX
> Increase Volume
> Send DTMF
> CUSD messages
> ....
> 

This is the most interesting section.
I would like to do three groups and try to catch one stage before start
next level. Sure in first level we'll see some errors in our schema that
can be changed easily, better than if we try to do all stuff at same time

1-Basic functions. make calls & receive
2-network monitoring, pin, volume
3-SMS & CUSD, switch sims...

So for first stage, my idea is
Init modem.
Make a call.
Answer a call.
Hangup a call.

Thinking...


> Regards, Artem
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev