VOIPINTEGRATION

VoIP Control and Processing System

F. J. Serrano, G. G. Talav

an, B. Curto, V. Moreno, J. F. Rodr

ıguez Arag

on and A. Moreno

Faculty of Sciences, University of Salamanca, Salamanca, Spain

Keywords:

Technology integration, VoIP, Telephony.

Abstract:

Analog telephone networks, are gradually giving way in favor of new Internet-based communication systems

(VoIP). However, the diversity and heterogeneity of systems and suppliers prevent users from communicate

with their contacts on an uniform and simple way. In this paper a new VoIP multiprotocol and multidevice

system, extensible by plugins, is presented. Heterogeneous character has lead us to the need of considering

several different communications mechanisms at present. The usage of common devices for telephone com-

munications has also been considered. A complete system has been developed in order to integrate all possible

components of a VoIP system.

1 INTRODUCTION

Analog telephone networks, are gradually giving way

in favor of new Internet-based technologies. There are

more and more protocols like SIP (Rosenberg et al.,

2002) or IAX (Spencer et al., 2009) and systems that

use the Internet as communication channel and pos-

sible replacement for the analog telephone network.

Skype (Skype, 2009) with its own protocol seems to

have a dominant position in this area, although many

providers already offer free calls from computer to

computer, or cheap calls to landlines and mobiles

phones mainly using the SIP protocol.

One of the main barriers preventing the prolifera-

tion of these new technologies is just the diversity and

heterogeneity of systems and suppliers. If end users

want to take full advantage of these technologies, dif-

ﬁculties arise like the installation of different clients,

learning their particularities, the lack of organization,

and so on. Although these clients are very easy to use,

just the simple need to interact with a computer may

lead some users to prefer to keep using their landline

phones as usual.

Up to date, Asterisk (Asterisk, 2009) was the

only system that integrates several VoIP technologies.

However, Asterisk is server-oriented, i.e. it’s not ori-

ented to ﬁnal users. A platform bringing together the

different technologies and allowing users to access

them in a uniform way and, if possible, be adapted to

the habits acquired over the years by telephony users

Figure 1: Proposed system.

becomes necessary. The development of an integra-

tion platform is viable since speciﬁcations of VoIP

protocols and clients are well deﬁned, and also those

of the subscriber loop and analog phones. The work

in this paper involves the development of a plugin

195

Serrano F., TalavÃ ˛an G., Curto B., Moreno V., RodrÃ guez AragÃ¸sn J. and Moreno A.

VOIPINTEGRATION - VoIP Control and Processing System.

DOI: 10.5220/0002809301950198

In Proceedings of the 6th International Conference on Web Information Systems and Technology (WEBIST 2010), page

ISBN: 978-989-674-025-2

Figure 2: VoIPIntegration architecture.

based communication platform (VoIPIntegration) that

is expected to facilitate access by a large number of

users to VoIP technologies, to allow users to access

all services in the same way that they access the con-

ventional analog phone, and to provide advanced fea-

tures for more experienced users. Below, we will ex-

plain this communication platform we have designed

an implemented, we will show how new plugins are

integrated in the system to provide compatibility with

telephone devices and VoIP protocols, and ﬁnally we

will describe the already developed plugins.

2 PROPOSED SYSTEM

The system kernel is a application called VoIPInte-

gration that must be installed on the user’s computer.

This application lets integrate different telephone de-

vices like hardware and software telephones, coordi-

nate them and easily access IP telephony using popu-

lar clients or most relevant protocols (ﬁg. 1).

Platform design is plugin based. On one side, plu-

gins for connection with VoIP clients, like Skype or

SIP protocol, are found. These plugins allow every

telephone devices connected to the system to access

the Internet and to contact other clients using their

respective protocols. On the other side, plugins for

connection with local telephones (software and ana-

log telephones) are found. To achieve integration with

analog phones, we have used the USB port and a hard-

ware adapter that we have designed and developed.

3 VOIPINTEGRATION

ARCHITECTURE

The platform kernel (ﬁg. 2) performs the typical func-

tions of a private branch exchange (PBX) and an ad-

dress book. It establishes connections between tele-

phone devices and VoIP clients with device occupa-

tion management and conﬁgurable relationships be-

tween VoIP accounts and telephone devices, so that

calls are received by different phones depending on

their origin account. This becomes even more use-

ful by allowing users to maintain multiple active calls

simultaneously. As shown in ﬁgure 2 one of the soft-

ware components works as a switchboard. This PBX

connects telephone devices installed in the system

among themselves or with VoIP clients through plu-

gins. Access to each plugin is done through proxies.

Each proxy accesses a plugin through a well-known

interface and using a speciﬁc protocol. Proxies are

responsible for getting the required information from

the plugins, storing their state and providing as much

functionality as possible in order to make the imple-

mentation of plugins as simple as possible.

Speciﬁcally, a phone plugin proxy stores the

phone status (on-hook, off-hook, dialing, ringing,

talking), the name of the audio input/output devices

that the phone uses, the default VoIP account used by

the phone (although any account integrated in the sys-

tem may be used), and the establishment of calls by

the three available dialing modes (normal, letters and

T9). Several instances of a same telephone plugin can

coexist.

VoIP client proxies link the PBX with client plu-

gins. These plugins can’t have several instances, but

they can access several accounts so that each one is

seen by the PBX as a different communication chan-

nel.

4 VOIPINTEGRATION API

VoIPIntegration has its own API that speciﬁes how

different plugins must connect and communicate with

the system. This API is based on a generic inter-

face for each plugin type (telephone or VoIP client)

and on the format of the text messages exchanged be-

tween the application and different plugins. This API

also allows extending and supporting new protocols

and new phone devices. For this, plugins must fulﬁll

certain requirements and respect the VoIP integration

communication protocol. Plugins are not able to start

a communication by themselves, but they must wait a

VoIPIntegration request. With this plugin design, it’s

not necessary to use any library, call any function or

WEBIST 2010 - 6th International Conference on Web Information Systems and Technologies

196

Figure 3: Phone plugins integration.

know anything about VoIPIntegration. This implies a

low coupling design.

4.1 Phone Plugins

Communication between VoIPIntegration and phone

plugins (ﬁg. 3) is performed by an interface

(PhonePluginInterface) and using an speciﬁc proto-

col (Phone Protocol) that we have deﬁned. Basic ser-

vices must be provided by the plugin implementing

the interface. Communication protocol messages are

used for notiﬁcations, for advanced features and for

adding new functionality in the future keeping back-

wards compatibility.

Basic services that the plugin must provide are: to

communicate with the user in order to let him know

about the reception of calls and to provide him some

kind of interface so the user can also make calls; to

know at every moment the status of the phone (on-

hook, off-hook) and to associate with an input and an

output audio device of the system.

Protocol between VoIPIntegration and a phone

plugin (Phone Protocol) allows bidirectional commu-

nications between them by a plain text messages ex-

change. Message structure contains a command ﬁeld

and some attributes. Plugins send requests to VoIP-

Integration using the return value of an PhonePlug-

inInterface function (getEvent). This function will

be called continuously by VoIPIntegration. To avoid

busy waiting, plugins must internally block this func-

tion until they need to send any request. If a plu-

gin doesn’t fulﬁll this requirement, or send incorrect

messages, VoIPIntegration would deactivate it. VoIP-

Integration responds all the request made by plugins

calling another PhonePluginInterface function (even-

tResponse). Response may be the ”OK” string or

the ”ERROR” string followed by a textual descrip-

tion of the error that happened. Several commands

can be sent by means of a numeric sequence to pro-

vide advanced functionalities of VoIPIntegration (ad-

dress book, dialing methods, voice synthesis, etc.) in

phone devices without graphical interface. VoIPInte-

gration can also send orders and notiﬁcations to the

phone plugins through PhonePluginInterface.

Extra features from the plugins are allowed

by combining the ”ACTION” command from the

Phone Protocol with the getActions function from the

PhonePluginInterface interface. Plugins must send to

VoIPIntegration the name of additional features that

they provide using the return value of the getActions

function. These names are included in the VoIPIn-

tegration graphical interface and when a user selects

any of them, an ”ACTION” command is sent to the

corresponding plugin with the name of the special ac-

tion that must be performed.

Already existing methods are used to extend the

protocol with new commands. Thus, plugins com-

patibility with new versions of VoIPIntegration are

ensured. New requests between VoIPIntegration and

plugins will be performed in the common way.

4.2 VoIP Client Plugins

Communication between VoIPIntegration and VoIP

plugins is performed through an interface (VoIP-

ClientPluginInterface) and with a speciﬁc protocol

(ﬁg. 4) in a similar way as phone plugins described in

the above section. VoIP client plugins must provide

access to at least one IP telephone account that al-

lows starting calls, receiving them and hanging them

up. Plugins must also play and extract audio from de-

vices indicated by VoIPIntegration. For this, an audio

library is provided with the application. Communica-

tion between VoIPIntegration and VoIP client plugins

is bidirectional and uses the same mechanisms as tele-

phone plugins (getEvent, eventResponse, getActions,

etc.) although the exchanged messages are different.

5 DEVELOPED PLUGINS

VoIPIntegration provides a GUI in order to manage

and control the plugins and the address book. It also

provides a library to manage the audio devices of the

system that allows recording, playing and synthesiz-

ing voice from text. VoIPIntegration includes a plugin

discovery system that allows automatically recogniz-

VOIPINTEGRATION - VoIP Control and Processing System

197

Figure 4: VoIP clients integration.

ing them. For implementing it, Java facilitates that

work as it allows us to pack plugins into a jar ﬁles with

information about them in the manifest.mf ﬁle. We

will now describe the VoIP clients and telephones de-

veloped plugins (Skype, SIP, software telephone and

USB telephone).

Skype plugin allows sending and receiving calls

through it, sending DTMF tones and additionally im-

porting Skype address book. Skype must be installed

in the system and logged in for the plugin to work.

SIP protocol plugin uses open source library

MjSIP (Veltri, 2005) in order to send and receive

calls. It lets VoIPIntegration the use of several IP tele-

phone accounts with any provider using this protocol.

All SIP accounts are managed concurrently, so that

several incoming and outgoing call can coexist simul-

taneously through different accounts.

Software telephone plugin implements a virtual

telephone with a friendly graphical interface for VoIP-

Integration that uses all the API functionality.

USB adapter plugin allows VoIPIntegration to ac-

cess to the analog telephone adapter that has been

built. Plugin can connect to the phone, retrieve its sta-

tus, send and receive DTMF tones, send and receive

ringtones and send caller ID information. It allows

any analog phone connected to the adapter to send and

receive calls using any of the VoIP clients integrated

in VoIPIntegration. The developed USB adapter ful-

ﬁll the USB Audio Class and the USB HID Class stan-

dards. Therefore, the prototype doesn’t need speciﬁc

drivers for Windows and Linux, but generic drivers

provided by the operating system that are automati-

cally loaded.

6 CONCLUSIONS

A voice communication system in order to work in

an heterogeneous VoIP environment has been devel-

oped. Main VoIP systems and classic telephone de-

vices have been considered in their speciﬁcations.

System design has been made in a way that, in the

future, new services of this technological scope can

be incorporated. For this, we have designed a soft-

ware that can handle plugins. Different plugins for

the most popular technologies like Skype client or SIP

protocol have been developed in order to validate the

proposed design.

From the users point of view, different interfaces

are also supported in our plugin-based proposal. So, a

software telephone and its corresponding plugin have

been developed. An USB adapter, which allows in-

teraction between the system and analog phones, has

been developed and built in order to achieve a greater

usability. It’s been necessary to design and develop

a complete hardware system with its corresponding

embedded real-time control software. The prototype

has been tested with different analog telephones and

satisfactory results have been obtained.

This proposal allows accessing different VoIP

technologies in a simple way at low cost. So, users

may integrate their telephone systems with current

VoIP systems performing a small investment using

our proposed architecture.

ACKNOWLEDGEMENTS

This work has in part been ﬁnanced by Junta de

Castilla y Le

on (Project SA030A-07) and Span-

ish Ministry of Science and Innovation (DPI2007-

62267). The main author has also worked under the

support of an University of Salamanca fellowship.

REFERENCES

Asterisk (2009). Asterisk reference information version

1.6.1.6. Asterisk.org.

Rosenberg, J. et al. (2002). Sip: Session initiation protocol

(rfc3261). Network Working Group.

Skype (2009). Skype public api 4.1 reference guide. In

Skype API reference. Skype.

Spencer, M. et al. (2009). Iax: Inter-asterisk exchange ver-

sion 2 (rfc5456). Network Working Group.

Veltri, L. (2005). Mjsip version: 1.5. In MjSip-Mini-

Tutorial. MjSIP.

WEBIST 2010 - 6th International Conference on Web Information Systems and Technologies

198