
Ask YC: Implementing an SMS application - aitoehigie
I am implementing an application that has SMS features and i will like to know if there are any free SMS providers that i can link my application to their SMS Center. I have heard about Kannel (i.e. an open source sms center) but i am not too sure if i have to attach a GSM or GPRS modem to my server for it to work? N.B. I do not live in the USA. thanks
======
bantic
There's a new peepcode pdf about this that looks interesting.
<https://peepcode.com/products/mms2r-pdf>

I'm sure the carrier negotiations in order to use shortcodes are different in
countries outside the US. I have heard that docomo in Japan actually makes
this sort of stuff really easy for developers (and that Japan has a burgeoning
diy market of cool phone-based services as a result).

What country are you in?

I've done work using the email2sms gateways for both sms and mms. For sms it's
kind of a pain because the gateways can't always be inferred just from carrier
and number (T-mobile for instance, sometimes uses a nickname that you set up
rather than your phone number, so your phone's sms email address ends up
something like coolguy@tmomail.net instead of 2125551234@tmomail.net).
Receiving MMS is a HUGE pain because the carriers all include the attachments
differently. Some carriers include multiple attachments -- some of them are
spacer gifs and things like that -- and you have to figure out the correct
one. Other carriers, like Sprint, don't even include an attachment, they have
a link in the MMS email that takes you to a page, and that page has another
link to the picture. I had to use come complicated regex's and multiple wget
calls to download the picture. The whole thing was very fragile as a result.
But, to Sprint's credit, they are so bloated and slow to change that in 9
months they never modified the way those messages were structured so nothing
broke.

I haven't worked on this stuff in over a year, so it may be out of date, but
given the glacial rate of change in telco's (esp in the US), I'd be surprised
if the situation has changed much.

Again, though, could be a very different story depending on where you're
actually located.

~~~
aitoehigie
I live in Nigeria, i.e. West Africa, I will like to talk to you and see what
we can work out. my email address is aitoehigie [at] gmail [dot] com

------
jsjenkins168
I dont have any experience with hardware, but have developed using Ericsson's
Parlay X libraries and they are very easy to use:

[http://www.ericsson.com/mobilityworld/sub/open/technologies/...](http://www.ericsson.com/mobilityworld/sub/open/technologies/parlayx/tools/telecom_web_services)

Its a useful library if the service provider you're trying to gain access to
exposes Parlay X access to their network. Very easy to send/receive SMS, MMS,
etc from your web application as they library wraps all the SOAP calls for
you.

------
rokhayakebe
Kannel still requires you to have a SMS provider or paired it with a modem as
you mentioned. All it really does is give better control over your SMS
in/outbond flow. I would recommend 41411 if you are going to server the US as
well. I have used it with different applications, and still do. They have an
API and you can get up and running within minutes. Best part, it is free.

~~~
aitoehigie
41411 only covers the USA and that is not my target audience for now

------
jonknee
I believe the free option is to use the carrier supplied email gateways (which
is what something like Google Maps uses to send addresses). If you want a full
two-way messaging system like Twitter, you have to pay up. You can find open
source software, but you need access to the networks and that's going to cost
money.

It's quite a racket, they often charge both the sender and the receiver.

~~~
mattmaroon
I've heard you quickly get blocked as spam by the email gateways if you start
doing this in bulk.

~~~
bantic
Yes, that's true. In my experience doing batch sms-emailing (with relatively
small batches -- several hundred at a time only), we would take use two
strategies: 1 -- queue the messages and send them slowly, maybe between 5-25
every minute. and 2 -- distribute across carriers. Group the users by carrier
and then for each queued batch take from as many of the different carriers as
possible, thus limiting the number of times you sent an email over any
specific carrier's gateway in a given queued clump of messages.

This seemed to work but it was hard to guarantee message delivery.

------
tlrobinson
<http://www.textmarks.com/>

------
sabat
Are you talking about sending, receiving, or both?

