Nay to the Naysayers!

by Richard “Zippy” Grigonis
We’ve heard it before: Slow progress on standardization and interoperability, unclear business models, unknown economic benefits. IMS didn’t exactly rocket out of the gate in 2007, but as you’ll see from the contents of this issue, it didn’t stand still either.

France Telecom (News - Alert) has been running its Technocentre that creates and analyzes IMS-compliant services, and since the world’s telecom infrastructure is going to end up with a single service architecture, they merged their fixed, mobile and Internet technical teams into one big entity.

And 2008 is shaping up to be a really interesting year for IMS. (Our bellwether, France Telecom, estimates that between five and ten percent of its revenues will be derived from full or partial IMS services by the end of 2008.)

Work still needs to be done of course. Massive interoperability testing occurred during 2007 and will continue into 2008.

Moreover, IMS calls upon SIP (Session Initiation Protocol (News - Alert)) to jump through quite a few hoops, far more than the original SIP specification called for, which is why the history of SIP has been a tabula rasa upon which has been written the hopes and expectations (via extensions) of the world’s telecom experts. Continued fiddling with it will occur as IMS percolates through the infrastructure.

Still, SIP will remain the supreme communications session protocol, and thus requires the most tinkering to make IMS work smoothly. On the web side, its alternative would be SOAP and flavors of XML. Soon we will have to worry about merging the two of those together. Right now the IMS architecture leaves things to a magic box that we call a SCIM (Service Capability Interaction Manager), within which something magical happens, reminiscent of the ‘magic’ that goes on in a Session Border Controller when it performs SIP-to-SIP peering.

All of these standards will have to interoperate to some extent, but the SOAP and the XMLs are identified by the types of domains for which they’re responsible. Much work will center not on grandiose, architectonic things, but application and user-related stuff. Services and systems will have to better explicitly define what they are trying to communicate – what are the semantics relating to a particular communication session? What’s the end user goal? The major end user phenomenon these days is ‘presence’ and that still has a lot maturing to do.

We haven’t yet worked out the usage models for presence for all possible environments.

When people talk about presence these days, they usually describe some kind of modified‘find-me/follow-me’ scenario. That’s not good enough for a future dominated by IMS and FMC (Fixed-Mobile Communications).

Imagine that you’re sitting in your office and there are five devices near you and three are charging and one’s low on battery, and you’re near a computer screen and somebody wants to call you, and they’re willing to call you through any of those devices. Now, unless the caller is not a friend of yours, what’s going to happen? Things can get very complicated when you start to consider all of the different possible presence scenarios. You’re not going to want to make all of the presence setting modifications yourself on a minute-by-minute basis.

Now, SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) has been devised for presence, but the actual presence models and the automation of modifying presence settings on-the-fly still needs to be worked out a good deal more than it already has. In the future, the presence manager will be the most important component of any communications system. Avaya (News - Alert) has been working fervently on these. And Alex Saunders at Iotum also has an interesting presence server you should take a look at.

And when everything is worked out, IMS will be ready and waiting…

Richard Grigonis is Executive Editor of TMC (News - Alert)’s IP Communications Group

IMS Magazine Table of Contents