Mobile Applications Commentary

Great Jon Udell interview with Dr. Joel Selanikio, lots of interesting mobile commentary in there. First two bits that really grabbed my attention:

Think about what you could do if you could give access to all the information on the Internet to anyone with a cellphone.

Amen to that. They’re talking mostly about SMS and base cell phone apps, but on the details I actually disagree. I think it is going to be the mobile web that becomes the defacto development platform on mobile devices. The web in a different form than we have now, but the high capability browsers we see on high end phones are going to end up on every phone soon enough. And this one, fantastic:

It’s kind of comical how Twitter is the hottest thing on the block right now and all these people with their 2 gigahertz computers and huge displays are sending each other basically text messages over the web.

Yea, “funny”, that’s really funny stuff. I love the way all the pundits switch direction without acknowledging at all just how totally and horribly wrong they were. Always gives me a chuckle.

There’s a bunch of great stuff in there from document formats that scale from traditional web use to use over an SMS channel to use of SMS as a general packet transport for richer applications. I want to take just one thread and pull on it a bit however, using SMS as a generic communications mechanism for higher level applications. They’re talking about it as using SMS to transport and stitching together the content transparently.

So first off, I assume the reason for this is that the networks in the regions they’re operating in aren’t at least GPRS capable, or the potential users of the systems are on prepaid plans where all they have is voice and text messaging. Took me a little while to remember that constraint might exist in Africa. Bad me, I should have been thinking more expansively to begin with.

Okay, so problem established. We want to make this work on the existing networks with the existing handsets. I believe that means that the programs that do this would have to be written in Java, otherwise it wouldn’t really be usable by those folks. What’s the Java support like in those handsets? I believe they would need a Java implementation that support JSR 120 for access to messaging APIs. And even if they have JSR 120 the only way to get access to the SMS stream is to listen to “SMS messages sent to a certain port”.

This part of the systems has always been very fuzzy for me, even though at one point I implemented a system that did send SMSes on different ports (we had the server that did it at a test site at Telecom Italia Mobile). I believe that most external hookups to telecom networks don’t allow for sending SMS messages from outside a carrier in to an alternate port. I assume that normal text messages sent to the end user have some reserved port for SMS, like port 80 on tcp is the standard port for HTTP. Can the SMS aggregators most of us go through send SMS to alternate ports? I checked the XML API for Clickatell and I don’t see anything. Is there an SMS aggregator that would allow for sending on an alternate port?

Or would we have to do this peer to peer somehow? Sending from a handset with an alternate port? In the JSR I don’t see client side sending exposing a port number either, it seems to be a server side function. And what if these messages would have to cross carrier boundaries? Would they retain their port number in the interchange?

The examples that I’m digging up seem to be distinctly non-end-user focused, I’m not sure the technique would really work out without carrier backing. Does anyone know what the details are around this stuff? Any good references out there?

This entry was posted in Community, ThisIsMobility. Bookmark the permalink.

6 Responses to Mobile Applications Commentary

  1. Tom Hume says:


    It’s been a little while since I looked at this myself, but I think what you’re after (port addressing of SMS messages) is part of the WAP Push spec, not SMS. In the distance past (late 90s) I think it was called narrowband sockets, then the WAP forum either appropriated it (or were “inspired” by it). You can deliver messages to Java apps by using correctly addressed WAP Push messages using the push registry in MIDP 2.0 (we’ve done this before):

    ISTR ( tho I’m not certain) that when we did this we were sending messages across carriers too – in the UK at least.

  2. PanMan says:

    Altho I agree that GPRS makes more sense for most applications (especially because SMS costs up to thousands of dollars/Mb), technically both options are possible. The JSR you linked to includes port numbers:
    “However, this Java API supports the use of port numbers to specify a Java application as the message target.” and, for incomming messages, there is an example: // Get our receiving port connection.
    messconn = (MessageConnection)“sms://:6222”);
    And with clickatell it’s also possible, altho you have to encode it yourself:

  3. jpop says:

    Yo Mike, I recently read this, hopefully this might help you out.

    I recently came across your blog, and I have to say it’s outstanding!


  4. Pingback: Mike Rowehl: This is Mobility » Blog Archive » SMS on Alternate Ports

  5. Mike, I’d love to talk with you about these issues sometime. –Joel

  6. Ron says:

    Wondering if you have worked on any Mobile live commentary application? We have developed the application using a Sound recorder application which records the Live commentary and converts it into 8 bit Mono .wav files. These files are typically 10-15 seconds duration and played by the IVR in a sequence. Thus we have made a scheduler to place these 10 seconds wav files one after the other in a schedule for the IVR port to play out. It does not seem to working too well. Pls advise.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">