The second tutorial of the day was co-presented by Surj Patel (a former member of France Telecom's innovation community in Orange Imagineering) and Dodgeball's Dennis Crowley.
Building an SMS Service, takes the user through three methods for creating SMS-based services:
- Using email transports such as SMTP
- Transforming a phone into an SMS gateway
- Using SMS shortcodes from third-party vendors
Of these techniques, the first two are inexpensive solutions but require significant maintenance, whereas the latter is relatively low maintenance but also costlier.
Using the SMTP email protocol, the developer can essentially fake an SMS by pinging a phone - for example, 07808786814@orange.net. Ingredients include:
- A free mail service, such as Gmail
- A Perl-based POP'ing script
- A script to automate the POP'ing script
Messages are parsed by removing the To, From, Subject, Body and Attachment fields and passing variables to a PHP script that processes incoming messages, sends outgoing messages, compiles usage statistics and validates authorised users. Outgoing messages are formatted as simple SMTP messages, whereas MMS messages include MIME attachments for media elements. Unfortunately, cross-carrier MMS is problematic and some networks won't accept images attached to email messages...some even replace them with URLs that references image attachments.
This method does however allow for lightweight development of interesting SMS-based services. Patel and Crowley hinted at query languages that enable mobile users to enter into dialogues with online services (a la Google SMS), opt-in location tracking and geo-coding, querying RSS content and communicating with networked appliances via PHP middleware.
The second method involves the use of a mobile handset as an SMS gateway. This method consists of a handset connected to a host PC running software capable of performing the functions of an SMS gateway device.
For the purposes of the tutorial, Crowley and Patel recommended any phone capable of infra-red, serial, Bluetooth or USB connection or a dedicated GPRS/GSM modem; in the spirit of ETech, their handsets were sourced used, unlocked handsets from eBay, pre-paid SIMS and family tariffs with additional handsets! Though the tutorial utilised NowSMS, the speakers also suggested alternative SMS gateways including:
Firstly, Crowley and Patel instructed attendees in connecting, installing and testing a phone as a Windows modem device. Next, NowSMS is configured and installed such that the gateways software can utilise the phone as an over-the-air medium.
In the next part of the tutorial attendees were shown how to process and reply to incoming SMS messages using simple CGI and PHP scripts. The first example, accepts a name-value pair from an incoming SMS message, reverses the contents of the message, and returns the result to the sender. NowSMS can extract a number of parameters from an incoming SMS - callerID, message content and receiving number - and pass these parameters to an external application. Essentially, 2-way applications flow as follows:
- Incoming
- SMS recieved by phone
- Gateway recieves SMS from phone
- Gateway assembles URL using name-value parameters from the SMS
- Gateway calls application script using this URL and embedded values
- Script processes data according to application logic
- Outgoing
- Create a string for the return SMS
- Isolate the destination number
- Application assembles URL using name-value parameters for the reply SMS
- Call the gateway using this URL
- Gateway passes message and destination number to gateway handset
- SMS reply send back to originating handset from gateway handset
The third and final method demonstrated utilises third party providers, most of which offer only 1-way services. Providers are able to provide high volume, low cost messaging with minimal fuss, though they can prove expensive for two-way messaging particularly when interconnection to foreign access numbers or international messages are considered.
Crowley and Patel identified a number of providers including:
Though signup fees vary, 2-way services are generally in the region of $200 with additional per-message costs of around 2.5c at high volumes. Buyers can either pre-pay for blocks of messages of be billed for overall usage. In addition to messaging costs, you can expect to pay interconnect and per-incident support charges too.
Requests can generally be made using most protocols - including SMTP, SMPP, HTTP POST, XML, SOAP, RPC and FTP. The service provider takes the incoming message and transcodes it into a URL containing name value pairs. For example:
http://www.yourapp.com/incoming.php?from16718876543&text=hello+world
Crowley and Patel went on to demonstrate the use of Clickatell's HTTP API service (ten message, 1-way free-trial).
Carrier's own SMSC platforms provide for ultra-high volume 2-way services, but are much more expensive than the three solutions outlined in these tutorials, both in terms of setup, legal contracts, VPN connections and lead-times. Such capabilities are usually reserved for very high volume applications such as TV and radio voting.
Finally, shortcodes present another alternative to the methods outlined by Crowley and Patel and with specialist InterNIC-like agencies and brokers, like the CSCA in the US and Quios in Europe, shortcodes are becoming more accessible to developers, they still represent an expensive option - costing around $500/month each with 'vanity' shortcode costs climbing even higher.
Despite a number of technical glitches (almost resulting in my shiny new VAIO being doused in water) the tutorial was actually very informative - though my own basic web development skills prevented me from undertaking the examples.
Recent Comments