A New Paradigm for the Recording of Shared Whiteboard Streams

Transcription

1 A New Paradigm for the Recording of Shared Whiteboard Streams Volker Hilt 1, Werner Geyer, Wolfgang Effelsberg Lehrstuhl für Praktische Informatik IV, University of Mannheim ABSTRACT The number of video conferences conducted over the Internet has constantly increased during the last years. The need to archive the multimedia data streams of the conferences became apparent, and a number of tools accomplishing this task for audio and video streams were developed. In many video conferencing scenarios, shared whiteboards are used in addition to audio and video to transmit slides or to sketch ideas. However, none of the existing recording tools provides an efficient recording service for data streams of these tools. In this paper we present a new approach to the recording and playback of shared whiteboard media streams. We discuss generic design issues of a shared whiteboard recorder, and we present a novel algorithm that enables efficient random access to the recorded streams. We describe an implementation of our algorithms for the media streams of our digital lecture board (dlb). Keywords: Recording, Shared Whiteboard, Real-Time Transmission, Multicast, Conferencing. 1. INTRODUCTION The Multicast Backbone (MBone) provides the infrastructure for efficient multipoint data delivery in the Internet. The most popular multicast application scenario is audio and video conferencing, e.g. for educational, research or business purposes. Early research focused on the development of tools for audio and video transmission such as vic 21 and vat 15. In recent years, new multicast applications in the field of telecooperation have emerged, in particular shared whiteboards, shared editors or distributed virtual reality applications. These applications are usually employed in multicast conferences together with audio and video tools. The need to archive the multimedia data streams of multicast conferences became apparent very early. Since the classical application field of the MBone was the transmission of audio and video, several tools were developed that accomplish the recording of these continuous media streams. For several reasons, however, little work has been done on the recording of media streams other than audio and video. First, most audio and video streams are transmitted using the real-time transport protocol 25 which eases the development of a recorder for these streams. In contrast, most other media types are encoded and transmitted using their own proprietary encoding rules and network protocols. Second, the characteristics of the media streams produced by applications such as shared whiteboards or shared editors are different from those of audio and video streams: A receiver must hold the state of such an application in order to be able to decode the media stream. This must be considered when developing a recording tool. In particular, random access to a recorded stream requires a recorder to provide the current media state to the receivers. For example, if a recorded shared whiteboard stream is accessed at a random position, the contents of the page active at the access position must be provided to the receivers. In this paper, we present a novel paradigm to record and play back shared whiteboard data streams. Our paradigm is based on a generic model for shared whiteboard media streams which assumes an event-based structure of these streams. As this is the stream-structure of shared whiteboard applications our approach is applicable to all of these systems. As a main feature, our recording scheme enables efficient random access to a recorded stream. In contrast to other approaches, it does not require the restoration of the full shared whiteboard state when accessing a recorded media stream. Instead, only those parts of the state are transmitted which are actually required during playback. As the internal state of a shared whiteboard may comprise a very large amount of data (e.g. a number of postscript slides, gif images etc.) our algorithm significantly reduces the amount of data transmitted over the network during each random access operation; this is a prerequisite for an efficient shared whiteboard recorder. To demonstrate the feasibility of our ideas, we have implemented the recording scheme in a recorder for the digital lecture board (dlb) 6, 8. Our implementation is based on the MBone VCR on Demand (MVoD) system Correspondence: hilt@informatik.uni-mannheim.de; Telephone: ; Fax: ;

2 The remainder of this paper is structured as follows: Section Two presents the most important related work in the field of archiving MBone multimedia streams. Section Three discusses important design issues of a shared whiteboard recorder that include an analysis of protocol requirements and a generic model for shared whiteboard media streams. Section Four describes our concepts and ideas for the recording of shared whiteboard streams. Section Five presents the digital lecture board, our sample application to demonstrate the feasibility of the proposed algorithms. Section Six describes the implementation of the shared whiteboard recorder module. Section Seven concludes the paper with a summary and an outlook. 2. RELATED WORK Much work has been done on the recording of video and audio streams transmitted over the Internet, however, few systems exist that are capable of handling shared whiteboard streams. The rtptools 24 are command-line tools for the recording and playback of single audio and video streams. The Interactive Multimedia Jukebox (IMJ) 1 utilizes these tools to set up a video-on-demand server. Clips from the IMJ can be requested via a Web-based user interface but once started the playback cannot be controlled any further. Meanwhile, there are a number of commercial video-on-demand servers available, one of them is the Real G2 server which is capable of streaming video and audio to RealPlayer G2 clients. However, none of these tools supports the recording and playback of shared whiteboard streams. The mmod 23 system is a Java-based media-on-demand server capable of recording and playing back multiple data streams. Besides audio and video streams, the mmod system records and plays back UDP packet streams of applications like the MBone whiteboard wb 14, mdesk and the Network Text Editor. The disadvantage of recording UDP packet streams is that random access to recorded streams is not feasible due to the lack of application-level protocol information. The MASH infrastructure 20 comprises an recording service called the MASH Archive System 22. It is capable of recording video and audio streams as well as shared whiteboard streams produced by the MediaBoard 27. The MASH Archive System supports random access to recorded MediaBoard streams. A disadvantage is that the implemented random access scheme initializes the receivers with all the data contained in a recorded stream prior to the access position and thus causes large amounts of data to be transferred before the playback is started. The AOF recording system 2, 3 differs from other systems in that audio and whiteboard streams are recorded locally. The audio streams are grabbed from a hardware device, and the shared whiteboard streams are recorded from one of the two applications AOFwb 17 or the MBone whiteboard wb. All the recorded data is converted to an internal storage format. A specific viewer allows the local playback of the recorded data streams, including random access and fast visible scrolling. However, the system does not support the streaming of the recorded data over a network. In the context of CSCW, collaborative workspace recorders have been developed. One of them is the ReplayAble toolkit 18 which is able to capture applications running in a local collaborative workspace. This toolkit requires an application to dump its full internal state on request into the recording to enable random access and restores this full state on access of the recording. Such a mechanism is not applicable to the recording of shared whiteboards as it does not cope with the huge amount of state information a shared whiteboard usually maintains. Furthermore, the usage scenarios of the ReplayAble system are short recordings of collaboration (typically of two to four minutes length 18 ) whereas a typical duration of a shared whiteboard recording is between 20 and 90 minutes. 3. DESIGN ISSUES FOR A SHARED WHITEBOARD RECORDER 3.1. Recording Scenario Most of the existing MBone conference recording facilities (e.g. the MVoD 10 ) accomplish the task of recording audio and video streams by storing media streams packetized in. The systems rely solely on header information for the recording and playback; the major advantage is that the same mechanisms, once implemented, can be used for all media types and encodings. A recorder can also use the same synchronization mechanism to synchronize audio, video and shared whiteboard streams. Of course, this assumes that the shared whiteboard uses the protocol. An recorder such as the MVoD 10, 11 usually handles two types of network sessions (see Figure 1). First, it participates in multicast transmissions of the media data. Usually, a different session is used for the transmission of each media type. Depending on its operation mode (recording or playback), it acts as a receiver or a sender towards the other participants of the sessions. Second, an additional network session is used to control the recorder from a remote client, e.g. by using the RTSP

3 protocol 26. During the recording, the recorder receives data packets and writes them to a storage device. Packets from different sessions are stored separately. When playing back, the recorder successively reads the packets of each session from the storage device. The delivery time for each packet is computed using the time stamps contained in the header. The recorder sends the packets according to the computed schedule. A detailed description of the synchronization mechanism implemented in the MVoD can be found in 11. Figure 1: Recording scenario for a shared whiteboard session 3.2. Protocol Requirements for Shared Whiteboard Streams Audio and video streams are usually transmitted over a multicast network by means of an unreliable datagram protocol since reliable multicast protocols usually do not meet the hard real-time constraints imposed by audio and video data. Moreover, minor errors in transmission do not strongly affect human perception of these media types. In contrast, shared whiteboard streams are very sensitive to transmission errors. The loss of even a single packet may corrupt the presentation of all of the shared whiteboard data. For example, if a page of a shared whiteboard is not transmitted correctly, the receiving whiteboards cannot properly display any data related to that page (e.g. annotations). Shared whiteboard streams have no hard real-time constraints in terms of a transmission delay imposed by the retransmission of data. As a result, a reliable multicast transmission protocol is required for shared whiteboard streams. If a reliable transmission protocol is used, a shared whiteboard recorder must implement the corresponding protocol stack. All data introduced into the transmission by the reliable transmission protocol (headers, repair packets etc.) must be removed while recording, and generated by the recorder during playback. The protocol data cannot be recorded statically because the reliability of the underlying network may change between recording and playback times. Rather, the reliable transmission protocol must be able to dynamically adapt itself to the current network situation. Furthermore, the recorder must be able to use the mechanisms provided by the reliable transmission protocol to ensure that all shared whiteboard data is received and stored correctly. In turn, during playback, the recorder must transmit the recorded data reliably to the receivers. It is sometimes desirable to encrypt a shared whiteboard stream. Two different approaches to the recording of encrypted streams are feasible: the encrypted stream may be recorded as is, without decrypting it, or the stream may be decrypted and stored as plain data. In the first case, it is assured that only participants who hold the key of the original session can view the recording, the disadvantage being that the original conference key must be handed out to any other person who is to be allowed to view the recording. Furthermore, each person who has once received the key may view the recording repeatedly since the encryption of the recorded stream can never be changed. In contrast, the second approach allows the recorded data to be encrypted differently for each playback. Thus, the scope of the playback can be controlled by generating appropriate keys. Consequently, the recorder must implement a cipher and mechanisms for key exchange. To protect the decrypted data streams stored on hard disk, the disk can be encrypted in an separate step.

4 3.3. Application Level Requirements for Shared Whiteboard Streams Audio and video streams allow random access to any position within a recorded stream since there are generally no dependencies within these streams. The data contained in an audio or video stream is sufficient to start the presentation of this medium shortly after the reception of the first data packets. In contrast to this, the decoding of a shared whiteboard media stream in principle requires the receivers to hold the full state of the medium when the presentation begins. The full state of a shared whiteboard medium comprises all data transferred in the stream so far because shared whiteboard applications contain all pages, annotations, etc. of an ongoing session. It is not possible to start the decoding of a shared whiteboard stream at an arbitrary position in the stream. For example, a draw-line event can not be decoded without having the page on which the line should be drawn. Even worse, a jump-to-page event can be decoded only if the destination page is available. However, in a typical presentation using a shared whiteboard, the presenter moves through his slides by displaying them successively, one after the other. Jumps to previous pages may occur but are usually not very frequent. The likelihood of jumps to previous pages even decreases if multiple topics are dealt with that are not closely correlated. For example, a recorded lecture may contain multiple distinct sub-chapters. Thus, operations on a shared whiteboard that actually require the presence of the full state to decode the stream are very rare. If a recorded whiteboard stream is accessed at a random position, the recorder must enable the receivers to decode the complete upcoming stream. An obvious solution to this problem is to initialize the receivers with the full media state at the access position. This could be done by simply playing back (at high speed) the recorded stream from the beginning up to the access position. Alternately, a recorder operating at the application level could calculate the full state and send it to the receivers. A clear drawback to this approach is that a significant amount of data must be transferred prior to the start of the playback. In most cases, this data will not be used during playback. For example, consider the recording of a conference session with four speakers. If the recorded talk of the last speaker in the session is accessed, our simple minded recorder would initialize the receivers with the slides, annotations, etc. of all previous speakers. A more sophisticated random access algorithm transfers only those parts of the media state that are actually required during the requested playback. Such an algorithm can significantly reduce the amount of data transferred at the initialization of a playback. Furthermore, the user does not receive any pages that do not belong to the part of the recording he/she is interested in. The special requirements of shared whiteboard streams described in Section 3.2 and 3.3 must be considered by a shared whiteboard recorder. Thus, traditional video-conference recorders are not sufficient to record shared whiteboard streams and must be extended with appropriate mechanisms. 4. A GENERIC MODEL FOR SHARED WHITEBOARD MEDIA STREAMS The transmission of shared whiteboard media streams is accomplished by using proprietary application level protocols of the various systems. Thus, before presenting an algorithm for the recording and playback of shared whiteboard streams, we must abstract from the specific protocols and establish a common view on this class of media. A shared whiteboard medium is a medium that is well defined by its current state at any point in time. At a given point in time, the shared whiteboard medium is defined by the internal state of the shared whiteboard application. The state of a shared whiteboard medium can be changed by events. A typical example of an event is the interaction of a user with the shared whiteboard, e.g. by drawing a line on a page. The state of a shared whiteboard application is determined by an initial state and a sequence of events applied to that state. Each event in a sequence refers to a specific preceding state that must be established before the event is applied. Notice that the event sequence is not bound to specific points in time. The application of an event sequence to an initial state will always result in the same media state, independent of the speed at which the sequence is applied. Thus, the decoding of a shared whiteboard stream results in the same final whiteboard state independent of the speed at which the stream is processed. Of course, the realtime decoding of a shared whiteboard stream must be ensured if it is to be synchronized with other media streams. The state of a shared whiteboard must be transmitted if the sender and the receivers of a shared whiteboard media stream hold different states. This situation occurs, for example, if a receiver joins an ongoing session (late join) or if a recorded shared whiteboard stream is accessed at a random position. The receiver must synchronize the local media state to the state of the sender before it is able to interpret the subsequent shared whiteboard media stream. Summing up, our approach assumes that a shared whiteboard media stream consists of events that are applied to the state of a shared whiteboard. For the purpose of resynchronization, the media stream may also contain the shared whiteboard state.

5 A shared whiteboard medium belongs to the class of interactive media, i.e. media that involve user interaction 19. Other examples of interactive media include multiuser VRML models 28 or distributed Java animations 16. In our current research, we are expanding the recording of shared whiteboard media streams presented in this paper to the more general recording of interactive media streams AN EFFICIENT ALGORITHM FOR RANDOM ACCESS The following algorithm for random access to shared whiteboard streams ensures that only those pages are transferred to the receivers that are actually required to display the stream. The set of required pages cannot be determined in advance of a playback because the duration of the playback and therefore the pages used are unknown. Thus, initialization with exactly the pages required during playback is not feasible. However, a recorder can start playback without initialization and successively insert all missing pages into an ongoing playback before they are required for the decoding of the whiteboard stream. To start the playback, positions within a recorded stream must be found that can be decoded independently of any previous data. Certainly, the creation of a new page is such a position. If the playback of a recorded stream is started with a create-page event, all receivers will be able to decode at least this event. However, if the playback continues, some events may refer to previous pages in the stream (e.g. a change-page event). Since the receivers are not initialized with any previous pages, they cannot decode these events correctly, and thus the recorder must start an exception handling. If such an event occurs, the recorder interrupts playback before sending the event and reconstructs the missing page. After sending the page, playback can be resumed, and the event can be processed. In order to determine which pages are unknown to the receivers and thus must be inserted into the stream, the recorder must remember the pages it has sent. Let us take a look at the recorded stream depicted in Figure 2. If this stream is accessed at t n+8, the recorder is required to insert page 7 into the stream before sending the changeto-page-7 event at t n+10. To reconstruct a page from a recorded stream, the recorder must locate its create-page event because this is the first occurrence of a page within a stream. The create-page event must be sent to the receivers in order to reconstruct the bare page. However, annotations and modifications might have been made to the page between its creation and the position where the playback was interrupted to start the page reconstruction. Thus, the recorder has to find all events referring to the recovered page that took place before the current playback position. All events occurring in a whiteboard stream are usually divided into sequences such that each sequence contains events belonging to a specific page. These sequences are delimited by events that change to another page (e.g. a change-page or a new-page event). Due to this characteristic, it is not necessary to play back many distinct events, which would be costly for a stream-oriented recorder. Instead, the recorder may play back the few sequences that contain multiple events. This greatly reduces the number of positioning, start and stop operations required to recover a page. After the create-page event and all subsequent events referring to the page have been sent, the page is restored to exactly the same state it would be in had the recording been played from the beginning. The recorder operates in a fast-playback mode during the recovery of a page such that the delay introduced for the insertion of a missing page is kept very small. Recorded Stream: Page Number: Screen-Output: Event: Create Page Create Page Change Page (7) Create Page Change Page (7) t n t n+1 t n+2 t n+3 t n+4 t n+5 t n+6 t n+7 t n+8 t n+9 t n+10 t Playback Sequence: (Random Access to t n+8 ) Figure 2: Random access to a recorded whiteboard stream

6 Let us take a closer look at the example in Figure 2. This excerpt of a recorded shared whiteboard stream contains events referring to pages 6 to 9. If the given recording is accessed at position t n+8, the playback starts with sending the create-page event for page 9, followed by a draw event. Next, the change-page event to page 7 occurs, and the recorder starts the recovery of page 7 because it has not yet been sent. The recorder locates the create-page event of page 7 at t n+1, jumps to this position and sends the event followed by the two sequences at t n+2 and t n+6, in which the events refer to page 7. Finally, the playback is resumed at t n+10 by sending the change-to-page-7 event. In the above description of the algorithm the playback is started without any initialization directly at a create-page event. This is not always the case. If the playback is to be started at an arbitrary position, the receivers must be initialized with the page that is visible at the access position. This initialization is accomplished analogously to the recovery of a missing page. Thus, if a stream is accessed at a random position, the recorder will start a page recovery for the active page as described above before starting playback. 6. THE DIGITAL LECTURE BOARD, AN EXAMPLE OF AN MBONE WHITEBOARD To demonstrate the feasibility of our approach, we have implemented a recorder for the digital lecture board (dlb) 6. The dlb is a shared whiteboard that we have developed in the context of computer-based distance education. The design of the dlb was significantly influenced by our experience with synchronous teleteaching in the TeleTeaching projects of the University of Mannheim 4. For almost three years we have been using MBone video conferencing tools (vic, vat, and wb) to transmit lectures and seminars to partner universities. These video conferencing tools turned out to be far from optimal for teleteaching since they do not take the specific requirements of teaching into account. This is specifically true for the shared whiteboard wb, which is an electronic substitute for the traditional blackboard or overhead projector. The whiteboard is most important for conveying knowledge in computer science and many other disciplines but is often a bottleneck since the teacher is forced to tailor his or her presentation to the limited features of this tool. In order to overcome the weaknesses of existing shared whiteboards we decided to develop the dlb, which is an enhanced whiteboard tailored to the specific needs of distance education and cooperative learning Main Features The current prototype of the digital lecture board supports the following main features. A more detailed description can be found in 6 and 7. User Interface. The user interface of the dlb (see Figure 6, left window) is easy to use and configurable so as to be able to adapt to different instructional settings. The shared workspace of the dlb basically defined by the common drawing area provides the common context for group work. In contrast to the MBone whiteboard wb, we have implemented a flexible workspace concept with multiple layers where arbitrary media objects can be displayed and modified. By following the relaxed WYSIWIS (what you see is what I see) paradigm, we provide private workspaces for individual participants that can be used to prepare material invisible to the rest of the group. Moreover, we provide the option to attach private annotations to an online document. The content of the shared workspace is persistent in the sense that objects and pages can be saved in a file. This allows to prepare all materials for an on-line session in advance. Furthermore, users can save the results at the end of a session, including all annotations. Media Support. Existing whiteboards, such as wb, provide very limited usage and handling of media. In order to overcome this limitation, we have integrated a variety of media formats (GIF, BMP, PCX, Postscript etc.) into the digital lecture board, as well as many types of built-in objects (rectangles, lines, circles etc.). In contrast to wb, all objects are editable not only by the user who created the object but also by other participants. Collaborative Services. Today s video conferencing solutions suffer from a lack of communication channels compared to the traditional face-to-face situation. Social protocols or rules that govern human interaction and the course of group work in a face-to-face situation are not automatically available in a remote situation, and are difficult to reproduce. These mechanisms include, for instance, raising hands, granting rights to talk or to write on the whiteboard, setting up work groups, or reference pointing. Collaborative services 13 provide mechanisms to support the communication of persons through computers and to increase social awareness. In this sense, they can be considered to be an electronic surrogate, designed to compensate as far as possible for the lack of inter-personal communication channels. The dlb implements basic services such as floor control, session control, voting, online student feedback, chat and telepointers. Security. Many existing teleconferencing applications neglect security issues almost completely, even though security is a vital aspect of private sessions. The dlb is furnished with a flexible, state-of-the art cryptographic component that provides

7 highly secure and fast software encryption by integrating modern encryption algorithms such as IDEA, CAST, Blowfish etc. A thorough discussion of the dlb security features can be found in Communication Protocols In order to provide high responsiveness, the architecture of the digital lecture board is completely distributed with full data replication, i.e. an instance of the dlb runs on each participant s computer. Each instance of the dlb holds a complete copy of the media state (i.e. the online document and all annotations). The dlb instances communicate with each other by using the protocol stack depicted in Figure 3. dlb WTP OPGP UDP IP Multicast Figure 3: Protocol stack of the dlb The Whiteboard Transfer Protocol (WTP) is the application layer protocol of the dlb. WTP defines the packet formats and semantics (e.g. for creating graphical objects or pages). The protocol is event-driven in the sense that a WTP packet initiates the rendering of the contained graphical object at the receiving site. To re-establish the current whiteboard state for a latejoining dlb, we retransmit the corresponding sequence of events (i.e., WTP packets). WTP packets are the payload of packets 25. is used for several reasons: first, packets contain time stamps that allow for synchronization to other -compatible data streams (in particular audio and video). Second, provides lightweight session control through RTCP. Third, MBone recording systems rely on and thus the implementation of a dlb recorder can be based upon an existing tool. The OPGP layer (Open Pretty Good Privacy) realizes the encryption/decryption of the transmitted data, i.e. packets are wrapped into OPGP packets. OPGP allows the standardized encrypted or unencrypted transmission of data. We then use either unreliable UDP connections (e.g. for telepointers) or reliable Scalable Multicast Protocol (SMP) 9 connections to transmit the OPGP packets. SMP is a reliable multicast protocol developed in the context of the dlb project. SMP uses the same receiverbased repair mechanism as SRM 5 in order to implement reliable multicast data delivery. While SRM is integrated into the application - following the ALF paradigm -, we have designed SMP to be a completely application-independent service. In addition SMP provides different levels of scalability, source ordering, late join and anycast options. 7. IMPLEMENTATION OF A RECORDER FOR THE DLB Our implementation of a recorder for the media streams produced by the dlb is based on the MVoD 10 which is an recording system developed at the University of Mannheim 8. The MVoD supports the recording and playback of audio and video streams and allows random access to these streams. During playback, the synchronization of all streams is assured. The MVoD system can be controlled from remote and supports the scheduling of recording and playback commands on a peruser basis. SMP

8 7.1. Architecture The dlb recorder 8 is designed as a separate module, extending the functionality of the MVoD. The dlb recorder module realizes the particular mechanisms required for the recording and playback of dlb media streams and implements the network protocols that are used by the dlb in addition to. The dlb recorder module runs as a separate process that communicates with the MVoD over local sockets (see Figure 4). This clear distinction between the dlb recorder module and MVoD allowed the concurrent development of both tools. Furthermore, the well-tested library that implements the dlb protocol stack could be reused within the recorder module; this would not have been possible within the MVoD due to conflicting timer models. MVoD vic RDCP vat dlb recorder module SMP dlb Figure 4: Architecture of the dlb recorder While audio and video streams are recorded directly by the MVoD, the dlb recorder module constitutes a gateway between the MVoD and the dlb (see Figure 4). It passes the data packets back and forth between dlb and MVoD and issues control commands to the MVoD by means of the Datapump Control Protocol (RDCP). The control over an ongoing playback is required mainly to accomplish the recovery of missing pages. If the dlb recorder module detects a missing page in the dlb media stream, it interrupts the current playback via RDCP control primitives and points the MVoD to the location of the missing page within the recorded stream Protocol Stack The dlb recorder module must implement both the protocol stack used by the dlb and the protocol stack of MVoD (see Figure 5). As explained above, the protocol stack of the dlb includes, in addition to, a Scalable Multicast Protocol (SMP) layer and an Open Pretty Good Privacy (OPGP) layer. During the recording, the module removes the SMP protocol headers from the packets, decrypts them if necessary and passes the plain packets to the MVoD. The MVoD stores the packets in synchronization with other media streams like audio and video. During playback, the packets are processed vice versa. dlb WTP OPGP dlb recorder module OPGP MVoD SMP SMP UDP UDP UDP UDP Figure 5: Protocol stack of the dlb, the dlb recorder module and the MVoD

9 7.3. Recording and Playback The algorithm for the recovery of missing pages requires that the create-page event of a page and all other events referring to it can be located in a recorded media stream within a short time. For this reason, a page-index table is created during the recording that contains an entry for each page which in turn contains the timestamps of all events referring to that page. We have implemented two different types of random access to recorded streams: random access to a specific timestamp or to a specific page. When accessing a specific timestamp, the recorder determines the page to which the last event before the access position refers, and recovers this page using the page-index table. If random access to a specific page is requested, the recorder retrieves the location of the corresponding create-page event from the page-index table and starts playback at that position. A screenshot of the playback dialog is depicted in Figure 6. The dlb, the MVoD system and the dlb recorder module are fully implemented and operational. They currently run on Sun/Solaris platforms, the dlb and the MVoD system also run on Linux and SGI/IRIX platforms. Figure 6: Playback of a recorded dlb media stream 8. CONCLUSION AND OUTLOOK In this paper we have presented a new paradigm for the recording of shared whiteboard streams. To establish a common view on this type of media, we have introduced a generic model for shared whiteboard streams. We have discussed design issues for a shared whiteboard recorder, and we have shown how random access to whiteboard streams can be handled. The most important aspect of our algorithm is that it does not initialize the receivers with a large amount of mostly redundant data. Rather, the algorithm utilizes an intelligent page-recovering scheme that allows the insertion of missing data during playback. We have implemented our ideas in an recorder for the digital lecture board (dlb). The dlb is an enhanced shared whiteboard tailored to the specific needs of distance education and computer-supported cooperative learning. The application layer protocol of the dlb is based on. This allowed us to implement the dlb recorder as an extension of the recording system MVoD. Thus, our implementation combines the well-tested recording mechanisms of the MVoD (e.g. synchronization of multiple media streams) with the new algorithms for shared whiteboard recording. Based on the experiences gained during the development of our shared whiteboard recorder, we are currently working on a generalized recording service for interactive media streams. Interactive media streams are a generalization of whiteboard media streams; for example they also include the streams produced by applications like distributed Java applets and shared VRML viewers. ACKNOWLEDGMENTS This work was partially supported by the DFG (Deutsche Forschungsgemeinschaft) within the V3D2 Digital Library Initiative.

10 REFERENCES 1. K. Almeroth, M. Ammar. The Interactive Multimedia Jukebox (IMJ): A New Paradigm for the On-Demand Delivery of Audio/Video. In: Proc. Seventh International World Wide Web Conference (WWW7), Brisbane, Australia, C. Bacher. Das Authoring on the fly System. Ph.D. Thesis (in German), LS für Algorithmen und Datenstrukturen, Multimedia, Teleteaching und Elektronisches Publizieren, Department of Computer Science, University of Freiburg, Germany, C. Bacher, R. Müller, T. Ottmann, M. Will. Authoring on the Fly. A new way of integrating telepresentation and courseware production. In: Proc. International Conference on Computers in Education (ICCE 97), Kuching, Sarawak, Malaysia, pp , A. Eckert, W. Geyer, W. Effelsberg: A Distance Learning System for Higher Education Based on Telecommunications and Multimedia - A Compound Organizational, Pedagogical, and Technical Approach. In: Proc. World Conference on Educational Multimedia and Hypermedia & Educational Telecommunications 1997 (ED-MEDIA & ED- TELECOM 97), Calgary, Canada, AACE, Available on CD-ROM, contact: 5. S. Floyd, V. Jacobson, C. Liu, S. McCanne and L. Zhang. A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. In: IEEE/ACM Transactions on Networking, Volume 5, Number 6, pp , W. Geyer, W. Effelsberg. The Digital Lecture Board - A Teaching and Learning Tool for Remote Instruction in Higher Education. In: Proc. World Conference on Educational Multimedia and Hypermedia & Educational Telecommunications 1998 (ED-MEDIA & ED-TELECOM 98), Freiburg, Germany, AACE, Available on CD- ROM, contact: 7. W. Geyer, R. Weis: A Secure, Accountable, and Collaborative Whiteboard. In: Proc. International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 1998 (IDMS 98), Oslo, Norway, T. Plagemann, V. Goebel (Eds.), LNCS 1483, Springer Verlag, Berlin, pp. 3-14, O. Graß. Realisierung eines Whiteboard-Recorder Moduls. Master s Thesis (in German), LS Praktische Informatik IV, University of Mannheim, Germany, URL: GrassDiplom.ps.gz. 9. M. Grumann: Entwurf und Implementierung eines zuverlässigen Multicast-Protokolls zur Unterstützung sicherer Gruppenkommunikation in einer Teleteaching-Umgebung. Master s Thesis (in German), LS Praktische Informatik IV, University of Mannheim, Germany, URL: W. Holfelder. Interactive Remote Recording and Playback of Multicast Videoconferences. In: Proc. International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 1997 (IDMS 97), Darmstadt, Germany, R. Steinmetz, L. Wolf (Eds.), LNCS 1309, Springer Verlag, Berlin, pp , September W. Holfelder. Aufzeichnung und Wiedergabe von Internet-Videokonferenzen. Ph.D. Thesis (in German), LS Praktische Informatik IV, University of Mannheim, Shaker-Verlag, Aachen, Germany, V. Hilt, M. Mauve, C. Kuhmünch, W. Effelsberg. A Generic Scheme for the Recording of Interactive Media Streams. In: International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 1999 (IDMS 99), Toulouse, France, M. Diaz et.al. (Eds.), LNCS 1718, Springer Verlag, Berlin, Germany, pp , V. Hilt, W. Geyer. A Model for Collaborative Services in Distributed Learning Environments. In: Proc. International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services 1997 (IDMS 97), Darmstadt, Germany, R. Steinmetz, L. Wolf (Eds.), LNCS 1309, Springer Verlag, Berlin, Germany, pp , V. Jacobson: A Portable, Public Domain Network Whiteboard, Xerox PARC, Viewgraps, April, V. Jacobson, S. McCanne: vat - LBNL Audio Conferencing Tool, URL:

11 16. C. Kuhmünch, T. Fuhrmann, and G. Schöppe. Java Teachware - The Java Remote Control Tool and its Applications. In: Proc. World Conference on Educational Multimedia and Hypermedia & Educational Telecommunications 1998 (ED-MEDIA & ED-TELECOM 98), Freiburg, Germany, AACE, Available on CD-ROM, contact: J. Lienhard, G. Maas. AOFwb - a new Alternative for the MBone Whiteboard wb. In: Proc. World Conference on Educational Multimedia and Hypermedia & Educational Telecommunications 1998 (ED-MEDIA & ED- TELECOM 98), Freiburg, Germany, AACE, June Available on CD-ROM, contact: N. Manohar, A. Prakash. The Session Capture and Replay Paradigm for Asynchronous Collaboration. In: Proc. of the European Conference on Computer Supported Cooperative Work 1995 (ECSCW 95), Stockholm, Sweden, ACM, New York, pp , M. Mauve, V. Hilt, C. Kuhmünch, W. Effelsberg: A General Framework and Communication Protocol for the Real- Time Transmission of Interactive Media. In: Proc. IEEE International Conference on Multimedia Computing and Systems (ICMCS 99), Florence, Italy, IEEE, Los Alamitos, Vol. 2, pp , S. McCanne, et. al. Toward a Common Infrastructure for Multimedia-Networking Middleware, In: Proc. International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 97), St. Louis, Missouri, S. McCanne, V. Jacobson. vic: A flexible Framework for Packet Video. In: Proc. ACM MultiMedia 95, San Francisco, ACM, New York, pp , S. McCanne, R. Katz, E. Brewer et. al. MASH Archive System. On-line: overview.html, P. Parnes, K. Synnes, D. Schefström. mmod: the multicast Media-on-Demand system On-line: mates.cdt.luth.se/software/mmod/paper/mmod.ps, H. Schulzrinne. Tools. On-line: H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. : A Transport Protocol for Real-Time Applications. Internet Draft, Audio/Video Transport Working Group, IETF, draft-ietf-avt-rtp-new-03.txt, H. Schulzrinne, A. Rao, R. Lanphier. Real Time Streaming Protocol (RTSP). Request for Comments 2326, Multiparty Multimedia Session Control Working Group, IETF, April T. Tung. MediaBoard: A Shared Whiteboard Application for the MBone. Master s Thesis, Computer Science Division (EECS), University of California, Berkeley, On-line: tecklee-masters.ps 28. VRML Consortium. Information technology -- Computer graphics and image processing -- The Virtual Reality Modeling Language (VRML) -- Part 1: Functional specification and UTF-8 encoding. ISO/IEC :1997 International Standard, December On-line: