Project P909-GI
Enabling Technologies for IN Evolution and INInternet Integration
Deliverable 2
Architecture and Service Scenarios for Internet-IN convergence
Annex 4: Early Product Evaluations
For full publication
March 2000
EURESCOM PARTICIPANTS in Project P909-GI are:

Telecom Italia S.p.a.

Deutsche Telekom AG

France Télécom

Telenor AS

Koninklijke KPN N.V.

eircom plc

Portugal Telecom S.A.

Telefónica S.A.
This document contains material which is the copyright of certain EURESCOM
PARTICIPANTS, and may not be reproduced or copied without permission.
All PARTICIPANTS have agreed to full publication of this document.
The commercial use of any information contained in this document may require a
license from the proprietor of that information.
Neither the PARTICIPANTS nor EURESCOM warrant that the information
contained in the report is capable of use, or that use of the information is free from
risk, and accept no liability for loss or damage suffered by any person using this
information.
This document has been approved by EURESCOM Board of Governors for
distribution to all EURESCOM Shareholders.
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
Table of Contents
Table of Contents............................................................................................................ i
1
Introduction ............................................................................................................ 1
2
France Telecom Product Evaluations .................................................................... 2
2.1 Microsoft Netmeeting 3.01 .......................................................................... 2
2.1.1 Description of the product .............................................................. 2
2.1.2 Tests description and results ........................................................... 4
2.2 Radvision Gatekeeper development kit ....................................................... 5
2.2.1 Description of the product .............................................................. 5
2.2.2 Functionality (related to the reference architecture) ...................... 7
2.2.3 Test description ............................................................................... 7
2.2.4 Test results ...................................................................................... 8
2.3 Dialogic Boards ......................................................................................... 11
2.3.1 Product description ....................................................................... 12
2.3.2 Test description ............................................................................. 12
2.3.3 Test result...................................................................................... 12
2.4 Apache Web Server ................................................................................... 12
2.4.1 Product description ....................................................................... 12
2.4.2 Test description and result ............................................................ 13
2.5 DPE environment ....................................................................................... 13
2.5.1 IONA Orbix .................................................................................. 13
2.5.2 Imprise Visibroker ........................................................................ 14
2.5.3 Test and Result ............................................................................. 16
3
CSELT Product Evaluations ................................................................................ 17
3.1 Lucent IST-SP............................................................................................ 17
3.1.1 Description of the product ............................................................ 17
3.1.2 Functionality (related to the reference architecture) .................... 19
3.1.3 Tests description ........................................................................... 20
3.1.4 Results/Tests Evaluations ............................................................. 22
3.2 Stratus XA/R and SINAP .......................................................................... 23
3.2.1 Description of the products ........................................................... 23
3.2.2 Functionality ................................................................................. 23
3.2.3 Tests description ........................................................................... 23
3.2.4 Results/Evaluations ....................................................................... 24
3.3 Slapd .......................................................................................................... 25
3.3.1 Description of the product ............................................................ 25
3.3.2 Functionality ................................................................................. 25
3.3.3 Tests description ........................................................................... 26
3.3.4 Results/Evaluations ....................................................................... 27
3.4 Dynamicsoft jSIP ....................................................................................... 27
3.4.1 Description of the product ............................................................ 27
3.4.2 Functionality ................................................................................. 27
3.4.3 Tests description ........................................................................... 28
3.4.4 Results/Evaluations ....................................................................... 29
4
KPN Product Evaluations .................................................................................... 30
4.1 Genesys Nirvana ........................................................................................ 30
4.1.1 Product description ....................................................................... 30
© 2000 EURESCOM Participants in Project P909-GI
page i (iii)
Deliverable 2
Annex 4: Early Product Evaluations
4.1.2 Nirvana Experiment Description ................................................... 36
4.1.3 Nirvana Conclusions ..................................................................... 38
4.2 Introduction – Java IDE evaluations .......................................................... 39
4.2.1 JavaBeans ...................................................................................... 39
4.2.2 Requirements for a JAIN SCE ...................................................... 40
4.2.3 Requirements for the Java IDE ..................................................... 41
4.2.4 Evaluation of Java IDEs ................................................................ 43
4.2.5 Evaluation...................................................................................... 44
4.2.6 Conclusions ................................................................................... 48
References ............................................................................................................ 49
5
Portugal Telecom Product Evaluations ................................................................ 50
5.1 Dialogic CT - Media .................................................................................. 50
5.1.1 Product description........................................................................ 50
5.1.2 Features ......................................................................................... 51
5.1.3 Application and system utilities .................................................... 52
5.1.4 Dialogic Hardware Support ........................................................... 52
5.1.5 Technical specifications ................................................................ 53
5.1.6 Results/Tests Evaluations ............................................................. 54
5.2 Text-to-Speech engine: Elan SpeechCube ................................................. 56
5.2.1 Product description........................................................................ 56
5.2.2 Functionality (related to the reference architecture) ..................... 57
5.3 JAVA Speech API (JSAPI) ........................................................................ 57
5.3.1 Product description........................................................................ 57
5.3.2 Features ......................................................................................... 57
5.3.3 Implementations available ............................................................. 58
5.4 ELAN MIME Message Preprocessing API ............................................... 59
5.4.1 Product description........................................................................ 59
5.4.2 Functionality ................................................................................. 59
5.5 Automatic Speech Recognition engine: Philips SpeechPearl .................... 60
5.5.1 SpeechPearl Native API ................................................................ 61
5.5.2 Compliance to standards .............................................................. 63
5.5.3 Functionality (related to the reference architecture) ..................... 63
5.6 VoiXX ........................................................................................................ 63
5.6.1 Product Description ....................................................................... 63
5.6.2 Features ......................................................................................... 64
5.6.3 Applicable Standards .................................................................... 66
5.6.4 Technical Specifications ............................................................... 67
5.7 Q.Mail Messaging Server........................................................................... 68
5.7.1 Product description........................................................................ 68
5.7.2 Features ......................................................................................... 68
5.7.3 License .......................................................................................... 69
5.7.4 System requirements ..................................................................... 69
5.7.5 Architecture ................................................................................... 70
5.8 JavaMail Messaging Client ........................................................................ 70
5.8.1 Product description........................................................................ 70
5.8.2 Architectural Overview ................................................................. 71
5.8.3 The JavaMail Framework.............................................................. 71
5.8.4 Major JavaMail API Components ................................................. 72
6
Telefonica Product Evaluation ............................................................................. 73
page ii (iii)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
6.1
6.2
6.3
6.4
6.5
Annex 4: Early Product Evaluations
Netscape Directory Server ......................................................................... 73
6.1.1 Product description ....................................................................... 73
6.1.2 Functionality (related to the reference architecture) .................... 74
6.1.3 Tests description ........................................................................... 74
6.1.4 Results/Tests Evaluations ............................................................. 74
CISCO AS5300 H323 Vocal Gateway ...................................................... 74
6.2.1 Product description ....................................................................... 74
6.2.2 Functionality (related to the reference architecture) .................... 76
6.2.3 Tests description ........................................................................... 77
6.2.4 Results/Tests Evaluations ............................................................. 77
Microsoft Netmeeting SDK ....................................................................... 78
6.3.1 Product description ....................................................................... 78
6.3.2 Functionality (related to the reference architecture) .................... 80
6.3.3 Tests description ........................................................................... 80
6.3.4 Tests result/evaluation .................................................................. 80
OpenH323 Protocol Stack ......................................................................... 80
6.4.1 Description of the product ............................................................ 80
6.4.2 Functionality (related to the architecture) .................................... 81
6.4.3 Tests description ........................................................................... 81
6.4.4 Tests results/evaluations ............................................................... 82
OpenH323 Gatekeeper ............................................................................... 82
6.5.1 Description of the Product ............................................................ 82
6.5.2 Functionality (related to the architecture) .................................... 83
6.5.3 Tests description ........................................................................... 83
6.5.4 Tests results/evaluation ................................................................. 83
© 2000 EURESCOM Participants in Project P909-GI
page iii (iii)
Deliverable 2
1
Annex 4: Early Product Evaluations
Introduction
In preparation for the experimental phase of the project, partners have made
evaluations of products which seemed promising or interesting to use in the
implementation of the P909 service scenarios. The purpose of this activity was to
provide a chance to do early product evaluations. The products evaluated are not
necessarily the final products to be used in the experiments. Within Task 4, it was
agreed that a product evaluation would be described in the following form:
If a partner evaluates a product, the following guidelines were decided upon
concerning the contribution describing the evaluation. The contribution should be 2 –
8 pages of text (depending on whether the product evaluated is a simple or complex
product). The information to be included in the evaluation description are:

Describe tests performed.

Describe results/evaluation of the tests.

Key words: scalability, openness, standard compliancy.
This document consists of an integration of the early product evaluations done by the
parnters in the first half of the project.
© 2000 EURESCOM Participants in Project P909-GI
page 1 (84)
Annex 4: Early Product Evaluations
2
Deliverable 2
France Telecom Product Evaluations
This contribution brings information about the described products in order to know
their value in the project context. Each product is the object of one part in this
document.
2.1
Microsoft Netmeeting 3.01
The most known telephony on IP software, Microsoft Netmeeting owes success to its
free software status. Currently included in Windows 98 and certainly in Windows
2000, it is easy for a PC user to get it and to communicate over an IP network.
2.1.1
Description of the product
Netmeeting is a video conferencing software. It brings a functionality of Multipoint
Data Conferencing, i.e. it allows to share any Windows-based application or folder
with several other participants using standards-based T.120 data conferencing. There
is also an electronic whiteboard, text-based chat as well as file transfer capabilities.
2.1.1.1
The User Interface
The user interface has changed drastically from the previous version of Netmeeting
(v2.11): the video screen or dial interface or participant list has become the center of
the user interface with controlling buttons around
and the calling history, directory listings and
speed dials that used to be optional "views" in
2.x moved to sub menus. The screen presence is
more compact but the ergonomics
It makes for a much more compact but it seems
clunky and unrefined with little ability to
customize and too much waste space around
buttons.
As of 3.01 some UI/function settings are
persistent. The following aren't and should be:
2.1.1.2
-
Hide /Show audio/video controls when in compact view,
-
Always on top,
-
Adjust Audio Volume/View participant list,
-
Automatically accept calls,
-
Do not disturb,
-
Video size (100%,200% etc)
Call initiation
2.1.1.2.1 ILS
A whole bunch of functionality has been added in this section. NetMeeting now
supports H.323 gatekeepers has special functions dialing features for H.323 gateways
page 2 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
and proxies. The default ILS access has been modified to provide http based access
rather than direct access.
The problem of multihomed users registering the wrong IP address in the ILS is
claimed fixed ( the IP registered is now the same IP that is used to access the ILS). A
mechanism for removing ILS servers from the list has been added ( there has always
been a mechanism for adding servers)
2.1.1.2.2 Audio/Video
The main differences here seem to be under the covers. Microsoft claims to have
improved the speed, quality and the interoperability and initial subjective information
seems to support this claim. One thing that is evident -- the option to use Direct Sound
is now by default off and controllable from within NetMeeting.
Another welcome addition is the digital level displays on the microphone and speaker
controls - the former tiny animated displays were inadequate.
A cute feature that allows picture-in-picture viewing of the local video with the
incoming video has been added.
2.1.1.2.3 Meeting Hosting
The hosting of meetings now has more meaning -- allowing an individual to host
named, password protected meetings and have some control over actions and
individuals in the meeting.
2.1.1.2.4 Security
Features have been added to allow encryption of data only meetings require certificate
based authentication of individuals joining the meeting. This mechanism is used
between two netmeeting software.
2.1.1.3
Other features
2.1.1.3.1 Whiteboard, Chat, File Transfer
There are now two (virtually identical from a user interface point of view)
whiteboards - one now obeys the T.126 standard for compatibility with other
standards based whiteboards and one that maintains compatibility with previous
NetMeeting whiteboards.
The Chat function has been slightly upgraded with more user interface options -- a
nice addition is the automatic detection and creation of clickable URLs.
File transfer interface has been changed -- and Microsoft claims increased speed in
transfer.
2.1.1.3.2 Application and Desktop Sharing
By far the greatest improvement seems to be in the area of application sharing.
Application sharing is now possible in full color, is very fast and allows much more
control of viewing at the receiving end.
A new feature that allows full desktop sharing and remote control has been added.
The desktop sharing should prove an extremely important feature for help desk and
support applications.
© 2000 EURESCOM Participants in Project P909-GI
page 3 (84)
Annex 4: Early Product Evaluations
2.1.1.4
Deliverable 2
The Resource Kit and the SDK
The resource kit for NetMeeting 3.01 is much improved allowing more control over
specially configured versions and an increased volume of documentation and
bandwidth usage analysis information.
The SDK is available at the download site. It brings a solution to develop specific
client software using the Netmeeting components. Interfaces are accessible via C++ or
visual basic program. The COM functionality is the base of this kit. Many examples
are given with the SDK.
2.1.2
Tests description and results
The test concerns the quality of ergonomics, the interoperability with other telephony
software and the possibly use with a vocal gateway.
The ergonomics is very difficult to evaluate because it is a personal judgement. But,
in reference to other user interface like CU-Seeme (not a H323 software), the
Netmeeting one could be better.
Many tests with several other H323 software (Voxware Voxphone 3.0, Netspeak
Webphone 4.02, Intel Internet Video Phone 2.2, Vocaltec Internet Phone 5) show that
the interoperability is true in the call domain. In the application context, this
interoperability is less succeed. In fact, the communication is really based on H323
Recommendation so there is not any problem when you use two software from
different vendors. But in order to manipulate the other functionality such as
whiteboard, no interaction is possible. This test was based on a simple call from or to
Netmeeting and on the launch of the application following the same principle.
With a vocal gateway, a minimum of requirements are necessary. First, you can use
Netmeeting directly with a vocal gateway by setting the gateway field in the user
interface. So, under condition that the vocal gateway can extract the callee number
from the Setup message, the communication can be realized.
Secondly, in order to have a acceptable quality of voice restitution, our vocal gateway
was configured fir using the G.723 codec. In fact, the G.711 codec is a too big
consumer of network resources.
During this tests, we have discovered that many features were removed :

Ability to switch audio/video in a call with multiple users the shared clipboard
(admittedly this as previously implemented with no user control and no warning
was a problem but taking away such a potentially powerful feature is not
sensible)

Ability to track individuals and determine the state of calls ( answered,
unanswered) via History/Speed dial list has been removed
An other constraint is also pointed : because of the way that V3.01 uses http based
directories and the encryption and certificates -- the requirement for IE4.01 or later (in
order to have the rendering engine and security subsystem) only hinted at in past
versions has become a fact.
page 4 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
2.2
Annex 4: Early Product Evaluations
Radvision Gatekeeper development kit
A Gatekeeper is an entity defined in the ITU-T H.323 recommendation. This
recommendation describes terminals and other equipment (such as Gateways and
Multipoint controllers) that provide multimedia communication services over packet
based networks.
According to the recommendation, Gatekeeper functions are:

Call processing.

Address translation.

Call authorization.

Bandwidth management.
All H.323 endpoints (terminals, Gateways and MCU) managed by a Gatekeeper
compose a Zone.
External
Database
Third Party
Application:
policies and
configuration
Zone
Neighbour
Gatekeeper
(other zones)
RADVision
Gatekeeper
Gateway
MCU
Terminal
H.323
Other
Figure 1 : Gatekeeper zone
According to this definition, Radvision has made a complete development kit which
allows to specify and implement a gatekeeper.
2.2.1
Description of the product
2.2.1.1
Functional description
The gatekeeper is composed of the following parts:

H.323 Stack - Handles the H.323 communication, and reports to the
Gatekeeper.

The Gatekeeper Core - Receives the network messages from the stack and
decided on the suitable response.

Internal Control Application (ICA) - Makes decisions about how to
process registrations and calls in the Gatekeeper Core, and sends commands
to the Gatekeeper Core.
© 2000 EURESCOM Participants in Project P909-GI
page 5 (84)
Annex 4: Early Product Evaluations
Deliverable 2
The Gatekeeper Core and H.323 Stack are the software libraries provided by
RADVision. The Gatekeeper Core uses the RADVision H.323 stack in order to
communicate with other H.323 entities. Together the Gatekeeper Core and the H.323
Stack constitute the Gatekeeper Kit (GKK).
The GKK is initiated and controlled by an Internal Control Application (ICA),
supplied by a third party, which must run on the same thread as the Gatekeeper. The
ICA can use some form of asynchronous communication to an External Control
Application (ECA) which runs on a different thread or machine. The ICA is usually
supplied by the provider of the H.323 integrated system. These interactions are shown
below.
Functional Gatekeeper
Internal Control
Application
Gatekeeper
Core
External Control
Application
One
Thread
H.323 Stack
Figure 2 : Functional gatekeeper
Using the built-in polices in the Gatekeeper Core, the ICA can do as little as initialize
the Gatekeeper. Alternatively the ICA can become very involved in the Gatekeeper
operations.
2.2.1.2
Detailed features
RADVision stack functionality includes full implementation of all mandatory
functions defined in the recommendation H323:

Q.931/2 Messages for Call Establishment, Call Clearing, Call Information Phase,
Status and Facility,

All RAS Messages,

H.245 Messages for Master/Slave Determination, Terminal Capability, Logical
Channel Signaling, Request Mode, Round Trip Delay, Maintenance Loop,
Commands, Conference Mode Commands, Indications,

Support of spontaneous ad-hoc multipoint sessions using INVITE and JOIN
commands, conferencing modes and open multicasting,

Support for TRANSFER and FORWARD Supplementary Services,
The tested development kit is designed for the Windows NT operating system, but
exists for UNIX and VxWorks.
According to this previous specifications, the GKK provides Built-In GK-323
functions and policies:

Services for defining the type of services that are available to endpoints,

Zone Control for controlling the number of endpoints allowed in a zone,
page 6 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
2.2.2
Annex 4: Early Product Evaluations

Gatekeeper discovery for determining which gatekeeper to register with
registration options for identifying endpoints,

Network resource management for managing bandwidth usage,

Call set-up routing which provides support for both indirect and direct modes to
route call set-up channels

Address resolution for translating between aliases and transport addresses,

Neighbor gatekeepers for optimizing inter-zone communication,

Keep alive mechanism which provides polling and activity mechanism for
detecting endpoints that fail to "un-registered",

Path resolution for defining preferred routes between endpoints that make service
calls to endpoints providing services,

Configuration saving for protecting against lost data using redundant file system.
Functionality (related to the reference architecture)
The gatekeeper constitutes an important key in the IP domain. It is the entry point for
the IP telephony service. Based on this assumption, the functions of a gatekeeper with
an ICA can include:
2.2.3

Protecting critical mission applications from H.323 traffic.

Controlling resource usage.

Injecting system administrator policy into H.323 system.

Performing call routing.

Carrying out supplementary services.

Integrating with other networks.

Billing services.

Automatic Call Distribution (ACD).

Building a scaleable Gatekeeper functionality by load distribution between
endpoints.
Test description
The test is divided into two parts : one part on the sample ICA making full use of the
Gatekeeper APIs which is included with the development kit. The second part of the
test is based on a specific development in order to know the real possibility of
implementation with this tool.
2.2.3.1
Sample gatekeeper
A gatekeeper is given with the Radvision development kit. It uses all functionality
provided by the API, offering by this way a complete software. The test has consisted
of an analysis of interoperability with many H323 software and of an evaluation of all
services and functions provided by the demonstration software.
© 2000 EURESCOM Participants in Project P909-GI
page 7 (84)
Annex 4: Early Product Evaluations
Deliverable 2
Using Microsoft Netmeeting 3.01 in a first step and then Voxware Voxphone 3.0,
several exchanges were made :

Using the direct signalling mode,

Using the gatekeeper routed signalling mode,

Using the automatic management of endpoint for registration, admission and
calls,

Using the manual management endpoint for registration, admission and calls,

Using the complementary services provided by the sotfware (zone management,
forwarded call on busy or on no-answer, tranfer call),
The main objective of this test is to shown that the development kit allows to
implement gatekeeper compatible with H323 client available on the market.
2.2.3.2
Specific development
In order to know if the development kit is useful in the Eurescom perspective, we
have tried to include a CORBA interface for communicating information with an
other component than a gatekeeper and also for providing a control interface usable
for a generic call control.
The development is not a wrapper for a call control, it is just a starting point for a
possible implementation.
2.2.4
Test results
2.2.4.1
Sample gatekeeper
The sample gatekeeper starts with the Memory Configuration Window which allows
to set up all memory parameters for this applications. This parameters define the
memory quantity used by the program. Then, many other windows are available for a
correct running.

Network Parameters Window for managing H323 parameters such as signalling
mode, gatekeeper ID,..)

Current Calls Window – this window also leads to the Call Details Window
allowing to control each call when the option is set on manual.

Topology Window – this window also leads to the Island Component List
window and the component edit dialog box for defining a zone.

Services Window for creating and activatinf services

Endpoints Window – this window also leads to the Messages, Predefined
Properties, and On-line Endpoint Properties Windows. This window allows to
manage endpoint (or H323 client) during the registration and admission steps.

Neighbours Window allows to define the links between all gatekeeper which can
have relationships.
page 8 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
2.2.4.2
Annex 4: Early Product Evaluations
Specific development
The analysis consist to see how control the gatekeeper behavior through a CORBA
interface. The gatekeeper core runs using several state models. Each transition is
triggered by an event and must be concluded by an action (can be a default action
leaded by the gatekeeper core alone). An IDL interface is defined between a test
control component in order to get the event and then to transmit an action decision.
ST1
REG IDLE
NW1
NW1
AP10
ST8
AP11
REG VACANT
GK2
ST3
AP1
APPROVED
GRQ/RRQ/URQ
ST2
AP6
ST4
NW1
DISAPPROVED
GRQ/RRQ/URQ
NO PENDING TRANS
NW1
AP4
NW1+
GK1
AP2
AP5
AP3
ST5
SENDING
MESSAGE (ONW1)
AP8
AP7
NW2
ST7
ST6
TRANS IDLE
RECEIVED RESPONSE
AP9
Figure 3: Gatekeeper RRQ/GRQ/URQ state flowchart
This control can be exercised on the RRQ/GRQ/URQ state model and also and the
call state model.
© 2000 EURESCOM Participants in Project P909-GI
page 9 (84)
Annex 4: Early Product Evaluations
Deliverable 2
ST1
IDLE STATE
NW1
ST2
AP7
ADDRESS RESOLUTION
AP3
AP1
NW2
AP2
ST3
ST5
ST8
WAIT ORIG
OFFERING
WAIT ORIG ADMISSION
AP4+ONW1
AP5
ST4
CALL CANNOT
COMPLETE
GK1
AP9
NW3
WAIT FOR SETUP
AP6a
ST6
AP6b
HUNTING AND
DESTINATION
CONNECT
NW5
AP6c
NW4
ST7
CALL CONNECTED
NW6
ST9
AP8
DISCONNECT
Figure 4 : Gatekeeper call state flowchart
In reference to Figure 4 : Gatekeeper call state flowchart, messages and requests from
the Network and ICA, cause the following Gatekeeper states:

Idle State (ST1)
Call place is vacant and is available for the next call. The call is not yet known to
the ICA.

Address Resolution (ST2).
The first message (NW1) in a call may be either an ARQ (Admission Request) or
setup message. Both messages, starts the address resolution negotiation of the
gatekeeper with the ICA

Wait Orig Admission (ST3).
When the ICA responds with the confirmation that the address is complete and
the call started by an ARQ message, the gatekeeper sends the ICA the state event
indicating it is waiting for approval to send ACF (Admission Confirm) to the
origin.

Wait For Setup (ST4).
The gatekeeper waits for a setup message to arrive from the origin (the
notification message is sent to the ICA about that state). When a setup message
(NW3) arrives the gatekeeper processes it, and checks if it can matches it with a
waiting call. If so, the gatekeeper switches the call to the state Wait Orig
Offering

Wait Orig Offering (ST5).
When the ICA responds with a message ConfirmAddressDone (AP2) and the call
started by setup message or when setup arrives for a call in process the
page 10 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
gatekeeper sends the ICA the state event indicating it is waiting for the ICA to
approve sending a setup message to the destination. The ICA may respond with a
message ConfirmOrigOffering to approve sending setup. This causes the call to
move to the state Hunting and Destination Connect (ST6).

Hunting and Destination Connect (ST6)
When the ICA sends a message ConfirmOrigOffering (AP5) the gatekeeper
switches the call to the Hunting and Destination Connect (ST6) state in order
to look for the destination address for connecting the origin to this address. The
network sends the setup to the destination address to prepare the destination to
receive the call In this state the gatekeeper tries to connect the call to the
destination and if not successful switches to the next destination : call connected
or call cannot complete.

Call Connected (ST7)
When the connect message arrives from the origin (NW4) the call is connected as
far as the gatekeeper is concerned. The gatekeeper waits for release complete
message from either side in order to switch the call state to the state Disconnect
(ST9).

Call Cannot Complete (ST8)
When a call cannot be completed as dialed, the call switches to this state. The
gatekeeper notifies the ICA with the state event CannotComplete.

Disconnect (ST9)
When the call is disconnected by either the destination, origin or gatekeeper
(initiated by the ICA), a Release Complete message (NW6) should arrive for
each party of the. The call switches to the state Disconnect (ST9).
At each step, there is a event following by an action, so a complete interface can be
made in order to control the gatekeeper. However, this implementation requires a
complete analysis for a mapping between a well-defined call control and all functions
of the development kit API. This test shows only that it is possible to externalize the
intelligence of the gatekeeper using CORBA.
An important comment can be made concerning the use of this API. In fact, it is
possible to manipulate two levels of API : the first one controls directly all H323
activities, it is the low level and the second is the gatekeeper API which provides a
high level API. Even it is possible to use both in the same development, there are
many problems when the low level is used (conflicts appear in the H323 stack).
2.3
Dialogic Boards
Testing each board do not bring enough information about the real potential. Indeed, a
complete system uses several board for providing a service. For example, a vocal
gateway can be made using a D41/ESC for the analog PSTN access and a DM3 for
the voice conversion. It is with this idea that all tests were realized.
© 2000 EURESCOM Participants in Project P909-GI
page 11 (84)
Annex 4: Early Product Evaluations
2.3.1
Product description
2.3.1.1
D41/ESC
Deliverable 2
Four-port DSP-based voice boards with onboard analog telephone interface and
SCbus ™ interface.
2.3.1.2
DM/IP0810A-E1
The DM3 IPLink product, a proven, high-performance, open development platform,
supports the H.323 standard for communication across Internet Protocol (IP) networks
and a wide variety of vocoder algorithms.
2.3.2
Test description
This two boards run on a PC which provides vocal gateway functionality. Linked by
the SCBus, these two boards provide access to POTS and IP.
The test is essentially based on the demonstration program given with the product line
from Dialogic. This program provides VoIP function with a static configuration set up
by a file reading. In order to avoid a complete development, we have introduced a
CORBA interface in this program for providing on-line configuration.
2.3.3
Test result
The control by the CORBA interface was enough to complete a call Phone-to-Net.
However, in the other way, a H323 specificity was used: to include the called party
number in the setup message. So, with this manner, the gateway extracts the
information from the message and dials the number. It is an easy way to provide Netto-Phone communication but an asymmetric one. In order to avoid this kind of
architecture, a more heavy development is necessary but realizable.
Concerning communications with terminals such as Microsoft Netmeeting 3.01, CUSeeme Pro 4.01 and Intel Internet Video Phone, no problem has been found except a
low level of sound on all terminal. We think that it is the IP/link board which needs
some modifications in several parameters.
2.4
Apache Web Server
The Apache Project is a collaborative software development effort aimed at creating a
freely-available source code implementation of an HTTP (Web) server. It is the main
reason for which Apache Web Server is so often used. The following part is limited to
the Solaris platform, architecture supported during the test.
2.4.1
Product description
The Web server Apache is distributed by the Apache group and is totally free. Many
operating systems are supported: NetBSD, Digital Unix, AIX, SCO, HPUX
WindowsNT, FreeBSD, IRIX, Solaris and other ones.
page 12 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
2.4.1.1
Annex 4: Early Product Evaluations
Protocols
Apache supports HTTP/1.1 persistent connections, HTTP/1.1 bytes ranges and
HTTP/1.1 PUT. It allows to access to the server state from CGI or other scripting Its
server side image maps are based on the NCSA one.
2.4.1.2
Security
Apache prohibits access by domain name, by IP address, by user and group and by
directory and files. It can change the user access control list without restarting the
server. It supports SSL v2 and v3, can require password and can hide a part of
document based on security rules.
2.4.1.3
Launching and logging
Apache can write multiple logs. This log files can be automatically cycled or
archived. CGI scripts can create their own log entries. It uses the CERN/NCSA
common log format. On Solaris (and Unix in general) can run from inetd.
2.4.1.4
Other features
Apache can act as an HTTP proxy server which has caches and is multi-threaded. It
allows the remote maintenance. For the last version (v1.3), the tools are GUI-based.
2.4.2
Test description and result
The tested wed sever runs on a Solaris platform. The tests consist of the use of this
server including the installation, the configuration and maintenance.
The use of this server is easy and no problem was occurred.
2.5
DPE environment
2.5.1
IONA Orbix
2.5.1.1
Product description
Orbix is an ORB that implements the CORBA 2 specification. By default, all Orbix
components and applications communicate using the CORBA standard IIOP protocol.
The supported platforms are :
2.5.1.2

Solaris 2.6,

Windows NT 4.0,

HP-UX 10,20, 11,

Digital Unix 4.0e,

AIX 4.3.2.
Tools and services
The components of Orbix are:
© 2000 EURESCOM Participants in Project P909-GI
page 13 (84)
Annex 4: Early Product Evaluations
Deliverable 2

the IDL compiler which parses IDL definitions and produces C++ code,

The Orbix library which is linked against every Orbix program and implements
several components of the ORB, including the DII, the DSI and the core
functionality,

The Orbix daemon is a process that runs on each server host and implements
several ORB components, including the Implementation Repository,

The Orbix interface Repository server which is a process that implements the
Interface Repository.
The CORBA services define a set of low-level services that allow application objects
to communicate in a standard way. These services include the followings:
2.5.1.3

The Naming Service. Before using a CORBA object, a client program must get
an identifier for a object, known as an object reference. This service allows a
client to locate object references based on abstract programmer-defined object
name,

The Trader Service which allows a client to locate object references based on the
desired properties of an object,

The Object Transaction Service which allows CORBA programs to interact
using transactional processing model,

The Security Service which allows CORBA programs to interact using secure
communications,

The Event Service which allows objects to communicate using decoupled, eventbased semantics, instead of the basic CORBA function-call semantics.
Standard compliance
Orbix is an ORB which implements the CORBA 2 specification. This includes the
DSI, the DII, the Interface Repository and the Implementation Repository.
Dynamic Skeleton Interface: Using this ORB component, the server can examine the
structure of the functions called through the IDL interface and can implement them at
runtime. It is for the support os dynamic server programming.
Dynamic Invocation Interface: This component is used by the client program to call
the function of an object.
Interface Repository: It is the database that stores information about the IDL
interfaces implemented by objects in the network.
Implementation Repository: it is the database of the ORB which allows to determine
exactly which object should receive the function call.
2.5.2
Imprise Visibroker
2.5.2.1
Product description
VisiBroker for Java is the first CORBA Object Request Broker (ORB) written
completely in Java. It is provided with several tools: idltojava, osgent, OAD, osfind
and gatekeeper. The supported platforms are:

Solaris 2.5.1, 2.6,
page 14 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
2.5.2.2

Windows 95/98, NT 3.51/4.0

HP-UX 10.20, 11.0

IRIX 6.3, 6.4

AIX 4.1, 4.2, 4.3

Digital Unix 4.0a

SNI Reliant Unix 5.32

DG/UX 4.20

Linux (RedHat 5.2, 6.0).
Annex 4: Early Product Evaluations
Tools
Visibroker provides several tools:

Visibroker development environment includes the following components :

Administration and programming tools,

Java class files,

ORB which supports ORB runtimes for the execution of client o server
programs, ORB utilities used by the system administrator or the developer
such as the osfind… and the server components which are optionally
installable and which include Interface Repository, Smart Agent, and the
OAD.

Gatekeeper: It runs on a web server and enables client programs to make
calls to objects that do not reside on the web server and to receive the
callbacks. In addition, the gatekeeper handles communication through
firewalls.

Smart Agent: it is an extension to the CORBA specification which make it easy
to obtain object reference. A smart agent can automatically reconnect a client
application to an appropriate object server if the server currently being used
becomes unavailable due to a failure. It can use OAD to launch instances of
process on demand.

OAD: Object Activation Daemon registers an object implementation in order to
activate automatically an instance of this object.

Location Service: It is an extension of CORBA specification which provides
general-purpose facilities for locating object instances.

Programmer tools:


IDL2JAVA compiler: it parses IDL definitions and produces Java code,

Idl2ir: it allows to populate an interface repository with interfaces defined in
an IDL file,

Java2iiop: Also Caffeine compiler, it allows to use the Java language rather
than IDL to define interfaces to CORBA objects,

Java2idl: it creates an IDL file from a Java file.
Administration tools:
© 2000 EURESCOM Participants in Project P909-GI
page 15 (84)
Annex 4: Early Product Evaluations
2.5.2.3
Deliverable 2

Irep: It starts the Interface repository server,

Locserv: It starts the location service,

Oadj: It starts the OAD,

Oadutil: it lists, registers and unregisters ORB object implementations
registered with the OAD,

Osagent: It starts the smart agent,

Osfind: It reports on objects running on a given network.
Standard compliance
Visibroker is an ORB which implements the CORBA 2 specification. This includes,
like Orbix, the DSI, the DII, the Interface Repository and the Implementation
Repository.
Dynamic Skeleton Interface: Using this ORB component, the server can examine the
structure of the functions called through the IDL interface and can implement them at
runtime. It is for the support of dynamic server programming.
Dynamic Invocation Interface: This component is used by the client program to call
the function of an object.
Interface Repository: It is the database that stores information about the IDL
interfaces implemented by objects in the network.
Implementation Repository: it is the database of the ORB which allows to determine
exactly which object should receive the function call.
2.5.3
Test and Result
The test is only based on the use of this two DPE. With our experience, two factors
can be noticed. The performance and the interoperability of these two DPE.
Concerning the performance, Orbix is quicker than Visibroker on the method
invocation. Some statistics will be available.
Concerning the interoperability, Orbix is not as good as in the previous point. In fact,
Orbix includes some problems, especially the IOR format. Orbix replaces the
character “/” in an IOR by the character “_”. It is a big problem for a complete
interoperability. Moreover, Orbix has some difficulties when two objects defined on
an other ORB use the same interfaces.
On other point which must be signaled is that naming services are not compatible.
page 16 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
3
CSELT Product Evaluations
3.1
Lucent IST-SP
The Lucent Technologies Internet Telephony System for Service Providers (ITS-SP)
release 2.2.0 product has been evaluated from an architectural point of view and
extensively tested to verify the supported functionality. The evaluation has been done
considering scalability, openness, performance and compliance to standards issues.
Currently Lucent is supporting a new release of the product called PacketStar Internet
Telephony System for Service Providers (ITS-SP). With release 3.0 of the product,
the ITS-SP will be forward compatible with the newly launched PacketStar IP
Gateway 1000.
3.1.1
Description of the product
The ITS-SP product provides high quality PSTN voice and fax transmission over an
IP data network (e.g. the Internet). The ITS-SP has three basic components a gateway,
a service access manager (SAM) and an administration manager. The Gateway
component provides capabilities to convert PSTN voice to IP by compressing,
packetizing, decompressing and depacketizing voice and fax calls. The ITS Service
Access Manager component performs gatekeeper functions. The SAM provides
capabilities to support security, to locate destination gateways, to perform QoS
analysis and to set up calls originating from a multimedia PC. One standalone SAM is
able to support up to 25 gateways and up to 500 PCs. The ITS Administration
Manager controls centralised administration and network management for gateways
and SAMs. It provides capabilities to master customer’s database, call routing
database and numbering plans. In addition, the ITS-AM provides capabilities to
administer gateways and customer services. The access to the ITS-AM is realised by a
secure web-based GUI interface.
Each ITS-SP gateway component has interfaces to both the Public Switched
Telephone Network (PSTN) and the packet network. When a call arrives from the
PSTN, the ITS-SP compresses and encapsulates the voice and transmits the packets to
a remote ITS-SP via the data network. The remote ITS-SP decompresses and extracts
the voice from the IP packets and converts them back into voice. The ITS-SP supports
phone calls setup and exchange of control messages, operations, administration and
maintenance (OA&M) messages, and other standard network services. The ITS-SP
system supports POTS-to-POTS voice and fax transmission services and PC-to-POTS
voice transmission services.
The system architecture is highly scalable and it is easy to expand it and to add new
customers and services. An Application Programming Interface provided with the
system allows the customisation of services and the development of new applications.
3.1.1
Technical specifications
ITS-SP:
Operative system:
ITS-SP, UnixWare 2.1.x (SCO) Unix system
Processor:
Pentium Processor 200 or 233 Mhz
DSP:
TAP-802 or TAP-801 DSP Resource Board
© 2000 EURESCOM Participants in Project P909-GI
page 17 (84)
Annex 4: Early Product Evaluations
Deliverable 2
Ethernet connection:
2 IEEE 802.3 10BaseT/100BaseT with 1 RJ45 connector
each
T1/E1 Interface:
1 E1 Trunk interface R1-MFC or PRI ISDN E1 (Euro ISDN)
supporting up to 30 voice channels with 1 RJ48C or 120ohm E1
Disk drivers:
CD-ROM and 3.5 Floppy drive
COM Port 1:
RS-232 interface to connect to the system console
ITS-SAM and ITS-AM:
3.1.1.2
Operative system:
Sun Solaris 2.5.1
Processor:
Ultra 60 Series platform, 300 Mhz
Setup cabling and software requirements
ITS-SP:
Ethernet connections:
one or two (10 BaseT or 100 BaseT) RJ45 Ethernet
connection to the IP network (primary LAN connection and
secondary LAN connection for Data Network Fallback)
System console:
an ASCII terminal connected through an RS232 null modem
PSTN interface:
one E1 facility from a carrier provider (must support 120ohm E1 RJ48C connector)
Power supply:
220-240 volt AC power outlets (1 for system console, 1 for
the gateway system)
Additional software:
Microsoft NetMeeting 2.1 for PC-to-POTS voice calls
support
ITS-SAM and ITS-AM:
3/1/1/3
Ethernet connection:
one (10 BaseT or 100 BaseT) RJ45 Ethernet connection
Power supply:
220-240 volt AC power outlets (1 for system console, 1 for
the solaris system)
Additional software:
a system running a Java (jdk 1.4.4) – compatible Netscape
Navigator browser with LAN connection to the IP network.
(It is recommended to use Netscape Communicator 4.5)
Scalability
Each ITS-SP support up to 30 concurrent calls at the same time through an E1
interface. It is possible to configure a set of gateways as belonging to one site. In this
case a single ITS-SAM will be used to manage all the gateways belonging to the same
site. In order to increase the number of channels available on a single PSTN address,
it is possible to configure a routing table in order to make each site gateway covering
the same PSTN number with same priority. The only limitation is due to the capacity
of each SAM to handle up to 25 gateways.
The new Lucent PacketStar IP Gateway 1000 product will be able to support up to 21
E1s interfaces. It will be possible to build networks consisting of both ITS-SP and
GW 1000 or to migrate to the GW1000 product.
page 18 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
3.1.1.4
Annex 4: Early Product Evaluations
Openness
The ITS-SP product offers an Application Programming Interface (API), sold
separately, which can be used to customise existing applications and developing new
services. The API is written in C++ and allows the access to the gateway basic
functionality. The API is based on a message/event model. Commands are issued by
invoking the C++ API class methods. The events are handled through a C++ analogue
of the Java programming language event model. The event model is used to handle
API-related asynchronous event, such as call related events (e.g. release-complete,
etc.).
The API supports the following call control functions:
3.1.1.5

Ability to launch different services based on the value of triggers such as ANI,
DNIS, network side of the incoming call, ecc.

Call setup and teardown;

IVR functions and DTMF digits collection;

Call related information handling;

Tone detection and generation.
Compliance to standard
The product supports the following standards:
3.1.1.6
Coders:
Supports multiple voice compression, including Lucent
Elemedia SX7300P, G.72x, ecc.
Network layer protocols:
TCP (H.225, H.245), RTP (over UDP), H.323 v1 is used
to control PC to phone calls. Future releases will be
H.323 v2 compliant.
Management protocols:
SNMP
Additional information:
For call setup and control from an ingress ITS-SP to the
egress one the systems use a proprietary protocol which
is not compliant to H.225.
Performance
The ITS-SP system provide voice quality that equals cellular call quality and
approaches toll quality at bandwidths as low as 12kbps. Results from tests have
highlighted a good quality on the average for fax and voice services. Nevertheless it is
suggested to carefully design the IP interconnection network in case of service
deployment. Some tests have enlighten that keeping the packet network delay less
than 100 ms can be a requirement to approach an acceptable quality for voice calls.
For this reasons it is suggested not to use the device with highly congested networks
such as company LANs or the big Internet.
3.1.2
Functionality (related to the reference architecture)
The ITS-SP can be used to provide two classes of services:
1.
POTS to POTS voice and fax calls
© 2000 EURESCOM Participants in Project P909-GI
page 19 (84)
Annex 4: Early Product Evaluations
2.
Deliverable 2
PC to POTS voice calls using NetMeeting
The first class of service can be realised using two ITS-SP interconnected by an IP
based network. POTS voice or Fax calls are routed to the first ITS-SP (called ingress
gateway) and then, through the IP network segment, to the second ITS-SP (called
egress gateway). An authentication procedure is supported and implemented within
the ingress gateway. A user will be authenticated by the ingress gateway after having
dialled its userID and PIN. After that, the user will be asked to dial the destination
POTS number. The call is routed according to the previously configured dialling
plans to the egress gateway and eventually to the destination number.
The second class of services can be realised using a PC with NetMeeting 2.1
interconnected to the ITS-SP device through an IP based network. The user will call a
destination POTS number using the NetMeeting GUI. The user will provide the POTS
number together with UserID and PIN information in form of an ASCII string.
NetMeeting will connect to the previously configured SAM and, if the user has been
authorised, the call will be routed first to the gateway and then to the destination
PSTN address.
The following additional features are supported by the ITS-SP gateway:

Single or two stage dialling (it should be possible to dial only one POTS
number);

Provides integrated routing, directory and billing functions;

System security and call security;

Hair-pin routing to PSTN;

In-call data network fallback;
Moreover, it is possible to build new service or applications through the API. Some
examples are:
3.1.3

Call screening

Call redirection

Alternate routing on busy/ no answer or congestion

Repeat dialling

Customisation of CDR recording

Call Timeout

Customised call routing
Tests description
The performed tests can be divided into four classes:

POTS to POTS voice call service test

PC to POTS voice call test

ITS-AM test

API tests
page 20 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
All the tests are aimed to prove the effective availability of the declared features, the
easiness of configuration and management and the device openness and
programmability.
3.1.3.1
POTS to POTS voice call test
Two gateways were interconnected using a controlled IP network (round trip delay
less than 10 ms). The gateways are connected to the PSTN using an ISDN E1
connection for each one. All the available features have been verified and tested.
3.1.3.2
PC to POTS voice call test
A multimedia PC with NetMeeting 2.1 was interconnected to the ITS-SP using the
company LAN. The ITS-SP has been connected to an ISDN E1 trunk interface to a
real PSTN switch. Several calls have been placed from NetMeeting to a destination
PSTN number. All the available options have been tested.
3.1.3.3
ITS-AM test
The ITS-AM has been used to configure the network (i.e. gateway and SAM
configuration), routing tables, numbering plans, authorised users and available
services. The ITS-AM has been accessed using a Netscape Communicator 4.5
browser from a PC interconnected to the ITS-SP. In the lab configuration the ITS-AM
and the ITS-SAM were co-resident with the ITS-SP device.
3.1.3.4
API test
The API has been installed, evaluated and tested in order to investigate how it could
be possible to deploy the identified service scenarios as described in PIR 2.4. The
following tests have been done:
Call information (POTS-POTS, PC-POTS)
An application that displays incoming call related information has been developed.
When a call arrives to the ITS-SP from one of the two side (i.e. PSTN or IP Net), the
application displays information such as ANI, DNIS, ecc. on the console monitor.
Third party –like call setup
An application that is able to bridge two incoming calls, one arriving from the PSTN
side and the other arriving from the IP network, has been developed. When a call
arrives on the PSTN side the application waits for the corresponding incoming call
from the IP network. When the IP network call arrives the application bridges the two
calls and the POTS to PC communication is set up.
Single stage dialling
It has been verified the possibility for a user to make a single number in order to reach
a destination on the PSTN.
© 2000 EURESCOM Participants in Project P909-GI
page 21 (84)
Annex 4: Early Product Evaluations
Deliverable 2
No authentication
It has been verified the possibility of bypass the authentication process. Some calls
could be recognised as valid calls using the DNIS or ANI information, without the
need to authenticate the calling user.
3.1.4
Results/Tests Evaluations
3.1.4.1
POTS to POTS voice call test
The POTS to POTS functionality has been extensively tested. The ITS-SP seems to
work well also with load peak condition. The following results have been found:
3.1.4.2

The authentication procedure, play of messages and routing of the call didn’t
present any problem even in critical load condition.

The device is able to handle up to 40 calls/hour;

The quality of voice is acceptable (GSM like) only if a controlled IP network
with a round trip delay less than 100 ms and with a limited loss of packets is used
to interconnect the two gateways.

The single stage dialling functionality has not been tested.
PC to POTS voice call test
The PC to POTS functionality has been tested considering the easiness in using the
service. The following results have been found:
3.1.4.3

The NetMeeting configuration didn’t present any particular problem. The user
needs only to know the SAM IP address;

It is important to check that the PC supports Full-duplex audio features;

The use of headphones with attached microphone can improve the quality of
conversation;

…
ITS-AM test
The ITS-AM has been used for configuration and administration and all its feature has
been verified. The following results have been found:
3.1.4.4

The tool is easy to use because it is structured as a window hierarchy;

The response to queries and request for update is good

From a remote administration site it is possible to configure and administer the
whole network;
POTS to PC voice call test
The results of this test verified the impossibility to use the API to manage phone-toPC scenarios. The API doesn't provide any operation to route an incoming PSTN call
to an IP address or to initiate a call towards an IP address. This prevents to use the
API and consequently the vocal gateway to perform hybrid scenarios between PSTN
and IP where the call is initiated by the PSTN side.
page 22 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
3.2
Stratus XA/R and SINAP
3.2.1
Description of the products
3.2.1.1
3.2.1.2
3.2.2
Annex 4: Early Product Evaluations

Fault Tolerant HW platform (STRATUS XA/R 5-S) with SW product for
Intelligent Network applications (SINAP release 3.1). The Stratus architecture is
designed to ensure that applications are continuously available. It protects its
systems from costly downtime with HW based fault tolerance via a proprietary
design.

Over this HW platform the Stratus Intelligent Network Applications Platform
(SINAP) can deliver enhanced services to the Advanced Intelligent Network.
SINAP is an API designed to deliver enhanced services to the Advanced
Intelligent Network.
Technical specifications

Operating System: FTX 2.2 (UNIX System V compliant)

Processor: Intel i860 64-bit RISC

Network Interface: V.35 SS7
Compliance to standard

CCITT Signalling System No.7 Blue Book

Fault-Tolerant UNIX (FTX™), the only fault-tolerant and scalable native port of
UNIX System V.
Functionality
SINAP includes signalling System #7 (SS#7) protocol with several additional
capabilities designed to simplify creating new services, testing, troubleshooting, and
delivery. As a SW platform product, SINAP can support many services
simultaneously, while offering performance optimisation for enhanced service
individually. The Common Application Service Layer (CASL), that is a part of
SINAP, is a library of C language functions linked to processes running in the SINAP
environment, as well as to some support processes. This CASL API allows
implementing applications, which use TCAP functions.
3.2.3
Tests description
Outside the scope of the project, it has been developed on top of SINAP platform the
Telecom Italia ASE-RI protocol (proprietary INAP dialect) and part of the ETSI- Core
INAP as the SSP-SCP protocol. These were used for the tests described in this
chapter.
© 2000 EURESCOM Participants in Project P909-GI
page 23 (84)
Annex 4: Early Product Evaluations
3.2.3.1
Deliverable 2
Web-IN test
Web Server
STRATUS
Client
Application
Client
Application
SCP
Servlet
INTRANET
SSP
Proprietary protocol
based on http
table
SINAP
Infrastructure
Common Application Service Layer
CASL
SS#7 I/O Subsystem
Figure 5: Web-IN like scenario



3.2.4
Functionality developed

SCP queries an external Web Server in order to retrieve the subscriber
routing number. The server launches a servlet, which loads a table
containing the association between a logical number and the routing number
to return back it to the SCP application.

Subscriber can change his/her current routing number from the Web using a
common browser. The servlet launched by the Web server upgrades the
values in the routing table.
Execution of functional tests of the example developed

Successful call, logical dialled number (e.g. 800-phone number) is translated
by Web Server to routing number

Unsuccessful call, dialled number is not recognised by SCP

Unsuccessful call, dialled number is not recognised by Web Server
Execution of performance tests of the example developed
Results/Evaluations

Execution of functional tests of the example developed
The main results of this evaluation has been to prove that the Stratus platform,
composed by the fault-tolerant hardware and the SINAP platform, can easily be
extended to handle the Virtual Presence scenario requirements, which is the IT
target service scenario in the project.
page 24 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
It allows to analyse incoming calls and run the correct service logic based on the
Service Access Code and to interact with an external application, which is
responsible for storing and managing the subscriber service data.

Execution of performance tests of the example developed
Send call istances
Application istances
calls
calls/sec
1
1
100
3.45
5
1
500
3.36
10
1
1000
3.28
1
5
100
3.03
5
5
500
10.87
10
5
1000
11.24
1
16
100
4.17
5
16
500
11.36
10
16
1000
10.53
The analysis of performance data has to take in account that there are other
parameters that can affect the results when the number of servers increases. In
particular the network connection established between the SCP and the external
application and the performances of the Web server can reduce the performance
rate quite sensibly.
3.3
Slapd
3.3.1
Description of the product
Slapd is a stand-alone LDAP daemon, product of LDAP development team at the
University of Michigan. Slapd’s model for directory service is based on a global
directory model called LDAP, which stands for the Lightweight Directory Access
Protocol. LDAP is a directory service protocol that runs over TCP/IP.
Slapd has a front end that handles connection management, access control, and
protocol interpretation, and a number of backends that handle database operations.
The two pieces communicate through a well-defined API. The slapd backend API
(SLAPI) consists of twelve calls. Nine of the calls correspond to the nine LDAP
protocol operations bind, unbind, search, compare, modify, modify RDN (Relative
Distinguished Name), add, delete and abandon.
3.3.2
Functionality
Some of slapd’s featurs include:

Choise of database: it comes with three different backend database you can
choose from (LDBM, high-performance disk-based database; SHELL, a database
interface to arbitrary UNIX commands; PASSWD, a simple password file
database).

Multiple database istances: it can be configured to serve multiple backend
database at the same time.
© 2000 EURESCOM Participants in Project P909-GI
page 25 (84)
Annex 4: Early Product Evaluations
3.3.2.1
Deliverable 2

Generic database API: it consist of two distinct parts, a front end that handles
protocol communication with LDAP clients and a backend that handles database
operations.

Access control: it provides control access to entries based on LDAP
authentication information, IP address, domain name and other criteria.

Replications: it can be configured to maintain replicated copies of its database.
Compliance to standard
LDAP is a directory service protocol that runs over TCP/IP. LDAP directory service
model is based on entries. An entry is a collection of attributes that has a name called
a distinguished name. Each of the entry’s attributes has a type and one or more values.
The values depend on what type of attribute it is. In LDAP, directory entries are
arranged in a hierarchical tree-like structure that reflects political, geographic and/or
organisational boundaries. LDAP allows you to control which attributes are required
and allowed in an entry through the use of special attribute called objectclass. The
values of that attribute determine the schema rules the entry must obey.
3.3.3
Tests description
The test consists in the design and implementation of a Directory Server based on
slapd, which provides functionality to access and modify data stored in the database.
In particular the operations getData, modifyData and addData have been tested.
The Java Naming Directory Interface (JNDI) has been chosen as the API to develop a
front-end for the slapd DS. It allows users to access in a standard way the information
stored in the database. Further, it makes the access to such an information
independent both of the quantity and type of requested information.
The information used in the test are organised sketched the information contained in
aUser Profile and consist in the following attributes:

DN = username@Cselt

LogicalNumber = <logicalNumber>

PhysicalNumber = <physicalNumber>

GSMNumber = <gsmNumber>

MailAddress = <mailAddress>

UserHomePage = <url>

Objectclass = userprofile
page 26 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
The picture depicts the architecture of the system used to test slapd.
3.3.4
Results/Evaluations
The results of the tests convey that slapd can be used as LDAP server in the
experimental sceanrio. We tested the performance of it with hundreds of user records
and by stressing it with concurrent requests to retrieve entries, to modify attributes of
them and to add new entries in the database.
3.4
Dynamicsoft jSIP
3.4.1
Description of the product
jSIP Version 2 is a Java based implementation of the Session Initiation Protocol (SIP)
as per the IETF RFC 2543. There are several levels of implementation defined in this
specification and they all will be incorporated into jSIP in time. The first level
includes minimal specification requirements as well as some basic SIP requirements.
Each level builds on the previous level. The subsequent levels include Redirection,
Firewall-friendly, Multicast, Negotiation, Authentication, and Encryption. The
minimal and basic SIP requirements and the Redirection are currently available and
Firewall-friendly, Multicast and Authentication are under development.
It requires the Java Virtual Machine (JVM) Version 1.1 or later. Version1.2, also
called Java 2, is recommended for the best performance and it will run on any
platform supporting such a JVM.
3.4.2
Functionality
One of the benefits of jSIP, is the High Level API that is available both in Java and C,
and is provided with the jSIP Release 2.1. This allows you to implement a SIP client
endpoint in Java and/or C without having to get involved with the complexity of SIP.
Here is how it works:
There is a class included in jSIP called SipClient that includes a class called
SipTranslator. Together these run as a process called the SipClient. This process
handles the SIP complexity of the State Machine. This includes the retry logic that is
used when the client endpoints run in the UDP mode.
© 2000 EURESCOM Participants in Project P909-GI
page 27 (84)
Annex 4: Early Product Evaluations
Deliverable 2
It is the job of the SipTranslator to listen for messages from the client endpoints,
implemented in Java and/or C, and to send messages to client endpoints. This works
in conjunction with the SipClient class. The DsSipApi class removes the complexity
of sending and receiving messages over sockets. The DsSipApi functionality is also
available in the C API library package included with jSIP Release 2.1.
The interface class, ClientEndPointInterface defines the methods that your endpoint
must implement. These are the callbacks that you will receive when SIP methods
arrive at the SipClient.
3.4.3
Tests description
The following picture depicts the physical scenario of the evaluation of jSIP. The SIP
client and client end-point run over Windows 95/NT machines while the SIP server
has been installed on a Solaris 2.6 machine.
The scenario that has been run during the different tests was the following:
1.
User A invites user B: a SIP INVITE message is sent to the SIP server
2.
The SIP server contacts the Location Server to get the information where the user
B is located
3.
The invitation is forwarded to user B
4.
User B accepts the invitation
5.
The response message is returned back to user A.
6.
User A acknowledges the user B to have received the response
7.
The SIP server forwards this acknowledges to user B.
To evaluate the product the following tests have been performed:

Running the demonstration delivered with the product in a single machine mode.
It consists in 2 client processes and a SIP server where one client invites the
other to the session via the SIP server, which locates the target client; this
allowed also testing the configuration of the system.
page 28 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
3.4.4
Annex 4: Early Product Evaluations

The same demonstration where the SIP clients are distributed over different
Win95 and Win NT machines;

Modification of the provided sample code in order to test
1.
How to pass application dependent parameters between the clients
2.
How to launch an external multimedia application (Microsoft NetMeeting)
consequently to an invitation. This test verifies the possibility to use the SIP
protocol to handle invitation and H.323 to handle the media stream flows.

Modification of the Location Server to test the possibility to integrate it with
external logic which implements simple example of routing policies.

Start an invitation from scratch directly from the SIP server
Results/Evaluations
The tests run successfully but the last one. The provisioning of sample code allows to
easily prototype an application that exploits the SIP capability. The product confirms
the foreseen capabilities and fits almost completely the requirements of the Virtual
Presence service scenario.
In fact the API provided with the products is related exclusively to the SIP client side.
The SIP server doesn’t have any API and this prevents starting from scratch any
invitation from its side. The solution that will be adopted is to integrate a dummy SIP
client in the server side in order to start invitation from the server side to fulfil the last
requirements expected in the Virtual presence service scenario.
© 2000 EURESCOM Participants in Project P909-GI
page 29 (84)
Annex 4: Early Product Evaluations
4
Deliverable 2
KPN Product Evaluations
As part of PIR 4.2, ‘Early Product Evaluation’, KPN Research has concentrated on
examining products and tools which can be used as Service Creation & Execution
Environments.
The main work has concentrated on evaluating the usability of the new Genesys
Nirvana product as an SCE for the experimental part of the IN/Internet project P909.
In addition to a description of Nirvana, the first sections of the KPN contribution also
give the results of small experiments which were performed for the product
evaluation.
In addition KPN Research has investigated products which are suitable to be used for
the creation of JAIN Services. It has been decided to study existing Java Integrated
Development Environments (IDEs) and to evaluate the suitablilty of these products to
be used as an SCE for JAIN Services. The results of these evaluations are described in
the second half of the KPN contribution.
4.1
Genesys Nirvana
Genesys provides an object-oriented service development, execution and control
environment, which makes it possible to distribute (DCOM) services (or parts
thereof) and to integrate commercial components.
By linking components together, via global and local variables, it is possible to
develop distributed applications. This manner of component-based development is
stored in scripts. When a script trigger is activated, the Nirvana platform takes over
control until the entire script has been processed.
The remainder of this section gives a detailed description of the Nirvana platform.
4.1.1
Product description
4.1.1.1
Architecture
The architecture of the Nirvana platform will be discussed first in order to give a full
impression of the platform. Following this, the development, execution and control
environments will be dealt with.
Nirvana uses the facilities of and extends DCOM to form a true object-oriented
middleware. DCOM has been chosen specifically by Genesys because Microsoft has
already integrated a large number of components in its products and the majority of
people use these. In addition, it allows the components of third parties to be (re)used.
The Nirvana platform supports several different types of components that can be
(re)used, using a scripting language, to develop distributed applications. These can be
divided up into two types of components:
1.
Solid components: these are components and objects that are made using a
normal programming language, such as C++, Visual Basic, etc. Some examples
include:

standard Microsoft COM/DCOM components

standard Microsoft Active-X components
page 30 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
2.
Annex 4: Early Product Evaluations

standard Genesys Nirvana components

components of third parties

reuse of standard components

creation of new components using a normal programming language.
Script components: these are scripts that can be reused as new components in
other scripts.
There are different types of solid components. The difference between the standard
components of Microsoft and those of Genesys lies in the number of interfaces the
components have. Nirvana components have extra interfaces and are DCOM
components with a DII (Dynamic Invocation Interface) interface and a Describe
interface. The DII ensures that late binding can take place and the Describe interface
is used by the Distributed Advisor to call up the characteristics of the component.
This compensates for the disadvantages of DCOM components in Nirvana and true
object-oriented middleware functionalities are provided thanks to the Distributed
Advisor and the Interface Repository.
Figure 1 shows clearly where the extra functionalities are added in order to make
DCOM into a true object-oriented middleware. As a result, the objects are available
everywhere in the network. The figure also shows where CORBA will fit into the
architecture if Genesys decides to adapt Nirvana to support this.
Script Editor (IDE) for NT
Script Engine for UNIX
(POSIX, CORBA)
Script Engine for NT
Script
Script
Script
Script
Script
Script
High-Level Dynamic Invocation Interface
Dynamic
Invocation
Interface - COM
ActiveX
Automation
CORBA Dynamic Invocation Interface
Distributed Advisor
Name Service, Locator, Load Balancing
DCOM - ORB
Bridge
DCOM
COM
Component
COM
Component
COM/DCOM
ORB
CORBA
Component
CORBA
Component
CORBA (Future)
Figure 1 Nirvana architecture
4.1.1.2
Distributed Advisor
A Distributed Advisor supplies information about all of the different objects that are
available in an application domain. An application domain is a domain within a
Windows NT domain. It is a domain within which a Nirvana application can find all
of the necessary components, of one or more machines, so that it can run effectively.
Only one Distributed Advisor can be active within one application domain, but
several application domains can be active in one Windows NT domain. In a Windows
© 2000 EURESCOM Participants in Project P909-GI
page 31 (84)
Annex 4: Early Product Evaluations
Deliverable 2
NT domain there are often specific servers that are in heavy use, for example a
database or a mail server. If you want to use the specific functionalities of this server,
it will have to be located in an application domain. It is thus sensible to create several
application domains so as to reduce the workload of a Distributed Advisor and to
distribute it over the network. There are three possible ways to divide up application
domains, as shown in figure 2:
1.
One Distributed Advisor on the local server (Application domain 1)
2.
One Distributed Advisor and a specific server in the same application domain
(Application domain 2)
3.
The specific server is used by several application domains simultaneously. It is
determined at component level which component belongs to which application
domain. (Application domain 3 & 4)
Windows NT Domein
Applicatiedomein 2
Applicatiedomein 1
Windows NT Server
met Distributed Advisor
Windows NT Server
met specifieke Hardware
of Software
Windows NT Server
met Distributed Advisor
Applicatiedomein 3
Windows NT Server
met Distributed Advisor
Windows NT Server
met specifieke Hardware
of Software
Windows NT Server
met Distributed Advisor
Applicatiedomein 4
Figure 2 Several application domains in one Windows NT domain, each with
one Distributed Advisor
Each application or component is registered in the Windows NT server registry and
knows which Distributed Advisor it needs in order to be able to run the application.
The Windows NT registries of the servers in its application domain are read
repeatedly by the Distributed Advisor by means of a ‘heartbeat’ mechanism. Using a
database, the Interface Repository, this mechanism records any changes and the
Distributed Advisor knows precisely which components are available in the
application domain and which ones are not. If a server should then break down, the
Distributed Advisor will take this into account. If any essential components that are
required to run an application are not available, an alarm is generated by the
Distributed Advisor. Figures 3 and 4 show the different collected lists.
page 32 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
Figure 3 List showing the available components in an application domain
Figure 4 List showing the available computers in the application domain
The Distributed Advisor needs the information about the registered components in
order to be able to arrange the communication between the various components of
different machines. Distributed applications use components that are on other
machines. If an application requires such a component, then the application will make
a request to the Distributed Advisor. The latter provides a reference to the other
computer and passes this on. Once the reference has been passed on, the specific
components communicate directly with each other until the execution has been
completed.
Several applications can be available and/or active in one application domain. If there
are two or more applications active in the same application domain and if they are
using the same components, then the Distributed Advisor will apply load-balancing
for the components that occur more than once in its application domain.
One disadvantage of the Distributed Advisor is that its application domain can only be
located in one network domain. As a result, Nirvana has become an object-oriented
middleware specifically for one network domain.
If you want to run an application and the Distributed Advisor is able to find all of the
necessary components in the application domain, then the script will be activated in
the Script Engine of the Nirvana platform.
© 2000 EURESCOM Participants in Project P909-GI
page 33 (84)
Annex 4: Early Product Evaluations
4.1.1.3
Deliverable 2
Development environment
One of the great advantages of the Nirvana platform is that it has a visual scripting
development environment. The development environment, known as the Script Editor
& Engine (SE&E), is fully object oriented and works on the basis of the objectoriented middleware standard of Microsoft, DCOM. In the future the CORBA
technology will be added to this.
The development environment also provides additional programs that work together
with the SE&E and can each add extra functionality to the scripts (applications). The
Form Manager enables the developer to design web interfaces for a service. The
ActiveX Wizard collects all ActiveX components that are present on the server. These
ActiveX components can be integrated in a script so that it is possible to include the
functionalities of almost all Microsoft products in one service. In addition, there is
also a Voice Worker which can be used to manage voice files.
Script Editor & Engine (SE&E)
De Script Editor & Engine (SE&E) forms the core of Nirvana’s development
environment and uses a visual scripting language to develop applications. The way in
which components are used to graphically define the flow-of-control provides the user
with a clear picture of the application to be developed. The user only invokes the
interfaces of the different components, which in turn are linked to global and local
variables. This reduces considerably the programming time for the development or
modification of (existing) business applications. It is not necessary to look through
and process very long lists of C-codes before an application will work properly.
The SE&E console is divided up into four screens, as shown in figure 5:
1.
Project Workspace screen: here all of the script interfaces, methods and variables
are defined. The ‘Language Operators’ (to be discussed later on), components
and the (interface) repositories are also shown here.
2.
Script screen: it is here that the script is designed. A script is designed by
graphically specifying the flow-of-control.
3.
Monitor screen: when a script is activated it always sends back messages
(reports), correct or incorrect reports. The DCOM network protocol sends back
32-bit hResult return values. The components in the Script window can use these
as a check. The DCOM hResult return values are given in appendix A.
4.
Quicklook screen: here the methods and variables for a component are shown
when the mouse is placed on a component in the Script window.
page 34 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
Project
Workspace
scherm
Script
scherm
Quicklook
scherm
Monitor
scherm
Figure 5 Nirvana Script Editor & Engine Console
Language Operators
Within SE&E there is a great variety of functionalities available, comparable with
normal programming languages such as C++, Java and Visual Basic. Some examples
of these include:

Structured: enables the flow to be organised in methods, blocks and separate
objects.

Full-featured: provides all standard facilities, such as looping, if statement,
calculate, start, stop, etc.

Multithreaded: provides the facility for parallel processing in scripts with
extensive synchronisation opportunities.

Flexible: the scripts are interpreted, which means that there is no need for any Ccodes or for any compilation to take place. It is based on the method ‘What you
see, is what you run’, i.e. what you see is what you activate.
Working in conjunction with the Distributed Advisor, Nirvana makes it possible for
software to be reused as a scalable, flexible and resilient platform, for anything from
small to large implementations, by means of the addition of components.
4.1.1.4
Execution- & management environment
Once a new application or service has been developed using SE&E, it can be loaded
in the Script Engine. Here the applications or services are registered so that the
Distributed Advisor sees them during its checks. The Script Engine is the execution
environment of the Nirvana platform. As long as the script is active in the Script
Engine, it can be activated and customers can use the service. The scripts can be
activated in various ways:
© 2000 EURESCOM Participants in Project P909-GI
page 35 (84)
Annex 4: Early Product Evaluations
Deliverable 2

A web interface: by means of an ASP document. Users are able to activate a
given service, depending on the ASP document. (Additional software is however
required for this.)

Call trigger: a service is activated when a telephone call is received. The Nirvana
platform can make the call in different ways, depending on the script. (Additional
hardware and software is however required for this.)

E-mail: a service is activated when an e-mail is received. This can be converted
for voice. (Additional hardware and software is however required for this.)
It is possible to develop components with event functionalities. This can be done by
building new solid components, for example using C++, or by designing a shell
around existing components that provides these functionalities.
The Script Engine will work together with the Distributed Advisor to attend to the
applications during execution. The Distributed Advisor arranges the communication
between the different components.
4.1.2
Nirvana Experiment Description
This section describes the experiments as they were performed at KPN Research the
explore usability of Genesys Nirvana for the experimental part of the Eurescom P909
project.
4.1.2.1
Genesys Nirvana Training
As part of the evaluation of Nirvana a training session (4 days) was organised at KPN
Research by Genesys Nirvana.
The goal was to get a clear view on the underlying architecture and possibilities of the
Nirvana platform. Several subjects were covered as listed below:

Nirvana Architecture

Standard Nirvana Components

Building Services (Scripting)

Configuration Management

Building Custom Components
This knowledge forms the basis for the rest of the experiments which were performed
within the early product evaluation activity.
4.1.2.2
Realization of Experimental Environment at KPN Research
To be able to evaluate the Nirvana platform an experimental environment is realised
in which the development experiments can be fullfilled. This is done as part of the
Service Creation Lab (SC-Lab) within KPN Research. This lab is used for both
service architecture studies as well as prototyping of services.
Within the Service Creation Lab an prototyping IN environment is available from
Ericsson that could be used for the experimental part of the Eurescom P909 project at
KPN Research. For this IN environment source code is available, so needed changes
to the interfaces towards the Reference Architecture can be implemented relative
easy.
page 36 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
For the product evaluation activity part of the entire configuration was performed as
described below. This way, a clear view on problems with configuration and
management of the platform could be identified.
The Nirvana platform runs in its own network domain on the network of the SC-lab
that consists of two Windows NT 4.0 servers in a cluster linked to a storage array i.
Windows NT is not always entirely stable, which is why a cluster mechanism has
been included in the system; this improves the availability and scalability of the
platform. If one machine breaks down, the other takes over all of the work. One of the
servers will also function as a webserver. This is possible because the cluster
mechanism is only going to be used for demos. The cluster servers will function as the
heart of the network domain.
Within this network domain there are two other Windows NT 4.0 servers: one with
Dialogic hardware, consisting of an ISDN-30 card, and one with Nirvana. The
Nirvana server will be used as an SCE (Service Creation Environment), on which new
services will be developed. In the SC-Lab there is also an IN-platform that is linked to
the Ethernet network. This will be linked to the domain. The interface between these
two platforms is expected to be ready half way through the year.
The Dialogic hardware enables limited switching functionalities to be driven,
including a voice response functionality. The IN-platform drives a switch, which
enables the Nirvana platform to set up and/or terminate a telephony call. The switch is
also linked to the public network, the Delta network (internal telephony network) of
KPN Research and, via a gateway and a Firewall, to the Internet for the purposes of IP
telephony.
Figure 1 gives a diagrammatical representation of the general configuration of the
Nirvana platform as it stands in the SC-lab.
Publieke Netwerk
Delta Netwerk
Telefoon
Telefoon
PBX/PABX
Telefoon
NT Server
Service Creation Environment
IP Telefonie
Gateway
Telefoon
IN Platform
IN Platform
Firewall
"David"
(Operationeel)
"Goliath"
"Kerberos"
Intranet
Telefoon
Telefoon
ISDN-30
Storage Array
- Genesys Nirvana
NT Servers Cluster
- Enterprise edition
- WWW-server
NT Server met
Dialogic Hardware
Figure 6 General configuration of the Nirvana platform in the SC-Lab
© 2000 EURESCOM Participants in Project P909-GI
page 37 (84)
Annex 4: Early Product Evaluations
4.1.2.3
Deliverable 2
Click-to-dial Service Development Example
In order to evaluate the Nirvana platform, a service example was implemented using
different components available. The Click-to-dial service was chosen because this is
one of the service scenario’s for P909.
The following features of Nirvana were testing in some way within this experiment:

Visual Programming Language (Java and C++ alike).

Distributed Service Execution.

(Re-)use of existing components.

Dialogic Component (DCOM).

Microsoft Internet Explorer Component (Active-X).

Microsoft Netmeeting Component (Active-X).
The purpose of this experiment was not to built the service according to the P909
Reference Architecture, but to gain experience in how to build services with Nirvana.
Two service scenario’s were implemented:

CTD from PSTN to PSTN (using Dialogic Hardware)

CTD from IP to IP
(using Netmeeting API)
Within the evaluation no experiments using a Vocal Gateway were performed.
4.1.2.4
Interworking CORBA/DCOM in Nirvana
Because the purpose of this product evaluation is to test usability within the
experimental part op the project, it is important to test the re-usability of components
developed within the rest of the Eurescom project (Task 3). Because the choice there
will very probably not be to implement using DCOM technology, interworking is very
important. If it is possible to use a CORBA/DCOM bridge to integrate Task 3
components directly into a service implementation in Nirvana, then very little effort is
needed to re-use these components.
Therefore this experiment was defined to use a simple existing CORBA component
and integrate this within a service script in Nirvana. Within the experiment a simple
component is used, which is capable to sent SMS messages.
4.1.3
Nirvana Conclusions
This section describes in short the conclusions that were drawn from the results of the
different experiments.
Realization of Experimental Environment at KPN Research
The configuration of the Nirvana Service Platform is experienced as very simple. This
is mainly because of the tight integration of Nirvana and Window NT. The
Distributed Advisor is able to gather almost all needed information. For instance the
available component within the NT domain are detected fully automatic. This tight
integration is also a disadvantage because the service platform is only available on
NT, although components can be executed on another OS.
page 38 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
The only problem was concerning the Microsoft Cluster for high availability of the
Distributed Advisor. This doesn’t concern the Nirvana platform and also other (more
sophisticated) clustering sollutions are available.
Click-to-dial Service Development Example
The development of the service example was after some startup (read inexperience)
problems reasonable simple. Esspecially changing the script from using ISDN
hardware from Dialogic to using Microsoft Netmeeting was very simple.
Nirvana uses ASP to communicate directly between the webpages and the active (or
activated) script. It took some time to get this working, but no architectural problems
were found.
Interworking CORBA/DCOM in Nirvana
Currently the experiment on interworking is still ongoing, so no results are available
yet.
Overal Conclusion
From the architecture study of Genesys Nirvana and the experiments perfomed KPN
Research concludes that Genesys could be used very well to perform the experimental
part of the P909 project.
This will mean that a separate implementation of the P909 Reference Architecture
will be realised at the KPN Research location using Nirvana as the basis service
platform.
4.2
Introduction – Java IDE evaluations
This section presents the results of a study for Service Creation Environments (SCEs),
for the creation of JAIN Services. It has been decided to use an existing Java
Integrated Development Environments (IDEs) as SCE for these JAIN Services.
We begin by describing the requirements for the desired SCE for JAIN services.
We then describe the minimal requirements for the Java IDE as a SCE.
Finally a best match is found between the desired requirements for SCE and the
existing Java IDEs.
The conclusion summarises the matching-process, emphasising the final choice, of the
Java IDE as a SCE.
4.2.1
JavaBeans
The new JAIN services can be built (in the SCE/IDE) using JavaBeans. JavaBeans are
independent building blocks representing various services, features etc. Java Beans
are explained in more detail in the following section.
A JavaBean (sometimes referred to as just ‘bean’) is a reusable, independent software
component that from the SCE’s point-of-view, has a visual representation and can be
manipulated via this visual representation.
Some JavaBeans may be simple GUI elements, such as buttons and sliders. Other
JavaBeans may be sophisticated visual software components such as database
viewers, or data feeds. Some JavaBeans may not have a GUI appearance of their own
© 2000 EURESCOM Participants in Project P909-GI
page 39 (84)
Annex 4: Early Product Evaluations
Deliverable 2
at all (like the ‘JINI-Bean’), but these can still be visually manipulated using a SCE
builder by visualizing them.
Some SCE builder tools may operate only visually, thus allowing the direct ‘plugging’
of all JavaBeans. Other builders may support the creation of Java classes that then
interact with (and thus control) a set of beans. Builders may provide furthermore a
simple scripting language to allow easy high-level scripting of a set of beans.
Although JavaBeans differ in the functionality they provide, they all have a number of
features in common:

“Introspection” support;
So that a builder tool can analyze how a bean works

“Customization” support;
A user can customize the appearance and behavior of a bean.

“Events” support;
A simple communication method to interconnect beans.

“Properties” support;
For both customization and programming applications.

“Persistence” support;
Enabling the storage and retrieval of a customized bean.
The SCE builder tools may include web page builders, visual application builders,
GUI layout builders, or even server application builders.
Sometimes the “builder tool” simply is a document editor that is including some
beans as part of a compound document.
4.2.2
Requirements for a JAIN SCE
This section describes the desired general requirements for the Service Creation
Environment (SCE) for the development of JAIN services. A SCE is an environment
for the definition, development, integration, and validation of service logic. A service
logic is assembled using generic service independent building blocks in a plug-andplay fashion.
4.2.2.1
List of requirements

Working with JavaBeans components
The SCE should support the creation and application of JavaBeans.

Working with non-JavaBeans applications
The SCE should support the creation, execution and debugging of ‘ordinary’ (i.e. nonJavaBeans) applications, of applets etc.

Graphical User Interface
Although there are various possibilities to relate JavaBeans to each other, a graphical
way seems to be a common approach (a collection of JavaBeans can be related by
linking them, e.g. via arrows or lines). One of the main reasons evidently is the
naturality and (consequently) easy of use.
For this a Graphical User Interface is necessary.
page 40 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2

Annex 4: Early Product Evaluations
HTML support
Browsing of HTML documents should be possible.

On-line JAIN Help and Development support
The SCE should support the creation of JAIN-compliant services both via help
(documentation) and active support (e.g. with wizards).

JAIN awareness
The SCE should contain JAIN-specific libraries, Beans, documentations, JAIN TCAP,
ISUP etc. reference Implementations and/or hardware resources.

Security
As a customer is not allowed to perform activities for which there is no permission
(e.g. in contradiction with an interconnect agreement) the access to various resources
is to be controlled at user level. The SCE should support this user-level access
control.

Testing
There has to be a possibility to test the new services. In particular, as services might
use different networks, simulations (‘stubs’) of these networks need to be available.

Repository
A user-extendable repository of services/features needs to be supported by the SCE.
Only those JavaBeans that meet the standard specification process (‘seen and
approved’) may be added to the repository.

Support of other environments
To develop a JAIN service, EJB, Jini and/or JDMK environments are to be supported.
This can be achieved in various ways, e.g. a ‘JINI-Bean’ that can be linked by a new
service if this new service needs to make use of a JINI network (features).

Programming Language
Of course, at least the Java programming language has to be supported.

Multi-user support
To be able to develop new services in teams, it should be able to work on different
scripts with multiple developers including functionality as script looking. Preferably,
this is integrated with the Repository for the scripts and JavaBeans.

Data provisioning template
It should be possible to develop a data template and data entry functions
corresponding to the created services.
4.2.3
Requirements for the Java IDE
A JAIN SCE can be built using existing Java Integrated Development Environments
(JIDEs) products. This section describes specific requirements for the JIDE product
which make the JIDE best-suited to use as a JAIN SCE.
© 2000 EURESCOM Participants in Project P909-GI
page 41 (84)
Annex 4: Early Product Evaluations
4.2.3.1
Deliverable 2
List of requirements

Debugging
The JIDE should contain a full-functional Debugger; source-level debugging,
breakpoints, inspecting/evaluating variables/expressions, exception handling, thread
management, and calling stack browsing.

Stability
The JIDE should be stable (it should not ‘crash’ on a regular basis) and it should not
suffer from any memory leaks.

Ease of use
The JIDE should be convenient to use. Most (J)IDEs tend to be very large and
consequently slow (as a rule, they need at least 64M, and then this is just enough for
only a simple project).
Of course the upgrading of memory could solve the problem, but the slower the JIDE
is, the less efficient the upgrading of this JIDE is.

Project support
I.e. the organising of files into projects. Although (at least) all the evaluated JIDEs
have it, it is mentioned here for completeness.

(Fast) Compilation
A compiler from a JDK is written in Java, ‘thus’ it’s rather slow.
Fortunately, most IDEs are shipped with their own (proprietary) compilers, which are
usually very fast (but; proprietary).

Help system with Search Engine
The JIDE should contain an exhaustive help system a.o. including a full description of
the Java language, the Java API, and IDE features.
Here, a search engine is a must!

JavaBeans support
Support for both for using and creating of JavaBeans is to be provided by the JIDE.

GUI Design
Although it is discussible whether or not Java is suitable at all to develop complex
and/or good GUIs, it is still mentioned here as a requirement, as some kind of GUI
design-support at least is very easy.

Service Support
SCE should support wide range of services.

3rd party support
SCE should support 3rd party developed JavaBeans (Enterprise JavaBeans) and enable
3rd party service development.

Service logic
SCE should support service logic portability and reusability.
page 42 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2

Annex 4: Early Product Evaluations
Target Network Independence
SCE should support development of service logic without reference to the
infrastructure of the target network (PSTN, IP, mobile etc.)

Common Format
All Service creation tools should use a common format for service logic expression.

Service Logic Verifiability
SCE should provide a verifiability of service logic – a user described services logic is
well formed and can be successfully executed.

Call model support
SCE should transparently support a variety of call models including PSTN and IP
networks.

Creation of Service Package
A Service Package includes service logic and associated data. SCE should support
creation of Service Package.

Configurable plug-ins
The JIDE should finally offer support for configurable plug-ins.
This is one of the most important requirements for Source and Version Control
Systems!
4.2.4
Evaluation of Java IDEs
4.2.4.1
Introduction
The following list enumerates all investigated IDEs:

Metrowerks CodeWarrior;

Microsoft Visual J++ 6.0;

Sun JavaStudio 1.0;

IBM Visual Age 2.0;

Borland JBuilder 2.0;

Symantec Visual Café 3.x;

Sybase PowerJ 2.X, 3.0;
There are two possibilities to work with Java, using either a JDK only (not necessarily
the Sun JDK), or an IDE (possibly including a JDK).
When working with an IDE, it is at least recommended to install the JDK as well. A
project should then periodically be compiled with a compiler from the JDK. Also, to
ensure compatibility with Sun’s Java specification, the final (release) compilation
should be done with it. For the same reason, the main testing should be done running
an application on a JVM from this JDK. By doing so, many compatibility problems
can be avoided, since the most widespread (and the most conformed to JLS) JVM and
compiler are those from Sun’s JDK.
© 2000 EURESCOM Participants in Project P909-GI
page 43 (84)
Annex 4: Early Product Evaluations
Deliverable 2
Only a JDK is in general not enough (although the development in the UDP project
has been done using only the Sun’s JDK 1.1.6 where the only thing really missing was
a good debugger; see forthcoming) because of a number of reasons:
4.2.5

Debugger;
The JDK debugger, although available, is very difficult to use (command line
interface) and rather slow.

Project support;
The JDK has no project support.

Slow compiler;

Help system;
In JDK, this is just a number of HTML files and has no search engine!
If it is clear where to look for some info, it is easy to find it; it takes however too
much time if you don’t know.

JavaBeans support;
This is a separate product (BDK - Beans Development Kit).

GUI Designer;
None, in JDK.
Evaluation
The evaluation of IDE products was a combination of hands-on and paper studies.
4.2.5.1
Shareware/freeware IDEs
There are several shareware and freeware IDEs on the market. These add some of the
required functionality to the JDK, like project support and front-end to the debugger,
but they use a compiler, a debugger and a help system from a JDK. They therefore
inherit most of the problems of a JDK itself.
4.2.5.2
Metrowerks CodeWarrior
This IDE is nothing more than a good layer above JDK (see the previous Section). It
allows a developer to use either Sun JDK or Microsoft JDK, but its debugger works
only with Microsoft JDK.
4.2.5.3
Microsoft Visual J++ 6.0
This IDE has the following characteristics:

Project support;
Traditional approach.

Memory load;
The least memory consuming IDE.

Sun’s Java specification compliant;
Not Sun’s Java specification compliant.

GUI Designer;
With proprietary components only.
page 44 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
4.2.5.4
Annex 4: Early Product Evaluations

Help system;
With proprietary format and a search engine (advanced).

Two editions:
Standard Edition (~110 USD) and Professional Edition (~550 USD).
Sun JavaStudio 1.0
This IDE has the following characteristics:

Project support:
No source files at all; all “development” is being done by placing components
within the GUI and Design Windows, connecting them in the Design Window,
and then setting their properties. GUI components are placed within both
windows; non-GUI components are placed within only the Design Window.

Debugger;
No debugger.

Memory load;
Memory-consuming.

JDK support;
No pluggable JDK support (only JDK 1.2 available).

Plug-in support;
No plug-in support.
At the moment it is really no more than a toy because:
It’s possible to create only GUI programs (AWT), using only one window/form.
It’s very difficult to build even a simple application (more than 10-15 components in
the Design Window).
No direct way to use Java API. The only possible solution is to create a Bean that
would act as a gateway, and to add the Bean to the Component Palette. The Bean
should be arranged into a jar-file: it’s impossible to add a class-file to the Component
Palette.
No full JavaBeans support: there is no way to change a Bean’s properties at runtime
(only at design time).
Very limited set of components shipped with JavaStudio.
4.2.5.5
IBM Visual Age 2.0
This IDE has the following characteristics:

Project support;
A completely different approach (in comparison with other tools); no files,
everything is stored in the source database.
Because of this it is very difficult to use external tools with Visual Age, since
these external tools tend to use files only and have no knowledge about the
internal database.
It is possible to export and import files, but it’s inconvenient when done often.

Class support;
It is impossible to see a whole class, only a method at a time (by choosing a
© 2000 EURESCOM Participants in Project P909-GI
page 45 (84)
Annex 4: Early Product Evaluations
Deliverable 2
method in the class browser).
The browser furthermore doesn’t recognise inner classes; they are displayed
together with member variables.
4.2.5.6

Version/source control system support;
A very powerful version/source control system is built-in (useful for a medium
and large team development).
It is however too powerful for individual or small team development, and can not
be disabled.

Stability;
It is stable.

Memory load;
It is slow and memory consuming (according to some Usenet messages, 128 MB
is a lower limit at which it could be usable for simple projects).

JavaBeans support;
I.e. creating and visual composition.

GUI Designer;
Is available.

Debugger;
The debugger is good, but has some drawbacks. The main one is that it is
impossible to evaluate any arbitrary expression. Only parameters, local or
instance variables, and hard-coded expressions can be evaluated.

JDK support;
No JDK 1.2 support and no pluggable JDK support.

Help system;
HTML with a search engine (advanced) based on HTTP-server and CGI.
Its installation cannot be controlled.

Three editions;
Entry Edition (free), Professional Edition (~100 USD), and Enterprise Edition
(~3000 USD).
Borland JBuiler 2.0
This IDE has the following characteristics:

Project support;
Traditional approach.

Debugger;
Good.

JavaBeans support;
JavaBeans are supported although not graphically.

GUI Designer;
Is available.

Memory load;
Slow and memory consuming on medium/large projects (although no so much as
Visual Age).
page 46 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
4.2.5.7
Annex 4: Early Product Evaluations

Stability;
Stable/Not very stable(according to some information in Usenet).

JDK support;
Support for pluggable JDK.

Plug-in support;
Plug-ins supported.

Version/source control system support;
Build-in support for PVCS, a version/source control system.

UI;
This one is a bit ugly and exposes some strange behaviour.

Help system;
A proprietary format with search engine (average).

Three editions;
Standard Edition, Professional Edition, and Client/Server Edition.
Symantec Visual Café 3.x
This IDE has the following characteristics:

Project support;
Traditional approach.

Debugger;
Good.

JavaBeans support;
JavaBeans are supported.

GUI Designer;
Is available.

Memory load;
Memory consuming, but still quite fast.

Stability;
Stable/Not very stable (according to some information in Usenet).

JDK support;
Support for pluggable JDK.

Version/source control system support;
Support for version/source control systems.

Help system;
MS Windows HLP files.

Three editions;
Standard Edition (~100 USD), Professional Edition (~300 USD), and Database
Edition (~800 USD).
A trial version has been used for evaluation.
© 2000 EURESCOM Participants in Project P909-GI
page 47 (84)
Annex 4: Early Product Evaluations
4.2.5.8
Deliverable 2
Sybase PowerJ 2.X, 3.0 (beta version)
This IDE has the following characteristics:
4.2.6

Project support;
Traditional approach.

Debugger;
Good debugger, but it has some drawbacks. The main one is that it cannot work
with exceptions.

JavaBeans support;
JavaBeans are supported although not graphically.

GUI Designer;
Is available.

Memory load;
Memory consuming but quite fast.

JDK support;
Support for pluggable JDK.

Profiler;
A built-in profiler is available.

Version/source control system support;
Support for version/source control systems.

Help system:
MS Windows HLP files.

Two editions:
Learning Edition (free), and Enterprise Edition (PowerJ v 2.5: special prise ~300
USD).
Conclusions
After the hands-on evaluations, a comparison of the IDE products was made. The
requirements for an SCE were compared to the results of the evaluations, and a choice
was made for the IDE most suitable for a JAIN SCE. The results below give the main
reasons for the final choice.
1. Microsoft Visual J++;
Out of the list of alternatives mainly because of its incompatibility with Sun Java
Specifications, including JavaBeans specification.
2. Sun JavaStudio;
Because it is not possible to design and develop ‘real’ applications. (Recall, ‘just
a toy’)
3. Borland JBuiler 2.0;
Removed because it operates poorly on medium/large projects and there is bad
graphical support for JavaBeans.
4. Sybase PowerJ 2.X, 3.0;
No graphical support for JavaBeans.
page 48 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
5. IBM Visual Age;
The facts that it is impossible to view a complete class at once and also that it has
bad JDK support removed this product from the list of choices.
4.2.6.1
Final choice
Although just a trial version has been used in the evaluation, the final choice for a
Java IDE thus is Symantec Visual Café.
4.2.6.2
Detailed product features
An extensive list of product features can be found at the following references:

IBM Visual Age 2.0 – Ref. [3]

Borland JBuilder 2 – Ref. [4]

Symantec Visual Café 3.0 – Ref. [5]

Sybase PowerJ 2.X, 3.0 – Ref. [6]
References
[1]
JAIN TCAP REQ-DC-01-01
[2]
JAIN TCAP REQ-LR-*
[3]
Http://www.ibm.com
[4]
Http://www.inprise.com
[5]
Http://www.symantec.com
6]
Http://www.powersoft.com
© 2000 EURESCOM Participants in Project P909-GI
page 49 (84)
Annex 4: Early Product Evaluations
5
Deliverable 2
Portugal Telecom Product Evaluations
In this contribution a set of evaluated products is presented.
These products are usable for service scenarios that have been defined within the
scope of the P909 project. Particularly these products will be in use for the PT inhouse test.
These products cover (fully or partially) the needed functionalities for the
performance of the Unified Communication service. In the following table the
functionalities and the products are itemized
FUNCTIONALITY
PRODUCT
Text-to-Speech Media Translator
Elan SpeechCube, Elan Mime Message
Preprocessing API, JSAPI
Automatic Speech Recognition Media Translator
Philips SpeechPearl, JSAPI
Messaging Control Resources
VoiXX / Exchange Server
Q.Mail Server
Messaging User Interfaces
VoiXX / Exchange Client
JavaMail Client
Message Store
ORACLE (in the future)
Call control / Telephony User Interfaces
5.1

S.100 Adapter
Dialogic CT Media

IVR
Dialogic boards
Dialogic CT - Media
CT Media for Windows NT from Dialogic provides a standards-based application
development software platform and run-time environment for building open
telecommunication servers.
5.1.1
Product description
CT Media is a resource management software package that supports multiple, open
application programming interfaces (APIs), including the S.100 media APIs defined
by the Enterprise Computer Telephony Forum (ECTF). CT Media makes it possible
for applications developed to these APIs to share a computer telephony (CT) server
and its technology hardware — providing a more economical and extensible platform
for adding new services when needed, without duplicating hardware. CT Media
supports all CT devices such as voice digitizers, voice recognizers, and network
interfaces through a published Service Provider Interface (SPI). Support for the CT
Media SPI can be developed using the resource development libraries available in the
Dialogic CT Media Resource Developer’s Kit. The open interfaces in CT Media make
applications portable, letting them run on servers with multiple vendors’ hardware,
without any modification to existing software applications. This framework also
allows for the addition of new devices like facsimile or speech recognizers to the
server, with no change to software applications.
page 50 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
CT Media provides a rich CT server environment that will support TAPI applications
in the future. Its resource management support will make it possible for TAPI
applications to control hardware devices from independent suppliers in the same
server. It also handles SCbus™ time slot connections — completely abstracting this
complex task from the application developer. CT Media provides a framework that
can enhance TAPI 2.x applications with the ECTF industry-standard S.100 interface
for media functionality.
5.1.2
Features
CT Media provides system services and application interface adapters for all defined
S.100 APIs, including
• Player
• Recorder
• Signal detector
• Signal generator
• Automatic speech recognition (ASR)
• Facsimile
In the future, CT Media will support the Microsoft Windows® standard telephony
interface, TAPI, for call control functions.
The “Run-Time Control” (RTC) feature of CT Media enhances performance and
facilitates hardware independence. RTC is a server-based process, by which
independent devices can control each other, for example
• Causing a text-to-speech (TTS) player device to speed up or slow down playback
when a signal detector device receives a dual-tone multifrequency (DTMF) digit
• Causing a voice coder player device to stop output when an ASR device recognizes
a specific voice input
Before CT Media, such inter device communication required custom integration by
vendors of the different technologies.
CT Media supports the hand-off of calls and call-related data between applications.
This powerful capability lets applications become more specialized and provide
encapsulated services.
Applications can rely on other applications to provide additional services.
Collectively, multiple applications can provide a higher level of service to a caller
than a single application. For example, a help desk application could query a caller
and then hand off the call to a voice mail application, permitting the caller to leave a
message. The call can then be transferred to a fax-on-demand (FOD) application, to
let the caller request a fax document. Each application can be supplied by a separate
developer without any coordinated or integrated development efforts.
CT Media provides a framework for configuring systems for customer-specific
telephone network environments and customer-specific call routing requirements.
CT Media (SCR – “Service Call Router”) serves as the central service for routing
inbound calls to applications based on configurable routing parameters, such as
Automatic Number Identification (ANI) or Dialed Number Identification Service
(DNIS) information, or the time of day. CT Media is responsible for allocating
© 2000 EURESCOM Participants in Project P909-GI
page 51 (84)
Annex 4: Early Product Evaluations
Deliverable 2
telephone lines to outbound applications and can even dial on behalf of the
application. CT Media abstracts the telephone network interface and presents a
simplified interface to the application developer for handling the unique protocols
required by different telephone networks. The call routing and call control interface of
CT Media is extensible, letting developers build support for specific network
interface devices or for customized switching extensions.
5.1.3
Application and system utilities
CT Media features several useful utilities to assist developers in creating applications
and configuring servers.
5.1.3.1
CT Server administration
• System administration is enabled through an Administration application that
provides support for remote connection to a server, editing profiles, and managing
various replaceable system services. Developers have the option to use this
application or to build their own, using the Administration API supported in CT
Media.
5.1.3.2
Container Manager
• A CT Media Container Manager utility provides the tools for managing media files
in the CT Media Container System where data objects are stored. in the TVM format
(TVM are encapsulation of atomic pieces of time-varying media).
5.1.3.3
CT Simulator
• The Dialogic CT Simulator (CT Sim) lets developers emulate system resources and
simulate events to test application responses, without the presence of hardware
resources. Alternatively, CT Sim allows API commands to be entered via a command
line interface, to test resource behaviour or to prototype application code sequences.
5.1.3.4
SDK
The CT Media SDK provides:
• Libraries of “C” language functions that allow vendor applications and signal
processing hardware to be integrated with the CT Server
• Tools to test vendor code and monitor its execution
• Documentation describing how to use the supplied libraries and tools
• To help application developers get started, source code programming examples for
sample applications and resources are included.
5.1.4
Dialogic Hardware Support
The following Dialogic hardware products are supported by CT Media:
• D/41ESC™
• D/80SC™
• D/160SC™
page 52 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
• D/160SC-LS™
• D/240SC™
• D/240SC-T1™ (T-1 Robbed Bit and ISDN PRI protocols)
• D/240SC-2T1™ (T-1 Robbed Bit and ISDN PRI protocols)
• D/300SC-E1™ (ISDN PRI protocols)
• D/300SC-2E1™ (ISDN PRI protocols)
• D/320SC™
• D/480SC-2T1™ (T-1 Robbed Bit and ISDN PRI protocols)
• D/600SC-2E1™ (ISDN PRI protocols)
• LSI/81SC™
• LSI/161SC™
• DTI/240SC™ (T-1 Robbed Bit and ISDN PRI protocols)
• DTI/241SC™ (T-1 Robbed Bit and ISDN PRI protocols)
• DTI/300SC™ (E-1 ISDN PRI protocols)
• DTI/481SC™ (Dual T-1 Robbed Bit and ISDN PRI protocols)
• DTI/600SC™ (Dual E-1 ISDN PRI protocols)
• MSI/80SC-R™ (Station Set and Conferencing functionality)
• MSI/160SC-R™ (Station Set and Conferencing functionality)
• MSI/240SC-R™ (Station Set and Conferencing functionality)
• VFX/40ESC™
• VFX/40ESC plus™
The open interface and CT Media Resource Developer’s Kit makes it possible to add
support for third-party hardware products.
CT Media already provides support to hardware devices from several companies.
5.1.5
Technical specifications
Operative system: Microsoft’s Windows NT, version 4.0
Processor:
Pentium Processor 200
RAM:
64 Mb
For the SDK:
Microsoft’s Visual C++, version 5.0
© 2000 EURESCOM Participants in Project P909-GI
page 53 (84)
Annex 4: Early Product Evaluations
5.1.6
Results/Tests Evaluations
5.1.6.1
Scenario
Deliverable 2
The PT scenario for test CT Media API is the follow:
CT Media
CT - Server
CT - Client
Applications
Server administration
Mailbox
Container Manager
Bridge
CT Media Service
Provider Interface
S.100 Media API
TCP/IP
TCP/IP
Ethernet card and drivers
Eth. card
2
D/41ESC drivers
3
 
Dialogic D/41ESC
GS
M
Commands
Events
POTS
1

Fig.1 PT scenario for test CT-Media
5.1.6.2
Description
We have made two client application:
• The first we called mailbox. With this application a user can record a message in the
CT Media Container and he can listen it, after a user validation with a PIN code.
These are the steps of mailbox application.
1 – The user on phone 1,2 or 3 (see fig.1) dials one of the D/41ESC lines in the CT
Server
2 – After two (may be changed) rings the mailbox application gets control of the call
3 – Prompt: Welcome to the service
4 – Prompt: Menu:
Option 1 – Listen the last message recorded.
Option 2 – Record a message
5 – Enter the Option
If option 1
6 – Prompt: PIN Code?
page 54 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
7 - Enter PIN Code
If PIN Code is correct
8 - Listen the message
If option 29 - Record the message (‘*’ to end)
10 – Prompt: Goodbye
11 – Drop the call
12 – Exit
• The second we called bridge. With this application a user can do a call (phone 1, fig.
1) than, after a user validation (PIN code), can enter two phone number (phone 2,3 –
fig.1), drop the initial call and after this, the application connect (bridge) the two
phones.
These are the steps of Bridge application.
1 – The user on the phone 1 calls one of the D/41ESC lines in the CT Server
2 – After two (may be changed) rings the Bridge application gets control of the call
3 - Prompt: Welcome to the service
4 – Prompt: PIN Code?
5 - Enter Pin Code
6 - If PIN Code is correct
7 – Prompt: first number? (phone 2)
8 – Enter the number
9 – Prompt: second number? (phone 3)
10 – Enter the number
11 – Prompt: Goodbye
12 – Drop the initial call on the phone 1
13 - Make a call to the first number
14 – Play “music” on the phone 2
15 – Make a call to the second number
16 – Bridged the two calls
17 – Exit
5.1.6.3
Objectives
Whit this two application we can test:
• The basic resources of CT-Media:
Player
Recorder
Signal detector
Signal generator
© 2000 EURESCOM Participants in Project P909-GI
page 55 (84)
Annex 4: Early Product Evaluations
Deliverable 2
• The RTC “Run-Time Control” for example, stop the voice prompt when a four digits
PIN code is enter by the user
• The interaction between a Client Application and a CT-Server in another PC over a
TCP/IP network
• Resources (hardware an software) concurrency and resources sharing, between
applications.
• The SCR “System Call Router” Wait, make, and drop calls. Bridging and routing
calls depending on their CLI (or other related infos) and pass this information to the
applications.
5.1.6.4
Results and comments
With only two lines the system works well and quickly the question is when we have
for instance four Dialogic D/300SC-E1 card, how we can control all the channels (4 *
30)? We must have one thread for each channel? What is the performance of this
scenario?
The next steps are:
We haven’t; yet, test how to get information like CLI (ANI OR DNIS) from a call and
how the applications can take decisions depending of this information, so, we will try
this.
Another step is to test the hand-off of a call (pass the call control between
applications).
Another step that we shall do, perhaps, is to run these applications with shared
resources over ATM.
In the future, we will try to integrate this with the ASR Speech Pearl 99 from Philips
and the TTS Speech Cube from Elan.
5.2
Text-to-Speech engine: Elan SpeechCube
5.2.1
Product description
The Speech Cube is a multi-channels and multilingual a full Text to Speech software
solution. It also includes an e-mail processing API.
The SpeechCube supports the following languages: American, English, French,
German and Spanish, Brazilian and Russian. Three other languages are currently
under development: Italian, Dutch and Arabic.
5.2.2
Technical specifications
Elan SpeechCube Text to Speech core technology is based on the P.S.O.L.A.
technique: Pitch Synchronous OverLap Add., which has been created by C.N.E.T.
Lannion, laboratory of research of France Telecom in 1989.
To convert text to speech, the SpeechCube system is organized in several modules:

the High Level processing modules including :

a lexicon database and rules for phonetics and grammatical analysis,
page 56 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2


Annex 4: Early Product Evaluations
the prosody calculation modules specific for the concerned language,
the synthesizer modules including :

the acoustic unit database which stores all diphones sound units recorded for
the language,

the units selection module

the P.S.O.L.A. synthesizer which process speech signal.
All these modules use a common programming interface called SYC.
The product is available under several operating systems, Win NT in SAPI version,
Unix SCO or Solaris, LINUX.
On Pentium platform under Win NT, the Speech Cube SAPI is compatible with
Dialogic, NMS or others telephony interface boards which accept wave files (an audio
destination object type wave file is available).
For NMS board, Speech Cube SAPI can used CT ACCESS environment and is
provided with an Audio Destination Object (ADO) for NMS board. An ADO is also
available for Dialogic boards D41 and D300.
5.2.1.2
Compliance to standards
The Speech Cube Software Development tool Kit is SAPI compliant.
5.2.1.3
Scalability
Today the product allows 30 channels per host on Windows NT with the SAPI
version.
Elan is planning to enlarge the number of channels supported by a distributed Speech
Cube product.
5.2.2
Functionality (related to the reference architecture)
The SpeechCube enables Media Translation for the User Interaction Control, by
converting Text media to Audio media.
5.3
JAVA Speech API (JSAPI)
5.3.1
Product description
The Java Speech API defines a standard, easy-to-use, cross-platform software
interface. Two core speech technologies are supported through the Java Speech API:
speech recognition and speech synthesis (text-to-speech).
5.3.2
Features
Along with the other Java Media APIs, the Java Speech API lets developers
incorporate advanced user interfaces into Java applications. The design goals for the
Java Speech API included:

Provide support for speech synthesisers and for both command-and-control and
dictation speech recognisers.
© 2000 EURESCOM Participants in Project P909-GI
page 57 (84)
Annex 4: Early Product Evaluations
5.3.3
Deliverable 2

Provide a robust cross-platform, cross-vendor interface to speech synthesis and
speech recognition.

Support integration with other capabilities of the Java platform, including the
suite of Java Media APIs.

Be simple, compact and easy to learn.
Implementations available
The following are the primary mechanisms for implementing the API.
5.3.3.1
5.3.3.2
5.3.3.3

Native implementations: most existing speech technology is
implemented in C and C++ and accessed through platform-specific APIs such as
the Apple Speech Managers and Microsoft's Speech API (SAPI), or via
proprietary vendor APIs. Using the Java Native Interface (JNI) and Java software
wrappers, speech vendors can (and have) implemented the Java Speech API on
top of their existing speech software.

Java software implementations: Speech synthesizers and speech
recognizers can be written in Java software. These implementations will benefit
from the portability of the Java platform and from the continuing improvements
in the execution speed of Java virtual machines.

Telephony implementations: Enterprise telephony applications are
typically implemented with dedicated hardware to support a large number of
simultaneous connections, for example, using DSP cards. Speech recognition and
speech synthesis capabilities on this dedicated hardware can be wrapped with
Java software to support the Java Speech API as a special type of native
implementation.
IBM's "Speech for Java"

Description: Implementation based on IBM's ViaVoice product, which
supports continuous dictation, command and control and speech synthesis. It
supports all the European language versions of ViaVoice -- US & UK English,
French, German, Italian and Spanish -- plus Japanese.

Requirements: JDK 1.1.7 or later or JDK 1.2 on Windows 95 with 32MB, or
Windows NT with 48MB. Both platforms also require an installation ViaVoice
98.
IBM's "Speech for Java" on Linux

Description: Beta version of "Speech for Java" on Linux. Currently only
supports speech recognition.

Requirements: RedHat Linux 6.0 with 32MB, and Blackdown JDK 1.1.7
with native thread support.
Lernout & Hauspie's TTS for Java Speech API

Description: Implementations based upon ASR1600 and TTS3000 engines,
which support command and control and speech synthesis. Supports 10 different
page 58 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
voices and associated whispering voices for the English language. Provides
control for pitch, pitch range, speaking rate, and volume.

5.3.3.4
5.3.3.5
Requirements: Sun Solaris OS version 2.4 or later, JDK 1.1.5. Sun Swing
package (free download) for graphical Type-n-Talk demo.
Conversa Web 3.0

Description: Conversa Web is a voice-enabled Web browser that provides a
range of facilities for voice-navigation of the web by speech recognition and textto-speech. The developers of Conversa Web chose to write a JSAPI
implementation for the speech support.

Requirements: Windows 95/98 or NT 4.0 running on Intel Pentium 166 MHz
processor or faster (or equivalent). Minimum of 32 MB RAM (64 MB
recommended). Multimedia system: sound card and speakers. Microsoft Internet
Explorer 4.0 or higher.
Festival

Description: Festival is a general multi-lingual speech synthesis system
developed by the Centre for Speech Technology Research at the University of
Edinburgh. It offers a full text to speech system with various APIs, as well an
environment for development and research of speech synthesis techniques. It is
written in C++ with a Scheme-based command interpreter for general control and
provides a binding to the Java Speech API. Supports the English (British and
American), Spanish and Welsh languages.

Requirements: Festival runs on Suns (SunOS and Solaris), FreeBSD, Linux,
SGIs, HPs and DEC Alphas and is portable to other Unix machines. Preliminary
support is available for Windows 95 and NT.
5.4
ELAN MIME Message Preprocessing API
5.4.1
Product description
The MIME (Multipurpose Internet Mail Extensions) Message Pre-processing API is
designed to include Elan E-mail Pre-processing in any application using Elan Text to
Speech.
The API provides functionalities concerning the pre-processing, the data access and
the language processing.
The API gives you the possibilities of creating one or more pre-processing channels
and a great flexibility to browse and retrieve the parts of a MIME message.
All these functionalities are embedded in an Active Template Library (ATL), which
provides an interface class
to manage one or more pre-processing channel.
5.4.2
Functionality
The MIME Message Pre-processing API provides the following functionalities:
© 2000 EURESCOM Participants in Project P909-GI
page 59 (84)
Annex 4: Early Product Evaluations

Deliverable 2
extraction of the content of the most significant header fields :
The content of the field is restored in a formatted string according to the
language which applies to it.
Some particulars items contained in these fields (like e-mail address, URLs, date
and hour, etc ..) are translated in a literal “comprehensible” text.

extraction of the different parts of the message : text part or binaries attachments.
The content of a text part is restored, and some particulars items (like e-mail
address, URLs, date and hour,
smileys, etc ..) are translated in a literal “comprehensible” text.
When binaries attachments are inserted , the names of related attached files are
restored except for
AU (audio-basic) type file, for which the content is restored in Mu Law 8Khz
format.
5.5
Automatic Speech Recognition engine: Philips SpeechPearl
The SpeechPearl is available as an easy to integrate software link library ( DLL ), sold
as the SpeechPearl product, currently in version 1.1. SpeechPearl can easily be
integrated into an existing service creation environment and is intended for menuoriented dialogues.
The platform that calls SpeechPearl is supposed to deliver a stream of audio data with
start/stop markers. SpeechPearl supplies an n-best list of recognition result.
Here are some key features provided by this product:

Speaker Independent Technology
SpeechPearl provides Speaker-independent technology.

Continuos Digit and Speech Recognition
SpeechPearl supports Continuous Digit Speech Recognition using whole-word
models, offering the best recognition accuracy for the words in the models.
In addition, SpeechPearl supports Phoneme-based Speech Recognition, enabling the
use of application independent acoustic models.
SpeechPearl allows you to use both technologies in one application simultaneously.

Phonetic-based Recognizer
SpeechPearl supports tri-phoneme based recognition. In addition, they support whole
word model recognition.
SpeechPearl allows you to use both technologies in one application simultaneously.
Switching from whole word to phoneme based recognition is simply done by function
calls to the SpeechPearl API.
page 60 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2

Annex 4: Early Product Evaluations
Talk-over / Barge-in
SpeechPearl and SpeechMania products support barge-in functionality. Its quality
depends on Echo-cancellation technology outside our product, e.g. on an external
DSP.

Mixed Speaker Dependent & Independent capabilities
Speaker dependent and independent technologies, as needed for voice dialing
applications, can be mixed in SpeechPearl product.
5.5.1
SpeechPearl Native API
This is a very short overview of the SpeechPearl Native API.
5.5.1.1
Audio Input
Voice data is made available to SpeechPearl by providing audio data samples for the
SpeechPearl Native API. The figure below shows an example configuration:
SpeechPearl example audio interface configuration
..., audioInStart(), audioInStop(), ...
...,DS_SP_start(), DS_SE_stop(), ...
recognition result
callback
audio input callback
DS_SP_putAudioData,
DS_SP_putEndOfSentence
Audio Interface
SpeechPearl Native API
Audio Device Driver
5.5.1.2
Application Requirements
To be able to use SpeechPearl, your application must provide audio data to put to the
recognizer. This requires an audio interface that can deliver blocks of acoustic
samples. Audio data must be in the form of raw data, 16 bit signed integer, mono.
Because of the multi-threaded nature of SpeechPearl, a SpeechPearl application must
also be built as a multi-threaded executable.
5.5.1.3
Creating an Application
Creating a SpeechPearl application using its Native API requires the following steps:

implementation of an audio input interfacing function, for example, an audio
input callback, providing SpeechPearl with audio data. This step depends on the
audio interface that you are using

implementation of a main program controlling the dialog

implementation of a recognizer event callback retrieving recognition results
when notified
© 2000 EURESCOM Participants in Project P909-GI
page 61 (84)
Annex 4: Early Product Evaluations
Deliverable 2

creation of a run-time lexicon (or multiple lexicons) for the application

creation of the parameter file for your application.
The following sections describe these steps in more detail.
5.5.1.4
Providing Audio Data
Before the first utterance can be processed, SpeechPearl has to be initialized and
started. Note that a SpeechPearl license is required to start SpeechPearl.
The way your application is informed about the availability of audio data depends on
the type of telephony/audio device being used. A block of acoustic samples is passed
to SpeechPearl by the function DS_SP_putAudioData( ). When your audio interface
detects the end of an utterance it must call the SpeechPearl function
DS_SP_putEndOfSentence( ). SpeechPearl passes a handle to the recognition result
to your application using the callback function onRecognitionEvent( ).
Furthermore you have the possibility of switching the context in which your utterance
should be recognized using the function DS_SP_setContext() before starting the
recognition via DS_SP_putAudioData() by specifying a language resource name
defined in the parameter file.
5.5.1.5
Recognizer Event Callback
Using the recognition event callback your application is informed by SpeechPearl
when a recognition result is available. The callback function passes a handle to the
application, which is used to retrieve the result through the function
DS_SP_retrieveResults( ). SpeechPearl provides the ‘n’ best recognition results as
strings.
5.5.1.6
Debugging the Application
You may use the SpeechPearl Tracing facility to debug your application. To switch on
tracing you have to call the function DS_SP_getTraceFlag( ).
5.5.1.7
Lexicon Creation
The lexicon is created by means of the Lexicon Manager. The Lexicon Manager has a
graphical user interface and creates a lexicon out of a word list. In case words are not
found in the background lexicon, Autotranscription is used for transcribing those
words.
5.5.1.8
Parameter File
A parameter file is a textual file containing information required for creating a
SpeechPearl instance. Parameters may only be of type integer, Boolean, or string.
Parameters are identified by a name that conforms to the standard rules for identifiers,
where the name starts with a letter followed by an arbitrary sequence of letters and
digits.
For each language used, the parameter file must contain the string parameter
resourceXName, defining the name of the language, and the path names resourceXLex
and resourceXAmo pointing to the lexicon and to the acoustic model file, respectively.
page 62 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
Where, X is a positive integer number, starting with 0 for the first language, and
consecutively numbered for each language.
The parameter file must also contain the license feature name lmFeatureName, which
the SpeechPearl instance will demand from the license server at start time, together
with the path to the license file, lmSystemLicenseFile.
The parameter nBest is also mandatory and specifies the number of result strings that
are delivered by SpeechPearl after an utterance.
Here is an example of a SpeechPearl parameter file:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; sample.prm: Sample parameter file for SpeechPearl
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Languages:
resource0Name = "testLanguage";
resource0Lex = "/philips/spprl11/sample/sample.lex";
resource0Amo = "/philips/splang/german/generic/amo/ge_tl_3.amo";
; License Management
lmFeatureName
= "SpeechPearl_500";
lmSystemLicenseFile = "/philips/spprl10/system/license.dat";
; Number of best sentence hypotheses:
nBest = 3;
; end of file
5.5.2
Compliance to standards
There is a SpeechPearl version that runs upon the Dialogic CT Media middleware that
is S.100 compliant.
5.5.3
Functionality (related to the reference architecture)
The SpeechCube enables Media Translation for the User Interaction Control, by
converting Speech media to Text media.
5.6
VoiXX
5.6.1
Product Description
VoiXX is an Exchanged-based application running within Exchange Server.
VoiXX replaces the need for multiple systems with a single enterprise-wide unified
messaging system based on Microsoft Exchange. More than just voice-mail and auto
attendant for Exchange, VoiXX turns the existing Exchange environment into a
complete Unified Messaging System.
VoiXX stores all voice messages in the Exchange Server database as any
otherExchange message.
© 2000 EURESCOM Participants in Project P909-GI
page 63 (84)
Annex 4: Early Product Evaluations
Deliverable 2
VoiXX integrates with Exchange through a connector and users can access them
through the usual Outlook interface.
All messages are accessible via computer (Outlook) or telephone.
VoiXX provides single point administration for all voice messaging with Exchange
Server Administration and Management tools. The Exchange directory manages all
addressing for e-mail, voice and other addresses available in each Exchange
installation like fax.
VoiXX can be integrated with most popular PBX and Centrex systems to provide all
of the features traditionally associated with Voice mail systems and more. VoiXX
supports any PBX with in-band signaling, serial interfaces, SMDI including Nortel
Meridian, Panasonic, Lucent, AT&T, Mitel, Siemens, Alcatel, etc.
Because the Windows NT-based Client-Server architecture VoiXX is scaleable.
Example: start with 2 lines, 5 users and 1 VoiXX Server and expand up to 30lines per
Voixx Server, add additional Servers connected to one or more Exchange Servers or
different ones, enabling full functionality for thousands of users. VoiXX supports
analog and ISDN Primary Rate Interface voice boards (Lucent and Dialogic boards).
In addition VoiXX can also be configured with Auto-Attendant features. It can
answer incoming calls, play your company greetings and options, and transfer calls.
The caller can speak with a particular department or call a particular extension. If the
party is not available, a voice message can be left which is routed to the recipient’s
Exchange mailbox.
5.6.2
Features
5.6.2.1
Subscription
USER IDENTIFICATION: Pin Number + Password
UNIQUE TELEPHONE NUMBER FOR BOTH FAX AND VOICE MAIL
E-MAIL ADDRESS
page 64 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
5.6.2.2
Annex 4: Early Product Evaluations
Available Services
E-mail to Phone
E-mail to SMS (Short Message Service)
E-mail to Pager
E-mail to E-mail
E-mail to Fax
Fax to E-mail
Fax to Fax (Store and forward Fax over IP)
Phone to E-mail
Phone to Phone (store and forward voice over IP)
WEB to e-mail
WEB to Fax
WEB to Phone
WEB to SMS
SMS to E-mail
SMS to FAX
SMS to Phone
Fax Forwarding
Phone Forwarding
Notification of message arrival - From any type of message (voice, fax or text-based
e-mail) to any media (phone, fax or PC based e-mail)
5.6.2.3
User Capabilities
Forwarding (from any media to any media)
Notification of message delivery (to any media)
Message Management (priority, address list, etc)
Message Operations (send, receive, forward, reply etc)
Diversion (rules for automatic diversion of messages)
Least Cost Routing (taking benefit of the best Telecom routes based on price and/or
traffic)
Conversion (from several type of messages)
Voice Commands
5.6.2.4
User Access
E-mail PC based client
Web Browser
© 2000 EURESCOM Participants in Project P909-GI
page 65 (84)
Annex 4: Early Product Evaluations
Deliverable 2
Phone
SMS Phone
Fax
Pager
Custom applications
5.6.2.5
Generic Features
A common, enterprise-wide directory for all messages
A single data store for all messages in the server
A single point of administration
A single unified view of messages (fax, voice e-mail)
Ability to send e-mail and fax, receive, reply, forward messages (or notifications) to
any media
Ability to send, forward, or reply by voice, fax or e-mail across LAN, WAN or
Internet
IVR capabilities integrated, with WEB interface
PC, browser and phone access to the unified mailbox
Text-To-Speech delivery of e-mail subject headers or entire body text messages
Voice activated commands in addition to touch tone DTMF control
Voice message playback through PC multimedia or telephone
Voice, Fax, e-mail management using personal folders
5.6.3
Applicable Standards
PSTN Interface - ISDN PRI + Analog
Data transport standard - TCP/IP
Messaging engine - Microsoft Exchange
Operating System - WindowsNT
Fax group 3
Other email Interface
POP3
IMAP4
X.400
Direct connection to
MSMail
CC: Mail
Lotus Notes Mail
Microsoft Exchange
page 66 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
SMS Interface
ETSI SMS protocols
Web Interface
HTTP
Supported Browsers
Netscape
Internet Explorer
Voice format files
ADPCM
.WAV
5.6.4
Technical Specifications
5.6.4.1
VoiXX Server
Hardware
VoiXX Server hardware configuration is dependent on number of users, number of
available lines, available functionalities, etc. A typical configuration could be
described as:
Intel Pentium II-based computer (300 MHz or better), or equivalent.
128MB of memory.
At least 300Mb free disk space (recommended SCSI disk subsystem).
Standard TCP/IP connection to the computer network, over any Windows NT
supported LAN card.
At least one supported voice board.
Software
Microsoft Windows NT Server 4.0 SP3 or later.
Associated Exchange Server connector requires Microsoft Exchange Server 5.0 or
later (Intel platform).
5.6.4.2
VoiXX Client
Hardware
Intel 486-based computer (66 MHz or better), or better with 30 Mb free disk space.
8 MB RAM – (16 MB recommended for Windows 95), or 16 MB RAM – (24 MB
recommended for Windows NT Workstation).
Standard TCP/IP connection to the computer network over any Windows 95/NT
supported LAN card.
Optional - any PC compatible sound device capable of playing WAV files.
© 2000 EURESCOM Participants in Project P909-GI
page 67 (84)
Annex 4: Early Product Evaluations
Deliverable 2
Software
Windows 95, 98, or Microsoft Windows NT Workstation 4.0 or later.
Microsoft Exchange Client 4.0 or later, or Microsoft Outlook 97/98.
5.7
Q.Mail Messaging Server
qmail is an Internet Mail Transfer Agent (MTA) for UNIX-like operating systems. It's
a drop-in replacement for the Sendmail system provided with UNIX operating
systems. qmail uses the Simple Mail Transfer Protocol (SMTP) to exchange messages
with MTA's on other systems.
5.7.1
Product description
qmail was designed for high security (Sendmail has a long history of serious security
problems). High performance, qmail parallelizes mail delivery, performing up to 20
deliveries simultaneously, by default. Strong reliability, once it accepts a message, it
guarantees that it won't be lost. qmail also supports a new mailbox format that works
even over NFS without locking. It is smaller than any other equivalently-featured
MTA.
The official qmail web page, http://pobox.com/~djb/qmail.html covers the advantages
of qmail more extensively.
5.7.2
Features
5.7.2.1
Security
5.7.2.2

Clear separation between addresses, files, and programs

Minimization of setuid code

Minimization of root code
Message construction


5.7.2.3
RFC 822 and RFC 1123 compliant

Full support for address groups

Automatic conversion of old-style address lists to RFC 822 format

sendmail command for compatibility with current user agents
Header line length limited only by memory
SMTP services

RFC 821, RFC 1123, RFC 1651, RFC 1652, and RFC 1854 compliant

8-bit clean

RFC 931/1413/ident/TAP callback--can help track spammers/forgers

Relay control--stops unauthorized relaying by outsiders

Automatic recognition of local IP addresses
page 68 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
5.7.2.4
5.7.2.5
5.7.2.6
5.7.3
Annex 4: Early Product Evaluations

Refusal of connections from known abusers

Relaying and message rewriting for authorized clients
Queue management

Instant handling of messages added to queue

Split queue directory--no slowdown when queue gets big

Quadratic retry schedule--old messages tried less often

Independent message retry schedules

Automatic safe queueing--no loss of mail if system crashes

Automatic queue cleanups
SMTP delivery

RFC 821, RFC 974, and RFC 1123 complaint

8-bit clean

Artificial routing--smarthost, localnet, mailertable

Passive SMTP queue--perfect for SLIP/PPP
POP3 service

RFC 821, RFC 974, and RFC 1123 complaint

RFC 1939 compliant

UIDL support

TOP support

APOP hook

modular password checking
License
qmail can be used for any purpose, unmodified qmail source and var-qmail binary
distributions can be redistributed.
5.7.4
System requirements
qmail will install and run on most UNIX and UNIX-like systems, but there are few
requirements:

About 10 megabytes of free space in the build area during the build.

A complete, functioning C development system including a compiler, system
header files, and libraries.

A few megabytes for the binaries, documentation, and configuration files.
© 2000 EURESCOM Participants in Project P909-GI
page 69 (84)
Annex 4: Early Product Evaluations
5.7.5
Deliverable 2

Sufficient disk space for the queue. Small single-user systems only need a couple
megabytes. Large servers may need a couple gigabytes.

A compatible operating system. Most flavors of UNIX are acceptable.

Access to a domain name server (DNS) is highly recommended. Without one,
qmail can only send to remote systems configured in its smtproutes config file.
Architecture
Internet MTA's perform a variety of tasks. Earlier designs like Sendmail and smail are
monolithic. In other words, they have one large, complex program that "switches
hats": it puts on one hat to be an SMTP server, another to be an SMTP client, another
to inject messages locally, another to manage the queue, etc.
qmail is modular. Each of these functions is performed by a separate program. As a
result, the programs are much smaller, simpler, and less likely to contain functional or
security bugs. To further enhance security, qmail's modules run with different
privileges, and they don't "trust" each other: they don't assume the other modules
always do only what they're supposed to do.
5.8
JavaMail Messaging Client
The JavaMail API provides a set of abstract classes defining objects that comprise a
mail system. The API defines classes like Message, Store and Transport.
5.8.1
Product description
The JavaMail API is designed to make adding electronic mail capability to simple
applications easy, while also supporting the creation of sophisticated user interfaces.
It includes appropriate convenience classes which encapsulate common mail
functions and protocols. It fits with other packages for the Java platform in order to
facilitate its use with other Java APIs, and it uses familiar programming models.
In addition, the API provides concrete subclasses of the abstract classes. These
subclasses, including MimeMessage and MimeBodyPart, implement widely used
Internet mail protocols and conform to specifications RFC822 and RFC2045. They
are ready to be used in application development.
The JavaMail API draws heavily from IMAP, MAPI, CMC, c-client and other
messaging system APIs: many of the concepts present in these other systems are also
present in the JavaMail API. It is simpler to use because it uses features of the Java
programming language not available to these other APIs, and because it uses the Java
programming language’s object model to shelter applications from implementation
complexity.
page 70 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
5.8.2
Annex 4: Early Product Evaluations
Architectural Overview
The javaMail architectural components are layered as shown below:
The layered design architecture allows clients to use the same JavaMail API calls to
send, receive and store a variety of messages using different data-types from different
message stores and using different message transport protocols.
5.8.3
The JavaMail Framework
The JavaMail API is intended to perform the following functions, which comprise the
standard mail handling process for a typical client application:

Create a mail message consisting of a collection of header attributes and a block
of data of some known data type as specified in the Content-Type header
field.

Create a Session object, which authenticates the user, and controls access to
the message store and transport.

Send the message to its recipient list.

Retrieve a message from a message store.

Execute a high-level command on a retrieved message.
© 2000 EURESCOM Participants in Project P909-GI
page 71 (84)
Annex 4: Early Product Evaluations
Deliverable 2
This figure illustrates the JavaMail message-handling process.
5.8.4
Major JavaMail API Components
5.8.4.1
The Message Class
The Message class is an abstract class that defines a set of attributes and a content
for a mail message. Attributes of the Message class specify addressing information
and define the structure of the content, including the content type. The Message
class adds From, To, Subject, Reply-To, and other attributes necessary for
message routing via a message transport system.
5.8.4.2
Message Storage and Retrieval
Messages are stored in Folder objects. A Folder object can contain subfolders
as well as messages, thus providing a tree-like folder hierarchy. The Folder class
declares methods that fetch, append, copy and delete messages. A Folder object
can also send events to components registered as event listeners. The Store class
also specifies the access protocol that accesses folders and retrieves messages stored
in folders (IMAP4, POP3 etc.)
5.8.4.3
The JavaMail Event Model
The JavaMail event model conforms to the JDK 1.1 event-model specification.
Clients listen for specific events by registering themselves as listeners for those
events. Events notify listeners of state changes as a session progresses. During a
session, a JavaMail component generates a specific event-type to notify objects
registered as listeners for that event-type. The JavaMail Store, Folder, and
Transport classes are event sources.
page 72 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
6
Annex 4: Early Product Evaluations
Telefonica Product Evaluation
In this document a set of evaluated products is presented.
These products are usable for service scenarios that have been defined within the
scope of the P909 project. Particularly these products will be in use for the Telefónica
I+D in-house test.
These products cover (fully o partially) the needed functionalitie for the performance
of the Meeting Scheduler service. In the following table the functionalities and the
products are itemised.
FUNCTIONALITY
PRODUCT
Directory server
Netscape Directory Server
Web Server
Netscape Web Server
Call control

Vocal Gateway
CISCO AS5300 H323 Gateway

Vocal Gateway Wrapper
OpenH323 protocol stack
User interface
Microsoft Netmeeting SDK
6.1
Netscape Directory Server
6.1.1
Product description
A directory service is a distributed database application designed to manage the
entries and attributes in a directory. A directory service also makes the entries and
attributes available to users and other applications. The Netscape Directory Server
offers a directory service based on an open-systems server protocol called the
Lightweight Directory Access Protocol (LDAP). The directory server is a robust,
scalable server designed to manage an enterprise-wide directory of users and
resources. Using the directory server, all user information can be managed from a
single point of control, while this information can be retrieved from multiple, easily
accessible network locations.
6.1.1.1
Compliance to standards
LDAP, or the Lightweight Directory Access Protocol, was invented to preserve the
best qualities offered by DAP ISO standard while reducing the administrative costs.
LDAP provides an open directory access protocol running over TCP/IP. It retains the
X.500 data model and it is scalable to a global size and millions of entries for a
modest investment in hardware and network infrastructure. The Netscape Directory
Server supports LDAP versions 2 and 3.
The directory server uses the LDAP Data Interchange Format (LDIF) to describe a
directory and directory entries in text format. In this way, the Netscape Directory
Server can import entries from other directory servers and so export them.
© 2000 EURESCOM Participants in Project P909-GI
page 73 (84)
Annex 4: Early Product Evaluations
6.1.1.2
Deliverable 2
Scalability
The Netscape Directory Server supports the use of replication and referrals.
Replication is the mechanism by which directory data is automatically copied from
one directory server to another. Using replication, is possible to copy entire directory
trees between servers. Updates of any kind - entry additions, modifications, or even
deletions - are automatically mirrored to other directory servers using replication.
Referrals are a redirection mechanism that are supported by the LDAP protocol. If the
client requests a directory entry that cannot reside on the local server, then a referral
is returned. If the client is attempting to modify an entry that is supplied to the local
server by some other directory server, the consumer server returns a referral that
indicates which server mastered the entry. The client can then follow the referral back
to the supplier server and attempt the modification operation there.
6.1.2
Functionality (related to the reference architecture)
A directory consists of entries containing descriptive information. For example, a
directory might contain entries describing people or terminals, such as telephones or
PCs. The descriptive information is stored in the attributes of the entry. Each attribute
describes a specific type of information. For example, attributes describing a person
might include the person’s name (common name, or cn), telephone numbers, or email
address. This allows the location/identification of users via nicknames.
6.1.3
Tests description
To test the Netscape Directory Server performance, a directory instance was created.
Linking this instance with Nestcape’s Administration Server and using the Web
interface provided by the latter to manage users and groups as well as the LDIF
importing facility of the directory server some entries were added to the directory.
The directory structure offered by the Administration Server (based on user entries
with limited attributes, organizational unit entries and group entries to which the
defined users can belong) is not appropriate to represent the information needed for
the target service, but provided an easy way to test the characteristics of the server.
The Netscape Directory SDK 3.0 for Java was the API chosen to implement some
client applications that access the directory server . Read only accesses where
performed to retrieve the information stored in the instance previously created.
6.1.4
Results/Tests Evaluations
The result of the tests convey that Netscape Directory Server can be used as directory
server in the experimental scenario.
6.2
CISCO AS5300 H323 Vocal Gateway
6.2.1
Product description
The AS5300 a member of Cisco's award winning AS5x00 family of universal access
servers. The AS5300 raises the bar for performance in high-traffic, real world
environments by providing the ability to terminate ISDN and 56K Analog Modem
calls on the same interface.
page 74 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
The Cisco AS5300 delivers near line-speed performance for as many as 240
concurrent analog modem calls and ISDN B channels over a single dial-in telephone
number. It incorporates high-performance, reduced instruction set computing (RISC)based processing with high-density Modem ISDN Channel Aggregation (MICA™)
technologies.
The Cisco AS5300 universal access server is intended for telecommunications
carriers and other service providers, as well as large enterprises that require consistent
high-density connectivity for subscribers and telecommuters connecting to the
Internet and corporate intranets.
This Voice over IP feature implements high-density voice support on the Cisco
AS5300 by using DSPM-549 digital signal processor (DSP) modules. When equipped
with Voice Feature Cards (VFCs) and voice-enabled Cisco IOS software, the
AS5300/Voice Gateway supports carrier-class VoIP and FAX over IP services.
High-density voice support increases the voice capacity of a Cisco AS5300 up to 120
channels. This increase in voice support provides the voice density of up to four T1
lines (96 voice or FAX calls) or four E1 lines (120 voice or FAX calls).
A fully configured voice-capable Cisco AS5300 router includes two voice carrier
cards, each capable of supporting 60 concurrent sessions.
6.2.1.1
Technical specifications
Operating System: CISCO IOS in different versions (IOS 12.0 in the evaluated
equipment)
Processor: AS5300 Processor (RISC) 150 MHz
DSP:
Ethernet connection: 1 IEEE 802.3 10BaseT and 1 100BaseT with 1RJ45 connector
each
T1/E1 Interfaces: up to 4 E1 Trunk interface R1-MFC or PRI ISDN E1 (Euro ISDN)
supporting up to 120 voice channels with 4 RJ48C
COM Port 1: RS-232 interface to connect to the system console
6.2.1.2
Setup cabling and software requirements
Ehternet connections: 1 IEEE 802.3 10BaseT and 1 100BaseT with 1RJ45 connector
each
System console: an ASCII terminal connected through an RS232 null modem
PSTN interface: one to four E1 facilities from a carrier provider (RJ48C connector)
Power supply: 220-240 volt AC power outlets
Additional software: Microsoft NetMeeting 2.1 (or 3.0 for Gatekeeper enabled
function) for PC-to-POTS and POTS-to-PC call support
© 2000 EURESCOM Participants in Project P909-GI
page 75 (84)
Annex 4: Early Product Evaluations
6.2.1.3
Deliverable 2
Scalability
Each Voice over IP enabled AS5300 Access Server supports up to 120 concurrent
calls at the same time through an E1 interface
6.2.1.4
Openness and Interoperability
It lacks a programmable API.
All the configuration is made by means of a text based user interface that allows a
wide degree of possibilities.
It does not support the MGCP protocol (though intended for the future).
It is H323 v2 compliant. Its interoperability has been tested against the NetMeeting
2.1 client.
It can be configured to work with an H323 Gatekeeper.
6.2.1.5
Compliance to standards
Coders: (In tested equipment) G721 Alaw and G.721 Mlaw
Network layer protocols: H323 on top of TCP: H225, H245, RTP, RAS
6.2.2
Functionality (related to the reference architecture)
The AS5300 Network Access Server with VoIP feature (VoIP gateway) can be use to
provide POTS to IP networks interconnection, as it allows:

POTS to PC calls

PC to POTS calls
It also allows POTS to POTS calls traversing an IP network, though this feature is less
important for the scope of the services that are being defined in the P909 project.
Anyway it is important to highlight that for this kind of communication, the protocol
between the involved gateways is also H.323 thus making it possible to establish calls
from a phone to a PC.
There are no detected interoperability problems for the POTS part (phone to gateway
and vice versa) of the communication, though during the configuration problems
where found in the Q.931 setup process between the equipment and the switch that
were finally solved.
For the VoIP terminal part (PC to gateway) the equipment has been successfully
tested with a NetMeeting 2.1 client and with the OpenH323 Voxilla Client for
Windows 95. It has been unsuccessfully tested with the IBM java client and the Intel
Internet VideoPhone due to problems with the call setup.
It can also work with a gatekeeper using the RAS protocol. It has been successfully
tested working with the OpenH323 gatekeeper.
It lacks an API thus limiting the possibilities of its use, but anyway it is possible to
use it for services in which voice communications from the POTS world to the PC
world are needed. Using it in conjunction with a gatekeeper multiplies the
possibilities of configuration.
page 76 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
6.2.3
Annex 4: Early Product Evaluations
Tests description
The performed tests were the following:
6.2.3.1

Voice over IP feature configuration

PC to Phone communication

Phone to PC communication
Voice over IP configuration
In order to test the equipment the gateway was connected to a in-house switch with a
PRI ISDN link (Euro ISDN) and to the laboratory LAN with the 10BaseT ethernet
port.
It was configured to work with a named gatekeeper (the default configuration finds a
gatekeeper asking with multicast).
In the gateway the basis for the configuration is the definition of dial-peers that define
a trigger pattern and treatment parameters for the configuration.
A set of dial-peers where configured, some for PC-to-POTS communication and some
for POTS-to-PC communication.
6.2.3.2
PC to Phone communication
Once the gateway had been configured it was tested with calls from the PC to the
phone.
Four different clients were used for the PC: Netmeeting 2.1, IBM java client, Intel
Internet Videophone and OpenH323 Voxilla client .
6.2.3.3
Phone to PC communication
Calling from a PC to a phone trough the gateway. Microsoft Netmeeting 2.1 was
installed in the called PC.
6.2.4
Results/Tests Evaluations
6.2.4.1
Voice over IP configuration
The configuration possibilities are well documented, though the documents are
somehow disperse.
The configuration interface is test based and is sometimes uncomfortable to use.
In the early attempts to configure it was impossible to get duplex PC-phone
communication. After multiple configurations attempts the operating system was
upgraded to IOS 12.0 and everything worked cleanly.
6.2.4.2
PC to Phone communication
The main problem testing the PC to Phone communication was solving the Q.931 call
setup problem between the gateway and the switch in our test lab. There was a
required field in the Q.931 Setup message (the calling party number) that was not
© 2000 EURESCOM Participants in Project P909-GI
page 77 (84)
Annex 4: Early Product Evaluations
Deliverable 2
send from the gateway. It was finally found a way to solve this problem forcing in the
gateway configuration to send always this required field.
When the call was finally possible the resulting quality was similar to the SGM, with
a slight delay. Due to the silence detection there are problems of sample losses at the
beginning of the periods after the silence detection, that are appreciable.
6.2.4.3
Phone to PC communication
It was impossible with the IOS 11.3 operating system. When it was upgraded to the
12.0 it worked.
The same remarks related to quality are applicable.
6.3
Microsoft Netmeeting SDK
6.3.1
Product description
The Microsoft NetMeeting 2.1 Software Developers Kit (SDK) provides application
programming interfaces (APIs) that enable authors and developers to integrate
conferencing capabilities into other applications using C, C++, or Visual Basic.
In addition, the NetMeeting SDK includes an ActiveX™ control for conferencing,
which Web site creators can use with ActiveX Scripting solutions (such as J Script and
Visual Basic Scripting Edition) to add conferencing functionality directly to their Web
sites.
The key features of the NetMeeting 2.1 SDK include:

A Component Object Model (COM) interface that enables developers to add
NetMeeting functionality to their applications, manage calls, replace the
NetMeeting User Interface, and write applications that work within a NetMeeting
conference.

A complete Lightweight Directory Access Protocol (LDAP) client API for
accessing all the capabilities of the Internet Locator Server (ILS) directory used
by NetMeeting.

Application developers can use the client API for NetMeeting applications or for
any Application in need of the dynamic storage facilities provided by ILS servers.

Codec installation for enabling vendors of audio and video codecs to install their
products, and for making NetMeeting leverage them in calls.
page 78 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
Figure: Netmeeting Architecture
The Netmeeting SDK allows using the Microsoft NetMeeting conferencing API,
shown in orange in the figure above. Developers can then take advantage of the
functionality provided at lower layers, including, optionally, the NetMeeting user
interface.
6.3.1.1
Requirements
The NetMeeting SDK runs only on Windows 95 or later and Windows NT 4.0 or
later.
To run an application that uses the Microsoft NetMeeting SDK, NetMeeting 2.0 or
later must be installed in the user’s computer.
To implement application sharing on Windows NT 4.0, Service Pack 3 and the
application sharing driver must be installed.
The NetMeeting control is implemented as a custom control called the ActiveX™
Conference Control. To use the control in an application, the NetMeeting application
must be installed on the user’s computer.
6.3.1.2
Compliance to standards
NetMeeting features support for industry standards set by the International
Telecommunications Union (ITU) and the Internet Engineering Task Force (IETF), as
well as other standards organizations. Among the standards NetMeeting supports are
the follwing:

ITU T.120:
NetMeeting contains a wealth of collaborative data capabilities, including Chat,
Whiteboard, file transfer, and program sharing. The ITU T.120 standard
provides the protocols for establishing and managing NetMeeting data flow,
connections, and conferences.

ITU H.323:
NetMeeting includes audio and video codecs, as well as framing and call control
protocols. H.323 codecs provide the format for the audio and video that is
transmitted over various connection rates. NetMeeting supports a suite of H.323
audio and video codecs for many different modes of Internet telephony.
© 2000 EURESCOM Participants in Project P909-GI
page 79 (84)
Annex 4: Early Product Evaluations
Deliverable 2
ITU H.323 protocols enable NetMeeting to send and receive audio and video
information between NetMeeting and H.323-compatible nodes.

IETF LDAP:
Directory services for NetMeeting use the LDAP standard. Microsoft Internet
Locator Servers (ILSs) utilize the LDAP interface to create directories of current
NetMeeting users that people can call and communicate with over TCP/IP
connections.
6.3.2
Functionality (related to the reference architecture)
The Netmeeting SDK provides a way to develop applications that will act as VoIP
terminal in Windows 95/98/NT based computers. These applications will in fact be
customizations of Microsoft Netmeeting, either via a different graphic user interface
or a reutilization of its interface but configuring the features offered by it.
It can also provide the means of including audio conferencing facilities in Web pages
via the use of ActiveX controls, but it requires the use of Internet Explorer as HTTP
client to do so.
A shortcoming that appears in the use of Netmeeting as a VoIP terminal in a PC to
phone call is that it is not possible to indicate the calling-party number in the Q.931
setup messages, a feature that could be very useful for the providing of several
services.
6.3.3
Tests description
None
6.3.4
Tests result/evaluation
None
6.4
OpenH323 Protocol Stack
6.4.1
Description of the product
OpenH323 is a project committed to the collaborative development of an Open
Source H.323 protocol stack that is available for use by both private and commercial
users. It was started in September 1998 by Equivalence Pty Ltd, a private company
based in Australia.
It provides an H323 protocol stack in source code (C++). It has the H225, H235 and
H245 protocols implementations.
It is provided in source code and has been tested for Windows and Linux platforms. It
has also been compiled for Solaris.
The audio codecs that are bundled with the code are G.711 and GSM, so that they are
not covered by patent restrictions.
A test program (voxilla) that interoperates with Netmeeting versions 2 and 3 is
provided
Currently the version is coded 0.8alpha1.
page 80 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
6.4.1.1
Annex 4: Early Product Evaluations
Technical specifications
Programming language: C++
Operating systems: Linux, Windows 95/98/NT, Solaris
API: Source code provided, The class definition has been designed to use
specialisation to treat common protocol needs.
Documentation: No good documentation is provided
6.4.1.2
Compliance to standards
H323: H225/H235/H245
Codecs: G.711/GSM
6.4.2
Functionality (related to the architecture)
It provides the H323 protocol stack. It can be used for the call control H.323 wrapper
to control H323 endpoints (either gateways, MCUs or terminals).
It provides also the RAS stack, so that it can also be used to build a gatekeeper.
6.4.3
Tests description
The following tests were performed:
6.4.3.1

Building of the libraries and executables from the source code.

Testing of the resulting test application.

Creation of a H225 proxy application.
Building from the source code
The source code was build in Windows 95 and Solaris environment.
There is a mailing archive and an active distribution list for the support.
Two version of the product were built: 0.5 and 0.8alpha1
6.4.3.2
Testing of the resulting test application
The generated test application were tested against a Netmeeting 2.1 client.
6.4.3.3
Creation of a H225 proxy application
Using the provided API a H225 proxy was created that could act between two H323
endpoints just decoding and re-sending the H225 messages, and establishing the basis
for the H235 negotiation between the two endpoints.
© 2000 EURESCOM Participants in Project P909-GI
page 81 (84)
Annex 4: Early Product Evaluations
6.4.4
Tests results/evaluations
6.4.4.1
Building from the source code
Deliverable 2
For the Windows 95 environment it built easily and with no remarkable problems
For the Solaris environment there were problems that made necessary to modify the
source code to correct them. The modifications were needed because of the different
operating system libraries that had different function prototypes.
6.4.4.2
Testing of the resulting test application
For version 0.5alpha:

On Windows 95: No full duplex communication available. The Netmeeting side
could talk and be heard, but not he other way around

On Solaris: Same situation but no sound output. According to the traces there
were packets coming but it was impossible to take the device to the application.
For version 0.8alpha1
6.4.4.3

On Windows 95: Full duplex communication.

On Solaris: Same situation as for 0.5alpha version. No real communication.
Creation of a H225 proxy application
It was not difficult to build the application once the API was deducted from the source
code, that is well commented.
The design of the application involved the building of two endpoints, one for each
side of the proxy communication and passing the H225 messages between the two of
them. On every PDU it was possible to define a trap method that allowed an special
treatment for each of them.
6.5
OpenH323 Gatekeeper
6.5.1
Description of the Product
It is a gatekeeper based on the OpenH323 H323 protocol stack. It is a RAS compliant
and allows registration of endpoints and bandwidth control.
6.5.1.1
Technical specifications
Programming language: C++
Operating systems: Linux, Windows 95/98/NT, Solaris
API: Source code provided, The class definition has been designed to use
specialisation to treat common protocol needs.
Documentation: No good documentation is provided
6.5.1.2
Compliance to standards
H323: RAS
page 82 (84)
© 2000 EURESCOM Participants in Project P909-GI
Deliverable 2
Annex 4: Early Product Evaluations
LDAP
SNMP management is being added
6.5.2
Functionality (related to the architecture)
It is another element involved in VoIP communications that can be controlled from
the reference architecture (specially from the call control component).
It can also work together with the Call Control to provide a finer grain control of the
communications (address translation and bandwidth control).
In the status it has right now it is only useful for testing purposes, as it doesn't really
have a powerful user registry or QoS control.
Anyway it can be useful for address translation and channel control.
6.5.3
Tests description
The following tests were performed:
6.5.3.1

Building of the application

Testing of the application in a VoIP environment.

Modification of the application for address translation.
Building of the application
It was built in a Solaris machine from the source code and the OpenH323 libraries
that were previously built.
6.5.3.2
Testing in a VoIP environment
With the Voxilla VoIP client calls were made, using both the multicast gatekeeper
search and a named gatekeeper option
6.5.3.3
Address translation
A new application was made modifying the behaviour of the application for a
LocationRequest PDU (LRQ), making it look in a configuration file with rules for
translation.
6.5.4
Tests results/evaluation
6.5.4.1
Building of the application
It built without problems
6.5.4.2
Testing in a VoIP environment
In both cases the application sent the correct sequence of PDUs answering the
terminals and allowing the communication when enough bandwidth was available.
© 2000 EURESCOM Participants in Project P909-GI
page 83 (84)
Annex 4: Early Product Evaluations
6.5.4.3
Deliverable 2
Address translation
It was possible to built the application. No functionality test was made as it was not
possible to find a client sending a LocationRequest to the gatekeeper.
page 84 (84)
© 2000 EURESCOM Participants in Project P909-GI