A Classification of IMS Critics, Part 1

I am usually very upset when I read articles or presentations that dismiss IMS as yet another stupid telco technology. It might be because I am an IMS dogmatic devout, but I prefer to think that this is because most of the time the writer does not know what he or she is speaking about, and has a personal or company agenda when performing this IMS bashing activity.

I have my own classification of IMS critics. In this first post on the subject I will speak about one of the most active anti-IMS groups, at least at the begining.

#1 The OSA/Parlay Gang

For those who do not know, OSA/Parlay has been for some time and for some people the future of telecommunications. The original idea was that the exposure of network capabilities to 3rd party service providers through a set of CORBA APIs would generate plenty of new services.

Though OSA/Parlay is still branded as a success by the Parlay group, I think that it did not work out as initially planned. First, the APIs did not expose so attractive capabilities (how many 3rd party service providers want to control voice calls?). Second, the APIs were far too complex and the usage of CORBA did not help making them simpler. Third, the architecture implying the clear separation between an application server implementing service logic and the OSA/Parlay gateway was far from optimal for an operator wishing to use OSA/Parlay to implement its own services.

Then came Parlay X, which is much better as it relies on the idea that network capabilities should be exposed through simple web services. This said, it is still not clear whether the Parlay X services are the best telco web services you can think of.

OSA/Parlay was already struggling for success when IMS came. While the IMS service architecture included an OSA/Parlay gateway from the begining, it rapidly appeared that IMS and OSA/Parlay were perceived more as alternatives than complements.

A problem was that the OSA/Parlay APIs were specified to apply to a pre-IMS circuit-switched network. On the other hand, SIP and IMS defined a new world that did not optimally map to the old one. Moreover, the IMS service architecture came with a "SIP Application Server" alternative, and it was rapidly clear that all initial IMS applications were implemented on a SIP AS rather than an OSA/Parlay AS.

More generally, OSA/Parlay makes sense when you need to provide an IT interface to a telco network making use of complex and specific telco protocols like SS7. SIP is far from being such a complex protocol, and therefore makes the need for a protocol-independent exposure layer less critical. More especially when this exposure layer is unable to provide access to most of SIP capabilities.

IMS therefore became a threat to companies implementing OSA/Parlay gateways (at least until they manage to adapt their products to it) and to individuals who spent years evangelizing the world about OSA/Parlay.

I think that some of these individuals want the failure of IMS as a way to legitimate their own mistakes, i.e. "OSA/Parlay was a good technology, but this was a good technology for a telco industry near to its demise. Demise for which IMS is certainly the main reason".

Typical arguments from the OSA/Parlay gang (sometimes conflicting):
- SIP is a complex protocol like SS7. Nobody can directly implement an application on SIP. You need a gateway.
- The success of IMS will be measured through its ability to support the same voice quality as circuit-switched.
- IMS is the new IN.
- IMS is widely opening the door to Internet companies so that they can kill telco operators.

As I wrote above, I think that as OSA/Parlay companies find new IMS-friendly products to sell and OSA/Parlay gurus re-invent themselves as IMS or SOA gurus, this gang is weakening in strength.

Christophe