A Web services based framework for voice over IP

Abstract

Currently, more and more enterprises adopt the voice-over-IP (VoIP) technology to replace their traditional circuit switching infrastructure in order to reduce the cost of their telephony services. The most frequently used VoIP solutions are made up of stand-alone software - usually complex and requiring extra hardware in a local area network. Some VoIP service providers offer Web site based or plug-in based solutions, which are, however, difficult to integrate with other applications by the end user. Web services provide functionality over the Internet using various standards like XML and HTTP, independently of the operating system and programming language. In this paper, we propose a framework for voice-over-IP based on Web services. Service providers using this framework can offer their customers a protocol-neutral Web service interface, thus enabling the deployment of a general and integrated VoIP solution. Because of the simplified logic, a client in this system is easy to implement and can communicate with clients in other systems without additional local hardware for VoIP.

Full text

Page 1

A Web Services Based Framework for Voice over IP
Markus Hillenbrand and Ge Zhang
University of Kaiserslautern
Department of Computer Science
PO Box 3049, 67653 Kaiserslautern, Germany
{hillenbr, gezhang}@informatik.uni-kl.de
http://www.icsy.de
Abstract
Currently, more and more enterprises adopt the Voice
over IP (VoIP) technology to replace their traditional cir-
cuit switching infrastructure in order to reduce the cost of
their telephony services. The most frequently used VoIP so-
lutions are made up of stand-alone software - usually com-
plex and requiring extra hardware in a local area network.
Some VoIP service providers offer Website based or plug-
in based solutions, which are, however, difficult to integrate
with other applications by the end user.
Web services provide functionality over the Internet us-
ing various standards like XML and HTTP, independently
of the operating system and programming language. In this
paper, we propose a framework for Voice over IP based on
Web services. Service providers using this framework can
offer their customers a protocol-neutral Web service inter-
face, thus enabling the deployment of a general and in-
tegrated VoIP solution. Because of the simplified logic, a
client in this system is easy to implement and can commu-
nicate with clients in other systems without additional local
hardware for VoIP.
1. Introduction
Many research and implementation work has been ac-
complished in the area of Voice over IP (VoIP) in the past
years. Compared to the traditional telephony system, the
VoIP technologyprovidesmore sophisticated and enhanced
features including cost reduction for installation and main-
tenance. Currently, two rather distinct types of VoIP solu-
tions exist: stand-alone software stacks (e.g. for H.323 [13,
5]) and Web-based approaches like Mediaring [15]. The
stand-alone software runs on the end user’s computer. It is
responsible for signaling according to one of the existing
protocolsandmediaprocessingsuchasaudiodatacompres-
sion and transmission. Nowadays, there are various com-
munication protocols used in VoIP systems, among which
the ITU-T recommendation H.323 and the Session Initia-
tion Protocol (SIP) [7, 8] from the IETF are well-known
andwell-established.Whilethedataprocessingandthedata
transmission part is the same in these protocols, each of
them has its own signaling functions that are not directly
interoperable.
The stand-alone approach lacks in some way integration
of VoIP functions into other (i.e. not related to VoIP) appli-
cations because of insufficient interfaces to access this soft-
ware. In the worst case, a programmerhas to implement the
VoIP functions completely anew in his own code, although
all these functions are already installed on his computer.
Additionally, extra hardware such as gateway, gatekeeper
or a network server is required in a LAN based H.323 or
SIPsetup.Configurationandadministrationofthehardware
also involve extra work and cost.
Moreover, the stand-alone client software has to be in-
stalledoneveryenduser’scomputerandupdatedeverytime
the software changes, which could for example be induced
byanew versionofthecommunicationprotocol,anew sup-
plementary service, or even a new graphical user interface.
Manual installation and update on each end device there-
fore also result in extra work and cost.
Usually, it is very difficult for customers using stand-
alone solutions from one software vendor to integrate sup-
plementary services from another software vendor. Without
supplementary services such as call forwarding or an ad-
dress book,to whichtoday’s users are accustomedto, it will
beratherimpossibleforVoIPto replacethetraditional– and
time-tested – telephone systems on a larger scale. On the
other hand the second type of VoIP solutions, i.e. the Web-
based approach, provides a thin client solution, which is –
regardingthe update and maintenance issues – more advan-
tageous than the solution with stand-alone software. Never-
theless, using this Web-based approach, a programmer still
cannot easily integrate the VoIP functionality into hers or
his own applications.

Page 2

For future VoIP systems to be successful on a larger
scale, it is very important to have a general framework
which, rather than providing an ”isolated application” like
H.323 or SIP, makes it possible for clients using one system
tocommunicatewithclientsusingadifferentsystem–with-
out any concern about the differences between various pro-
tocols [14, 5]. This is also quite reasonable in a way that the
VoIP service provider could use such a general framework
to providea VoIP solution in which the hardwareconfigura-
tion and installation are taken over by the service provider
itself. This, in turn, means one more cost-reducing factor
for companies planning to use VoIP. It is also preferable for
the VoIP user to be able to flexibly integrate the VoIP func-
tions into his own application. The technology of Web ser-
vices [2] permits loose coupling and simple integration of
software components into applications, irrespective of pro-
gramminglanguagesandoperatingsystems using standards
likeWSDL [1]forservicedescription,SOAP [6]forservice
access, and HTTP [4] as an underlying transport protocol.
Thus, the idea of using Web services to create a sophisti-
cated VoIP framework to overcome the obstacles discussed
in section 2 is very promising [10].
The remainder of this document is as follows. Section 2
discusses in more detail the major problems and its pro-
posed solutions addressed in this paper. Section 3 makes
a comparative digest into related work in this field of inter-
est, while section 4 outlines the architecture and describes
the major components and technologies to solve the prob-
lems stated in section 2. Finally,section 6 gives a briefsum-
mary and concludes with a note on future work.
2. Problem Domain
The integration of Voice over IP (VoIP) solutions into
company networks has not yet been as widely accepted
and adopted as was expected a few years ago. There are
several reasons why VoIP is still lacking deployment on a
larger scale. Four of them will be discussed in this section
in greater detail, as they form the basic incentives for the
work presented.
One is, that due to the nature of the existing VoIP pro-
tocol stacks like H.323 [13, 12, 20] and SIP [7, 8, 20], ad-
ditional hardware and software components have to be in-
tegrated, configured and administered in a company’s local
network. A second reason is the complexity of the mostly
monolithic client software, leading to maintenance and up-
grade cost every time a new feature or service has to be in-
tegrated into a VoIP solution [18]. Third, compared to tra-
ditional telephony systems like ISDN, the support for sup-
plementary services is reduced to a minimum set of most
commonly used services like call transfer, call holding and
the like [11]. A fourth and probably more serious reason is
the lack of compatibility. Products and solutions from one
provider sometimes are not able to communicate with the
solutions from other providers easily. Compared to tradi-
tional telephony systems where every user can easily call
another participant regardless of the underlyingtechnology,
this can be seen as a major disadvantage.One possible solu-
tion to these problems will now be outlined in greater detail
as well as the usage of Web services and its related tech-
nologies.
2.1. Infrastructure and Services
Using a service-oriented architecture instead of a rather
monolithic software solution for Voice over IP reduces the
amount of hardware and software that has to be integrated
into a LAN in order to be VoIP enabled [17]. A service-
oriented architecture (SOA) is basically a set of services
interacting with each other and coordinating some activ-
ity. Service providers and service consumers are the two
main entities acting on behalf of a user. The Web service
technology additionally addresses a standardized descrip-
tion of a service’s functionality using an XML dialect [3].
Using the Web Service Description Language (WSDL), a
service provider describes the functionality (interface) of a
service in a platform, language, and operation system neu-
tral way while a service requestor talks to these services us-
ing SOAP over HTTP (or other transport protocols). Fig-
ure 1 illustrates the usage of Web services for Voice over
IP.
Figure 1. Services for Voice over IP

Page 3

Sourcing out installation and maintenance of VoIP Web-
services to a service provider like other ITservices (Email,
Web presences, etc.) reduces the amount of changes and
hardware installations in local area networks. It is thus nec-
essary to identify logical components of VoIP software and
hardware that are manageable by a service provideror must
remain in the company’s LAN. There might even be ser-
vices that can be managed by both a company or a service
provider. One of these services is for example a service au-
thenticating users (e.g. by their name and password). Such
a service may either be inside a company and integrated
into other local authentication services, or it may be com-
pletelyindependentof the company’suser managementand
thus managed by a service provider.
2.2. Client Software Updates
Client software is used as a user front-end for the VoIP
service and its supplementary services. User interaction,
media processing, and media transportation take place on
the client side and require some kind of software to accom-
plish these tasks. In orderto keep the client software as sim-
ple as possible, all non essential client functionality can be
identified and sourced out to services on the Internet or In-
tranet. This means that service software updates are the re-
sponsibility of the service providers, while the client can
still access these services because of the standardized inter-
faces they offer.
The remaining task is to update the client whenever nec-
essary. A client update might still be necessary because of
changes to the graphical user interface or changes concern-
ing one of the few supplementaryservices that are partly lo-
cated within the client software (see section 2.3).
A client update can be achieved with several techniques.
It is possible to have a user install it, use a semi-automatic
update built into the client code, or a Web based automa-
tism that automatically updates the new components when-
ever the client is re-started. The Java Network Launch Pro-
tocol (JNLP) [19] realizes the latter technique for Java pro-
grams. All resources needed by a Java program (JAR files,
images, etc.) are stored on a Web server. A description file
links those resources together and allows the client soft-
ware (Java Webstart [22]) to analyze what is needed, what
has changed, and what locally exists and is still valid. The
Java Webstart Client then automatically downloads and in-
stall the new components.
A general software deployment service as proposed
in [9] can be used do describe, download, update and in-
stall software components in a service oriented architecture
and provides a seamless integration into the VoIP ser-
vice architecture.
2.3. Supplementary Services
Theintegrationofadditionalsupplementaryservicesinto
existing VoIP protocols like H.323 often results in a new
versionof the protocolwhich must be integratedinto the in-
frastructure as well as into all installed hard- and software
clients [11, 14, 18]. Using a service oriented architecture
as described above, a supplementary service can be repre-
sented by a Web service with a standardizedinterface wher-
ever possible. The supplementary services can be grouped
into three categories: services that must completely be inte-
grated into the client software (like call holding), services
that can be run independently (like an address book), and
services that can be separated but have to be supported by
the VoIP Web service itself (like call forwarding).
It is important to distinguish between those three cate-
goriesin orderto knowwhere the code to access the supple-
mentary services has to be implemented. This can either be
the server, the client, or both. The definition of standardized
interfaces allows for the generalized management and inte-
gration of supplementary services of all three kinds. This
will be addressed in more detail in section 4.
2.4. Compatibility
Compatibility issues regarding the interaction between
signaling protocols of different kinds – or even between the
same protocols from different vendors – is one of the re-
maining challenges in VoIP. From a client’s view, the us-
age of a service oriented architecture and the introduction
of standardized interfaces to a dedicated Web service han-
dling the different signaling protocols instead of a signaling
protocol built directly into the client, the burden of solv-
ing compatibility problems moves from the client’s LAN
administrator to the VoIP service provider. Thus, all clients
can automatically benefit from a solved compatibility prob-
lem as they just communicate with their corresponding
Web service and don’t need an update.
3. Related Work
Some of the topics addressed in section 2 are also part
of other projects and products. The interoperability issues
have been thoroughly investigated by several groups and
projects [20, 21]. Several working groups still work in this
area (IMTC, IETF, ITU-T, etc.). The results of those activ-
ities directly apply to this work and can be seamlessly in-
tegrated into the Web services as they address section 2.3
and 2.4.
Products like net2phone [16] or Mediaring [15] only ad-
dress the problems noted in section 2.2 and cannot be seen
as an open service oriented architecture where supplemen-
tary services can be offered by different service providers.

Page 4

They provide a ”closed” client software containing all the
program code, though they handle the client update prob-
lem in section 2.2 using a plugin or an applet as a client.
The work presented in [5] is a Web services framework
for an audio/video collaboration system. In this framework,
all the components of videoconferencing system are re-
garded as Web service entities, coupled together using an
XML based communication protocol. The work addresses
mainly the bridges between different communication tech-
nologies and thus deals with the problems noted in sec-
tion 2.4 while it factors out the support for supplementary
services.
4. Service Oriented Architecture for VoIP
Thissectiondescribesthedevelopedarchitecturetobuild
the VoIP solution using Web services. It is divided into sev-
eral subsections, each providinga more detailed level of in-
formation.
4.1. Overview
The overall architecture is as show in figure 2. A user
of the scenario is using a Web portal to register at a VoIP
provider and receives some client software (”Venice Sim-
ple Client”), which is being deployed using the Java Net-
work Launch Protocol JNLP in case of a Java client. This
client software is capable of contacting a VoIP Web service
using the stubs generated for the well-defined WSDL inter-
face of the VoIP Web service.
Figure 2. Architectural Overview
As for the client to be as simple as possible (Simple-
Client), all necessary communicationmeans are handled by
the corresponding Web service. Thus, the VoIP Web ser-
vice is responsible for contacting other VoIP Web services
and the integration of H.323 and SIP communication pro-
tocols to be able to communicate with other entities (an-
other SimpleClient, an H.323 telephone or perhaps a SIP
user agent). It is even possible to integrate communication
Webservices for proprietary protocols like Yahoo Messen-
ger or Microsoft NetMeeting (which uses H.323 with addi-
tional features).
4.2. Authentication Service
The service responsible for the authentication of users
is shown in figure 3. The service itself offers a few func-
tions like login(),logout(), refreshLease(),and getLeaseRe-
freshRate().Whenevera user logs intothe service,his client
receives a Lease object to be used for further communica-
tion. A Lease object is basically a universally unique iden-
tifier (UUID) identifying the user. It has to be refreshed at
a given rate to remain valid. If the client software fails for
somereason,and doesnot logout,the whole system will de-
tectaninvalidLeaseandfreeall resourcesrelatedtothecor-
responding user.
Figure 3. Authentication Service
Internally, a LeaseManager object is responsible for the
handling of all leases. It regularly checks for invalid leases
and refreshes them whenever a user calls refreshLease().
A UserManager is responsible for the users and their pass-
words. As the UserManager is designed as an interface, the
actualUserManagerintegratedintotheservicecanhavedif-
ferent persistent representations of the users and their data:
a simple XML file, a database, or even a PluggableAuthen-
tication Module (PAM) or Active Directory module. The
services provider decides which technology to use.

Page 5

4.3. VoIP Service
The main component of the VoIP framework is the VoIP
Web service. It is responsible for the management of all
clients and all calls made by these clients. It therefore of-
fers a set of functionsthat are related to making and manag-
inga call (i.e. signaling).Figure4 illustrates the major com-
ponents inside the service and its functions offered to the
outside world. The service itself is associated with an Au-
thentication Service in order to check the validity of Leases
provided by users that want to access the Web service. The
most important functions this service offers via its interface
are as follows:
• initCall()
preparea call and check the service for enoughfree re-
sources
• makeCall()
actually make a call to another participant
• acceptCall()
accept an incoming call and establish the RTP trans-
mission
• denyCall()
denyto accept an incoming call and free all server side
resources
• getCallInformation()
retrieve all information about a call (like IP addresses,
port numbers, codecs etc.)
• endCall()
gracefullyenda previouslyestablished call and freeall
server side resources
Most of the server-side work is done within the make-
Call() operation of the service. Whenever a client wants to
establish a call, it has to call this operation with the param-
eters needed to identify the recipient and to have the service
establish the call.
The identification is coded into a string representation
and decoded by the service to identify the CallHandler
needed to establish the call. Such an identifying string can
besomethinglike”email://john.doe@domain.com”toiden-
tify the user with his email address, ”id://callee” to iden-
tify the callee using his unique identifier on the server, or
”h323://192.168.30.5” to make an H.323 call to the spec-
ified IP address. Other values are possible and depend on
the service’s capabilities and installed (or enabled)call han-
dlers. The communication with H.323 and SIP clients or
gateways is handled by dedicated Web services performing
a protocol translation (e.g. a makeCall() operation is being
translated into a SIP invite message). In case of SIP, these
servicesact as a SimpleClient onthe oneside andlikea SIP
gateway on the other side of the communicationpipeline. A
detailed description of this protocol translation and its im-
plementation considerations can be found in [23].
Figure 4. Voice over IP Service
Depending on the identification string, the service in-
stantiates a new CallHandler which from now on will be re-
sponsible for the remaining tasks to establish the call. In
case of a local user (i.e. a user also registered at the lo-
cal VoIP Web service), a LocalCallHandler is created and
used to manage the call. If the user is registered at a remote
Web service, a RemoteCallHandler will be used. The cor-
rect remote Web service is detected using a registry for all
VoIP services, and the handleracts as anotherSimple Client
to this remote service, representingthe client that originally
wants to make the call. In this case, a software bridge be-
tween two Web services (WSBridge in figure 4) is used to
forward all commands to the remote Web service – such
a bridge is created only once for every Web service and
speeds up the communication between the services.
Everything associated with the current call will be for-
warded to and processed by the call handler in charge – a
call handler thus represents the ”state” of a call. The call
handler will be destroyed when the call ends or is inter-
rupted. This frees all server resources allocated for the call.
4.4. Metering and Accounting
The VoIP Web service framework supports a user ori-
ented and event driven metering and accounting architec-
ture [24] (as shown in figure 5). Here, metering is the pro-
cess of collecting all kinds of events that occur in a sys-
tem and might be accounted. Accounting is the process of
grouping those events so that they can be billed.
All events that have to be accounted are collected by
a Metering Service which stores them persistently in a

Page 6

database management system. The service is associated
with an Authentication Service in order to match an event
to a user.
Figure 5. Metering and Accounting Services
An Accounting Service frequently retrieves all metered
events from the Metering Service and cumulates them for
billing – by summing up calculated prices for event se-
quences. For example, the metering events ”call estab-
lished” and ”call ended” (each at a given time) define a call
length while the type of call handler used may define the
price per time unit (a local call is cheaper than a remote call
etc.). The service is directly related to the service provider’s
business model for his VoIP business.
4.5. Supplementary Services
Theautomaticintegrationofsupplementaryservicesinto
the Simple Client is an important part of a VoIP solution to
be successful – this has already been discussed in section 3.
Figure 6. Supplementary Services
Figure 6 now shows the communication between the en-
tities necessary to actually realize a supplementary service.
The client knows about the supplementary services it wants
to use. They are either built-in (like call hold) or exter-
nal (like call forward or an address book). External supple-
mentary services can be found using a broker or the VoIP
Web service itself, but this finally results in a WSDL file
the client receives in order to locate and access the service.
The supplementary service then tells the client where to in-
tegrate it into the graphical user interface, so that the user
canaccessit.Whentheusercallsanoperationofthesupple-
mentaryservice, the latter talks to the VoIP Web service and
calls some of the well-defined (i.e. described in the WSDL
file) operations on behalf of the user.
In order to support such a supplementary service, both
the client and the Web service must agree on its operations.
This is achieved by well-defined interfaces which a supple-
mentary service actually implements.
5. Prototype
Most of the components presented in the previous sec-
tion have already been realized and put into operation. The
prototype has been implemented using the Java program-
ming language and the Java Web Services Development
Pack for the creation of and access to Web services. The
client is based upon the Java Media Framework and uses
the integrated RTP protocol to establish an audio connec-
tion between two clients.
The update of the client code is managed using Java
Webstart [22] – every time the client is re-started, it checks
for updates and installs them if necessary. The client can be
configured to access different VoIP Web services as its ser-
vice provider, so that it is easily possible to create several
VoIP domains with a different range of supplementary ser-
vices.
The first (subjective) test results are very promising. The
management of the clients and calls using a Web service is
– with exception to the first initial contact to the Web ser-
vice – fast andreliable. As the prototypeis still underdevel-
opment, an objective measurement of processing time and
delay has not yet been made. The deployment of new ser-
vices and client updates are very easy to accomplish due to
the modular configuration of the service oriented architec-
ture.
There are several performance issues though. The Java
Media Framework and its audio processing capabilities are
not satisfying when both client sides are running a Linux
operating system. With one client (or even better two) run-
ning under Windows, the audio processing is fast and with
a neglectable delay during a call. Here, the Java Media
Framework uses DirectSound to access the sound device
whilethereis currentlynosuchalternativeunderLinux.But
as the emphasis of the project is call signaling using a ser-
vice oriented architecture and the mediation of supplemen-
tary services, this lack of performance is still acceptable.
6. Conclusion and Future Work
In this paper we have presented a service oriented ar-
chitecture for Voice over IP – realized using Web services

Page 7

technology.The major services and their functionality have
been discussed. An Authentication Service is responsible
to identify users in the framework, while the VoIP Service
manages all user calls to local and remote participants. A
Metering Service collects events and a corresponding Ac-
counting Service retrieves these events frequently and cre-
ates a bill to be paid by the user that caused the events.
Known supplementary services like call hold or an ad-
dress book have been divided into three categories, each of
them has to be integrated into the framework differently.
The major work remaining is to define interfaces so that all
participatingservices and clients can access and understand
the operations of a supplementary service. With the proto-
type running smoothly and efficiently, the major work re-
maining is to identify several supplementary services and
define their interface. It is also of great interest to develop
some important supplementary services like call forward-
ing that prove the advantage of the service oriented archi-
tecture and can be used across all three client worlds: the
Simple Client, H.323 and SIP.
As the service oriented framework adds a new layer into
currently established VoIP protocols, it is also necessary to
make some objective measuring for the resulting additional
overhead in H.323 and SIP signaling. Finally, the next step
in client development will be to generate a .NET client that
iscompatible(i.e.caninteract)withtheJavaclientcurrently
available.Afirstprototypeofa.NETclientworks,butitstill
lacks interoperability with the Java audio codecs (only one
codec is working). The problem here is, that there are no
native .NET classes for RTP and audio processing, so that
a COM+ component has to be wrapped and integrated into
.NET.
References
[1] E. Christensen, F. Curbera, G. Meredith, and S. Weer-
awarana. Web Services Description Language (WSDL) 1.1,
2001. http://www.w3.org/TR/wsdl.
[2] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and
S. Weerawarana. Unraveling the Web Services Web: An In-
troduction to SOAP, WSDL,and UDDI. IEEE Internet Com-
puting, March/April 2002:86–93, 4 2002.
[3] D. Fallside.XML Schema Part 0: Primer, 2001.
http://www.w3c.org/TR/xmlschema-0.
[4] R. Fielding. Hypertext Transfer Protocol – HTTP/1.1, 1999.
http://www.w3c.org/Protocols/rfc2616/rfc2616.txt.
[5] G. Fox, W. Wu, A. Uyar, H. Bulut, and S. Pallickara. A Web
Services Framework for Collaboration and Videoconferenc-
ing. In Proceedings of the 4th International Conference on
Internet Computing 2003, Las Vegas, USA), 6 2003.
[6] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, and
H. F. Nielsen. SOAP Version 1.2 Part 1: Messaging Frame-
work, 2003. http://www.w3.org/TR/soap12-part1.
[7] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg.
RFC 2543 - SIP: Session initiation protocol, 3 1999.
[8] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg.
RFC 3261 - SIP: Session initiation protocol, 4 2002.
[9] M. Hillenbrand, P. M¨ uller, and K. Mihaijloski. A Software
Deployment Service for Autonomous Computing Environ-
ments. In Proceedings of IAWTIC 2004 (Gold Coast, Aus-
tralia), 7 2004.
[10] M. Hillenbrand, P. M¨ uller, and H. M¨ uller. Voice over IP
als Web Service. In Proceedings of 18. DFN Arbeitstagung
(D¨ usseldorf, Germany), 6 2004.
[11] ITU. Recommendationx
mentary Services
http://www.itu.int/rec/recommendation.asp?type=products
&lang=e&parent=T-REC-H.
[12] ITU.Recommendation
ulussignalingprocedures
http://www.itu.int/rec/recommendation.asp?type=folders
&lang=e&parent=T-REC-H.323.
[13] ITU.Recommendation
multimediacommunications
http://www.itu.int/rec/recommendation.asp?type=folders
&lang=e&parent=T-REC-H.323.
[14] W.Jiang, J. Lennox, S.Narayanan, H. Schulzrinne, K.Singh,
and X. Wu. Integrating Internet Telephony Services. IEEE
Internet Computing, pages 64–72, 6 2002.
[15] MediaRing.Mediaring
http://www.mediaring.com.
[16] Net2Phone.
http://www.net2phone.com.
[17] S. Rixner, W. J. Dally, U. J. Kapasi, B. Khailany, A. Lpez-
Lagunas, P. R. Mattson, and J. D. Owens. A bandwidth-
effi cient architecturefor media processing. InProceedings of
the 31st annual ACM/IEEE international symposium on Mi-
croarchitecture, Dallas, USA. IEEEComputer Society Press,
1998.
[18] J. Rosenberg, J. Lennox, and H. Schulzrinne. Programming
Internet Telephony Services. IEEE Network, 13(3):42–49, 6
1999.
[19] R.Schmidt.Java
tocol (JNLP) Specifi cation
http://java.sun.com/products/javawebstart/download-
spec.html.
[20] H. Schulzrinne and J. Rosenberg. A Comparison of SIP and
H.323 for Internet Telephony. In Proceedings of Network
and Operating System Support for Digital Audio and Video
NOSSDAV (Cambridge, England), 7 1998.
[21] K. Singh and H. Schulzrinne.
SIP/SDP and H.323. In Proceedings of the 1st IP-Telephony
Workshop IPTel, 4 2000.
[22] Sun. Java Webstart Technology, 2003. http://java.sun.com/
products/javawebstart.
[23] G. Zhang and M. Hillenbrand. Implementing SIP and H.323
Signaling as Web Services. In Proceedings of the 30th Eu-
romico Conference 2004 (Rennes, France), 8,9 2004.
[24] G. Zhang, B. Reuther, and P. M¨ uller. User Oriented IP Ac-
counting in Multi-user Systems. In Proceedings of the 8th
IFIP/IEEE International Symposium on Integrated Network
Management (Colorado Springs, USA), 3 2003.
H.450.x:
H.323,
Supple-
for1998–2001.
H.323
for
Annex
H.323,
L:
7
Stim-
2003.
H.323:
systems,
Packet-based
72003.
PCPhone,2004.
Net2Phone,1996-2004.
NetworkLaunching
1.0.1,
Pro-
2001.
Interworking Between