Perl or Ruby program to interact with SMS/Text on mobile phones

Project Description: This project is to develop a user self-registration application (“Registrar”) that uses Twilio (an IVR provider in the US) services and API's. It will enable our users (Users) to register their mobile phone number and their home address on our system. Registration occurs via a series of text messages (SMS). The Twilio-based SMS interface will run as a web service under Tomcat on our web server, and will be accessed via a URL configured on Twilio. The web service may be written either in Perl or in Ruby. When an SMS message arrives from someone, Twilio will execute a POST to the URL we configure for that Twilio number. The POST will contain the hard-coded the customer’s telephone/account number. The POST will also contain dynamic content: the sender’s SMS number and the message text. The URL will be of the form: https://registrar.hyper-reach.com/incoming/account=customer_number/{twilio_content} There will be a dedicated Twilio telephone number for each customer account (customer_number). Therefore, we will be able to associate the twilio_content with the appropriate customer. This will then be used with the our API to retrieve information from and to populate the registration database. The web service will communicate back to the User via the Twilio REST API, found at [login to view URL] The SMS Registrar application will start by receiving a message (SMS) from someone wishing to register. That will initiate a series of interactions with the sender, which will retrieve the information necessary for that caller to complete his/her registration. Each interaction between the Registrar and our server may run into problems since they will occur on the Internet, an imperfect communications medium. We expect a small amount of resiliency with Registrar (e.g., some configurable retries) but they must then be able to terminate gracefully. Address Correction A User’s registration data contains at least one physical location address. This project’s scope includes using the Google Maps Geocoding API ([login to view URL]) to convert the arbitrarily formed address that a User sends in a text message into a normalized format with a Latitude and Longitude that may then be stored in our database. SMS Interface SMS registration will be accomplished with the server side acting as a state machine. The Registrar will essentially maintain a pseudo-session. Each user text number will have a state in the database. Depending on the current state and the incoming contents, the state will change and the server will send a message back to the user to draw successive information from that user. Message Content Equivalents Text messages may have several variations in spelling, abbreviations, and punctuations. The following table shows a generic message meaning and the various aliases that will be treated as equivalent. The program will provide a mechanism to modify the aliases without changing code (for example, an input data file). For this program, capitalization will always be ignored. “a-z” are identical to “A-Z”. States The following tables defines the distinct states for any user data record in the state machine and their meaning. It is always assumed that we know the telephone number (or SMS number) of the User who is sending the message. Users are associated with an individual Account. The Account is identified by the number which the User uses to contact the Registrar. Each Account will have a unique inbound calling/SMS number. Each Account will have a list of numbers which are not to be contacted. This is referred to as the Do Not Contact or DNC list. Confidentiality agreement required for detailed specifications and/or winning bid. Only 50% of bid will be milestoned before delivery of beta version. No money released until beta version provided. Deliverables must include commented source code. Full payment made after delivery of source and testing.