While it was fascinating to be able to send SMS in a number of ways it’s time to step it up a notch. Kannel is still the main topic and we’ll be looking at OMA CP (Client Provisioning) today, also sometimes known as OTA (Over-the-Air). I’ve previously mentioned that there are a number of standards under the OMA parent protocol, and the provisioning protocol is a good starting point. (For an introduction: What’s This OMA-DM Thingy All About?)

OMA CP is typically used for configuring APN settings, MMS settings and similar on a number of devices. It does not have to be what we refer to as “smartphones”, and work well on simpler phones as well. You’ve probably run into it if you’ve ever visited a mobile operator’s web site to configure your device by entering your phone number and receiving a text message that magically configures the relevant settings for you. But if you have some custom settings the generic web page might not be of help. So like so many other things – you can do it yourself

We’ve already got a Kannel server running, but while testing OMA CP I discovered that it wasn’t entirely smooth sailing to get working with what we’ve installed so far. The short story is that you need to compile in support for OpenSSL in your kannel files, and you need to be running Kannel 1.4.1 (as opposed to the newest build which is 1.4.3 as of the present time.) The long story is that SSL is required as a security measure, and the charset has changed from ISO-8859 in 1.4.1 to UTF-8 in 1.4.3. You are of course welcome to work out those bits and get it working on the newest release, but for me it turned out to be a quicker approach to turn to an older version than doing a workaround.

Check off “openssl” and “openssl-devel” when installing Cygwin. (Located under the “Libs” category.)

Remember how the basic interaction with Kannel was an HTTP GET to /sendsms with some parameters? Well it still is more or less – we just GET them from /sendota instead. Your basic string would be something like this:
http://kannel:13000/sendota?user=dummy&password=dummy&from=1234&to=12345678&text=urlencodedmessage

You’ll need a few more parameters for the message to get through; &settings=oma-settings, &coding=2, &sec=userpin, &pin=1234. (An explanation can be found in the Kannel reference docs. If you find that more academic than useful just try to the above settings, and turn to the docs if it doesn’t work on your specific device.)

In C# we end up with the following code:

string sendSMS(string uri)
{
   WebRequest webRequest = WebRequest.Create(uri);
   webRequest.ContentType = "x-www-form-urlencoded";
   webRequest.Method = "GET";

   try
   {
      WebResponse webResponse = webRequest.GetResponse();
      if (webResponse == null)
      {
         return null;
      }
      StreamReader sr = 

         new StreamReader(webResponse.GetResponseStream());
      return sr.ReadToEnd().Trim();
  }
   catch (WebException ex)
   {
      return ex.ToString();
   }
}

private void btnSendOTA_Click(object sender, RoutedEventArgs e)
{
   kannelServer = txtServer.Text;
   kannelPort = txtPort.Text;
   smsPath = txtOtaPath.Text;
   userName = txtUser.Text;
   passWord = txtPass.Text;

   string fromAddress = txtOtaFrom.Text;
   string toAddress = txtOtaTo.Text;
   string msgContent = txtOTAMsg.Text;
   string type = "oma-settings";
   string sec = "userpin";
   string pin = "1234";
   string coding = "2";

   msgContent = HttpUtility.UrlEncodeUnicode(msgContent);

   string otaPost = kannelServer + ":" + kannelPort + smsPath + 

   "?user=" + userName + "&pass=" + passWord + "&from=" + fromAddress
   + "&to=%2B" + toAddress + "&sec=" + sec + "&pin=" + pin + "&coding=" 

   + coding + "&type=" + type + "&text=" + msgContent;

   string kannelRes = sendSMS(otaPost);
}

And I’ve updated the UI of my test application:

Fair enough – but what would we go about typing into this message? A fairly good reference (for Nokia devices) would be the following doc:
forum.nokia.com – S60 OMA Client Provisioning

Most of these setttings are generic, and should work on other devices as well, but I’ve only tested these with my Nokia E75.

So say that you want to provision APN settings – you’ll use the following xml:

<?xml version="1.0"?>
<!DOCTYPE wap-provisioningdoc PUBLIC "-//WAPFORUM//DTD PROV 1.0//EN"
"http://www.wapforum.org/DTD/prov.dtd">
<wap-provisioningdoc version="1.0">
<characteristic type="BOOTSTRAP">
<parm name="NAME" value="My internjet"/>
</characteristic>
<CHARACTERISTIC TYPE="ADDRESS">
<PARM NAME="BEARER" VALUE="GPRS"/>
<PARM NAME="GPRS_ACCESSPOINTNAME" VALUE="internjet"/>
<PARM NAME="PPP_AUTHTYPE" VALUE="PAP"/>
<PARM NAME="PPP_AUTHNAME" VALUE="">
<PARM NAME="PPP_AUTHSECRET" VALUE=""/>
</CHARACTERISTIC>
</wap-provisioningdoc>

You’ll get a message on your device, you’ll need to enter a pin code to open the message, (I’ve set 1234 as a default), and you can then save the settings. Remember to include the “bootstrap” characteristic, or your device is not going to actually apply the settings.

Now, hold on a minute. I’ve created some cpf/cab files for Windows Mobile before to configure settings, and this seems familiar… Can I send off these messages to my WM devices as well? Ehh.. Yes…and no…or sort of… In the MSDN library you can see a lot of references to OMA CP samples for a lot of things. The problem is that your Windows Mobile device is running in a slightly different security context. By default the device doesn’t trust any OMA CP server. So if you send a message to the device you will not be able to use it. You’ll have to configure the trust first, and then send xml over-the-air. Which makes it slightly less usable in most scenarios. But as a “poor mans MDM solution” you could play around with it. Ok, that sounds a bit harsh. I’ve elaborated before on the differences of SMS-based and IP-based MDM solutions, and if I had to choose one of them I’d probably go for the IP-based. (MDM & “Enterprise Concerns”) But there’s nothing preventing you from using a hybrid model where most actions are performed over IP, but some are handled via SMS – possibly as a backup link to the device. I’ll be looking over some details in my lab, and if I come up with something of interest I’ll do a separate article on the perils of Windows Mobile and OTA.

While OMA CP is often used to provision OMA DM settings, and they are related, it is not the same thing. The xml is different, and usually the CP messages is just the gateway to the DM messages. Sending out complicated configurations over SMS has its drawbacks, and often you’ll just want to trigger a connection to the server for the actual configuration to occur over IP. OMA DM is more than a “push” service, and requires you to have a server on the back-end handling incoming requests from the devices. You could make your own OMA DM server (Nokia has a sample in Java you can start off with), or you can use System Center Mobile Device Manager from Microsoft, Afaria from Sybase, and a number of other products out there. Be aware though that some of these solutions might have different implementations of the OMA DM standard, and you may not necessarily be able to plug in your Kannel directly. (Afaria uses Kannel, so you can use what you know about interfacing with Kannel to make it a great combo.) And even if OMA DM is a standard there might be proprietary extensions to the server.