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

[Jose A. Deniz]

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.