DevDisasters

Cell Phone Buzz

When all you have is a hammer, should everything look like SMS?

• By Alex Papadimoulis
• 09/01/2009

The year was 2006, and something new was in the air. It wasn't new as in "just released"; Short Messaging Service (SMS) had been around for over a decade, but the technology was starting to generate a buzz.

After missing out on the dot-com boom, Jared's employer, a retail company, decided to invest in SMS and to invest big. Everything they did had to have an "SMS interface." Need to pay a bill? We'll SMS you. Need tech support? Send an SMS. Want step-by-step updates? We'll SMS you.

It all sounded well and good, except for one small detail: none of the developers at the company knew anything about how SMS worked, much less how to interface their software with it. A quick Web search revealed that there were gateways, message centers, and all sorts of other complexities involved with sending and receiving SMS messages. It would take at least a month or two for the developers to design and build the interface.

Management quickly decided on a different approach. They hired a consultant who could get it done in a couple of weeks.

Working SMS
The consultant's task was to build a library that could communicate with different SMS gateways via the Internet. That way, the developers could plug it into their code and send messages to customers. Three months later, after a series of "unforeseen" hurdles and hiccups, the consultant finally delivered. It wasn't the final version of the SMS library, but more of a demo.

Jared was tasked with evaluating the library and found something a bit strange. You couldn't simply send a message to 4405551234; you had to know that 4405551234 belonged to T-Mobile, and then specify that in the API call.

He decided to do some digging. Jared opened up a software utility called .NET Reflector and started disassembling code. Here's what he found:

object 
   GetEmailBasedOnCarrier()
{
 string d;
 switch (this.Carrier)
 {
   case Carriers.T_Mobile:
     d = "tmomail.net";
     goto Label_005B;
   case Carriers.Cingular:
     d = "cingularme.net";
     goto Label_005B;
   case Carriers.Sprint:
     d = "messaging.sprintpcs.com";
     goto Label_005B;
   case Carriers.Verizon:
     d = "vtext.com";
     goto Label_005B;
   case Carriers.Nextel:
     d = "messaging.nextel.com";
     break;
   ... snip ...
 }
Label_005B:
 return (this.PhoneNum + "@" + d);
}

Instead of building a .NET wrapper for SMPP (the protocol used to send SMS messages) and communicating with message centers, the consultant built a library that wrapped System.Net.Mail and would simply send e-mails to the various carriers' SMS e-mail gateways.

Jared brought this issue to management. They didn't quite understand the problem-the library sent SMS messages, after all-but relayed it to the consultant.

"This was only the demo version," the consultant reassured management. "The final version won't use 'e-mail calls' to send SMS messages, but instead will use 'IP calls.'"

Satisfied with the response, management paid the consultant in full and gave the library to the developers to use. Curious as to how the code would make an "IP call," Jared fired up .NET Reflector to find the answer, and found:

   case Carriers.Cingular:
     d = " 66.102.165.101";
     goto Label_005B;
   case Carriers.Sprint:
     d = " 144.230.162.49";
     goto Label_005B;

At least Jared learned something: You can actually send e-mail to an IP address.