OneVoice to solve IMS adoption issues?

[mgrayson]

The recently announced OneVoice initiative is an attempt to define a minimum set of functions an implementation must support (in IMS Servers, in the Network , in handsets) to provide VoIP service over LTE (http://news.vzw.com/news/2009/11/pr2009-11-03a.html).

Is this a recognition that the 1000s of pages of IMS framework specifications written over the last 10 years simply offered too many implementation options for multi-vendor deployments to be guaranteed interoperable?

Does this beg the question, if a strict profile is needed for IMS-voice interop, is the same needed for every other IMS-based service?

If a profile is indeed needed for every application (voice, RCS, etc), then how does this impact the speed at which new interoperable services can be deployed on a common IMS framework?

[tredman@cisco.com]

If the question distills down to whether profiles are good or bad, let's look at the alternative-- if the implementation IMS was defined such that profiles were not needed, we'd hear that IMS was "rigid', "restrictive", "brittle", etc.  The real question is whether an alternative "interoperable" system exists that would not require a profile.

The situation is that IMS is defined from protocols that are inherently extensible because experience has shown us that we can never anticipate all of the corner-cases that arise in designing a complex system.  So, whether it's IMS or something else, "extensibility" will be a fundamental characteristic of the system.  In a world of aggressive innovation, we'll see this extensibility result in the creation of many variants and they won't be interoperable until a community of implementors decides to converge on a specific variant.  The expectation is that the community will arrive at the variant that best serves the needs of the majority.

The existence of a "profile" may therefore be seen as a strength.  Thoughts?

[rsynnest]

Interesting question/observation.

I contend that breaking the BIG "migration" problem into smaller segments/profiles, and offering more focused elements which are easier to "digest" - like OneVoice - into the whole eco-system of system migration and "adoption", narrows the scope and helps focus on solving very specific challenges. So yes, I expect if we look into real customer adoption of "IMS", it won't follow specs - it'll follow pressing business needs, one step at a time.

In fact if we observe live IMS deployments, it suggests there was a fundamental flaw in the basic premise of IMS as an "entity" (a thing) to simplify and realize IP "adoption", legacy service "migration", and "open/standards based" interoperability to enable brand new world of revenue generating apps. Time has revealed a different reality - tieing together legacy systems and next generation systems ain't easy, needs customization, and is more about "methodology" and system integration/process than about inserting a magic multi-protocol adapter "entity" that seamlessly interconnects all the old stuff with the new stuff, all the old procedures with the new ones.  aka "IMS" viewed and discussed as a singular noun - a thing or small collection of things - does not address the real problem

The collection of "things" that comprise "IMS" were just the tip of an iceberg, where methodology and process under the surface for thorough "system integration", "migration", "adoption" have proven to be far bigger hurdles to overcome. And where does that lead? To alliances and methods for tackling the "process" in stages.

OneVoice is just one subset ... I expect we'll discover plenty of other "subsets" to the "process" of adoption, both for those operators that have already started the adoption, and those that take on that challenge in the future.