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

[Kai Hoerner]

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

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
>
>