try using @txt.att.net 
-Jim P.
I've had issues sometimes with Sprint throttling email -> SMS, especially if the message all look very similar. Also had the stop delivering some emails (our trouble ticket notification system specifically, they would accept the message and effectively bit bucket it).
We've had very good luck using qpage (http://www.qpage.org/) to send messages via TAP. It has worked for years to our Nextel's (NPA-NXX-NOTE), and I now do the same on my Treo from Sprint. Just need to locate a TAP terminal for your carrier. We have nagios (and various other bits of software) submit pages to a qpage daemon, and it handles delivery via dedicated modem, which is nice in case all of your upstreams decided to die @ the exact same time.
-Patrick
[...]
Analog modem and voice line and TAP software (like sendpage or qpage)
I like the TAP route with qpage.
I was starting to get spam via my provider's e-mail to SMS gateway. They were
kind enough to disable it, and we use TAP to send messages. I've never had
any serious delays when using this method.
Now, if I could just convince them that the messages are "on net" rather
than out of network...
Hi All,
Our experience with using the e-mail-to-SMS gateways provided by
AT&T/Cingular and T-Mobile:
AT&T: Messages come through with very little delay (even during alert
storms).
T-Mobile: 10-15 messages/hour are allowed through...then T-Mobile
refuses the IP for about an hour.
-J
:> Some mobile phones you can talk to via AT commandset, either
:>via USB cable or something else. (eg: I have used a Nokia 6230 with usb
:>cable.. you can also use bluetooth). If you pay $5 or whatnot for unlimited
:>SMS on a el-cheapo plan, it might work better than using the SMTP gateway
:>(when tied to Nagios, etc..) as you can send SMS messages with the AT
:>commandset.
:
:Assuming, for the moment, that there's a cell signal available in
:your data center... Not always the case, unfortunately.
I recall a datacenter in BOS that went so far as to nearly eliminate RF
using corrugated aluminum inside the walls (you know who you are 
The simple answer is that it depends on how critical such notifications
are. Address it as you would your upstream connectivity, and make it
as redunant as is justified.
For my meager purposes, smtp is usually fine. For truly critical
issues, my nms will use a dedicated phone line to dial a handful of
on-call techs, with no more info than caller-id. If that id shows up on
their phones, immediate investigation is needed. It's embarrassingly
primitive, but it's never failed.
Cheers,
Brian
As long as you're sourced from ARIN IP space. If sourced from
for exmaple, APNIC space, you may have mixed results or lack of service.
This has been my experience, even when there is proper rDNS, SPF, and other
such methods being used. This means you need to relay via an alias elsewhere.
- Jared
I used a wide range of alerting methods. The most reliable that I have
found (at least for Cingular/AT&T phones) has been TAP. Since this way the
monitoring server can have its own dedicated modem / phone line (separate
from the PBX). Thereby you no longer have to use any of the monitored
equipment to relay failures notifications (i.e. chicken and the egg).
Because a TAP solution is total separate, one thing we had to do was a daily
"test page". Basically every day at noon, a fake check would get tripped on
the monitoring system and send an alert to some of the folks that maintained
the monitoring server. This way if there was a breakdown in the monitoring
system they would (hopefully) notice that they did not get the daily page
and fix the problem.
Regards,
Adam Stasiniewicz
I would never trust SMTP for all the reasons already mentioned. Primarily if my network is dead, I still want to get paged about it. Relying on the import policy of another organization in the hostile port 25 environment is also bad voodoo.
We’ve used a mix of TAP and SMS for many years with varying success. When the cell providers started dropping their TAP gateways, we went through a few GSM modems. First a Nokia on a cable, but the thing would do dumb stuff like charge the battery, and with the cable connected go ahead and drain the cells unless someone walked by daily and reseated the power cord. Avoid tethering phones, you will likely run into something to drive you nuts. Next was a Sierra 750 PCMCIA GSM modem, which supported the standard AT command set (I forget the ANSI spec). That was fine once overcoming the motherboard not assigning an IRQ, but once a week it’d stop responding to commands and have to be reseated.
The final, ultimately reliable setup, which I recommend, was a Falcom Samba 75 USB GSM modem (quad band) talking to smstools. With unlimited SMS plans, two modems on separate networks, and some cron scripts, they could also monitor each other every hour to ensure they were sending and receiving pages. We also did a daily “paging system is up on X” to oncall similar to what another poster mentioned. Also we configured smstools to call an error script which’d send warnings another way (IRC in our case) if the modem wasn’t responding as expected (failed to send, receive or init).
Ken Simpson wrote:
> It's more effective to spend the money on SMS messages. Mobile
> providers are forced to use very aggressive anti spam
measures, which
> can add significant delays in message delivery.Recommendations on software and modems?
We've been having fun with these foxbox devices:
Low power, solid state embedded linux devices.
Sending sms's is as easy as wget --post-data. We have 2 monitoring
servers and 1 foxbox connected to each via crossover ethernet, and we're
using a different cellphone provider for each.
// nick
Is SMTP to a mobile phone a fundamentally flawed way to do this?
Yes. It takes too long and nobody is responsible for making sure it is
fast.
SMS is better, even though it can also suffer from delays, because
somebody is in charge of making sure it is fast. The worst delays I
witnessed were over an hour during the terror attacks on London a couple
of years ago.
We have an SDK http://web21c.bt.com/ that lets people build SMS sending
into their applications for event notification, so if you are in Europe,
this may be useful. I know other companies have software for sending SMS
that works with a PCMCIA GSM card plugged into a computer.
If guaranteed turnaround time is important, then becoming an official
customer is the best way of communicating those needs. Even better if
your supplier is selling you the SMS service specifically for event
notification. Outside of having a supplier who offers an SLA on SMS
delivery time, I'm not sure that it is wise to rely on SMS for notifying
your first responders.
--Michael Dillon
gsmd (from gsmlib http://www.pxh.de/fs/gsmlib/), a couple of small scripts, and a Siemens MC35i, working nicely with nagios at $work. gsmlib should be able to talk to most any GSM device with a serial port (data cards included), since the AT commands for sending and receiving SMS are standardized.
Stefan
Hello folks,
It seems especially prevalent when MANY things are sent at once; if, for
example, a central piece fails, and dependent pieces suddenly fail as
well.
I'd probably recommend implementing some sort of parent/child system
to reduce the number of messages you receive. Couple that with an
acknowledgment syetem to re-page every so often to remind you, and it
works out really well. That way you're not overloading the person
receiving the alerts, and, especially with SMS, it costs less to send
them.
As an experiment, I wanted to try to summarize all the answers given on
this question, hope this helps someone.
Suggestions given:
* modem and TAP gateway
** TAP numbers at http://www.avtech.com/Support/TAP/index.htm
** Software: sendpage or qpage
* Mobile phone with a serial port and AT commandset
** Software: sms-tools gnokii gsmd
** Issues: not reliable because of battery drain
* Purpose-made GSM/CDMA modems
** Software: same as above
** Manufacturers: Intercel, Sierra 750 (PCMCIA), Falcom Samba 75 (USB)
* Purpose-made GSM-IP modems
** Manufacturers: http://www.acmesystems.it/?id=70
* Pages via DTMF
** Hylafax/asterisk
-alex [for mlc]
s/serial/usb/ to solve the power problem
-Jim P.
Does anyone have experience and/or opinion (positive or negative) with the Multi-Tech cellular modems?
http://www.multitech.com/PRODUCTS/Families/MultiModemCDMA/
I’ve been quite pleased with their standard analog kit, so I’m hoping it translates well into this product line.
* matthew zeier <mrz@velvet.org> [2007-09-06 23:39]:
>It's more effective to spend the money on SMS messages. Mobile
>providers are forced to use very aggressive anti spam measures, which
>can add significant delays in message delivery.
Recommendations on software and modems?
the UMTS PC-Cards you can get rather cheap these days show up as usb
controllers with usb-cereal converters behind. add a little kermit
magic and you're done (this is on OpenBSD).
unlock at boottime (replace 0000 with your PIN):
#!/usr/local/bin/kermit +
set line /dev/ttyU0
if failure exit 1
set carrier-watch off
set input echo on
lineout "AT+CPIN?"
input 10 "+CPIN: SIM PIN"
if failure exit 1
input 10 OK
if failure exit 1
lineout "AT+CPIN=0000"
input 20 OK
if failure exit 1
lineout "AT+CPIN?"
input 10 "+CPIN: SIM PIN2"
if failure exit 1
input 10 OK
if failure exit 1
exit 0
send an sms:
parameters: number "message"
(+49177... is the SMSC, replace by your provider's one)
#!/usr/local/bin/kermit +
set line /dev/ttyU0
if failure exit 1
set carrier-watch off
lineout ATZ
input 10 OK
if failure exit 1
lineout AT+CSCA="+491770610000"
input 10 OK
if failure exit 1
lineout AT+CMGF=1
input 10 OK
if failure exit 1
lineout AT+CMGS="\%1"
input 10 >
lineout \%2
output \26
input 100 ok
if failure exit 1
exit 0
of course I have some shell around it for failure handling (retries) etc