Esendex Webservice SMS using C++

C++ is not my main language, but all Esendex developers are expected to help our customers integrate their systems with ours on top of our usual development work.

Admittedly we don't have many people asking for help with C++, but when they do we usually direct them to the C++ SMS SDK. This includes a COM component which developers must install, and this fact does pose some problems for some developers.

So, while waiting for a build I found How to Consume [a] WebService via unmanaged C++, which describes how you can get Visual Studio 2005 (and apparently 2003 as well, but I've not checked that), to generate a proxy for you.

In Visual Studio 2005:

1. Generate the proxy:

1. Right click on the project in the Solution Explorer and click Add Web Reference.
2. In the dialog, enter http://www.esendex.com/secure/messenger/soap/SendServiceNoHeader.asmx as the URL, and give it a name
   
3. Click Add Web Reference
4. This will generate a file in your project (with the name you gave it)

2. Write code to call the proxy:

   SendServiceNoHeader::CSendServiceNoHeader proxy;  
   BSTR result = NULL;  
   HRESULT hr = proxy.SendMessageFull( CComBSTR("username"),
       CComBSTR("password"),
       CComBSTR("account reference"),
       CComBSTR("originator"),
       CComBSTR("destination"),
       CComBSTR("C++ Hello!"),
       CComBSTR("Text"), 0, &result);

3. Notes:

1. result will contain the ID of the message you've just sent
2. hr can be used to check if the operation was successful
3. You may need to include the line CoInitializeEx(NULL, COINIT_APARTMENTTHREADED); before this code if your application doesn't already have it.
   

Sending SMS to a specific port using the Esendex API

I've written an Esendex Developers Blog entry describing how to send SMS to a specific port. It's quite technical, but we've had a few support cases raised about it in the last couple of weeks, so thought I'd write about it.

It's quite long as well, but I don't think I could make it be any shorter and still be meaningful.

Potential Breaking Change For API Customers

We are currently working on reassembling multipart inbound messages before they are placed into inboxes, which has the effect of increasing the maximum length of an inbound message from 160 to a purely theoretical 38,862 characters.

Esendex customers who use the API to receive inbound messages and have restricted their systems to the current 160 maximum will need to increase their current restrictions.

Read more here.

Esendex Inbound Multipart Messaging Update

Most people who use SMS will know that a standard SMS message is limited to 160 characters (using a standard 7-bit character set). But most people will also know that mobile phones are capable of sending a message of more than this.

The phone does it by splitting the message into parts, and placing a header on each part that describes:

• how many total parts there are in the message


• which part this current segment is


• a reference so parts from different messages don't get mixed up

Esendex's outbound service has supported sending these long messages for more than a year, but at the moment we treat inbound message parts as separate messages.

We're currently working on an update that will cause these message parts to be reassembled into one message, so all parts (or however many parts we actually receive) will be displayed as 1 message in the Inbox.

So what is this going to affect? Well, if you use the website to view your inbox, or have your messages emailed to you, then this won't affect you at all--all you will see is a longer than usual message if a multipart message is sent to your account.

However, if you have written an application that retrieves your messages from your Inbox, or which receives direct messages through the Application Notification service, then this could potentially be a breaking change.

If you are expecting a message to be a maximum of 160 characters, you will need to modify your code and/or database tables to accept messages longer than this. If you need to apply a maximum length, then the limit of 1 Esendex inbound message will now be based on the total characters in the maximum number of parts allowed by the specification.

The maximum number of parts is stored in an unsigned byte starting at 1, which gives a potential for 254 parts(!). Each part can have 153 characters, which gives a technical maximum of 38,862 characters in an inbound message.

However, I seriously doubt any provider or phone manufacturer will allow anyone to send a 254 part message. I certainly know that phones have their own limits on the number of parts a handset can send.

As an example Esendex's outbound service limits you to sending 4 message parts, or a total of 612 characters.

A maximum of something like 1000 characters should probably handle most cases, but the potential is there for 10s of thousands of characters under the right circumstances.

This update is currently in development and will hopefully be going live in September sometime. I've been told an email will be sent around to API customers giving an official announcement, but you can get a head start on any changes you need to make right now.

SMS Dead? Don't think so

Roland's blogging about SMS being dead on the basis that "a well funded startup like Twitter which is full of smart people can't get SMS to scale".

I don't really know where he's coming from basically. Is this just an American feeling? I know the US has been slow to take up SMS, and that is because of the carriers over there, but in Europe and over here in the UK SMS is the way to communicate.

There have been some posts in response to this already, and I couldn't agree more with some comments made. If Twitter can't scale their own systems, then that's Twitter's problem, not SMS as a technology. Twitter developer Alex Payne admits that Ruby on Rails makes it difficult to scale the web application, but makes no mention of limitations of SMS.

Twitter and other sites have had security problems with SMS but these have been misuses of SMS, not SMS itself. Likewise, the Australian Bopo card has potentially the same problem, but again, this is not a problem with SMS.

These problems have come about from people implementing SMS solutions without knowing all they need to know about SMS in the first place.

Anyone who's read this Letter to American Execs should surely understand how far behind Europe America currently is with SMS.

SMS is quick and discreet. Email is ignored or deleted. Phone calls are too direct and intruding for many things, and IM is too.

SMS is not dead. Esendex has customers worldwide, and we send millions of messages a month on their behalf to prove it.

Comments on the Esendex API

Had a nice comment left through Esendex's Contact Us page today:

Can I just say that as a new user/developer of the Esendex APIs that they are, without doubt, THE most comprehensive and easy to use (from Visual Basic) that I have worked with. Totally hassle-free.

Well done, keep up the excellent work.

I can't say I've personally worked that much on the VB SDK, but all kind words about the Esendex systems are more than welcome.

People are very quick to criticise when things don't go as they expect, but not many people take the time to give praise when something turns out well.

Thanks!

Picture Messages in SMS - Another Update

I've created a (very crude) bitmap editor so I can make a 72x28 pixel OTA bitmap. It flickers like crazy when you're editing, but it gives me enough functionality to prove that Esendex's SendWDPService can be used to send SMS picture messages.

I drew a square in my editor and sent the message with some custom text. I've noticed that the £ (sterling) sign came through as a $ (dollar), so there's some encoding problem there, but mainly I'm happy with what I've got.

Now I need to package up this solution so it can actually be used somewhere. I'll probably write a Codeproject article on it when I finally get around to making it work simply.

Picture Messages in SMS - Update

Found a couple of hours to check out SMS Picture Messaging last night. Using the example on the Nokia sample I can send the example picture with some text. I haven't yet managed to send my own picture, as I need to figure out how to encode the OTA bitmap.

I was thinking of creating my own editor to create the bitmap in the format that I need, but I reckon there must be ones already out there that I can use. If not I think I'll look into converting a standard monochrome bitmap to OTA format. Then I can use something like MS Paint to create the picture.

So at the moment I can sort of send a picture message. I can specify the text that I want to include anyway, and just use the "canned" picture that Nokia supply as an example. The text seems to encode properly, but I need to look into what encoding I need to be using for this to work completely.

As an experiment though I did all of this without touching Esendex's core messaging system. I sent the message through our SendWDPService Web Service that we originally implemented to allow people to send OTAP settings. The method simply takes originator and destination ports, and then some content which can be split across multiple PDUs.

The work outstanding is to figure out a way of easily encoding a picture for inclusion in the message. When that is done I'll write a more detailed explanation of how to send a Picture SMS.

OTA Bitmap Format

Further to the post about embedding a bitmap into an SMS, I needed to know the format of the picture to send. Wikipedia has an excellent article on the format, so I'll need to use this when I get those 5 minutes to give it a go.

Picture Messages in SMS

Embedding a bitmap picture into an SMS isn't something that Esendex directly supports, but after a customer's request I thought I'd take a few minutes to find out how to do it.

So I sent a picture message from my phone into one of our virtual mobile numbers, and I'm pretty sure I can reverse engineer the bytes that I got.

Then I found this Nokia article on it, which I should have known already as I used to have this document on my desk pretty much all the time... So it looks quite interesting.

I'll give it a go when I get 5 minutes, but the specification doesn't seem that complicated. Watch this space I guess.