When I try to send SMS to US number I'm getting from API accept but message not sent.
In clickatell I see "routing error"
Same message to number outside of US is working fine.
I have no 2-way number configured - is it a must?
Any other ideas?
Legislation in the US requires the use of a 2-way number if you are communicating via text with customers in this region. This is the likely cause of your routing error.
Hope this helps!
Related
I'm trying to establish SMS sending with Node.js via Clickatell.
I've already tried the way described here: https://www.clickatell.com/developers/api-documentation/nodejs/
And both REST and HTTP requests from here (topics "How do I test my HTTP integration?" and "How do I test my REST API integration?"): https://www.clickatell.com/faqs/product-specific-faqs/platform/integration-testing/
In "SMS integration" area for both HTTP and REST APIs delivery type been set to: "Time critical delivery".
And i'm sending messages to number, that is in "test phones" list.
All the messages, I've sent to the server, are visible in "Reporting" area. But all them are stuck in "Delivered_to_gateway" status.
What i'm doing wrong?
UPD:
So, first message is finaly delivered to cell phone. After almost one and half hour of waiting.
I've also tried to send message to another phone with another cell operator ("Mobile network: Beeline (KB Impuls, VimpelCom)"), and it delivered in a minute or two.
So, detailing my question: it seems Clickatell have some kind of problems with delivering messages to "Mobile network: MTS (Sistema, Prim Telefon)". Can it be fixed somehow?
I'm testing out the service and it appears that sandboxed applications do not support incoming replies even if the reply is from a verified number. Can I get that confirmed?
If that is not the case, my second question is how Sinch handles self-signed certs for the endpoint on non standard SSL ports ... in my case self-signed on 8443.
Lastly, a gripe. As a developer I look for immediate feedback when errors occur with my integrations. I'm not really willing to wait 24 hours for a CSV to see what happened. Any roadmap here to timely error feedback?
To handle incoming replies you need to rent a number like most providers, you can rent a number in the dashboard https://www.sinch.com/dashboard/#/numbers assign it to your app and configure your callback for SMS.
To handle incoming sms, check out the documentation here:
https://www.sinch.com/docs/sms/#smsmessagingcallbackapi
And if you have multiple numbers assigned to you app you can set the from id in the body of the request
{
“from”:”your rentednumber”,
“message”:”hello world”
}
You can always check the status for a particular message using the API here
https://www.sinch.com/docs/sms/#checkmessagestatus as you probably know long code delivery is only carrier delivery and not handset delivery.
If you mail me at christian#sinch.com I can hook you up with some more credits to rent a number.
I am using Spring JavaMail for my Email communication application. How Can achieve the functionality that when a email delivery fails due the reason of wrong email address?
Achieving this reliably is not trivial. The protocol specs for SMTP in RFC 821 specifies a number of return codes. Notably 550 is what an SMTP server should return when attempting to send an email to a nonexistent address. I say should because most public-facing SMTP servers won't do this - they either quietly accepts the message and then drops it or, if they are a little more good-mannered, accepts the message but sends a "delivery failed" notice back to the sender ("from" address). Public services like MSN and Gmail will also blacklist senders if they send enough emails to non-existing addresses to prevent spam.
The reason for this is to prevent email-fishing and spamming.
So what you can do is to
Check for SendFailedException in your code. This will only work for servers that follow the SMTP specifications and actually send an error code back. Like I said, very few public servers actually do this.
Set up a proper mailbox for the address you use as sender and monitor that inbox for delivery failed notices. Note thought that these need not follow any common pattern, which is why this is non-trivial.
For the email servers that doesn't give any notice, you really have no way of knowing.
This is one of the reasons why companies buy mass emailing services from dedicated providers, since they have all these things already built to measure bounce-rate etc. But even with those, it's never going to be 100% accurate.
These FAQ entries might help as well:
If I send a message to a bad address, why don't I get a SendFailedException or TransportEvent indicating that the address is bad?
When a message can't be delivered, a failure message is returned. How can I detect these "bounced" messages?
I need to send and receive SMS messages, but not on a phone. Sending is somewhat easy, as there are oodles of gateways that can be used. The challenge that I'm running into is handling responses received.
Can anyone point in me in the right direction of services or devices that can handle 2 way SMS short of an actual phone.
SMS GATEWAY ME is an android app that you can download for free.
I like it because it's free and easy to use. All you do is send a HTTP post to their server and it sends out a message from your phone.
You can set up rules on the site to get it to forward incoming messages to your server using HTTP / Email as well.
There are some 2 way SMS gateways out there. A quick search found this one: http://www.txtimpact.com/api.asp all I did was google for 2-way sms gateway.
Here's an example that uses Wammu under Linux:
http://www.techytalk.info/send-receive-sms-using-gsm-modem-phone-ubuntu/
Here's another link:
http://www.developershome.com/sms/smsLinux.asp
And:
http://www.developershome.com/sms/
Good luck!
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