Lessons learned implementing IMS

Also, today's "IMS R4" — until now an industry secret.  Dean Bubley has already picked up on this thought.

At Spring VON, I gave a presentation on what we've learned, so far, in migrating our MyCaller ringback tones application from the Intelligent Network (IN) implementation in use by ~30 operators today, to an "IMS" version that can be deployed in networks that today are nominally based on the 3GPP's IP Multimedia Subsystem (IMS). Martin Geddes encouraged me to write up my talk. 

The full article is here.  For the impatient, here are the takeaways.    

1. It’s very early days for IMS. Today’s “IMS” networks are combinations of SIP infrastructure with 3GPP Release 4 softswitch-controlled voice service.           

2. IMS is about connection control, only. Only part of your application has to change. For MyCaller, ~90 percent of the software remains the same.           

3. IMS enables multimedia ringback, i.e. video! So there is significant new functionality, versus today’s audio-only ringback.           

4. Parallels with Intelligent Network are striking!           

5. Most application–specific data remains outside of IMS. In particular, operators do not want to add data fields to their Home Subscriber Server (HSS).           

6. Application–specific MRFs make sense. Operators tend to avoid sharing resources between diverse applications. And, for rich media, application–specific MRFs can be more cost-effective.

7. Operators await 3GPP Release 7.  At least anecdotally, several operators have suggested that 3GPP Release 7 is the first complete, stable, and consistent version they will fully deploy.

Again, the full article is here.

Comments

[Alex]

1: It's early days. It's *still* early days. Perhaps it will always be early days.

2: Why should it require *any* change? Your app has to do a SIP REGISTER transaction, and then complete whatever SIP-mediated transactions it needs to with the other party/parties' user agents and any servers that are involved. But this would be true of an IETF SIP app. Or, if we relax the constraint of it having to be SIP, anything else.

3: I can't wait.

4: Yes...would one of them be "incredibly complicated and overcentralised"?

5: Good point. In a sense, if you're talking about the application server, you're already being less IMSsy, as after all the point of a standard application server is simply that it can send and receive various messages from the network core (or directly from a p2p client), and then do stuff. Could just as well be IETF SIP, SS7 over IP, or SOPE (Some Other Protocol Entirely - frex web services, REST, XML-RPC, VoiceXML, SOAP..)

6: And sharing resources between diverse applications is a core justification for IMS.

7: Bill Meredith of 3GPP said in Monaco that "Release 7 is an IMS you can deploy!"

[Istvan Tetenyi]

The Intelligent Network concept was fundamentally criticized by the "The stupid network" back into 1988. Why should we think the the IMS that is a follow-up of the Intelligent Network model is different. The Intelligent Network and the IMS both defend walled gardens that are to be opened for the public.

[brough]

Alex, Minor clarification on point 2 - I'm talking in the context of migrating an existing IN application to IMS (not SIP to IMS), so something has to change. My point is, what has to change is a lot less than most people expect.
Otherwise, we seem to be in complete alignment. Thanks for the quote from Bill Meredith. It reinforces what I've heard from a number of sources.

Istvan, We agree, although your timing is off. IN was conceived in the late 1980s and standardized in the early 90s. David Isenberg's classic article "The Rise of the Stupid Network" was written in May 1997, circulated via email, and then published in the August 1997 issue of Computer Telephony magazine. So David's article came when IN was at it's peak.

[Srini K]

On Item(5) - I would like to think that - this is primarily because operators are trying to port/convert their existing SIP Applications (like your scenario) with minimal changes and effort (and therefore cost) - to work with the new R5/R6 IMS infrastructure. So they take a phased approach - In this case it is easier to leave the app-specific data with the app - and in a later phase - they will attempt to move any subscriber specific data over to the HSS.

On the other hand, one problem here is that the HSS doesn't understand this 'app-specific' data and acts as a transparent-data-store. And any provisioning or 'semantics' associated with this data continues to need to be handled by the App - as the name suggests its app-specific. So now we have a semantics,syntax-aware App and then a data-store that's elsewhere, and a new interface to retrieve/store this data - so it is probably seen as easier to leave the data-store also at the App-server - for now.

On the MRF front, the cost benefit again I think is probably just the effort to integrate a new MRF with your APP - than anything else.
If the MRF in your note is a reference to todays SIP/H248/MGCP Media Servers - then the implementations that I have seen today pretty much do the same things - like Net-Ann, VXML and related - the same way. So I would think there is not much technical reason fo rnot being able to "share" these MRFs between apps today.

With R7 - I think the number of technical reasons (interfaces, procedures etc) for not-deploying IMS have come down greatly - and it probably is now just business analysis for each operator. Yet again, even for an R7 implementation I am sure operators will choose not to implement ALL pieces from the standard - would that then make it "non-IMS/hardly IMS"? as well?