Wayne Molina
2009-May-20 17:46 UTC
Sending SMS messages without knowing the user''s carrier
I have an idea for a new web-based application that involves the use of SMS notifications, however I can''t assume a particular carrier. Most of the plugins I''ve seen like sms_fu require you to know the carrier in order to send a message; is there any way around this, or would I have to use an SMS gateway like CellTrust to handle this? I''m going to need to both send and receive SMS messages (in case the users want to opt-out of notiifications) The app is still in the brainstorming stage, so I''m trying to gather information on it first to determine how complex it will be.
Danny Burkes
2009-May-20 18:23 UTC
Re: Sending SMS messages without knowing the user''s carrier
Both of your requirements (accepting inbound SMS, and sending without knowing the carrier) imply that you need a real SMS service provider. I''ve personally had experience only with Clickatell and that experience has been a good one. To send, you''ll need to use one of their APIs- I use their HTTP API, via the Clickatell gem (http://github.com/lukeredpath/clickatell), and it''s simple. Outbound cost is around 2.9c per text in the US. On the receive side, Clickatell will accept the inbound texts for you, then route to a URL you provide- so you just write a normal action handler in Rails and, voila, your inbound text start arriving on that URL. The bad part is the inbound cost- while the actual per-message cost is cheap (about 1c per inbound text, I think), you''ll also need to rent a shortcode, so your outbound message will appear to be from that code (Twitter uses 40404, for example), and your users will send you messages by texting to your shortcode (or replying to your outbound texts). The process to rent a shortcode is an asinine ball of shit, thanks to the carriers. It takes 2-3 months to complete the process, the carrier actually DICTATE to you what words you have to include in the texts to your users, then, as if that weren''t insulting enough, you have to pay $1600/mo for the privilege of renting the shortcode, after they''ve wasted 2-3 months of your time just acquiring it. Prepare for frustration in that process is all I can say. The good news is, if you can afford the monthly charge, and the heartburn of getting the shortcode, once you''ve got one, the actual day-to-day operation using Clickatell''s API for outbound and inbound works great. In my experience they have been exceptionally reliable. Best, Danny -- Posted via http://www.ruby-forum.com/.
Mark Studebaker
2009-May-20 18:33 UTC
Re: Sending SMS messages without knowing the user''s carrier
There is always the option of connecting a mobile phone to your computer and send/receive SMS through the phone. It''s slow though ~4 messages a minute. Its not practical if your app is hosted but I was able to run using a server called Kylix (which polls and updates your DB) as well as using gnokia (command line) running on Windows. ________________________________ From: Danny Burkes <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> To: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Sent: Wednesday, May 20, 2009 2:23:34 PM Subject: [Rails] Re: Sending SMS messages without knowing the user''s carrier Both of your requirements (accepting inbound SMS, and sending without knowing the carrier) imply that you need a real SMS service provider. I''ve personally had experience only with Clickatell and that experience has been a good one. To send, you''ll need to use one of their APIs- I use their HTTP API, via the Clickatell gem (http://github.com/lukeredpath/clickatell), and it''s simple. Outbound cost is around 2.9c per text in the US. On the receive side, Clickatell will accept the inbound texts for you, then route to a URL you provide- so you just write a normal action handler in Rails and, voila, your inbound text start arriving on that URL. The bad part is the inbound cost- while the actual per-message cost is cheap (about 1c per inbound text, I think), you''ll also need to rent a shortcode, so your outbound message will appear to be from that code (Twitter uses 40404, for example), and your users will send you messages by texting to your shortcode (or replying to your outbound texts). The process to rent a shortcode is an asinine ball of shit, thanks to the carriers. It takes 2-3 months to complete the process, the carrier actually DICTATE to you what words you have to include in the texts to your users, then, as if that weren''t insulting enough, you have to pay $1600/mo for the privilege of renting the shortcode, after they''ve wasted 2-3 months of your time just acquiring it. Prepare for frustration in that process is all I can say. The good news is, if you can afford the monthly charge, and the heartburn of getting the shortcode, once you''ve got one, the actual day-to-day operation using Clickatell''s API for outbound and inbound works great. In my experience they have been exceptionally reliable. Best, Danny -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Wayne, Clickatell rocks, go for it! Cheers, Sazima On May 20, 2:46 pm, Wayne Molina <wayne.mol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I have an idea for a new web-based application that involves the use > of SMS notifications, however I can''t assume a particular carrier. > Most of the plugins I''ve seen like sms_fu require you to know the > carrier in order to send a message; is there any way around this, or > would I have to use an SMS gateway like CellTrust to handle this? I''m > going to need to both send and receive SMS messages (in case the users > want to opt-out of notiifications) > > The app is still in the brainstorming stage, so I''m trying to gather > information on it first to determine how complex it will be.