How does Twillio get to send so many messages via SMS? I am thinking about making my own service for my company for internal use, but I am trying to discover how they managed to do that in such a large quantity while still remaning afloat? Are they using some sort of connection with a large set of phones, and automagically sending the messages from their actual devices? Wouldn't their service provider frown upon that kind of volume?
They are at most using SMPP protocol to send SMS messages directly to their service. SMPP is a protocol widely used for sending mass (bulk) SMS messages between third-party and operator.
Excerpt from Wikipedia:
The protocol is based on pairs of request/response PDUs (protocol data
units, or packets) exchanged over OSI layer 4 (TCP session or X.25
SVC3) connections. PDUs are binary encoded for efficiency. Data
exchange may be synchronous, where each peer waits for a response for
each PDU being sent, and asynchronous,
See full Wikipedia article: Short Message Peer-to-Peer
Related
If you sent out an SMS message from a SMS Gateway, will send it to the mobile network so how we get the perfect result for SMS delivery..? they send us the number of successfully send message but not in detail like sent Successful on this numbers and for this number are failure
It totally depends on what SMS gateway you use, what destinations you send to (even within a country there are differences between operators)
You have 3 options really, and these are country/SMS route dependant:
No DLR support
Network DLR (so you get updates if the NETWORK has received the SMS)
Handset DLR (you will get updates if the HANDSET has received the SMS)
The handset DLR is the most reliable, but in general, depending on DLR for delivery stats is not something you want to do too much. Operators fake these (antispam measures), SMS route suppliers sometimes fake them to be able to offer lower pricing (by not submitting 10% of the messages for example), etc.
Only way to be sure if an SMS is delivered is by using testing services.
There are a number of them around. If you use services like Messagebird or BudgetSMS.net, you can get the DLR updates pushed to your server, for further processing on your end (they are linked to the sent SMS itself)
Please I'll like to know the difference between SMS and SMPP or at the very least get pointed to a good resource that breaks down this difference in layman terms. I'm currently on a project where the product vendor says the product only supports SMPP for inbound messages so it cannot be integrated to an SMS gateway. I've tried researching the fundamental peculiarities of SMPP that makes the integration with an SMS gateway for inbound messages impossible for this product but my research has yielded nothing material so far.
I'll really appreciate your feedback as the project is basically at an impasse due to the insistence of the vendor on SMPP.
SMPP is the protocol used to send SMS. Currently there are 2 ways to send a SMS. Either by SMPP (beneath the TCP protocol) or by SS7 (which requires hardware and is costly).
Usually SMS gateways are SMPP which is weird that you are not able to integrate it with it.
In brief, the SMPP protocol does the below:
Client binds to the server (Bind Request) / Server Accept or Reject
bind (Bind Response)
Client Sends SMS (Submit-SM) / Server accepts or Rejects SMS (Submit
Resp) server also includes the message Id
Server sends the DLR with the same message Id in the submit
response(Deliver-SM) / Client acknowledge the DLR (Deliver Resp)
Theres also an Enquire Link sent from the client and its response from the server to keep the connection from timing out usually 30 seconds.
Here's a link describing the SMPP Protocol in details:
http://opensmpp.org/specs/smppv34_gsmumts_ig_v10.pdf
Right now I'm using socket.io with mandatory websockets as the transport. I'm thinking about moving to raw websockets but I'm not clear on what functionality I will lose moving off of socket.io. Thanks for any guidance.
The socket.io library adds the following features beyond standard webSockets:
Automatic selection of long polling vs. webSocket if the browser does not support webSockets or if the network path has a proxy/firewall that blocks webSockets.
Automatic client reconnection if the connection goes down (even if the server restarts).
Automatic detection of a dead connection (by using regular pings to detect a non-functioning connection)
Message passing scheme with automatic conversion to/from JSON.
The server-side concept of rooms where it's easy to communicate with a group of connected users.
The notion of connecting to a namespace on the server rather than just connecting to the server. This can be used for a variety of different capabilities, but I use it to tell the server what types of information I want to subscribe to. It's like connection to a particular channel.
Server-side data structures that automatically keep track of all connected clients so you can enumerate them at any time.
Middleware architecture built-in to the socket.io library that can be used to implement things like authentication with access to cookies from the original connection.
Automatic storage of the cookies and other headers present on the connection when it was first connected (very useful for identifying what user is connected).
Server-side broadcast capabilities to send a common message to either to all connected clients, all clients in a room or all clients in a namespace.
Tagging of every message with a message name and routing of message names into an eventEmitter so you listen for incoming messages by listening on an eventEmitter for the desired message name.
The ability for either client or server to send a message and then wait for a response to that specific message (a reply feature or request/response model).
What software/hardware do the SMS centers use to make the following possible:
An SMS is received to a number. The SMS is routed to one of X machines (Mac/PC). An operator responds to the sender.
It seems that a GSM modem is needed? However, I have trouble understanding the architecture.
Is there any plug-and-play solution? Are there any specific frameworks/languages/tools for building such a system? How do you route incoming messages to machines? How do you queue outgoing text messages?
For getting SMS there are at least 2 types of numbers exist: real (simcards) and virtual (VLN).
Real numbers:
-simcards you need to own and to insert into devices called gsm-gateways or gsm-modems, gsm-modem pools etc. These devices are like collection of many mobile phones, they will collect and/or keep/forward all incoming SMS (to some DB, to server/script etc.)
-to make lot of users manage SMS you need some tool. Most common - webserver with appropriate GUI software. Webserver collects all SMS into DB (by downloading them from gsm-gateways via protocols like SMPP or HTTP, or by geting as HTTP Requests from devices). Via some WEB-GUI you can make messages available to your operators for replying.
Virtual numbers (VLN) (provided by most SMS operators):
-no need for hardware. Just contract operator for numbers, then connect via HTTP API or some protocol like SMPP for collecting inbound SMS on these numbers, or get them on your server as HTTP Requests from operator's server.
-WEB-GUI the same as for real numbers
So basically the flow is:
for Real numbers: SMS Origination from phone -> GSM-operator (Vodaf... etc) -> SIM-Card (Vodaf...) in GSM-gateway -> GSM-Gateway API -> Your Web-GUI
for Virtual numbers: SMS Origination from phone -> GSM-operator (Vodaf... etc) -> SMS Service provider (Clicat... etc.) API -> Your Web-GUI
There are some software titles free and paid available for each task.
Any organisation with a large amount of traffic will most likely use a connection to an opertors SMSC (SMS Message Centre in an operators network) via an IP interface and the SMPP protocol.
The SMPP protocol is an open standard designed to bridge the IP web world to the CCITT No.7 messaging world in the telcos, and allow web services be built to send an receive SMS's.
There are also providers who provide aggregation services for SMS - some are independent and some are 'preferred partners' of an operator (e.g. http://developer.att.com/technical-library/app-certification-policies/working-with-aggregators)
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.