Framework for a Highly Extensible IP Telephony System

IP telephony or Internet telephony had been used by a lot of Internet users as well as organizations and companies as a cost effective telecommunication tool. As the usage of IP telephony become wider, its role had been expanded into more than merely a communication device. Some IP phone software also provide additional services like email, file transfer, whiteboard, etc. IP phone users will value these extra services and choose the one that fulfill their needs. As a result, the IP telephony service operators and IP phone developers have to keep revising and rebuilding their program with new and exciting services. This process is undoubtedly very time consuming and costly.

This article introduces a framework to develop a highly extensible IP telephony system. A great effort had been put to carefully design each module in the system to ensure its reusability and extensibility. The key components in this system are: (1) a general phone engine specification that can be implemented using any proprietary telephony API, (2) a communication interface module that performs client/server communication in a predefined XML message, (3) service plug-in and service provider manager that allows new services to be added into the system easily. By following this framework, we will be able to develop an IP telephony system, which allows rapid development of new services into the system with the minimum amount of time.

Introduction

The basic concept of IP telephony is the transmission of voice data across the IP network. IP based network is packet-switched, thus it does not have to maintain a dedicated connection throughout the duration of each session, as in the case of most circuit-switched network used to connect most of traditional phones around the world. IP network minimizes the time that a connection is maintained between two systems, which reduces the load on the network. The prime advantage of this is cost saving, which is also the main reason that brought IP telephony under the spotlight of telecommunication world. According to a study done by Sage Research on the year 2000, more than one half of large enterprise organizations have or will deploy IP telephony in the next 12 months and nearly half of small and medium organizations will do the same. [1]

Providing IP telephony services is only one small part of our system. The main idea of our system is to develop various services around the IP phone. This will allows it to be more than just a communication device. These services are highly extensible. New services can be developed and added into the system at anytime, without having to rebuild and redeploy the whole system. This is what makes our system unique from the rest that are currently on the market.

Architecture

There are two main functional components that are responsible for running the entire system, the IP Phone Client (IPC), and the Telephony Services Server (TSS). There are other modules that aid these two components to carry out the entire system functionalities. Figure 1 depicts the overall system architecture and the relationships between different modules in the system.

Figure 1: Overall system architecture.

The following are some brief descriptions about each module in the system.

Phone Engine – This module is responsible for handling all the call operations. It abstracts the low level call handling process like call signaling and media controlling into a series of high level programming interfaces, which are more straightforward and easier to use.
Communication Interface – This module is responsible for handling the communication between IPC and TSS. The messages sent between them are in XML. This module simplifies the complicated XML parsing and network programming into a set of message sending and receiving methods, which looks more intuitive in terms of usability.
Service Plug-in Manager – This module manages Service Plug-ins on IPC. A service plug-in is a standalone functional unit that provides certain feature or service on IPC. This module will scan for the new service plug-ins and load them into the system.
Service Provider Manager – This module is fairly similar to the Service Plug-in Manager. It manages Service Providers on TSS, which each of them provides server side functionality to its corresponding service plug-in on IPC. The module is able to load any newly added service providers and execute them automatically upon startup.

Phone Engine Specifications

The Phone Engine is actually a generic specification to abstract the complexity of various call operations like making and receiving calls, conducting call conference, call signaling and media control, etc. The specification is very general and does not tie to any specific technology. The phone engine specification can be implemented freely using any proprietary telephony API like: Microsoft TAPI, Java Telephony, and Vovida VOCAL. Thus, this specification allows the developer to pick the telephony technology of their choice depends on the target operating platform, and yet still able to use with the rest of the modules in the system. This increases the flexibility of the whole system in terms of portability. Figure 2 is a class diagram illustrating the phone engine design.

There are several rules need to be followed by any implementer of this phone engine specification.

All calls and conferences must be initiated by the PhoneEngine class.
After a call has been made, or a conference has been started, the following process needs to be delegated to the Call and Conference class respectively.
Call and Conference class contains more specific methods to manipulate a call and conference. These methods must be implemented correctly according to their definitions.
Upon receiving external events, for instance incoming calls, PhoneEngine will first intercept the event, and process it according to the nature of the event, i.e. an incoming call event will instantiate Call class and transfer the process to it.

Communication Interface Module

The Communication Interface Module is used for the intercommunication between IPC and TSS over a TCP/IP network. The main objective of this module is to hide the complicated network programming details. Figure 3 shows the classes in the communication interface module.

Connection is an abstract class that represents a network connection. The connection can be a client connection, represented by the ClientConnection class, which will initiate a connection to a designated host. On the other hand, ServerConnection is accepted connection on the server. In contrast with ClientConnection, ServerConnection does not require to specify a host as the connection is already initiated by the client.

As mentioned earlier, the messages sent between IPC and TSS are in XML that follows a predefined schema (see Figure 4). The advantage of using XML here is platform independence. We know that XML is a plain text file that can be understood by any program regardless of its operating platform, provided it has an XML parser, and understand the XML schema. Message class is used to construct these messages, and transform them into XML form prior it was sent across the network. It can also parse a raw XML message from the network stream, and convert it back to its corresponding Message object. A Message can have various message attributes that are relevant to its message type. SimpleMessage is a simplified version of Message, which only can has name-value pairs its message attribute.

Service Plug-in and Service Provider Manager

The main objective of having Service Plug-in and Service Provider is to allow new services added to the system easily. This apparently is the most significant module to create a highly extensible IP telephony system. Each service plug-in is executed by the IPC to provide its own unique service to the end user. Some services however, require extra processing from TSS. Thus in this case, a specific service provider must exist on the server to handle all the requests from its corresponding service plug-in. Nevertheless, there are service plug-ins which do not required server side processing and can run by itself on the IPC. Likewise, there are also some service providers that only provide additional server functionality, thus they only exists on the TSS. Figure 5 will give you a better picture of the service plug-ins and service providers’ relationship.

Figure 2: Relationship between service plug-ins and service providers.

Both Service Plug-in and Service Provider can be generalized as plug-ins. A plug-in is actually a compiled class file that conforms to the plug-in specification. The technique that is used to load the plug-in file dynamically is called Reflection. Reflection is a technique to load a compiled class file, and retrieve the metadata related to the classes programmatically [2]. These metadata contains the validity information of class file, class name, base class name, attributes and methods inside the class, etc. The process of loading the plug-in files can be seen as follows:

Scan the plug-in directory for files with the plug-in file extension, e.g. files with extension .plugin.
Load each of the file found in step 1 via reflection.
Check whether it is a valid plug-in class by verifying the class inherits (or implements) the plug-in specification base class.
If both step 3 and step 4 passed, then instantiate the plug-in class and keep it in the plug-in manager.
If either step 3 or step 4 failed, then we proceed back to step 2, with the subsequent file found.

You might be wondering how each plug-in is actually being executed by the system? As mentioned earlier, all plug-ins need to conform to a plug-in specification. This specification contains some methods, which by default are empty methods. The plug-in developers are responsible to implement these methods to provide its own functionality dependent to the service it provides.

Listing the complete plug-in specification here is beyond the scope of this article. In the following section, we will show you how each plug-in is being executed by the system.

Figure 3: Interaction between Service Plug-in and IPC.

Figure 6 illustrates the interaction between IPC and various sets of methods defined in the Service Plug-in specifications.

Plug-in Operation Methods are used for constructing, starting, stopping and destroying the plug-in. Plug-in developers will typically write the plug-in initialization and cleanup code here.
User Interface Processing Methods will be called if there is any user interface events take place at the IPC front end. Plug-in developers have to implement these methods to handle the events, and return feedback to the user.
Plug-in Helper Methods serve as a bridge between the plug-in and other modules in the system. These methods are used heavily by the plug-in developers to access the core functionalities in the system, like Phone Engine, and Communication Interface module.

The way a Service Provider is being executed by TSS is somewhat similar to the execution of Service Plug-in by IPC. The only difference is lack of User Interface Processing methods in the Service Provider specifications. This is very obvious as a service provider does not have a user interface. It instead has Service Request handlers to handle requests from the service plug-in. The service provider developers need to write the codes for handling every request from the service plug-in, and send a response back to it.

Figure 4: Interaction between Service Provider and TSS.

Conclusion and Future Work

This article had discussed thoroughly about a framework for developing an IP Telephony System that is highly extensible. It creates a new horizon for IP telephony operators and developers. It had shortened the development time to develop new services into the system, and also save the cost of deploying these new services to reach the end users. Once the new services are added to TSS, it will automatically update the IPC when it is connected to TSS. This system enables IP telephony operators to better cope with the demand of their customers from time to time.

Nevertheless, there are some enhancements can be done into this framework to further improve the system. The following will be considered as a future work to improve this system to the next level.

Enhance the security in the Communication Interface Module to ensure more secure communication between IPC and TSS.
Create a web interface module to allow the services accessible to the web users.
Allow the services to be exposed as XML web services so that it can be consumed by third party website and expand our user network.
Extend the plug-in specification to increase the flexibility of plug-in development.

Reference

VoIP / IP Telephony Statistics, CMD Media, http://www.commweb.com/article/COM20021015 S0002, October 2002.
Programming C#, O’Reilly & Associates, July 2001.
C. Sells, Windows Telephony Programming, Addison-Wesley Pub Co., June 1999.
“Java Telephony API Version 1.3″, Java Documentations, Sun Microsystems, http://java.sun.com/products/jtapi/
“An Introduction to JTAPI (Java Telephony API)”, Enterprise Computer Telephony Forum, http://java.sun.com/products/jtapi/jta pi-1.2/JTAPIWhitePaper_0_7.html