"the site for those who crave disappointment"

Sponsored Links GSM Card

23rd Apr 2013, 21:37:42

By James Stocks

Since I first started to experiment with chan_mobile, I've got used to the convenience of a GSM breakout for my Asterisk PBX. As you might reasonably expect, chan_mobile isn't 100% reliable, so a 'proper' GSM card was a tempting prospect.

I had two Nokia 6021 phones tethered to my Asterisk box, and since I wanted to retain both of these numbers that meant I'd need a card with two GSM radios - one for each SIM. Prices for 2-SIM Asterisk compatible GSM hardware range start from £200. Having been stung before by poor quality drivers, I initially wanted something which would work with DAHDI, but such cards are expensive. Sangoma for example offer a W400, but it is £600 with VAT. In the end, I was given the opportunity to test's GSM PCI card. At £250 it is slightly dearer than the cheapest card I could find (OpenVOX G400P), but I was won over by the promise of free phone and email support.


The card arrived. Immediately I notice that it is huge. The manual states that the card measures 63.5mm high x 94.3mm long, but it is more like 120mm high and 150mm long. It seems like there's been a hardware revision since the manual was written, but on the plus side it now means that all the SIM cards can be inserted and removed from slots in the PCI faceplate which is a welcome convenience. However, this card wasn't going to fit in the small form factor PC I use as my PBX.

To solve this problem, I pressed into service a Pentium III box I had spare, since I thought this would use fairly little electrical power whilst still having enough power to run Asterisk.

The card just fits in the Chassis

The top edge of the card protrudes above the level of the faceplate by 10mm or so, this is a problem for most cases smaller than a midi-tower.

The card requires a molex power connection on the rear edge of the card since it can't draw enough power from the PCI bus. I had to use an extension cable to reach this. This is also a requirement for the PCIe card. It is an annoyance since few rack-mount servers seem to have a molex connector, so some creativity might be needed.

Finally, the antennae simply screw on to some SMA connectors on the faceplate.

Setting up the card is pretty well documented in the manual, however it does assume that you'll be using CentOS whereas I prefer Debian. Not a big problem, but it does mean the package names don't match up exactly. Something like this does the trick:

# apt-get update ; apt-get install \
bison zlib zlib1g-dev openssl libgnutls libgnutls-dev flex \
gcc g++ build-essential linux-headers-`uname -r`

Assuming the Asterisk source is already in /usr/src, unpack the tarball and build the driver:

# cd /usr/src
# wget
# tar xf allo_gsm_driver.tar
# cd allo_gsm
# ./install /usr/src/asterisk-1.8.3

At this point, the install script will compile the allogsm module and install it into Asterisk's module directory.

Upon starting Asterisk it was evident that not all was well. Although the two GSM radios showed as being present and registered...

hpoo*CLI> allogsm show status

Port      Status              InUse   Provider           Home Zone      Signal Quality

1 (1)     REGISTERED          n       "none"             y              -73dbm
2 (2)     REGISTERED          n       "none"             y              -77dbm
3 (3)     INITIALIZED         n       "none"             n              not measurable
4 (4)     INITIALIZED         n       "none"             n              not measurable

P(1)> SIM is ready
P(2)> SIM is ready

I couldn't make a call across them. The phone would ring, but there would be no audio and it would cut off after a second or two. I noticed that the syslog was filling up very quickly with the same error many times per second:

Apr  7 10:30:57 pbx kernel: [  930.035989] Plx9030: Received PLX message ===> PLX_IOCTL_NOTIFICATION_WAIT
Apr  7 10:30:57 pbx kernel: [  930.035992] Plx9030: Waiting for Interrupt wait object (c3b19280) to wake-up
Apr  7 10:30:57 pbx kernel: [  930.040155] Plx9030: DPC signaling wait object (c3b19280)
Apr  7 10:30:57 pbx kernel: [  930.040167] Plx9030: Interrupt wait object awakened
Apr  7 10:30:57 pbx kernel: [  930.040171] Plx9030: ...Completed message

After some fiddling about with loading and unloading modules and not getting terribly far, I elected to test out's support. After a brief email conversation, their support people offered to SSH into my system in order to investigate, which I was happy for them to do. A short time later, the problem had been found and I have been issued with a new release of the driver. From what I can gather, this has something to do with early media, since the fix requires


to be set for each GSM channel.


So, this gives me two extra channels, GSM/1 and GSM/2, which are dialled from the dialplan in the usual way:

exten => _07XXXXXXXXX,1,Dial(GSM/1/${EXTEN})

and so on. Incoming calls get dropped into extension s in a context of your choosing, so these can be handled the same as any PSTN or ISDN call.

I wanted a simple way of round-robin balancing between the GSM radios for outgoing calls. As an early attempt, I've started off with:

exten => _X.,1,GotoIf($[${GROUP_COUNT(gsm1calls)} > ${GROUP_COUNT(gsm2calls)}]?gsm-out-2,${EXTEN},1:gsm-out-1,${EXTEN},1)

exten => _X.,1,Set(GROUP()=gsm1calls)
exten => _X.,n,Dial(gsm/1/${EXTEN})

exten => _X.,1,Set(GROUP()=gsm2calls)
exten => _X.,n,Dial(gsm/2/${EXTEN})

This is partially successful, but it will prefer card 1 if there are no calls. I really want to be able to balance call volumes across the cards so that I make best use of the available minutes on each SIM. I am planning to do this by logging the calls to an SQL database and then selecting whichever card has been used for the fewest billable minutes each time a number is dialled. But that's an improvement for the future.


SMS is fairly straightforward, it can mostly be handled from within Asterisk.

Incoming SMS messages generate an event in Asterisk and land on the 'sms' extension in the dialplan context specified in gsm_additional.conf. Details like the message text and the sender are stored in variables, so it's simple enough to pipe this through to whatever is desired. In my case, I've decided to forward my messages to an email address:

; Generate some useful messages on the console.
exten => sms,1,Verbose(GSM Port ${SMSPORT} RECEIVED: Idx ${SMSIDX} Number ${SMSSRC} Date ${SMSDATE} Text ${SMSTEXT})
; Create a temporary file containing the message and the required email headers.
; UNIQUEID prevents concurrent messages overwriting each other.
exten => sms,n,System(echo "To:" > /tmp/smsmail-gsm1-${UNIQUEID})
exten => sms,n,System(echo "Subject: SMS from ${SMSSRC}" >> /tmp/smsmail-gsm1-${UNIQUEID})
exten => sms,n,System(echo "" >> /tmp/smsmail-gsm1-${UNIQUEID})
exten => sms,n,System(echo "${SMSTEXT}" >> /tmp/smsmail-gsm1-${UNIQUEID})
; Pipe the whole mess through sendmail
exten => sms,n,System(sendmail -t -f ${SMSSRC} < /tmp/smsmail-gsm1-${UNIQUEID})
exten => sms,n,System(rm /tmp/smsmail-gsm1-${UNIQUEID})

Outgoing SMS messages are handled by a different extension which is as simple as:

exten => gsm1,1,gsm_send_sms(1,${SMSTO},${SMSBODY})

call this extension with the SMSTO and SMSBODY variables set and off it goes. I wanted to do this by email, which I was able to accomplish by using a python script I had already developed for chan_mobile:

The script uses the Asterisk Manager Interface, so it will need an AMI user. Append this to manager.conf:

# vi /etc/asterisk/manager.conf

and also make sure it is enabled in the general section:
# vi /etc/asterisk/manager.conf
enabled = yes
webenabled = yes
port = 5038

I used postfix to pipe the incoming messages to this script by creating a new transport in

# vi /etc/postfix/

smsgsm1 unix -      n       n       -       -       pipe
  flags=FR user=YOURUSER argv=/usr/sbin/ gsm1

Then, it's a matter of routing these messages to the new transport:

# vi /etc/postfix/transport ; postmap /etc/postfix/transport smsgsm1

If postfix doesn't already have a transport_maps setting, create one. Obviously this could break any existing postfix setup:

# postconf -e transport_maps=hash:/etc/postfix/transport

Now, new SMS messages can be sent be sending email to, and incoming SMS messages will be emailed to


Apart from difficulties accommodating the size of the card -- which can hardly be helped -- this was a pretty painless project. So, is it any good? Yes. The card and its drivers are stable and they include all the features I need.'s support have been helpful and were very responsive to some suggestions I had around SMS handling. I was impressed enough with the card that I've purchased a second PCIe unit for use at work to replace an ageing GSM gateway. If you're looking for GSM breakout for your Asterisk PBX, give the Allo GSM card a look.

New Comments

Some Rights Reserved