command at the control level. In cooperative playback sessions, it is important that each member of the group has the same view as the others. It is the concept ...
An MBone-based On-demand System for Cooperative Off-line Learning G. Fortino, L. Nigro, F. Pupo Laboratorio di Ingegneria del Software DEIS – Universita’ della Calabria, I-87036 Rende (CS), Italy {g.fortino, l.nigro, f.pupo}@unical.it Abstract MBone technologies have fostered a variety of multimedia large-scale applications supporting collaborative joint work and remote group learning. Such applications span from videoconferencing to video on-demand systems. Learning centered on videoconferencing tools delivers live video, audio and whiteboard-based interaction among the participants of a multimedia session, e.g., an on-line teleteaching session. Video recording on-demand systems have the potential to augment the contents of a learning session by playing back previously archived lectures. This paper proposes a multimedia system -VICROC- enabling an original distance learning model, namely cooperative off-line learning, which merges text-based live interaction and shared control and visualization of remote playbacks. The system allows an explicit group of users, e.g., classmates, to select an archived lecture, share its playback and go over it collaborating with each other through an interactive question board.
1. Introduction The development of IP-multicast and its deployment as an overlay network over the Internet, namely MBone [2], have made available a scalable and efficient mechanism for multipoint data delivery to large interacting user groups. An assortment of multimedia applications have been developed ranging from video conferencing tools (e.g., vic and vat) to shared whiteboard and text editors (e.g., wb and nte) [13,14] to distributed virtual environments [7] to video recording on-demand systems [1,4,10,17]. These applications depend on the Light Weight Session model (LWS) and on Internet “request for comments” protocols, such as RTP (Real-time Transport Protocol) [15] for data delivery, RTSP (Real Time Streaming Protocol) [16] for data streaming control, SDP (Session Description Protocol) [8] for multimedia session description.
In particular, videoconference recording on-demand (VCRoD) systems have been developed with the purpose of providing the user with the ability to remotely record and playback multimedia sessions such as conferences, group meetings, and lectures. In such systems, a user can connect to a media server and request the recording of an advertised multimedia session, which will be archived and made accessible. Once the recording is over, the same user or another can connect to the media server, select the previously archived multimedia session and control its playback. A requested multimedia session can be played to a unicast address (e.g., the address of the requesting client) or to a multicast one. Since VCRoD systems are mainly single user oriented, normally they do not provide support for groupware. They only allow playing a presentation to a multicast address so that a group can view it. However, the presentation control is handled by its initiator, i.e., the requesting user, which connected to the media server. Groupware [6] in the context of a playback system means that a group of remotely located users cooperatively control the playback of a multimedia session and perform joint work. As an example, students, which belong to the same academic course, can access a video on-demand system in which course lessons are archived, choose a particular lesson and go over it collaborating with each other. Several applications and protocols have been developed dealing with groupware. For instance, distributed whiteboards are based on multicast transport protocols based on the SRM (Scalable Reliable Multicast) concepts [3,11]. These protocols allow a message to be reliably transmitted from a sender to multiple receivers. No strict real-time is required for message delivery. In addition, control policies are needed in order to manipulate shared objects and coordinate participants to shared sessions. Among them floor [12], token and lock based approaches have been proposed. Such technologies can be usefully employed and tuned to groupware in Internet playback systems. This paper first discusses mechanisms and policies enabling users grouped in an explicit way, e.g., through a
rendezvous tool, to jointly work and cooperatively control playbacks of on-demand multimedia sessions. Then, the architecture and client' GUI of ViCROC is described. ViCROC is an original contribution in that it delivers an integrated, collaborative multi-user playback system enabling cooperative off-line learning [18]. Moreover, a multicast control streaming protocol (MACπ) is presented. It is a multicast extension of the RTSP protocol adapted on top of LRMP [11], which is a light weight reliable multicast protocol designed according to SRM concepts [3].
2. Cooperative Playback Systems Cooperative playback sessions [5] are sessions in which a group of users shares both the view and the control of a playback, and collaborates on the contents of the presentation being played. A group of interacting users, in the sense given above, is called “explicit” cooperative group. Each participant has a remote control, which operates on a single playback shared by all. If one group member performs a seek/pause operation, that operation must be propagated, according to certain rules, to all other members of the group. They can also collaborate with each other by marking specific instants within a session and by questioning through a questionboard. Cooperative playback systems (CPS) are video ondemand systems, which provide cooperative playback sessions. They are characterized by three levels of interaction: (i) data, which involves unidirectional multicast media stream delivery from the multimedia archive server (MS) to the users; (ii) control, which entails bi-directional control messages to be sent from the users to the MS and viceversa; (iii) collaboration, which comprises messaging among users. The levels (ii) and (iii) can embody global implicit and explicit coordination policies (e.g., moderated, floorbased and lock control schemes) that manage resources or resolve conflicts between different users’ actions. In an explicit floor-controlled cooperative session, a member can issue a command (e.g., a pause) only if he/she is entitled to do it according to the adopted control policy, i.e., if he/she got the “floor”. Conversely, in a moderation-free scenario, users can perform actions with no need to ask for resources. Interaction levels are not independent; in fact, actions performed at certain levels can affect directly or indirectly other levels. For instance, a pause command at the control level has the effect to stop the media transmission at the data level. A voting
mechanism at the collaboration level can disable a seek command at the control level. In cooperative playback sessions, it is important that each member of the group has the same view as the others. It is the concept of “What You See Is What I See” (WYSIWIS). Although the consistency of the views for all the users is unachievable mainly due to the user’s distribution heterogeneity, it has to be guaranteed after performing a command such as pause or seek. For instance, after a user pauses a playback, any other user should look at the same frozen image as the one that executed the pause command. The pause command is taken into consideration because is the most critical one. In fact the seek command implicitly contains a pause since it can be subdivided into three commands: a pause, a successive seek and a play. Two approaches can be envisaged: server and user based. In the former, when a user executes a pause command, the reference pausing time is not the one of the user but that of the server, i.e., when the server receives the request and actually pauses the multimedia session. In this way, each user is synchronized with the server. The latter introduces the issue of re-synchronizing the other users with the user that executed the pause command. Several strategies can be screwed up such as those based on a per user media caching [1] but they remain out of the scope of this paper. A cooperative playback system has to be equipped at least with the following functionality: (i) Group organization contains group formation and group management. The former deals with the issues of creating a group of users who wish to work on and control the same playback session. A rendezvous mechanism has to be employed. A simple mechanism can be based on dynamically modifiable web pages where users can find a list of archived sessions and subscribe to a particular one by filling a form. Indeed, two mechanisms are currently used according to the Internet multimedia architecture [1]: Session Directory (SD) and Session Initiation Protocol (SIP). Thus, information about cooperative playback sessions can be obtained by tuning on the SD or by receiving an explicit invitation, via email or SIP notification. The information is normally under the form of an SDP document [8], which should contain at least the CPS address, in order to locate the playback service, and the title of the presentation to be played back. Group management involves issues such as how to share the starting time of a playback session. (ii) Shared state maintenance and control between users and server. The former is primarily devoted to managing the exchange of control streaming parameters between server and users. These parameters include at least: the server’s current position in time on the stream; data, control and collaboration addresses; control and
collaboration session identifiers. On the basis of these parameters, server and clients construct a shared state table, which is dynamic and modifiable during the playback session lifetime. Control contemplates messages that can be transmitted from clients to media server and viceversa in order to affect (i.e., fill and change) the shared state table and control the data transmission. Thus, the control messages are grouped in shared state table affecting commands (presentation description, presentation setup and shared table updating) and presentation control commands. Presentation description commands allow a user to both receive a list of multimedia sessions archived in the server and the description of a particular presentation. A presentation description should contain at least the presentation title, media types and related data formats in the presentation, and the presentation duration. These parameters are used by the clients to correctly set up the media presentation tools. Optional information such as the presentation creator, its email and web address, etc. can also be present. Presentation setup commands are used to request a presentation. A media server after receiving a presentation request begins a negotiation phase with the client in order to establish the media stream channels. After this phase, the server launches a player agent on the data channels. Presentation control commands include VCR-like commands, which directly affect the transmission of data. Shared table updating messages consist of replies to requests and messages such as the server’s current playtime beaconing. (iii) Fault tolerance is an important property of an Internet service, which is subjected to frequent network connectivity problems and a pacing introduction of new and not debugged protocols and software. Fault tolerance includes detection, which deals with the discovery of failures at both server and client side, and recovery, which involves actions the server and/or the clients have to carry out in order to cope with detected failures. (iv) Joint work is crucial in the context of a CPS. It is in the form of questioning and annotation. Questioning means that the members of a group can send questions about the content of the playback session and possibly receive answers. Annotation allows tagging a particular point in the session for question proposal or for a discussion proposal, which is to be started at the end of the playback. (v) Control policies are needed to regulate the access to shared resources such as the VCR commands. For instance, a user, who whishes to seek in the presentation, can do so only according to certain rules dictated by the chosen control policy. Three kinds of basic policies have been identified: (1) moderation-free, each group participant can perform a command whenever he/she wants; (2) floor-based, in order to send a command a
user needs to get the floor; (3) voting, a group member submits a command to the approval of the others, that can acknowledge or refuse it according to a majority vote. Different actions on the VCR remote control can be constrained by different control policies. For instance, the effect of the pause command is different as that of the seek. The former results in a temporarily data stream stop, which has to happen as soon as the user presses the pause button. Thus, the pause command can be subjected to the (1) or (2) policy. Conversely, a seek results in a temporal displacement from the current position in the presentation, and not only can occur within a certain tolerance range but also has to be approved by the group, which is usually concentrated to watch the presentation and doesn’t want to jump from one point to another in the presentation. The (3) policy seems to be the most appropriate for this case. How the communication patterns of the control and collaboration interaction levels are designed and implemented has a profound impact on the performance of a cooperative playback system. Although the data are always multicast relayed, control and collaboration interactions can be conveyed by exploiting unicast, multicast or a hybrid combination of both. The use of multicast versus unicast is strategic for improving efficiency and scalability. Conversely, the exploitation of Internet standard protocols, which are already deployed such as RTSP on TCP, can simplify the implementation of a CPS [4]. In the following subsections the unicast and hybrid approaches are described. The multicast approach is presented in section 3.
2.1. Unicast-based multi-connected approach The multi-connected approach (Fig. 1a) is based on RTSP on top of TCP. A user or media client (MC) who wishes to join a collaborative playback session connects to a multimedia archive server or media server (MS). Once the RTSP connection is established between server and client, the latter is served by a front-end (FE), which is encapsulated in a logic controller managing all the FEs of the other MCs attached to the same session. When an MC issues a request (e.g., play/pause methods), the server, after accepting and processing it, replies to all the MCs (Fig. 1b, section 1). By using this infrastructure an MC not only can send a command to an MS but can also interact with the other MCs, e.g., by questioning. In the latter case, the MS behaves like a reflector of messages from an MC to the others. This mechanism is achieved by sending an RTSP SET_PARAMETER request, which is labeled by a pre-defined content-type referring to the group interaction channel and contains the message to be delivered. As soon as a FE receives the request, the
control logic copies the received message to each other MCs (Fig. 1b, section 2). Although the approach is not scalable and introduces a heavy load on the server, which has to spawn as many FEs as the number of the group members, it has the advantage of using RTSP/TCP, which is well specified and its implementation is widely available. In addition, if the group size is relatively small (e.g., two classmates), the approach can be appealing. MS Control Logic FEi RTSP
RTSP
MC#1
MC#n RTSP
RTSP
MC#2
MC#k
MS. Once the MS has processed the request, it replies to the initiator that in turns reflects the response to all the other members on the group channel (Fig. 2b, section 1 and 2). The collaboration messages are also sent onto the group channel (Fig. 2b, section 3). In order to ensure a certain degree of fault tolerance in the case the session initiator fails or wants to leave, the RTSP has been enhanced. Two new methods were introduced: PASS and CONTINUE. The method PASS is performed by the initiator when he/she wants to pass the session control to another MC and leaves. When the MS receives the PASS, it disconnects the initiator and waits for another connection by freezing the FE, which was handling the connection with the IMC. The FE is kept alive till a time-out expires. The method CONTINUE is invoked by the new initiator to take control of the session. When the MS receives the CONTINUE request, it connects the new initiator to the frozen FE. If the initiator fails (e.g., leaving without sending the PASS, losing the connection with the MS) the MS behaves the same as it received a PASS invocation.
(a) MS FEi MC#1
MS
MC#2
MC#n
REQUEST
RTSP
REPLY REPLY
MC#1
IMC#n
REPLY
(1)
LRMP MC#2
MC#k
MESSAGE
(a)
MESSAGE
(2)
MESSAGE
IMC
MS
MC#2
MC#n
REQUEST
(b) Figure 1. Unicast-based multi-connected approach.
(1)
REPLY REPLY
REPLY
2.2. Hybrid approach REQUEST
In this approach (Fig. 2a), only one group member called the initiator (IMC) of the session is connected to an MS according to RTSP/TCP. All the members are grouped on a multicast channel based on the LRMP protocol. The initiator can directly send a control command to the MS (Fig. 2b). The other members wishing to send a control command have to transmit a control message (e.g., pause) to the multicast group channel. This message is captured by the initiator that encapsulates it in an RTSP request and sends it to the
(2)
REQUEST REPLY REPLY
(3)
MESSAGE
REPLY
MESSAGE
(b) Figure 2. Hybrid approach.
3. ViCROC: A PLAYBACK SYSTEM SUPPORTING COOPERATIVE OFF-LINE LEARNING ViCROC is a cooperative playback system which aims to create an environment where users can easily request playbacks of streamlined and archived conferences, lectures, movies and so forth and can also interact and collaborate to one another on the contents of the multimedia session as a virtual tightly coupled group of workmates. The architecture of ViCROC is portrayed in Figure 3. The system consists of Media Servers (MS) and Media Clients (MC). The media server is the network entity that provides playback and browsing services for multimedia sessions. It entails a MACπ Server and Player components. The service entry point (SAP) is the MACπ Server which allows media clients to request a service according to the MACπ protocol. It is composed of a Manager and FrontEnds. The former performs load monitoring and admission control. For each cooperative playback session, the Manager spawns a Front-End thread which directly dialogs with the media clients. The Front-End starts, manages and terminates the Player under the media client’ control. The component Player reads media files consisting of previously archived RTP-based multimedia sessions and streams them back onto the Media Multicast Group (MMG). The Player is borrowed from the ViCRO system [4] which is also equipped with recording functionalities for creating a multimedia archive (MMDB).
MACπ protocol specification. The Media Browser allows the user to start, control (e.g., by issuing pause and seek commands), and tear down playback sessions. The Media Presentation tools currently used are VIC for video and VAT for audio. The Collaborative Board, which is based on the COπ (COllaborative protocol), supports the exchange of questions and related answers, shared annotations, and a flexible voting mechanism.
3.1. MACπ: Multicast Archive Control protocol The primary goal of the proposed multicast archive control protocol (MACπ) is to allow media clients (MCs) explicitly grouped to access a media server (MS), request a recorded multimedia presentation, and share the control of the playback of the chosen presentation. MACπ is based on a variant of the RTSP (Real Time Streaming Protocol) adapted on top of the LRMP (Lightweight Reliable Multicast Protocol) (see Fig. 4a). However, a MACπ session is not strictly bounded to an LRMP transport session. In fact an MS creates for each playback session a SESSION ID, which identifies a MACπ session and represents a shared state between MCs and MS that will use it in the body of each exchanged message. An MS is located on an IP-multicast address. An archived multimedia session is identified through a URL as follows: macp://multicast_address:port/abs_path where multicast_address is the MS address, port indicates which port the messages should be sent to, and abs_path identifies a presentation. An example URL is: macp://224.2.100.100:5000/JavaLesson1.
MACπ Client
Media Browser
MACπ
Manager
Collaborative Board
Front-End #i
LRMP UDP
MACπ Multicast Address
Media Presentation Tools
Player #i
MEDIA CLIENT #k
Media Multicast Group
COπ
MEDIA SERVER
MC#1
FEi
MACπ MC#2
MC#n
MC#3
IP-Multicast a)
RTP
MS
MACπ
MACπ Server
b)
MMDB
CO π Multicast Address
Figure 3. The architecture of ViCROC. The media client is the network entity that requests and controls continuous media data from the media server. It consists of the MACπ client, a Media Browser, a Collaborative Board and Media Presentation tools. The MACπ client implements the client part according to the
Figure 4. (a) Protocol stack of MACπ. (b) A MACπ session. FE is the server’s front-end of the session. MACπ control messages are categorized in requests, responses and notifications. A request is sent from MCs to the MS and is considered provisional in the sense that an MC waits for the response before changing state. A response is transmitted from the MS to all the MCs of the group as a result of an accepted request. It synchronizes the behavior of each MC. A notification is sent either from MCs to the MS or viceversa and does not imply a response.
MC#1
MS
MC#2
MC#n
DESCRIBE REPLY
REPLY
REPLY
SETUP REPLY
REPLY
REPLY
REPLY
REPLY
REPLY
fragmented in more packets at the sender, and reassembled at the receiver. Since an LRMP message is multicast to all the session members and can carry out a control message part, a header containing the message target (single MC or broadcast) and the fragment number is associated to each MACπ message.
PLAY
3.2. COπ: Collaborative protocol
PAUSE REPLY [PAUSE TIME]
REPLY [PAUSE TIME]
REPLY [PAUSE TIME]
BEACON [TIME]
BEACON [TIME]
BEACON [TIME]
LEAVE TEARDOWN REPLY
REPLY
Figure 5. An interaction scenario where a group of n MCs is involved in a MACπ session. MACπ control messages are structured as RTSP messages in a header, split in several sub-headers, and a message body. The request and notification messages include the Request Line, which contains the Request URI specifying the resource (i.e., the presentation) subject to the request and the Method or command to be executed. The response message embodies the Status Line, which contains the Status Code indicating the result of the command execution carried out in the previous request, and the Method executed. The defined standard methods are: Describe, Setup, Play, Pause, Teardown, which are used in MC-to-MS requests, Leave and Beacon, which are used in notifications. Describe serves to obtain from the MS the description of a presentation to be played back. Setup causes the MS to allocate resources for a presentation and starts the MACπ session. Play starts the presentation streaming. Pause temporarily halts the data streaming without freeing MS resources. Teardown frees resources associate with a presentation, so that the MACπ session terminates. Leave signals an MC’ abandon to the MS. Beacon updates states. In figure 5 a typical MACπ session is shown. LRMP [11] is a reliable multicast protocol designed to meet the requirements of many-to-many reliable message transfers in a large interacting group of users. It was implemented in Java under the form of a reusable library. After opening an LRMP session, the MACπ control messages are to be first encapsulated in LRMP packets in order to be transmitted. Since the maximum transmission unit (MTU) has been fixed to 1400 bytes, it is possible that a MACπ message spans more LRMP packets. In order to minimize the occurrence of a spanning, which would result in efficiency degradation, the message is first compressed by using a Gzipper block, and then, if it fits the MTU, put in one LRMP packet, otherwise, it is
The collaborative protocol (COπ) was purposely implemented to support both questioning on the playback session contents and synchronization on the control commands among the media clients (see Figure 6). Its main characteristics are: (i) it centres on the concepts of the CCCP (Conference Control Channel Protocol) [9]. It doesn't exist a master application which controls the conference and maintains data consistency, instead each application is responsible of sending and receiving its own data on a common multicast channel; (ii) messages are based on the LRMP protocol; (iii) inter-client communication takes place onto a known multicast group. The main COπ functionality encompasses: (i) an identification of media clients; (ii) a voting mechanism on particular control commands (PLAY, SEEK and TEARDOWN); (iii) an interactive remote questioning. MC#1
∆t
MC#2
MC#n
MC#2’IDENTITY
MC #2’IDENTITY
SEEK PROPOSAL
SEEK PROPOSAL
CMD ANSWER
CMD ANSWER
PLAY {Trange}
QUESTION MC#1’ ANSW ER MC#2’ ANSW ER
QUESTION MC#1’ ANSW ER MC#2’ ANSW ER
Figure 6. An interaction scenario where a group of n MCs is involved in a COπ session. 3.2.1 Identification of media clients. COπ uses a “soft state” approach [17] based on announcement message exchanges for the conference members identification. A client introduces itself through an announcement message. Every client involved in a cooperative playback session stores in a state table the identity of the known announced members. The state table is periodically refreshed: at a timer expiration (∆t) the presence/absence of a message announcement from a member in the state table is verified. If a member didn’t
send an announce message (called also "heart beat" message), the member is considered lost. A member can explicitly decide to leave the session by sending a LEAVE message. 3.2.2. Voting mechanism. The voting mechanism allows handling the remote control commands Play, Seek and Teardown. Since such commands are shared among the clients, they can be issued only if the majority of the playback session members agrees. When a client wants to execute a shared command, he/she sends a command proposal message and waits for answers from the other participants within a deadline of 5s. The answers can be positive or negative. In the case of a Play or a Seek command, the total positive answers are to be the majority with respect to the total number of members. In the case of a Teardown command, the total positive answer must be equal to the total number of members. A not sent answer is considered a negative answer.
Figure 7. Collaborative GUI.
3.2.3. Interactive remote questioning. The COπ protocol makes it possible the interactive remote questioning among the playback session members. Questions can be directed to all the participants (public question) or to a specific client (private question). It is also possible to hide the identity of the questioner.
3.3. Media Client's GUI The Media Client system's GUI consists of three parts: media, control and collaborative. The control and collaborative parts are linked through a CCCP-like [9] interface. In the following, the three GUI are outlined by examples. Figure 7 depicts the base collaborative GUI. The collaborative GUI appears when the SETUP phase (see §3.1) is completed. It presents on its top-center part six buttons which are respectively named: "". The button Attendees displays a panel that lists information about all the members of the playback session (see fig. 9). The button Questions visualizes the panel to submit questions. It is possible to insert a question and send it to the cooperative session group. The question panel also highlights the cooperative session address, port and TTL (225.2.100.100/3666/15). The Answers button causes a panel which lists all the answers received during the session to appear. In addition, it gives the functionality to archive the answers into a file. The Talk button enables an MTalk board among the session participants. The buttons "" permit scrolling the above mentioned panels.
(a)
(b) Figure 8. (a) Command and (b) Monitoring GUI of ViCROC.
Figure 8a shows the dialog box by which a media client can accept or refuse a control command on the playback session which was raised by a session member (i.e., “Antonio”). If the media client presses the button accept, a positive answer is expressed, else if he/she presses the button refuse or doesn’t press any button within a certain deadline (e.g., 3s), a negative answer is issued. Each member of the session can control the voting process by using the monitoring GUI (see Fig. 8b). In this case, the proposal command Play is accepted as
depicted in Figure 8b: the textfield CurrentState reports “Command Accepted!” Figure 9 shows a media client “Antonio” which sends through its collaborative GUI a question to a media client “Giancarlo” who participates to the same playback session. When the question reaches “Giancarlo”, a dialog box appears on its media client’s GUI and allows to insert the reply. For each playback session attendee, statistics about loss rate, transmitted packets, duplicates, repairs, etc. are reported
Figure 9. Remote questioning among two media clients.
Figure 10. Media GUI and Media Browser of ViCROC.
In Figure 10, the media and control GUI of ViCROC is shown. Two media clients are attending an audio/video playback session on the URL: rtsp://228.114.228.114/Lecture1. The video tool employed is vic and the audio tool is vat. The voting mechanism is triggered when the Play (after a Pause command) or Stop button is pressed, or the Seek slider of the client's Media Browser is moved.
4. Conclusions Cooperative off-line learning is an original group interaction pattern discussed in this paper which enables a group of users to jointly work and share a playback session. Mechanisms, functionality and issues of cooperative playback systems over the Internet MBone are presented. ViCROC, a Java-enabled cooperative playback system, has been introduced and its main components described. On-going work aims at: (i) testing the implemented system in playback sessions involving many users so as to evaluate its scalability, robustness and efficiency, and its impact to the education; (ii) re-implementing the media client's GUI using the Swing API; (iii) employing the Java Media Framework 2.0 to play audio/video media streams, in order to obtain a completely Java-based system; (iv) formalizing the MACπ protocol as multicast-RTSP and possibly publishing it as an informational RFC.
5. References [1] K.C. Almeroth and M.H. Ammar, “The Interactive Multimedia Jukebox (IMJ): A new Paradigm for the On-Demand Delivery of Audio/Video”, Proc. of the 7 th Int. World Wide Web Conference (WWW7), 1998. [2] J. Crowcroft, M. Handley, and I. Wakeman, Internetworking Multimedia, UCL press, UK. 1999. [3] S. Floyd, V. Jacobson, S. McCanne, C. Liu, and L. Zhang, “A reliable multicast framework for light-weight sessions and application level framing”, ACM Transactions on Networking, Nov. 1996. [4] G. Fortino and L. Nigro, “ViCRO: an interactive and cooperative videorecording on demand system over Internet MBone”, Informatica-An Int. J. of Computing and Informatics,
24, pp. 97-105, 2000. [5] G. Fortino and L. Nigro, “A cooperative playback system for on-demand multimedia sessions over Internet”, Proc. of IEEE Conference on Multimedia and Expo, New York, USA, Aug. 2000. [6] W. Geyer and W. Effelsberg, “The Digital Lecture Board – A teaching and learning tool for Remote Instruction in Higher Education”, Proc of ED-MEDIA’98 - World Conference on Educational Multimedia and Hypermedia, Freiburg, Germany, June 1998. [7] N.D. Georganas, E.M. Petriu, M. Cordea, and D. Ionescu, “Distributed Virtual Environments for Training and Telecollaboration”, Proc. of IMTC’99, Venice, Italy, 1999. [8] M. Handley and V. Jacobson, “SDP: Session Description Protocol”, IETF RFC 2327, Apr. 1998. [9] M. Handley, I. Wakeman, and J. Crowcroft, “The Conference Control Channel Protocol (CCCP): A scalable base for building conference control applications”, Proc. of SIGCOMM Symposium on Communications Architectures and Protocols, (Cambridge, Massachusetts), pp. 275-287, Sept. 1995. [10] W. Holfelder, “Interactive remote recording and playback of multicast videoconferences”, Proc. of IDMS’97, Darmstadt, Germany, Sep. 1997. [11] T. Liao, “Light-weight Reliable Multicast Protocol”, 1998. http://webcanal.inria.fr/lrmp/. [12] R. Malpani and L. Rowe, “Floor Control for Large-Scale MBone Seminars”, Proc. of ACM Multimedia, April 1997. [13] “Mash streaming media toolkit and distributed collaboration applications based on the Internet MBone tools and protocols: software and documentation on-line”. University of Berkeley (CA), USA, 2001. http://www.openmash.org/. [14] “MBone Tools: software and documentation on-line”. University College of London (UK), 2001. http://www-mice.cs.ucl.ac.uk/multimedia/index.html [15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: a Transport Protocol for Real-Time Applications”, IETF RFC 1889, Jan. 1996. [16] H. Schulzrinne, A. Rao, R. Lanphier, “Real Time Streaming Protocol (RTSP)”, IETF RFC 2326, 1998. [17] A. Shuett, S. Raman, Y. Chawathe, S. McCanne, and R. Katz, “A Soft State Protocol for Accessing Multimedia Archives”, Proc. of NOSSDAV’98, Cambridge, UK, July 1998. [18] M.J. Sipusic, R.L. Pannoni, R.B. Smith, J. Dutra, J.F. Gibbons, and W.R. Sutherland, “Virtual Collaborative Learning: A Comparison between Face-to-Face Tutored Video Instruction (TVI) and Distributed Tutored Video Instruction (DTVI)”, Technical Report SMLI TR-99-72, Sun Microsystems Laboratories, Palo Alto (CA), USA, Jan. 1999.
