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

Jose A. Deniz odi at odicha.net
Thu Nov 19 06:28:18 CST 2009


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.



More information about the asterisk-dev mailing list