DevDisasters

Cell Phone Buzz

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

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.

About the Author

Alex Papadimoulis lives in Berea, Ohio. The principal member of Inedo, LLC, he uses his 10 years of IT experience to bring custom software solutions to small- and mid-sized businesses and to help other software development organizations utilize best practices in their products. On the Internet, Alex can usually be found answering questions in various newsgroups and posting some rather interesting real-life examples of how not to program on his Web site TheDailyWTF.com. You can contact Alex directly via email at [email protected].,

comments powered by Disqus

Featured

  • Mastering Blazor Authentication and Authorization

    At the Visual Studio Live! @ Microsoft HQ developer conference set for August, Rockford Lhotka will explain the ins and outs of authentication across Blazor Server, WebAssembly, and .NET MAUI Hybrid apps, and show how to use identity and claims to customize application behavior through fine-grained authorization.

  • Linear Support Vector Regression from Scratch Using C# with Evolutionary Training

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the linear support vector regression (linear SVR) technique, where the goal is to predict a single numeric value. A linear SVR model uses an unusual error/loss function and cannot be trained using standard simple techniques, and so evolutionary optimization training is used.

  • Low-Code Report Says AI Will Enhance, Not Replace DIY Dev Tools

    Along with replacing software developers and possibly killing humanity, advanced AI is seen by many as a death knell for the do-it-yourself, low-code/no-code tooling industry, but a new report belies that notion.

  • Vibe Coding with Latest Visual Studio Preview

    Microsoft's latest Visual Studio preview facilitates "vibe coding," where developers mainly use GitHub Copilot AI to do all the programming in accordance with spoken or typed instructions.

  • Steve Sanderson Previews AI App Dev: Small Models, Agents and a Blazor Voice Assistant

    Blazor creator Steve Sanderson presented a keynote at the recent NDC London 2025 conference where he previewed the future of .NET application development with smaller AI models and autonomous agents, along with showcasing a new Blazor voice assistant project demonstrating cutting-edge functionality.

Subscribe on YouTube