Example Application Scenario

An example shall serve to illustrate how application scenarios are translated into role, bridge and bridge set definitions. A distributed school has to be imagined with professors and students all geographically dispersed. Professors have application scenarios for all kinds of teaching purposes at hand, among them a scenario that supports translation work on stage-plays written in a foreign language. The scenario has four states or phases. In a first phase, the professor gives an introduction into the translation assignment that was previously distributed by E-mail.

Students see and hear the professor, and they hear each other, which allows them to listen to questions asked to the professor by fellow students. In a second phase, the students start to work on the translation of the stage-play. The professor goes from student to student and answers their questions. The editor of the currently visited student is automatically shared with the professor. The professor may return to phase one if a question is of general interest. Once students have finished the translation, phase three begins where individual students present their results. The professor and the momentarily presenting student are visible to all other stu-dents and to each other. The editor of the student is automatically shared with all others, and audio is like in phase one. In phase four, multiple students take roles in the stage-play and recite them. Their image and voice is distributed to the professor and to the other students. The professor finishes the course with some remarks, with the application being again in phase one.

During the whole session the professor has as the replacement of a classroom-view an icon-sized video image with low frame rate from every student.

The roles that can be identified in this scenario are:

• professor: static professor role

• student: static student role

• studentSpeaker: visible students in phase two, three, four

• master: held by the professor

• participant: professor and students

The transient role studentSpeaker is assigned to the visited student in phase two, to the pre-senting student of phase three, and to the acting students in phase four. The bridges that need to be defined are shown in Table 4.3 . The first audio bridge is the all-to-all audio bridge of phase one and three. Audio bridge 2 and video bridge 6 form a bidirectional audiovisual connection for phase two. Audio bridge 3 and video bridge 7 form the virtual stage of phase 4. The

No. Medium Source Roles Sink Roles

1 audio participant participant

2 audio professor,studentSpeaker professor,studentSpeaker

3 audio studentSpeaker participant

4 video professor student

5 video student professor

6 video professor,studentSpeaker professor,studentSpeaker

7 video studentSpeaker participant

8 sharedX studentSpeaker professor

9 sharedX studentSpeaker participant

Table 4.3. Example bridge definitions.

multipoint-to-point bridge 5 represents the icon-sized classroom view. Four bridge sets are defined according to the four phases of the application scenario:

• bridge set one (introduction): audio bridge 1, video bridges 4+5. In the introduc-tory phase, all participants hear each other (1). The professor is visible to all stu-dents (4), and can see all stustu-dents (5).

• bridge set two (question): audio bridge 2, video bridge 5+6, sharedX bridge 8.

The professor has bidirectional audio and video connections and a sharedX con-nection with an asking student (2,6,8), and can see all students (5).

• bridge set three (presentation of results): audio bridge 1, video bridges 5+7, sharedX bridge 9. During result presentation, all participants hear each other (1), the student that presents his results is visible to all participants (7), and the professor can see all students (5).

• bridge set four (recitation): audio bridge 3, video bridge 5+7. During recitation, the reciting students can be heard and seen by all participants (3,7), and the professor can see all students (5).

Connection control during the session consists of changing between bridge sets and assign-ing the transient role studentSpeaker.

The example scenario illustrates some aspects of application development on top of the Beteus API. Starting point is the invention of an application scenario. Then comes a problem analysis phase during which the roles, bridges and bridge sets within the application scenario are identified. This is an iterative process because the analysis of the scenario will likely influ-ence the scenario itself. The following design phase comprises the dimensioning of bridge parameters, the specification of the messages that are exchanged between session vertices, and the specification of the functionality to be put into GUI’s. The final implementation phase is mainly concerned with the development of GUI’s. The tight match between scenario analysis methodology and API functionality greatly reduces the effort needed to implement the connec-tion management part of a teleconferencing applicaconnec-tion.

4.3.7 Implementation

The Beteus platform is implemented in C++ and Tcl/Tk and runs on Sun workstations under SunOs 4.1.3. Communication between applications and site control is based on Tcl-DP. All other platform components within the site communicate by means of a proprietary RPC-like protocol that is closely integrated with C++. Three applications have been developed on top of the platform. The following discusses implementation issues concerning the various platform components.

Audio and Video Transmission

Audio and video is transmitted via UDP or, if available, via IP multicast. The audio and video sender components implement simple UDP stream duplication that allows to deploy the plat-form on networks like the European ATM pilot that do not support IP multicast. Video trans-mission is built around the XVideo board from Parallax. The compression of the Parallax board follows the JPEG standard for the compression of still images [Wall91]. On connection setup, the video sender allows to specify a target data rate that is consequently enforced by means of a control loop in which maximum and measured data rate are constantly compared, with the JPEG compression factor being modified according to the result of this comparison. Such a

mechanism was necessary in the case of Beteus where there are data rate restrictions per video stream and traffic policing within the network. The audio component is implemented as a sin-gle process that contains both sender and receiver. The sender performs silence detection and transmits audio in the form of talk spurts. The receiving side supports both mixing and stream selection.

Application Sharing

The application sharing component of the platform is Xwedge from project partner ETH Zürich [Gute95]. Xwedge is a distributed shared window system that has agents running at all implicated client and server sites. X11 clients connect to the local Xwedge agent which in turn communicates via TCP with remote agents and the local X11 server. The Beteus API offers three calls for application sharing control: a session vertex can get a list of sharable applica-tions, which are the clients that are momentarily connected to the Xwedge agent, and it can share and unshare an application. Sharing means that the interface of the chosen application is replicated at the sink endpoints of the currently active X11 bridge. The platform does not implement the rich set of floor control mechanisms that Xwedge offers. The platform uses the default floor control mode where the floor follows mouse clicks and keyboard input.

Site Control

It was planned to implement the site control in two steps. A first version should only support sessions within a single site, which is effectively a completely centralized platform. A second version should extend the centralized platform to the semi-distributed platform described in Section 4.3.2. The first version was finished on time and was presented in July 1995 to a com-mission of the European Union. In order to be able to operate this first version of the platform on the Beteus network depicted in Figure 4.2, all Beteus sites had to be configured as a single logical site. This worked without any problem, but was clearly against the design philosophy of the Beteus platform. The second version of the platform was almost finished when the first was presented, but was never made to run, for the problems that were encountered with the ATM pilot network moved the focus of the project away from the applications to basic audio and video transmission [Blum96]. However, the existing first version of the site manager imple-ments the complete API as described in Section 4.3.5. In addition to this runtime version of the site manager there is a development version that forks a dummy connection manager which reads the site configuration file and returns positive responses to site management connect and disconnect requests. This allows to test session vertices in emulated sessions on a single screen and without establishing audio, video or application-sharing connections.

Applications

The applications that have been developed are the generic control panel, a tele-meeting appli-cation, a tele-tutoring appliappli-cation, and a test application that allows to dynamically establish arbitrary connection structures. The originally intended distributed-classroom application was not implemented because the distributed summer school for which it was intended did not take place.

The tele-meeting scenario is a simple framework for work meetings that can be used within many environments. The audio and video connection structure is all-to-all, i.e., everybody sees and hears everybody else. There are simple GUI’s for a chairman and a normal participant, with the chairman being able to assign the role of a presenter to one of the session participants.

The presenting person can share one of its X11 applications with the other participants. The chairman interface allows to transfer the chairman role to another participant, in which case

this participant gets his interface exchanged for a chairman interface. The tele-meeting sce-nario is implemented with a single bridge set containing an all-to-all audio bridge, an all-to-all video bridge and a one-to-all application-sharing bridge with the presenter role as source. Con-nection management only gets active when the presenter role is assigned, or when participants join or leave the session, in which case their connection endpoints are automatically added or removed from the audio and video bridges.

The tele-tutoring application features a professor and students that are all geographically dispersed. The application can be in the states global and talk. In the state global, the professor has a video window for every student, and can himself be seen and heard by all students. In the talk state, the professor talks to a single student, but audio and video of both professor and dent are distributed to all other students so that everybody can follow their discussion. The stu-dent can also share an X11 application to show his work. The roles, bridges and bridge sets defined for this scenario resemble the ones described in the example scenario of Section 4.3.6.

The tele-tutoring application is still a simple application, but it already has much more connec-tion structure dynamics than the tele-meeting scenario.

4.3.8 Assessment

The Beteus platform supports conference-style communication among a small number of sites that have a static relationship with each other. Examples for such groups of sites are universi-ties with a common tele-teaching program, or laboratories working on a common project. The platform is not designed for ad-hoc communication on a network with a large number of sites like the MBone. Such a deployment is imaginable, but would require a redesign of at least the directory service.

The principal contributions of the Beteus platform are its connection abstractions (role, bridge and bridge set) and the API that supports the rapid development and incremental improvement of collaborative teleconferencing applications. The use of Tcl-DP for the API has the advantage that applications can be entirely developed in Tcl/Tk, which makes sense given that GUI code represents the most significant part of the application¹. The ease with which applications can be developed on top of the Beteus platform was proven with the tele-tutoring application, which was implemented by two Eurécom students as part of a small 1st semester project. None of the two was familiar with Tcl/Tk at the beginning of the project, and most of the work was done within a period of a couple of days at the end of the semester. In addition it has to be noted that the tele-tutoring application is a remake of the Betel application [Pusz94]

that was jointly developed by Eurécom and the EPFL as part of a 1 year European project. The Beteus platform made it possible to implement the Betel application with significantly reduced effort and in very short time.

Concerning the drawbacks of the API, the same can be said as in the case of the Touring Machine. The API is monolithic, and it is not possible to extend it without modifying the site manager. The now procedure-based API would profit from being reformulated with CORBA IDL. A Beteus API based on CORBA would for instance have an interface for bridge set con-trol, a session vertex interface for role assignment, various interfaces for audio and video end-point control, and interfaces for audio, video and application-sharing bridges that inherit from a generic bridge interface. A good part of the API call parameters are right now identifiers for

1. Tcl is a controversial language. For arguments against the use of Tcl see Richard Stallman’s 1994 mail to the Usenet newsgroup comp.lang.tcl ‘Why you should not use Tcl’ [Stal94].

what would be objects with CORBA. It can therefore be expected that an API based on CORBA would be much easier to use. Besides that, CORBA is also likely to simplify the site manager which is already implemented in C++, and which now contains code that dispatches Tcl-DP procedure calls onto object methods. CORBA would also improve the internal commu-nication of the platform. As an example, the modification of the audio volume is now an API call that traverses the site manager, the connection manager and the station agent before arriv-ing at the audio process. In the case of CORBA there would be a direct TCP connection between the Beteus control panel and the audio process, and audio endpoint control would be implemented directly by the audio process, making it possible to add audio control functional-ity without modifying the site control. During the Beteus field tests it turned out that people had difficulties in identifying the video window of the current speaker in a set of video receiver windows depicting conference participants. A straightforward solution to this problem would be to visually mark the video window that shows the current speaker. There was no way to do this in the Beteus platform. In a CORBA-based platform, the video receiver would simply reg-ister for activity events with the audio process, and receive them directly without any other platform component being involved.

Beteus Platform

Requirement Fulfilled Remark

Open ❄ uses the de-facto standard Tcl-DP RPC for the API

Extensible no every extension requires platform modifications Programmable ❄❄❄ API contains high-level connection management support

Scalable no limited number of sites and nodes

Deployable ❄❄ runs on TCP/IP; deployment = editing site configuration file

Simple ❄❄ clearly structured platform; simple API

Session Management ❄❄ users can create or join a session; concept of roles Connection Management ❄❄❄ powerful abstractions (roles, bridges, bridge sets, nodes,...) Multimedia Data Processing ❄❄ highly configurable digital audio and video transmission Multipoint Control Comm. ❄❄ communication between session vertices provided by the API

Resource Management no

-Synchronization no would be necessary

Mobile Code no session vertex code is installed on the endsystem

Presentation Environment ❄ A/V presentation controllable, but not integrated with the GUI Federation of Applications no

-Security no

-Mobility no

-Directory Service ❄❄ information about users, announced sessions, ongoing sessions Platform Management ❄ performance monitoring of audio and video [Bess95]

Accounting no

-Standard DPE no

-Table 4.4. Evaluation of the Beteus platform.

The semi-distributed architecture of the Beteus platform supports arbitrary node configura-tions and accommodates inter-classroom as well as person-to-person applicaconfigura-tions. If perfor-mance considerations suggest so it is possible to dedicate resources to single media, as is indicated in Figure 4.3. It is clear that the central site management becomes a bottleneck as the number of concurrently active nodes grows within a site. However, the Beteus platform was neither conceived for a large number of sites nor for a large number of nodes. Table 4.4 sum-marizes the features of the Beteus platform.