[asterisk-dev] Channel support for GSM devices

[Odicha]

So what is done...

dahdi support for two cards
- OpenVox G400P (pci, 4 gsm channels)
-Huawei E169/K3520/K3515 (usb,1 gsm channel)

Some minor changes to chan_dahdi (gsm signalling & some little patches 
for these cards)

- The "big block" is at libpri. It has more changes. at_internal.c (same 
as q931.c but for gsm) It's called from pri.c public functions. The 
"trick" I've used for testing is related to pri struct. I added a new 
type of pri dchannel pri_at so in example when chan_dahdi calls pri 
library if the card is a gsm one it calls the at_internal function 
instead the q921.c/q931.c function.
at_huawei.c & at_opvxg4xx.c for internal at comm with cards. It uses 
same signalling channels as pri devices. So we have a new case.
We have a "pseudo-pri" with one b channel and one d channel (as rdsi 
cards but one b per span)
If you want as soon as I clean all code I can upload it ( it's yet in a 
very alpha state). It's not production quality yet, but I can make & 
receive calls using those two cards.

The main trouble I see is that each hardware supplier (at gsm module 
level) makes its own at implementation. So, a siemens module is 
different at "at" level from a Qualcomm module (used by huawei ones) or 
a Simcom module (used by OpenVox). For example Junghanns pci-gsm card 
uses a motorola module that is already different from all I have told 
before. It implies that we might have one c unit for at traffic per gsm 
module, working as old 1.0 chan_modem did. So if in future time we want 
add support for a new gsm card at dahdi, we'll have to write an 
additional module to libpri.

The alternative I see is write our "own pseudo-standard". So we can 
define all standard modem events. Call, conf, connect, dial, hangup, 
send pin, etc. And make it in a way as the dahdi driver "translate" that 
standard commands into the at implementation it has. It could be a 
bigger work at now, but we'll have a more "stable" libpri. So in that 
way, we'll send the same command to any gsm device, and at dahdi level 
it'll be translated to the at commands it needs. If we want to add 
support for a new card in this way, we only need work at dahdi level, 
because all the rest is part of a standard.
I'd like to read your ideas.
Best regards


Odicha escribió:
> 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
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> AstriCon 2009 - October 13 - 15 Phoenix, Arizona
> Register Now: http://www.astricon.net
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>