Avaya, Cisco, and Sphere Communications took the first step this week towards VoIP-enabling corporate applications by introducing Web service interfaces to their underlying VoIP servers. Such interfaces enable applications to perform nearly any VoIP functions, such as initiating, answering and transferring telephone calls, just by calling a web service. These interfaces radically reduce the development times needed to deploy VoIP-enabled applications while expanding the pool of potential developers by eliminating the need for telephony expertise.

"Ask a SIP developer to create an application that will notify you when someone calls your office and there's no answer and he or she will tell you that it'll take one or two weeks. With a web services interface you develop the same application in a few minutes," says Wu Chou, technical manager in Avaya's dialogue system research group. VoIP mashups not only become possible they become probable.

However, today those WSDL definitions remain proprietary and replicate the mistakes made within the TDM world. The telephony vendors will pursue third-party developers in an attempt to create an ecosystem of applications that will enrich the value of their product architectures and drive more customer value. Limited resources will force those developers to focus on specific vendor architectures, ultimately leading to small range of applications that depend on a particular VoIP backend in order to function properly.

Vendor-specific applications may provide short-term value for Avaya, Cisco and Sphere, but it will inhibit their strategic goal of transforming how they sell telephony services from a cost-driven process focused on improving IT efficiency to a business –driven discussion focused on growing top-line revenue. Such an achievement will require VoIP vendors to aggressively market and sell to executives charged with top-line tasks such as improving the success of marketing campaign or raising customer satisfaction levels. Such scenarios require business analysts that are versed in specific industry requirements, not just in the technical requirements of deploying VoIP. This, in turn, requires that the specifics of a business solution be divorced from the underlying VoIP environment. Such a distinction isn't possible, or at least is significantly hampered, when the applications are tied to the underlying telephony server.

A better solution is for the VoIP community to coalesce around a generalized WSDL definition independent of the backend telephony architecture. Such an interface will create a larger potential market providing a greater incentive for developers to create VoIP-enabled applications. A generalized WSDL definition will reduce the resources required by those developers. With applications divorced from the underlying VoIP architectures, business, not technical, specialists can be engaged to sell those applications to executives who may never be involved in a discussion with IT.

Chou and the Avaya team proposed such an interface in a paper presented to the IEEE conference back in July, 2004. The paper defined Web services-to-SIP calls. Avaya should use that that paper as the basis for work in the OASIS or the ,a href="HTTP://WWW.W3.ORG">W3C technical consortiums specializing in Web services. Cisco and Nortel should support the approach and not be afraid that it will undermine their own efforts to capture the lucrative applications market. Their SIP implementations still use proprietary extensions for more advanced call-control features, such as malicious call trace or other features. The Web services interface will allow vendors to create applications with common base functionality and still leave the possibility of up-selling more advanced capabilities for their own environments. By creating a common-based of capabilities, however, third-party developers will minimize the amount of recoding that's needed and grow the range of possible of applications for all environments.