I'm looking for the best practice, proper and "mobile carrier accepted" way of authorizing the sending of SMS/text messages to a cell phone number so that it can't be flagged as spam or abuse.
Basically, I want the user to enter in their cell phone number in my web app and then I want my web application to send some kind of SMS to them asking them to do something that tells the carrier and my app that they accept SMS messages from my web service. I do not want to spam - I only want people that want to receive the messages to their phone.
Also, I'm assuming that I can just SMTP to "email" text messages to their phone as well. Hopefully there's not a caveat to this method.
I have a little experience in this area and AFAIK there is no 'opt-in' list. However, carriers typically use the keyword DELETE to allow users to block messages.
Most carriers support a SMTP gateway addresses but you will need to know the carrier for each number. Here's a list to get you started. Also most messages received via a SMTP gateway will appear to come from different numbers on the users phone. (This is annoying for iPhone users who are accustomed to grouping of messages by individuals.)
If you are willing to pay per message services like EZTexting can take away some of the pain by doing the carrier lookup for you or sending your message via a direct, and more expensive, SMS gateway.
Here is a good overview :
http://www.acma.gov.au/webwr/consumer_info/frequently_asked_questions/spam_business_practical_guide.pdf
The US is actually behind with SMS regulations. We typically adhere to EU and Australian Legislation, which are stricter. The US will get there.
From a technical perspective:
You can use our Red API, just log on to www.redoxygen.com and select developers.
Related
I hope to create a web server that can give some extra facilities for SMS Service Providers. Can I send SMS through internet? If its possible then, Are there any libraries for Send and Receive SMS over the internet?
There are many different options to send SMS over Internet, but most popular are the following:
Connecting to SMSC of mobile carriers directly (usually via SMPP protocol).
Connecting through some SMS aggregation service like Clickatell mentioned in previous answers.
Choice between these options depends mostly on non-technical issues:
Required coverage (mobile carrier will provide only messaging inside it's network).
Premium Rate billing possibility (this requires closer work with carrier).
Well, price too... :-)
Technically most popular options are:
Specialized protocols like SMPP (Short Message Peer to Peer).
HTTP based protocols provided by SMS aggregators.
If you need unified solution, I recommend to use Kannel open source SMS gateway that support many popular transports (SMPP, CIMD, UCP, HTTP, etc).
You've got www.Nexmo.com www.tropo.com www.twilio.com www.smsified.com ... and so on...
You can use http://www.clickatell.com/ which gives you a few options such as sending SMS one by one, or by using bulk files such as XML.
I found the clickatell API to be really usefull and easy, I managed to add SMS capability to an existing website in a few hours by creating a simple class to wrap up all the methods.
One thing to remember though this is not going to be free for you, there will be costs involved depending on where you send the text to, and where you are based.
You can send SMS programmatically through TheTexting API, They provide cheap rates and their service is really good.
Full disclosure: I work for company that makes this product.
I read that a GSM modem can only receive up to 30 SMS per minute. What would you do if you need to receive more than that? Is there another technology?
I think you might want something different to those answers listed at What are the best practices for building an SMS server
If you just have one service that is running where you want to receive many SMS then it would be most cost effective (and simplest) to avoid integrating with a mobile network operator and instead use a SMS aggregator. These often call themselves SMS gateways, but they are independent companies and not a mobile network operator's gateway.
An SMS aggregator acts as a middle man between you and the networks - they have agreements with many network operators and this interconnection means you can link with one aggregator and get access to almost every network in the world.
Aggregator's usually advertise for outbound SMS (where you are sending an SMS from your application to a user), but they all offer inbound SMS as well. Depending on your country you could opt for a premium number or free to receive number. A premium number would mean that the person sending the text message would pay extra money to send you a message - you may want this for a commercial service in order to bill the user. A premium number would also mean you receive a share of the money the user paid to send you the text message. A free to receive number would not cost the person sending the text message anything more than it would normally cost for them to send an SMS. Almost all aggregators will charge you a monthly rental for a free to receive inbound telephone number, but no additional charge per message received.
You can expect to integrate with an aggregator using HTTP or SMPP. HTTP is usually the easiest and the aggregator will want to know where to send the HTTP post when a message is received on your telephone number. Therefore you will need some sort of service that is running to receive the HTTP post from the aggregator, and possibly a way to reply to the user by sending another HTTP post back to the aggregator asking them to forward a message to the user confirming receipt of the inbound SMS message.
SMPP is a more robust protocol and is often used for high volume SMS applications - unless you already have SMPP experience or are sending many hundreds of thousands of messages you may want to avoid SMPP as it is difficult to implement until you have a lot of experience with SMS.
Some aggregators will provide their own platform where you don't need to have your own service running. For example you could setup a simple "autoresponder" on an aggregators website, this would receive the inbound message from the user, then autopmatically respond with a "thank you message". All interaction is done by the aggregator and you can log on periodically to download statistics or look at the messages people have sent.
Popular aggregators are:
InfoBip
Silverstreet
mBlox
If you do not have your own platform for managing the SMS interaction then either use the aggregator's own platform of install your own SMSC gateway. Some SMSC's are:
Kannel - Open Source, fairly difficult to install and manage.
NowSMS - Commercial software. Powerful, windows only, easy to use SMPP integration and has a 30 day free version. Allows GSM modems, HTTP and SMPP integration. Most expensive of these options but pricing is based on number of messages you want to send OUT per second / minute so if you're not planning on sending many out and only receiving them maybe this would be a viable option. There's a cheaper version where you can use one GSM modem (mobile phone) connected to a computer with a USB lead but as you will only have one GSM modem and no aggregator's you are limited to the speed at which your device can receive inbound SMS.
Ozeki - Commercial software. Lots of documentation available and the support team are very responsive. You can add local GSM modems or aggregator's using HTTP or SMPP.
I am trying to implement my own theoretical SMS web service (just to understand how this stuff works, I have posted a few other related questions, I think this is it).
Set up a PC. It takes requests from a website I make to send out SMS messages: a user-entered destination phone number, and a user-entered text message
I get a GSM modem, or just a GSM phone. I connect it to the computer.
I get a service plan from Verizon or whoever, some sort of unlimited SMS messaging plan.
They give me a SIM card, which has my unique phone # attached to it (ex: 555-5555). I stick this in the GSM modem.
I get some application (like Kannel) which handles interfacing with the modem and sending out the messages from my machine.
Now users can visit my theoretical website, enter a phone # and message. I grab that data, forward it to Kannel. Kannel interacts with the modem, passing it the data for the message. The modem interacts with the carrier network I signed up with, and broadcasts the actual SMS to it. The carrier network handles routing the message to the actual destination.
This is my understanding of how it works. Now the recipient of this text message will see this message pop up on their device from my modem's number (555-5555). In fact, all the thousands of people using my service will all see the same origin phone number.
If that's so, how do these 3rd party SMS applications give people unique #s for replying to messages they send out?
For example, when I sign up for one of these 'free' SMS services on iPhone, they assign me a unique user ID, like '123'. My friend is on a normal AT&T phone plan. He can send an SMS addressed to '123', and somehow I will get the message. How does AT&T know to route that to this third party service? I can't imagine that they would somehow get a new SIM card with a unique phone number per user that signs up for their service!
Thanks for all your help.
Thanks
The cell network carriers (e.g. AT&T, Verizon) actually rent out custom phone numbers (called "short codes") to 3rd parties to use.
You usually can't acquire these short codes directly from the carrier, but you can go through a 3rd party company to rent the short code. I've worked with companies like MBlox and OpenMarket to use carrier short codes. These companies are sometimes referred to as "SMS/MMS messaging aggregators," because they aggregate messaging services across multiple carriers and offer them to people/companies like you. Most of the time the aggregator will expose some sort of API (SOAP/XML or binary protocol) to access the messaging services to send and receive messages.
There may be other ways to do it, this is just my experience.
I think your comment at the bottom of your message is misleading.
Your friend probably doesn't send a message to "123" infact he probably sends "123 hello george" to a central number, which in turns routes "123" on to you, behind the scenes.
FWIW, mobile messages can appear as though they come from anything (including, for example, a word, and not a number).
Your general underlying assumption as to how gateways work (acquiring simcards) is accurate enough.
Simple question: I'm researching SMS gateways for the U.S. We've implemented in Europe before, but I can't determine if renting a "short code" is required for for subscription automated outbound SMS traffic in the U.S. or if that just varies by SMS gateway provider. My hunch is that it is required, expensive as it is, but I need confirmation before I'm comfortable presenting that to my manager.
It varies by carrier. Some carriers will allow you to use an email gateway for a production-level application; some will not.
More to the point, you will have far, far less headaches down the road by actually using the short code and native SMS than an email gateway, which tend to have fairly diverse latency, availability, and functionality behaviors.
I previously worked for a company that did some SMS work, and I believe a short code is required.
If I understand your question correctly, most SMS gateway providers in the U.S. don't require a special short code for outbound SMS. I am using SMS in an app right now without my own shortcode.
They do require it for inbound SMS though. There are alternatives to that too, as you can use a service like Textmarks.
We are building a web app that should be able to receive SMS messages and store the information contained in it in database.
Which methods have you used? Which service providers are out there that can assist?
http://www.clickatell.com/ are massive and it works exactly like it says on the tin. You pay for a phone number and sms messages sent to that end up hitting a URL on your site to deliver them just like someone posting a form.
I'd recommend using a service such as TextMarks. TextMarks is free, and lets you pick a keyword for your service that allows users to route messages to you through TextMarks' shared short code, 41411. The only catch here is that they reserve 20 characters in each message for short advertisements to pay for their services.
If you ever outgrow their ad-sponsored services, you can upgrade to a premium version that doesn't include ads.
Another (cheaper) alternative is to have your users send text messages to an email address like sms#yourapp.com. Then you can have a background thread that's looking at the email account and puts the messages into the database.
I've implemented and tested this approach with major US carriers with everything from smart phones to pay-as-you-go "crappy" phones without a hitch.
When the user sends the SMS to your email address you get the SMS email gateway address (e.g. 8055551234#vtext.net) so you can send response messages.
The only downside is that it's a bit more difficult to find the "send to email address" options on most phones, but it is (basically) free for you. This is especially helpful for reducing costs while testing out workflows. Those ~3 cents for each SMS add up pretty quickly, especially during automated testing.
When you want to support SMS numbers you can configure most SMS gateways to send an email to an address, so you won't have to change your infrastructure to support a "real" SMS messages.
I haven't done it yet, but I guess you could also setup an Asterisk system on your server, then get a regular VOIP acccount (which Asterisk hooks into) and configure the Asterisk server to forward all SMS to your application. This article might help setting up the Asterisk server.
I've had experience using MX Telecom as an SMS Gateway. Essentially they posted data to our web service every time we received an incoming SMS. The application in question was also sending SMS messages as well and we just did an http GET to a web page of theirs.
I can't speak to the business end (i.e. cost), as I was just in charge of implementing the features - but working with an SMS gateway is really very simple from a development perspective.
+1 on sebastian i was jsut writting pretty much the same
if you are working with ruby you might want to have a look at adhearsion
You can use SMS gateway software which will receive SMS messages through a GSM modem or 3G dongle connected to a PC and POST them to your website via HTTP. Eg: this software