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)
Related
I use SMPP routes towards providers, which have others providers in order to send SMS until the local operator.
My question is... How can I know how many provider hops there are in each SMS via SMPP?
I mean, since the SMS is sent towards the next provider until the SMS is delivered in the handset, does exist any way to know how many hops there are?
Could I add any information in the SMS in order to get this information?
I would like to get this information in order to know if the route is good or not.
Thank you.
With standard SMPP it is not possible to know how many hops (i.e. SMS gateways and SMSCs) there are between your application and the handset.
Monitoring the latency between submission by your application and delivery to the handset can provide a hint at there being multiple hops. This approach isn't reliable as high latency could simply be a slow single hop rather than multiple hops.
Asking your immediate provider how they route your messages can provide some insight. If they send directly to an SMSC belonging to handset's mobile network operator then you know that it should only be a hop from you to the provider and then another from them to the MNO. Probes, or your own testing, can be used to confirm if your message is being routed directly to the handset's MNO. In such cases you will see an SMSC address (SMSC GT) in the receive SMS that belongs to the handset's MNO.
It is not part of the SMPP protocol to know the hops to the final SMSC that delivers your SMS to the destination mobile. Number of hops does necessarily account for delays in SMS delivery.
If you will like to know if a certain route is good or not you could use other metrics like how many successful delivery reports have been received for SMSes sent via that route to build a table of good routes and bad routes.
Definetly not part of the SMPP protocol. For sure your sms won't be delivered via SMPP only, but also via SS7. The performance could depend on so many factors ... I think the best way to evaluate a 'route' is ( as other have said) to build some metrics/kpi's yourself and analyze them.
Could anyone please provide a real-world example of using zmq with the router/dealer pattern, and explain its advantage over the more simple publish/subscribe pattern? Thanks.
A 'real-world' example: Stock market simulation
Router socket is the server (or 'Market'), Dealer sockets are the clients (or 'Traders').
Traders place buy and sell orders by sending relevant 'order'
messages to the Market.
The Market responds immediately with an 'acknowledge' message
Sometime later when an order is fulfilled the Market sends
'order complete' messages to all involved traders.
This sort of behavior would be quite cumbersome to implement with pub/sub as you would need both Market and Traders to run a Publisher and a Subscriber socket to allow the 2 way communication. There would also be privacy concerns if all completed transactions were 'published' rather than sent direct to the relevant traders. (Trader B should not get to know that Trader A bought or sold something).
What makes Router sockets different
Sending and receiving from Router sockets are slightly more complicated to allow the asynchronous responses:
Any incoming message has an identity frame prepended to the incoming message upon receipt, this indicates which client the message came from.
The first frame of any sent message is removed and used to identify which client to send the response to.
The 'identity' is a string and will be set to something unique per connected client by default, but you can set custom identities on client sockets via socket options.
Dealers send their client ID with each message. Router is able to accept connections from multiple dealers and each time a message is received, it is able to discern which client sent the message. It is also able to send messages to specific clients by referring to their IDs.
Real life example: game server lets clients join a room until it is full. It keeps track of each client ID in the room. When room is full, it loops over each client ID within that room and sends them a "game started" message.
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.
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.