VoIP Application Lifecycle Cost And Complexity

The rate of VoIP adoption has accelerated, and responsibility for VoIP has increasingly moved into IT networking departments. As this has occurred, and as businesses have begun to demand new voice-enabled applications, enterprise IT developers have been tasked with building these new converged applications. Early development efforts have encountered many of the same problems that most recently plagued the early developers of Web applications before platforms such as J2EE, LAMP, and .NET became available and reasonably robust. For example:

• The Complexity of How — Developers must worry too much about how to do things rather than focusing on what they want to do. The wide variety of arcane telephony protocols and vendor-specific APIs presents significant complexity, and developers tasked with creating innovative converged applications are struggling with the learning curve to successfully use these protocols. There is a need for protocol abstraction, similar to the way that application servers abstracted complexity in the Web environment.
• Lack of Experience — As VOIP causes responsibility for telecom to migrate into the IT data center organization, IT developers are being asked to develop voice applications with little to no experience in the telephony domain.
• Building From Scratch — Early developers of voice applications have also found that they must develop all the functions they need from scratch. There is no comprehensive library of pre-built and pre-tested functions available to pick and rapidly integrate into a coherent solution.
• Unique Voice Requirements — Like each new application architecture before it, voice presents unique new requirements. IP PBX's like Cisco's CallManager include basic support for voice processing, but they do not expose a robust media processing engine capable of sophisticated conferencing and prompt handling, text-to-speech, speech recognition, and other more advanced voice processing capabilities. Developers have repeatedly run into roadblocks as they try to deliver the solutions demanded by the business.
• No Visual IDE — Developers today have little in the way of application development tools. They must download and study protocol specifications and experiment with the use of the protocols to see what capabilities are available and if and how they work. Those tools that do exist primarily focus on solving the problem within the limited scope of inbound IVR definition. There is a need for a visual integrated development environment that can ease voice application development across the entire problem domain — from call control and media processing to IP phone display manipulation and integration with Web services.
• No Automated Test Tools — Once applications are developed, they must be tested, and again there have not been good tools available to automate this effort. For example, if a developer wants to see what is going to show up on the IP phone display when the program runs, he or she must look at an actual phone rather than having an integrated QA tool that can be used for functional or automated regression testing.

Learn how Metreos addresses these issues with the Metreos Application Runtime, Metreos Media Engine, Metreos Applications, and Metreos Visual Designer.