I am in the US and have been using a Clickatell Central API account and connect through HTTP API. Here is an example of the string I used :a href="http://api.clickatell.com/http/sendmsg?user=ljaxxxxxx&password=9ixxxxxx&api%0b_id=3xxxxxxx&mo=1&to=1xxxxxxxxxx&from=1xxxxxxxxxx&text=Thank+you">http://api.clickatell.com/http/sendmsg?user=ljaxxxxxx&password=9ixxxxxx&api
_id=3xxxxxxx&mo=1&to=1xxxxxxxxxx&from=1xxxxxxxxxx&...> Some information has been blocked for security purposes. The problem is FLSMS is not passing the MO and the TWO-WAY number to Clikatell gateway. Although the message is marked SENT in FLSMS but not DELIVERED because the MO and the TWO-WAY have not been passed, so it ends up in "Routine Error". If anyone is familiar with this kind of issue please let me know. FYI, I have contacted Clickatell and they are the one who told me that is what's happening.
I haven't come across this before, but from Clickatell's documentation "This is only applicable to clients that have subscribed to a two-way messaging service." Is this an extra service you've requested from Clickatell?
Also, was the error "Routine" or "Routing"?
And finally, which version of FrontlineSMS are you running?
I'm having this same issue and am trying to work with Clickatell support today as well (for an urgent project we need working today). It is "Routing Error" that shows up on the ClickaTell control panel. ClickATell says it is because the app is not specifying the mobile origination variable as well as the the assigned two-way number.
The URL construction needs to be:
I'm using 188.8.131.52.
I just spoke with support. They said the mo=1 mobile origination parameter and from=assigned two-way number parameter is a US only restriction. It has to do with carrier restrictions in the US.
I've not found a way to specify FrontlineSMS to receive a message from the two way number. I do not see a receive checkbox option for ClickaTell similar to what there is for IntelliSMS. I'm not sure if FrontlineSMS has a way to retrieve messages sent to the two-way number, but they said there needs to be a script to handle the incoming messages. Is that something can be added fairly easily - or configured? We are hoping to be able to use it today for election alerts.
I found this two-way API guide from ClickaTell, which might be helpful for development changes:
Thank you All for responding to this troubling issue. I have tried one thing that seems to work partially. For people using Clickatell Central API, if you have a TWO-WAY number by using MO=1 and FROM=TWO-WAY number, (Example:http://api.clickatell.com/http/sendmsg?user=xxxxxxxxx&password=...) you can place this string in the FLSMS configuration panel also modify the string to include MO and TW number just like the example above then insert it in the From Number as well:
The message will be delivered but my problem right now I don't know yet how to get the reply to work since I am not using a GSM modem or a cell phone. All your suggestions are welcome. Thanks.
Jack, can you clarify which field you are putting the extra parameters? We have a modem setup, but we aren't able to figure the round-about from Clickatell to use the modem number either.
Silas, et al. do you all know if Intellisms supports US origination numbers?
I just spoke with IntelliSMS and they do not provide US sender IDs so there would be problems with US users replying with IntelliSMS to an international origination number. So I think getting ClickaTell to work similar to IntellisSMS is our best option at the moment, but I do not know what best way to do that. We have several developers here that might be willing to help, but I don't know if that is something we can get done quickly or not.
If we could get on a call with someone that would help immensely.
I have inserted a screenshot for your convenience. The From Number dialogue box would be a good place to enter the number you want people to reply to. However in my case I entered and API string that seems to work as well.
We are looking at the development wiki section about Internet SMS services:
And reading about how to extend the services. Does this mean that we could write/extend the existing ClickaTell service and add it to our current installation, or would we have to recompile all of Frontline? In either case, could we get connected with a developer that could point us in the right direction? If it works, we'd be happy to share back with the community.
That is a wonderful idea. I am sure that many people specially in the US would benefit from it. I don't know who you could talk to in terms of compiling Clickatell discussions from FLSMS to your wiki project. But that would be awesome. About that screenshot, please see the attachment. Thanks.
Sorry for our slowness in replying to this today.
You're right that FrontlineSMS doesn't currently support two-way messaging using Clickatell - you might find it easier to extend version 2 than version 1, but my understanding is that it would mean adding incoming http connections, which we haven't yet done. As we're in Nairobi the developer team is unfortunately no longer in the office, so we won't be able to jump on a call with you this evening - I appreciate that's outside your timeframe, and apologies again.
We will look to add two way support, and other aggregators, as soon as possible.
Thank you Laura for your response. Right now I can get my messages delivered by using the steps that I mentioned above. I just can't get people to reply or receive through FLSMS using some script combination as oppose to using a GSM modem.
Thanks Laura. If we could speak with someone in the Morning time Nairobi (evening time CDT) that might be helpful as well. From what I understand of the clickatell documentation:
Section 11.3, there are multiple methods to retrieve messages from Clickatell via polling and/or ftp and then have to be parsed. However, I do not know whether Clickatell will automatically forward messages to an http service (this might be what they define as the callback URL). I understand version 2 might support it better, but we need autoforward functionality that currently isn't in version 2. (and Groups was harder to figured out in 2 as well). I do like the http nature of version 2, though.
Maybe we can look at the ftp log file method as an alternative, but not sure how easy it would be to discard previously committed messages. Thanks for any help you all could provide in our time sensitive project.