Architecture – In-house SMS (using a SIM card) receiving and sending

Architectureserversmsweb-applications

My needs are very simple but I don't know the terms I should be Googling for: I need to occasionally send a SMS to a machine and that machine is going to answer with another SMS to the number that did send the first SMS.

I've got no say as to how that machine works: it's closed and all it does is receive SMS and send SMS in reply to SMS received (and uniquely to the number that did send the first SMS) and there's no other way to interface with it.

Upon receiving the "response SMS", I need to update a server / DB (a regular Java webapp server + SQL DB) with the infos contained in the SMS.

There isn't going to be a lot of volume (only a few SMSes daily) and robustness isn't that important (a few SMSes can be missed).

What would be a possible architecture for something like that?

I was thinking about using two or three cheap smartphones and giving them SIM cards and then program them to regularly (once every height hours or so) send an SMS. Then these smartphones would receive an SMS back from the machine they contacted and I'd intercept that SMS and update my server/DB accordingly. (I'll have physical control on these smartphones so giving any permission needed to any app won't be an issue).

Is this something easily doable? Technically, if such a solution could work, how can I access the SMS functionalities of the phone? And how can I have the phone udpate my server/DB? (the phone can be hooked to the Internet, so I take it I can simply do an HTTP POST to my server). Or is there already some (preferrably free or open-source) offering a similar functionality? (maybe something not totally unlike what "zapier" of "ifttt" does, where I could create a rule saying: "If I receive a SMS containing the word xxx, then send the SMS using an HTTP POST to the URL yyy").

Note that I did configure the server(s) hosting the Webapp myself and develop the entire webapp myself: so the "programming" part ain't that much of a problem. My issue is that I don't know how to "create a bridge" between the SMS coming in response to another SMS and my webserver.

I hope I explained the issue simply enough: basically I need some guidance on the architecture to use here (which fits programmers.stackexchange as far as I can tell from just having read its FAQ).

Best Answer

I think it will be far easier for you to just use on of the many services available online for this purpose, e.g. Nexmo. I am not aware whether they are the best in business, but you could google "SMS API" and you'll find plenty of other providers.

This way you can send SMS messages with a single RESTful API call and receive them by providing a callback URL at your own server.

What you gain is that you won't deal with broken phones, etc. and you can focus on your core product.

Even if you don't pick a provider that does this for you, I strongly urge you to at least not do this with Android phones. Not only will you waste money on touchscreen and camera, but a sophisticated OS like Android has a higher chance of a failing component.

I think you'd be far better with a specialized hardware (they are not that expensive) that is designed specifically for the purpose of sending messages. You can search for "GPRS modem" and you'll find proper hardware.

This site has some useful information, although it seems dated: http://www.developershome.com/sms/howToSendSMSFromPC.asp

Related Topic