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

  • Death of the Dev Machine?

    Here's a takeaway from this week's Ignite 2020 event: An advanced Azure cloud portends the death of the traditional, high-powered dev machine packed with computing, memory and storage components.

  • COVID-19 Is Ignite 2020's Elephant in the Room: 'Frankly, It Sucks'

    As in all things of our new reality, there was no escaping the drastic changes in routine caused by the COVID-19 pandemic during Microsoft's big Ignite 2020 developer/IT pro conference, this week shifted to an online-only event after drawing tens of thousands of in-person attendees in years past.

  • Visual Studio 2019 v16.8 Preview Update Adds Codespaces

    To coincide with the Microsoft Ignite 2020 IT pro/developer event, the Visual Studio dev team shipped a new update, Visual Studio 2019 v16.8 Preview 3.1, with the main attraction being support for cloud-hosted Codespaces, now in a limited beta.

  • Speed Lines Graphic

    New for Blazor: Azure Static Web Apps Support

    With Blazor taking the .NET web development world by storm, one of the first announcements during Microsoft's Ignite 2020 developer/IT event was its new support in Azure Static Web Apps.

  • Entity Framework Core 5 RC1 Is Feature Complete, Ready for Production

    The first release candidate for Entity Framework 5 -- Microsoft's object-database mapper for .NET -- has shipped with a go live license, ready for production.

Upcoming Events