What do MMS and Brick Walls Have in Common?

I've written before about my interest in pursuing MMS as a method of rich-media distribution.  Indeed I've directed a lot of my efforts on the Mobile MUSE projects trying to leverage this technology in the projects.

In a previous life, I've spent a lot of time in this area; participating in standards definitions and understanding carrier requirements as well as dealing with the issues of interoperability between 3GPP and 3GPP2 domains.  However, until the mobile MUSE projects, I've had no practical experience with trying to use MMS as a service delivery technology.

Now that the Mobile MUSE project finally has access to some CDMA phones and networks (through the gracious participation of one of our industry partners: Bell Canada), I've finally had a chance to experiment the inter-carrier delivery of MMS.  Previously I've been restricted to using only a GSM carrier and have been almost exclusively using Nokia phones (again, through the gracious participation of Nokia as an industry partner).  The problem with Nokia phones however is they tend to represent the best-case scenario for feature implementations.  Nokia has always pushed hard in promoting the standards when it comes to features and interoperability.  Their MMS implementation on handsets has long been a very rich implementation indeed.

To date MMS has been promoted throughout the industry as picture and video messaging.  However, MMS has the potential to be much more than that.  Through the use of SMIL, relatively light-weight audio visual presentations can be created using a variety of media types.  Admittedly few handset users would bother to create such presentation, but applications on the other hand could certainly benefit from this cabability.

In any event, I finally got a Samsung SPH-A920 phone over the Bell Mobility network.  So armed, I was prepared to test interoperability between GSM and CDMA.  My first experiment was to send an image from the GSM network to the CDMA network.

Well, the good news is that this represented my most successful experiment I conducted.  The bad news is that even this paltry experiement disappointed.  As near as I can determine the time between when I actually send an MMS and when the recipient receives can be best measured by use of a calendar, or an hourglass.  It seems to help if you send a couple.  The first one tends to get lost in the ether somewhere.  A second one tends to pull it out of hiding; although there's no guarantee you'll receive them in transmitted order.

I then tried to transmit a picture from the Bell network to the Fido network.  I made the mistake of tagging some text onto the picture.  I shouldn't have been so hasty.  SHould have just stuck to the basics.

The good news is I received the "picture".  It was in a most peculiar form however.  The MMS on the Nokia device resembled more of an e-mail with attachments rather than an MMS.  There were recognizec "objects" within the MMS; one was a pictuer and the other was the text.  Not quite what I expected when I sent it.  Give credit where credit is due however.  The picture did actually resemble the picture I transmitted from the Bell network.

I then tried video messaging.  Things took an ugly turn here.  The good news is that from the GSM network to the CDMA network, video works.  The bad news is that going the other way sort of sucks.

Specifically, the audio portion of the video is encoded using the standard audio encoding algorithm of QCELP.  Now QCELP is well-known in the CDMA world, but AMR is the codec of choice in the GSM world - and indeed is the MANDATORY CODEC REQUIRED BY THE 3GPP2 MMS SPECIFICATION!  Alas when I received the video on my GSM phone, the Nokia software got quite upset with it.  First it again, didn't exactly "play" the video.  Rather it simply presented me with a message with two objects in it: a video and an audio object.  Though I couldn't play the message, it did let me look at the video using the builtin Realplayer on the Nokia platform.  Now the Realplayer software roughly told me this:  "I'll play this video, but the audio portion is really quite sick".  So I was able to see the video (sort of), but unable to hear the associated audio.

Now this has been one of the merits I've been promoting about MMS.  Namely the network-based transcoding that handles these network and device differences.  Indeed the MMS specification defines exactly how this transcoding is to be performed.  Alas, someone at Bell or Fido neglected to read the standards and simply did whatever pleased themselves.

Undaunted, I went for the holy grail:  I used my Nokia phone to create a multi-media slide show.  This was as relatively simple slide show.  I had a couple of images, and audio stream and a single text element.  I used the default timing sequence of 5 seconds per slide and sent it off to my Bell phone.

Alas the Samsung really didn't do much with it.  It completely ignored the audio object and in fact didn't even bother rendering the slide show.  It correctly identified the fact that there were 4 objects in the MMS (one text, two images, and one audio).  However, it seemed completely unaware of the SMIL markup surrounding those objects.  As a user I was able to manually scroll between the objects, but that misses the point entirely.

So my great goal of encouraging application developers to create SMIL presentations as rich-media content, has hit a very big brick wall.  Sure if all you customer base has Nokia phones (actually I hope other GSM phone do at least as well, but I'll have to wait for more devices to test that).  If not, then your multi-media extravaganza risks being converted into a useless collection of half-rendered objects.

I blame all of these problems on Lightsurf.  You see Lightsurf is the technology behind Bell's implementation of MMS.  Indeed Lightsurf has been around for some time as a solution for picture and video sharing.  In fact around longer than MMS.  Lightsurf was originally adopted in the Sprint PCS network as a non-standard implementation of picture and video messaging.  However, for a long time now, they've been promoting their compliance with MMS.  Apparently by compliance with MMS they mean, they'll digest it burp something out that may or may not be of value.

So there I am,  MMS for all its promise seems to fail at even the most trivial task of inter-carrier video messaging.  For all its promise, MMS as a delivery mechanism for rich multi-media - at least in Canada - seems some piece away.  And that's too bad.

I haven't tossed out my baby with this bath water yet however.  MMS integrates nicely into handsets user interfaces making picture and video messaging relatively easy for end users.  In that sense as a method of rmobile ich content authoring for applications it still provides the best model for that.  However as a delivery mechanism from applications to users, the problems are great.

That leaves our projects with some serious headaches.  How is rich-media going to be adapted and transcoded for differing networks and carriers?  I'm of course working on that problem, but for sure it will not be a simple as the elegance of a full MMS solution.