[asterisk-dev] Channel support for GSM devices
Odicha
odi at odicha.net
Thu Oct 8 04:00:54 CDT 2009
Hello
Firstly apologies for my English
I have a project idea. The aim is to provide a single asterisk channel
services to all GSM hardware that can connect to the system
Needs to be met.
1) It will provide voice capabilities
2) It will bring instant messaging services
3) It will provide a layer signaling over states of the GSM network and
the hardware itself
Hardware capable of being used.
Any device with GSM capabilities. We can distinguish 3 main groups:
1) GSM Modems. Usually USB or PCMCIA PCEXPRESS.
2) MultiModem Devices (eg. Junghanns Openvox quadGSM or OpenVox G400P)
3) External FXS Gateways (Nokia Premicell type, Xacom Celline, etc) with
a serial or usb port usually we can use for receive and send sms
** Supported buetooth devices be left out but are covered by another
module that has a different philosophy to that proposed here, they could
be ported without much complexity in the future
If we look we see first of all we have to divide, first between devices
with voice and data devices that operate alone, and secondly, between
devices that must be added hardware management (as multiport cards) and
those with maintain contact with only AT (like any traditional modem)
My proposal goes through using a model similar to chan_dahdi with a
common interface towards Asterisk and connect with specific modules for
each class of hardware device, simplifying management tasks. For
example, to send an sms through any supported device to follow the
protocol to asterisk would face exactly the same.
On the operating philosophy, we might speak of a largely redundant with
the structure of chan_dahdi (or adding some code to it). In principle we
would have from the point of view of a pool of channels Asterisk so
discretionary associate in groups, with the exception of alarm signaling
that was to be rethought from the standpoint of GSM. Two situations that
come to mind are a priori "out of coverage area" and "at-roaming"
network level, and all those inherent in CUSD in the case of prepaid SIM
cards. It is a place where you will carefully apply the standards of the
3GPP consortium or trying to deviate as little as possible of the
standard protocol, to reconcile the most of the code that is created
with any possible future platform hardware level.
Let's say a level of communications with the hardware itself, we have
two different layers.
First, distinguishing the type of device connected to it we will enable
your communications ports. Just keep in mind that unless someone stated
otherwise, all the hardware I've seen for communications based on GSM AT
commands, as it has been doing for many years with any modem.
Thus we have two layers themselves. The less that is responsible for
maintaining the connection to the modem at a lower step (eg usbserial is
said in the case of GSM modems USB port or multiport controllers OpenVox
O Junghanns to which serial ports enable you to communicate with modems)
On this we have the AT communication layer with which all maintain
operational communications.
A voice support level, then discuss each case is different but which
generally receive two-way channel digital audio with a standard format
that will flow between the hardware and Asterisk.
So after this brief explanation, It could be something like this (code):
1) A library standardized by the 3GPP communication (much as like
libpri) (AT translation mainly...)
2) A channel for device management at asterisk, with its functions,
applications, monitoring, etc.. or some additional layers to chan_dahdi
3) Modules for each of the hardware devices that support them (with
corresponding additions to the library gsm to cover non-standard
implementations of manufacturers, because the standard is not always used)
I have some gsm hardware for develop and test, so I can work on it.
(Siemens tc35i & mc35i, Huawei voice modems, OpenVox multiports 3g
cards, Telecom & Nokia Premicells..)
Any ideas will be welcome
Best Regards,
Odicha
More information about the asterisk-dev
mailing list