I am new to Twilio and tasked with evaluating whether to switch from our current service which is CDyne.
We have an application that uses SMS to interact with clients on behalf of staff using two-way SMS. The app automatically launches SMSs at certain trigger events and based upon the responses from clients decides what to do next - including asking further questions of the client. The SMS gateway I use currently allows me to include a reference id in outgoing messages. This id is returned when someone replies to the message. This makes it dead easy to look up everything related to the incoming message and form a decision and reply. Twilio does not seem to have anything similar. In fact, it does not even return the SMS ID of the original message which seems to make it a pain to determine the relation. I understand you could potentially look up the FROM and TO and trace it back, but with multiple phone numbers being used for the same client (staff can send messages directly too using a different phone number and there are several numbers being used for mass text messages), this is potentially (very) hazardous.
Question 1: Is there any (good) solution to this issue in Twilio, and
Question 2: If not, why not??? (It seems pretty obvious and simple to include a reference to the initiating SMS in the reply)
This is one of the many features that CDYNE offers at no cost to their customers.
To my knowledge, Twilio doesn't offer this feature.
For additional information on SMS Notify!'s additional free features, check out CDYNE's wiki.
Related
I was wondering how to create an SMS app like this where you text something say "1GB" and get some response from server. https://imgur.com/zwFFhzz
Sorry I'm new to USSD so apologies if amateur question. 1) How does an app like this work? What do I need to know to implement this?
To implement a USSD style application you need to have buy in and assistance from the network operator.
There are API's in various toolsets that will allow you to issue USSD commands to the device, these API's simply just pass the request straight through to the GSM modem on the device as an AT command (I can't remember off the top of my head what it actually is), and the modem unit is responsible for actioning it.
Some commands are processed directly on the device. For example if you type in * 06# (or #06 *) i forget which, most devices will display thier IMEI number. Many mobile sites too, will often have lists of "Secret Manufacturer Commands Your Not Supposed to Know" or "Special Commands that get you Free Credit".... :-)
All these are, are fixed strings built into the modems firmware by the manufacturer of the modem, not the device.
Most USSD style SMS's however are actually parsed and acted upon inside the providers network, usually on some kind of application server that's attached to or works in tandem with the main network SMSC's
For example when I worked on the Yalla Bill pay system out in Qatar we routinely had to attend meetings at QTel (The state telcom provider) to explain our routing rules and test them to make sure they where implemented correctly.
When I worked as a network engineer for Orange UK, i would often have to take care of service requests from vending machine companies that used USSD in thier firmware to send messages to a router at the provider's SMSc center.
The other thing to consider too, is that many providers will charge you A LOT OF MONEY to undertake a project like this, even more if you want them to just intercept anything sent to a given number and be routed directly back to you for you to act on in your own servers.
Some providers do have SDK's that allow some kind of similar access, sometimes for free, sometimes for a cost. I remember when I worked for Orange, you could join the "Orange Partners Program" and that got you some nice SDK code and access to various inner network stuff (I built a big chunk of it :-D) that allowed you to do some interesting stuff, since the company became EE and now part of BT however, I honestly don't know if any of it is still in use.
You can also get a shortcode, and while that's not USSD style SMS, you can have SMS messages sent to the code and those messages will then get forwarded onto a TCP server endpoint that you control.
I believe Twilio have this feature available, and I know MBlox do beacuse that's who I use.
It's not genuine USSD, but you can easily set up a shortcode, have folks send SMS to it, then use an SMS send API to reply back to the sending number.
My MBlox account for example gives me a pay as you go HTTP SMS end point, where I send regular TCP based get requests with a set of parameters, and they turn those into SMS's and send them to the recipient. I pay roughly 2p UK per text inside the UK, and it cost me £50 UK to set it up.
On top of that, I got an inbound SMS number, which costs me a fixed £50 per year, and any SMS recieved by the number is sent to a TCP/WEB based endpoint I provide to them, and which I then do what's needed with the recieved SMS when it arrives.
My inbound is a normal full length number though, for a "shortcode" number which is what your picture shows, you'll likley have to pay extra for that.
That looks like it uses a short code for the interaction, the response is parsed to make a purchase of the 2GB via another API.
I am php developer and for our project (mobile website developed using JQM) we need following functionality,
We need to send SMS to the customer and when customer reads the SMS we need to get the receipt in our site so we can store in database.
I have checked different SMS service api such as ,
Nexmo,plivo,tropo,Twilio,textlocal,clockworksms
Most of them providing facility of the Delivery Receipts such as "delivered/undelivered/QUEUED/ACCEPTD" which denotes delivery status but we want weather SMS is read.
Is this possible in mobile website?
I have checked some reference which gives idea about doing it with andriod app.
http://mobiforge.com/design-development/sms-messaging-android
Thanks.
I have worked with several of the SMS gateway APIs you mention and talked to a number of SMS service providers over 2+ years. The answer to your questions is: No, there is no such thing as a read receipt for SMS in general -- to the very best of my knowledge.
The API delivery status is all you get. And even that status is not 100% reliable. Text messages usually go over a number of hubs to reach their target and service quality and response reliability depend on these.
If you want to make sure the user received your message, you need to have them respond either on you website (with some code you supplied) or by responding to your SMS (in which case you would have to send your message from your own inbound number).
You can get a more definite answer when you do payments via SMS. In this case, there will be multi-step protocols involved that ensure completion of the entire messaging process.
I'm working on a web service that would use an SMS gateway to receive instructions from customers. Since this would be a commercial product I would like to implement a safeguard to protect our system from SMS spoofs. I don't want people impersonating others by spoofing their number.
I've noticed that Twitter allows people to tweet through text messages, how can they make sure that messages are actually genuine?
Is this possible, and if so how do I accomplish this? Or should I ignore this and just deal with it through support should they get through.
How do users spoof their numbers? Every service I've seen that allows users to interact from their phone requires a validation process first (like this). And carriers won't let you send messages through their system from a device they don't know. SMS gateways also provide safeguards to prevent spoofing. So I'm not sure how big a problem this will be for you. I would worry about it once you start encountering it.
Unfortunately with services like Spoofcard it is sometimes possible for someone to spoof an sms message. Spoofcard even works in the US even though US carriers have historically been better at blocking spoofed text messages. You can try it yourself at their site. I was able to spoof a text message to/from a tmobile number.
The solution is to implement a verfication question/text for the user to answer but this will cost you/them an additional text message.
Fogmo, a popular SMS spoofing site, allow you to contact them and add any number to a 'blacklist'. This would ensure that your customers' phones won't be spoofed to, or from. It's well worth contacting them (and similar sites) to request this.
Do all cell companies have open APIs that allow you to send SMS messages like Twitter does?
Do you have to pay to do this?
Many (most?) mobile companies have email gateways allowing you to send an SMS. For AT&T I believe it's phonenumber#text.att.net, but each provider will have a different address.
This wikipedia article summaries it pretty well. Some cell companies have easy formats. For example, Verizon uses number#vtext.com.
It depends what country you're in.
In the UK to pay to send - receiving is free.
Take a look at messagepub. They provide an easy API so that you can send SMS messages from your application.
If you want a reliable solution then yes you will have to pay for it, there are some limited free versions.
We used Clickatell with an earlier project http://www.clickatell.com/developers.php
It gets a bit more complicated. E-mail gateways may work for some carriers, but not others. As noted, it's based on your cell carrier, what we can the aggregator, and possibly a third-party "intercarrier". However, it also depends on volume. If you're just sending the occasional SMS via e-mail, it certainly can work, but, it's occasional in use, and you don't get the confirmations that your phone normally sees. For volume transfers of messages, you typically need to talk to your carrier about access to their "SMSC gateway". The SMSC gateway speaks an internet protocol (SMPP) to transfer messages from your app, into the carrier clouds. It it designed for volume, and you get response codes for your messages.
What is the easiest way to set up an SMS alerting system so that I will receive notification if my server doesn't respond or a GET query doesn't return correct content?
You can completely outsource the monitoring and alerting, for example by subscribing to Pingdom. The most basic Pingdom plan will monitor up to 5 services (including using HTTP GETs with optional content pattern matching) and send an SMS after a configurable amount of downtime.
If you want to roll your own solution, the first thing to get right is the monitoring software. Many, many third party solutions exist for this, from the free to the outrageously expensive. Of course, rolling your own "try a GET and do something if it doesn't work" script is always an option, but as with all software, feature creep may mean that you're just re-implementing existing solutions soon...
For the SMS notification, using an e-mail-to-SMS gateway might work for you, if you're in a territory well-served by such services. Most US providers, for example, provide free gateways, whereas in Europe they tend to be run by third parties and pay-only. As already suggested, Google is your friend here. Also, your monitoring tool may support sending notifications directly using a cellphone/GSM modem attached to the monitoring server.
Often I've found that what you need is a SMS modem attached directly to your monitoring server. What if the problem is the network connection?
What you want is an SMS gateway. There are surely some service providers local to you. Unfortunately, they are a bit hard to find. Try asking Google...
You can get a service like http://www.serviceuptime.com/ and the send an email to your-number#a-domain-your-provider-gives They usually have the exact domains for the providers on their respective websites but you could just try #t-mobile.com if your provider is t-mobile for example.
If you want to write your own tool should be pretty straightforward - send GET request if you dont get the expected response send email. You should run it from 2 different locations from 2 different ISPs tho because if there are routing problems and the request doesnt go through you'll get smsed