I'm looking into sending regular automated text-messages to a list of subscribed users. Having played with Windows Mobile devices, I could easily implement this using the compact .Net framework + a device hooked up to usb and send the messages through this. I would like to explore other solutions like having a server or something similar to do this. I just have no idea what is involved in such a system.
+2
A:
You can usually get an account with an sms service provider and send messages using an API (SOAP, resful http, smpp ....)
A google search for sms service provider yeilds many results with varying costs. Here is an informative article How to Choose an SMS Service Provider
Pat
2008-09-09 22:13:22
+1
A:
You could always try a third-party gateway service for this. Somebody like clickatell provide a number of services and APIs to make this work in a variety of countries. This isn't an ad! I only used their services for a technology pilot. There are quite a few of these around.
reefnet_alex
2008-09-09 22:13:40
+9
A:
It really all depends on how many text messages you intend to send and how critical it is that the message arrives on time (and, actually arrives).
SMS Aggregators
For larger volume and good reliability, you will want to go with an SMS aggregator. These aggregators have web service API's (or SMPP) that you can use to send your message and find out whether your message was delivered over time. Some examples of aggregators with whom I have experience are Air2Web, mBlox, etc.
The nice thing about working with an aggregator is that they can guide you through what it takes to send effective messages. For example, if you want your own, distinct, shortcode they can navigate the process with the carriers to secure that shortcode.
They can also make sure that you are in compliance with any rules regarding using SMS. Carriers will flat shut you off if you don't respect the use of SMS and only use SMS within the bounds of what you agreed to when you started to use the aggregator. If you overstep your bounds, they have the aggregator relationships to prevent any service interruptions.
You'll pay per message and may have a baseline service fee. All if this is determined by your volume.
SMTP to SMS
If you want an unreliable, low-rent solution to a low number of known addresses, you can use an SMTP to SMS solution. In this case you simply find out the mobile provider for the recipient and use their mobile provider's e-mail scheme to send the message. An example of this is [email protected].
In this scenario, you send the message and it is gone and you hope that it gets there. You really don't know if it is making it. Also, some providers limit how messages come in via their SMTP to SMS gateway to limit SMS spam.
But, that scenario is the very easiest to use from virtually any programming language. There are a million C# examples of how to send e-mail and this way would be no different.
This is the most cost-effective solution (i.e. free) until you get a large volume of messages. When you start doing too much of this, the carriers might step in when they find that you are sending a ton of messages through their SMTP to SMS gateway.
Effective Texting
In many cases you have to make sure that recipients have properly opted-in to your service. This is only a big deal if your texts are going to a really large population.
You'll want to remember that text messages are short (keep it to less than 140 to 160 characters). When you program things you'll want to bake that in or you might accidentally send multipart messages.
Don't forget that you will want to make sure that your recipients realize they might have to pay for the incoming text messages. In a world of unlimited text plans this is less and less of a concern.
jttraino
2008-09-09 22:40:29
+2
A:
I use AQL who provide gateways to send SMS messages, voice push messages, inbound SMS -> HTTP POST gateways and other stuff.
For Perl there's my SMS::AQL module to interface with them; whipping up something in C# should be pretty easy.
David Precious
2008-09-09 22:44:28