Introduction

The main goals of implementing Voice over Internet Protocol (VoIP) systems in most companies are mostly short-term, related to cutting costs and better utilizing their existing network infrastructure. But as VoIP solutions mature, their long-term potential of integrating voice services into the enterprise data services architecture is revealed. For enterprise environments, this potential results in a transformation of business applications such as corporate email, Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP). For service providers offering VoIP, this capability provides an easy way of offering a broad range of value-added services. VoIP equipment and solutions vendors, well aware of this potential, are pushing service-oriented interfaces into their VoIP systems and working on standardizing these interfaces. These standards and services are the underlying principles behind the Service-Oriented Telephony Architecture (SOTA). This article discusses architectural designs of such solutions, as well as the interfaces and standards behind the solutions.

Figure 1:

An example of an interactive phone book, which works with the telephone system to make calls. This particular application is available with a Cisco Unified Communications Manager (CUCM) PBX.

Architecture

A service architecture for the traditional telephone network is defined around the so-called Intelligent Network (IN). The IN concept separates call control from service execution. As a result, new services can easily be added without making changes to the existing network. Telephony service providers use Service Switching Points (SSPs) and Service Control Points (SCPs) to implement service logic, such as Automated Call Distribution (ACD) and Interactive Voice Response (IVR), which is concentrated in a central location and is under control of the telephony provider. VoIP networks are very similar to Intelligent Networks in that they can also provide an independent service layer, but they are able to extend telephony services more effectively and in a broader way. The key principles and also a modern trend behind this capability are distributed computing and Service-Oriented Architecture (SOA).

SOAs are well established as part of enterprise data services. As telephone networks migrate to the same physical network as that used by data services, telephony services can easily be integrated and even extended, creating a Service-Oriented Telephony Architecture. This evolution of the telephony service layer is now extending toward the edges of the telephone network. Instead of service logic being confined to a central location (SSPs and SCPs), it is now being pushed to the Internet Protocol (IP) PBX. As a side effect, telephones and computers are becoming general-purpose devices, able to provide data as well as voice services, and communicating over a common network.

Instead of limiting service development to closed provider environments, where strong knowledge about the telephone network is required in order to develop additional services, SOTAs require only minimal network knowledge. Thus, developers can focus on their primary work, which is service and application development. As a result, service and application development is much faster and more efficient, and it can be done outside the vendor or provider environment.

Computer Telephony Integration

The central component of the SOTA is an IP PBX, which provides interfaces for communication between telephony and computer systems. Since a telephony system is very complex, these Computer Telephony Integration (CTI) interfaces provide an abstraction model with as few entities as possible. There have been numerous efforts to standardize these interfaces; the Computer-Supported Telephony Applications (CSTA) standard of the European Computer Manufacturers Association (ECMA) is the most widely used standard today. Unfortunately, this standard does not bind vendors to implement all proposed features into their CTI interfaces; therefore, they can choose which features will be available to the developers and which features will be available only to the vendor. As an example, Cisco Unified Communications Manager, which is basically Cisco’s enterprise-level IP PBX, provides extensive call-control functionality through CTI interfaces with the Cisco Java Telephony Application Programming Interface (JTAPI). The underlying abstraction model of this interface is shown in Figure 2.

Apart from CTI interfaces, telephony interfaces can be broken down into four more categories:

standardized network protocols such as the Session Initiation Protocol (SIP) and H.323.

carrier APIs, which are an abstraction layer for standardized network protocols. Parlay/OSA and Java APIs for Integrated Networking (JAIN) serve as the most widely used examples.

vendor proprietary interfaces, which can be used only by vendors.

management APIs.

Generally, three basic groups of such interfaces are now provided by the vendor:

call control interfaces enable observation and interaction with the telephone system and its components, making call-based actions and application call control possible. They provide support for first-party call control (1PCC), which is suitable for server-based solutions that terminate calls, such as IVR or ACD; as well as third-party call control (3PCC), which lets the PBX control the call, but the 3PCC application acts as an active observer of the call and can also control it by communicating with the PBX.

administrative interfaces enable provisioning of the telephone system from third-party applications.

monitoring interfaces provide access to device information, call detail records for billing applications, logs and performance counters.

Figure 2:

An example of a telephone system abstraction model provided by Cisco JTAPI.

Achieving Platform Independence

Many of these interfaces have been around for quite some time now, but most of them have yet not reached platform independence, which is pretty much a requirement in a modern SOA, where platform-independent web services have become the primary interfaces to gain service access. Developers could still tap into SIP itself to provide additional services, but that would mean interfering with telephony networks and would break down the proposed architecture, because services and underlying protocols would no longer be independent. As opposed to proprietary CTI interfaces, web service CTI interfaces provide a service level that is independent from the telephony network. Vendors like Cisco are well aware of this difference, so they are gradually providing a rising number of telephony services on their IP PBXs with the use of web services, and slowly moving away from proprietary interfaces.

Figure 3 shows an example of an enterprise SOTA in a Cisco Unified Communications Manager PBX-based environment. Applications can access the telephone network through the PBX over SOAP/HTTPS. Minimal knowledge about the telephone network itself is required of the application developer.

Figure 3:

Enterprise SOTA based on Cisco Unified Communications Manager PBX.

Service Delivery

Platform independence is not the only benefit of SOTAs using web services. These services can now be discovered, selected and bound across the Internet using these three components:

Web Services Description Language (WSDL): an XML-based language for describing web services and how to access them.

Universal Description, Discovery and Integration (UDDI): a platform-independent framework for describing services, discovering businesses and integrating business services over the Internet.

Simple Object Access Protocol (SOAP): a protocol for exchanging structured information in the implementation of web services, based on XML format.

This approach simplifies service delivery from an ISP to its customers in a cost-efficient manner. Figure 4 illustrates web service discovery. The service provider publishes its service description at one of the directories. The service consumer can learn about this service and how to interact with it by querying the directory server (UDDI). Traditional telephone networks using the Intelligent Network concept have no equivalent mechanism, and their service delivery relies on Signaling System 7 (SS7), which can only be terminated by expensive equipment, which generally confines it to an ISP environment. Web services have no such limitations: a web service written by one service vendor should work across the platforms of multiple service providers and be accessible by customers in a similar manner. Similar trends have already been adopted by modern 3G mobile networks.

In enterprise environments, web services enable a simple integration of voice services into the data service layer, which already conforms to SOA and is based on web services.

Figure 4:

Example of web services discovery and communication.

Security Considerations

One major difference between traditional telephone networks and VoIP networks lies in their security infrastructures. At the physical layer of traditional telephone networks, telephone lines and switching equipment are very hard to tap into, making eavesdropping on a phone call very difficult, although it can be done. Furthermore, legal systems have provided mechanisms to protect phone calls and defined fines for malicious access and disruption of telephone service.

Because SOTAs use an IP network for service discovery and delivery, which is by design a much more open system, gaining access to phone conversations is simple. It only requires “sniffing” all the packets from the network, and all active phone conversations are available to the attacker in a matter of seconds. This capability extends to unprotected web service messages, which can expose SOTAs to malicious activity or denial-of-service (DoS) attacks. Additional security measures such as Internet Protocol Security (IPsec), Transport Layer Security (TLS) and DoS attack protection therefore have to be taken into account when implementing SOTAs.

Conclusion

VoIP-based telephone networks are adopting current trends in distributed computing and Service-Oriented Architectures to build an open and platform-independent service layer. On the enterprise level, this change results in integration of voice services into the organization’s data service infrastructure and a transformation of its business applications. On the ISP level, service logic is being extended toward the edges of the provider’s network, making it easier to deliver new value-added services to customers.

The key benefits of SOTA:

platform independence

integration of VoIP services into the data services architecture

service discovery and delivery over IP networks

application development without extensive knowledge about telephone networks

Equipment vendors are slowly dropping proprietary interfaces and providing an increasing number of web services interfaces to their call controls, conforming to existing SOA standards and driving the creation of new, open standards to support SOTA. This means that the time of SOTAs and a real evolution of the telephony service layer are just beginning.