Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

SOTAs: The Telephony Code: Page 6 of 12

But while this separation makes integrating control functions into data-oriented applications simpler, it's also important to recognize that it imposes a wall between the two worlds as well. In particular, applications do not have access to voice media through the SOTA interface—while they can manipulate calls all day long, they cannot actually participate in the call through this interface. If you need to have your users and/or systems take part in a voice call, you'll still have to bring them to the telephony network, (whether that be SIP/RTP, a POTS line, or whatever.

Given the interest both carrier and enterprise vendors have in virtualizing their equipment, it's not surprising that standards have emerged addressing the requirements of both communities. Within the enterprise, a collection of standards from the Euro-pean Computer Manufacturing Association (ECMA) focuses on call-management functions, already widely implemented in private exchange equipment typically found on enterprise networks. This includes Avaya's and Siemens' IP PBXes, which both use a subset of the ECMA collection for their Web services interfaces.

At the heart of the ECMA collection is CSTA as defined by ECMA-269, which describes a generalized API for telephony applications to use when communicating with other services and devices. ECMA-269 defines more than 130 functions, ranging from basic call-control tasks to operational features, such as putting a device into a "do not disturb" state, and it also describes ASN.1 encoding rules to use for those functions. However, these specifications are heavily focused on call- and device-management, and are missing many important non-telephony functions, such as presence and instant messaging

The CSTA specification was subsequently supplemented by ECMA-323, which de-fines XML-encoding rules as an alternative to the ASN.1 encoding rules, and also provides examples for use with different SOAP bindings. ECMA-323 was further supplemented by ECMA-348, which defines a standard WSDL definition for XML encoding and provides examples for use with SOAP/HTTP.

However, we do not know of any vendors that implement ECMA-348. Avaya and Siemens both implement portions of ECMA-269 and ECMA-323, but that's as close as we've seen. Furthermore, many of the vendors we spoke to expressed the opinion that the ECMA standards are too complex for wide-scale adoption outside the vendor community. Given the broad adoption of CSTA however, we feel it's highly probable that these standards will continue to be adopted in some form.

The other significant set of existing standards are the Parlay collection of specifications, as published by the vendor consortium of the same name. Carriers frequently use the Parlay standards for their application interfaces, so the spec is more common in carrier-class systems and associated application-development platforms than in enterprise-class telephony gear. However, IT organizations that want to integrate public-network telephony devices and services into their unified applications will likely need to work with Parlay at some point.