SMS two-way booking engine

SMS two-way booking engine SearchSearch
Author Message
Tillmann
Posted on Friday, January 24, 2003 - 09:25 am:   

Cheers guys,

I have a rather macro question: I've read through the site and the different posts here and understand the functionalities of the Gateway, but I need some help to decide whether the system is good for what I want to do.

I want to set-up an interactive booking system via sms (i.e. a two-way SMS) application. Is it advisable to get a gateway for that, buy a GSM modem and write the application that handles the HTTP data from the gateway?

I'm looking at potentially high volume, but only 6 to 12 months into the project. It seems that the switch from the GSM modem to the telco hook-up is no problem with the NowSMS gateway, right? Even if I buy more than one GSM modem, they wouldn't be able to share the number and do some sort of load-balancing, right? I was also thinking of assigning one GSM modem for incoming messages and one for outgoing, but that would be rendered useless if the other side replies to the message by just hitting the reply button on the phone. Any ideas on that?

Alternatively to a commercial, there are tons of OpenBSD, Linux GNU gateways out there, that seem to do the same, except for the proper GUI perhaps. Correct me if I'm wrong.

Thanks!

Tillmann
Bryce Norwood - NowSMS Support (Bryce)
Posted on Friday, January 24, 2003 - 03:33 pm:   

Tillman,

You could get started on a GSM modem ... but I do think it is going to be really important to separate the inbound and the outbound traffic as your volume starts to build.

Basically, if you're busy sending outbound messages while inbounds are coming in, you don't want inbound buffers to overflow.

If you want to keep the costs down, my suggestion would be that as you get past that initial phase, you use a web based provider (e.g., HTTP interface for sending messages) that lets you set the phone number that you are sending from for outbound messages. That handles the reply issue.

If you're handling a lot of inbound traffic though, you would have to migrate away from that GSM modem. Depending on network issues, it's really only good for 6 to 10 messages per minute.

And you're right, one of the nice things about our gateway is that you do have a lot of flexibility in changing your SMS connectivity around without changing your application.

I can't really comment too much on other gateways. I know there are a ton of them out there, some free, some mysteriously expensive. We're trying to make things simple ... at least as simple as we can while offering a lot of flexibility.

-bn
Tillmann
Posted on Tuesday, January 28, 2003 - 07:49 am:   

Bryce,

Thanks for your reply. I see things clearer now.

Just to check two of your comments:
Outgoing traffic congestion - instead of going through a webbased provider, can I just add 1 or more GSM modems and mask the reply phone number the same way you suggested for the HTTP, this time using your gateway? Or is that not possible due to the gateway or the GSM modem?

Incoming traffic congestion - imagine I manage the outgoing traffic the way you suggested or via multiple GSM modems, is there any way to speed up the incoming message process? The thing is, I don't want to have more than one phone number for people to remember and to send smses to.

I greatly appreciate your help, will definitely consider your gateway once we get the go from our client.

Tillmann
Bryce Norwood - NowSMS Support (Bryce)
Posted on Tuesday, January 28, 2003 - 02:20 pm:   

Tillman,

Based on the nature of the GSM modem interface, it is not possible to mask the sender address. I haven't seen any solutions for doing this other than going through a provider (which in the case of our software would be an HTTP, SMPP or UCP/EMI based provider).

If most of your incoming traffic is going to come from new requests, instead of replies, multiple modems will help. Configure one modem for inbound only, and the others could do a mix of inbound for replies, and outbound. Inbound traffic is generally given precedence.

-bn