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.
