We’ve got another article in IPConvergence.tv about the intersection of IMS and Mashups:
Can you think of two more different application platforms than IMS and Web as platform? I bet that, in fifty years, it will be difficult to imagine that both architectures were developed during the same period in time, and that both had such massive amounts of attention and investment. Whereas it is quite clear that the Internet is here to stay, and that software as service will dominate application architectures for as far out as we can see, the role of IMS in this larger environment is less clear. Read the rest of the story…
Hats off to the forward thinking sponsors of this wonderful site. I personally believe that there is a place for IMS, but it will never be the dominant application platform. Many people disagree. I’ve been wrong before, and maybe now again, but IPConvergence.tv is a place to hear all voices. Hear, hear!
Nonsense article.
What architecture would you recommend telcos should evolve towards? An operator could choose to offer web services on an IMS core.
I get the impression that you don’t actually understand what the IMS promises, it may be far from perfect but it’s the only game in town for large telcos moving to all-IP.
These are extremes. SaaS will never get widespread adoption by the big bureaucratic and highly regulated Fortune 500. Can you imagine Sarbox, HIPA, or EU privacy in an environment where the government can do warantless inquiries. Furthermore, at large scale the enterprise can often do it better than the service provider, hence why you have PBXs and not CLASS at large companies. Conversely it is absurd to think IMS can do anything other than real-time session. Carriers who think they can ditch Web 2.0 for multi-media enabled service defined by 3GPP have a very limited future indeed. Nevertheless, I have yet to see anything but a dedicated SIP infrastructure deliver consistent, reliable and scalable real time (defined as person to person requiring less than 200ms latency) session oriented services.
Has anyone considered that the two could be complimentary to each other. Peace!
“Has anyone considered that the two could be complimentary to each other.”
Exactly. The IMS offers the scalability, QoS and reliability required to offer large-scale communication services on wired & wireless IP networks. I fully expect to see web-services offered from carriers’ IMS cores.
Thank you, both, for your comments!
JIm, I suppose I’d like to think this article is more than nonsense, as I wrote it. But you might be right and I might be full of crap – I’m never that sure of myself.
My biggest issue isn’t that I don’t understand what it promises, it’s just that I seriously doubt that it can deliver on what it promises, and for very specific technical and business reasons. My discussions with high level executives at very large telcos confirm my suspicions that no one is clearly reporting benefits by deploying IMS solutions, and no one is pretending that IMS has fundamental advantages over dedicated SIP networks. Indeed, as IMS increases its scope to cover even more functionality, it deepens the problems and increases the chances of its failure as an architecture.
My friend Henry would claim that SIP is the only game in town for large telcos moving to all IP. As a matter of fact, I often hear people accuse him of nonsense as well. At least I’m in good company.
Todd – yes, I agree, they could be complementary, but the web world will dominate the long term, furthering the demise of IMS as an important application platform. Just my two cents.
Oh yes, perhaps I didn’t emphasize it like I should have, but I do think that the best IMS play is in a blended environment, where IMS provides the basic functionality which is then exposed to developers as web services. My point is that IMS purports to be the best way in which service providers construct and deliver new services and applications, and I think IMS fails in that primary mission because it is a closed, proprietary, heavy weight architecture that doesn’t provide particular support to SOA or web services approaches.
“IMS purports to be the best way in which service providers construct and deliver new services and applications” – That is IMS Cool Aid.
The overlooked beauty of IMS is the decoupling of session control from transport and access. This, along with SIP and IP, give Carriers some significant OPEX and CAPEX savings through network flattening, horizontalization and commoditization of components.
Revenue growth on the other hand, will be tied to service creation, and that I agree with you will in the long run come from SOA or web like approaches.
Unless telcoland wakes up soon, either 1) TEMs will find IBM, MSFT, BEA, Oracle or a host of others taking high-margin SDP positions in the network to do this, or 2) Google, Yahoo, MSFT or a host of others will wholesale disgusting proprietary or IMS/OMA/Parlay/TISPAN/etc services and again turn it into high-margin web opportunities, further disintermediating the Carriers.
Well maybe “nonsense” was a little strong
There is no longer any question in my mind as to whether IMS will reach the critical mass that it needs to be successful, I’d argue that it has already passed that point.
If you are an existing operator there is no other realistic option for evolving your network to all-IP. First generation softswitches will not cut it at the scale required by carrier networks, while also not providing critical features (like AGCF for example) and obviously such softswitches are entirely proprietary implementations (unlike IMS).
IMS is not closed or proprietary, it is certainly heavy-weight, but that should not be a criticism for a technology that will serve hundreds of millions of users. Arguably the SCIM is well positioned to provide the interface from IMS to SOA & WS. Again, not perfect, but the only game in town.
I assume your friend Henry knows that IMS uses SIP for signaling?
Hi Todd -
Yes, I understand.
My exact questions to the operators of both greenfield and brownfield installations was precisely that: have you seen any capex or opex savings from your deployment of IMS. They said no. Then they gave me a look. I said no? They said “no”. Then we went back to our wine.
My contention about revenue growth is that nearly all value added service offerings provided by carriers fail, for a number of reasons. Some don’t, but it’s a really bad bet. Services such as caller ID, SMS and ring tones are few and far between, and the ones that are successful are easily replicated by competitors.
The real innovation seen in the last years come from smaller shops, developing in Web like ways and who are close to the customer – none of which are carrier attributes. I think you are exactly right about telco’s waking up, and the next gen SDP guys or the large Web concerns will stomp all over them.
I suppose I’m not a big fan of IMS, and I’m probably too biased against it. Maybe I’ll call my IMS Forum friends and listen one more time, as I refuse to read the 30k pages of the multiple standards again.
Thanks for writing back!
Thanks Jim, and you may be right. Maybe this will be like the IN push in more ways than one. Maybe this is nonsense. A big part of why I feel this way comes from my gut.
Henry would be apoplectic if I suggested that IMS uses SIP for signaling. He’s a purist and, frankly, he gets apoplectic enough without me egging him on. He would feel, as many others would, that IMS intentionally sucked in SIP to bastardize it, to the large vendors benefit. I’m not so paranoid as all that.
I admit that I don’t have a better option for carriers, except to tell them not to invest in IMS, or if they do, to recognize that it’s all about large scale reduction of Capex and Opex, not new service creation. I even feel shaky with that view. (Read the above note). Many I speak with don’t like that particular piece of advice, especially representatives from large vendors.
All I know is that it’s been a long time since I’ve seen any sort of innovation from the carrier market, and the innovation I have seen from the Web world seems directly at odds with nearly everything that IMS represents.
Time will tell with all of this, and I’m happy to be the contrarian. Feel free to flip my bozo bit, I’m just trying to be honest.
Oh yes – one more thing – any standard that can only be reasonably implemented by a handful of large carriers and vendors is practically closed. In addition, if I don’t miss my understanding, IMS seeks to control the execution environment to ensure quality of service and to ensure consistency of billing – in essence to create a walled garden – and is in this sense closed as well. I think I’m too tired today to really express myself clearly – sorry about that.
IMS already has free & open source implementations, one large vendor’s CTO went so far as to tell me that all core IMS (CSCF, HSS, MGCF) functions would end up being free in much the same way as the operating systems on which they will run. I’m not so sure about that but it was interesting to hear it argued. This particular CTO recognised that there will be little value in simply switching calls in the future and the value will inevitably shift to the applications (on top of the IMS).
The point is that carriers need to implement something that will provide the same kind of service guarantees that they have today in the PSTN & PLMN. They also recognise the need to evolve complex services in this environment and you are quite right in noting that large operators do not innovate well. This is where initiatives like the BT web 21 SDK are really interesting (which I know is not IMS based today!). Operators will expose network functionality to 3rd parties while retaining a slice of the action. The IMS provides a suitable framework to allow this kind of service exposure to happen.
I don’t think this is at odds with the web world in any way, far from it. The IMS allows the PSTN/PLMN to evolve to IP while also providing the basis for more open services. I don’t know what you mean by your walled garden comment, the IMS will exist in an environment of ubiquitous IP connectivity effectively bypassing any such walls.