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

[Odicha]

Kai Hoerner escribió:
> Hi Jose,
> 
> there are already great efforts made by "Odicha" to integrate support 
> for GSM cards and modems into DAHDI. Please have a look at the mail-archive.
> 
> This is already working with a few devices, but is still alpha quality.
> If you intend to make own efforts in GSM support, i suggest you jump 
> into that project.
> 
> You may write an eMail to Odicha and ask for SVN/CVS access (if he has 
> source control):
> 
> odi at odicha.net
> 
Thanks. (Jose A. Deniz == Odicha) Sorry, I wrote message from other PC.

> Regards,
> Kaii
> 
> 
> Jose A. Deniz schrieb:
>> Hi!
>>
>> I am doing some job on GSM support at asterisk level, and I'd like make
>> some propossals and listen to your ideas.
>>
>> The requeriments I see for GSM support.
>> three layers. voice, sms & network
>> Voice support. Simple
>> Sms support. Send & Receive capabilities.
>> Network. Info of net status (coverage, provider...)
>>
>> Paths to accomplish these requeriments.
>>
>> A) New struct at chan_dahdi level (as pri or ss7) + new library (similar
>> to libpri)
>>
>> B) Use pri existent struct and add a new layer at libpri library.
>>
>> C) Let each hardware supplier makes its own channel or patch.
>>
>> I discard C ... of course.
>>
>> Anyway, using A or B options, there's a very important issue(from my
>> point of view). AT implementation. AT is a "not standard" standard. Each
>> module has a different commands set. So we can't try to do it in the
>> same way as libpri. I think in two different options.
>> 1- Make a standard unit (as libpri q931.c) that makes calls dependent on
>> modem type. So we should have a module or a set of functions for each
>> different hardware we try to support.
>>
>> chan_dahdi-> libpri -> at standard module -> at private implementation
>> module -> dahdi -> hardware driver
>>
>> 2- Construct an abstraction layer and let every dahdi driver the
>> translating mission into AT codes.
>>
>> chan_dahdi-> libpri -> at standard module -> dahdi -> hardware driver
>> (it translates internally our layer into AT codes)
>>
>> Pros & Cons I see
>>
>> Reusing pri struct implies make some dirty things at libpri level,
>> because many of gsm devices don't have a signalling structure for making
>> procceding & progress status whe we make a call.
>> For example, Motorola or Simcom implementation haven't an AT event for
>> this. So we might send procceding progress and alert status at same time
>>  back to chan_dahdi. In the other hand we have Qualcomm chips based
>> Huawei model that has ORIG & CONF events when we make a call.
>> Siemens uses a different AT implementation and each hardware supplier
>> makes adaptations.
>>
>> Making a new struct gives us more freedom, but sure It could have some
>> cons that I can see yet.
>>
>> On the sms side we have a lot of options, but they relies on the path we
>> walk on. What do we do when a sms gets in? Something like chan_mobile?
>> Yes, not?
>>
>> I have done tests on A & B options and it's possible any of them, but
>> I'd like to know what dou you think of this before doing whole job.
>>
>> Thanks in advance and aplogyze for my english.
>>
>> _______________________________________________
>> --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
>>
>>   
> 
> 
> _______________________________________________
> --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