mediabuilder: a next-generation multimedia service creation and deployment platform

Bell Labs Technical Journal ◆ April–June 1999 57

IntroductionThe rapid increase in bandwidth availability and

the advances in multimedia computing enable the

deployment of a wealth of new applications such as

teleshopping, teleconferencing, and video on demand.

Businesses get access to new applications that will

facilitate collaboration independent of distance,

expecting to increase productivity in the emerging

global economy. Although many of these exciting

new services will enter our workplaces and eventually

our living rooms, service providers and manufacturers

are faced with huge challenges. It is clear that end

users will require flexibility in service provisioning,

speed, and quality of service; however, definitive

requirements are not available. As a consequence, ser-

vice providers and manufacturers face unknowns in

several areas:

• Applications/end-user services,

• Network and multimedia standards, and

• Hardware platforms and operating systems/

environments.

The challenge is to design products that easily adapt to

and fully exploit the ongoing developments in these

areas. Application software development needs to

evolve independently of network technology and

operating systems. Distributed systems are applying

standard programming interfaces and protocols to

help facilitate heterogeneity in operating systems, net-

works, and hardware devices. Platforms implementing

these interfaces and protocols are often described with

the term middleware.1

Initiated in the PLATINUM project2 and contin-

ued in the MESH project,3 a middleware platform

called MediaBuilder was developed, aiming to fulfill

the requirements mentioned above. The initial plat-

form mainly targeted the enabling of multimedia ser-

vices provisioning over asynchronous transfer mode

(ATM) networks. At the time, ATM was considered

the long-term ubiquitous networking protocol that

would be the end-to-end interconnection medium of

choice. ATM has many desirable features such as

guaranteed quality of service (QoS) and dynamic con-

nection management. During the course of the

♦ MediaBuilder: A Next-Generation MultimediaService Creation and Deployment PlatformFrank V. Baumann

The main driving force for customer acceptance of next-generation networks will bethe availability of new and yet unknown multimedia services. The MediaBuilder plat-form fulfills this need by offering rapid service creation and deployment through anextensible set of service components. Initially, the platform was designed with theassumption of an asynchronous transfer mode (ATM) signaling-based telecommunica-tions future. During its development, however, the Internet protocol (IP)-basedInternet became much more influential, creating a need to evolve the MediaBuilderplatform into a universal next-generation service creation and deployment platformsupporting all underlying network technologies and services. This paper describes theevolution of the MediaBuilder platform. It outlines the initial ATM signaling-basedapproach and presents the rationale for the final approach along with its architectureand design. Finally, it evaluates the Mediabuilder platform based on practical experi-ence with a prototype used within a number of pilot settings.

58 Bell Labs Technical Journal ◆ April–June 1999

project, however, the vision changed into a future

with a much more heterogeneous end-to-end inter-

connection. Advances in Internet technology made it

clear that the transmission control protocol

(TCP)/Internet protocol (IP) used for networking was

also going to be used for provisioning of high-

bandwidth connections, possibly with some form of

guaranteed QoS. Due to these occurrences, the focus

of the MediaBuilder development was moved toward

provisioning of services over heterogeneous networks

and support of guaranteed QoS wherever possible.

In the next section, we present the initial ATM-

based approach, outline its shortcomings, discuss its

evolution, and present the resulting configuration. The

following section describes the MediaBuilder internal

architecture. MediaBuilder is divided into three subsys-

tems, namely, session management, media realization,

and application engineering. A subsequent section gives

an overview of the software design of MediaBuilder. A

brief explanation of the underlying design concept of

design patterns4 is given, followed by an overview of ses-

sion model interfaces and medium realization imple-

mentation. The next section gives an overview of the

practical experience in using the MediaBuilder platform

in a pilot setting. The final section presents conclusions

and future plans for MediaBuilder.

Initial Approach and EvolutionThe initial MediaBuilder platform, developed

within the PLATINUM project, is described in detail by

Baumann and Ouibrahim.5 At the time, it was

assumed that ATM would become the future network

standard and that service provisioning would be done

in a network-centric way. The intelligence would be

found mainly inside the network (call processing), and

the terminals would be relatively dumb, as in the cur-

rent telephony network. This section gives a brief

overview of the initial approach, discusses the reasons

for its evolution toward a more TINA-like6 approach,

and gives an overview of the resulting platform.

Figure 1 shows the initial target network configu-

ration. Within the client domain (that is, the end-user

terminal), we see a protocol stack containing the ATM

layer and the ATM adaptation layer (AAL) at the lower

end. For the session control part, the Q.2931 protocol7

was extended with multiparty and multimedia capabil-

ities,8 resulting in the Q.2931ext. protocol. Above the

Q.2931ext. protocol layer we find the call handler

layer, which has the task of converting the complex

Q.2931ext. protocol messages into more high-level,

session-object-oriented messages that are in turn used

by the control part of MediaBuilder. MediaBuilder also

interfaces directly with the AAL layer for exchange of

user (stream) data. Above the MediaBuilder layer we

find the application layer, where client applications

run. These applications present the services (for exam-

ple, teleconferencing and teleshopping) provided by

the call processing residing in the provider domain to

the end user via a graphical user interface. Note that

the Q.2931ext. protocol data between the client and

the provider domain is also transported over the

AAL/ATM layers. For clarity, the figure shows only the

functional information flow for control data.

Panel 1. Abbreviations, Acronyms, and Terms

AAL—ATM adaptation layerAPI—application programming interfaceATM—asynchronous transfer modeCBR—constant bit rateDLL—dynamic linked libraryGUI—graphical user interfaceIP—Internet protocolJPEG—Joint Photographic Expert GroupMESH—multimedia services on the electronic

superhighway, a project based in theNetherlands that focused on the develop-ment of middleware for multiparty multi-media applications

MOT—MediaBuilder object typePLATINUM—a project that delivers multiparty

multimedia applications built atop aGlobeView® ATM switch

PVC—permanent virtual connectionQ.2931—network layer protocolQoS—quality of serviceSSM—service session managerSVC—switched virtual connectionTCP—transmission control protocolTINA—telecommunications information net-

working architectureUNI—user network interfaceVBR—variable bit rate


Inside the provider domain, we find the termina-

tion of the Q.2931ext. protocol, the call processing

software, and the ATM connection management mod-

ule, which controls the setup and teardown of perma-

nent virtual connections (PVCs) in the ATM switch.

Call processing is based only on information contained

in the Q.2931ext. protocol; in the network, we do not

see the sessions in the same way as in the

MediaBuilder layer in the client terminals. Services are

provided by the call processing layer.

The initial approach has the advantage that, in

principle, call processing in the network is indepen-

dent of developments in the MediaBuilder and appli-

cation layers. Services are offered by call processing,

and the MediaBuilder and application layers deal only

with the representation of these services toward the

end user. In this way, MediaBuilder terminals can also

interoperate with all terminals supporting the

Q.2931ext. protocol.

Eventually, however, several serious drawbacks

were found in this approach:

• The introduction of new services requires the

extension of the call processing software and,

regularly, the extension of the Q.2931ext. pro-

tocol as well, since the protocol carries all the

service-specific parameters.

• A model of the current sessions is maintained

inside both the MediaBuilder layer and the call

handler/call processing layer, containing essen-

tially the same information.

• The extension of this architecture to other net-

work types is impossible because of the ATM

and Q.2931ext. dependency.

• There is no possibility for third-party service

providers to provide services; only the network

operator is able to do so. This is because call

processing is a monolithic entity.

For these reasons, the Q.2931ext.-based approach

was dismissed and a new session control protocol that

interfaces directly with the MediaBuilder layer was

developed. Inside the provider domain, the architec-

ture was changed in several ways. The tasks per-

AAL – ATM adaptation layerAPI – Application programming interfaceATM – Asynchronous transfer mode

I/F – InterfaceQ.2931ext – Extended network layer protocol

Provider domainClient domain

Application

MediaBuilder

AAL

ATM

Call handler

Q.2931ext

Q.2931ext I/F

ATM streams

Call processing

Q.2931ext

GenericATM

connectionsAPI

ATMconnectionmanager

ATMswitch

Operational interfaceStream interface

Figure 1.Initial network configuration.


formed by call processing were split into three separate

functional modules: the user agent, the service session

manager, and the communication session manager.

The service factory module has only the task of creat-

ing new service session managers on request. The task

of the user agent module is the registration of clients.

It is used by the service session managers to locate

clients in the network. A service session manager

(SSM) provides the network services and manages a

single session; each time a new session is started, a

new SSM is created by the service factory. The SSM

builds on top of the MediaBuilder platform, which

provides the basic functionality for session control. By

specializing the basic SSM, new services can be intro-

duced in the network (also by third-party service

providers). The communication session manager con-

trols the low-level network-oriented aspects of the

user data transport. It serves as an interface between

the SSM and specific network connection managers.

In the case of native ATM, its task is to request ATM

connections via the ATM connection manager and

map the responses containing ATM endpoints back to

the SSM’s session model.

Another important change allowing for the provi-

sioning of services over any network type is the de-

coupling of connection management from session

control. In case ATM with PVCs is still used as the

transport medium, connection management is per-

formed by a centralized ATM connection manager as it

had been in the initial approach. If other network

types (such as TCP/IP or ATM with user network

interface [UNI]/switched virtual connections [SVCs])

are used as the transport medium, the connection con-

trol is not performed in a centralized way but in a dis-

tributed way by the MediaBuilder instances in the

client terminals. The design was heavily influenced by

the TINA6 architecture—useful concepts and ideas

were used, but at this moment the platform is not

TINA compliant. The platform is being further devel-

oped toward full TINA compliance. Figure 2 is a dia-

gram of the new network configuration.

MediaBuilder ArchitectureThe MediaBuilder platform has been developed as

a service creation and exploitation platform. Some of

these tasks are fulfilled by providing standard pro-

gramming interfaces to the application software.

Besides bridging the gap between the applications and

the network, MediaBuilder also serves other purposes.

MediaBuilder hides the characteristics, the interface,

and the internal structure of the network from the

application. It also hides terminal-specific characteris-

tics such as video and audio boards. In order to deal

with the complexities inherent in large systems,

Mediabuilder has been divided into several parts.

These parts form a collection of loosely-coupled sub-

systems that are connected using well-specified inter-

faces. The behavior of generic components in

MediaBuilder can be specialized and overloaded. For

this means, the platform offers a set of tools to facili-

tate the work of application software developers,

thereby ensuring reusability, flexibility, open-endedness,

extensibility, and scalability.

MediaBuilder provides a collection of subsystems,

each of which provides specific services. The subsystem

services visible to users (through graphical user inter-

faces) are session management and application engi-

neering. Although most end users will interact only

with session management, application engineering ser-

vices allow the configuration and assembly of applica-

tions without a need for programming. Media

realization is a third key subsystem responsible for user

data traffic management and routing to the appropriate

devices. These components are depicted in Figure 3

and discussed in more detail below.

The key features of MediaBuilder are:

• Provisioning of multiparty/multimedia

sessions;

• Support for multipoint-to-multipoint commu-

nication over both multicast and unicast net-

works;

• Session server support (for example, a video-

conferencing bridge with video mixing); and

• Support for downloadable applications and

application extensions.

Session ManagementToward the application running in the client

domain (and so, indirectly, toward the end user), ses-

sion management provides an interface to request the

setup, modification, and teardown of calls. Toward the


network, it offers an interface that passes these

requests via service elements toward the service fac-

tory and the service session manager and receives

replies on these requests. Session management sup-

ports setup/release of conferencing sessions,

addition/deletion of other participants, addition/

deletion of media, control of participant involvement

in different media, and setting of user rights. A session

can be saved (suspended) and resumed at a later time.

Conference templates allow users to preconfigure a

particular session (containing participants and media)

so that it can be activated in a single action. A simple

directory service (white pages) allows users to be

located by name.

A session is represented by a session model

(SessionModel) based on work done within the

European MAGIC project.9 The SessionModel forms

AAL – ATM adaptation layerAPI – Application programming interfaceATM – Asynchronous transfer modeCSM – Communication session managerI/F – InterfaceIP – Internet protocol

Provider domainClient domain

Application

MediaBuilder

AAL

ATM

UA I/F

ATM streams

ATMconnectionmanager

ATMswitch

TCP/IP

SF I/F Servicefactory

Useragent

creates

SSM

MediaBuilder

SM I/F

CSM I/F

CSM

GenericATM

connectionsAPI

SF – Service factorySM – Session managementSSM – Service session managerTCP – Transmission control protocolUA – User agent

Operational interfaceStream interface

Figure 2.New network configuration.

Application

Mediarealization

Sessionmanagement

Network

Applicationengineering

Figure 3.MediaBuilder components.


the heart of the session management subsystem.

Application developers do not need to concern them-

selves with the activation of multimedia realization

components, since this is handled internally by

MediaBuilder based on settings in its configuration

files (see the “Application Engineering” section below).

The basic SessionModel is a graph of session objects

with the class structure depicted in Figure 4.

At the top level is the session (Session). A ses-

sion maintains a list of parties (Party)—that is,

users—and media (Medium)—for example, audio or

video—involved in the session. A third object

(PartyMediumEdge) maintains the participation state

for each Party associated with a Medium. Medium

embodies attributes common to all Party objects

sharing it. PartyMediumEdge represents aspects that

are local to each Party with respect to that Medium,

such as permissions and send/receive directivity.

Another way of viewing this part of the model is as a

matrix of Medium and Party objects, where cells rep-

resent PartyMediumEdge objects. This is how the

user is expected to view the sessions via a graphical

user interface (GUI). Session, Call, Party,

Medium, and PartyMediumEdge embody a user QoS.

The lower part of the SessionModel embodies a

communication QoS. The class Association holds

attributes for the type of application protocols

negotiated—for example, encoding formats for data

streams. An Association object has a one-to-one

relationship with an actual network connection (point-

to-point or point-to-multipoint). The class Connection

holds attributes related to transport endpoint

connections such as transport protocols, bandwidth,

and local ports. This class is specialized for different

transport protocols such as AAL/ATM or TCP/IP.

PartyAssociationEdge denotes the participation sta-

tus of a Party in an Association. Many different

connection topologies (meshed point-to-point, multicast,

and multipoint-multipoint) can be modeled using

Associationand PartyAssociationEdgecombinations.

Figure 4 also shows the classes constituting a

MediumProfile—that is, Medium, Association,

and Connection. The concept of MediumProfile

was introduced to facilitate the mapping of the user

QoS parameters to the communication QoS parame-

ters (that is, bearer characteristics). The user is able to

select a given preconfigured medium with a specific

QoS without having to bother with the technical

aspects. For video, for instance, a user will only have

to specify high-, medium-, or low-quality video. Users

(or applications) might, however, choose to disregard

the MediumProfile mechanism and specify all ses-

Session1 1

PartyMediumEdge PartyMedium

Association

n

1

n

Connection

User QoS

Communication QoS

MediumProfile

n

QoS – Quality of service

PartyAssociationEdge

1

1

Figure 4.Basic SessionModel showing MediumProfile bundling.


sion objects in the call themselves, in this way taking

complete control over all session details.

Figure 5 depicts an example of a GUI application

built on top of the session management subsystem.

The user’s view is basically a two-dimensional matrix

of participants and media. The cells denote the partici-

pation status in a medium (connected, alerting, or not

participating). Several meetings can be held concur-

rently and can be switched through tabs.

This GUI is very intuitive. A common session

setup scenario invoked through this interface works as

follows:

1. With the GUI, the end user creates a new multi-

media, multiparty session.

2. The GUI application requests MediaBuilder’s ses-

sion management to start a session with the

required number of participants and media.

3. This request is expanded with specialized objects

concerning the network connection type and

topology.

4. The MediaBuilder client contacts the service fac-

tory to create a new service session manager

(SSM) to manage the new session.

5. The request is sent to the SSM, which in turn

contacts the called parties and provides informa-

tion about associations and connection endpoints.

6. In case ATM PVCs are used, the communication

session manager is instructed to set up the PVCs

through the ATM switch. Otherwise, the TCP/IP

or ATM SVC communication channels are set up

by the communication endpoints. Connections

are set up with guaranteed QoS if supported by

the network.

7. The SSM collects the replies from the called users

and signals all parties that the session setup is

completed.

Once these session management interactions have

been completed, user data is exchanged. The media

realization handles the raw user data streams, which

are mapped to the proper devices—for example, audio

or video boards.

Media RealizationThe actions performed through session manage-

ment result in the activation of multimedia components

in the user’s terminal. MediaBuilder allows the flexible

configuration of the relationship between specific ses-

sion management objects and specific multimedia

components. The “Application Engineering” section

Figure 5.User’s view of session management subsystem.


discusses how to define these relationships, and the

“Medium Realization Programming” section gives an

overview of how the multimedia components are

brought into life.

Multimedia components are responsible for:

1. Sending and receiving user data to and from net-

work connections (for example, native ATM vir-

tual channels or TCP/IP sockets);

2. Mapping these data to and from local multimedia

devices (for example, sound/video cards and win-

dows); and

3. Implementing multi-peer protocols (for example,

reliable multicast) and combining incoming data

streams (for example, audio mixing).

The following user-visible multimedia compo-

nents are available in the current MediaBuilder

platform:

• Audio: shared audio;

• Video: shared video through multiple video

windows (one for each participant);

• Chat: text message exchange;

• Shared whiteboard: shared drawing on a white-

board window; and

• Document structure editing: IBM SOM*/

OpenDoc*-based collaborative editing of docu-

ment layouts.

Most multimedia components offer several versions

(for example, high-quality/low-quality audio or

large-size/small-size video).

Application EngineeringA specific part of MediaBuilder is devoted to appli-

cation engineering, which is defined as the creation of

new applications and services based on the reuse of

already existing components and building blocks. It

consists of tools that facilitate the creation and mainte-

nance of applications and services. These can be read-

ily deployed across any network as provided by the

network layer. The most powerful feature of the appli-

cation engineering environment is that it allows the

configuration, assembly, and addition of new applica-

tion components without a need for programming.

The manner in which this is achieved is further dis-

cussed below.

Information related to application engineering is

stored in a repository, currently realized through a set

of configuration files and dynamically loadable libraries

(dynamic linked libraries [DLLs] on Microsoft

Windows*). When a component is instantiated at run

time, its implementation DLL name is obtained from

the configuration file. Next, this DLL is loaded and the

component is created. This allows us to have pre-

defined program modules consisting of a configuration

file plus a corresponding DLL. These modules contain

the code for specific networking environments (for

example, network protocol), local hardware drivers

(for example, video board), or multimedia components

(for example, shared whiteboard). A new program

module can easily be added to the platform without the

need for recompilation of the other modules. The plat-

form also provides for the possibility of downloadable

DLLs that can be used immediately after download.

The following are examples of application engi-

neering services:

• Component inheritance hierarchy and naming.

Components form an inheritance hierarchy

that is expressed by a hierarchy of numbers

(MediaBuilder object type [MOT]). They can

also be given user-defined names.

• Component initialization. Component attributes

can be predefined so that when a component

is created, these attribute values are automati-

cally assigned. For example, a video compo-

nent can be preconfigured as having JPEG

encoding.

• Component relationships. This allows compo-

nents to be instantiated at run time based on

relationships configured off-line. It is used

extensively to relate the areas of session man-

agement and multimedia realization. For

example, a particular shared whiteboard real-

ization component can be activated whenever

its related medium is negotiated through ses-

sion management. Session management does

not have hard-coded knowledge of which

multimedia realization components it should

activate.

• Medium profiling. This is a special case of a com-

ponent relationship service that realizes a con-

figurable mapping between user QoS and

communication QoS. A MediumProfile


describes a set of session management compo-

nents and their attributes under a single name.

The components of a MediumProfile

describe encoding options, the bandwidth

required, the connection topology to be used,

and, optionally, the type of network to be used

(for example, TCP/IP or ATM). This entire set

can be given a single name. For example, a

MediumProfile “HighQualityVideo” can

bundle the options of JPEG encoding, ATM

networking, required bandwidth, and multi-

cast topology. MediumProfiles appear at the

session management interfaces as the media

that are available to the application.

Below is an excerpt from the configuration file for

an ATM network showing a component for AAL con-

nections. The component with MOT [1,4,8,1] is a

base AalConnection component. The component

with MOT [1,4,8,1,3] is derived from the

AalConnection component and is specialized for

10-Mb/s connections. Both components are imple-

mented by the C++ class MW_AalConnection. The

excerpt also shows how a relationship is expressed:

each connection type has a corresponding

TransportAdapter (a medium realization base

component) that implements the particular protocol or

interacts with system drivers. For example,

AtmTransportAdapter implements ATM transport,

interacting with the ATM system driver. This compo-

nent is automatically instantiated whenever an

AalConnection is negotiated through session

management.

[1,4,8,1]

name = AalConnection

c++class = MW_AalConnection

; default values for all parameters

are included for the base class

; bandwidth in kb/s

bandwidth = 150000

peakBandwidth = 150000

; traffictype: CBR = 0; VBR = 1

trafficType = 0

transportAdapter =

AtmTransportAdapter

[1,4,8,1,3]

name = Aal_10Mb

; all parameters are inherited; only

bandwidth and peakbandwidth are

redefined

; bandwidth in kb/s

bandwidth = 10000

peakBandwidth = 10000

Below is an example of a MediumProfile for

extra-large video from the configuration file contain-

ing MediumProfiles:

[1,50,2]

name = Video

medium = PictureMedium

default = 1

[1,50,2,1]

name = Video_XLarge

mediumAssociation =

ExtraLargeSizeVideo

; CBR 5 Mb/s

bandwidth = 5120

; traffictype: CBR = 0; VBR = 1

trafficType = 0

The MediumProfile bundles a Medium type

and an Association type (encoding). The commu-

nication type that was present in the previous version

has now been replaced with QoS requirements—in

this case, only bandwidth and traffic type. This

enables the MediumProfiles to be specified inde-

pendent of the underlying network type, increasing

MediaBuilder’s extensibility regarding networks. At

the moment, the party setting up a connection

determines the type of network used; future exten-

sions foresee the negotiation of network con-

nections on a case-by-case basis. Note that the

base MediumProfile in this example (video,

MOT [1,50,2]) only specifies the Medium type; it

cannot be used by itself because the Association

type is not specified. Therefore, the default state-

ment is included; in case the base “video”

MediumProfile is selected, it defaults to the

Video_XlargeMediumProfilewith MOT [1,50,2,1],

where mediumAssociation is defined.


MediaBuilder Software DesignThis section describes software design patterns, the

session management programming model, and

medium realization programming.

Software Design PatternsMediaBuilder was designed using object-oriented

techniques. Several additional concepts were applied

in the design—most notably, design patterns. Design

patterns are an emerging discipline that helps design-

ers understand and apply proven solutions to recur-

ring design problems. There is a growing body of

literature for the patterns of object-oriented program-

ming,10 telecommunications architecture,11 and many

other software areas. Patterns can be regarded as

reusable micro-architectures that contribute to an

overall architecture.12 The software design described in

this paper was the subject of a paper by

van den Broecke and Coplien.13 Note that

MediaBuilder has evolved further since then, although

the fundamental principles have not changed.

Figure 6 shows the main design patterns, their

relationships, and their external interfaces (small blue

ellipses). Dashed arrows indicate that a pattern partici-

pates in the pattern to which it points. Solid lines

denote collaboration between patterns. Each pattern

belongs to one of the subsystems introduced above—

that is, session management, media realization, or

application engineering. Although many more pat-

terns contribute to the architecture, seven form the

backbone structure and determine its basic behavior.

These main design patterns operate as follows:

• The Facade pattern10 shields its clients from the

complexities of an underlying subsystem. It is

applied within MediaBuilder to provide applica-

tions with a common high-level interface—the

session management application programming

interface (API)—while shielding them from the

details of how a session is controlled.

• The Command pattern10 encapsulates a request

as a class. It is applied within MediaBuilder to

Sessionmanagement

Multimediadevices Layers

Network(transport)

Builder

builds

SessionObserver

Mediarealization

Session Control& Observation

Parties &Media as

First Class Citizens

SessionModel

Command

SessionControl

Facade

Applicationengineering

PluggableFactory

Sessionmanagement API

Network(control)

Databases

API – Application programming interface

invokes

(global)

Figure 6.MediaBuilder patterns software architecture.


encapsulate the execution of network-specific

control procedures through which a session

context is negotiated.

• The Session Control & Observation pattern con-

trols and maintains the state of a session and

provides notifications to those interested in

that state. This pattern is a specialized Model-

View-Controller pattern. It is the most central

pattern in MediaBuilder, since it provides the

bridging between session management and

medium realization. Figure 6 shows that its

three participants are realized using additional

patterns. The session state (SessionModel) is

modeled using the pattern Parties & Media as

First Class Citizens. SessionControl controls

the session state and is realized using the

Command pattern.10 SessionObservers

have an interest in the session state.

• The Builder pattern10 is a specialized

SessionObserver. It is applied to build a

realization of a session context (the

SessionModel) that is local to the applica-

tion. This involves the creation and linkage of

transport connections, application protocols,

and local multimedia devices. These elements

are structured according to the Layers pattern.

• The Pluggable Factory pattern is applied to pro-

vide a global service for configuring and

instantiating framework components. A data-

base holds a repository of components that can

be reused in different applications.

Session Management Programming ModelApplication code interacts with the session model

through three APIs. The programming model from the

application perspective is depicted in Figure 7. The

three APIs—modification API, query API, and notifica-

tion API—together consitute the Mediabuilder session

management API.

Modification API. The first API is one through

which a program requests modification of the

SessionModel by adding (add()) or deleting

(delete()) session objects. The completion of a

request can be notified to the application through the

event notification service (see below). For incoming

requests (invite()), the programmer can overload

an incoming responder class, for example, in order to

pop up a modal dialog that asks the end user to accept

or decline the incoming call.

Two implementations of the modification API are

specified. The first presents a low-level interface in

terms of session objects of the basic SessionModel. It

Application objects


Notification API Query API Modification API

register() notify() query()add()

delete() invite()

Session model

Figure 7.Session management programming model.


allows the application to have a very fine control over

the communication QoS. The second presents a more

abstract interface to the application. Modifications to

the SessionModel are made in terms of user QoS

captured in MediumProfiles, and parties are

denoted by their symbolic names. Obviously, pro-

gramming with the second interface is less complex.

Query API. The second API is one through which

the SessionModel can be queried (SessionBrowser).

This allows detailed queries (query()) of the session

objects (parties, media, connections, and relationships)

present in the SessionModel.

Notification API. The third API is an event notifi-

cation API for changes in the SessionModel.

Progammers can register (register()) objects with

the SessionModel, specifying events and/or session

object types for which they want to be called back

(notify()). For example, an application may have a

graphical status display of all parties and media

involved in a session. In this case, it registers for the

events “creation,” “deletion,” and “alerting” related to

any party or medium session object. Whenever a party

or medium is added, deleted, or alerted, the frame-

work will call back the application object.

Medium Realization ProgrammingApplication developers can extend the current set

of medium realization components. They do not need

to be concerned about how these components are

brought into life through session management.

Inheritance is the main programming model through

which new components are realized. Through applica-

tion engineering, new components can be configured

in the repository (configuration files) so that they are

automatically instantiated whenever their related ses-

sion objects are added to the session model. The basic

structure for medium realization components and the

programming concepts are explained next.

The MediumBuilder is a special observer of the

SessionModel that is responsible for the lifecycle of

the components realizing the actual multimedia/

network functions. These are the objects consti-

tuting layers of the protocol stack (if present,

ProtocolLayers), the objects providing a mapping

to network devices (TransportAdapter), and the

objects mapping data to multimedia devices

(PresenterAdapter). Multimedia realization pro-

gramming implies overloading of one or more of the

classes for MediumBuilder, ProtocolLayers,

TransportAdapter, and PresenterAdapter,

depending on what is required. Figure 8 depicts the

multimedia realization programming model.

Dynamically, the MediumBuilder gets notified

whenever objects in the SessionModel are

added/deleted. This provides a trigger to build (or

destruct) a protocol stack with adapters at both sides of

the stack. Many stack element components are already

available. For example, when adding a new medium,

fax, only a new PresenterAdapter (for example,

FaxPresenterAdapter) and probably a

ProtocolLayer need to be provided. Existing com-

ponents for TransportAdapters (for example,

ATMTransportAdapter) can be reused. The stan-

dard MediumBuilder will instantiate the

FaxPresenterAdapter automatically, based on

information in the engineering repository (which, of

course, must be configured for fax as well).

Pilot ExperiencesThe MediaBuilder platform has been implemented

within the MESH project using the C++ language and

the Microsoft Visual C++* compiler versions 4.2

and 5.0 on the standard Windows NT* 4.0 operating

system. For high-quality audio and video perfor-

mance, the Montage audio/video board provided by

Bell Labs is used.14 Interfacing with the ATM network

is provided by Olicom 155-Mb/s ATM cards together

with an ATM device driver. Interfacing with the local

Ethernet is possible via a standard Ethernet card.

Within the Netherlands, divided over eight loca-

tions in total, MESH platforms (PCs running the

MESH software equipped with Montage audio/video

boards, cameras, and loudspeakers) were installed.

ATM interconnection was provided from the central

ATM switch to the eight locations using the services of

Surfnet—the Dutch university and research institute

Internet and ATM provider. Most of the locations also

have the capability to connect the platforms to local

Ethernet networks and to Surfnet’s Internet backbone.

For the pilots, several services were developed on

top of MediaBuilder. A generic conferencing tool was


created that allows pilot users to interact using audio,

video, text, and a shared whiteboard. For specific

pilots, advanced media were created: the CoCoDoc

medium (providing shared document structured edit-

ing) and the Sybar medium (providing a shared inter-

active medical data examination tool used by a

revalidation clinic and an academic hospital).

Furthermore, MediaBuilder was coupled to an

advanced virtual three-dimensional interface giving

access to a wide number of university facilities.

The pilots started in December 1997 and finished

in September 1998. The MediaBuilder platform was

further improved during the pilots, partly to improve

the stability of the software and partly to extend the

functionality. The pilots provided valuable feedback to

the developers, mainly concerning reliability and func-

tionality. The fundamental design was proven capable

of providing advanced multimedia/multiparty services

to the pilot users. The extensibility of the platform was

proven by the addition of new media.

ConclusionsIn this paper, a platform for distributed multi-

media applications called MediaBuilder was presented.

This work was done within the framework of the

PLATINUM and MESH projects. MESH is a joint

research project between industry, research institutes,

and universities. The MESH system consists of three

functional layers: the application layer, the middle-

ware layer, and the network layer. Because technolo-

gies in all three layers are still evolving and will not

stabilize fast enough, it is important to decouple the

developments within each layer and allow each one to

evolve independently and gracefully.

The developments in the middleware layer play a

central role in freeing application software from the

intricacies of the network layer and shielding it from

evolving networking standards. The MediaBuilder

platform is used as middleware in the PLATINUM and

MESH projects. Multimedia applications access the ser-

vices of MediaBuilder via an API. A powerful feature

of MediaBuilder is its application engineering, which

enables the creation of services from existing building

blocks (multimedia components and service session

logic) and allows for the creation of new building

blocks from existing ones. The MediaBuilder platform

was designed using object-oriented techniques.

Several additional concepts were applied in this

design—most notably, design patterns.

The usability of MediaBuilder was tested in the

pilots. Current results show that the platform is indeed

capable of providing state-of-the-art multimedia/

Multimedia devices

PresenterAdapter

ProtocolLayers

TransportAdapter

Network devices

MediumBuilder

create

create

create

register()

Notification API(see Figure 7)

notify()


Figure 8.Multimedia realization programming model.


multiparty services to the pilot users. The extensibility

was also tested by adding new multimedia compo-

nents to the platform.

Future plans include completion of the application

engineering layer with user-friendly tools for the cre-

ation of new services and new multimedia compo-

nents. Additional work will be conducted on the

exploitation aspect of these services concerning billing

and security. Scalability of the platform is also an area

of interest. A more detailed issue is the addition of

connection type negotiation and the addition of an

option for network bridges to interconnect clients with

different network connections.

*TrademarksIBM and SOM are registered trademarks of

International Business Machines Corporation.

Microsoft, Visual C++, Windows, and Windows NT areregistered trademarks of Microsoft Corporation.

OpenDoc is a registered trademark of Apple Computer,Inc.

References1. P. A. Bernstein, “Middleware: A Model for

Distributed System Services,” Commun. of theAssoc. for Computing Machinery (ACM), Vol. 39,No. 2, Feb. 1996, pp. 86–98.

2. R. Richardson, E. Clark, A. Sarma, U. Behnke,and H. Ouibrahim, “A Broadband MultimediaSignaling Demonstration System,” Proc. Intl.Switching Symp. (ISS ’95), Apr. 1995, Vol. 2, pp. 52–56.

3. http://www.mesh.nl/4. J. O. Coplien, “Pattern Languages of Program

Design,” edited by D. C. Schmidt, 1st AnnualConf. on Pattern Languages of Programs (PLoP),Monticello, Ill., Aug. 1994.

5. F. V. Baumann and H. Ouibrahim, “A Network-Based Platform for Multimedia Applications,”Proc. Intl. Switching Symp. (ISS ’97), Toronto,Sept. 21–26, 1997, pp. 143–150.

6. Telecommunications Information NetworkingArchitecture Consortium, “Overall Conceptsand Principles of TINA,” TINA-C Public DeliverableVersion 1.0, Feb. 1995, http://www.tinac.com

7. International Telecommunication Union—Telecommunication Standardization Sector,“Broadband Integrated Services Digital Network(B-ISDN); Digital Subscriber Signaling SystemNo. 2 (DSS2) Protocol; B-ISDN User-NetworkInterface Layer 3 Specification for BasicCall/Connection Control; Part 1: ProtocolSpecification,” ITU-T Rec. Q.2931, 1995,

http://www.itu.int/ITU-T/index.html8. S. Minzer, “A Signaling Protocol for Complex

Multimedia Services,” IEEE J. Selected Areas inCommun., Vol. 9, No. 9, Dec. 1991, pp. 97–114.

9. R. Carli, L. Ronchetti, H. Ouibrahim, andA. de Smedt, “A Conceptual Framework forB-ISDN Multiconnection/Multiparty Calls,”Proc. 11th Intl. Conf. on Computer Commun.(ICCC ’92), Genoa, Italy, Sept. 1992, pp. 283–290.

10. E. Gamma, R. Helm, R. E. Johnson, andJ. Vlissides, Design Patterns—Elements of ReusableObject-Oriented Software, Addison-Wesley,Reading, Mass., 1995.

11. M. Adams, J. O. Coplien, R. Gamoke,R. Hanmer, F. Keeve, and K. Nicodemus,“Fault-Tolerant Telecommunication SystemPatterns,” Pattern Languages of Program Design 2,edited by J. M. Vlissides, J. O. Coplien, andN. Kerth, Addison-Wesley, Reading, Mass.,1996, pp. 549–562.

12. K. Beck and R. E. Johnson, “Patterns GenerateArchitectures,” Proc. 8th European Conf. on Object-Oriented Programming (ECOOP ’94),Bologna, Italy, July 1994, pp. 139–149.

13. J. A. van den Broecke and J. O. Coplien, “Using Design Patterns to Build a Frameworkfor Multimedia Networking,” Bell Labs Tech. J.,Vol. 2, No. 1, Winter 1997, pp. 166–187.

14. R. D. Gaglianello and G. L. Cash, “Montage:Continuous Presence Teleconferencing UtilizingCompressed Domain Video Bridging,” IEEE Intl.Conf. on Commun. (ICC ’95), Seattle, Vol. 1,June 1995, pp. 573–581.

(Manuscript approved June 1999)

FRANK V. BAUMANN is a member of technical staff inthe Forward-Looking Work Department atLucent’s Switching and Access SolutionsGroup in Huizen, the Netherlands. Hereceived an M.S. degree in computer scienceand completed a post-graduate course in

tele-informatics, both at the University of Twente inthe Netherlands. Mr. Baumann’s work is focused on theresearch and development of multimedia conferencingand collaboration platforms as well as the networktechnologies supporting those platforms. ◆

mediabuilder: a next-generation multimedia service creation and deployment platform

Documents