I remember doing this a few companies ago. Except we didn't have a modem, we just found a phone we could send commands to. It had some user interface that would pop up after every sent message, so we rigged up a terrible little hack to press the acknowledge button every few seconds to dismiss it. It worked surprisingly well :)
Side note to your post, the w800 in your picture was my all time favorite phone. I'm a full time Android developer now and I consider the Java programs I first worked on with the w800 to be the reason behind my interests :)
Haha, that's a nice solution. I recently did something like this and the process really makes you dislike the AT command set. If you don't want to take an old GSM phone apart to find its serial pins, a simple USB GSM modem, pretty much any USB GSM modem should be able to expose a /dev/ttyUSB* interface.
My SIP provider (Voip.ms (I am unaffiliated to them beside being a customer)) just send them by email, for free. It's included in my ~0.70$ USD per monthly plan (pre-paid almost forever on a 25$ payment). So, these day, I find it ridiculous to pay for a carrier voice/sms plan. It's pointless.
The worst thing that can happen is having a use a VPN on top of the SIP stream for carriers that void net neutrality. Tablet data plan + SIP = win
* You get your calls on your computer and devices, all of them, for the same price.
* You can script your softphone to pause your music and answer in your music headset
* You can add a SIP server in from of the link to add new features.
* You can inter-operate media stream from Skype/(name your IM app) and "real" phones for "free"[1] using pulse audio / core audio.
* Usually, multiple line, transfer and conferences are included, you don't have to pay extra. If they are not, you can implement them using your own SIP server or some scripts.
* Most softphone have multiple account support, so you can have your business phone and home phone on the same devices, but with different Ringtones.
The possibilities are near limitless _and_ it is beyond cheap. The main downside is that you almost have to be an IT person to be able to make it all work :P
You don't have to pay for Skype _and_ a phone plan, only your phone plan.
/shameless plug
If your using Ring.cx (I am one of the dev), you can also seamlessly make end-to-end encryptet and decentralized/P2P calls if your peer also use Ring.cx (or anything SIPS compatible, minus the decentralized part, so technically risking a MiM).
It's been a long time since I've tried to do serious SIP usage on Linux, but way back when, I could never get a client that worked consistently. One or the other would work fine for a while, until either the client, a library elsewhere on the system, or the SIP server would update, and then it'd misbehave terribly and I'd have to go through the roulette and try to find another client that worked well (not always possible). Is the situation better now? What do you use?
Linphone was the last client I had working before I gave up totally. Though it would often hang when trying to make a call, it worked well enough for 3 months or so. I started having to compile the builds from git and eventually it got to the point where the app was hanging every time I made a call and I'd have to kill -9 it. It's probably been 3 years or so since I tried it. Similar experiences were had with twinkle and a couple of other clients before I found Linphone.
When I looked for a Windows and a Linux SIP client, I found that most things were based on PJSIP so all suffered the same problems. SIP (and RTP/RTMP) are complex to implement, so I don't think many people try.
Pity they don't have any servers <150ms away from me: http://wiki.voip.ms/article/Choosing_Server. I'm in Australia, so the SIP server really has to be in Sydney or Melbourne for it to work for me (~70ms RTT on ADSL). Someone from Perth can yell at me for being so Eastern-centric.
I haven't had a landline in about 4 years (known as "naked" ADSL - there's no dialtone on my copper line). I played with VOIP for quite a while but could never really get the quality I wanted. Then the mobile costs came down enough so I haven't looked since. Hangouts and Skype solved my international phone call problems, although I'm not entirely sure how they solved the echo/delay problems so well.
Edit: oh, right, this was an SMS specific article.
Written in Golang, simple api to push messages to queue, takes care of AT protocol for you. Also supports load balancing if you have multiple modems :)
There is (was?) also Gnokii [1] for old Nokia phones, which I've used successfully. I even managed to port a small part of it to Arduino to send a message automatically (code [2] and write-up [3]), but these days there are shields with much better interfaces than the Nokia FBus (e.g. using the SIM900 chip [4]).
I recently used gammu[1] to receive SMS messages on OSX using a Huawei modem, then forward them into iMessage[2]. Gammu's written in python and works great on Linux.
Goal was to have my old foreign number still able to receive SMS (receiving messages while roaming is free in most countries), and have them appear in iMessage on my current phone.
We've been using Gammu for over 5 years now for on-call alerts or other small services. It has worked very well with an ordinary 3G dongle you can buy to get mobile internet on your laptop. The SIM card is provided by the company since we're a large telco we get pretty much free unlimited SMS from them.
This has been used in two different data centres without any reception issues, even though they're properly shileded data centres and we have no external antennae.
Only issues have been forced re-seats of the USB dongle a few times a year, most likely due to oxidation on the connector.
The only thing I've had trouble with is suspend/resume/etc on OSX which seems to hang gammu occasionally. I used the cheapest E170 I got from Ebay, the hardest part was messing with all the unlock tools to get it to play with the SIM in the first place :)
I used to do this back in 2005. Forgive me if something has changed in the intervening years.
There was a rate limit for receiving and sending SMSes via the hardware approach. My experiments yielded 1 per 20 seconds iirc
In the end my implementation purely received via hardware and exited via a bulk SMS provider like clickatell
clickatell at that stage allowed big users to set the 'sender caller id'. This was loved by spammers unfortunately so the providers became much more cagey about allowing that feature.
Michael here (author of the post). We didn't find any rate limits when receiving SMS, but found sending to be quite slow. Fine for our needs, but if you need to send a lot you may be better off paying for access to a gateway.
I have a ready to use bootable sdcard image for raspberry Pi(built with buildroot). This solution allows you to deploy your raspi and huawei-E173 behind your home router, and access the sms send/receive functionality via google-hangout.
In this setup, you need two google accounts, one for you and second one for your raspi-xmpp-chat-bot. You can have the whole setup up and running within 5minutes.
This project is a opensource hosted on github.
here are the details:
http://albert-david.blogspot.de/2016/01/rbox-remotely-deploy...
There are apps on Android that lets you run your (old) phone as a SMS gateway. Just plug it into a usb port and select usb tethering. Then on the server/pc:
ethtool usb0
sudo ifconfig usb0 192.168.100.100
ip addr show usb0
I've tried using the gateway published there to send an SMS message to my phone, but my wireless service provider won't accept messages from my email server.
The other question is do any non-US providers have these gateways? Optus and Telstra in Australia don't support this kind of Email-to-SMS (at least, not for free).
It's arguably a lot easier to use Twilio for something like this because there's no hardware needed and you can be up and running in about 5 minutes for a simple setup. That said, the real difference here is probably that Twilio allows you to buy a bunch of numbers cheap so you can scale SMS. Carriers sometimes filter out messages if they are sent too often by one number, so it helps to spread the load across several if you are talking to a lot of users (and services like Twilio handle rate-limiting for you).
This is really cool though, the second SMS hardware hack I've seen on here this week. Glad to see people playing more in this space (especially in theatre, my other passion).
Yep, a nice service that gives you an API is a real winner, and you can send messages much faster. We didn't go that route because we were projecting out of a van. in rural South Australia, and had no data connection.
This was actually put together for an interactive, mixed media theatre project, If There Was A Colour Darker Than Black I'd Wear It. I've posted the followup on my website:
Oh the stories I could tell you of some old Nokia phone that was actually in a datacenter for an app I worked on. There was no cell reception in the new datacenter location, so that method was decommissioned.
Serious question: How can you think that if you can buy wireless computers that can send and reveive SMS via their wireless connection ... that the only way to do so would be via some internet service?!?
edit: hello idiots! you might not believe it, but downvoting doesn't actually answer my question.
This is a great write up. At first I was thinking "just use an api..." But the engineer quickly showed how easy it was with just a tiny bit of elbow grease.
Yep. We couldn't use an API anyway because we were projecting out of the back of a van, in rural South Australia. We were lucky to have any phone reception at all!
I have successfully used an Android device as a cheep SMS gateway. An app installed on the device acted as the gateway and messages are triggered from the server via GCM push messages to the device.
Incoming messages to the device are intercepted by a receiver on the device and posted back to the server.
I remember using SMS server tools and a cyclone(?) 8 port RS-232-hub to drive a bunch of GSM modems to act as an SMS gateway for a company back in '99. Funny to see that the software is still around.
Photo of this amazing disruptive device: https://i.imgur.com/6MNb19R.jpg