IMS handsets and IMS proxies

At 3GSM last week, I caught up with a number of providers of phones, SIP/IMS-related handset software, and their counterparts on the network side. I wanted to see how far things had moved on since I wrote my SIP- and IMS-capable Handsets report*. In the middle of last year, it was very evident that mobile operators' possible deployments of IMS faced a fairly insurmountable problem (in addition to all the other problems with IMS...) in the lack of IMS-capable phones, and the lack of any agreed standards or consistent specifications to create them. (And how to to integrate IMS and non-IMS apps on the phone, and myriad other issues).

Although numerous vendors have pitched "IMS client frameworks" for handsets, they have used proprietary interfaces internally with few open APIs and limited developer support, meaning that any innovating operator or application vendor would face a nightmarish porting challenge, if they wanted to get a cool new IMS app across multiple phones. While a few, very large and prescriptive carriers could possibly "standardise" on one specific framework, insisting that all handset suppliers used it, this is unlikely for the majority of service providers.

The net result - a bottleneck in handset development for IMS services. A few things have been standardised - PoC (push to talk) for example. The GSMA was highlighting its video-sharing interop trials in Barcelona last week. Big deal. Neither of these are going to generate even a small % of the revenues needed to build a business case for a mobile operator deploying IMS infrastructure. What is needed is either proper cellular VoIP (which has other issues), or some way for the "next MySpace" to be developed for IMS and adopted virally across a broad range of operators, handsets and IMS client software variants.

My discussions in Barcelona last week suggested that not much had changed, unfortunately. There's still no "alliance of IMS client framework suppliers" to foster interoperability. There's still no broadly-agreed basis of operator requirements for IMS phones (I know that OMTP was working on something, although no details are apparent yet). There's still a lack of developer support for software vendors wanting to write IMS applications that actually give a decent user experience on a range of phones.

Meanwhile, adoption of handsets which include a "naked" SIP stack, addressable by non-IMS 3rd party applications, continues to increase rapidly.

The only movement around IMS handsets appeared to be a growing consensus (OK, OK, perhaps a forlorn hope....) that a new Java API, JSR281, could fix the problem. The idea is that developers (operator-internal or 3rd party) could just write normal Java applets that use IMS capabilities. In principle this seems reasonable... apart from the fact that much of the cool stuff on handsets is now migrating to the browser rather than the Java engine, or else is in completely separate "domains" like a music or TV section of the phone's software. I'm somewhat pessimistic that JSR281 is a complete answer to the problem.

One alternative approach I've started to see is the possibility of using "IMS proxies" - basically embedding some form of IMS user agent in a home gateway, femtocell, PBX or something else, converting applications or content so that it can be used on "normal" non-IMS handsets. Clearly, this isn't an ideal option either, but it might end up being seen as a more practical choice in the short-to-medium term.

(*my IMS handset report is still the most in-depth published analysis available covering these issues. Contact me via info at disruptive-analysis.com for details)